rudy_b

Причина, скорее всего, простая - высокая напряженность поля в конце секционированной обмотки относительно феррита. И это вы не победите никаким, даже самым лучшим пластиком - все равно пробьется со временем - нужно менять конструкцию. Возможно это не совсем понятно, но поле оказывается очень большим в связи с малым диаметром провода, но это долго объяснять. Нужно снижать (выравнивать) напряженность поля у высоковольтного края обмотки. Это можно сделать использовав пирамидальную намотку, т.е. каждый слой поверх следующего со снижением длины слоя обмотки. При этом по мере роста напряжения на обмотке увеличивается расстояние до феррита + поле у края верхней обмотки определяется не керном, а предыдущим слоем - т.е. значительно меньше. Именно так намотана обмотка ТВС в телевизорах, а это хорошо вылизанные и долгоиграющие детали. Вы легко можете посмотреть напряженности полей в программе FEMM4.2 - сделайте осесимметричную модель, можно даже на статике и все поймете сами. Сделайте 2 варианта - с вашей и с пирамидальной намоткой и сравните. Программа бесплатная с неплохим хелпом и примерами, правда на аглицком и с несколько неудобным интерфейсом, но разобраться можно довольно быстро.

Нет. Время вашего старта и ваша частота оцифровки произвольны по отношению к сигналу и его частотному спектру.

Тут может быть много самых разных проблем. посмотрите тут и тут.

Может я чего-то не понимаю, но ваши рассуждения кажутся мне странными. Не существует такого понятия как фаза сигнала, есть только разность фаз, например фазовый сдвиг между излучаемым и принимаемым сигналом, а, именно, бесконечно длительным синусом фиксированной частоты. В вашем случае (не синус) правильно использовать не фазу, а временной сдвиг между передаваемым и принимаемым сигналом, или между двумя принимаемыми разными приемниками сигналами. Это связано с тем, что если использовать понятие разности фаз между передаваемым и принимаемым сигналом, то она будет зависеть от частоты (в пределах спектра сигнала) и для каждой частоты будет свой фазовый сдвиг (расстояние деленное на длину волны).

А лучше добавить такой же комплексный импульс, но в противофазе для гашения раскачки.

В стандартных случаях источником запроса на прерывание является периферия, DMA и т.п. Например при приеме байта UART при разрешенном прерывании, таймер, SPI и т.д. Они устанавливают запрос на прерывание, он отрабатывается процессором и запускается соответствующий обработчик прерывания. Для сброса источника прерывания, как правило, нужно считать соответствующий регистр или ручками сбросить бит в периферии. А, затем, снять бит в NVIC процессора. Последнее может делаться автоматически при возврате из прерывания по reti.

Сразу видно, что вы не умеете работать с прерываниями. В начале нужно сбросить не флаг прерывания, а источник запроса, и, только потом, сбрасывать флаг (pending бит)

Есть стандартная проблема при обработке прерываний - перед выходом из прерывания нужно проверить, не пришло ли еще одно и, если пришло обработать его и т.д. Если этого не сделать - то можно пропустить следующее прерывание, т.к. оно может быть сброшено при выходе из прерываний. По хорошему - в начале обработки сбросить pending бит, а в конце проверить не встал ли он снова. Если точнее, в начале сбросить источник запроса на прерывание, сбросить pending бит, в конце - проверить pending бит.

У меня Мегафон. И действия операторов меняются быстро - проблемы 10-летней давности частично поправлены, но, похоже, взамен старых проблем появляются новые. Но, увы, у операторов нет никаких статей, хелпов, errat и т.п. Если бы они эти проблемы хотя бы обозначили - сколько времени было бы сэкономлено.

Ну вот, провел еще один эксперимент - открыл UDP сессию модема на 1 час 56 минут. Закрыл сессию сам по окончании эксперимента. Результат - ни адреса, ни порты за время сессии не изменялись, пакеты (с некоторой точностью - см. далее) ходили туда и обратно. Возможно мне повезло. Но выяснилась одна интересная подробность. В NAT, кроме внешнего адреса и порта есть, похоже, и еще один параметр - что-то типа "Разрешение трансляции внешнего пакета на локальный адрес модема". Этот параметр исходно выключен, но первый пришедший пакет его включает на время 16-20 минут (специально проверил, но грубо), а сам пакет пропадает (не транслируется). Если следующий пакет придет до истечения этого интервала - он пройдет и продлит интервал на это же время (это предположение, специально не проверялось). Если интервал между пакетами превышен, то пришедший пакет включит разрешение, но сам пропадет. Причем при открытии UDP сессии этот параметр отключен - вот почему пропадает первый ответный пакет сервера после открытия сессии. Т.е. для нормальной работы сервер должен посылать два пакета - первый, "просирающий" NAT, который может пропасть, и, только затем, второй с данными. И вот это уже почти точно проделки оператора. Да уж, накрутили ребята...

А можно ли сделать выпадающий или скрытый текст для длинного текста? Он будет занимать одну строку в закрытом виде и разворачиваться только если пользователь его открывает?

Не хочу спорить с опытным человеком, возможно вы правы. Мой опыт слишком невелик. Поживем - увидим, если поживем.

Именно до дисконнекта. Возможно и существуют какие-то таймауты разрывающие соединение, но их срабатывание автоматически приведет именно к дисконекту соединения. При этом сотрутся параметры NAT. Я, при тестировании, неоднократно висел в UDP довольно долго - несколько десятков минут без передачи пакетов и все работало. И модему нет необходимости долго висеть в UDP - послал запрос, получил ответ, завершил сессию.

В момент подъема GPRS модему присваивается локальный адрес, который сохраняется до отключения GPRS. В момент коннекта (запуска сессии UDP модема), формируются и сохраняются данные NAT, т.е. выделяются внешний адрес и порт и запоминается связь между внешним адресом и портом и локальным адресом и портом. Все пакеты, поступающие на выделенные внешний адрес и порт транслируются на соответствующий локальный адрес и порт. Вот на какой именно локальный порт - не знаю, задание порта UDP не влияет или незаметно. Запомненные параметры NAT должны сохранятся до дисконнекта (завершения сессии UDP модема). Так что у оператора нет проблем на какой локальный адрес отправить пакет, пришедший на конкретный внешний адрес и порт. Эта информация запомнена в NAT и сохраняется вплоть до дисконнекта. Другие данные поступающего пакета ( в частности порт отправителя) в общем случае не должны проверятся. То, что пакеты фильтруются по порту отправителя - это дополнительная фича.

Ух, тяжек путь познания. Запустил Wireshark и посмотрел ответные пакеты от моего UDP сервера и от SocketTest в одной сессии модема. Вы правы, контрольная сумма IP заголовка может быть равна нулю - и так и есть в обоих случаях. Пакеты различаются только в одной детали - порте отправителя. Мой сервер отвечает с того же порта, на который пришел пакет. А вот SocketTest отвечает с другого порта, то ли случайно выбранного, то ли назначенного, но изменить его ручками нельзя. Формально это вполне допустимо, но, похоже, не в этом случае. Получается, что оператор или сам модем блокируют пакеты, если порт отправителя не совпадает с тем портом, который был указан при коннекте. Можно предположить, для чего была сделана такая фильтрация. В старых форумах народ ругался на то, что как только открываешь UDP, на него начинает валиться разный мусор, предложения от операторов и т.п. Эти пакеты попадают в трафик и платит за них пользователь. Возможно оператор добавил такую фильтрацию для блокировки этого. А может это делает сам модем. Так что моя ругань на SocketTest неправильна, точнее не совсем правильна.