Леонид, Совершенно очевидно, что ваша схема выдает неадекватные сэмплы. Посмотрите на кадры с железа что я выкладывал. Максимальный размах в плюс - 2A0000 (0x00002A , +42 dec); в минус - 88FEFFFF (0xFFFFFE88 ,-177 dec) О каком шуме может идти речь? Такой сигнал нельзя услышать.
А теперь посмотрите на сэмплы что выдаются на звуковуху. +16755 и сразу -25347.Конечно будет шуметь. Выходные сэмплы должны быть в точности как и входные, только 16 бит и в прямом коде.
Старший байт b3 и это очевидно. Его не нужно использовать в формуле расчета вообще, так как переходя с 24бит на 16 мы полюбому жертвуем динамическим диапазоном, и лучше нам его ограничить сверху.


Извините за мои Ся, кодим как могЁм

rolin, если UDR сокет выдаёт СТРОКУ в виде (как Вы выкладывали) (я-то с UDR никогда не работал и повёлся, а сейчас проверил ) :
"7200B5FEFF7AFFFFAAFFFF62FFFFA9FEFF..."
то связка CharArray + Convertor(Str->Stream не годится т. к. она каждое HEX значение этой строки преобразует в байт и на выходе поток имеет не 1442 байта, а 2884 что и приводит к неработоспособности всей схемы.
Так что у Вас на выходе UDR строка HEX или поток? Проверить это просто: вычленить одну строку и отобразить в Edit code_31638.txt
По отбрасыванию старшего байта Вы не правы, регулировкой максимальной величины сигнала должна заниматься АРУ и обеспечивать на входе АЦП Вашего железа максимальный сигнал, но без насыщения (т. е. в пределах АЦП)

Леонид,железо выдает в поток кадр из байтов данных, каждому значению любого из них соответствует символ CHAR, и таким образом можно говорить что в поток выдается строка, я просто преобразовал каждый Char символ в HEX только для наглядности. Железо не выдает HEX, оно выдает данные, которые можно записать как CHAR, HEX, INT и любым другим способом.
Я прекрасно понимаю, что HEX интерпретируется как 2 символа CHAR.
Вот кусок моей программы, которая берет каждый кадр от HIQSDR и преобразует его в кадры SDR_IP. Как видите, работа со строками и символами, никакого HEX и все работает.
code_31639.txt


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

Это не так и обьяснить нюансы весьма сложно. Подумайте сами, 24бит глубина выходного сигнала - это офигенный динамический диапазон, никакая АРУ не нужна, в реальности этот диапазон используется на 18-20 бит.При том, что параметры входного АЦП 14бит, - 72дб шум, на выходе имеем -127дБ шум что соответствует 20бит разрешающей способнсти, благодаря математике.

rolin, пробуем обработать данные как строку: rolinicstring.rar
Выход звуковых семплов в формате Integer (четырёхбайтное знаковое целое число), пусть BASS сама с ними разбирается.
Если заработает, но не так, нужно попробовать поменять в IC в строках 68--70 и 76--80 b1 на b3, а b3 на b1
Ну а насчёт динамического диапазона особо не обольщайтесь, из 14 бит АЦП реальных максимум 12--12.5, при дискретизации 120 МГц и выходе 48 кГц математика даст ещё 5.5 бит, так что на выходе у Вашего железа максимум 18 значащих бит или 108 дб на CW, а на LSB (USB) ещё на 3-4 бита меньше или ~90 дб Впрочем не на этом форуме такие вещи обсуждать

Прошу извинить. Уехал в отпуск на две недели. Спасибо большое за помощь. После отпуска продолжу с новыми силами.

rolin, да ничего страшного Счастливо отдохнуть!

Приветствую всех!! Вернулся из отпуска.
Запустил последнюю схему от Леонида, и .... оно работает! Как я и предрекал, сигнал весьма мал, но я всё же слышал телеграф в наушниках. SDR - программы с сигналом работают, но не так как надо.
Во первых, при частоте сэмплов на входе 48к буфер не заполняется, сигнал рвется. При 96к работает устойчиво, но некоторые сигналы имеют зеркальное отражение. При 192к что интересно, то же работает, при этом отображается панорама более широкая чем при 96к,зеркальные сигналы отсутствуют.
Во вторых, программа SDR-Console выдает звук с плавающим тоном у сигналов.

В общем - есть ошибка.
------------ Дoбавленo в 20.43:
PS Амплитуда сигнала +-650 при подключенной антенне, +-50 без антенны, постоянное смещение -200.

Эти данные из графика в программе? или ещё как измерены?
Посмотрите на схему Вашего железа, как подаётся средняя точка на АЦП, есть-ли возможность подкорректировать и убрать это "постоянное смещение", по времени оно плавает или всегда -200?
Ввёл АРУ ступенями по 3 дб (1.4142), хотя наверное лучше ручная регулировка? rolinicstring2.rar

Данные из графика в программе.
АРУ работает, но зачем оно надо? Все функции усиления , детектирования и АРУ в том числе берет на себя программа обработки.
Буфер не успевает заполнятся при входном 48к. Здесь надо разобраться, это серьёзная ошибка.
Смещение постоянное, наблюдалось всегда с этим железом. Антенна подключается к АЦП напрямую, через симметрирующий трансформатор, а значит никакой постоянной разности потенциалов между выводами IN+ и IN- быть не может.Видимо, это особенность конкретного чипа. Родная программа QUISK имеет фильтр отсекающий постоянку а вот другие проги показывают её на панораме.

rolin, АРУ ввёл чтобы определить, правильно-ли BASS определяет четырёхбайтные числа на входе, если работает, значит всё правильно.
Буфер не заполняется при одном условии: частота семплирования у железа меньше частоты семплирования у звуковой карты; если наоборот, то буфер будет постепенно заполняться и когда-то переполнится. Попробуйте выставить у BASS_Init и BASS_StreamCreate не стандартную частоту, скажем 47500 Гц, (даже не знаю, будет-ли работать BASS с не стандартом ), может полУчится что-нибудь путное
На всех частотах семплирования или только на 48000? На много-ли меняется тон, плавно или скачками?
Смещение легко можно скомпенсировать.
------------ Дoбавленo в 11.22:
Сейчас проверил 47000Гц -- работает! так что проблема решаема!
------------ Дoбавленo в 18.53:
rolin, наверное нашёл ошибку, блин, и чем я думал
На выходе имеем два буфера: Левый и Правый в виде двухмерного массива, при чтении BASS_StreamCreate обращается 96000 раз/сек (при 48000 Гц) отдельно на каждый канал, и надо менять адрес один раз на два обращения, а я менял на каждое и поэтому пропускал половину данных
Надо заменить в IC процедуру doNextSound (на картинке)
на вот эту:

Ну что ж, совсем другое дело. Теперь буфер не опустошается. Работает устойчиво на всех скоростях до 192к. Надо будет 384к попробовать, SDR_Console поддерживает.
Насчет плавания тона это я лоханулся, было включено SyncAM вот оно и подстраивалось в поиске несущей.
Так что осталась только одна проблема. Сигналы зеркалят. Я записал видео, чтобы не обьяснять на пальцах.
Похоже, что сигналы с левого канала как-то попадают в правый или наоборот. Обратите внимание, что отражения более слабые по уровню.
https://docs.google.com/file/d/0BzuiSb2tJSbzVFZfUl9KWHZHSkE/edit?usp=sharing

rolin, да, подавление зеркального канала не на высоте
И вряд-ли причина в нашей цифре, перегрузки АЦП не видно, скорее всего в управляющем АЦП генераторе, может фазовый шум, или умножитель частоты добавляет Попробуйте на нижних диапазонах, на 80, или 160, правда там чистого участка не найдёшь.
Лучше всего не в эфире, а сорудить кварцевый генераторик на одном транзисторе и подать сигнал с него на антенный вход (через делитель конечно).
Потом можно будет вместо графиков подцепить StrList-ы, записать секунду-другую и проверить цифру в спокойной обстановке

Э нееет.... У меня SI590 стоит как генератор, куда уже круче. Железо давно оттестировано и работает.
Кроме того есть ещё симптом, когда всё выставлено на 192к, то отображаемый диапазон не соответствует 192к.
А вот когда установки на 48к а входные сэмплы 192к то тогда панорама соответствует 192к.
Глубина буфера достаточна,?, она как-то привязана к 1секунде проигрывания?
------------ Дoбавленo в 22.58:
PS увеличил буфер до 384000, ничего не изменилось. На 192к,отобрашаемая ширина очень узкая.

BASS просто не может передавать данные на 192000 Гц
Наверное это означает, что панорама считается отдельно, а звук отдельно.
От длины буфера ничего не зависит, он нужен чтобы сохранить непрерывность звука, когда Windows отвлекается на свои задачи (на 20--30 мсек запросто). Я сделал такой большой буфер ~1 сек исключительно для возможности контроля на время наладки, потом его можно уменьшить раз в 10.

В итоге запустил я все это дело на 192к, там проблема была в настройках виртуального аудиокабеля.
Про BASS не знал что он до 100к, но вроде у меня работает на 192к, по крайней мере не ругается. Я ещё проверю ширину точнее.

Так что осталось у нас - зеркальный канал. Я тщательно проверил - в QUISK никаких зеркалок нет. С железом все в порядке.
Так же заметил, что основной канал принимается заметно слабее чем в QUISK, что очевидно, ведь часть сэмплов уходит в зеркальный канал.
Надо искать ошибку.