Rst7

Ну как бы *p++=v явно быстрее, чем fwrite(&v,sizeof(v),1,f) Я, понятное дело, про накладные расходы и прочее, если одно и другое вызвать 32768 раза (чтобы получить 128К данных)

Для узкополосной - улучшится.

Ну так просто расширение полосы сигнала приводит к увеличению и шума тоже, полоса-то шире в n раз, шум больше в sqrt(n). И меняете шило на мыло.

Смотрите, у Вас есть две полосы. Пусть f - это ширина полосы полезного сигнала до расширения спектра, F - после. F много больше f. Если Вы к сигналу с полосой F примешиваете шум (тоже с полосой F, лишнее надо отфильтровать до перемножения с ПСП), то после перемножения с ПСП в приемнике ширина спектра полезного сигнала становится f, а шума остается все равно F (грубо говоря). Теперь надо отфильтровать полезный сигнал с полосой f, и тогда уровень сигнала помехи упадет на выходе в sqrt(F/f) раз. А уровень полезного сигнала после перемножения возрастет в F/f раз. С узкополосной помехой будет то же самое - энергия размажется по спектру, и лишнее отфильтруется. Может Вы там в своих моделях забыли фильтры поставить?

В борьбе с многолучевым распространением в основном.

Куча есть КВ-радиоприемников с ключевыми смесителями на входе. И вполне адекватно работают.

Если Вы думаете, что запустив этот АЦП с частотой семплирования 500кГц, получится 24 бита - то Вы ошибаетесь. Там 24 бита не получается даже на 48кГц, RMS шума примерно -120dbFS у него с такой частотой дискретизации. И такого же порядка побочные продукты, где-то -120dBc. А если сделать 500кГц, то ситуация ухудшается даже не на 20дБ, а на все 30, а то и 40. Рекомендую все таки гетеродин, смеситель и оцифровку ПЧ с узкой полосой. Если смеситель на ключах сделать, то вполне 120дБ динамического диапазона можно получить без проблем. PS Кстати, сдается мне, что это гидроакустика ;)

Плохо искали. Например - https://www.sensirion.com/en/flow-sensors/differential-pressure-sensors/differential-pressure-sensor-asp-1400/ И таких есть разных.

Ну во-первых, кругом у Вас обведен не мифический контроллер питания, а обычная SMD-индуктивность номиналом 3.3мкГн. Пусть пальцем покажут, что именно эти ремонтники меняли. Во-вторых качество пайки - ну обычное среднепотолочное. Если тут и менялось что-то руками, то так и будет выглядеть.

Даже и медленно там будь-здоров. Оценить можно примерно так. Сила лобового сопротивления будет вот такого порядка (это вариант, когда лодочка стоит поперек течения): Cf сразу возьмем равным 1, нас только порядок цифр интересует, двойку тоже выбрасываем. Давление - это P=F/S, т.е. P=плотность*v^2. 1000кг/м^3 * (0.1м/с)^2 = 10Па. К сожалению, там квадрат скорости, потому 100-паскальный манометр перегрузится уже при скорости 0.3м/с. Ну можно поставить еще дополнительный на большие скорости. Хотя зачем, не нужен никакой дополнительный, потому что Вам надо 0 градусов относительно течения держать, а это 0 давления. Ну или совсем колхоз - не датчик давления, а просто шарик в этой трубке. И два датчика - шарик слева от ДП - право руля, шарик справа от ДП - лево руля.

Да ладно, там будь-здоров перепады давления.

Т.е. как раз по показаниям 0 у такого диффманометра.

Ну так и поставьте дифференциальный манометр между кингстонами на бортах и будет вам счастье.

А что Вас удивляет? С точки зрения файловой системы - это вполне адекватно. После того, как случился fopen и имя файла перестало что-то значить (а стал что-то значить хэндл), переименование - вполне допустимая операция.

Переименовать в какой-нибудь .bak (это можно сделать с открытыми файлами), положить новый файл с нужным именем (в Вашем случае - 3966.ttf) и перегрузиться. Никаких линухов для этого не надо.

Moderator: Да какое же, черт возьми, отношение имеет этот вопрос к разработке интегральных схем? Тему перенес.

Да нормальный путь. Особенно с учетом того, что можно сделать вот так: Можно. С моей точки зрения 5 секунд вполне достаточно.

Да, конечно, правильно - ISN, а не ISS. Пардон. "Что-то с памятью моей стало" (с)

Нет. Это сквозной счетчик, один на всех. Типа +1 каждые 0.1мкс, так рекомендовано (если мне память не изменяет). Тоже защита от старых пакетов.

Именно. Можно. Но, к сожалению, эта настройка на сервере крутится, а не на клиенте. С другой стороны, клиент может послать RST не сразу по получению ACK на FIN, а через паузу. Ну, скажем, через 5 секунд. Именно этим сымитировав уменьшение настройки MSL на сервере.

Это понятно. Но есть нюанс. Связанный с ISS, который довольно бодро убежит вперед и опоздавшие пакеты будут отброшены следующим соединением (если вдруг чудо случится, и совпадут ip/port) как не попадающие в окно. В общем, вероятность последующего провала из-за отказа от TIME_WAIT крайне невелика. Ну и давайте посмотрим правде в глаза, и скажем, что MSL в 120 секунд в наше время - это с явно излишним запасом.

Не надо заменять FIN на RST. Надо послать дополнительный сегмент (RST) при приходе валидного ACK в состоянии CLOSING и LAST-ACK. Ну WireShark много чего красным красит. Это ж не повод для беспокойства в конкретно данном случае.

Ну так посыл последнего RST и происходит со стороны клиента. Добавьте там генерацию такого сегмента в состоянии получения ACK на FIN, и все будет хорошо.

Moderator: @Zoltrix, Вам последнее предупреждение.

Конечно. Заводите у блока N флагов broadcast (N - количество портов). Порт, в который пришел широковещательный пакет, выставляет все флаги в 1, кроме собственного, и засовывает этого номер блока в fifo всем остальным портам. Каждый порт после отправки содержимого блока сбрасывает в 0 только флаг, соответствующий своему номеру и проверяет, если все флаги стали равны 0, то отправляет блок в список свободных. Если не все флаги равны 0, то с блоком ничего не делается. Освободит его последний, кто его передал.