Или применять свисток V3 с преселектором или дпф на интересуемые диапазоны.
Тут вроде автор топика хочет сделать приемник на 820Т, то есть не о свистке речь, его вспоминали только как девайс использующий сабж. А по сути задуманное изделие не для "верхнего" КВ, никто диапазонную антенну таскать с ним не будет, да и любой широкодиапазонный приемник в этом участке покажет себя лучше. Это в чистом виде УКВ тюнер. Как компромисс можно, но нужно ли.

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

А по сути задуманное изделие не для "верхнего" КВ, никто диапазонную антенну таскать с ним не будет,
У дегена тоже нет полноразмерной антенны, а этому свистку ничто не мешает приделать истоковый повторитель с полосовичком и антенну 30 см. делов 15 минут

У дегена нет телевизионного тюнера внутри) и работает он от нескольких десятков кГц.

У дегена нет телевизионного тюнера внутри)
Ему же хуже ))

Мнение секты превосходства свистка очень предсказуемо)) Вот только результатов, как может деген, никто из них не достиг)

Этот укв тюнер можно например, встроить в простейший бытовой приемник-"мыльницу" благодаря малым размерам, в какой-нибудь Маsоn, и будет внешне не вызывать никаких подозрений, так как все функции обычного радиовещательного приемника будут сохранены, так как не придется освобождать обьём в корпусе для установки внутрь столь небольшого всеволнового тюнера, зато включил наушники, и сканируешь VHF/UHF диапазоны, а никто и не догадывается. Чтоб бдительные люди и менты на улице не напрягались , как при при виде человека с Alinco DJ-X10 в руках

Мнение...
при чем тут это? Да у дегена функционал как у приемника Попова, а тут поле непаханое.

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

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

Ох уж эти портативщики и шпийоны-скрытники :-)

На самом деле тема применения тюнера более широкая, не только для ваших поративно-шпионских игрушек но и просто для самопального ШП приемника, даже стационарного.

killer258
Чтоб бдительные люди и менты на улице не напрягались , как при при виде человека с Alinco DJ-X10 в руках
- Шо вы кажете, диду? Якой я американьский шпигун? Я гарний хлопче...
- Да ты хоть парашут отстегни та Harris прикопай, дытина бисова...

У меня эта тема возникла из-за того, что ещё года два назад захотелось разместить свисток на крыше впритык к антенне, а не через 30 метров кабеля, но USB работает еле-еле на 10 метров, и то если витой парой только и питание отдельно. Было решено все принимаемые частоты превращать в низкую 3.57, а уж её-то в кабеле не потеряешь, потери ноль, вести вниз. Ну, а внизу дома уже разные варианты- или подать пч на всё тот же RTL2832 и использовать HDSDR, как обычно, или подключить ради интереса обычный аналоговый тракт или PCR-1000, настроенный на 3.57.
Сначала я хотел поставить на крышу его самого (PCR-1000) , управлять по RS232, а вниз вести или вторую ПЧ по кабелю, или сразу аудиосигнал, или и то , и другое.Но жаль стало туда его тащить, учитывая его цену, мало ли что с ним случится на крыше, а вот если свисток на крыше сопрут, это не так жалко будет, как PCR-1000.
Можно было и самодельный конвертер сделать и поставить на крышу, но тогда две сложных задачи- "всеволновый" гетеродин, и борьба с зеркалкой при низкой пч, а тут всё готовое уже реализовано,и зеркалки нет, только разобраться в управлении по I2C, и всё, можно ставить наверх.

Ну а попутно рождаются и другие идеи, раз уж этот укв тюнер сможет работать автономно, без компа..

Ещё один сканирующий приёмник лишним никогда не будет. А их можно и не один сделать при такой-то цене свистка. Я ещё помню, как в 90 годах я покупал сканер Alinco DJ-X10 за 400 долларов. Каких героических жертв это тогда мне стоило при тогдашней зарплате на том заводе , равной эквиваленту примерно сорока долларов в месяц. Тринадцать зарплат на него грохнул тогда, хотя все равно не пожалел о том, что взял. Собственно, с него мониторингом и начал заниматься.
А тут из свистка за 8 долл получить тот же функционал и в общем-то, сравнимые характеристики..

Странный подход к решению несложной задачи минимизации потерь в кабеле.
Не зря напоминал про ТЗ на первой странице, с его обсуждения надо было начинать.

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

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

сейчас просчитал sdm по ихнему калькулятору

/* sdm calculator */
while (vco_fra > 1) {
if (vco_fra > (2 * pll_ref_khz / n_sdm)) {
sdm = sdm + 32768 / (n_sdm / 2);
vco_fra = vco_fra - 2 * pll_ref_khz / n_sdm;
if (n_sdm >= 0x8000)
break;
}
n_sdm <<= 1;
}



Ну, я всё это переписал для турбопаскаля в эквивалентном виде

===================================================
sdm:=0; n_sdm:=2; vco_fra:=23040;

while vco_fra > 1 do begin

if(vco_fra > 57600 div n_sdm) then begin
sdm:= sdm + 65536 div n_sdm; vco_fra:=vco_fra - 57600 div n_sdm;
if(n_sdm >= 32768) then goto M1;
end;

n_sdm:=n_sdm*2;
end;

M1:
writeln ('sdm= ', sdm); readln;

========================================
и запустил на компе под тубопаскалем.

подставил я туда начальные значения, просчитал. Вот прикол.
Получилось 0х66 и 0х66 , то есть алгоритм свистка выдал не то sdm , которое свисток сам себе записывает в регистры 0х16 и 0х15 при этих же самых,как я думаю, входных данных, а входным данным здесь является только vco_fra. (может, ее проверить?)

(сам свисток записывает в этом случае 0х66 и 0х12 соответственно)

получилось и с ихним алгоритмом всё те же 0х66 и 0х66 , что и у меня ранее получались . так вот там столько же получалось.
То есть ихний калькулятор даёт на моих данных тот же результат, что и мой, но пишет то в регистры немножечко другое. Старший байт у меня с ними совпадает, а вот младший не очень.Это приведёт к ошибке в несколько кгц

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

Хотя .... кажется, вот здесь она порылась. вот это в исходнике меня смущает (странный перевод в из герцов в килогерцы. зачем число 500?)

/* Frequency in kHz */
freq_khz = (freq + 500) / 1000;
pll_ref = priv->cfg->xtal;
pll_ref_khz = (priv->cfg->xtal + 500) / 1000;

Уж не 1024 ли герца в китайском килогерце???? :-)))


Непонятно, зачем эти 500, но так и быть, попробуем с ними. Вдруг сойдётся?

Стандартное правило округления из арифметики.
Больше 0.5 kHz - kHz+1, меньше - без изменения (деление затем целочисленное).

.Не повлияло на результат. Но чувствую, что осталась какая-то мелочь уже
Истина где-то рядом

Может, что-то прояснится, если попробовать сравнивать мои вычисленные вручную значения регистра 0х15 с перехваченными по I2C, для самых разных частот и поддиапазонов,
может, тогда и проявится закономерность.

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

напишет частоту гетеродина, необходимый коэфф деления перед смесителем, частоту VCO,
коэфф деления , его целую и дробную часть, посчитанные Ni,Si, VCO_fra, содержимое регистров 0х10, 0х14, 0х15
и тогда можно будет просчитать регистр [0х15] для самых разных частот, сравнивать с перехватами ,смотреть разницу, может, что-нибудь и выявится тогда. Может, младший байт просто будет отличаться всё время на одну какую-нибудь константу, как например странное число 13 в формуле для вычисления Ni и Si

Ni=(Nint-13)/4 и
Si=Nint-4*Ni-13

Кстати, я только сейчас заметил, что по этим ихним формулам исходника Si всегда будет получаться ноль независимо ни от чего, зачем было и считать:
Si= Nint -4*((Nint-13)/4)-13== Nint -Nint +13 -13 == 0

Впрочем, нет, если деление здесь целочисленное, с отбрасыванием остатка

PS: ну вот, готова программка на турбопаскале, которая по входной частоте просчитывает
регистры 0х10,0х14,0х15 и 0х16
а заодно и всё промежуточное. Пока что прокрутил её, посмотрел как зависит Si от целой части делителя. Оно в зависимости от того, делится он нацело на 4 или нет,
равно либо 0, когда делитель Nint кратен 4, либо принимает значения 1 и 2, если не кратен. (из-за разности округления) Других значений он принимать при таком его вычислении не может. Видимо, это отражает какие-то невидимые нам особенности архитектуры целодробного синтезатора ИМЕННО ЭТОГО чипа.

Теперь надо пробовать сравнивать с перехватами.

На атмеги я пишу на микропаскале, поэтому собственно, если бы сейчас не было этого расхождения в младшем байте регистра дробного, то уже сейчас можно было бы портировать эту прогу с турбопаскаля на микропаскаль для AVR, добавить процедуру отправки по I2C, и собственно говоря, всё.

Вот и появились первые результаты продолжения этой научной работы по исследованию R820T. Правда, терпения у меня сейчас хватило пока на пару десятков перехватов. В разных поддиапазонах.
Если не брать во внимание пока 1й поддиапазон, который начинается от 24 мгц (он какой-то особенный) , то про остальные можно сказать следующее:

регистр 0х10 моя прога считает так же, как и HDSDR. Тут вопросов нет.

Регистр целого 0х14. Здесь младшая его тетрада совпадает везде у меня и у них, а старшая у меня везде в 2 раза меньше, чем у них. То есть если у них меня 0х06, то и у меня 0х06, если у них0х47, то у меня 0х27, если у них 0х84, то у меня 0х44, если у них0хс9, то у меня 0х69. Ну тут, я думаю, просто когда я сдвигал Si влево перед складыванием его с Ni, то видимо, надо просто было Si сдвигать влево ещё на один разряд , и тогда будет получаться правильно везде.

С регистрами дробности 0х16 и 0х15 выяснилось, что старший регистр 0х16 у меня по моему "SDM калькулятору" (алгоритм которого между прочим, позаимствован ихний, из исходника!) получается чаще всего таким же, как у них, но иногда почему-то на единичку больше, чем у них. И всегда в таких случаях ровно именно на единичку.
Младший, как я и предполагал, не сходится никогда. Но тоже есть закономерность.Хоть он и не совпадает, но на каждом килогерце он увеличивается у меня ровно на столько же, как у них. (то на 26h, то на 24h. видимо, погрешности округления) И когда он увеличивается за эти 7 шагов по 24-26h, то после этого на единичку растёт старший регистр, то есть тут как-бы всё в порядке, но этот рост сдвинут вперёд по фазе на две единички старшего из этих двух байтов.Такое ощущение, что где-то в двоичной арифметике что-то слегка сдвинуто.
Будем искать.

PS: Ага, а вот и ещё одна закономерность расхождения cодержимого старшего регистра 0х16 у меня и у них :
Увеличиваю частоту настройки с шагом в 1 килогерц , снимаю показания и слежу за тем, как растёт этот старший регистр с ростом частоты у них . Он подрастает на единичку через каждые 7 кгц. (шагаю по 1 килогерцу). Мой вычисляемый 0х16 ведёт себя точно так же, тоже подрастает на единичку после каждых 7 шагов по одному килогерцу), но происходит это на два килогерца раньше. То есть всё то же самое делает, только на два шага впереди !
И уже третий раз во всех случаях расхождения моего с ихним фигурирует эта колдовская цифра "2".Хотя чего удивляться, арифметика двоичная :-)
Будем завтра думать и анализировать дальше. Если момент инкремента старшего регистра у меня "синхонизировать" бы по фазе с ихним инкрементом, то тогда наверное, и младший регистр тоже начал бы совпадать с ихним при шагании по частоте. Вернее, если где-то начальную фазу для SDM при его подсчёте поправить в той процедуре, то, наверное, он пойдёт ноздря в ноздрю с ихним.

Но, это приращение младшего дробного, оно за 1 кгц составляет24-26h только на 60 мгц. На 600 мгц поддиапазоне оно равно только 4. Значит, бессмысленно добавлять или вычитать что-то в процедуре SDM. Это частотнозависимая штука, значит, это надо делать не в впроцедуре SDM, а раньше. в неё должно поступать что-то другое, чтоб на выходе увеличивалось позже. Короче, надо VCO_fra надо будет посмотреть, оно должно поступать на вход в калькулятор будучи на примерно хх кгц меньше. (экспериментально установлено, что при из vco_fra надо вычесть 74, и тогда на выходе получается правильный результат. А может, не вычитать, а делить на что-то надо? но вот как-то не верю я , что в килогерце 1024 герца..) И тогда всё пойдёт, это как если в идущих на 2 минуты вперёд часах часовая стрелка станет подходить на деление очередного часа вовремя, если минутную отвести на пару минут назад Как говорил наш шеф, надо переспать с этой идеей :-) Чувствую, истина где-то совсем рядом.

Я сейчас прогнал на симуляторе в Паскале этот ихний SDM калькулятор, чтоб понять физический смысл его работы, прогнал для всех входных значений VCO_fra в диапазоне от 0 и до 28800*2=57600 (кгц) и анализировал, что получается при этом на его выходе, то есть SDM, который записывается в регистры 0х16 и 0х15 (старший и младший соответственно)

Оказалось, что процедура переводит 0...57600 в 0х0000 .... 0хFFFE.
то есть почти линейно переводит недостающую до требуемой (как если было бы при только одной лишь только целой части делителя петли фапч, без дробной части, так как в этом случае частота VCO может быть только кратной частоте двойной опоры,то есть кратной 57600 кгц) частоту VCO в пределах [0...57600] в двухбайтовый код диапазона от нуля до FFFE

-------------
PS: попутно выяснилось предназначение бита PW_sdm в регистре 0х12

Я имею в виду вот этот кусок
/* pw_sdm */
if (!vco_fra)
val = 0x08;
else
val = 0x00;

rc = r82xx_write_reg_mask(priv, 0x12, val, 0x08);


// В случаях, когда VCO_fra окажется =0, то есть для тех частот VCO, когда получается целочисленный коэфф деления в петле фапч, то бишь с нулевой дробной частью, этим битом в чипе (видимо,за ненужностью) выключается блок sdm (сигма-дэльта-модулятор)

Его бы заставить ещё принимать частоты не от 24 мгц, а от сотен кгц..

Обычно на такие частоты делают DDC

У меня эта тема возникла из-за того, что ещё года два назад захотелось разместить свисток на крыше впритык к антенне, а не через 30 метров кабеля, но USB работает еле-еле на 10 метров, и то если витой парой только и питание отдельно.

Роутер на OpenWRT с USB входом, на него устанавливается rtl_tcp, все это питается через POE.

Возвращаясь к SDM калькулятору. У меня такое сложилось впечатление,что если бы опорный кварц был бы не 28.8 мгц, а 32.768 мгц, то двойная частота сравнения была бы не 28800*2=57600, а 32.768*2=65.536 мгц, то есть VCO_fra получалось бы в границах [0...65535] мгц , и тогда процедура SDM-calculator вообще просто не понадобилась бы . Всё передавалось бы один к одному в регистры 0х16 и 0х15

killer258
если бы опорный кварц был бы не 28.8 мгц, а 32.768 мгц, - так оно и есть, 28.8 МГц - это компромиссное решение, ведь в "свистке" скрестили "бульдога с носорогом" R820 с RTL2832 :)

а существуют ли стандартные кварцы на 32768 мгц ? с ним вся математика была бы ровнее, меньше всяких погрешностей округления.

killer258
а существуют ли стандартные кварцы на 32768 мгц ?

https://www.digikey.ca/product-detail/en/abracon-llc/AB-32.768MHZ-B2/535-9018-ND/675213

killer258
всё рядом, самовар на 32768 хоть какой тут:

http://www.quartz1.com/price/group.php?p1=32768&group=430

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

http://www.quartz1.com/price/group.php?p1=32768&group=405

желательно из VCXO или даже VCTCXO , которые подлежат калибровке потом.

Да, пожалуй. Иначе придётся вводить такой же программный компенсатор ppm, какой сделан в HDSDR.

Это о погрешности "железа" . А сейчас вернусь к вопросу о погрешности вычислений .То есть к "математике". Вчера я опять провёл огромное количество перехватов по I2c на первом поддиапазоне выборочно на разных его участках.
(от 24 мгц до 55 мгц)
Сравнил то, что вписывает их драйвер и моя программа-симулятор.
Попутно выяснилась ещё одна интересная вещь. Во всём диапазоне и на всех остальных пяти поддиапазонах моя программа правильно считает
все регистры , то есть значит, все мои предположения построены в целом верно (кроме небольшого расхождения младшей части регистра дробного 0х15), но вот на начальном участке первого поддиапазона , очень небольшом,
от 24.000 мгц до 24.085 мгц, там свисток грубо нарушает все правила, и ставит такое значение регистра 0х10, как будто он принимает на 5-ом поддиапазоне 800-1700 мгц. Тут видимо, применены какие-то недокументированные особенности чипа) Но этот участок крайне небольшой, всего 100 кгц.(хотя, я не проверял ещё но возможно, что на этом участке свисток у меня реально уже и не работает, например, нет захвата фапч, и пытаясь исправить это, софт начинает переписывать регистр 0х10 в поисках других поддиапазонов, где бы произошёл захват). А начиная с 24.100 мгц и выше, всё уже идёт штатным образом, как по нотам. И согласно выясненному алгоритму вычисления регистров управления частотой PLL.

На остальных диапазонах и практически на всём первом диапазоне моя программа все регистры определяет верно, кроме небольшого расхождения в младшем байте регистра дробного 0х15

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

Есть "прибавка" к частоте VCO ,обеспечиваемая дробной частью коэффициента деления в петле фапч, называемая здесь как VCO_fra. Она является входным данным для калькулятора "SDM calculator", на выходе процедуры получаем SDM, то есть содержимое 0х16 и 0х15

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

Опытным путём было установлено, что если я из подаваемой в калькулятор VCo_fra вычитаю некоторое экспериментально подобранное мною число, то на выходе калькулятора начинает выходить SDM (содержимое регистров 0х16 и 0х15) в точности то самое,какое и нужно (то же самое, что генерит и сам свисток, когда он под управлением HDSDR)

Беда только в том, что это число к сожалению не постоянно, а зависит от самой частоты VCO по поддиапазону.
Для полного совпадения работы моей программы с ихней необходимо, как я выяснил, вычитать разные числа из подаваемой на вход sdm калькулятора величины, плавно растущие по мере перемещения от начала поддиапазона к концу поддиапазона. Вначале диапазона из VCO_fra надо вычитать 63 для правильного результата на выходе , в середине уже надо вычитать побольше,например 74 и более, а в конце поддиапазона надо вычитать уже 126.
И вот тогда всё правильно считает.

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

А иначе придётся делать массив поправок для разных значений октавного диапазона частот работы VCO.Это тоже работать в принципе будет, но это будет тогда как костыль вроде бы..
Опять эта магическая "двойка".. всё крутится вокруг неё :-)

То есть, поправка зависит от частоты VCO, прямо пропорционально ей.

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

А это мысль. Спасибо! А ведь точно, этот драйвер-это ещё не всё. Есть ведь ещё и HDSDR. Я как-то и не подумал об этом. Действительно, надо будет попробовать при нуле.

Может, я и правда не там ищу источник расхождения. Трудно искать черную кошку в тёмной комнате , если её там вообще нет :-))

killer258, а во всей Вашей арифметике есть где-нибудь проверка на чет-нечет
исходно требуемой частоты?