След като търсих и нищо не ми допадна (даже май имах тема тук някъде..) реших да седна сам да си пиша RF стекче...

Та ако някой има предложения/идеи/съвети е добре дошъл. Особено пък ако някой иска да помага

Значи целта ми са евтинджос модулчетата с RFM73, nRF24L01 на първо време, но няма да е зле да се предвиди поддръжка и за long range модулите.

Под стек разбирам не просто "някаква" конфигурация и да праща/получава пакети (това си го има из разните примери). Говоря за малко по-Ентелигентен вариант, който динамично да си преценява мощности, скорости, що не и канали, защити и т.н.. Да има разпознаване, евентуално рутиране... задължително бриджване (към usb,ethernet, wifi, що не и синьо зъбче)

1. Може да измислиш, ама да не стане по-сложно от GSM клетка, че тогава е по-добре да ползваш GSM модул.
2. Различните модули имат различни екстри различен размер на адреса(3,4,5 байта), някой подържат FEC, повечето подържат auto-retransmit и генерират прекъсване, когато отсрещната страна е получила пакета. Някой модули имат само 16 битов CRC, а може би, ще ти се иска да направиш 32 CRC. Всъщност това до някъде прилича на TCP/IP, само дето посления слой не е Ethernet ами е RF. Тоест, ако имаш TCP/IP работещ стек, можеш да преправиш само драйвера на физическия слой.
3. Това с мощностите повешето го игнорират и бичат на пълна мощност. Може би говоря глупости но май при GSM имаш контролен канал, който се предава по-лесно и се използва за установяване на канала за данни. Например имат 5 канала и по тях приемаш и предаваш на скорост 250кбпс по тези канали предаваш на какво received signal strength indicator (RSSI) са получили, за да може отсрещната страна да си намали мощността, както и на кой от 128-те канала да предават с 2мбпс.
Очаква се, че 250кбпс имат по-голям обхват от 2мбпс. Също така трябва да се гледа кои канали са заети, да се макрират като лоши и да не се ползват за известно време.

P.S. Това всъщност си е заешка дупка и от тебе зависи до колко на дълбоко искаш да се завреш там. Повечето хора са доволни само на pipeline където да пишат и четат. А други задълбават с няколко честотни обхвата, няколко честотни канала, няколко вида модулация, няколко вида FEC, няколко diversity antennas и т.н.
P.P.S. Забравих да спомена, че имаш 3 типа пакети. 1. От Плутон до Земята трябва да изпратиш снимка, като предварително знаеш че 50% от пакетите ще се загубят, а от изпращането на пакет до получаването му минават няколко часа, като има 50% вероятност пакета, който потвърждава получаването да се загуби. 2. Трябва да преточиш 4.7GB фаил максимално бързо. 3. Трябва да предадеш, че потребителя е натиснал левия бутон на мишката с минимално закъснение.

1. Един стек трябва да предлага избор между сложност и функционалност. Не ми е сефте да пиша стекове, така че съм наясно с проблема и знам как да го направя така че да се конфигурира лесно (поне от моя гледна точка). Очевидно ще има различни типове устройства, както е при разните пчелички, зъбчета и т.н. Някои ще трябва да са простички да не хабят батерия, други няма проблем да бръмчат повече и да правят повече неща.
За щастие нямам ограничение от към хардуер, т.е. "сложността" ми е ограничена само от времето за писане. Демек не се притеснявам че ще стане сложен, а че нямам да имам време да го направя толкова сложен

2. Разликите в модулите също си има механизъм по който се обират софтуерно. Така че от софтуерна гледна точка, това не е проблем... Проблем ще е несъвместимост в радио ефира. Но това май не е проблем, който мога да реша така или иначе, Ех, гледах един руснак как с nrf24 имитира bluetooth BLE... но това определено не ми е целта.

3. За мощностите мисля че прост адаптивен алгоритъм ще е достатъчен. Ще видим, като почна реални тестове. Принципно идеята е стека да се грижи за тия неща, т.е. в простия вариант може да е набита някаква мощност, в по-сложен вариант да си следи грешките и да вдига/сваля мощността... Още не съм го измислил....

Миро, задачата която си поставяш е мнооого по-амбициозна и от моето захранване за „програмисти” ... 

Като начало добре ще е този стек да покрива определени RF стандарти, така че да може да се използва за нещо повече от хоби проекти. Покриването на стандарти касае както хардуера, така и протокола. По отношение на протокола, в зависимост от изходната мощност се дефинира различно време (или коефициент на „запълване”) за използване на канала. Дори само заради това, стека трябва да е различен за щорт и лонг реиндж радиа.

В зависимост от мощността на предавателя и коефициента на използване на канала има изисквания и за „LBT – listen before talk”, за избягване на колизии.

Друг много важен момент е каква да е максималната латентност при комуникация и дали устройствата (или част от тях) ще са батерийно захранени. Батерийните устройства няма как да „слухрят” непрекъснато радиоефира и да чакат да получат пакет, така че или трабва да имат малка латентност, или малка консумация. Това зависи от конкретния случай.

Друг много важен момент касаещ рутирането е дали устройствата са стационарни или мобилни ...

Ще помагам с каквото и когато мога. Имам личен интерес за създаването на алгоритми за frequency-hopping (channel-hopping).

Относно контрола на мощността на предавателя – имам опит с това в нашите системи. Целта при нас беше основно пестене на батерия. Не е невъзможна задача – особено при стационарно разположени модули, Наистина има ефект и полза от това.

Емо, тя може да стане и много дебела, ама за разлика от теб мога и смятам да почна от работещите примери и полека-лека да добавям неща. По принцип не ми е цел да правя супер сложни неща. То и идеята на тия модули е простотата, от там и ниска консумация. Не искам да ги съсипвам с тежки алгоритми.
Но пък от друга страна сорсовете дето са в нета са съвсем тъпи. Всички стойности са фиксирани, само phy и някаква минимална част от линк ниво... Въобще мнооо е постна пицата
То за част от приложенията не мисля да усложнявям излишно радиото, по-скоро от приложна гледна точка. Примерно едно от нещата е термометърчета дето трябва да издържат по възможност години на една батерия. Та това само ще предава и спи, но искам да е практично, т.е. да няма нужда от инсталации, настроики и т.н. Демек произвежда се, даже може да се наложи и батерията да се постави и да се залее, щото трябва да издържа на влага. Та трябва да е достатъчно умно и да не си хаби батерията докато седи в склада. Т.е. трябва да има режими и да си търси само сървър и едва като намери такъв сървър дето пасва да почва да работи. После може да има възможност някои настройки да се променят от сървъра, включително канали, времена и т.н.

Това устройство е в единия край на спектъра, където се предават малко данни и много рядко. Трябва много внимателно да прецениш дали си струва да му слагаш много мозък и да го усложняваш, защото колкото е по-сложен софтуера толкова повече ток ще гълта и е по-голяма вероятността да си откриеш бъг, а като са заляти устройствата връщане на зад няма.
Ето един прост пример. nRF24L01 когато предава на максимална мощност гълта 11.3мА, а при приемане гълта 12.6 - 13.5. Тоест по си на далавера да изпратиш един и същи пакет 3 пъти насляпо, от колкото да предаваш и да чакаш да видиш има ли сървър дето е приел пакета. Освен това, тези 11.3мА TX импулси може да ги поеме кондензатор и ще натоварва батерията по-малко, от колкото дълъг 12.6мА RX, който вече ще почне да разрежда батерията. Малките батерии, когато ги разреждаш с 1мА имат по-голям капацитет от колкот, ако ги разреждаш с 10мА.
Разбира се има и батерии които ако ги разреждаш с малък ток ги прецакваш и имат най-голям капацитет, когато ги разреждаш с по-голям ток.

ike, еднопосочната комуникация не е никак добра идея. В предишните ни системи беше такава и тя не вършеше работа. Предавахме 4 пъти фрейма със случайни времена на закъснение между трансмисиите и въпреки всичко пак имахме неприети съобщения от устройства.

Според мен радиовръзката задължително трябва да е двупосочна. Трансивърите покриващи зигБи стандарта имат опция хардуерно да изпращат потвърждение по радиоканала (без участието на процесора), че фреймовете са приети.
При по-простите трансивъри, това може да се имплементира и софтуерно. Е, няма да е чак толкова ефективно, но пълно щастие няма

emilvtc значи според теб, ако се появи някакво съобщение е по-добре температурния сензор 30 минути да се пробва постояно да предаде температурата от преди половин час, хабейки батерията, вместо да предаде последната актуална температура. Всички SPI трансивъри които съм виждал го имат това за auto acknowledgement, когато пакета е получен от отсрешния трансмитер.

Това гледал ли си го:
http://www.airspayce.com/mikem/arduino/RadioHead/

За температурния сензор на радио-часовник с термометър мерещ външната температура си абсолютно прав.
А какво ще кажеш за газ, димен, сензор за наводнение "flood", температурен сензор в обратна връзка на отоплителна/охладителна системи, разните сензори по алармени системи и др.? Според мен в този случай предаването на евента е по-важно, от "опазването" на капацитета на батерията ... Т.е. всичко зависи от конкретното приложение.

Относно SPI трансивърите и вградените опции за автоматично отговаряне при приемане на валиден фреим - тези с които аз работя на Тексас и СиликонЛабс (относително нови чипове) - нямат. Тези покриващи ЗигБи стандарта трябва да имат и имат такава функционалност.

не помня... но обезателно ще го разгледам

Относно двупосочната връзка и потвържденията - модулите дето съм си харесал всички имат възможност и за двупосочност и автоматично потвърждение. Така че от към възможност - има я... останалото е въпрос на транспортните протоколи дето евентуално ще се имплементират.

Аз лично нямам фиксирани изисквания какви протоколи и кое как да го правя. Така че ще го правя както ми дойде Освен ако някой няма конкретния изисквания. Ако има желаещи да участват в писането или даже само да ползват написаното - да си дават изискванията. Същото се отнася и до модулите, ако някой предлага или пък иска.... За в момента съм си взел от ТМЕ на 2лева с RFM73 мисля от ebay да си поръчам с nrf24 - цените са около 1$. Ще огледам и с други чипове какво има... Много се замислям и за blutooth LTE модулчета, особено тия с куртексчета на нордик.

В момента най-евтините за близки разстояния са тези
5$ за 10 броя
http://www.ebay.com/itm/NEW-10PCS-2-4Gh ... 3a96c559f3
фейкове на NRF24L01+
за 8.60$ има оригинални NRF24L01+
http://www.ebay.com/itm/10PCS-NRF24L01- ... 2a2ea59d7f


за далечни разстояния най-евтините са тези $2.81
http://www.ebay.com/itm/SI4432-470MHz-4 ... 3ceeb783aa
но вече не ги произвеждат, заменени са от тези за $6.92
http://www.ebay.com/itm/E10-SMD-433MHz- ... 1e913cb32c

emilvtc ако ще зависи живота на някой от RF канала, то отпадането на връзката трябва да е аларма, както и срязването на кабела на алармена система. Но на мен ми се вижда безотговорно да слагаш толкова важни неща на свободни канали, които всеки може да заглуши съвсем законно. Например с 10 кибритени кутийки всяка от които да предава 10% от времето и слуша преди да предава - както е по изискване. Или примерно 3 таблета които гледат ютуб на 2.4GHz.