[M_Z 0]

- до 3 м

- частота, думаю, несколько кбит/c, передать нужно всего 3 бита.

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

- время задержки значение имеет, оно не должно быть слишком большим - не более 100 мс, включая всё время распространение от начального до конечного элемента.

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

Как вариант, Инфрокрасный канал обмена. Дешево, просто и дальность 3 м без проблем.

[Valery_Vlad 0]

Почему нет? У меня большие надежды на те модули HM-TR. Не знаю, правда, как они будут работать в случае нескольких передатчиков и одного приемника...

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

 

1. Надо разнести передачики по шкале частот, так, что бы их спектры не перекрывались с учетом всех дестабилизирующих факторов.

2. На приеме полосу частот, в которой работают передатчики, перенести на промежуточную частоту, где при помощи скорстного процессора (DSP) произвести фильтрацию и обработку сигнала каждого передатчика.

В этом случае возможно определить какой сигнал пришел раньше и на сколько.

[Harbinger 10]

Передатчики на разных каналах, приёмник сканирующий. Лучше, конечно, дуплекс - отправил датчик посылку, получил подтверждение и успокоился до следующего сеанса передачи...

[M_Z 0]

Передатчики на разных каналах, приёмник сканирующий. Лучше, конечно, дуплекс - отправил датчик посылку, получил подтверждение и успокоился до следующего сеанса передачи...

А почему нельзя временное разделение.

Если информации не много, то задача легко решаема.

Все передатчики и приемник работают на отной частоте.

А раздвинуть по времени передатчики, это задача легко решаема.

[zl3p 0]

А раздвинуть по времени передатчики, это задача легко решаема.

В данном случае нерешаема, т.к. источник информации носит стохастический характер. Придется, видимо, решать эту задачу алгоритмически, т.е. програмно.

[Valery_Vlad 0]

Придется, видимо, решать эту задачу алгоритмически, т.е. програмно.

Как это вы сделаете?

[zl3p 0]

Как это вы сделаете?

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

[Valery_Vlad 0]

У нас такая задача специально ставилась, при помощи DSP процессора одновременно принмали несколько сотен передатчиков. См. выше мои сообщения.

[zl3p 0]

У нас такая задача специально ставилась, при помощи DSP процессора одновременно принмали несколько сотен передатчиков. См. выше мои сообщения.

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

Придется как-то выкручиваться в пределах RISC-архитектуры...

[Valery_Vlad 0]

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

Придется как-то выкручиваться в пределах RISC-архитектуры...

При малом количестве передатчиков (например 4), при трех битах данных, еще, если снизить скорость передачи до 100 бит/с DSP становится слишком дорогим, можно уже применить ARM (может быть и RISC-архитектура).

[M_Z 0]

- до 3 м

- частота, думаю, несколько кбит/c, передать нужно всего 3 бита.

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

- время задержки значение имеет, оно не должно быть слишком большим - не более 100 мс, включая всё время распространение от начального до конечного элемента.

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

неизвестно сколько устройств передающих информацию одновременно.

Но предлогаю следующий вариант

в качестве приемопередатчиков берем сс1100 или сс2500. Очень мало навесов и в прграмном плпне они удобны. Я на них реализовывл уже одну систему аналогичную вашей.

Варианты програмной реализации следующие:

1. центральное устройство делает запрос. Все устройства получив запрос отвечают через промежуток времени равный адресу устройства умноженному на время передачи посылки плюс небольшая пауза. для ССхххх это время при небольшом количестве информации прискорости 250..500кбит/с будет примрно 1 мс. делаем запас 2мс. В итоге если период опроса 100мс, то количество устройств может быть до 50.

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

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

в случае с динамическим адресами програмная реализация гораздо сложнее.

Но как мне подсказывает интуиция, для вашей задачи статические адреса вполне пригодны.

[zl3p 0]

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

Хотя, скорее всего, я просто забъю на эти конфликтные ситуации в виду их редкости, т.к. среднее время между 3-х битными посылками с одного датчика составляет около 1 сек при их количестве 5-10 шт.

Изменено 17 ноября, 2008 пользователем zl3p

[M_Z 0]

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

Хотя, скорее всего, я просто забъю на эти конфликтные ситуации в виду их редкости, т.к. среднее время между 3-х битными посылками с одного датчика составляет около 1 сек при их количестве 5-10 шт.

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

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

[Serj78 0]

А если у вас нет прямого солнца , прямая видимость 3м или помещение, и все датчики могут видеть потолок, например, тогда на передатчики- светодиоды, приемники- ик-сенсоры от пультов ДУ. С них на выходе уже обработанный и демодулированный сигнал. стоят рублей по 40 :) Единственное что вам надо- сформировать несущую 36-8кгц для модуляции ик-данных. Передавать можно обычным uart-ом. Метод опроса такой же- приемник датчика ждет своего адреса, потом посылает информацию.

Пульт ДУ от пары батареек сами знаете сколько работает :)

У вас потребление, скорее всего, будет раз в 10 больше, но я думаю что вас это устроит :)

[M_Z 0]

Пульт ДУ от пары батареек сами знаете сколько работает :)

У вас потребление, скорее всего, будет раз в 10 больше, но я думаю что вас это устроит :)

Пульт долго работает в спящем режиме, не нажаты кнопки и нет передачи.

в случае постоянной передачи время рабрты сократится не в 10 раз а несравнимо больше и скорее будет больше чем прииспользовании радиоканала.

Хотя версия ИК онта тож имеет право на жизнь, из за своей прстоты реализаци в домашних условиях, не требует изготовления печатных плат. Можно на макетке споять. Версия с радиканалом она схемно проще, но требует специально изготовленной печатной платы.