ISRM a "authenticating"

[Jan Urbánek]

Trochu predbehnu FrSky
Novy firmware pro moduly bude fungovat takto.
Po spusteni bude provedena autentifikace, pokud projde jiz se nebude opakovat do dalsiho spusteni. Pokud neprojde, bude komunikace zastavena a uzivatel informovan.

[ellet]

Vím, že to píšu zbytečně, ale prostě mně to nedá. Když dojde k mžikovému výpadku napájení nebo něco podobného co si vynutí novou autentizaci za letu a ta selže, oznámení asi uživatele moc nepotěší.
Optimální průběh vidím takto. Po zapnutí vše funkční, potom test, při neúspěchu několikanásobný (cca 3x po 1s ?). Teprve potom odtavit radio. Jde o to, aby za letu, při opakovaném testu, nedošlo k výpadku řízení.Ty cca 3 sekundy by snad FrSky mohla tolerovat.
Rozdíl je v tom, že řízení by mělo fungovat po zapnutí a ne až po autentifikaci.
(K tomu, že to asi bude fungovat obráceně mě vedou informace z jiných zdrojů)

[Jan Urbánek]

Z jakych jinych zdroju? Zadne oficialni stanovisko zatim nebylo zverejneno.

Co ma za smysl ridit 3s a pak stejne vypadek? Pokud radio vypadne kvuli napajeni, je mnohem vetsi sance ze bude problem v baterii, konektoru, pameti modelu ktera se muze poskodit, pameti nastaveni radia a mnoho dalsich casti ktere radio nenchaji nabehnout.
Autentifikace casti pri startu je naprosto bezna u elektorniky kazdodeniho uziti a ze by nekde neco bezne havarovalo...

Obecne nam informace dava vedet, ze nebude dochazek k nepretrzitem overovani ale pouze pri startu. To jestli tam je nekolik pokusu nebo jen jeden uz jsou dalsi detaily dane procedury.

[ellet]

Z jiných zdrojů = drby z netu a taky o žádným oficiálním stanovisku nepíšu. Pokud ale tato varianta hrozí, není to dobře. A co má za smysl řídit 3s ... svědčí o nepochopení mého příspěvku (asi se špatně vyjadřuji) naopak, jde o to, že k výpadku nedojde vůbec (!) a to ani po resetu nebo podobné události. Rovněž opakování má význam. Pravděpodobnost chyby na sběrnici není nulová a ztracený paket s dotazem by měl za následek ztrátu kontroly nad modelem.

[Jan Urbánek]

Ja tomu nerozumim, nejdriv mluvite o vypadku a pak ne, zkuste me to vysvetlit v cem vidite to nebezpeci. Idealne priklad

[ellet]

Jsou dvě možnosti:
1. Po zapnutí řízení nefunguje. Řízení začne "fungovat" po zdařilé autentifikaci.
2. Po zapnutí řízení funguje. Řízení bude "odstaveno" po nezdařilé autentifikaci.
Pokud dojde k problému za letu (vím, že by k tomu dojít nemělo - ale jenom nemělo) na př. ke krátkodobému výpadku napájení vlivem špatného kontaktu baterie a dojde k resetu procesoru, dojde k nové autentifikaci a v případě 1. bude výpadek v řízení, v případě 2. k výpadku řízení nedojde ani při opakovaném testu, pokud bude poslední test, při opakovaném testování, úspěšný.
Pokud bude test v případě neúspěchu prováděn opakovaně, bude se v přídadě 1. výpadek v řízení prodlužovat.

[Jan Urbánek]

Dobre vezmeme to zjednodusene.

At dojde k vypadku napajeni nebo resetu watchdogem ridi modul hlavni CPU.
Hlavni CPU nabehne v nouzovem rezimu a spusti modul ten nabiha oproti CPU blezkove.
Modul si zada o identifikaci radia a CPU odpovida, pokud selze, opakuje to, pocet pokusu jsou 3.
Pokud modul dostane spravnou odpoved je odemcen do dalsiho vypnuti.
Pokud modul nedostane odpoved zustava uzamcen.

[ellet]

Dobrá, zjednoduším to ještě víc a vynechám všechno kromě modulu.

Modul by měl být "odemčen" hned po aktivaci, potom teprve autentifikace...
a bude to bez výpadku řízení při případné další autentifikaci. To odpovídá algoritmu z bodu 2.

Potom by Vaše věty:
"Pokud modul dostane spravnou odpoved je odemcen do dalsiho vypnuti.
Pokud modul nedostane odpoved zustava uzamcen."
mohly být:
"Pokud modul dostane spravnou odpoved zůstane odemcen do dalsiho vypnuti."
Pokud modul nedostane odpoved bude uzamcen."

Jde o prostou negaci, která zabrání výpadku řízení modelu během provádění autentifikace. Pravda je, že pokud bude test prováděn rychle za sebou, nemusí být výpadek řízení modelu pozorovatelný. Ale nechme to být. Uvidíme, snad nás FrSky mile překvapí

[Jan Urbánek]

My se ale nebavime o sekundach kdy mozna Vase predstava je ze modul se pta kazdou sekundu nez se odemce ale bavime se o ms.
Tzn po startu modulu je vznesen dotaz, bez tak neni mozne ovladat protoze do te doby startoval CPU, dotaz je odbaven v ms pokud nedojde k odpoveti je opakovan dotaz zase v radu ms toto se deje 3x.
Vsechny dotazy jsou odbaveny za podstatne mene nez 100ms tedy za mene nez 1/10 sekundy a to rizeni neovlivni.

Cely mechanizmus jsem dnes probiral jak s FrSky tak OpenTX, vse je nacasovano tak, aby bylo zajisteno, ze modul ma dostat odpoved uz na prvni dotaz, tzn 2 dalsi jsou zaloha pro sum na sbernici atp. Celkove zpozdeni startu modulu je tak do 10ms a to ani ne pokud dostane odpoved na prvni dotaz.

[ellet]

Tak tahle odpověď se mně konečně líbí. Ten test 3x byla jen moje úvaha a jsem rád, že to tak bude. To samé platí o prodlevě mezi testy. Taky nevidím důvod proč s opakováním testu čekat.
(A taky jsem rád, že jste se nechal vyprovokovat ke konzultaci mechanizmu s FrSky a OpenTX, někdo za nás musí "kopat". . Byl to trochu můj cíl.) Děkuji.

[Jan Urbánek]

Ty informace bych dostal s novou verzi FW, jen jsem si je vyzadal driv. Na rovinu rikam, ze kdyby Jumper neblbnul s pokusy zneuzit nas modul a protokol tak by toto nebylo potreba.

[Macil]

No, myslím, že keď z nejakého dôvodu dôjde k resetu, už to je problém, bez ohľadu na to, ako rýchlo sa dokáže CPU z toho pozbierať, zvlášť ak k tomu dôjde z dôvodu výpadku, alebo výpadkov napájania.

[ellet]

Doba zotavení systému je při návrhu jedna ze zásadních věcí. A taky proto nový firmware pro dodatečně montovanou ISRM (s datem 11.11) - testy neprošel. (Přijatelný algoritmus je přitom tak jednoduchý. Nevěřím, že za to co se kolem toho děje, můžou vývojáři.)

[Jan Urbánek]

Dnes vysel update, ktery opravuje divne chovani, cekame na openTx aby odemcel internallaccess kompilaci a posledni pozadavky FrSky .

[ellet]

No výborně, teď jsem to četl a řízení vysadí až po posledním neúspěšným testu. Před testem bude řízení fungovat.....(a že to píšu od začátku, snad si tu kartu teď i koupím )