У меня в каждом из модулей GPS-Glonass модули стоят, которые дают эталонное время. Поэтому временные задержки на передачу каналов тут можно и не учитывать.
ну тогда воообще нет проблем)) берите любые модули.
Anton.M писал(а):
как насчет однонаправленности связи?
какой однонаправленности? nrf24L01+ это трансиверы.
Anton.M писал(а):
увы похоже не подойдут....
почему? зависит от дальности. Простые модули без усилителя работают максимум ~400 метров (при условии точной направленности).
Карма: 38
Рейтинг сообщений: 618
Зарегистрирован: Пн апр 06, 2015 11:01:53 Сообщений: 3092 Откуда: москва, уфа
Рейтинг сообщения:0
хочу сочинить из nrf-ок сеть а-ля шина с мастером и кучей слейвов, конкретно - для подцепления разномастных датчиков по modbus-у. С самим модбасом более-менее разгребся, теперь рисую архитектуру беспроводной части. В общих чертах: не хочу сильно заморачиваться с самостоятельным контролем передачи на физическом уровне, и предполагаю использовать ShockBurst. Шести адресов на канал мало, плюс у каждого устройства будет еще и modbus-адрес. Тако же modbus ADU в общем случае не влезет в максимальные 32 байта payload-а, которые допускает ShockBurst, и его придется крошить. Пока вырисовывается такая схема передачи одного ADU: -1) мастер PTX, слейвы PRX 0) мастер получает от клиента ADU по rs485 1) все слейвы слушают один и тот же RX_ADDR, на всех отключен Auto ACK. 2) мастер посылает в эфир пакет c payload-ом вида "modbus-адрес abc прими n байт ADU" 3) все слейвы получают пакет, проверяют адрес. Слейв с совпадающим адресом включает Auto ACK (или нет, если нужного адреса нет в сети вообще или он висит на проводе rs485). 4) мастер, не получив ACK, передает пакет еще раз. На этот раз получает его от слейва с совпадающим modbus-адресом (или нет, тогда через несколько повторов процедура заканчивается). 5) мастер передает покромсанный на куски ADU, слейвы его принимают и собирают. 6) мастер передает "тчк". Получает на него ACK, переключается в режим PRX со включеным Auto ACK. 7) слейвы анализируют ADU обычным для модбаса образом - т.е. все, кроме одного, его игнорируют ввиду несовпадения modbus-адресов. 8 ) нужный слейв крутит шестеренками, обрабатывает PDU, переключается в PTX. 9) от бывшего слейва к бывшему мастеру передается цепочка "прими n байт ADU" - покромсанный ADU ответа - "тчк". 10) мастер собирает ADU, снова переходит в PTX, слейв - так же обратно в PRX с выключенным auto ACK. 11) мастер отсылает клиенту ADU по rs485.
если нужно передать ADU с broadcast адресом в понимании модбаса, просто на мастере отключаем auto ACK и передаем все подряд, как-нибудь там примут (или нет). Такое поведение (отсутствие ответов на broadcast ADU и негарантированная их доставка) вполне соответствует спецификации.
есть какие-то фатальные недостатки в этой схеме, из-за которых она не будет работать?
не хочу сильно заморачиваться с самостоятельным контролем передачи на физическом уровне, и предполагаю использовать ShockBurst.
Ну и зря)) ShockBurst (с Auto ACK) гарантирует доставку пакетов только между двумя nrf24L01+ <> nrf24L01+, но он не гарантирует доставку пакетов между двумя конечными устройствами: МК---nrf24L01+ <> nrf24L01+---МК.
arkhnchul писал(а):
1) все слейвы слушают один и тот же RX_ADDR, на всех отключен Auto ACK.
Не обязательно всем слейвам слушать один и тот же RX_ADDR. Мастер может обратится к любому слейву напрямую, по адресу радиомодуля nrf24L01+.
arkhnchul писал(а):
Слейв с совпадающим адресом включает Auto ACK (или нет, если нужного адреса нет в сети вообще или он висит на проводе rs485).
Если верить даташиту, то перед началом передачи пакетов, все радиомодули nrf24L01+ должны быть настроены в одинаковый режим: -в режим с включенным ShockBurst (с Auto ACK) -или в режим с выклюенным ShockBurst (с Auto ACK). Радиомодуль не может "на ходу" включать/выключать режим ShockBurst (с Auto ACK). В этом случае мастер не получит ACK. Да и нафиг он вообще нужен.. этот ShockBurst (с Auto ACK).. Лично я им вообще не пользуюсь, так не вижу в нем практической пользы.))
ShockBurst (с Auto ACK) гарантирует доставку пакетов только между двумя nrf24L01+ <> nrf24L01+, но он не гарантирует доставку пакетов между двумя конечными устройствами: МК---nrf24L01+ <> nrf24L01+---МК.
вот этого не понял. Что случится с данными при передаче МК--nrf по SPI?
Радиомодуль не может "на ходу" включать/выключать режим ShockBurst (с Auto ACK).
я не нашел там прямого запрета на таковое действие. В крайнем случае, можно и переинициализировать модуль вообще с нуля, отключая питание, тайминги вроде как позволяют.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Что случится с данными при передаче МК--nrf по SPI?
Всё что угодно..)) Перечислять можно долго.. начиная от плохого контакта и помех по шлейфу SPI... ))
arkhnchul писал(а):
я не нашел там прямого запрета на таковое действие. В крайнем случае, можно и переинициализировать модуль вообще с нуля, отключая питание, тайминги вроде как позволяют.
PRX получил пакет и атоматом отправил ACK. А если ShockBurst (с Auto ACK) отключить... то PRX атоматом ACK не отправит. Не пробовал)) Но помоему логика nrf24L01+ не позволит отправить "в ручную" ACK, после того как пакет уже принят и обработан.
В крайнем случае, можно и переинициализировать модуль вообще с нуля, отключая питание, тайминги вроде как позволяют.
при отключении питания все регистры nrf24L01+ сбрасываются (переходим на заводские настройки) и вся информация теряется.
И вообще мне не нравится ShockBurst (с Auto ACK)... Отправлять по одному пакету и сидеть ждать ACK после каждого пакета... В нормальных протоколах так не делают)) Например Modbus TCP - http://www.cta.ru/cms/f/435973.pdf
Протокол TCP. Управление потоком. - http://kunegin.com/ref1/net_prot/tcpprot.htm Для ускорения и оптимизации процесса передачи больших объемов данных протокол TCP определяет метод управления потоком, называемый методом скользящего окна, который позволяет отправителю посылать очередной сегмент, не дожидаясь подтверждения о получении в пункте назначения предшествующего сегмента.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Но помоему логика nrf24L01+ не позволит отправить "в ручную" ACK, после того как пакет уже принят и обработан.
не, идея не в том, чтобы отправить ACK руками, а в том, чтобы оно отправило его автоматом на второй (или третий-четвертый-пятый) переотправленный пакет, который пришлет PTX, не получив ACK на первый) судя по даташиту, на packet id, по которому оно определяет чего это за пакет, не должно влиять чтение содержимого из буфера.
отправило его автоматом на второй (или третий-четвертый-пятый) переотправленный пакет, который пришлет PTX, не получив ACK на первый)
ну можно и так. Тогда на первый отправленный пакет PTX не получит ACK. А начиная со второго и далее... получит ACK)).
arkhnchul писал(а):
на packet id, по которому оно определяет чего это за пакет, не должно влиять чтение содержимого из буфера.
Тогда наверное лучше чтобы первый пакет PTX отправил с установленным флагом NO_ACK в поле "PacketControl Field". В этом случае ни один из слейвов ACK не отправит.
из даташита: Функция выборочного автоматического подтверждения - флаг NO_ACK. Установка флага - пакет не должен быть автоматически подтвержден. На PTX вы можете установить флаг NO_ACK в поле управления пакетами "PacketControl Field" с помощью этой команды:W_TX_PAYLOAD_NOACK. Однако сначала функцию необходимо включить в регистре FEATURE, установив бит EN_DYN_ACK. Когда вы используете эту опцию, PTX переходит непосредственно в режим ожидания-I после передачи пакета. PRX не передает пакет ACK при получении пакета.
А начиная со второго пакета и далее... в PTX сбросим флаг NO_ACK в поле "PacketControl Field". В этом случае от всех слейвов, в которых включена функция ShockBurst (с Auto ACK) будет получен ACK. Значит, после получения первого пакета от мастер, на всех слейвах кроме одного одолжна быть отключена фенкция ShockBurst (с Auto ACK) ... надо уточнить, можно ли отключить Auto ACK в слейве с помощью регистра/флага.
Блин.. чтото слишком много телодвижений)) Включать отключать... устанавливать/сбрасывать флаги... Помоему проще вообще отключить режим ShockBurst (с Auto ACK) и отправлять ACK "в ручную". Т.е. доверить управление потоком stm8s103... Так будет быстрее и проще)) А главное надёжней)) Не нужно думать что делать в случае потери пакетов и т.д.
Не нужно думать что делать в случае потери пакетов и т.д.
ну как не нужно? как раз рожать систему с квитанциями и переотправками) вообще, в случае чего просто не сойдется контрольная сумма у самого modbus ADU, она там своя. Штатная ситуация по спецификации.
раз рожать систему с квитанциями и переотправками)
Да что там рожать.. )) Куча слейвов... сидят ничего не делают)) А nrf24L01+ слушает эфир... nrf24L01+ принял пакет, сработал IRQ, читаем адрес (кому адресован пакет). Если нам, то закинули свой адрес в TX FIFO и нажали кнопочку "отправить" (CE 1). ACK улетел мастеру)) Всё. Сидим дальше ничего не делаем... )) По количеству операций, не больше чем со всякими переключениями... флагами... auto_ack... ShockBurst... и т.д.))
Хотя для низкой скорости передачи, modbus-овских 19200 бит/с, не вижу разницы как передавать, если использовать буферизацию))
А можно сделать сквозной канал, без гарантии доставки. modbus чувствителный к задержкам... Согласно спецификации у modbus сообщение начинает восприниматься как новое после паузы 14 бит.... Пакет максимум 255 байт. Тогда передаём все 255 байт подряд, с modbus CRC, без всяких ACK, без задержек ..)) Можно только в самом конце отправить ACK, типа весь пакет (255 байт) прошёл..
Вообще с modbus не работаю. Но лично мне нравятся универсальные схемы. А если я завтра захочу заменить радиомодуль на другой, без auto_ack, всё надо будет менять? ))
И вообще... мне не нравится протокол TCP. Лучше UDP. Контроль, доставка, разборка/сборка пакетов, порядок следования пакетов и т.д. всё на уровне приложения. Схема универсальная, не зависит от канала связи... от типа радиомодуля... и т.д. и т.п.))
modbus чувствителный к задержкам... Согласно спецификации у modbus сообщение начинает восприниматься как новое после паузы 14 бит.
это в какой спеке? в modbus RTU - после 3.5 длительностей символа, т.е. 38.5 длительностей бита, или 1750мкс для бодрейтов больше 19200. В modbus ASCII требований нет, новое сообщение начинается с символа ":", заканчивается CR LF. Самому по себе модбасу вообще плевать на тайминги. Спецификация рекомендует иметь какой-нибудь таймаут, чтобы не ждать ответа от зависшей железки весь остаток вечности, и все на этом.
Лучше UDP. Контроль, доставка, разборка/сборка пакетов, порядок следования пакетов и т.д. всё на уровне приложения. Схема универсальная, не зависит от канала связи... от типа радиомодуля... и т.д. и т.п.))
с другой стороны - вот все это нужно велосипедить на уровне каждого приложения.
какой однонаправленности? nrf24L01+ это трансиверы.
Свалился в больницу, выпал совсем из диалога. Имеется ввиду, работает как приемо-передатчик на одном канале (двусторонняя связь)? Или только один приемник, другой передатчик и никак по-другому?
Имеется ввиду, работает как приемо-передатчик на одном канале (двусторонняя связь)?
Это смотря как вы его настроите, он может работать как приёмопередатчик но только в полудуплексном режиме. Причём переключить его нужно будет контроллером сам он переключаться не умеет(за исключением ответа на принятый пакет).
Это смотря как вы его настроите, он может работать как приёмопередатчик но только в полудуплексном режиме. Причём переключить его нужно будет контроллером сам он переключаться не умеет(за исключением ответа на принятый пакет).
Вот этот "ответ" сам по себе интересный для полудуплекса подрежим. Фактически, приняв пакет, приемная сторона может тут же передать свой пакет произвольного (в рамках ограничений ntf24) объема в ответ, не разрывая связи. Эту фишку удобно использовать на неких автономных устройствах, которые никогда не находятся в режиме приема, а только шлют данные. Например, забрасывать данные точного времени для "подводки" часиков на удаленном девайсе.
этот "ответ" сам по себе ничем не интересен, ктоме как передавать ACK (подтверждение и приёме) это "ответ" ничем не интересен.))
a5021 писал(а):
Фактически, приняв пакет, приемная сторона может тут же передать свой пакет произвольного (в рамках ограничений ntf24) объема в ответ, не разрывая связи.
Что значит не разрывая связи? )) А если ntf24 работает под управлением МК... связь разывается? ))
a5021 писал(а):
забрасывать данные точного времени
в автоматическом "ответе" не может быть данных точного времени..)) потому, что.. что бы забросит данные точного времени... например на удалённое устройство... запрашиваемый сначала должен записать данные точного времени в ntf24 и только потом отправить на удалённое устройство. )) этот "ответ" абсолютно бесполезен))
запрашиваемый сначала должен записать данные точного времени в ntf24 и только потом отправить на удалённое устройство. )) этот "ответ" абсолютно бесполезен))
А в чём проблема заблаговременно "записать данные точного времени в ntf24"?
Кто подскажет как наиболее правильно организовать связь с нулевой потерей данных. Потеря байтов не допустима, как организовать передачу байта в один конец до тех пор пока он не передастся? У меня при плохой связи теряются байты, а потом некоторые уже всплывают из буфера(не могу понять пока из какого) примерно так: 1234567890 ........ где то потерялось пару байт ........ 8901234567
Один из вариантов: Отключить все заводские настройки (всякие автоматические АСК) и передать всё управление МК. МК точно знает: сколько пакетов отправлено, сколько получено, сколько (и какие именно) пакеты требуют повторой передачи... В этом режиме nrf24L01+ работает "прозрачно".
если все отключить, то тогда не узнать передался байт или нет. после каждой отправки байта проверять TX_DS и MAX_RT в статусе, если TX_DS=1 то байт улетел, если MAX_RT=1 то повторить передачу. IRQ при любом исходе же сработает?
Код:
//отправка байта по воздуху void send_byte(uint8_t data)//отправка байта. { w_register(W_TX_PAYLOAD,data);//запись байта в буфер TX для отправки ptx();//передача байта while (BitIsSet(PIND,IRQ));//Ждем пока байт не передан uint8_t temp_status = r_register(STATUS);//прочитали статус регистр if (BitIsSet(temp_status,TX_DS)&&BitIsClear(temp_status,MAX_RT)) { w_register(STATUS, temp_status);//сброс флагов прерываний } else { if (BitIsSet(temp_status,MAX_RT)&&BitIsClear(temp_status,TX_DS)) { w_register(STATUS, temp_status);//сброс флагов прерываний Erase_TX(); Out_TX_return();//выбор предыдущего OUT_TX--; байта из буфера send_byte(buff_TX[OUT_TX++]); } } }
теперь при плохой связи появляются лишние байты на 2000 переданных байта от 3 до 20 байт лишние(((
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 20
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
