само че по нашия край не се казва пуйка, а мисирка...
и не казвай на никой за 433-те, щото тва е тайната в рецептата за "мисирка по добруджански"

това 433 да не е като онази система 442 дето беше модерна навремето

Тъй... доста време се мотах, но май ще сядам вече да подкарам малко радиа.

Въпросът е как да си заформя някакво RF-стекче така че да поддържам различни модули. От една страна всеки модул/чеп си има някакви уникални способности. От друга страна в много от потенциалните приложения RF-а е просто интерфейс и ме интересуват само данните, без значение от къде и как минават.
Това с унифицирането някак си ще го измисля, т.е. по един или друг начин ще портна всеки RF модул до някое от 7-те нива на OSI-то. По-трудно ми е и не знам как точно да го измисля това с "автоматизацията". Имам предвид че за повечето прости радиа много от параметрите не е добре да са фикснати както е в повечето примери. Примерно на каква мощност да се излъчва, или на каква честота/банд/скорост.
Значи приложението може да има възможност да ги "набие", но по-скоро само като възможност. В повечето случаи приложенията не им е това работата и е по-добре да има "auto", т.е. стекът трябва да може да следи връзката и ако е нужно да вдига или да сваля мощността. По същия начин и раздаването на честоти/канали/адреси може да се автоматизира. Някои неща сигурно ще станат и без овърхед на трафика, за други не знам... може би ще се наложи протоколчета нещо. Ще ми се да видя какво има първо вместо да откривам топлата вода. Та ако някой знае такива решения, независимо как точно са оформени да свирка...

Обсъждали сме го и преди, но за да направиш ефективно работещ стек според мен трябва максимално да се възползваш от тези "уникални способности". Под ефективно работещ разбирам минимален овърхед, минимално време за използване на канала, минимална консумация,покриване на стандарти и т.н.

Днес не те интересува консумацията, но утре когато те заинтересува да не се окаже, че ще трябва основно да прекрояваш стека?

От друга страна не трябва да се "обременява" проекта с "мисли за бъдещето" ...

За нашите фирмени цели от им пея, че готов протокол за нашите цели няма да намерят, ама дървените мениджерски глави даже и не стоплят за какво им говоря. Не са на ясно с материята и стават лесна жертва на по-напористите търговски представители на такива решения и ми коства доста усилия, за да ги разкандардисам. Направиха едногодишен рисърч на съществуващите към момента решения и стигнаха по трудния начин до моите приказки от преди година ...

Та в този ред на мисли - ако имаш конкретна задача и си решил да разработваш собствен протокол - скроявай го според конкретните ти нужди...

Прекрояването е неизбежна част от работата ни... ако нещо не се прекроява значи не се развива
Точно от тая гледна точка се стремя да оформям кода като "стек", т.е. да може RF-частта да се променя/допълва без да се налага сериозна революция в готовите вече проекти.

В случая има няколко проблема, които спокойно могат да се изолират в стека. Говоря за избор на канал, избор на мощност и т.н. Всеки от тези проблеми може да има повече от едно решение. Решенията може да са конкретни, т.е. да изискват определено поведение от останалите играчи в ефира. Може и да са по-универсални, това няма никакво значение и не е проблем на стека, а на приложението. В смисъл приложението ще реши как да си конфигурира стека, дали да ползва този или онзи протокол или не... Това знам как да го оформя

Въпросът е в самите протоколи/решения/алгоритми... аз сигурно мога да измисля "някакви". Но предвид това, че нямам опит е много по-добре да питам за вече измислени и тествани, вместо да откривам топлата вода по трудния начин...

Въпроса опира до стандарти за стандартните протоколи или за стандарт за използване на ефира за нестандартните протоколи.

В стандартите за стандартните протоколи всичко е разписано как трябва да е. За нестандартните - можеш да мислиш свои или да взаимстваш решения от "стандартните". В крайна сметка обаче трябва да покриеш стандартите за използване на ефира.

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

za ISM мощност не се регулира, бичи се на мах щото понякога в сграда и на 15м нямаш покритие дори и с +10дБм на 433 и качествени антени. Когато отиваш на сертификация не им казвай че фърмуера ти модифицира каквото и да е по отношение на мощността. РФ чиповете трябва да гарантират че при всяко допустимо захранващо напрежение няма да сговняват качеството на сигнала или да увеличат мощността, и това е едно от основните неща които гледат сертификаторите
едит
по отношение на честотата няма нужда от регулиране. Когато се произведе устройството после минава настройка на честота и мощност и после не се пипа. Става супер бързо

Да, в нито един от примерните сорсове не видях някой да си играе да регулира каквото и да е. Очевидно е, че това е масовата практика... За евтините 2.4G модули (RFM73/nrf24xx) това може би е оправдано. В масовия случай тези модули са за до 30-на метра пряка видимост и трудно минават през повече от една стена. Точно поради тези причини мисля да си вържа гащите и с далеч по-сериозно модули, някои от които могат да достигнат и стотина километра при пряка видимост. Очевидно е, че ако два модула стоят на 2м един от друг няма нужда да заглушавам цялата сграда. Още повече, че въпросът не е само за мощност, лентата също има голямо значение.
По принцип може да стане с фиксирани стойности, но фиксирането трябва да е съобразено с конкретната инсталация. Това обаче изисква някой да е наясно и да настрои параметрите. Аз пък предпочитам да не разчитам на инсталаторите. А и понякога при инсталацията условията са едни, после клиента решава да поразмести халето....

Малко да раведрим темата

Мисля че си се захванал с нещо на което му казват overengineering. Няма универсално нещо което да работи навсякъде. Дори и да успееш да го направиш кой мислиш че ще го верифицира? Ако е супер гъвкаво трябва ти някой който да го разбира, поддържа и да го настрои. Не знам за какъв бизнес става дума, но ако смяташ ти да обикаляш и да настройваш тогава кой ще пише и проектира? Винаги има вероятност клиента да размести рафтове и т.н. Както писах по горе, дори и на супер близко разстояние може да нямаш покритие в зависимост от условията. Тогава почва едно ходене по мъките и след една седмица загубено време на отбор инженери за тестове, става ясно че някой инсталатор или продавач не е преценил правилно какво е най подходящо за клиента, ефира е станал супер пренаселен, комшиите са си купили и те същите системи с по 200-300 сензора и тем подобни

Емил по горе написа: скроявай го според конкретните ти нужди...
от това по добър съвет не знам дали има
Също така не виждам практически смисъл да се поддържат 100 различни РФ платформи. Масова практика е когато се разработи нещо с определен чип, после 5-10г се произвежда и се пълни хазната. Всяка промяна, дори и на нещо дребно е разход, и много често е по добре да платиш $1 повече за стара генерация РФ чип, отколкото много хиляди за разработка, сертифициране, документи за производството и т.н.
Едит:
Относно мощността: В болшинството от случаите клиента си купува батериите, така че за това не трябва много много да му се мисли. Ако една литиева батерия издържа 1-1.5 години на това здраве му кажи. След като клиента купи нещото никой няма да ти каже браво за това че си проектирал устройството да изкара 18 месеца вместо 12. Например болшинството от клиентите ни купуват батериите от нас, така че реално нямаме интерес един сензор да изкара 5г, след като още от едно време са научени, че всяка година трябва да се сменят батериите

Очевидно всеки се съобразява с практиката си...
В моя случай нямам практика да печеля от батерии и изобщо от оборот, производство и т.н. Така че ако някой му се наложи да сменя твърде често батерии аз не печеля нищо, напротив, губя щото ще ми реват, че устройството не е проектирано добре. Естествено нито съм толкова добър, нито толкова ми се бачка, нито пък имам безкрайно време та да реша всички проблеми. Така че, спокойно няма да се "преработя"... то и идеята на питането ми беше "някой ако знае примерни алгоритми/решения" да взема да ги скрабна
Сега, ако няма аванта - няма! Ще се спасявам както мога, като стигна до тестове ще преценя има ли смисъл, макар че то е очевидно че с фикснати параметри е кофти...

Относно управлението на мощността - мисля че това е задължително да се имплементира.
Един от вариантите е първоначално излъчваш на МАХ и в зависимост от силата с която чуеш отговора си сетваш мощността. (разбира се трябва да знаеш отговора с каква мощност е излъчен. Това може да се кодира в няколко бита (2-3 примерно) предавани в хедъра на всеки пакет).
Така освен, че ще се спести батерия ще се спести и генерирането на излишно зашумяване на канала.

Всичко това става автоматично и се донастройва на всяка трансмисия.
Ако се загуби комуникация - след 3-ти опит примерно минаваш на МАХ мощност и като получиш отговор - автоматично се донастройваш по нивото с което си го приел.

Относно честотите - може да работиш на една честота и при зашумяване - бягаш на друга.
Друг вариант е Frequency Hopping. Това е по-читавото решение за мен, но е по-сложно за имплементиране, защото се изисква синхронизация на всички устройства.

Важно е и какъв тип/топология на мрежа мислиш да изграждаш. Вариантите наистина са много...

Точно там е една от тънкостите. Защото можеш да броадкастваш до примерно 20 устройства и всяко едно може да иска различна мощност, даже и тези дето до преди малко са искали малка мощност може да се окаже изведнъж, че са попаднали в радиосянката на някой електрокар и има нужда от максимална мощност.

Така е. За това по стандартите пише, че след инсталирането на устройствата трябва да имат надеждна връзка (PER < 1% примерно) между устройствата, когато мощността им е с 6dBm по-ниска от "номиналната" (в случая с 6dBm надолу от автоматично определената мощност на предавателя).

Отделно ако се бродкаства към няколко устройства, може бродкаста да е винаги на МАХ мощност или с най-голямата такава необходима за връзка към най-отдалеченото устройство.
Уникаст връзката обаче няма проблем да си е с автоматично определената мощност.