Rst7

В общем-то сама по себе идея этого приемника очень занятная, но работать нормально он не будет никогда. Основная проблема - плохой режим работы гетеродина (он же и смеситель). Для хорошего коэффициента преобразования на второй гармонике транзистор должен работать в классе С с углом отсечки порядка 60 градусов. В генераторе такой режим достижим, если базовым/затворным/сеточным током перезаряжается входная емкость и транзистор подзапирается. Конкретно в этом приемнике напряжение частоты гетеродина слишком мало, и транзистор все время находится в классе А. И коэффициент преобразования из-за этого слишком мал. Из-за аналогичной проблемы практически не работает схема с доп. диодом, призванная улучшить ситуацию с прямым детектированием. В классическом смесителе на встречно-параллельных диодах напряжение гетеродина выбирается таким, чтобы угол отсечки тока диодов был порядка 60 градусов. В рассматриваемом приемнике вроде бы и да, диод работает на другой полуволне напряжения гетеродина, но только он все время открыт и практически не производит "ключевание" другой полуволны. Я даже думаю, что ситуация вообще ухудшается относительно начальной схемы, ибо характеристика диода почти наверняка сильно отличается от входной характеристики транзистора. В общем, я, конечно, понимаю, что один транзистор - это очень прикольно, но лучше бы вы попробовали намакетить вот такой приемник: Тоже в общем совершенно несложный, но заработает почти наверняка с хорошим результатом. Эта схема на самом деле весьма толковая, даже очень правильно сделан момент с устранением постоянного тока через диоды смесителя. В принципе сам УПТ стоит по нынешним временам заменить на малошумящий ОУ с заметно лучшим результатом.

Причем тут UDP? И, кстати, причем тут "самопальный стек"? Это, простите, в чем я "по ушам езжу"? Так все очень просто. Например: АЦП->Контроллер1->Ethernet->Wifi router1->радиоканал->Wifi router2->Ethernet->Контроллер2->ЦАП. Пусть будет 2канала*16бит*48кГц. Надо, чтобы в этой цепочке не было потерь пакетов. Пауза в приходе пакетов, которая вызывает щелчок на выходе - это тоже потеря. Вот основная проблема именно в паузах, причем неконтролируемых. Для борьбы с ними в контроллере2 делается буфер. Минимальный более-менее работоспособный размер его - где-то эквивалентен 5-6мс по времени. А лучше бы все 10, потому что с 5-6 иногда все таки опустошается буфер. Ну а общая latency в таком случае - это задержка от входа АЦП до выхода ЦАП. Со всеми внутренними буферами, понятное дело. Предупреждая всякое "не такой вайфай, не такой эзернет" и прочее: понятное дело, что если кусок Wifi router->радиоканал->Wifi router выбросить, то все становится хорошо. Даже если там включен какой-нибудь свич, ничего страшного не происходит, буферизация требуется, ну на сотню микросекунд, не более. А роутеры в этой цепи проверялись самые разные, в самых разных конфигурациях, в том числе и вместо куска Wifi router2->Ethernet->Контроллер2->ЦАП использовался iPhone (ну только там Ethernet'а нет внутри, но это неважно). Возможно, если бы у меня был голый WiFi MAC/PHY с полной документацией, я бы сделал вариант стека, который не переключался бы в режимы с малой скоростью и не занимался бы какими-то побочными делами. Но таковых нет, дизассемблировать существующие драйвера нет ни времени, ни желания.

А вот пусть этот "самый первый модератор" попробует с WiFi пободаться именно с точки зрения low latency и получить хоть какую-то минимальную цифру. У меня с использованием моднейшего Linksys'а с технологией MU-MIMO в лучшем случае получилась задержка почти 6мс, но это только буферизация входа, а еще ввод-вывод, считайте, что все 7 набегает. Именно так.

Прошу прощения, похоже что конекретно этот девайс - это аналоговый радиоканал. Но все эти FM-передатчики/приемники - то еще барахло. А я про те, которые в таком же формате, но в цифре носят. Вот например - https://aliexpress.ru/item/4000507198259.html На самом деле она 2.4ГГц, а не 760, как написано. Но зато не обманули про латенси.

А еще бы честно указывали, что там 12мс задержки, а не "менее 4мс", и все бы хорошо было.

Я вам вот что скажу. Даже aptX Low Latency не спасет. Там 32мс задержка, это очень много для игры на музыкальном инструменте. Так что Ваши хотелки нереализуемы. Только в виде "свой стационарный передатчик + свой носимый приемник, в который включаются проводные наушники".

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

В варианте с контроллером, у которого свой MAC внутри - легко получается wire speed. Т.е. чуть меньше чем, например, 100Мбит/с. Со всякими визнетами сильно повезет, если получится перешагнуть 10М. Это Вам надо будет пробовать бодаться с его параллельной шиной, еще неизвестно, сколько там глюков, народ-то в основном его по последовательным портам гоняет (и то матерится). Вам сильно нужны эти эксперименты?

Но зачем? Вы же не сможете ни шага влево, ни шага вправо ступить с ним. Да и обещанные 80М - скорее всего какой-то сферический конь в вакууме.

Та в общем вроде нет особых проблем с приемом. Вот, например, 8 лет назад - там что-то под 500к пакетов в секунду с средней полосой за 4Гбит/с. http://www.serverframework.com/asynchronousevents/2012/08/winsock-registered-io-io-completion-port-performance.html Проблем с записью тоже нет, если обеспечите дисковый массив с подходящей пропускной способностью. Если вдруг чего, то RIO и memory mapped files очень даже хорошо совмещаются, практически имеете полностью zerocopy.

Moderator: Господа, тему вынужден закрыть. Потому что офтопик.

Ну так уже не 2 D-триггера ;) Повторюсь, основная проблема заключается в том, что большинство камней сильно ограничены по максимальной частоте SCK в режиме Slave. Там же вроде 16МГц, что, все так печально? Вроде ж 6 тактов надо на саму пересылку, ну плюс еще тест и цикл. А всего есть 12.8 такта, вроде должно хватить.

Сэмулировать 10M Ethernet. Достаточно имитировать только Normal Link Pulse и все. Линк поднимется, дальше просто посылать UDP-пакеты. Главное, чтобы SPI без дырок между байтами мог данные посылать со скоростью 10М. Либо работать в слейв-режиме с такой скоростью. Из I2S, кстати, хорошо получится. Не хватит двух D-триггеров для декодирования манчестера. Да еще и не в каждом камне SPI умеет в слейв на 10М.

Да. Именно так. Изначально был TCP, потом перешел на UDP, потому что понадобился мультикаст. В общем это непринципиально. Нет. Буфер там у меня размером 32пакета*8семплов_в_пакете*8каналов_в_семпле*32бита=4килобайта. Таких буферов два, потому что в обе стороны. Характерные возможные задержки в Windows, если у Вас более-менее вменяемый компьютер по производительности и сделаны нужные оптимизации, - не более 0.5мс. Оценить эти задержки в конкретно Вашей системе можно при помощи вот этой софтины - https://www.resplendence.com/latencymon Вот мои буфера в самом сложном случае (при частоте дискретизации 192кГц) обеспечивают буферизацию на время порядка 1.3мс, это с приличным запасом.

Это ж только модулятор. У него цифровые выходы.