Начал играть с Si4432. Пока все нравится. Но заметил что в примере из AN415 используется 9600 бод и 45 КГц девиация частоты. Почему такой большой индекс? Что это дает кроме меньшей заботы о стабильности и точности кварца? Есть какие нибуть источники мудрости о выборе оптимальной девиации и полосы приемника - как влияет на дальность при тех же ошибках?

При увеличении индекса - растет база сигнала => повышается его помехоустойчивость, но при этом растет полоса, занимаемая сигналом.

Ну не такой и большой у вас индекс. Я и с 8-ой игрался. Больший чем 1 индекс мод дает более широкую полосу (RX/TX), повышается его помехоустойчивость (для относительно малых рассояний) к импульсным коротким помехам. Которые обычно доминируют. Например когда много устройств с близкорасположенными частотами. Но для относительно больших рассояний (где требуется минимальное количество ошибок в канале) больший чем 1 индекс мод это плохо, поскольку уменьшается соотношение с/ш и количество ошибок в канале получаем большее. Все зависит также от поставленной задачи. Например максимальная дальность с допустимыми потерями. Или ограниченная дальность без потерь. Характер шумов тоже влияет на выбор коэф мод. Еще нужно учитывать антенну её тип, стационарный или перемещающийся объект, переотражения, зоны и тд. Индекс модуляции это всегда компомис. Я много различных индексов и скоростей протестил для Si4432 для различных задач и разных проектов. О меньшей заботы о стабильности и точности кварца, думаю тут они перестраховались, если включена AFC. Не нашел проблем при 10ppm и 30ppm при включеной AFC. Другое дело когда вы не используете AFC.


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

Именно исходя из этого я слегка удивился примеру. То что компромис я понимаю. Практического опыта по RF практически никакого, но Физтех я когда то окончил, так что с теорией все хорошо

Конкретная задача - передавать медленно, буквально десятки байт раз в несколько секунд от центра многим "слушателям", так что без подтверждения. Но не жалко при такой скорости повторить хоть 10 раз и избыточности напихать хоть сколько. Так что единичные ошибки по боку, но совсем пропустить сообщение никак нельзя.
Экспериментировать трудно: неизвестно какие помехи и железобетонные перекрытия могут быть у клиентов. 915 МГц. Хочу сделать 2400 скорость и 10 КГц девиацию. 20 КГц полосу на приеме. Естественно с AFC.

Это разумно?

Из теории оптимального приема желательно иметь равные полосы как при RX также и TX. Я проверял и это ;-) для Si4432. Повозился и с этим диапазоном 915 МГц. Переизлучение как и положено неплохое. Дайте больше информации какие у вас могут быть рассояния, и проблемы с перкрытием.
Поскольку это трансивер, вам желательно обеспечить подтверждение! Тем более у вас есть возможность повтора 10-и раз. Проблема с так называемыми единичными ошибками тут в их аппататном протоколе и демодуляторе. Если короткая помеха попадаете на синхронизацию то и весь пакет не примется. Данные теряются. Желательно передавать несколько раз с подтверждением. 2400 скорость и 10 КГц девиацию это вообщем то низкие скорости для этого чипа. У них на сайте есть экселовский файл для подсчета значения регистров, в том числе и полосы RX/TX и девиации, и он близок к оптимальному, советую его использовать если вы начинаете.
Но я бы использовал скорости повыше 40...80Kbit. По причине меньшего времени как на RX/TX. И 1-у для девиации. Сохранив доп время для повторов. Также для уменьшения вероятности сбоя использовал бы технологию спред-спектрума, тем более это решается не сложно на этом трансивере со средненьким контроллером. Используйте GFSK без манчестера.

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

Спасибо за подробный ответ, но вопросы остались.

Я так понял из datasheet что девиация скажем 45 КГц означает +/- 45 КГц, поэтому полоса 90 КГц и во всех примерах полоса приемника выбирается соответственно. Например в AN415 :
/*set the modem parameters according to the excel calculator(parameters: 9.6 kbps, deviation:45 kHz, channel filter BW:
112.1 kHz*/

Еще найдено такое:

** Copyright 2009 Silicon Laboratories, Inc.
** http://www.silabs.com


//The table store the precalculated modem parameters for different data rate cases.
//This table is used in the non compatible mode (for best RF performances)
//see the comments at the end of the line for more details.
code uint8 RMRfSettings[NMBR_OF_SAMPLE_SETTING1][NMBR_OF_PARAMETER] =
{
// IFBW, COSR, CRO2, CRO1, CRO0, CTG1, CTG0, TDR1, TDR0, MMC1, FDEV, AFC
{0x01, 0x83, 0xc0, 0x13, 0xa9, 0x00, 0x05, 0x13, 0xa9, 0x20, 0x3a, 0x40}, //DR: 2.4kbps, DEV: +-36kHz, BBBW: 75.2kHz
{0x04, 0x41, 0x60, 0x27, 0x52, 0x00, 0x0a, 0x27, 0x52, 0x20, 0x48, 0x40}, //DR: 4.8kbps, DEV: +-45kHz, BBBW: 95.3kHz
{0x91, 0x71, 0x40, 0x34, 0x6e, 0x00, 0x18, 0x4e, 0xa5, 0x20, 0x48, 0x40}, //DR: 9.6kbps, DEV: +-45kHz, BBBW: 112.8kHz
{0x91, 0x39, 0x20, 0x68, 0xDC, 0x00, 0xD3, 0x9D, 0x49, 0x20, 0x0F, 0x40}, //DR: 19.2kbps, DEV: +-9.6kHz, BBBW: 28.8kHz
{0x91, 0x9C, 0x00, 0xD1, 0xB7, 0x01, 0xA6, 0x09, 0xD5, 0x00, 0x1F, 0x40}, //DR: 38.4kbps, DEV: +-19.2kHz, BBBW: 57.6kHz
{0x92, 0x68, 0x01, 0x3A, 0x93, 0x02, 0x78, 0x0E, 0xBF, 0x00, 0x2E, 0x40}, //DR: 57.6kbps, DEV: +-28.8kHz, BBBW: 86.4kHz
{0x9B, 0x34, 0x02, 0x75, 0x25, 0x04, 0xEE, 0x1D, 0x7E, 0x00, 0x5C, 0x00}, //DR: 115.2kbps, DEV: +-57.6kHz, BBBW: 172.8kHz

};

---------------------------

При малых скоростях почему то большие индексы. Боятся слишком острой настройки?

Короче попробую золотую середину /DR: 19.2kbps, DEV: +-9.6kHz, BBBW: 28.8kHz и как вариант DR: 9.6kbps, DEV: +-45kHz, BBBW: 112.8kHz.

Про то что весь пакет пропадет при сбое синхры я понимаю. Но если 300 приемников, то от каждого подтверждение получать накладно. Я подумал о такой схеме: каждый пакет имеет номер. Если пришел Х но не было Х-1 или Н секунд ничего не было, то просить передать еще раз. Процессор у меня мощный - ARM 400 MHz+, но круче Хеминга все равно не планирую. Расстояния не очень большие - одно большое здание, но возможно 2 этажа. Может передавать несколько раз на разных каналах? Но не совсем понятно как синхронизировать. Очень привлекательно было бы FHSS сделать, но пока рабочих примеров не нашел, а писать самому с нуля нет ни времени ни особого желания. Опять же особенность в том что посылки идут раз в несколько секунд. Если синхронизация занимает заметное время, то будет накладно.

Ответ типа RTFM с ссылкой на FM очень приветствуется.

Еще посмотрел конфигуратор от CC1101. Начиная с 9.6К бод четко девиация половина скорости, т.е. 4.8 КГц. Для 50К бод 25 КГц, и т.д. Но полоса приемника всегда примерно вдвое и более выше двойной девиации, т.е в первом случае 58 КГц, а во втором - 100.
И для маленьких скоростей огромный индекс: 1200 бод, 14.3 КГц девиация, 58 КГц прием. К чему бы это?

При малых скоростях большие индексы из-за ширпотребных дешевых кварцев. Там же синтезатор и деление. Разброс частоты в группе квацев может быть и 50ppm при их уходе в 10ppm. Да и 10 ppm для скорости 600-1200 уже на грани. Также их спроектированная AFC имеет мин/мах полосу захвата и соотретствующее время реакции. Надеюсь вы не планируете использовать кварцы с погрешностью и разбросом в 0.2...0.5ppm?

... Но полоса приемника всегда примерно вдвое и более выше двойной девиации, ...
Это же из принципа модуляции следует. В Datasheet формула есть. Для (G)FSK излучаются две частоты (у каждой полоса девиации) с расстоянием между частотами. Отсюда и выше двойной девиации полоса приема.

Для 300 приемников и от каждого подтверждение получать не накладно! Тут вам нужно просчитать временные окна. Если 300 то и скорость можете поднимать до 80...100Kbit. Из моих проектов, ранее сделанных, 50 устройств опрашивались за ~4 секунды на скорости 20K. Подняв скорость до 160K (близкая к пределу обработки моим мелким контроллером) я за ~5 сек опрашивал уже 400 устройств с подтверждением. Пакеты были короткие, очевидно как и у вас.

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

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

Если пользуете что-то типа 9-ого ARMа, якобы мощного. Пощитайте время в ветках, может вам и хватит а может и нет. Кортексы М4 мне понравились больше. В одном из проектов на ARM9 пришлось мне ставить промежуточный дешевый контроллер.

Я от Хеминга отказался после тестирования. Мало чего давал. Может каких 1 ... 2% выигрыш. Но потери как по времени, так и по ресурсу не устроила. Тем более повторными запросами, проблема получения данных снялась. Но это в моем проекте.

В вашем проекте еще проблема антенн, направленности и тп важна, поскольку у вас здание с этажами.
С CC1101 игрался еще как только вышли. Капризные, менее мощные.
Хотя, кому что больше нравиться.

Aner достаточно подробно и качественно разжевал.

Предлагаю еще вариант. Для повышения помехоустойчивости примените коды Баркера. Расширение спектра, с одной стороны, повышение уровня распознавания символов, с другой. Ес-но, приведет к некоторому увеличению длины пакета и к процессорной обработке.
Можете сделать финт ушами. В режиме PH вывести на GPIO0 сигнал после демодулятора - то, что поступает в FIFO. По прерыванию по обнаружению преамбулы или по синхрослову начинаете цикл ловли кодов Баркера, применяя простейшую корреляцию. Я так делал - работает. Тогда плевать на ЦРЦ в фифо. Здесь на форуме я чуть подробнее рассказывал.
примечание. Si4432 силабс не рекомендует для новых разработок. используйте следующее поколение - 446х. Девайсы на голову выше 443х. проверено практикой.

OK, т.е. как я и предположил.



Это я тоже понимаю и даже помню про функции Бесселя Удивило не то что полоса приема шире двойной девиации, а то что у CC1101 предлагается заметно шире делать чем у Si4432 при той же девиации, ну да ладно. Я собственно смотрел на CC1101 до того как нашел 4432. Использовать не буду.




Вполне возможно что я многого не понимаю. Допустим у меня 100 каналов. Пусть на каждом передаю пакет в 100 байт включая преамбулу, синхру и CRC.
Скорость 10К, значит порядка 100 мс на 1 канале, так? Приемнику чтобы синхронизироваться надо ждать на одном канале (где нет шума) 10 секунд и переходить на следующий, пока не поймает сигнал. Если передача идет непрерывно, все прекрасно: поймали и дальше только считай байты и прыгай. А если передача всего 100 байт раз в секунду, как у меня? Ждать 100 секунд? Посылать постоянно ненужный пилот?



Samsung S3C2416. Но у него другой работы много, так что тоже склоняюсь к простым методам.

О, SergNKо вы и тут появились со своей идеей корреляции. Вы так и не ответили мне ранее с чем же коррелировать должен ( бит, симовл или что-то еще?) Если вы про автокорреляцию, то постарайтесь правильную терминологию использовать, не как ранее.

Ранее я вам пояснял, таки и в данном случае, ...данных мало передается! Как то вы не замечаете этот главный момент. Избыточные коды и предложенные вами коды Баркера не дадут выигрышь на приёме, и не особо помогут, только все усложнят. По нескольким причинам:

( ... если советуете коды Баркера то указали бы сразу разрядность, пробую угадать ... 11 это у вас из 802.11? Или я ошибаюсь? Но лучше работают коды Голда или Касами те, что в CDMA из-за их переодической корреляции. Но это все не сюда!)

1) Длина синх+преамбула соизмеримы или более чем передаваемые данные. Сбой с большей вероятностью из-за не приема синхры или преамбулы. Далее коды не помогут никак. Повтор поможет.

2) ошибка пакета также детектируется, и если у вас уж совсем мондраж за потерю данных, повторяйте и сравнивайте по 2-3-5 раз.
Надежнее чем код Баркера. Или вы не согласны?

3) ...Расширение спектра, с одной стороны, ... <---это ухудшение соотношения сигнал/шум. Не нужно этого тут!
Разве, что это нужно вам, чтобы затем с этим бороться кодами!

4) ... Ес-но, приведет к некоторому увеличению длины пакета <--- И это лишнее тут, для 100 девайсов или более это куча потеренного времени и тд ... .

5) ... В режиме PH вывести на GPIO0 сигнал после демодулятора ... <--- Ну никакого смысла нет, ошибка то как раз делается в демодуляторе! Зачем затем "мертвого" реанимировать ведь не получиться. Разве, что для начальства тупого, денег срубить и дополнительного времени. И чем же так плоха внутренняя структура модема с FIFO? Что её нужно обходить?

6) ... к процессорной обработке кода...<--- Правильно понимаете, ...но как в предложенном процессоре так и у вашего, явно нет инжины для аппаратной обработки этого кода, нужно писать не очень удобную обработку, пожирающая немало ресурсов проца, а также - жрущую батарейку если это автономный девайс.

Si4432 от силабса будут еще выпускать до 2015 года, у них в планах. Улучшенные Si446X много дороже. Их отличает командное управление против регистрового у Si4432. Девайсы никак на голову не выше. Просто улучшены немного параметры. Но я тоже за новые проекты на новых Si446X, если конечно есть желание платить много больше.


Я же советовал вам поднять скорость до 80...100Кбит, не 10Кбит!, это даст вам больше времени в окнах.
Зачем так много каналов? У вас же в ресурсах и временные окна и частоты. Ну на худой конец, можете использовать одновременно 2...4 чипа на прием/передачу, разделив всех на группы. Данные то идут по SPI, чипы на одной шине. Также можете задействовать и другой диапазон c этим чипом SI4432.
Зачем приемнику ждать, пусть сканерит непрерывно из числа нужных. Вариантов у вас ну очень много, не такая и трудная задача, правда для тех, кто уже имел опыт в аналогичных проектах. Хотя всего вашего задания не знаю. Можете детали написать мне в личку.

Samsung S3C2416 - а чего этого мамонта ставите? Или нашли совсем дёшево?

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

Диапазон обязан быть 915 и не менее 50 FHSS каналов законодательно. Я согласен что задача не особо сложная и все начинает складываться. Просто чем изобретать велосипед стараюсь понять на чем люди ездят.

Самсунг - таки да, совсем дешевый и полностью устраивает. Прибор - специализированный планшетный компютер с 8" экраном работающий весь рабочий день т.е. 8 часов от батареи. Для более быстрого устройства сделал прототип на TI OMAP3, но оказалось дорого POP память, хоть и симпатично. В моей линейке есть еще 2 Самсунга: 6410 и 210.
Если есть другие варианты, с удовольствием посмотрю. Требования: поддержка LCD не меньше 1024х768 и готовый Linux kernel 2.6.3x.


За последние пару дней нашел на просторах интернета кое какие примеры с FHSS. Разберусь.

Спасибо.

P.S. Модули на 4432 по $5 не делает в Шензене только ленивый, а на 446х я готового ничего не нашел. Конечно не хитро и самому делать, но китайцев много, а я один Не знаю как они это делуют, но один чип почти столько стоит как готовый модуль с кварцем и раз'емом...

А что за модули , можно поподробнее?

Чувствительность сильно не пострадает, тестировал я этот момент. Если у вас совпадают полосы RX/TX. Также используйте кварцы не хуже 10ppm.
50 FHSS должно хватать с избытком. Дайте ваши ссылки на примеры с FHSS, может что подскажу из практики. Может вам готовый планшетник в том же Шензене взять и пользовать как готовый?

Например такие модули:

http://www.aliexpress.com/store/product/SI..._750797803.html

Их там вагон и маленькая тележка. К сожалению (почти) все настроены на 433 МГц, но договориться с ними ставить другие номиналы на balun наверное не сложно.

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

2 Aner: найден такой проект
http://sourceforge.net/projects/openfhss/

интересно Ваше мнение. Там под CC1101, но нижний уровень заменить не трудно.

У hoperf модули поменьше размером в той же цене.
alexf: посмотрел проект, тексас проплачивал его, продвигая свои чипы. Наворотили много всего, много отладки требуется еще, сыроват.
Вы потяните тот HFSS?

Нижний уровень взять можете, но нужен он вам такой? Там в СС часть софта, в люминариксе другая часть. Ваши 100-и устройств передающие
короткие пакеты, потребуют той же нехилой обработки и какой-то ARM. Думаю перебор.

Вам по-проще что-то нужно. Там ведь проброс TCP/IP стека через всю их сеть с роутингом. Скорости заявлены высокие, в параметрах много ошибок, неточностей. Плату сделали почти правильно, забавно что в орле, тоже его пользую. ВЧ часть сделана слабо, из моего опыта вижу.