OrangeRx Open LRS 433MHz TX Module

Yden
Павел_28:

А на 8 замыкаем ±?

на картинке не нарисовано думаю это делается штатной перемычкой а она замыкает крайние контакты т.е - и сигнал

baychi

Усовершенствовал прошивку приемника Open Tiny. Исходники и прошивка здесь: files.mail.ru/E9F88F6D4CA240C1B2FEA88BF0BA5434

Что сделано:

  1. Быстрый старт. Надоело ждать 2-3 сек, для входа в меню, да и не всем АП это нравится. Теперь при включенном передатчике, приемник стартует за 400-600 мс. Вход в меню возможен в течении 5 сек (можно и больше поставить - это константа в config.h).
  2. Совмещенный PPM/PWM. При установленнй перемычке на каналах 1-2, на третий канал выводятся PPM импульсы (пока ограничил 10-ю, каналами но это тоже константа, ставьте 12 если надо). На выходы 4-10 идут PWM имульсы каналалов 4-10.
  3. RSSI в режиме би-би (помимо уровня), как в оригинальном приемнике от Эксперта.
  4. Автоматическую подстройку частоты. Отклонение, читаемое из 2B усредняется и если превышает порог (сейчас 4), через 9-й регистр RFM подстраивается поправка частоты из 2-го регистра настроек (сам регистр не меняется).

Кстати в прошивке приемника от Эксперта подстройки частоты и тем более температурной компенсации так и не увидел (надеюсь, она есть в передатчике). Регистр АЦП термометра читается один раз в начале работы и просто выводится на экран заставки (T=).
В процессе работы один раз (!) делаетс такая штука: на 10 пакетов обнуляется AFC_LIMITER (фактически это запрет автоподстройки для RFMки), на экран выводится af5, а через 10 пакетов ok. И все! Никаого воздействия на 9-й регистр или регистры коррекции частоты не делается. Это фактически тест: свалтся связь при отключенной AFC в RFMке, или нет. ИМХО - это очередной миф Дмитрия. Так-же как “фирменная технология AGC” сводится к установке бита 6 в 69-ом регистре. 😃

Expert
baychi:

ИМХО - это очередной миф Дмитрия.

или очередной бред Александра

Mark_Kharkov
baychi:

Кстати в прошивке приемника от Эксперта подстройки частоты и тем более температурной компенсации так и не увидел (надеюсь, она есть в передатчике). Регистр АЦП термометра читается один раз в начале работы и просто выводится на экран заставки (T=). В процессе работы один раз (!) делаетс такая штука: на 10 пакетов обнуляется AFC_LIMITER (фактически это запрет автоподстройки для RFMки), на экран выводится af5, а через 10 пакетов ok. И все! Никаого воздействия на 9-й регистр или регистры коррекции частоты не делается. Это фактически тест: свалтся связь при отключенной AFC в RFMке, или нет. ИМХО - это очередной миф Дмитрия. Так-же как “фирменная технология AGC” сводится к установке бита 6 в 69-ом регистре.

Александр, а Вы как-то дизассэмблируете код? Или как Вы его смотрите?

Павел_28

Спасибо всем большое, удалось сконектить orange и Rmilek! Будем вечером испытывать!

Yden

а что нужно сделать с приёмником орандж чтоб его в качестве спектроанализатора заюзать ? и каким софтом снимать показания ?
приёмник и програматор ещё едут поэксперементировать не могу , но хочу подготовится

Павел_28:

Спасибо всем большое, удалось сконектить orange и Rmilek! Будем вечером испытывать!

не за что , отпишись как связь по сравнению со штатным приёмником, разобрался как rssi с него снять ?

Dimmitri
Yden:

а что нужно сделать с приёмником орандж чтоб его в качестве спектроанализатора заюзать ? и каким софтом снимать показания ?

Скачать это, подключить через подобную штуку.

И сделать вот это.

TX: Put TX into binding mode and connect with GUI (may need to press update once).

RX: put jumper on output pins 3 and 4 (CH2&3 by default). This will force the RX to act as spectrum scanner, both LEDs will be off in this mode.

Павел_28

Отпишусь конечно! С rssi разобрался (правда не я а мой товарищ) в прошивке есть инструкция со схемой! Как сделаю, отпишусь как работает! А для того чтобы сигнал с маяка ловить, я так понимаю рация нужна?

baychi
Mark_Kharkov:

Вы как-то дизассэмблируете код?

Да, любым дизассемблером для Atmeg.

gorbln

@baychi, Expert
Господа знающие! Подскажите, пожалуйста, каким образом делается Hopping? То есть, не принципиально (прибавлением номераканала*шаг к основной несущей) - а в общем алгоритме? Как приёмник и передатчик синхронизируют свои переключения частот? Я так понимаю, сетка прыжков заливается в них ещё при программировании. Допустим, передатчик передаёт пакеты по очереди на каждом канале. Если приёмник не синхронно будет прыгать по каналам - он ничего не словит… Или приёмник ждёт пакета на 0 канале (на несущей), и после прихода первого начинает прыгать дальше? Как тогда рассинхрон по времени убрать? Иначе ведь может ошибка накопиться, или можно пакет не с начала начать ловить, а с середины?

baychi
gorbln:

Допустим, передатчик передаёт пакеты по очереди на каждом канале. Если приёмник не синхронно будет прыгать по каналам - он ничего не словит…

Вот именно поэтому он переключает частоты синхронно. Ему ведь тоже известна последовательность прыжков.

gorbln:

Или приёмник ждёт пакета на 0 канале (на несущей), и после прихода первого начинает прыгать дальше? Как тогда рассинхрон по времени убрать? Иначе ведь может ошибка накопиться, или можно пакет не с начала начать ловить, а с середины?

Перед началом связи приемник переключает каналы медленно, примерно 1 раз за цикл из 8 каналов. Как только первый пакет пойман, начинается синхронное переключение каналов. Даже если часть пакетов теряется, синхронизацию можно удерживать десятки секунд и даже минуты - ведь расхождение частот кварцев не превышает десятков PPM, а с учетом подстройки чатоты - оно еще меньше.
Но обычно через несколько секунд после потери связи, приемник вновь переводят в медленный режим поиска пакетов.

gorbln
baychi:

Даже если часть пакетов теряется, синхронизацию можно удерживать десятки секунд и даже минуты - ведь расхождение частот кварцев не превышает десятков PPM

То есть, прыжки делаются не по факту выполнения передачи пакета, а по времени? Ну, тогда с синхрой вроде бы проще. Хотя всё равно не совсем понятен механизм. По логике, передатчик должен иметь довольно широкий кадр, в середине которого находится собственно пакет. Чтобы приёмник успел переключиться и словить пакет не с середины, а с начала?
Хочу впилить hopping в проект OpenBee, а то он там заявлен, но походу не сделан.

baychi
gorbln:

По логике, передатчик должен иметь довольно широкий кадр, в середине которого находится собственно пакет.

Данных 16 байт (у LRS Expert). Всего 22 байта. Приемник сначала ловит преамбулу (2 байта), затем проверяет синхрослова (еще 2) и уже потом начинает принимать данные. В конце идет CRC16, так что целостность пакета известна. Даже если приемник случайно словит середину кадра, CRC не сойдется и пакет будет отброшен. Так как поток данных не сплошной - между пакетами есть паузы, рано или поздно прием состоится.

Mark_Kharkov
gorbln:

Господа знающие! Подскажите, пожалуйста, каким образом делается Hopping? То есть, не принципиально (прибавлением номераканала*шаг к основной несущей) - а в общем алгоритме? Как приёмник и передатчик синхронизируют свои переключения частот? Я так понимаю, сетка прыжков заливается в них ещё при программировании. Допустим, передатчик передаёт пакеты по очереди на каждом канале. Если приёмник не синхронно будет прыгать по каналам - он ничего не словит… Или приёмник ждёт пакета на 0 канале (на несущей), и после прихода первого начинает прыгать дальше? Как тогда рассинхрон по времени убрать? Иначе ведь может ошибка накопиться, или можно пакет не с начала начать ловить, а с середины?

Отвечу по прошивке KHA, т.к. с ней разбирался:

  1. базовая частота и номера каналов прыжков заливаются в приемник при бинде. Если изменить настройки каналов передатчика, а потом снова забиндить - то все будет ловить.
  2. Само собой, что если не синхронно - то ничего не словит. Но приемник будет ждать на одной из частот, пока не прийдет пакет. Пришел - и дальше по очереди.
  3. Пакет не с начала, а с середины приемник принять в принципе не может, сам радиомодуль RFM22B так работает, что сначала он ищет преамбулу (серию 0101…0101), потом синхрослово (специальные несколько байт) и только после этого уже идут данные, в конце - контрольная сумма. Если или в преамбуле помеха, или в синхрослове - за пакет это не будет воспринято, и прием данных НЕ начнется. Если прием данных произошел, но контрольная сумма не совпадет (для этого достаточно что бы 1н бит был “не такой”) - пакет будет воспринят как неверный и он также не повлиляет ни на что.
    Так работает сам чип, вне зависимости от прошивки, хоть от Александра, хоть Эксперта, хоть KHA и т.д. У него есть и другие режимы работы (Direct Mode), но железо приемника сабжевой железки его не поддерживает, только передатчик.
Shuricus
Mark_Kharkov:

Но приемник будет ждать на одной из частот,

На какой из?

Mark_Kharkov
baychi:

Приемник сначала ловит преамбулу (2 байта),

Александр, а у Эксперта 2 байта??? Ппц… Дык тогда понятно, почему нету AFC… Она просто не заработает с преамбулой 2 байта… Гляньте даташит, раздел по AFC. Без антенна диверсити и с AFC преамбула (на сколько я помню) должна быть минимум 28 бит (или что-то такое, но явно не 2 байта). Сейчас даташита нет под рукой, я с медленного инета. Проверьте. На сколько я помню - то так.

baychi:

Даже если приемник случайно словит середину кадра, CRC не сойдется и пакет будет отброшен.

Шанс что в давнных окажется хотя бы 16 бит 0101…0101, а потом сразу нужное синхрослово - мизерный. Практически нулевой. А без этого чип выставит неверную преамбулу, и перейдет в режим поиска преамбулы, в соотв с его алгоритмом работы. Я бы сказал, что шанс этого чуть-чуть больше шанса встретить на улице динозавра 😃))

baychi
Mark_Kharkov:

Ппц… Дык тогда понятно, почему нету AFC… Она просто не заработает с преамбулой 2 байта… Гляньте даташит, раздел по AFC

Ошибаетесь, AFC достаточно 2 байт.

"When selecting the preamble length, the length needs to be long enough to settle the AFC. In general two bytes of preamble is sufficient to settle the AFC. "

Mark_Kharkov:

Без антенна диверсити и с AFC преамбула (на сколько я помню) должна быть минимум 28 бит (или что-то такое, но явно не 2 байта).

Наоборот. Это для диверсити требуется более длинная преамбула. Почему Эксперт и не хочет вводить диверсити.

Mark_Kharkov:

Шанс что в давнных окажется хотя бы 16 бит 0101…0101, а потом сразу нужное синхрослово - мизерный.

В пакете могут встретися любые комбинации данных, в том числе и вышеуказанные. Само по сбе это не редкость. Другое дело, что одновременное сочетание фиктивной преамбулы, синхрослова и случайное совпадения CRC16 - практичести невозможно. Хотя теория передачи информации рассматривает и такой случай. Например в телемеханике есть требования к вероятности приема ложного пакета, как своего, и они лежат на уровне 10^-9 … 10^-12, а это круче, чем 2^32. 😃

Expert
baychi:

Почему Эксперт и не хочет вводить диверсити.

А кто вас сделал мои личным пресс атташе?
Никакого отношения дивесити к преамбуле не имеет вААпще.
Может хватит уже этот бред нести?

baychi
Expert:

Никакого отношения дивесити к преамбуле не имеет вААпще.

"When antenna diversity is enabled, it is

advised to use a 20 bit preamble detection threshold. When the receiver is synchronously enabled just before the
start of the packet, then a shorter preamble detection threshold might be chosen (e.g., 8 bit).
The required preamble length is determined from the sum of the receiver settling time and the preamble detection

threshold. "

Expert:

Может хватит уже этот бред нести?

Тогда будем разбирать баги в Вашем протоколе. 😃 Наример Ваша дополнительная CRC8 для контроля пакета не защищает байт старших бит канальных импульсов и управляющий байт. Почему?

Expert

и чё? ну я же не по этому дивесити не делаю - что я байт один поправить не в силах.

baychi
Expert:

что я байт один поправить не в силах.

Это требует изменения протокола, то есть ведет к неполной совместимости.
И про удилнение преамбулы Вы сами неоднократно писали. Хотите процитирую? 😃