Роман, для какой скорости передачи данных указана дальность связи для простых модулей? В плане повышения дальности лучше использовать суб-гигагерцовые модули, а не на 2.4 ггц. В некоторых модулях можно направить через вывод корпуса сырые данные приемника до обработки.
У меня пока есть только простенький, без усилителя. Сначала поковыряем его)) Потом найдём с усилителем))
Установил мощность: -18dBm (0,015 mW) Установил чутьё: 2Mbps -82 dBm (17.8 мкВ) По дому до 5 метров без потерь пакетов. До 10 метров с потерей...
Установил мощность: -18dBm (0,015 mW) Установил чутьё: 250kbps -94 dBm (4.46 мкВ). Заметно лучше)) По дому до 10 метров без потерь пакетов. Только иногда замирания...
Установил мощность: -0dBm (1 mW) Установил чутьё: 250kbps -94 dBm (4.46 мкВ). Заметно лучше)) По дому до 10 метров без потерь пакетов. В доме нет такого места, где бы была потеря пакетов)) Только если засунуть в микроволновку и закрыть дверцу (микроволновка - один большой экран для СВЧ) ... ))))
Теперь мне интересно какая максимальная дальность nRF24L01+ без усилителя при прямой видимости... Только за окном плохая погода... Проверю позже...))
Спасибо за данные по NRF. У меня такие модули без усилителей тоже есть, но попробовать их руки не дошли. Поэтому будут интересны Ваши данные по испытаниям их на открытой местности. Кстати, насчет дальности, попробуйте радио-модули с модемом по технологии LoRaWAN. Выглядит обещающе, у меня это в ближайших планах, как время позволит.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
попробуйте радио-модули с модемом по технологии LoRaWAN. Выглядит обещающе, у меня это в ближайших планах, как время позволит.
Не знаю.. пока не думал)) Вообще есть Wi-Fi ...)) Надо изучить подробней... куда это использовать.
Ещё пару тестов nRF24L01+))
4- тест на количество ошибок. Важный момент, потому что для нашего кораблика - недопустимы ложные срабатывания !!!
В самодельном радиомодуле можно посмотреть сигнал на выходе детектора и посмотреть работу дешифратора во всех подробностях)) : отпеределить точно количество и характер ошибок, и даже точно определить источник помех и ошибок. Например вот наш самодельный радиомодуль принял сигнал автосигнализации... Можно посмотреть как на него реагирует наш дешифратор... Во всех подробностях))
Как реагирует nRF24L01+ на помехи.. можно только догадываться))
Для того что бы лучше разобраться в работе заводских радиомодулей, мы собрали самодельный, с таким же алгоритмом как в зоводском)) Теперь можно сравнить их работу...))
Наш самодельный модуль работает по стандартному алгоритму: 1- приёмник синхронизируется по преамбуле. 2- затем приёмник ищет синхрослово. 3- если синхрослово совпадает, то приёмник переходит к записи данных в буфер FIFO.
Есть один важный момент: количество ошибок (или проще говоря - вероятность ложных срабатываний) зависит от уровня сигнала (точнее отношение сигнал/шум). Причем, что любопытно, зависимость эта нелинейная. По результатам тестов я тут накидал "на глаз" график зависимости ошибот от уровня сигнала. Получилось так:
Почему зависимость нелинейная? Да очень просто..)) На графике циферками подписал:
1- в первом случае сигнал хороший (отношение сигнал/шум большое), поэтому приёмник четко синхронизируется, чётко находит синхрослово и записывает в буфер все данные без ошибок. Вероятность ошибки крайне мала.
2- во втором случае сигнал слабый (отношение сигнал/шум меньше). Приёмник по прежнему синхронизируется и находит синхрослово, но данные уже содержат ошибки... Возможны ложные срабатывания, причём с высокой вероятностью.
3- в третьем случае (отношение сигнал/шум низкое). Приёмник не может синхронизироваться, а если и может то не может найти синхрослово. В этом случае приёмник ничего не записывает в буфер. Именно поэтому вероятность ложных срабатываний ниже.
4- если вообще выключить передатчик, то приёмник вообще не сможет синхронизироваться... Поэтому вероятность ложных срабатываний при выключенном передатчике крайне мала.
При тестировании самодельного радиомодуля я устанавливаю такой уровень сигнала, при котором количество ошибок на выходе дешифратора максимальное. Именно в таком режиме я тестирую все свои самодельные радиомодули. При этом добиваюсь максимальной надёжности схемы радиоуправления.
Теперь сравним с заводским радиомодулем nRF24L01+)) У nRF24L01+ есть два основных режима: 1- можно включить так называемый "расширенный" режим с контролем пакетов.
Для тестов отключим этот "расширенный" режим )) Это позволит нам включать/отключать проверку контрольной суммы (CRC8 или CRC16). Именно это нам и надо для тестов))
Отключам проверку контрольной суммы в nRF24L01+ (CRC8 или CRC16) и сравним его работу с самодельным модулем...
1-Включаем первый nRF24L01+ в режим TX, а второй nRF24L01+ в режим RX. Побежали пакеты... ))) Ложных пакетов нет.
2- Относим подальше второй nRF24L01+ в режим RX... Пошла потеря пакетов... )) Во... !!! начали проскакивать ложные пакеты ! Все точно так же, как в нашем самодельном модуле... Максимальное количество ложных пакетов надлюдается при определённом уровне сигнала (примерно когда теряется половина пакетов).
3- Относим ёще дальше второй nRF24L01+ в режим RX... ложные пакеты стали проскакивать намного реже... Точно так же как в нашем самодельном модуле))
4- Ну и последнее... Выключаем первый nRF24L01+ в режиме TX ... и ждём))) Через некоторое время второй nRF24L01+ в режим RX... принял пакет... Что за пакет он принял ? ))) первый nRF24L01+ в режиме TX выключен !!! Поймали помеху... Ну вот... Получили ложное срабатывание от помехи... Всё ясно. ))
Вывод: Если кратко, то вот:
1- Самое опасное для радиомодуля nRF24L01+ , это когда он работает в зоне неуверенного приёма. При этом наблюдается максимальное количество ложных пакетов. Если хотим сделать действительно надёжную систему передачи данных, то об этом нужно помнить. 2- Использовать радиомодуль nRF24L01+ без проверки контрольной суммы (CRC8 или CRC16) не рекомендую. 3- Контрольную сумму рекомендую выбирать максимально возможную. Для nRF24L01+ это CRC16.
P.S. Для теста самодельных модулей использовал тестовую программку... Почти сутки радиомодули работали в тестовом режиме... Передано... миллионы пакетов...)) Программка вылавливала ложные пакеты (т.е. пакеты с ошибками) при слабом сигнале (т.е. при максимальном количестве ошибок). -При использовании CRC8 программка выловила несколько ложных пакетов... Детальный анализ показал, что причина была в срыве синхронизации... и CRC8 не смог их распознать и отбросить... -При использовании CRC16 программка не выловила ни одного ложного пакета... Все ложные пакеты (пакеты с ошибками) программка отбросила...)) -При передачи больших файлов я бы ещё рекомендовал передавать в конце CRC32. Так же как в протоколе TCP/IP. На всякий случай)))
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
В TCP и IPv4 хедерах используются 16-битные CRC. У NRF-ки весьма простой PM (packet manager). Посмотрите для сравнения на структуру пакета у силабовской серии EZrado PRO. Там в пакете может быть несколько полей, каждое со своими CRC, автоматически вычисляемыми и проверяемыми.
Точно)) Справочник написал: 16-битовое значение контрольной суммы, вычисляемой для 16-битовых слов заголовка и текста... CRC32 - обычно для проверки файлов... Но можем использовать и для передачи по радио...)) Вообщем смысл ясен.))
Ser60 писал(а):
Посмотрите для сравнения на структуру пакета у силабовской серии EZrado PRO.
Без усилителя по дому пробивает максимум два этажа...))
Без усилителя на открытой местности: 1 - передатчик - высота 10 метров. 2 - приёмник - высота 1 метр. 3 - частоту установил 2.512 Мгц (подальше от всяких Wi-Fi 2.400-2.483,5 Мгц)
Дальность... измерить точно трудно... диапазон крайне нестабильный... )) Да и абсолютно чистого места у меня нет... Простое дерево на пути сигнала глушит так, что связь уменьшается до ~100 метров. Нужно абсолютно открытое место...
- до ~250 метро связь стабильная. Практически без потерь пакетов... Прямая видимость.
- дальше... сигнал то появляется, то пропадает... Прямая видимость. Только одиноко стоящие деревья... Неужели рядом стоящие деревья так сильно влияют))
...пропал... - 380 метров - сигнал есть. Почти без потерь пакетов... Прямая видимость. ...пропал... - 450 метров - сигнал ещё пробивается... потери пакетов... Прямая видимость. ... пропал... - 570 метров - сигнал ещё пробивается... потери пакетов... Прямая видимость. ... пропал... - 600 метров - сигнала нет. Полная потеря пакетов. Только один пакет случайно пробил отметку в 600 метров)) Чисто случайно ))
Всё. Дальше нужен усилитель))
Вообщем, реально без усилителя nRF24L01+ добивает до 250...300 метров по прямой нормально.
В принципе можно добиться связи до 500 метров без усилителя, если поднять повыше передатчик и приёмник и точно направить антенны (передатчик >> приёмник). Вообщем нужны идеальные условия... )) Или попробовать поставить направленную антенну... Хотя бы рефлектор)))
Собственно я большего и не ждал... учитывая что чувствительность приёмника максимум 4.46 мкВ, а мощность передатчика максимум 2,5 mW... , то 250...300 метров это нормально))
Кстати... простые модули (см. выше) работают в два раза дальше)) Но зато у nRF24L01+ скорость в 100 раз выше))
Ser60 писал(а):
попробуйте радио-модули с модемом по технологии LoRaWAN. Выглядит обещающе, у меня это в ближайших планах, как время позволит.
Посколько ими можно легко добится плохой сигнал то я восползовался етим и провел следующий експеримент.
Цель експеримента - добътся стабилной работъ радиотракта при плохом качестве связи.
Для цели: Поставил передатчика так, чтоб бъло отчетливо видно, слъшно, пропадание связи. Для цели на стороне декодера поставил звуковую сигнализацию (модуль из поющих карточек - ДжингоБел мне уже надоел) - очень хорошо на слух долавливается плохое качество работъ.
В качестве "железо" стандартнъй приемник-передатчик FS1000A и МК-34 (ила как там его) на 433
Без доработки бъли пропуски и зависания на въходе декодера, что говорить о его плохой работъ. Интересно, что на 27MHz токого не наблюдал ни разу. Явно что сверхрегенератор -
Доработка заключается в програмной резлизации (на стороне декодера) мажоритарной логики (2 из 3) на въходе, анализ "качество" сигнала при определение СИ и слежка за пропадание сигнала в процессе приема пакета.
Я попътался изобразить визуално идею.
В программе сохраняются два последних принятъх пакета (-1 и -2). Есть несколько режима работъ: 1. Принятъй пакет соответствует старъх - все в порядке 2. Принятъй пакет не соответствует старъх - мъ все еще не знаем - ето ошибка тракта или ето новъй пакет. Принимаем (2 из 3) что старъй пакет ето верно. Новъй (пока) игнорируем, но сохраняем 4. Смена командъ. Мъ получили два пакета с одинаковъм содержанием и (разумеется) принимаем его за вернъм
3. Здесь оказъвается что -1 ето "ошибка" Мъ ее игнорируме.
Другие проверки - анализ "качество" сигнала при определение СИ и слежка за пропадание сигнала в процессе приема пакета - применимъ только к моим методом кодировки согнала и их коментировать не буду, но они приносят к повъшение "достоверности" въхода
В опътной постановке (в декодере) сделал оба варианта работъ: по новой версии и по старой. Управляются кнопкой. В резултате: Заметное улучшение "достоверности" сигнала.
В заключение: Для радиолюбителской системъ ДУ путь в усложнение протокола - мое мнение - не является вернъм. Я могу позволить себе пропуска одного пакета, потому что у меня пакет идет меньше чем за 16mS. Я делаю анализ пакета и могу (в процессе приема) въдать (на въходе) верного пакета - т.е. без всяких CRC, у меня проверка достоверности и коректировка грешного пакета. Я делаю проверку качество пакета (его достоверности) в процессе приема пакета (за несколько машиннъх инструкции).
_________________ Лом - ето город в Болгарии, а не инструмент юстировки електроники.
Выше уже делали радиоуправление с повтором пакетов каманд для надёжности. Для надёжности передавали три пакета на команду (два повтора оказалось мало). От этой идеи отказались. Теперь используем только контрольную сумму (CRC).
-При передачи повторных пакетов увеличивается длина пакета и соответственно уменьшается скорость передачи.
-При использовании контрольной суммы (CRC), длина пакета меньше и соответственно увеличивается скорость передачи. Или можно оставить прежнюю скорость передачи и уменьшить полосу пропускания приёмника - это более эффективный метод борьбы с помехами.
Были идеи использовать протоколы исправления ошибок, но это опять же увеличит длину пакета и соответственно уменьшит скорость передачи. Тоже отказались...
Для радиолюбительских схем можно использовать и заводские технологии (со своими поправками, под свои задачи). Заводских технологий много)) Думаю это верное направление.
При передачи повторных пакетов увеличивается длина пакета и соответственно уменьшается скорость передачи
Я пакетов не повторяю. Кодер всегда передает непреръвно во времени пакетъ. Один за другим. Если не подана другая команда то ето является повтор, но ето полноправнъй пакет информации. Пакет всегда одинаковой длинъ. и т.д.
roman.com писал(а):
использовании контрольной суммы (CRC), длина пакета меньше
Вот и озвучтье длину пакета. Если в пакете 8 (восем) дискретнъх команд то в самъй тяжелъй случай у меня меньше 16mS (ето с СИ, паузой и 8 команд - весь пакет). А у вас сколько? С преамбулой, Синх, Дата, CRC и т.д. А для 8 команд? Интересно будеть, сколько
roman.com писал(а):
протоколы исправления ошибок
Код:
movf out,w xorwf OutBuf,w ;проверка дали информацията е същата като предишната btfsc STATUS,Z ;същата ли е? = 0 goto to_b ;същата e => извеждане movf out,w xorwf OutBuf+1,w ;проверка дали информацията е същата като по предишната btfss STATUS,Z ;същата ли е? = 0 goto skip_buff_to_b ;не е същата => пропускане .... ShiftOutBuff movlw 8 movwf Sftcnt ShiftOutBuff_loop bcf STATUS,C rrf OutBuf,f rrf OutBuf+1,f rrf OutBuf+2,f decfsz Sftcnt goto ShiftOutBuff_loop return
Ето все необходимое для корекции. Длина пакета все такая.
roman.com писал(а):
Для радиолюбительских схем можно использовать и заводские технологии
Конечно можно. Скорость передачи того-же nRF24L01+ 2MBit/s, а у нас сколько? Я не расскулачивал промъшленное ДУ, но у меня подозрение, что там не сидит 8 битовъй МК с тактовую частоту 1MHz. Вот когда я поставлю МК с тактувую 40MHz и радио тракт с полосу пропускания 2MB/s я не буду обдумъвать протокола передачи, а буду гнать все что мне задумается.
Так, что я на другое мнение. Если у нас слабъй радио тракт и слабъй МК, то остается обдумавать другие возможности.
Но, как всегда, у нас коренно разнъе мнения.
_________________ Лом - ето город в Болгарии, а не инструмент юстировки електроники.
Без доработки бъли пропуски и зависания на въходе декодера, что говорить о его плохой работъ. Интересно, что на 27MHz токого не наблюдал ни разу. Явно что сверхрегенератор
Дело не в сверхрегенераторе, а в настройке.
Супергетеродин или сверхрегенератор... 27 Мгц или 433 Мгц ... У всех приёмников сигнал на выходе одинаковый. Поэтому нет никакой разницы, какой радиоканал.
botchin писал(а):
Я попътался изобразить визуално идею. В программе сохраняются два последних принятъх пакета (-1 и -2). Есть несколько режима работъ: 1. Принятъй пакет соответствует старъх - все в порядке 2. Принятъй пакет не соответствует старъх - мъ все еще не знаем - ето ошибка тракта или ето новъй пакет. Принимаем (2 из 3) что старъй пакет ето верно. Новъй (пока) игнорируем, но сохраняем 4. Смена командъ. Мъ получили два пакета с одинаковъм содержанием и (разумеется) принимаем его за вернъм 3. Здесь оказъвается что -1 ето "ошибка" Мъ ее игнорируме.
Проблема Пункт 2:
botchin писал(а):
2. Принятъй пакет не соответствует старъх - мъ все еще не знаем - ето ошибка тракта или ето новъй пакет. Принимаем (2 из 3) что старъй пакет ето верно. Новъй (пока) игнорируем, но сохраняем
В этом вся проблема: нужно ждать подтверждения. Выше уже так делали... Мне не нравится этот метод.
Бывают случаи, когда мы не можем ждать подтверждения (задержки критичны)... Или бывают случаи, что пакет подтверждения никогда не придёт)) Всякое бывает при слабом сигнале))
с CRC всё проще: пришёл пакет, проверили CRC: 1-если CRC совпадает, то немедленно приняли к исполнению, не дожидаясь подтверждения. 2-если CRC не совпадает, то просто сидим и ждём следующий пакет. Так более надёжно (я так думаю). Никаких пакетов подтверждения.
Пакет всегда одинаковой длины - это хорошо. Так проще его выловить))
nRF24L01+ максимальная скорость = 2MBit/s. Минимальная скорость 250 кБит/c. Но даже минимальной скорости много для простого радиоуправления. надо ещё меньше... но нет. Жаль)))
а у нас сколько? Если у нас слабъй радио тракт. Для обычного радиоканала: -Простой супергетеродин 27 Мгц обычно полоса до 3 кГц. -Для сверхрегенератора FS1000A 433 примерно столько же: до 3 кГц. (если ничего не перепаивать в схеме).
МК у нас не слабый)) 8 битный, с частотой 16 МГц. (можно в 1,5 раза больше, но даташит не рекомендует) ))).
1-Если в пакете 8 (восем) дискретнъх команд, то...
27 Мгц или 433 Мгц ... У всех приёмников сигнал на выходе одинаковый
Спорить не буду. На 27 у меня отношение сигнал/шум (LA1186+TA7640) 60dB+60dB - по памяти из документациях, а здесь шумит как на паравозе.
roman.com писал(а):
нужно ждать подтверждения
Ничего не нужно ждать. Если пакет принят, то ето означает (по моей кодировке), что уже принять СИ следующего, нового пакета. Т.е. у нас запаздъвание точно в один пакет (менее 16mS). Но зато достоверност информации - . Если сигнал пропал то у меня включается следующая "защита" - если за время 4*4mS (4mS - чуть более длину СИ) не будет сигнала - программа решает. что сигнал пропал. Кстати, ето у меня сейчась висит на преръвание и всегда работает - т.е. время реакции на пропадание сигнала 16mS - мог бъ сделать и 4mS, но ето думаю - уже чересчур.
(LA1186+TA7640) 60dB+60dB - по памяти из документациях, а здесь шумит как на паравозе.
Всё зависит от конкретной схемы... В схеме есть ещё УВЧ +dB и УПЧ +dB. Поэтому общее усиление приёмника +dB может быть разное. Все нормальные приёмники с ЧМ шумят как паровоз))
botchin писал(а):
у нас запаздъвание точно в один пакет (менее 16mS). Но зато достоверност информации
Это хорошо, если мы принимаем все или большую часть пакетов подряд...
1,2,3,4,5,6,7,8,9,... - пакеты
А что будет, если сигнал очень слабый? Большая часть пакетов потерялась...
Вопрос 1 - задержка ?
1,..,..,..,5,..,..,..,9,... - принятые пакеты
Какая будет задержка? )))
При использовании CRC задержки нет. Т.к. для CRC не нужны пакеты подтверждения))
Вопрос 2 - подтверждение ?
1,..,..,..,5,..,..,..,9,... - принятые пакеты
А что если все принятые пакеты 1,5,9 - это разные команды? Тогда подтверждения мы никогда не получим. Схема работать не сможет.
При использовании CRC пакеты подтверждения не нужны. Поэтому и в этом случае схема с CRC работает нормально.)) ----------
Если сигнал пропал, то у меня включается следующая "защита" - если за время 1 секунда не будет сигнала - программа решает, что сигнал пропал. Время задаётся таймером.
Так же есть дополнительная функция (пока не используется): счётчик пакетов. Все пакеты у меня идут под номерами. 0...255.
0,1,2,3...255 - номер пакета.
Приёмник знает, сколько принято пакетов и сколько потерянно пакетов:
У меня скорее так (за каждой циферки пакет) 1,1,1,1,1,2,2,2,1,1,1 Здесь скажем за 1 не нажата кнопка, за 2 нажата какая-то кнопка. Пакетъ всегда идут один за другим. Я принимаю СИ следующего пакета как потверждение верности принятой информацией. Т.е. в процессе приема я уже знаю даннъе у меня валиднъе или нет. На границе перехода 1->2 (2->1) будет задержка в один пакет пока информация поступит на въходе - из за "2 из 3". Ситуация как 1,1,1 . . . . 1,1 для меня является потеря сигнала. Все начинается сначала с поиском СИ. Что и думаю нормально. Все ето мъ обдумавалъ и пришли (с отцом) к въводу, что самое верное решение, ето не допускать потеря сигнала. Разумеется есть и другие решения - автопилот (и ето обдумавалъ) потом решили, что не стоит.
roman.com писал(а):
А что если все принятые пакеты 1,5,9 - это разные команды?
Я бъ хотел посмотрет на оператора нажимающии на клавишу с честотой 62Hz. и въше
roman.com писал(а):
При использовании CRC пакеты подтверждения не нужны.
Во всяком случае явление как то, что въ описали - передатчик въключен, а приемник принял команду, я не наблюдал.
_________________ Лом - ето город в Болгарии, а не инструмент юстировки електроники.
Так я же специально отключал CRC, чтобы проверить Дешифратор во всех режимах... как он реагирует на помехи.)) Да, при отключенном CRC, есть вероятность ложного срабатывания при выключенном передатчике. Несколько ложных пакетов Дешифратор зафиксировал от шума приёмника...
Если подумать, то можно отключить преамбулу... а синхронизацию брать из общего потока битов. Такая функция есть в заводском радиомодуле... выше писали. Можно выкинуть паузу... она нажна приёмнику для обработки сигнала. Можно оптимизоровать время обработки...))
Короче, можно сильно всё ужать... до предела)) Выкин 11110000 - 8 бит - синхро + 0101010101010101 - 16 бит - кнопки + 01010101010101010101010101010101 - 32 бит - crc = 56 бит.
Итого: манчестер ( 3 kHz, 9 mc, 107 пак/c ); ...
Можно использовать CRC-8, вместо CRC-16... Правда не рекомендуется)) Всё таки нужен запас надёжности от помех... 11110000 - 8 бит - синхро + 0101010101010101 - 16 бит - кнопки + 0101010101010101 - 16 бит - crc-8 = 40 бит.
Это минимально возможная длина пакета... В принципе можно сделать, если подумать...
Хотя нет)) Дело в том, что CRC изначально нужно для проверки больших объёмов данных... а если надо передать 8 кнопок, то можно выкинуть CRC... 11110000 - 8 бит - синхро + 0101010101010101 - 16 бит - кнопки = 24 бит.
Итого: манчестер ( 3 kHz, 4 mc, 250 пак/c );
Закрутим "гайки" цифрового фильтра)) Надёжность в данном случае обеспечит цифровой фильтр, который будет пропускать импульсы только определённой длительности (с минимальным допуском). Схема может работать только при сильном сигнале... но зато очень быстро)))
Но и это ещё не всё...)) Если надо ещё быстрей, то можно использовать уплотнение... Например вместо модуляции FSK-2, использовать FSK-4. Тут её назвали DFSK-модуляция - http://vrtp.ru/index.php?act=Attach&id=589159&type=post Скорость удвоиться)) Итого: FSK-4 ( 3 kHz, 2 mc, 500 пак/c );
Я вас спрашивал. Какая у вас скорость передачи на самой простой случай - 8 дискретнъх комманд (8 кнопок) Посколько внятного ответа я так и не прочитал, то я позволил покопатся в твоего кода. Последние программъ для be8708
Код:
PORTB.1= btx & (1<<a) ? 1 : 0; // PORTB.1=0; // выход Data TX delay_us(485); PORTB.1= ~PORTB.1; delay_us(485);
Ето фрагмент кода с кодера. Въходить, что для передачи одного бита программе нужно время 1mS. Если посчитать для 96 битов (длина пакета 8 кнопок) - 96mS, или чуть въше 10 пакетов в секунду.
Если посчитать и другой параметр - заполнение пакета полезной информацией (96 бит-8 бит) то получается что у вас "КПД" пакета 8,33%. Т.е. 92% пакета идет на ......??? Как с етим дела у меня. Длина пакета (самъй тяжелъй/лекгий случай) 15,74mS/11.62mS Длина СИ 3,264mS. "КПД" 79/82%.
Я не понимаю, правда, не понимаю. В погоню за "как в заводских модулях" и "у нас манчестер" дойти до 8% полезности!!!!????
Частота импульсов - 1 kHz, Длительность пакета - 56 mc, Скорость передачи - 18 пакеков в секунду.
botchin писал(а):
Последние программъ для be8708
Код:
PORTB.1= btx & (1<<a) ? 1 : 0; // PORTB.1=0; // выход Data TX delay_us(485); PORTB.1= ~PORTB.1; delay_us(485);
Ето фрагмент кода с кодера. Въходить, что для передачи одного бита программе нужно время 1mS. Если посчитать для 96 битов (длина пакета 8 кнопок) - 96mS, или чуть въше 10 пакетов в секунду.
В последней программе для be8708, кроме 8 кнопок, есть ещё: ШИМ 1 + ШИМ 2 + счётчик пакетов. Итого: длина пакета 144 бит, из них 32 бит полезной нагрузки. Cкорость для be8708 получается:
Частота импульсов - 1 kHz, Длительность пакета - 72 мс Скорость передачи - 14 пакетов в секунду.
Если посчитать и другой параметр - заполнение пакета полезной информацией (144 бит - 32 бит) то получается что у нас "КПД" пакета 22,2%. Т.е. 77,7% пакета идет на - "служебная информация". )))
В погоню за "как в заводских модулях" и "у нас манчестер" дойшли до 22,2% "полезности". ))
И самое главное: В погоню за "как в заводских модулях" мы получили универсальный протокол передачи, под любые задачи.
Для радиоуправления моделями, нам надо кроме кнопок передавать ещё много другой информации: Управление двигателями и cервами (ШИМ), данные напряжения аккумуляторов и различных датчиков (телеметрия), и т.д. и т.п. Для этого лучше всего подходит заводские протоколы. Всё передаём одним пакетом и без ошибок. Для контроля БОЛЬШИХ объёмов данных лучше всего подходит CRC.
"КПД" пакета зависит от объёма передаваемых данных (длины пакета). Чем больше длина пакета, тем больше "КПД" пакета.)) Например максимальная полезная нагрузка для пакета nRF24L01+ 256 бит. Можно посчитать "КПД" пакета, если будем передавать 256 бит.))
Заполнение пакета полезной информацией (328 бит - 256 бит) то получается что у нас "КПД" пакета 78,0%. Т.е. 22,0% пакета идет на - "служебная информация". )))
Нормально)) Можем сделать "КПД" пакета ещё больше )))
Последний раз редактировалось roman.com Пн окт 10, 2016 13:21:27, всего редактировалось 1 раз.
Сейчас этот форум просматривают: Google [Bot], valshev и гости: 31
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
. Если сигнал пропал то у меня включается следующая "защита" - если за время 4*4mS (4mS - чуть более длину СИ) не будет сигнала - программа решает. что сигнал пропал. Кстати, ето у меня сейчась висит на преръвание и всегда работает - т.е. время реакции на пропадание сигнала 16mS - мог бъ сделать и 4mS, но ето думаю - уже чересчур.
