Важный момент в том, что имеется несколько источников цифрового сигнала. И их надо подключить беспроводно к одному приемнику. Главное это определить номер источника сигнала, а сам сигнал значения не имеет. Только сами передатчики должны быть не очень большого размера.
Попытка сделать это с помощью фильтров (разделение по частоте) оказалась не очень удачной пока что, так как не нашёл нормальных ускополосных фильтров по приемлемой стоимости.

Думаю, какой физический носитель лучше использовать - ИК или радио-диапазон. Пока что пытаюсь ИК, но ввиду того, что направление перечи не является прямолинейным (только после отражение от стены), подозреваю, что могут возникнуть проблемы с помехами на уровне сигнала или ещё какие ньюансы. Хотя если существуют готовые системы на ИК, то не мешало бы их проверить.

Может попробывать использовать модули GPRS или что-то подобное.
Есть ещё мысль сделать это дело в ультразвуковом диапазоне, а сигнал анализировать с помощью МК AVR или другим способом. Что думаете по этому поводу?

Телепаты в отпуске на Канарах!!!

Расстояние?
Условия распространения (характер препятствий) ?
тип сигналов (частота передачи данных хотя бы)?
синхронность сигналов (предполагается что асинхронные?)
допустимое время задержки на приеме?

Все элементарно. Берется несколько сотовых телефонов...

Ну дальше вы поняли.

Yuri Potapoff, Вы точно телепат . Как там на Канарах? ))
Что имеется ввиду под термином "цифровой сигнал", что представляют собой источники...

Сам пока в этом направлении не пробовал топать, но на Вашем месте я посмотрел бы на микросхемы-приемопередатчики CC2500 или CC1100

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

У нас на востоке Канар сегодня подморозило.

Тут надо учесть, что в воздухе ультразвук распространяется плохо.
Поэтому желательно использовать водную среду.
Если в зданиях - можно использовать систему отопления или канализации-водоснабжения.
Система отопления работает только зимой, это неудобно.
А вот система канализации-водоснабжения работает (если исправна), круглогодично.
Наиболее подходит водоснабжение -водяной поток непрерывен.
С канализацией похуже: если возбуждать водное зеркало унитаза, звук далеко не пойдет.

- до 3 м
- частота, думаю, несколько кбит/c, передать нужно всего 3 бита.
- сигналы, я также полагаю, асинхронные, ибо синхронизировать их, к сожалению, нечем.
- время задержки значение имеет, оно не должно быть слишком большим - не более 100 мс, включая всё время распространение от начального до конечного элемента.
- желательно иметь малый размер передатчика, а также небольшую мощность (питание от батарейки, разумеется).

Из готовых решений вполне подойдет сеть zigbee

если делать что-либо на полуготовых решениях, (однокристалльные трансиверы) я бы сделал опрос всех трансиверов последовательно, на 115200б/с можно сотню датчиков успеть опросить за 100мс

Исрользуйте волноводы! Хороший способ предать ВЧ сигнал без помех и прехвата )))

Не пробовали рассматривать кодовое уплотнение сигнала? По аналогии с CDMA, может помочь.

Ещё не пробывал. На изучение теории кодирования только пол года уйдет. Нет желания изобретать велосипед, что называется. Вернее, нет времени на это. Поэтому буду использовать радиомодули типа HM-TR и RFM12.

По поводу задержки. Не могли бы мне напомнить одну вещь. Особенно волнует задержка на входе ПК компьютера. На сколько я знаю, она м.б. довольно существенной. Поэтому интересует промежуток времени от подачи байта на вход COM-порта (или USB через микросхему FT232) до того, как программа на ПК получит этот байт.

С этим точно ничего не выйдет, тут даже знания теории кодирования не помогут.


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

На чтение задержки не велики- под хр и драйвером vcp от ftdi 10-15мс максимум. Причем это задержка начала пакета, если у вас данных не много, (20-30 байт/с) то она скорее всего будет менее 5мс. Но вот ОТВЕТ в тот же ком-порт - до 40мс.

Возможно, с D2xx драйверами ситуация будет лучше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А не подскажите на какое расстояние можно будет передавать информацию на чипе сс2500?? С внешней антенной до 15 см, например?