Цифр осциллограф есть.. но тема снифа на атмеге выглядит интереснее, в принципе это и сам реализовать могу, но поищу готовый программный проект..

Ну, в общем-то да, если есть время на написание и отладку, то на атмеге можно легко набросать простейшую прогу, стартующую по изменению уровня на одной из линий порта и и пишущую все изменения порта в свою оперативную память до её заполнения или до прерывания нажатием какой-нибудь кнопки, затем выгружает по RS232 в комп. Или писать в кольцевой буфер и одновременно тут же отправлять из него по RS232 со скоростью большей, чем в него поступает.
У атмеги плохо то, что своей оперативной памяти мало, по сравнению с досовской комповой программой(64кб), но есть возможность навешивать внешнюю статическую память до 64 кбайт.
Но опять таки, для того, чтобы один раз всем этим воспользоваться для одноразового сниффа панасоника, затевать эту разработку , изготовление и отладку не всегда есть желание, даже с прицелом на будущее.

Я в 90 годах помню, когда снифферил синтезатор 900 мгц панасоника, даже на такое извращение один раз пошел, что поставил кварц часовой (32.768 кгц) вместо штатного (был около 4 мгц), а на линии повесил светодиоды. Только оооочень долго пришлось ждать от момента включения до начала моргания светодиодов на шине управления синтезатором.И не на любом аппарате это прокатит.

killer258
Посчитал интересным вернуться к вопросу.
А вот протокол CAT трансивера FT-817 (там просто блок из 5 байтов, первые4 байта- данные и пятый- команда, интервал между байтами не должен превышать 200 миллисекунд) его интересно, HDSDR тоже понимает?
Что то сомневаюсь.
Айкомовские пртоколы, какие попадались на глаза, тоже страдают этими 200 мс.
Я по-Кенвудовски гонял настройку с платы STM32F4 Discovery, к которой прицепил китайский оптический энкодер.
Потом, как то не представляю такой картины - кручу я ручки FT-817, а у меня на мониторе шкала настройки ползет...
А управлять из HDSDR внешними железками - там прокладка ОмниРиг. Не юзал, но позволяет, думаю.
Идеальных протоколов нет, в каждом какая то кислятина, но я по любому обходил бы те, где для синхронизации используют временные интервалы.

но я по любому обходил бы те, где для синхронизации используют временные интервалы.

ну, я вот для этого и привел эти два варианта, чтоб обсудить, что лучше. В протоколах таких как FT-817, мне нравится то, что передаются непосредственно сами байты, а не их текстовая интерпретация, но для правильного определения начала и конца посылки требуются либо уникальные последовательности перед данными в качестве маркера начала, либо пришлось бы руководствоваться критерием считать принятой посылкой пять байтов, не имевших между собой большой паузы. Это значит, надо таймеры каждый раз запускать после приема каждого байта, если таймаут вышел раньше получения пяти байтов, всё сбрасывать и опять начинать сначала и тд.

А в случае кенвудовского протокола хоть и литералы передаются, зато программное управление потоком легче, так как просто по каждому прерыванию от уарта запишем очередной принятый байт в кольцевой буфер , заодно подсчитывая общую длину, и так до тех пор, пока не встретим символ ";", после чего копируем строку, сбрасываем счётчик длины принимаемой строки обратно на ноль, затем парсим принятую последовательность известной длины. Если там первыми двумя символами окажутся FA, то остальные одиннадцать литералов переведём в понятное процессору значение частоты и "скормим" это значение функции Set_Freq_R820T. Если что-то не так, то проигнорируем и будем ждать дальше. Ну, вот как-то так.

killer258
Я же говорю, в каждом протоколе своя кислятина.
В случае с временной синхронизацией, надо жестко риэлтайм контролировать, чтоб не подвисла многозадачная среда или Main() какая нибудь.
И еще - функции по Кенвуду можно писать свои и отлаживать в Гипертерминале или подобной проге.

killer258
И вообще желательно присмотреться к Кортексам хотя бы из-за того, чтоб не рыдать над Атмегой, выполняющей функции преобразования. Вроде:

ASCII_to_HEX(convi_char) - switch на 16 позиций;

/*############## ASCII-DECIMAL TO BINARY CONVERSIONS ################*/
uint32_t input_ASCII_to_dword (char *Ptr_Buff)//Stranno rabotaet s null zapolneniem
{
uint32_t tmp1 = 0x00000000 ;
uint32_t tmp_incount = 10 ;
uint32_t D10_multiplier = 1000000000 ;
uint32_t cnt_inmass = 0 ;

*Ptr_Buff = 0x30 ;//Ограничиваем 999999999 Гц
do
{
convi_char = *(Ptr_Buff + cnt_inmass) ;
tmp1 += D10_multiplier*ASCII_to_HEX(convi_char) ;
D10_multiplier /= 10 ;
++cnt_inmass ;
--tmp_incount ;
}
while(1 <= tmp_incount);
return tmp1 ;
}
Быдлокод приведен для оценки загрузки процессора!

Вобщем нахимичил менее быдлокодный, чуть более короткий вариант ASCII-to-Integer, и главное можно задавать длину преобразуемого массива. Пока тестируется.

Если я правильно понял, то в кенвудовском протоколе максимальная длина строки видимо, составляет не более 20 символов ?
Можно зарезервировать массив такой длины , а длину строки в нём или подсчитывать во время приёма байтов по RS232 или просто после получения символа ";" производить анализ содержимого массива на основании того, что началом строки должны являться две буквы.

killer258
Я сделал два массива - in_CAT_massive[4200] и out_CAT_massive[4200] потому что собираюсь играться с SD картой, записью секторов и кластеров.
Как уже сказал, написана и тестируется, пока успешно, функция ASCII_to_dword, которая позволяет взять для преобразования в интегер из любого массива, из любого места массива кусок произвольной длины, главное чтоб интегер не получился больше примерно 4300000000, т.е. двойки в степени 32.

Да приведу, че ее солить.
/*############## ASCII-DECIMAL TO BINARY CONVERSIONS ################*/

uint32_t input_ASCII_to_dword (char *Ptr_Buff, uint32_t Len)
{
uint32_t tmp1 = 0x00000000 ;
uint32_t i = Len - 1 ;
uint32_t D10_multiplier ;

do{
if(i == Len - 1){D10_multiplier = 1 ;}
else if(i == Len - 2){D10_multiplier = 10 ;}
else {D10_multiplier *= 10 ;}

convi_char = *(Ptr_Buff + i) ;
tmp1 += D10_multiplier*ASCII_to_HEX(convi_char) ;
i-- ;
}
while(i > 0) ;
return tmp1 ;
}

главное чтоб интегер не получился больше примерно 4300000000, т.е. двойки в степени 32.

то есть 4.3 гГц, если в герцах. Для наших целей этого достаточно, всё равно R820T выше 1.7 ггц не сможет работать.

Кстати, я удивлялся, почему ихний драйвер на участке от 24 до 24.1 мгц выдаёт очень странные значения регистра 0х10, не соответствующие даташиту и моему калькулятору, а на всех остальных частотах все совпадает. Так вот, ничего странного, свисток на этом участке от 24 до 24.1 мгц действительно ничего не принимает.(и не мог бы принимать с такими странными значениями)

(я время от времени подумываю всё о том же, о размещении этого чипа на крыше, впритык к антенне)
А как вам такая реализация ?

Интересно. Надо будет и это тоже попробовать. Но это будет уже совсем другая история (С)

Сейчас вывел проводочек от 5 ноги R820T наружу для экспериментов. Тут меня ждало разочарование. Сколько-нибудь заметного сигнала гетеродина на этой ножке не почувствовал не только индикатор поля, но даже подключенный через кабель Roger RFM12. не загорелось ни одного сегмента на шкале уровня. По показаниям частотомера видно, что он пытается что-то схватить, но уровень крайне мал.Наверное, такой уровень годится только для проверки приёмников. А я-то хотел сделать измеритель ачх и антенный анализатор, где свип-генератор управлялся бы всё той же атмегой по I2C. Пригляделся получше к блок-схеме в даташите, оказалось, 5 ножка идет вовсе не от гетеродинного входа смесителя, а от выхода детектора уровня сигнала гетеродина, и там видимо, постоянное напряжение, пропорциональное размаху, так что если там и есть какое-то ВЧ, то это не сигнал, а просто паразитное пролезание сквозь детектор уровня. Жаль. Если только может, попробовать отключить программно выходной фильтр ПЧ со смесителем и попробовать поймать сигнал гетеродина на выходе пч... Хотя, наверное и там ничего хорошего не выйдет.
А такая задумка была заманчивая- сделать из чипа широкополоснейший генератор с ФАПЧ, от примерно 27 мгц и до примерно 1770 мгц, с уровнем, достаточным для создания антенного анализатора на его основе.

killer258

Зачем такой изврат, все равно будет не синус после делителей ФАПЧ.
Для этих целей есть готовые китайские пласты с ADF4351.
Для более низких частот есть ад9850 или си5351.

По мотивам Георгия Яцука RX9CIM (ставится в Main())

void CAT_protocol (void)
{
while ( indxBuf_In_Write != indxBuf_In_Read )//Крутим кольцевой буфер
{
vcp_in_var = Buf_In[indxBuf_In_Read++];
if(vcp_in_var == ';')//Ловим окончание САТ-команды
{
in_CAT_massive[p_CAT_inmass] = vcp_in_var ;
p_CAT_inmass = 0 ;//Указатель в ноль, САТ-буфер готов к приему следующей команды
CAT_status ();//Начинаем исполнять
CAT_decode_comand ();
CAT_comand_exec ();
}
else
{
in_CAT_massive[p_CAT_inmass] = vcp_in_var ;
++p_CAT_inmass;
}
}
}

Здесь мы видим кольцевой буфер объемом 256 байт Buf_In[256], указатели записи и чтения indxBuf_In_Write и indxBuf_In_Read.
Писать в буфер может все что угодно - RS-232/485, USB Virtual Com Port, клавиатура и тд.
Объем буфера 256 байт позволяет не париться коррекцией 8-битных указателей. И тут то мы подходим к ограничениям 8-битных процессоров. Отслоить 256 байт на один из служебных буферов - это поступок)))

В простейших системах, наверное, можно обойтись без буфера.

Функция CAT_status (); - определяет флаг, что мы хотим от ведомого устройства - прописать в него или считать.
Честно говоря, я думаю Георгий ее создал по запаре, она анализирует наличие ';' в третьей ячейке in_CAT_massive.
В любой целевой функции стоит if( ){} на анализ флага, отчего бы ему не анализировать третью ячейку...

Функция CAT_decode_comand (); - тупо собирает код команды из первых двух символов, например, 'F''A'...

Функция CAT_comand_exec (); - переключатель, согласно коду команды, вызывающий целевые функции.

Ты у меня, одна заветная...
Целевая функция FAxxxxxxxxxxx;

void CAT_FA_comand (void)
{
int32_t i ;
int32_t p = 0 ;
if(Status==STATUS_WRITE)
{
options.frequency = input_ASCII_to_dword((char*)&in_CAT_massive [2], 11);//Вот и пригодилась см. выше)

}
else
{
for ( i=0; i<38; i++)out_CAT_massive[i]='0';//Чистим выходной буфер, от греха подальше...
out_CAT_massive[0]='F';
out_CAT_massive[1]='A';
dword_to_ASCII_arroy (options.frequency, (char*)&out_CAT_massive[3]) ;//Обратное преобразование
/*sprintf((char*)&out_CAT_massive[4], "%i", options.frequency);*///Их применял Г.Яцук, но свое вкуснее...
out_CAT_massive[13]=';';
VCP_DataTx (&out_CAT_massive[0], 14);//Швыряем в комп по виртуал ком порту
/*usb_cdc_printf((char *)&out_CAT_massive,14);*///Их применял Г.Яцук, но свое вкуснее...
}
}

killer258
то есть 4.3 гГц, если в герцах. Для наших целей этого достаточно, всё равно R820T выше 1.7 ггц не сможет работать.
У Кенвуда резервировано под частоту 11 знаков, то ли сверхдальний прицел, то ли мания величия...

Отслоить 256 байт на один из служебных буферов - это поступок)))

Я с содроганием вспоминаю, что для PIC16F84 вся "оперативка" вообще была 32 байта . И 64 байта еепром для данных. Любое упоминание о массивах и строках звучало для него как жестокая насмешка. Никаких Си, только аsm..

я наверное, пойду другим путём. Хоть и считается плохим тоном слишком много делать в программе обработки прерывания, но в данном конкретном случае после получения символа точки с запятой это вполне допустимо, поэтому с её приходом принятые до неё символы в кольцевом буфере "не отходя от кассы" тут же будут проанализированы на наличие на заранее известном нам расстоянии назад от точки с запятой заранее нам известных символов FA (установить частоту), либо IN (привести чип в рабочее состояние), либо WR (записать в регистр XX чипа байт YY), либо RR (чтение регистра ХХ), поскольку команд предвидится всего навсего эти четыре. Всё другое будет игнорироваться)

Или ещё как возможный вариант приходящие из уарта байты с каждым очередным принятым байтом последовательно продвигаются по искусственно созданному программным путём 14-тибайтовому сдвиговому регистру, у которого некоторые фиксированные позиции на каждом таком шаге сдвига проверяются, пока в них не окажется ожидаемое содержимое. Например, все время проверяется на совпадение с образцом самая последняя(перед сдвигом в никуда) позиция регистра , при появлении в которой символа ";" , продвижение по регистру сразу будет приостановлено и начнётся разбор содержимого, зашедшего в регистр. (своего рода аналог аппаратной реализации )

Далее в зависимости от определения принадлежности к одной из этих 4 команд будет соответствующим этому образом интерпретировано то содержимое, что, заключено между ключевыми символами и точкой с запятой, далее основная программа сделает всё, что надо в таком случае и продолжит крутиться в цикле ожидания.

Я честно говоря с программными делами дошел до одури и сломал режим, и не могу предметно комментировать.
Разве что уверен, что все получится, основатель темы доказал упорство)))
Без кольцевого буфера возможно обойтись, и заполнять только САТ - буферы.
Кольцевой буфер удобная вещь для передачи данных, формируемых в прерывании от таймера, у меня так опрос клавиатуры работает.
И энкодер работает в прерывании таймера. Очень удобно, представим, что мы жмем кнопку, сели на нее скажем, и завесили Майн() )))).

ну вот, наконец-то я допилил и коммуникационную часть (приёма и выполнения терминальных команд..) Функции работы с чипом столько не отняли времени, сколько это. Причина- обнаружился баг в библиотечных функциях микропаскаля, из-за которого командная строка с RS232 интерпретировалась неверно. Там, где я это никак не предполагал. Конечно, посидел, разобрался с этим, нашёл , где не так, поправил с учётом этого,но времени потерял много из-за этой "кривости" библиотек, пока заработало всё как надо. Вообще-то, надо сказать, что для платной версии среды разработки такая кривость и тупость (да ещё и закрытость) её библиотек- не делает ей респекта. (поэтому часто отказываюсь от них и увы, пишу свои процедуры)

Сейчас вроде бы всё работает как хотелось. (тщательно и долго ещё не проверял, но пару частот ввёл, нужные регистры чипа вычислились правильно).

Терминальные команды на данный момент такие:
====================================

1) PSX; где X='1' --> ВКЛЮЧИТЬ ЧИП(с инициализацией), X='0' -> ВЫКЛЮЧИТЬ ЧИП

2) FA0XXXXXXXXXX; --> ЗАДАТЬ ЧАСТОТУ В ГЦ(11 ЦИФР) например FA00063750000; --> 63750 KHZ

// последние три циферки(герцы) обработчиком игнорируются , так как в них нет смысла, всё равно погрешность установки частоты на этом синтезатое может доходить до 50-100гц, (а в районе гигагерца наверное и до одного кило герца, как я полагаю) и поэтому функция установки частоты всё равно принимает её в килогерцах, но , чтобы не отступать от кенвудовского формата команды, герцы писать придётся. Можно забивать последние три поля в этой команде нулями (или всё равно чем, они будут проигнорированы точно так же, как и первая, самая старшая цифра, обозначающая десятки гГц).

3) WRXXYY; --> записать в регистр чипа XX байт YY (шестнадцатиричн)
// ну, это для "тонкой" работы с чипом, и для экспериментов над ним.

4) RRXX; --> прочитать регистр ХХ чипа R820T (шестнадцатиричн)
//это для проверки статуса PLL (если конечно,знать, что означает возвращаемое чипом значение "VCO indicator" и " RF indicator" :-) ) В принципе, этой командой можно прочесть не только первые пять, но и любой другой регистр чипа, если например, забыл, что именно в него было записано ранее или для того, чтобы перезаписать его предыдущей командой ,но сохранив при этом некоторые его биты теми же самыми, что и были в нём до этого

5) PPxxx; --> задать PPM 0...999

//тут вылезла ещё одна маленькая проблема. PPM ведь наверное может быть и отрицательным.
В моей программе это предусмотрено, но про ввод отрицательных значений в кенвудовском протоколе вроде бы ничего не говорится.
Поэтому, до решения этого вопроса, пока с терминала получится ввести только положительные PPM.
Надо будет тут подумать на свежую голову.

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

и осталось дописать процедуры, связанные с приходом команд WRxx; и RRxx; и процедуру деактивации (выключения) чипа, но это уже мелочь.
и еще не проверял работу , когда по RS232 пойдут байты вплотную друг к другу и на скорости не 9600, а скажем 115200, успеет ли моя процедура все обработать.

PS: в дальнейшем можно будет прицепить к атмеге ЖКИ индикатор и клавиатуру для рчного ввода частот и команд (например, сканирования от и до, в разных режимах, если выход RSSI приёмника завести на вход ацп атмеги. Желания правда, особого нет, поскольку сканирующие приемники и так имеются, но, можно сделать кучу дешевых сканеров)

killer258
Вообще-то, надо сказать, что для платной версии среды разработки такая кривость и тупость (да ещё и закрытость) её библиотек- не делает ей респекта.
Это от "братской" фирмы Mikroelektronika из Белграда? Чрезвычайно дорого берут за свои поделки, раза в два дороже, чем STM, причем зачастую качество плат сильно отличается от того, что на картинках.
Видно, очень денюжков хочется.
Учитывая, как криво спроектированы некоторые платы - мозг там не включали, видимо для большей сохранности, с программным обеспечением возможно тоже самое.

Это от "братской" фирмы Mikroelektronika из Белграда?

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

Для таких-то целей , как этот проект,в принципе, микропаскаль годится. А вот библиотеку LCD в нем вообще все ругают, не я один. Не работает она корректно, вплоть до полной пурги на индикаторе. Её-то я давно уже написал для себя сам, заодно дополнив процедурами вывода на ЖКИ одно, двух и трёх и четырёхбайтовых чисел в в HEX и в десятичном виде, только не получается запихать всё это туда к ихним библиотекам, чтобы убрать с глаз долой,и просто вызывать при необходимости, и поэтому эти мои процедуры с дисплеем торчат в каждом проекте в самом начале, там, где подпрограммы располагаются.
Я не пробовал ещё ихние библиотеки, связанные с Ethernet, что если и там глюки.. Вот их то уж точно самому писать мне бы не хотелось. Библиотека работы с MicroSD ихняя работает, но тоже ложка дёгтя в них есть- поддержка карт памяти там не более 2гб, а таких сейчас ещё поискать надо. Тоже надо писать свою, но всё никак не могу себя заставить за это взяться, за все эти низкоуровневые алгоритмы с командами управления MicroSD по SPI.
Что понравилось ещё в Микропаскале- это то, что есть команды работы с отдельными битами, если нужно изменить оди бит в любой переменной , не трогая остальные биты, мне это как-то удобнее, (хотя и знаю, что когда он откомпилирует в ассемблер, там конечно все равно будет чтение-модификация-запись, но по крайней мере это убрано с глаз ) чем писать для этого каждый раз логическую операцию & или | с той или иной маской , как это делается в Си.

Проснифферил выключение свистка при закрытии HDSDR.

[0x05] <--0xA3
[0x06] <--0xB1
[0x07] <--0x3A
[0x08] <--0x40
[0x09] <--0xC0
[0x0A] <--0x36
[0x0C] <--0x35
[0x0F] <--0x68
[0x11] <--0x03
[0x17] <--0xF4
[0x19] <--0x0C

В принципе, ничего интересного. В основном регистры, содержащие PWxx биты. Разбираться в них пока не буду, просто скопировал эту последовательность вдуваний в процедуру выполнения терминальной команды PS0;
не знаю, нужна ли она, но, пусть будет. Ибо раскочегаренный чип потребляет аж 300 миллиампер всё-таки.

Теперь дописать осталось ещё команды записи/чтения одиночных регистров чипа, и дистанционное управление чипом будет совсем готово

Ну вот, вроде всё написал. Осталось теперь на свежую голову протестировать работу во всех режимах.
Как всегда, вспомогательная часть программы получилась в разы больше той её небольшой части, которая собственно непосредственно управляет чипом R820T

По-хорошему, надо бы ещё предусмотреть обратные ответы в терминал в случае, если команда с терминала введена правильная, но поле операндов заполнено с ошибками, но на это уже просто нет сил.
Придётся видимо ,просто всё внимательно вводить или потом когда-нибудь допишу и это. А то и так уже программа вырастает настолько, что сам перестану её понимать через несколько месяцев

killer258
АРУ усилителя ПЧ в R820T делать планируете?

АРУ усилителя ПЧ в R820T делать планируете?

Я извиняюсь за задержку с ответом здесь в этой теме, мой бан только сегодня закончился (почему-то он распространяется как ни странно, и сюда тоже, хотя этот раздел вроде никакого отношения к клубным форумам не имеет). Сам я АРУ в этом свистке обычно никогда не пользуюсь, так как мне больше нравится ручная установка усиления, чтоб видеть истинную картину уровней, у меня и в HDSDR галочка на чек-боксе "tuner AGC" всегда снята, и в этом проекте наверное, я АРУ тоже не планирую, но , для того, чтобы другие пользователи могли поиграться с АРУ, возможность такая конечно есть. Даташит даёт нам два варианта . В регистрах 0х05, 0х07 есть биты, которые определяют режимы, чем задается усиление LNA и смесителя соответственно, режимы - "авто" или "ручной"(в последнем случае оно задается содержимым этих регистров), а также в регистре 0х0С есть бит, определяющий, чем задается усиление ПЧ, кодом этого регистра или напряжением на ножке Vagc.

бит4 рег 0х0С
называется VGA Gain manual/pin selector

1: IF vga gain controlled by vagc pin
0: IF vga gain controlled by vga_code [5:0]
(биты 5:0)

В наборе моих терминальных команд есть команда WRххуу; позволяющая в любой регистр хх чипа записать байт УУ, то есть всё ,что угодно, в том числе и в эти три регистра, глядя в даташит. Но можно я думаю,предусмотреть и специализированную команду в протоколе, которая будет аналогом чек-бокса "Tuner AGC оn/off".

Я проснифферил обмен, при установке в HDSDR этой галочки в чек боксе, в регистры 0х05,0х07 и 0х0С прописываются значения 0х08,0х78, и 0х6B соответственно, а при снятии галочки в 0х05 и 0х07 возвращаются старые значения, в 0х0с пишется 0х68.
Можно это оформить отдельной процедурой, запускаемой по терминальной команде, например что-то типа AGХ; где х=0 ручная регулировка, х=1 это "Tuner AGC", управление напряжением, подаваемым на ножку чипа.

Не смотря на то, что усилением можно управлять и сейчас через команду записи регистра, я пожалуй, всё же добавлю более удобную для пользования ещё одну отдельную терминальную команду, в которой просто будет вводиться желаемое усиление от 0 до 49 дб. Если контроллер с помощью своего АЦП измерит уровень RSSI , он может сам поменять значения этих регистров с помощью этой команды, и получится что-то вроде "RTL AGC". В этом случае получаем возможность формировать "напряжение" АРУ по любому требуемому закону, например, так называемая "задержанная ару"

Теперь о результатах на текущий момент. В общем-то эта неделя ушла на написание и отладку терминальной части, синтаксического анализатора и модуля выполнения команд. И ещё немало крови мне попортила процедура чтения регистров чипа, которая вначале ну никак не хотела нормально работать, но в конце концов допилил и эту часть. Оказалось также, что в даташите действительно не опечатка, хотя я поначалу не очень-то верил. Если передача байтов в регистрры чипа по шине I2cу них ещё идёт в точном соответствии с классическим описанием I2c протокола старшим битом вперёд, то при чтении тех же самых регистров принимать биты из R820T уже надо в обратном порядке., сначала младший бит, потом постарше и тд . Не критично, конечно, но есть вот оно там такое. Второй момент оказался в том, что в данном чипе совершенно отсутствует (хотя я очень надеялся ) возможность прочитать отдельно взятый его регистр с произвольным адресом. Только через процедуру чтения подряд начиная всегда с нулевого регистра один за другим, пока не доберёшься до требуемого, нужно читать все предыдущие. Ну да ладно, всё это я учёл.
Короче, уже испробовал всё это в работе на "железе". (к одной из противофазных линий выхода ПЧ чипа в качестве ПЧ тракта был на скорую руку присоединён упоминавшийся уже ранее Icom PCR-1000, настроенный, как нетрудно догадаться, на 3.570 мгц)

Всё работает, как и было задумано. Даю с терминала команду PS0; в ответ на терминал приходит строка "R820 ON!" , в регистровую матрицу чипа загружается дефолтный набор, из динамика PCR-1000, о чудо, начинает идти звук той релейки на 63.750 мгц (она у меня здесь как ориентир для проверки, так как всегда доступна и идёт с приличным уровнем, и ее ни с чем не спутать.)

Даю команду PS0; звук пропадает, чип выключается, на терминал приходит " R820T OFF!!". А кроме того, я дописал недавно ещё одну процедуру, благодаря которой теперь перед выключением чипа вся его регистровая матрица в состоянии на этот момент сначала считывается и прописывается в энергонезависимую память атмеги. При последующем включении, (а также при получении команды PS2; ) сохранённый набор регистров загружается обратно в чип, и он становится опять в том же самом состоянии, в каком он находился перед выключением :-))))

Отправляю с клавы терминала команду PP034; устанавливается PPM=34, при выключении он также будет сохранён в еепроме атмеги и при последующем включении будет восстановлен из энергонезависимой памяти атмеги. (не вводить же каждый раз его...)

Далее ввожу FA00041800000; и , о чудо, слышна речь скорой помощи. Всё правильно вычисляет!
При выполнении команды FA обратно в терминал идёт отчёт о значениях регистров 0х10, 0х12, 0х14, 0х16, 015 и 0х1А. Это отладочная информация, её можно потом будет и убрать, но пока по ней хорошо видно, правильно ли работает математика, ибо есть с чем сравнить при необходимости.

Дописал я сегодня и ещё одну команду DP; выполнение этой команды приводит к передаче по терминалу содержимого всей регистровой матрицы чипа . Полезно иногда посмотреть.

Набираю RRxx; в ответ терминал сообщает значение хх-ового регистра чипа. (долго мучился, но теперь и это работает)

Набираю WRххyy; происходит запись байта YY в регистр №ХХ. Разумееется,с отчётом по терминалу тоже.

( Все нераспознанные команды игнорируются, команды с некорректными полями параметров тоже не выполняются, но отправляют сообщение " wrong parameter". То же самое при попытке вести частоту за пределами возможности чипа. Постарался в синтаксическом анализаторе учесть все возможные ошибки ввода, но за 100% не ручаюсь. Ибо и так уже эта часть по обьёму в разы превысила собственно саму процедуру управления чипом (которая уже там затерялась, как иголка в стогу сена)


Вообще эта команда WRххyy; , она довольно прикольная , так как прямо во время работы приёмника меняет любые регистры, и можно тут же слышать, как при этом сразу меняется частота настройки или что-нибудь ещё.

Ну, а самый же главный прикол здесь я увидел в том, что эта команда может на ходу менять содержимое любого регистра чипа даже при работающей в это время со свистком HDSDR ! И результат этого вмешательства сразу же визуально виден на водопаде, например, при изменении частоты настройки все линии на водопаде сдвигаются. Это из тех эффектов, что заметны визуально. Причём сам HDSDR и RTL2832 ничего этого не замечают и продолжают работать так, словно никто и не вмешивался. :-)
Так что здесь открывается простор для экспериментов с регистрами , прямо глядя на картинку водопада.

А там, глядишь, захочется и второй чип RTL2832 поменять на какой-нибудь АЦП от аналог девайса c полосой оцифровки 10 мгц, вот только с обработкой отсчётов, а скорее даже и с отправкой их в комп по Ethernet атмега скорее всего уже просто не справится..

По поводу контроллеров. Ещё пару дней назад прошивка под завязку влезала в 8-ую атмегу (десять байтов оставалось свободных в памяти программ), а с егодняшнего дня влезает в атмеги от 16-ой и выше .
(у меня в макете сейчас Atmega128, примерно 7% памяти занимает прошивка).
У атмеги много свободных портов-ввода вывода. Возникает мысль у меня использовать их для дистанционного управления командами всё по тому же самому rs232 терминалу ключами антенных реле, коммутирующих в свою очередь антенны разных поддиапазонов и диапазонные полосовые фильтры . А может быть, даже и управлять приводом поворотного устройства и получать оттуда с крыши информацию о текущем азимуте поворотного устройства.

В общем, ещё надо дописать команду установки усиления и , в принципе, можно сделать команды записи в энергонезависимую память некоторого количества "фиксированных настроек" и выбора любой из них.
В принципе можно создать хоть целый банк для сканирования, но это уже внешнюю память надо на атмегу вешать будет.

Но в целом, всё довольно неплохо работае уже и сейчас, реально приёмник работает и радует.
В выходные нарисую схемку и можно выложить будет уже здесь более менее устаканившуюся версию прошивки .
Вот интересно, что будет лучше- пускать с крыши вниз ПЧ по коаксиалу или по экранированной витой паре?
И если по коаксиалу, то какой должен быть коэффициент трансформации у "бинокля"? Такой же, как и для директ-самплинга?