Перейти к содержанию
Поиск
    

Rst7

Модератор
 Профиль  Обзор контента

  • Постов

    4 619

  • Зарегистрирован

  • Победитель дней

    2

 Тип контента 

Сообщения, опубликованные Rst7

  1. Опубликовано · Пожаловаться

    9 hours ago, Harvester said:

    Предыдущий программист реализовал самодельную буферизацию вывода: записываемые данные сначала заносятся в промежуточный буфер (127 КБайт), а при его заполнении вызывается функция write().

    Не могу понять - чем этот подход лучше по сравнению с использованием fwrite(), которая, по факту, делает то же самое?

    Ну как бы *p++=v явно быстрее, чем fwrite(&v,sizeof(v),1,f)

    Я, понятное дело, про накладные расходы и прочее, если одно и другое вызвать 32768 раза (чтобы получить 128К данных)

  3. Опубликовано · Пожаловаться

    1 hour ago, Zelenecul said:

    Мощность передатчика и скорость передачи данных предполагается оставить неизменными.

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

  4. Опубликовано · Пожаловаться

    24 minutes ago, Zelenecul said:

    если у меня есть устройство с BPSK модуляцией, меня устраивает скорость и дальность

    Смотрите, у Вас есть две полосы. Пусть f - это ширина полосы полезного сигнала до расширения спектра, F - после. F много больше f.

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

    Может Вы там в своих моделях забыли фильтры поставить?

  6. Опубликовано · Пожаловаться

    4 hours ago, Абырвалг said:

    Если делать на ключах, гармоники гетеродина всё не загадят?

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

  7. Опубликовано · Пожаловаться

    On 9/9/2020 at 11:45 AM, Абырвалг said:

    1) АЦП 24 бита, 500 кГц, 8 каналов одновременно.

     

    On 9/9/2020 at 12:10 PM, Абырвалг said:

    24 бита - принципиально. Последовательно. АЦП прикинули AK5578.

    Если Вы думаете, что запустив этот АЦП с частотой семплирования 500кГц, получится 24 бита - то Вы ошибаетесь.

    Там 24 бита не получается даже на 48кГц, RMS шума примерно -120dbFS у него с такой частотой дискретизации. И такого же порядка побочные продукты, где-то -120dBc.

    А если сделать 500кГц, то ситуация ухудшается даже не на 20дБ, а на все 30, а то и 40.

     

    Рекомендую все таки гетеродин, смеситель и оцифровку ПЧ с узкой полосой. Если смеситель на ключах сделать, то вполне 120дБ динамического диапазона можно получить без проблем.

     

    PS Кстати, сдается мне, что это гидроакустика ;)

     

     

  8. Опубликовано · Пожаловаться

    38 minutes ago, whale said:

    Самый лучший цифровой дат давления который я видел на сапфировой подложке в шумах выдавал максимум разрешения 1000Па

    Плохо искали.

    Например - https://www.sensirion.com/en/flow-sensors/differential-pressure-sensors/differential-pressure-sensor-asp-1400/

    И таких есть разных.

  9. Опубликовано · Пожаловаться

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

    Во-вторых качество пайки - ну обычное среднепотолочное. Если тут и менялось что-то руками, то так и будет выглядеть.

  10. Опубликовано · Пожаловаться

    38 minutes ago, whale said:

    если  только до 40км/ч разогнаться ) Тут все очень медленно.

    Даже и медленно там будь-здоров. Оценить можно примерно так. Сила лобового сопротивления будет вот такого порядка (это вариант, когда лодочка стоит поперек течения):

    image.png.3ed8f88644eb4c0a17fd91f24f5c21f4.png

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

     

    Хотя зачем, не нужен никакой дополнительный, потому что Вам надо 0 градусов относительно течения держать, а это 0 давления.

     

    Ну или совсем колхоз - не датчик давления, а просто шарик в этой трубке. И два датчика - шарик слева от ДП - право руля, шарик справа от ДП - лево руля.

  12. Опубликовано · Пожаловаться

    17 minutes ago, whale said:

    Это автоматическая лодка-робот, в ее задачу входить держаться против течения при любой ее скорости 

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

  13. Опубликовано · Пожаловаться

    38 minutes ago, whale said:

    У рыб например по бокам стоят датчики давления и по разности с них она определяет свое положение по отношению к течению

    но все равно там присутствует та же проблема и как ее решают рыбы неясно.

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

  14. Опубликовано · Пожаловаться

    42 minutes ago, ViKo said:

    Получается, удалить - заменить нельзя, а переименовать можно.

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

  15. Опубликовано · Пожаловаться

    46 minutes ago, ViKo said:

    Как его удалить?

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

  17. Опубликовано · Пожаловаться

    4 hours ago, Ruslan1 said:

    Уже понял, что путь с вставкой RST не такой безоблачный, как хотелось бы.

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

    On 7/24/2020 at 5:13 PM, Rst7 said:

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

     

     

    4 hours ago, Ruslan1 said:

    Можно ли меньше?

    Можно. С моей точки зрения 5 секунд вполне достаточно.

  19. Опубликовано · Пожаловаться

    22 minutes ago, jcxz said:

    А TCP-сервера по умолчанию не обнуляют их при новом коннекте?

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

     

  20. Опубликовано · Пожаловаться

    5 minutes ago, jcxz said:

    Это что такое? Уж не про номера TCP-последовательностей ли, необнулямые при новом коннекте?

    Именно.

    5 minutes ago, jcxz said:

    Значение MSL можно принять соответствующим современным реалиям скорости доставки 

    Можно. Но, к сожалению, эта настройка на сервере крутится, а не на клиенте.

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

  21. Опубликовано · Пожаловаться

    41 minutes ago, jcxz said:

    Это делается для того, чтобы опоздавшие пакеты не были восприняты как часть нового соединения

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

    В общем, вероятность последующего провала из-за отказа от TIME_WAIT крайне невелика. Ну и давайте посмотрим правде в глаза, и скажем, что MSL в 120 секунд в наше время - это с явно излишним запасом.

  22. Опубликовано · Пожаловаться

    34 minutes ago, Ruslan1 said:

    В-общем, как-то и мне не хочется одно другим подменять.

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

    37 minutes ago, Ruslan1 said:

    А еще он в WireShark красным показывается, что как бы намекает на необычность действия.

    Ну WireShark много чего красным красит. Это ж не повод для беспокойства в конкретно данном случае.

  23. Опубликовано · Пожаловаться

    1 hour ago, Ruslan1 said:

    И очень хотелось бы помочь решить эту проблему со стороны клиента (если возможно), может действительно у меня в lwIP чего-то покрутить можно, и серверу станет легче.

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

  25. Опубликовано · Пожаловаться

    On 7/3/2020 at 10:39 AM, nice_vladi said:

    Есть ли общепринятые правила?

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

×
×
  • Создать...