[zl3p 0]

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

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

 

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

 

Может попробывать использовать модули GPRS или что-то подобное.

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

[Serj78 0]

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

 

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

 

Расстояние?

Условия распространения (характер препятствий) ?

тип сигналов (частота передачи данных хотя бы)?

синхронность сигналов (предполагается что асинхронные?)

допустимое время задержки на приеме?

[Yuri Potapoff 0]

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

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

 

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

[GAin 0]

Yuri Potapoff, Вы точно телепат :). Как там на Канарах? ))

Что имеется ввиду под термином "цифровой сигнал", что представляют собой источники...

[Mik174 0]

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

[Yuri Potapoff 0]

Yuri Potapoff, Вы точно телепат :). Как там на Канарах? ))

Что имеется ввиду под термином "цифровой сигнал", что представляют собой источники...

 

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

 

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

[Mirabella 0]

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

 

Тут надо учесть, что в воздухе ультразвук распространяется плохо.

Поэтому желательно использовать водную среду.

Если в зданиях - можно использовать систему отопления или канализации-водоснабжения.

Система отопления работает только зимой, это неудобно.

А вот система канализации-водоснабжения работает (если исправна), круглогодично.

Наиболее подходит водоснабжение -водяной поток непрерывен.

С канализацией похуже: если возбуждать водное зеркало унитаза, звук далеко не пойдет.

[zl3p 0]

Расстояние?

Условия распространения (характер препятствий) ?

тип сигналов (частота передачи данных хотя бы)?

синхронность сигналов (предполагается что асинхронные?)

допустимое время задержки на приеме?

 

- до 3 м

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

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

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

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

[Serj78 0]

- до 3 м

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

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

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

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

 

 

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

 

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

[player999 0]

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

[leoluk 0]

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

[zl3p 0]

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

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

 

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

[Valery_Vlad 0]

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

 

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

 

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

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

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

[Serj78 0]

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

 

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

 

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

[zl3p 0]

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

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