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

Немного не понял вашего вопроса про чётность-нечётность требуемой частоты. Можно поподробнее об этом ?
У меня здесь частота приёма после прибавления к ней величины ПЧ сначала умножается на коэфф деления делителя, того , который перед перед смесителем, потом это делится на двойную опору, на целую часть результата такого деления этот "чет-нечет" вроде не влияет, а вот дробная часть вычисляется по ихней процедуре SDM-callсulator, смысла выполняемых в ней действий я к сожалению так до конца и не разобрал, хотя общий принцип и понимаю, поэтому я не могу ничего по поводу дробной части сказать. Может, конечно, я чего-то не знаю. Заметил тольтко, что этот калькулятор у них написан так, что на его выходе его младший байт (регистр 0х15) всегда почему-то получается только чётным, и увеличиваясь, всегда скачет не меньше чем через 1. Видимо, это не просто так,возможно, чипу это нужно,чтобы нужное ему SDM значение инкрементировалось через один и было всегда чётным. Почему-не знаю, так как схема SDM этого чипа для нас - черный ящик.

Сейчас я пока набросал по быстренькому в программе аналог HDSDR-овского движка корректора PPM (все равно ведь он понадобится?)
Идея была такая.
При изменении частоты VCO от Min до Max число коррекции, вычитаемое из VCO_fra, должно меняться от 64 до 128.

Я опытным путём подбора выяснил, что если текущее значение частоты VCO поделить на примерно 29150, (на другом свистке возможно, это будет чуточку другое число) то будут получаться как раз те самые числа, во всяком случае, того самого порядка, что нам нужны для коррекции. Вот их я и попробовал вычитать из VCO_fra перед подачей на SDM калькулятор. Вписал перед калькулятором строчку, в которой частота VCO делится на эти 29150, и VCO_fra уменьшается на эту величину перед подачей в sdm калькулятор.

Попробовал пробежаться по разным частотам всех диапазонов. Вот теперь очень хорошо стало.
Расхождение содержимого регистра 0х15 теперь либо совсем отсутствует в ряде точек, либо отличается на плюс-минус две единички. Но он и у них меняется всегда только скачком минимум на две единички, так что это немного. По приблизительным прикидкам, на 2 поддиапазоне это даст погрешность установки частоты имхо около 125-250 гц

Короче, всё работает. Радуйтесь, афиняне, мы победили! (С)
А число 29150 здесь является чем-то вроде того числа коррекции PPM ,которое на движке настроек в программе HDSDR и будет зависеть от конкретного свистка

А это не PPM-коррекция опорника, если в программе ноль поставить и прогнать снова частоты?

Примите мои поздравления и благодарности! Вы попали в самую точку!

Запущенный с нулевым значением ppm-коррекции HDSDR выдал в чип по I2C как раз в точности те самые "неправильные" значения регистров 0х16 и 0х15, которые у меня до этого упорно получались в моей арифметике , и над "неправильностью" которых я ломаю свою голову уже целую неделю, а исходник драйвера зачитал вообще до дыр, но так и не нашёл там того, чего там нет :-)

Заодно при перехвате обнаружилось ещё кое-что. При передвигании движка ppm в HDSDR, по I2C шине тоже проходит сессия с записью и чтением регистров чипа... Что-то HDSDR ему там сообщает. Прописывается как всегда, вся куча регистров, даже те, содержимое которых не требуется менять (в данном случае менялись только 0х16 и 0х15)
При этом при установке ppm=33 в регистры 0х14, 0х15 и 0х16 для чего-то было передано 0xc5, 0xd7,0xde соответсвенно, а при установке ppm=0 в те же регистры было уже передано 0xc5, 0xd8 и 0х2e

Правда, это было сделано при недвижущемся водопаде. Надо попробовать то же самое при движущемся.
Только что попробовал. При движущемся водопаде эффект стал более понятным. При работе на частоте 63.750 мгц после передвижения ползунка ppm из положения 0 в положение +1 младший байт рег. 0х15 просто уменьшился с "неправильного" 0х66 до чуть более правильного 0х62, то есть исправился на 4 единички, чтобы соответствовать новому значению ppm. А совсем правильное значение регистра 0х15 получается у меня на этом свистке при ppm=34, тогда оно =0х12

Поздравляю с успешной разгадкой. Конечно, РРМ не будет в драйвере, это же функция ПО и логично, что корректировка учитывается уже в отправляемом коде для регистров.

Да, коллективный разум работает эффективнее одиночного.

Кстати, если бы не требовалось этой коррекции, то , как я сейчас понял, вместо ихнего SDM калькулятора
так же точно работал бы и тот мой метод, котоорый я по началу предложил вместо ихнего, а потом стал смотреть в сторону ихнего sdm калькулятора, так как думал, что у моего способа вычисления SDM получаются неправильные значения, а они оказывается были правильными, просто я напрочь забыл про ppm.
А способ вычисления у меня был простой, без всяких циклов с условиями: просто берёшь дробную часть от деления требуемой частоты VCO на уже примелькавшиеся здесь (2*28.8) , и эту часть помножаешь на 65536. Всё. Получаешь готовый sdm в двух байтах
Вот только непонятно тогда, как корректировать ppm. Хотя, догадываюсь. Вместо 28.8 пришлось бы вписывать что-то наподобие 28.8000113213423 , а это большие затраты для микроконтроллера на деление чисел с плавающей точкой, ибо атмега не пентиум всё же. Или переносить десятичную точку вправо у обоих операндов и делить их друг на друга как два огромных целых числа целочисленным делением, а потом восстанавливать положение точки в результате и отбрасывать всё,что окажется правее её?

Или может, всего-то надо просто поставить и подкрутить подстроечный конденсатор при опорном кварце, как это делалось в вч блочках радиотелефонов Panasonic KXT-9080/7980 для точного совмещения частот каналов сетки с требуемыми ? Там опорник 12.8 мгц был с подстроечником для этого, чтоб точно "в канале" приемник и передатчик стояли.
Может, и здесь так же сделать? Или всё равно ppm будет возникать необходимость подстраивать?
(нужна подсказка телезрителей :-) )

Продолжаем научное исследование чипа R820T.

И так, с вычислением содержимого регистров 0х10, 0х14, 0х15 и 0х16 мы с общей помощью разобрались.
В описании алгоритма на предыдущих страницах страницах и-за недостатка информации были допущены некоторые неточности в рассуждениях, они были впоследствии переосмыслены и исправлены, но внести исправления назад уже не представляется возможным, так как редактирование здешних постов доступно только в течении суток, поэтому я несколько позже напишу это снова, в окончательном варианте, убрав все рассуждения и предположения, оставив только то, что верно и убрав то, что было неверно и то, что находилось в статусе "непонятки".
Я конечно,ни в коей мере не претендую как на полноту освещения данного чипа , так и на 100% правильность и достоверность того, что здесь написано , но стремиться к этому всегда буду. Буду также благодарен всем, приславшим мне в личку или высказавшим на форуме свои замечания , предположения, или подсказки.

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

Это регистр 0х1А , встречающийся в перехватах почаще, чем остальные. Он во время I2C сессии записывается как минимум, дважды.

Назначение битов регистра 0х1А:
7:6 -- Какой-то там RMUX Tracking Filter (00->TF ON, 01-> TF BYPASS. Не знаю, что это за Tracking Filter такой, но HDSDR включает его только на частотах приема 24.00-306 мгц)

5:4 -- Всегда 10, (неперезаписываемая константа, зашито намертво)

3:2 -- какое-то "PLL autotune clk", может принимать три значения 00-> 128khz,01-> 32khz,10-> 8khz
(предположительно, это ширина полосы захвата и удержания, которую расширяют для более скорого входа ФАПЧ в синхронизи и сужают после этого, как он произошёл, чтоб уменьшить фазовый шум)
HDSDR перед вычислением очередной частоты всегда устанавливает этот параметр равным 128 кгц, потом прописывает регистры 0х14,0х16 и 0х15, а после чтения рег 0х00..0х03 (проверяет факт захвата в петле ФАПЧ и что-то ещё) , после чего опять ставит 8 кгц.

1:0 -- это выбор одного из трёх вариантов RF фильтра (10-> lowband,01->Midband, 00-> Highest Band)

Путём перехватов обмена выяснилось, что HDSDR выбирает нужный RF фильтр так:

lowband= 24.000 мгц...306.429 мгц
Midband= 306.430 мгц...584.400 мгц
Highest Band=584.500 мгц...1760 мгц

Что делает HDSDR:

на lowband : вначале в регистр [0х1А] вдувается 0х2А (0010_1010), что означает "Tracking Filter On, PLL autotune clk=8 khz, RF Filter=lowband
Затем ввычисляются все эти калькуляторы делителей, в рег 0х1А вдувается 0х22 , что означает всё то же самое, но только autotune clk=128 khz для ускорения захвата частоты
потом прописываются регистры задания PLL: 0х14, 0х16, и 0х15
потом читаются регистры 0х00...0х03 для проверки результата (захват и что-то ещё)
Затем в регистр [0х1А] снова вдувается 0х2А (0010_1010), "Tracking Filter On, PLL autotune clk=8 khz, RF Filter=lowband (то же самое, но опять ставится autotune clk=8 khz для режима удержания частоты.

на Midband : вначале в регистр [0х1А] вдувается 0х69 (0110_1001),потом 0х61(0110_0001), потом снова 0х69 (0110_1001)
(Короче , Tracing Filter в этом случае =ByPass, ну, Band ,естественно,= Mid , а PLL autotune как и в предыдущем случае, вначале clk=8 khz, потом 128, потом снова 8)

на HighestBand : вначале в регистр [0х1А] вдувается 0х68 (0110_1000),потом 0х60(0110_0000), потом снова 0х68 (0110_1000)
(короче, всё как в предыдущем случае, только бэнд RF фильтра ставится "Highest"


Обобщаю:

Для lowband= 24.000 мгц...306.429 мгц в [0х1А] вписываем 0х2А, потом 0х22, затем снова 0х22

Для Midband= 306.430 мгц...584.400 мгц в [0х1А] вписываем 0х69, потом 0х61, затем снова 0х69

Для HighBand=584.500 мгц...1760 мгц в [0х1А] вписываем 0х68, потом 0х60, затем снова 0х68

Дальше остаются уже второстепенные настройки. Сейчас посмотрел, трогание каких движков HDSDR вызывает I2C сессию, а каких не вызывает.

Выбор Msps (0т 0.25 до 3.2) - вызывает. Но в логе I2C видны одни только безуспешные обращения к несуществующему чипу cо slave-адресом 0010000(записи и чтения)

"RTL AGC"-не вызывает
"OFFSET Tuning" -не вызывает
"FRec Correction" -как мы уже заметили до этого, вызывает (меняются рег [0х16] и [0х15])
"Direct Sampling" (disable,I input,Q input) -вызывают. Сначала прописывает вообще все регистры подряд строго в порядке возрастания номеров , от 0х05 до 0х1F, затем прописывает уже индивидуально 0x0c, 0x13, 0x1D, 0x0b, 0x1F, 0x10, 0x12, 0x1A, затем читает регистры 0х00...0х04

"Tuner Gain" -естественно, вызывает .Тут обмен совсем небольшой происходит. Поставил ради интереса движок в положение 44.5 дб. Вначале произошло обращение к несуществующему чипу , затем в регистры [0х05], [0х07] пишется 0х0с и 0х7B соответственно,потом опять обращение к несуществующему чипу(запись и чтение. такое ощущение, что NACK при этом просто игнорировались) потом снова пишет регистры [0х05], [0х07], на этот раз значениями 0х0с и 0х7С

Надо будет ещё детально уточнить, что конкретно туда пишется при самом верхнем, самом нижнем и нескольких средних положениях движка Tuner Gain. И тогда всё. Остальные регистры можно для начала будет прописывать и по дефолту.

Но в логе I2C видны одни только безуспешные обращения к несуществующему чипу cо slave-адресом 0010000(записи и чтения)
Вполне возможно, что это декодер каких либо систем телевидения.

Итого, ждем функции Init_R82x и Set_Freq_R82x. Я думаю, что написать их можно даже со скромными познаниями в Си (виртуозность тут не требуется) и наиболее эффективной и безошибочной тут будет авторская работа.
Дело не в иждивенчестве, а то что многие заняты не менее важными делами, возможно близкородственными.

В общем-то, да, именно такие функции и будут. Я пишу на MikroPascal for AVR, поскольку на нем у меня хоть что-то работающее получается, несмотря на то, что компилятор этот довольно сырой и некоторые его библиотечные функции недоделаны и не могут использоваться, тк не работают корректно, приходится например пользоваться собственным софтовым I2C вместо ихнего аппаратного и собственной программой вывода на LCD. Если кто-то тоже пишет на этом, тому будет проще разбираться в моём. Я напишу и отлажу на этом, на чем сам делаю а потом уже нетрудно будет переписать на MicroC For AVR или даже на CWAVR, но последний я ещё не освоил, так что там "допиливать" код придётся уже совместными усилиями всех, кто подключится.
Для тех, кто захочет параллельно писать самостоятельно Set_Freq_R82x, я весь алгоритм распишу здесь детально, собрав всё в одном месте.

Для непрограммирующих пользователей можно будет просто сделать готовую HEX прошивку для атмеги, которая будет рулить чипом, и пусть экспериментируют, а задание частоты и усиления мега будет принимать либо с комбинации джамперов на своих входных портах , либо управляться по UART-у (RS-232) чем-то наподобие АТ-команд, подобно тому, как по RS-232 управляется приёмник Icom PCR-1000. Этот вариант пригодился бы например, для дистанционного управления чипом, расположенным на крыше.

Ну, а пока попробую более детально проснифферить обмен при установке усиления , чтобы понять границы вдуваемых в рег 0х05 и 0х07 величин,

и наверное, запишу и выложу здесь на всякий случай всю матрицу регистров при включении режимов "Direct Sampling" (disable,I input,Q input). Нам они, в принципе, не нужны, но чисто из интереса можно будет глянуть, что именно там происходит при переключении чипа в этот режим. (Скорее всего, там отключаются внутренние узлы, управляемые битами с названиями, начинающимися на PWxxx, коих довольно много там)

Вообще , надо сказать, я тут параллельно занимаюсь управлением ещё одним синтезатором, входящим в состав довольно неплохого по параметрам ВЧ блочка из найденного на улице домашнего кинотеатра LG XH-T6747X, который принимает у них там только FM 65-108мгц и средние волны, но по даташиту возможности делителей синтезатора у него позволяют гонять VCO в АМ тракте аж до 40 мгц (то бишь короткие волны принимать запроосто), а на FM от 10 мгц до 160 мгц.
Так вот, по сравнению с этим чипом, там настолько всё проще, что это даже и не выразить словами. Надо будет только запаять всё это и в коробку подходящую оформить, с индикаторами и кнопками.
А в этом чипе R820T похоже, припасено для нас загадок ещё предостаточно, имхо.

killer258
А в этом чипе R820T похоже, припасено для нас загадок ещё предостаточно - совершенно с вами согласен. Приедут мои "свистки" подключусь к теме "кладоискательства" )) И когда будет свободное время, займусь "скрещиванием" R820T2 c Arduino, благо, от старых моих проектов шилдов ещё осталось предостаточно )) Есть ещё одна идея, но, о ней позже... Я, практик, а не теоретик, привык сразу реализовывать свои идеи, а потом уж обсуждать пути её(идеи) модернизации. Есть один большой минус, в таком подходе к "задумкам" - не всегда есть под рукой нужные "комплектующие", блоки, и т.д. и самое главное - времени (да и со здоровьем, в крайнее время, хреновато стало)). Поэтому, участникам не судить строго, буду появляться в теме по мере своих сил и возможностей. Постараюсь сразу с "идеями в железе"(макет).

Собрал перехваты при движении ползунка регулировки усиления. (регистры 0х05 и 0х07). Тут всё оказалось довольно просто.

Tuner Gain _ рег.[0x05] _ рег .[0x07]
---------------------------------------
0 дб __________ 0х10 ______ 0х60
0.9 дб _________ 0х11 ______ 0х60
1.4 дб _________ 0х11 ______ 0х61
2.7 дб _________ 0х12 ______ 0х61
3.7 дб _________ 0х12 ______ 0х62
7.7 дб _________ 0х13 ______ 0х62
8.7 дб _________ 0х13 ______ 0х63
12.5 дб_________ 0х14 ______ 0х63
14.4 дб_________ 0х14 ______ 0х64
15.7 дб_________ 0х15 ______ 0х64
16.6 дб_________ 0х15 ______ 0х65
19.7 дб_________ 0х16 ______ 0х65
20.7 дб_________ 0х16 ______ 0х66
22.9 дб_________ 0х17 ______ 0х66
25.4 дб_________ 0х17 ______ 0х67
28.0 дб_________ 0х18 ______ 0х67
29.7 дб_________ 0х18 ______ 0х68
32.8 дб_________ 0х19 ______ 0х68
33.8 дб_________ 0х19 ______ 0х69
36.4 дб_________ 0х1A ______ 0х69
37.2 дб_________ 0х1A ______ 0х6A
38.6 дб_________ 0х1B ______ 0х6A
40.2 дб_________ 0х1B ______ 0х6B
42.1 дб_________ 0х1C ______ 0х6B
43.4 дб_________ 0х1C ______ 0х6C
44.5 дб_________ 0х1D ______ 0х6D
48.0 дб_________ 0х1E ______ 0х6D
49.6 дб_________ 0х1F ______ 0х6E

Переключения "Direct Sampling" (disable,I input,Q input)

В случае переключения на Direct Sampling Disable ( наш режим) происходит очень длинная сессия, не помещающаяся полностью в буфер логического анализатора (он у меня под MS-DOS), но та её часть, которая помещается, она абсолютно идентична тому, что происходит при запуске HDSDR в этом же самом режиме Direct Sampling Disable (об этом чуть позже)

в случае "Direct Sampling" I input, и Q input происходит запись довольно небольшого количества регистров, она совершенно одинаковая в обоих случаях:

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

Все эти регистры действительно содержат биты PWxxx, видимо, в этом режиме просто напрочь отключаются всякие там фильтры, усилители , смеситель, делители, и VCO.

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

static const uint8_t r82xx_init_array[NUM_REGS] = {
0x83, 0x32, 0x75, /* 05 to 07 */
0xc0, 0x40, 0xd6, 0x6c, /* 08 to 0b */
0xf5, 0x63, 0x75, 0x68, /* 0c to 0f */
0x6c, 0x83, 0x80, 0x00, /* 10 to 13 */
0x0f, 0x00, 0xc0, 0x30, /* 14 to 17 */
0x48, 0xcc, 0x60, 0x00, /* 18 to 1b */
0x54, 0xae, 0x4a, 0xc0 /* 1c to 1f */

,да и всё. Но однако, оказалось, что после этого зачем-то некоторые регистры прописываются ещё раз (названы в исходнике как Shadow regisers, это 0x0с,0x13,0x1d,0x0b,0x0f,0x10,0x1A,0x12)
Потом он читает информацию из первых 0х00...0х03 регистров (она такая: 0х69,00,FC,FF,47) это что-то типа статуса чипа. Затем он , видимо, удовлетворившись прочитанным,вписывает другие значения в регистры
0х10,0х14,0х12,0х16 и 0х15 (это регистры , задающие частоту), опять затем делает чтение,( получает 0х69,0х00,0хС2) , переписывает заново регистры 0х1А,0х0B,0x0F, опять делает контрольноен чтение, опять принимается за регистры 0x0A,0x0b,0x07, и далее в том же духе очень долго, не поместилось в анализатор.

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

Да, и в самом начале идёт обращение не только к несуществующему чипу со slave адресом 001 0000,
но и ещё к двум тоже несуществующим чипам со slave адресами 110_0100 и 110_0011 соответственно.
Тоже безуспешные попытки что-то записать туда и потом что-то прочесть из них, после чего уже начинает вплотную заниматься чипом R820T,который откликнулся сигналом ACK.

Надо переварить это. Раскуривать вот этот кусок

/* for LT Gain test */
if (type != TUNER_ANALOG_TV) {
rc = r82xx_write_reg_mask(priv, 0x1d, 0x00, 0x38);
if (rc < 0)
return rc;
// usleep_range(1000, 2000);
}
priv->int_freq = if_khz * 1000;

/* Check if standard changed. If so, filter calibration is needed */
/* as we call this function only once in rtlsdr, force calibration */
need_calibration = 1;

if (need_calibration) {
for (i = 0; i < 2; i++) {
/* Set filt_cap */
rc = r82xx_write_reg_mask(priv, 0x0b, hp_cor, 0x60);
if (rc < 0)
return rc;

/* set cali clk =on */
rc = r82xx_write_reg_mask(priv, 0x0f, 0x04, 0x04);
if (rc < 0)
return rc;

/* X'tal cap 0pF for PLL */
rc = r82xx_write_reg_mask(priv, 0x10, 0x00, 0x03);
if (rc < 0)
return rc;

rc = r82xx_set_pll(priv, filt_cal_lo * 1000);
if (rc < 0 || !priv->has_lock)
return rc;

/* Start Trigger */
rc = r82xx_write_reg_mask(priv, 0x0b, 0x10, 0x10);
if (rc < 0)
return rc;

// usleep_range(1000, 2000);

/* Stop Trigger */
rc = r82xx_write_reg_mask(priv, 0x0b, 0x00, 0x10);
if (rc < 0)
return rc;

/* set cali clk =off */
rc = r82xx_write_reg_mask(priv, 0x0f, 0x00, 0x04);
if (rc < 0)
return rc;

/* Check if calibration worked */
rc = r82xx_read(priv, 0x00, data, sizeof(data));
if (rc < 0)
return rc;

priv->fil_cal_code = data[4] & 0x0f;
if (priv->fil_cal_code && priv->fil_cal_code != 0x0f)
break;
}
/* narrowest */
if (priv->fil_cal_code == 0x0f)
priv->fil_cal_code = 0;
}

rc = r82xx_write_reg_mask(priv, 0x0a,
filt_q | priv->fil_cal_code, 0x1f);
if (rc < 0)
return rc;

/* Set BW, Filter_gain, & HP corner */
rc = r82xx_write_reg_mask(priv, 0x0b, hp_cor, 0xef);
if (rc < 0)
return rc;

/* Set Img_R */
rc = r82xx_write_reg_mask(priv, 0x07, img_r, 0x80);
if (rc < 0)
return rc;

Иначе как бы не пришлось просто копировать весь этот поток инициализации.и вдувать его наудачу.

Хотя, из чтения даташита у меня всё время скадывалось впечатление, что достаточно просто вдуть в регистры чипа массив дефолтных значений-и вперёд..

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

содержат биты PWxxx, видимо, в этом режиме напрочь отключаются всякие фильтры, усилители , смеситель, делители, и VCO.

Так и есть, свисток меньше греется и потребляет меньше тока.

К сожалению, в даташите ничего не сказано детально о битах первых регистров (я так понимаю, регистров состояния)
[imgs] [/imgs]

Именно их драйвер читает, и от того, вкаком состоянии он их найдет, он потом что-то дописывает.
После вдувания в регистры 0х14,0х16, 0х15 тоже всегда обязательно происходит чтение упомянутых выше регистров.(проверка захвата фапч скорее всего плюс ещё что-нибудь)
Видно из названий, что один из регистров имеет прямое отношение к VCO (lock/unlock и возможно, не только это) , другой к RF
Знать бы это побитно. Особенно непонятно что здесь может значить RF.

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

На сколько я понял, они там настраивают ПЧ и ширину фильтра под разные стандарты DVB (6-7-8МГц полоса сигнала), этот процесс по идее достаточно выполнять один раз при первом обращении после запуска ПО.

я таки записал весь обмен при запуске HDSDR полностью. По обьёму переданных даннных он примерно в 7 раз превышает тоже самое при просто установке в другую частоту уже запущенного HDSDR. Очень много раз читались там регистры состояния. Осталось набраться терпения, разложить всё это полочкам и проанализировать, чтоб понять, обязательно ли всё это полностью копировать.. На всякий случай сниффернул обмен трижды. Потом то же самое надо будет попробовать и со свистком R820T2 тоже.

Давно была мысль прикрутить свисток к микроконтроллеру. Почитал по теме. Для тех кто разбирается в C#, исходники нашей любимой программы SDRSharp. Там есть и драйвер для работы с тюнером чтобы понять протокол обмена. Я не знаю C, только вот за изучение взялся. Может среди нас есть гуру... Так же там есть обработка разных видов модуляции.
http://www.radioscanner.ru/uploader/2018/sdrsharp-master.rar

я таки записал весь обмен при запуске HDSDR полностью.
А не пробовал сравнить запуск свистка с помощью rtl_tcp+hdsdr и запуск из sdr#?

теперь можно будет попробовать. Я бы здесь выложил для совместного препарирования логи I2C, но очень уж места много займет, прямо вспомнилось как раньше в журналах Радио на страницах публиковались шестнадцатиричные таблицы прошивок Орион-128 или Радио-86РК и ПЗУ АОН-а:-)

С утра на свежую голову попробую проанализировать
Хотяя, кому интересно, можете взять из файлообменника по ссылке
http://transfiles.ru/8nnca
(хранится 14 дней)

там смысл имеют те транзакции, которые имеют слэйв адррес 34(запись) и 35(чтение)
(если читать их вместе с битом R/W) а те, что обращение по адресам 20 и 21 без ACK от этих устройств, можно не смотреть. (особенно много их при старте)
Start (1,2,3)- это логи запуска HDSDR (три отдельных запуска), а маленький файлик- это то, что происходит при смене частоты на 63.750 мгц

Поясню на маленьком кусочке, что в логе что обозначает

START
00110100 0 [34H]
00010000 0 [10H]
10000100 0 [84H]
0 STOP


// [34]-значит, операция записи в наш чип R820T, а не в какой-то другой (35 означало бы чтение)
[10H]- адрес регистра, куда записывается байт
[84H]- это собственно, сам байт, тот, который записывается в регистр с указанным до этого адресом 10h

А такой кусок
START
00110100 0 [34H]
00000000 0 [00H]
0 STOP
START
00110101 0 [35H]
01101001 0 [69H]
00000000 0 [00H]
11001010 0 [CAH]
11111111 0 [FFH]
01000111 1 [47H]
0 STOP

Означаеет
[34H] [00H] запись(установка) адреса на 0х 00 для последующего чтения начиная с этого адреса и далее с авто инкрементом адреса
[35H]- будем читать последовательно, пока не оборвем стопом (всё по даташиту)
[69H] [00H] [CAH] [FFH] [47H]- это то, что прочитали из регистров cостояния чипа с адресами 0, 1, 2, 3, и 4

69H , прочитанное из нулевого регистра, является признаком-идентификатором чипа R820T

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

[reg ] >----------------------------------время--------------------------------------------------------->

5 -------------------03--83-----------------03---------------13-------------1F-------1F------------
6 -------------------12--32-----------------12---------------------------------------12------------
7--------------------75--75-----------------75---------------65-------------6E---------------------
8 -----------------------C0---------------------C0-----------------C0----------C0------------------
9 -----------------------40---------------------40-----------------40----------40------------------
0A ------------------D2--D6-----------------D2---------------------------------------D2------------
0B --6C------7C,6C---6B--6C,6C------7C,6C---6B-----------------------------------------------------
0C --F0------------------F5,F0----------------------------------68---------------------------------
0D ----------------------63----------------------------------------------------------53------------
0E ----------------------75----------------------------------------------------------75------------
0F---6C-------68-----68--68,6C--------68----68-----------------------------------------------------
10---6C--8C--------------6C,6C--8C--------------84-----04----------04-04-------04-A4---------------
11-----------------------83-----80---------------------------------------------------BB------------
12---80--80--------------80,80------------------80-----80-60-------80-80-60----80-80---------------
13---31--80--------------00,31---------------------------------------------------------------------
14-------84--------------0F-----84---------------------7F-------------7F----------8B---------------
15-------72--------------00-----72---------------------EE-------------DE----------2C---------------
16-------1C--------------C0-----1C---------------------EE-------------EE----------85---------------
17-----------------------30---------------------38-----------------38----------38----38------------
18-----------------------48------------------------------------------------------------------------
19 ------------------EC--CH-----------------EC-----------------------------------------------------
1A---60-------68---------60,60--------68--------2A,22--------------22----------22----2A,3A,2A------
1B ----------------------00---------------------DF-----------------DF----------BE------------------
1C ----------------------54----------------------------------------------------------24,20,24------
1D --86------------------AE,86-------------------------------------------------------ED,C5,DD,6E---
1E-------------------6A--4A-----------------6A-----------------------------------------------------
1F-------------------40--C0-----------------40-----------------------------------------------------

или ровнее будет наверное так
[imgs-r] [/imgs-r]

массив дефолтных значений вписывается во всю матрицу регистров дважды. (первый раз в самом начале, я его опустил)

Также видно, что помимо дефолтных значений частоты PLL,
производились ещё три установки частоты PLL.
Одна была в диапазоне частот гетеродина 55-110 мгц, вторая была в диапазоне 880-1600 мгц, третья была осуществлена в диапазоне 27-55 мгц.

Более точно можно посчитать по значениям регистров 0х10, 0х14, 0х15 и 0х16
Я пока не подсчитывал, на какие конкретно частоты и с какой целью он три раза перенастраивался.
первый раз - около 53 мгц, если пч считать равной 3.57

Сейчас сниффернул для сравнения запуск SDR-SHARP.

Детально лог ещё не разглядывал, но пробежавшись целиком галопом по нему, видел, что вроде примерно то же самое, но обьём прошедшего по шине I2C траффика получается в 2 с небольшим раза больше обьема траффика при запуске HDSDR, а вот при изменении частоты на уже запущенной SDR-SHARP ,наоборот, траффик был в 2 раза меньше, то есть было меньше записей в регистры.(только установка регистров PLL, выбор RF фильтра и включения всяческих PWxxx). Надо будет подетально сравнивать. среди несуществующих чипов упоминались ещё 2 или три незвестных адреса, которых не было в HDSDR, и что бросилось в глаза, по дефолту регистровая матрица прописывалась не 2, а три раза, но что ещё сильнее бросилось в глаза, так это то, что , что при записи этого дефолтного массива они не церемонились с отдельной записью каждого региистра, как это делает HDSDR, а писали прямо блоками по 7 байт за один раз (как рекомендовано в даташите). Правда, непонятно, что им мешало вообще на одном дыхании весь массив вдуть.

И ещё что интересно, SDR-SHARP писал ещё и нулевые байты в несуществующие по даташиту чипа R820T два регистра с адресами 0х21 и 0х22 (максимум по даташиту , это может быть там 0х1F), так вот, что интересно, чип утвердительно отвечал на эту операцию, как будто у него внутри и правда больше чем 32 регистра..

Заполню логи в виде таблиц, тогда можно будет подетально сравнить, какие регистры прописывались отдельно, и чем.
Если кто хочет сам сравнить логи, могу так же закинуть в тот же самый файлообменник и логи от запуска SDR-SHARP

Может так оказаться, что закончится выпуск R820T2 и устройств на нем SDR приемник AIRSPY - Страница 45

killer258
а этот ppm сколько должен дать коррекции? Можно от микроконтролера генерировать аналоговое напряжение и подавать на кварцевый ГУН. Для этого надо понимать сколько требуется тянуть частоту.

Черт его знает, на сколько придётся тянуть частоту кварца, поскольку циферки PPM на шкале ползунка в HDSDR и SHARP наверняка условные...в принципе, любой контроллер может легко управлять каким-нибудь ЦАП-ом, можно даже простейшим самодельным R-2R.
Также многие современные контроллеры имеют на борту выход аппаратно реализованного ШИМ-а, но он наверное, создаст помехи. Хотя в Р-45 питание варикапа идёт от преобразователя напряжения
Но я думаю, может, удастся просто обойтись подстроечными конденсаторами при кварцевом генераторе. Надо будет почитать основную тему, там люди вроде экспериментировали с внешними опорными генераторами, не знаю, какой они точности добивались

Там ничего аналоговым путем не крутят у опорника, коррекция частоты учитывается же в управляющем коде тюнера, это вроде бы выяснили недавно?

Да, учитывается, я даже вроде бы научился её учитывать при расчете регистров 0х15 и 0х16 .Просто если бы опорник можно было подстроить кондером, то в управляющем коде можно было бы вообще ничего не корректировать, а в HDSDR поставить ползунок PPM на ноль