Jump to content

    

Rst7

Модераторы
  • Content Count

    4564
  • Joined

Everything posted by Rst7


  1. Смотрите, у Вас есть две полосы. Пусть f - это ширина полосы полезного сигнала до расширения спектра, F - после. F много больше f. Если Вы к сигналу с полосой F примешиваете шум (тоже с полосой F, лишнее надо отфильтровать до перемножения с ПСП), то после перемножения с ПСП в приемнике ширина спектра полезного сигнала становится f, а шума остается все равно F (грубо говоря). Теперь надо отфильтровать полезный сигнал с полосой f, и тогда уровень сигнала помехи упадет на выходе в sqrt(F/f) раз. А уровень полезного сигнала после перемножения возрастет в F/f раз. С узкополосной помехой будет то же самое - энергия размажется по спектру, и лишнее отфильтруется. Может Вы там в своих моделях забыли фильтры поставить?
  2. В борьбе с многолучевым распространением в основном.
  3. Куча есть КВ-радиоприемников с ключевыми смесителями на входе. И вполне адекватно работают.
  4. Если Вы думаете, что запустив этот АЦП с частотой семплирования 500кГц, получится 24 бита - то Вы ошибаетесь. Там 24 бита не получается даже на 48кГц, RMS шума примерно -120dbFS у него с такой частотой дискретизации. И такого же порядка побочные продукты, где-то -120dBc. А если сделать 500кГц, то ситуация ухудшается даже не на 20дБ, а на все 30, а то и 40. Рекомендую все таки гетеродин, смеситель и оцифровку ПЧ с узкой полосой. Если смеситель на ключах сделать, то вполне 120дБ динамического диапазона можно получить без проблем. PS Кстати, сдается мне, что это гидроакустика ;)
  5. Плохо искали. Например - https://www.sensirion.com/en/flow-sensors/differential-pressure-sensors/differential-pressure-sensor-asp-1400/ И таких есть разных.
  6. Ну во-первых, кругом у Вас обведен не мифический контроллер питания, а обычная SMD-индуктивность номиналом 3.3мкГн. Пусть пальцем покажут, что именно эти ремонтники меняли. Во-вторых качество пайки - ну обычное среднепотолочное. Если тут и менялось что-то руками, то так и будет выглядеть.
  7. Даже и медленно там будь-здоров. Оценить можно примерно так. Сила лобового сопротивления будет вот такого порядка (это вариант, когда лодочка стоит поперек течения): Cf сразу возьмем равным 1, нас только порядок цифр интересует, двойку тоже выбрасываем. Давление - это P=F/S, т.е. P=плотность*v^2. 1000кг/м^3 * (0.1м/с)^2 = 10Па. К сожалению, там квадрат скорости, потому 100-паскальный манометр перегрузится уже при скорости 0.3м/с. Ну можно поставить еще дополнительный на большие скорости. Хотя зачем, не нужен никакой дополнительный, потому что Вам надо 0 градусов относительно течения держать, а это 0 давления. Ну или совсем колхоз - не датчик давления, а просто шарик в этой трубке. И два датчика - шарик слева от ДП - право руля, шарик справа от ДП - лево руля.
  8. Да ладно, там будь-здоров перепады давления.
  9. Т.е. как раз по показаниям 0 у такого диффманометра.
  10. Ну так и поставьте дифференциальный манометр между кингстонами на бортах и будет вам счастье.
  11. А что Вас удивляет? С точки зрения файловой системы - это вполне адекватно. После того, как случился fopen и имя файла перестало что-то значить (а стал что-то значить хэндл), переименование - вполне допустимая операция.
  12. Переименовать в какой-нибудь .bak (это можно сделать с открытыми файлами), положить новый файл с нужным именем (в Вашем случае - 3966.ttf) и перегрузиться. Никаких линухов для этого не надо.
  13. Moderator: Да какое же, черт возьми, отношение имеет этот вопрос к разработке интегральных схем? Тему перенес.
  14. Да нормальный путь. Особенно с учетом того, что можно сделать вот так: Можно. С моей точки зрения 5 секунд вполне достаточно.
  15. Да, конечно, правильно - ISN, а не ISS. Пардон. "Что-то с памятью моей стало" (с)
  16. Нет. Это сквозной счетчик, один на всех. Типа +1 каждые 0.1мкс, так рекомендовано (если мне память не изменяет). Тоже защита от старых пакетов.
  17. Именно. Можно. Но, к сожалению, эта настройка на сервере крутится, а не на клиенте. С другой стороны, клиент может послать RST не сразу по получению ACK на FIN, а через паузу. Ну, скажем, через 5 секунд. Именно этим сымитировав уменьшение настройки MSL на сервере.
  18. Это понятно. Но есть нюанс. Связанный с ISS, который довольно бодро убежит вперед и опоздавшие пакеты будут отброшены следующим соединением (если вдруг чудо случится, и совпадут ip/port) как не попадающие в окно. В общем, вероятность последующего провала из-за отказа от TIME_WAIT крайне невелика. Ну и давайте посмотрим правде в глаза, и скажем, что MSL в 120 секунд в наше время - это с явно излишним запасом.
  19. Не надо заменять FIN на RST. Надо послать дополнительный сегмент (RST) при приходе валидного ACK в состоянии CLOSING и LAST-ACK. Ну WireShark много чего красным красит. Это ж не повод для беспокойства в конкретно данном случае.
  20. Ну так посыл последнего RST и происходит со стороны клиента. Добавьте там генерацию такого сегмента в состоянии получения ACK на FIN, и все будет хорошо.
  21. Moderator: @Zoltrix, Вам последнее предупреждение.
  22. Конечно. Заводите у блока N флагов broadcast (N - количество портов). Порт, в который пришел широковещательный пакет, выставляет все флаги в 1, кроме собственного, и засовывает этого номер блока в fifo всем остальным портам. Каждый порт после отправки содержимого блока сбрасывает в 0 только флаг, соответствующий своему номеру и проверяет, если все флаги стали равны 0, то отправляет блок в список свободных. Если не все флаги равны 0, то с блоком ничего не делается. Освободит его последний, кто его передал.
  23. Moderator: К сожалению, кое-кто не внял предупреждению. R/O на неделю.
  24. Moderator: Посты с офтопиком (а сравнение производительности в данной теме - офтопик) убраны. Потрудитесь соблюдать правила, ибо в следующий раз будут наказания.
  25. Уважаемый, у Вас тоже явная проблема в общении. И бан в гугле выписан, как я посмотрю. И во внимательности и вообще в способности ориентироваться в RFC, относящихся к TCP, например. Потому что есть еще RFC1122 "Requirements for Internet Hosts -- Communication Layers". Ну и так желаемый Вами пруф - https://tools.ietf.org/html/rfc1122#page-101 И вообще там раздел 4.2 говорит очень многие вещи, которых нет в RFC793.