Перейти к содержанию
    

На чем организовать радиосвязь?

Встала задача организовать цифровую радиосвязь точка-точка со следующими вводными:

- связь проходит сеансами, продолжительность одного сеанса не более 5 сек;

- за сеанс нужно передать примерно 50кБ данных (в одну сторону) и подтвердить получение;

- расстояние до 50м.

В целом, одна точка (получатель) объезжает другие точки (источники данных) и вопрос, на чем бы такое сделать наиболее простым способом? Скорость, получается, нужна порядка 100 кбит/сек (лучше побольше, чтобы был запас), может существуют готовые китайские модули? Или самому городить, может чип/стандарт тогда посоветуете?

Скорость, в принципе, можно разменять на расстояние - если расстояние 100м, то сеанс может длиться уже 10сек и скорость в два раза ниже. Дело происходит в глуши где людей (и помех), вероятно, нет.   Мобильной связи и интернета тоже нет.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

наиболее простым для точка-точка это взять какие-нибудь модули которые "прозрачным радиоуартом" могут прикидываться.

когда-то очень давно были xbee, может они ещё живые.

и у semtech похожие модули были.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

16 часов назад, sz36 сказал:

. . . . может существуют готовые китайские модули?

. . . . Или самому городить, может чип/стандарт тогда посоветуете?

Посмотрите RFM50W-433-S2 (HopeRF) - из не сильно дорогого. В нем "задекларирован" UART. Правда, как оно работает - ничего сказать не могу. Мы использовали "чистый" трансивер RFM69 с управляющим интерфейсом SPI. Для реализации "моста" c UART нужен любой управляющий контроллер.

На базе WiFi ESP8266 и его родственниками - смотрите "мосты" UART с их использованием.

итд  - модулей очень много и решений тоже, заканчивая ардуинами. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 минут назад, k155la3 сказал:

Мы использовали "чистый" трансивер RFM69 с управляющим интерфейсом SPI. Для реализации "моста" c UART нужен любой управляющий контроллер.

Какой смысл в каких-то "мостах"? Ведь SPI намного удобнее в работе на МК, чем UART. Да и быстрее как правило. И имеется в любом МК.

17 часов назад, sz36 сказал:

может чип/стандарт тогда посоветуете?

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

Из ваших "хотелок" даже не ясно - нужен модуль (как часть какого-то своего девайса) или отдельный блок? Если последнее - гуглите "радиомодем"; если первое - да хоть дешёвый nRF24L01+ + усилитель и нормальная антенна. Или 100500 других модулей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 минуты назад, jcxz сказал:

Какой смысл в каких-то "мостах"? Ведь SPI намного удобнее в работе на МК, чем UART. Да и быстрее как правило. И имеется в любом МК.

Да, несомненно. Дело как раз в контроллере. Он нужен. При использовании "моста" UART можно обойтись без него и написания софта. Но я бы "не искал легких путей" :biggrin:

Цитата

TC >>     на чем бы такое сделать наиболее простым способом? 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

54 минуты назад, k155la3 сказал:

Да, несомненно. Дело как раз в контроллере. Он нужен. При использовании "моста"

Кому нужен? ТС? Так в описании ТС ни "моста" ни UART ни даже какого-то контроллера - ничего нет. "мост" - придумали уже Вы.  :unknw:

54 минуты назад, k155la3 сказал:

UART можно обойтись без него и написания софта. Но я бы "не искал легких путей" :biggrin:

А если "точка" ТС - это контроллер его собственного изготовления, то подключить его на имеющийся уже SPI (если он у него есть) - обычно намного проще, чем найти свободный UART с незанятыми уже ногами.

А в случае если как часто бывает: "уже все ноги заняты" потому что "когда начинали разрабатывать не подумали", то реализовать SPI даже ногодрыгом на более-менее свободных ногах на необходимую скорость 100кб/сек - будет кратно проще, чем сотворить такой же ногодрыжный UART на 100+ кбод. 2-й вариант я даже сказал бы ещё: бабка надвое сказала - получится-ли вообще. Смотря какой МК. А ну как у него STM8?  :cray2:

Вобщем "простым способом" - это, имхо, скорее SPI.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

51 минуту назад, jcxz сказал:

. . . .А если "точка" ТС - это контроллер его собственного изготовления, то подключить его на имеющийся уже SPI (если он у него есть) . . . .

ну, в этом случае ТС сам с легкостью отделит моих UART-"мух" от своих контроллеров-котлет. Я так думаю :buba: :)))))  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 hours ago, jcxz said:

Ведь SPI намного удобнее в работе на МК

Чем же он удобнее? Удобство: понятие субъективное. Но вдруг есть и объективные моменты?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 минут назад, haker_fox сказал:

Чем же он удобнее? Удобство: понятие субъективное. Но вдруг есть и объективные моменты?

Например тем, что:

1) На мастере вы сами определяете моменты передачи/приёма. И нет необходимости синхронизации взаимодействия двух отдельных асинхронных потоков TX/RX.

2) Также реализация совместной работы с DMA - проще. Нет необходимости привлекать дополнительный таймер. Либо ещё каким-то другим образом определять моменты завершения RX-данных.

3) Заведомо готовые средства кадр-ориентированного обмена (CS). Нет необходимости в кодировании: кадры->поток байт, и в обратной операции на приёме. А обмен в прикладных задачах чаще всего бывает кадр-ориентированным.

4) В случае реализации ногодрыжного варианта, даже говорить не приходится, что лучше - SPI vs UART. На слабых МК (или на уже загруженных прикладными задачами) ногодрыжный UART.RX на более-менее высоких скоростях обмена может оказаться вообще не реализуемым практически.

5) При реализации устройства с режимами сна, когда модуль, подключенный по UART/SPI должен оставаться в режиме бодрствования, а МК - спать, то тоже: чтобы добиться хорошего снижения потребления, скорее всего придётся останавливать тактирование UART. А значит - интерфейс с бодрствующим модулем придётся строить с применением сигналов flowcontrol. На SPI это сделать будет проще (он синхронный), к тому-же - частота тактирования потребуется в разы меньше (не забываем что UART требует 16-кратного оверсэмплинга). А значит и потребления с SPI можно добиться меньшего.

6) SPI вообще гораздо гибче в плане установки желаемой скорости тактирования.

7) Если в проекте имеется много разной периферии, то возможность объединения устройств в шину у SPI позволяет сэкономить кучу ног. И не только ног, но и чипов: например довольно дорогих гальванических изоляторов, когда на один изолятор можно повесить гирлянду slave-ов посредством daisy-chaining.

 

... хватит?  :wink:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

30 minutes ago, jcxz said:

И нет необходимости синхронизации взаимодействия двух отдельных асинхронных потоков TX/RX.

В принципе, на базе УСАПП можно то же самое сделать по принципу "мастер/подчинённый" (мастер инициирует передачу и ждёт ответа от подчинённого).

31 minutes ago, jcxz said:

Также реализация совместной работы с DMA - проще.

Согласен!

32 minutes ago, jcxz said:

А обмен в прикладных задачах чаще всего бывает кадр-ориентированным.

Согласен!

32 minutes ago, jcxz said:

В случае реализации ногодрыжного варианта, даже говорить не приходится, что лучше - SPI vs UART.

Да!

32 minutes ago, jcxz said:

При реализации устройства с режимами сна

С такими не работаю, но спасибо за Ваш опыт!

33 minutes ago, jcxz said:

SPI вообще гораздо гибче в плане установки желаемой скорости тактирования.

Согласен: от DC до бесконечности в идеале...

33 minutes ago, jcxz said:

когда на один изолятор можно повесить гирлянду slave-ов посредством daisy-chaining.

Согласен на 50%: то же самое с некоторым геммороем можно сделать и с использованием УАСПП.

34 minutes ago, jcxz said:

... хватит?  :wink:

А есть ещё?) Нет, если есть и Вы можете поделиться, я с удовольствием почитаю! На то это и форум, чтобы делиться опытом)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, jcxz said:

Например тем, что:

это всё так, но есть один нюанс,

у большинства измерительных железок обычно уарт и так уже есть для связи с ПК, 

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

 

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

но тут за ТСа можно что угодно навыдумывать.

 

23 hours ago, sz36 said:

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

Скорость, в принципе, можно разменять на расстояние - если расстояние 100м, то сеанс может длиться уже 10сек и скорость в два раза ниже.

экстраполируя дальше: а если километр, то можно и 5кбит/с, а если 10км, то 0.5кбит/с и можно никуда не ездить вообще?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, haker_fox сказал:

В принципе, на базе УСАПП можно то же самое сделать по принципу "мастер/подчинённый" (мастер инициирует передачу и ждёт ответа от подчинённого).

Какой бы ни был протокол, но в МК UART.TX и UART.RX - это разные события. В принципе независимые друг от друга. Так как интерфейс - асинхронный. А значит в ПО должно быть предусмотрена обработка события "приём" даже тогда, когда по протоколу его не должно быть (во время передачи например). И включая все возможные задержки. И ПО не должно виснуть, если вдруг во время передачи возникнет событие UART.RX. И не должно быть сдвига указателей DMA.RX (если используется DMA) и т.п.

Многие чайники об этом не думают и у них потом глючит в неожиданных местах.

В SPI ничего этого не надо по определению, так как интерфейс синхронный.

 

2 часа назад, haker_fox сказал:

Согласен на 50%: то же самое с некоторым геммороем можно сделать и с использованием УАСПП.

Каким образом? Вот у вас 4 слэйва за гальваническим барьером. Надо их подключить по UART. И топологию "кольцо" они не умеют.

Например: 4 шт. каких-нить AT-командных модуля. Естественно - они не имеют никаких средств адресации для работы на общей шине. Как обойдётесь одним изолятором?

1 час назад, _pv сказал:

у большинства измерительных железок обычно уарт и так уже есть для связи с ПК, 

Мы не знаем что там у ТС-а. Нет смысла гадать.

 

Он там про какие-то "источники данные" толкует. Видимо - собирает некие данные со своих "точек". Наверно ему можно на этих стационарных точках поставить что-то типа ESP8266, настроенные на подключение к точке доступа WiFi. Точку доступа (роутер) возьмёт перемещающийся субъект. При приближении субъекта к стационарным точкам, они будут коннектиться к роутеру. В Ethernet порт роутера воткнуть девайс, собирающий данные. Как только ESP8266 входит в сеть - МК подключенный к ESP устанавливает соединение с каким-то IP на Ethernet-девайсе и сливает в него данные. Всё!

Это если у него контроллеры своей разработки. Но это опять же только гадания.  :unknw:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 minutes ago, jcxz said:

Многие чайники

Так то чайники. Мы уже давно даже не кофейники. Понятно, что думать надо. Чайник и с SPI такую связь сделает, что она глючить будет на каждом шагу.

9 minutes ago, jcxz said:

И топологию "кольцо" они не умеют.

Когда я сказал о 50% и с "некоторым геммором", то подразумевал, что кольцу их можно научить программно. Наверное не во всех случаях, но всё же...

10 minutes ago, jcxz said:

Как обойдётесь одним изолятором?

В данном случае - никак. А разве есть модули, которые поддерживают AT-команды через SPI шину?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, haker_fox сказал:

В данном случае - никак. А разве есть модули, которые поддерживают AT-команды через SPI шину?

AT-команды видел только на UART. Хотя и там им не место давно уже.

Без разницы - AT-команды или что-то иное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...