500 метров. 433 МГц, 10 мвт, прямая видимость, мобильный обект (сеть), one way, скорость 2-5 кбод, пакет 100 бит
Возможно ли реализовать? И на чем?

Цена до $90 target price (включая процессор) на партию 100 штук.

На чем попробовать?

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

+1 за СС1100 с включенной FEC и минимальной полосой. Кварцы придется компенсировать.
Но требуется знать какова "цена сбоя". Если из-за временной потери связи случится чернобыль придется искать более надежные варианты.

Ну, при таком раскладе радиоканал вообще не должен рассматриваться в качестве основного. Да, еще немаловажно, в каких условиях будет эксплуатироваться линк, потому как 500 метров на земле и 500 метров воздух-воздух (либо земля-воздух) это совершенно разные случаи. Например, в сотне километров от города "на земле" может быть тишина и спокойствие, а если вдруг речь о радиоканале для авиамодели, то, поднявшись на сотню метров в воздух, приемник может просто оглохнуть по динамике....

Спасибо. То есть можно попробовать.
Думаю, что нужна будет псевдоперестройка частоты. Чтобы "автомат" не попал в забитый канал.
Потеря одного из шести пакетов в минуту с одного источника сети допустим. Общее число источников сети до 256, с разбивкой по каналам по 48-64 передатчиков на канал. Общее время сбора информации от передатчиков на прием хочу иметь 2 секунды. Можно до 5 секунд. Вряд ли больше.
Кроме того, есть точное время, на приемной и передающей стороне. Погрешность микросекунд 10.
Где тут узкое место может быть?

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

Если поиеха задавит все каналы по динамическому диапазону, то остается только ждать приема.
Условия эксплуатации, я полагаю, несколько километров от стоянок автомобилей, и городской инфраструктуры.
Другие, мощные источники излучения (GSM, VHF, UHF) могут быть в регионе "как есть". Отстроиться на прием возможность будет путем удаления от "подрозрительно мощных источников" метров на 50-200. Приемник мобильный с оператором.


Дополнительно.
Надеюсь на синхронизацию времени. Считаю, что она есть. И могу обеспечить. То есть, на передающей и приемной стороне имеет место синхронные скачки по частотным каналам. Более того, хочется использовть синхронные выборки не только по несущей частоте канала, но и по частоте (фазе) модуляции (данных). К примеру, битовый поток имеет период 200 мкс, погрешность времени 10 микросекунд. Должно хватить.

А это уже ни к чему. Предложенный CC1100 (1101) имеет встроенный и очень даже неплохой модем, и вряд ли стоит заниматься демодуляцией самостоятельно.

Спасибо за предупреждение.
Предположим мой процессор подготовил данные (пакет 100 бит) и готов послать через CC1100. Мой процессор подождет момент T1 своего выхода в эфир. И желает отправить пакет через CC1100.
Вопрос.
С какой максимальной задержкой t и разбросом dt начнется передача этого пакета? Какой может быть разброс времени. У меня ведь на очереди отправка по расписанию с другого передатчика в момент T2 итд. Разделение по времени (расписанию). Приемника (прослушки эфира) на передающей стороне нет.

То есть, на пропускную способность системы (среднюю скорость передачи в системе) будет влиять t и особенно dt.

Можно оценить эти возиможные значения? Например, dt<500 микросекунд. Или t= 1000 микросекунд. Здеь важен опыт работы с CC1100.

Иными словами, какое время между передачами пакетов разными передатчиками используется зря на временные погрешности?

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

Можно сократить практически до нуля. Но надо учесть, что пакет данных дополняется синхропреамбулой и CRC, и окно приема должно быть широким для приема всей информации. Кстати, а почему бы не использовать двунаправленный канал ? При использовании этого трансивера никаких лишних компонентов не потребуется... Ну, а если есть иные средства очень точной синхронизации, то да, можно и жестко по расписанию, с субмикросекундной точностью (заодно этими же средствами можно воспользоваться, чтобы вычислить частотную поправку для компенсации разбежек опорников, чтобы не было проблем из-за малой ширины канала). Возможности быстрого переключения каналов там тоже весьма внушительные...

Можно сократить практически до нуля. Но надо учесть, что пакет данных дополняется синхропреамбулой и CRC, и окно приема должно быть широким для приема всей информации. Кстати, а почему бы не использовать двунаправленный канал ? При использовании этого трансивера никаких лишних компонентов не потребуется... Ну, а если есть иные средства очень точной синхронизации, то да, можно и жестко по расписанию, с субмикросекундной точностью (заодно этими же средствами можно воспользоваться, чтобы вычислить частотную поправку для компенсации разбежек опорников, чтобы не было проблем из-за малой ширины канала). Возможности быстрого переключения каналов там тоже весьма внушительные...
[/quote]

Спасибо. Обнадеживает.
100-200 микросекундной погрешности будет вполне достаточно

Кстати, а почему бы не использовать двунаправленный канал ? При использовании этого трансивера никаких лишних компонентов не потребуется...
[/quote]

Надо подумать. Может имеет смысл использовать широковещательные команды типа "всем включиться/выключиться".

И последний вопрос.
В CC1100 много критических багов? Есть непонятные подвисания или остановы?

В эрратах вроде описаны все. Есть неприятные моменты, но поскольку они описаны, то можно без труда обойти, но прочитать надо обязательно. А вот с CC1101 я обнаружил неприятную и недокументированную особенность (я в этом разделе ее описывал, в декабре прошлого года) - если трансивер поднимается из powerdown, то обязательно надо использовать задержку в PO_TIMEOUT, отличную от 00, либо вводить дополнительную задержку между появлением CHIP_RDY и передачей первого байта по SPI, там что-то поднакрутили с таймингами против CC1100, и возможны неприятные проблемы (подробности я описывал).

Обязательно изучите еррату.
Непрерывный прием лучше не использовать. У меня cc2500 (идентична cc1100) иногда зависает при приеме. Либо всегда используйте прием ограниченный таймаутом либо если очень хочется принимать непрерывно мониторьте состояние трансивера. Если вылетел из RX перезапускайте прием. До причин самопроизвольного выключения приема мне докопаться пока не удалось.

Спасибо. Полезная информация.

А через какое среднее время "зависает" (прекращается) прием?
В моем случае можно переконфигурироваться через ~ 10 секунд. Или каждую минуту после цикла. То есть, после скачка на другую несущую или накопления принятых данных за кадр псевдослучайной перестройки.
Этого будет достаточно, или надо чаще?

Когда я экспериментировал, зависаний в режиме непрерывного приема никогда не наблюдал, все ж, мне кажется, тут что-то с конкретными настройками. А 10-секундного интервала хватит, полагаю, на все, даже теоретически возможные и невозможные, ситуации.

У меня подвисает довольно редко и нерегулярно. Разброс от единиц минут до 30-50 минут. 10 секунд вполне достаточно.

У меня была похожая проблема на СС2500 , происходило переполнение входного буффера, до конца не разобрался,
просто после чтения данных стал выдавать строб очистки буффера,помогло. СС2500 находился всё время в режиме
приёма

Какой микропроцессор лучше применить для управления СС1100? Дополнительно в устройстве будет GPS с одним UART-ом.
Цена имеет значение.

У меня, например, во всех проектах используются ATmega8 и ATmeg168. Если килобайта оперативки хватит для парсинга NMEA, то, наверное, самое оно. Дешево и сердито.

Спасибо.
Килобайта хватит вполне. Нужно всего одно NMEA сообщение. Даже 128 или 256 байт будет достаточно для парсинга.
Остальное пойдет на радиосвязь.

За такую цену можно приобрести и готовое устройство. Например SATURN-433 (radiomod.narod.ru), для вашего случая вроде как раз подходящий.

Два вопроса.

1. GPS с пассивной GPS антенной интегрирован с приемопередатчиком и RF антенной. Будет ли "заваливаться" GPS при излучении RF. Что говорит опыт? Где подводные камни?

2. Две сети работают на разных несущих частотах. Устройства могут слать одинаковые сообщения, по крайней мере устройства с одинаковыми адресами в каждой подсети. Возможно ли ложное обнаружение (прием) не своего пакета от другой подсети? Или все "не свое" уйдет под шум? Что говорит опыт? Конечно, можно добавить адрес подсети в сообщение. Но хочется съэкономить на длине сообщения.