FrSky Taranis - OT non consentiti

[andreavi90]

Io avrei una domanda sul RSSI, ho fatto delle ricerche ma non sono riuscito a trovare risposta... Qual'è il range di valori dell' RSSI che mi facciano capire che ho un buon segnale? Sotto quale livello rischio di perdere il controllo del modello e di far intervenire il failsafe?
Durante l'ultimo volo ho visto che l'RSSI è arrivato ad un valore minimo di 45 e non riesco ad interpretare il dato.
Inoltre vorrei sapere se è possibile, e come, registrare il log dei valori di RSSI per poterli studiare in un secondo momento.

Grazie mille a tutti

[absinth84]

Originalmente inviato da andreavi90

Io avrei una domanda sul RSSI, ho fatto delle ricerche ma non sono riuscito a trovare risposta... Qual'è il range di valori dell' RSSI che mi facciano capire che ho un buon segnale? Sotto quale livello rischio di perdere il controllo del modello e di far intervenire il failsafe?
Durante l'ultimo volo ho visto che l'RSSI è arrivato ad un valore minimo di 45 e non riesco ad interpretare il dato.
Inoltre vorrei sapere se è possibile, e come, registrare il log dei valori di RSSI per poterli studiare in un secondo momento.

Grazie mille a tutti

Qui da un'ottima spiegazione!
https://opentx.gitbooks.io/manual-fo...ry_values.html

RSSI è in dB e non percentuale quindi al raddoppio della distanza si ha circa una perdita di 6dB.

Indicano come limite con perdita del controllo a 38dB difatti consigliano allarme a 45 e critico a 42

Per il log su sd segui questa guida ma riferisci a rssi invece che alle coordinate gps
https://oscarliang.com/log-gps-coordinates-taranis/

[mpresi]

Originalmente inviato da andreavi90

Io avrei una domanda sul RSSI, ho fatto delle ricerche ma non sono riuscito a trovare risposta... Qual'è il range di valori dell' RSSI che mi facciano capire che ho un buon segnale? Sotto quale livello rischio di perdere il controllo del modello e di far intervenire il failsafe?
Durante l'ultimo volo ho visto che l'RSSI è arrivato ad un valore minimo di 45 e non riesco ad interpretare il dato.
Inoltre vorrei sapere se è possibile, e come, registrare il log dei valori di RSSI per poterli studiare in un secondo momento.

Grazie mille a tutti

Come già detto, i valori 45/42 preimpostati sono valori ragionevoli.

RSSI di FrSky, per il protocollo ACCST *non* è in dB. E' un valore misto di RSSI e link-quality. Quindi non è esattamente vero che il valore scende di 3 dB quando raddoppia la distanza. Diciamo che questo discorso vale per valori di RSSI sopra i 60 (con ACCST). In ACCESS invece hanno disaccoppiato gli indicatori, quindi l'RSSI è *puro*. Occhio però, in entrambi i protocolli, il valore di RSSI non è uniforme.. ogni ricevente ha il suo range ottimale.

Ci sono due modi per determinare il valore soglia. Uno empirico, ed uno quantitativo.

Quello empirico è quello del range test: metti la radio un modalità RANGE, ti allontani di 50/100 metri e prendi nota del valore di RSSI a cui inizi ad avere i telemetry lost/telemetry recovered (fail safe) e quando i servi non si muovono più. Questa è ovviamente una prova da fare in due.

Il secondo metodo, è quello di costruire ed installare un sensore basato su Arduino Nano, ben descritto qui[1]: ti consente di misurare il rate di pacchetti ricevuti correttamente, e quindi di determinare esattamente come è la qualità del tuo segnale. Ricorda che l'RSSI è solo un indicatore di potenza ricevuta, non necessariamente indica la qualità del link! Con questo strumento abbiamo misurato fail-safe di pochissimi millisecondi anche con RSSI relativamente alti (interferenze radio significative introdotte di proposito). Di questi sensori ne abbiamo costruiti diversi, funzionano molto bene e ci hanno consentito di fare misure molto precise fino a distanze di 1 km (dove avevamo l'indicatore link quality maggiore del 70%). Non solo, ci hanno permesso di individuare "errori" nel posizionamento delle antenne (sia sui modelli che sulle trasmittenti), risolti i quali la qualità del link è migliorata significativamente.

Con questo strumento a bordo, di fatto, sapere l'RSSI non serve più.

Abbiamo anche misurato miglioramenti netti con il nuovo firmware 2.1.0, che però non è rilasciato per tutte le riceventi.

Se hai bisogno di chiarimenti per realizzare questo sensore, chiedi pure.

Per il log dei valori di telemetria, mi pare ti abbiano già risposto.

[1] https://www.rcgroups.com/forums/show...nsor-for-FrSky

[davinja]

Originalmente inviato da andreavi90

Io avrei una domanda sul RSSI, ho fatto delle ricerche ma non sono riuscito a trovare risposta... Qual'è il range di valori dell' RSSI che mi facciano capire che ho un buon segnale? Sotto quale livello rischio di perdere il controllo del modello e di far intervenire il failsafe?
Durante l'ultimo volo ho visto che l'RSSI è arrivato ad un valore minimo di 45 e non riesco ad interpretare il dato.
Inoltre vorrei sapere se è possibile, e come, registrare il log dei valori di RSSI per poterli studiare in un secondo momento.

Grazie mille a tutti

Il valore RSSI nel protocollo ACCST é un mix tra l'intensità del segnale ricevuto (RSSI) e il numero di pacchetti persi, per quello che si è recentemente appreso. Il tutto gestito da un algoritmo FrSky.
Quindi in modulazione ACCST il dato RSSI di fatto non contempla solo l'intensità ma anche la bontà.
In Access non è più così dall'ultima release del FW V2. 1.0. che registra sia il valore puro RSSI (receiver signal strenght indicator) che quello FL (Frame loss) o LF (Lost frames).
Questo pippone per dire che il valore dipende da che protocollo usi, infatti mentre i valori soglia e critici in ACCST sono 45 e 42 in ACCESS sono 35 e 32 perché con ACCESS devi controllare anche il dato FL per giudicare la bontà della ricezione.
Normalmente una ricevente in ACCST con radio nel raggio di 3 metri oscilla da 100 a 85 a seconda dell'orientamento antenne rx e tx. In volo anche a distanze sui 200 metri puoi leggere 45, dipende dall'orientamento delle antenne rx rispetto la tx. Di solito il grafico del valore telemetrico RSSI su Companion fa vedere un picco negativo e poi il valore si riporta sopra i 50 - 55, indicativo di una virata o messa in ombra delle antenne per manovra (tonneaux, volo a coltello...)
Per vedere la registrazione del dato telemetrico RSSI basta andare nella pagina telemetria e assicurarsi che il sensore RSSI abbia la spunta del campo LOG (credo lo sia per default ) Questo abilita la registrazione del dato del sensore. Perché la registrazione avvenga sulla radio devi andare su Funzioni Speciali e attivare la funzione SD Logs (sotto interruttore fisico o logico o sempre attiva) . Questa registrazione la troverai nella cartella LOGS della SDcard, una registrazione (file) al giorno, con all'interno la possibilità di vedere i vari voli usando Companion.
Per default i valori allarme valore minimo e critico in ACCST sono impostati a 45 e 42 e danno luogo ad avvisi vocali della radio. Immagino tu abbia impostato la lettura del valore telemetrico RSSI- che registra il valore RSSI minimo del volo, di per sé leggere 45 non è preoccupante. Solo attraverso la lettura del log RSSI puoi capire se é il caso di preoccuparti, se la media rimane oltre 50 e ci sono alcuni picchi negativi siamo nei casi citati sopra, se il valore rimane costantemente su 45 e non é giustificato da distanze notevoli oltre 500 m allora bisogna approfondire. Io confronto il valore RSSI con quello della distanza e noto che proprio in virata scende (volo pendio, limite sx e dx della planata); in qualche caso ho notato che proprio mentre mi passa di fronte il segnale diminuisce anche se la distanza é minima, perché il modello mi espone il fianco dell fusoliera e in quella posizione forse l'antenna va in ombra.
Comunque visto che in tutti i casi il valore 45 è stato un picco negativo momentaneo la radio non mi ha mai dato allarme, cosa che fa invece quando in modalità RANGE mi allontano così tanto da leggere valori inferiori a 45 continuitivamente.
Spero di essere stato chiaro.

[absinth84]

Originalmente inviato da mpresi

Come già detto, i valori 45/42 preimpostati sono valori ragionevoli.

RSSI di FrSky, per il protocollo ACCST *non* è in dB. E' un valore misto di RSSI e link-quality. Quindi non è esattamente vero che il valore scende di 3 dB quando raddoppia la distanza. Diciamo che questo discorso vale per valori di RSSI sopra i 60 (con ACCST). In ACCESS invece hanno disaccoppiato gli indicatori, quindi l'RSSI è *puro*. Occhio però, in entrambi i protocolli, il valore di RSSI non è uniforme.. ogni ricevente ha il suo range ottimale.

Ci sono due modi per determinare il valore soglia. Uno empirico, ed uno quantitativo.

Quello empirico è quello del range test: metti la radio un modalità RANGE, ti allontani di 50/100 metri e prendi nota del valore di RSSI a cui inizi ad avere i telemetry lost/telemetry recovered (fail safe) e quando i servi non si muovono più. Questa è ovviamente una prova da fare in due.

Il secondo metodo, è quello di costruire ed installare un sensore basato su Arduino Nano, ben descritto qui[1]: ti consente di misurare il rate di pacchetti ricevuti correttamente, e quindi di determinare esattamente come è la qualità del tuo segnale. Ricorda che l'RSSI è solo un indicatore di potenza ricevuta, non necessariamente indica la qualità del link! Con questo strumento abbiamo misurato fail-safe di pochissimi millisecondi anche con RSSI relativamente alti (interferenze radio significative introdotte di proposito). Di questi sensori ne abbiamo costruiti diversi, funzionano molto bene e ci hanno consentito di fare misure molto precise fino a distanze di 1 km (dove avevamo l'indicatore link quality maggiore del 70%). Non solo, ci hanno permesso di individuare "errori" nel posizionamento delle antenne (sia sui modelli che sulle trasmittenti), risolti i quali la qualità del link è migliorata significativamente.

Con questo strumento a bordo, di fatto, sapere l'RSSI non serve più.

Abbiamo anche misurato miglioramenti netti con il nuovo firmware 2.1.0, che però non è rilasciato per tutte le riceventi.

Se hai bisogno di chiarimenti per realizzare questo sensore, chiedi pure.

Per il log dei valori di telemetria, mi pare ti abbiano già risposto.

[1] https://www.rcgroups.com/forums/show...nsor-for-FrSky

dB è una unità di misura logaritmica quello forse che vuoi intendere è che frsky non passa direttamente il vero RSSI (potenza del segnale) ma lo miscela con la qualità del link (penso usi una forma di BER) appunto per dare un valore più consono in quanto la sola potenza potrebbe essere fuorviante.
Si leggevo anch'io su rcgroup che hanno chiesto espressamente di separare i 2 valori

[mpresi]

Originalmente inviato da absinth84

dB è una unità di misura logaritmica quello forse che vuoi intendere è che frsky non passa direttamente il vero RSSI (potenza del segnale) ma lo miscela con la qualità del link (penso usi una forma di BER) appunto per dare un valore più consono in quanto la sola potenza potrebbe essere fuorviante.
Si leggevo anch'io su rcgroup che hanno chiesto espressamente di separare i 2 valori

si, appunto, per quanto ci è dato sapere non è logaritmico (su ACCST). Più che una forma di BER (Bit Error Ratio) è una misura del rapporto della percentuale di pacchetti corrotti sul totale dei pacchetti ricevuti nell'unità di tempo (lost frames rate). Quale sia la formula con cui i due dati vengono "miscelati" non è dato sapere....

Il sensore di cui sopra, misura il numero di pacchetti corrotti in tempo reale. La misura, è fatta in questo modo: la trasmittente viene programmata in modo da generare su un canale una forma d'onda triangolare che si ripete all'infinito. Il sensore confronta la forma d'onda triangolare con quella attesa, ed in base a questo confronto determina quanti pacchetti non sono stati ricevuti correttamente. Parlo di pacchetti, non di bit, perchè se c'è un errore, il protocollo scarta tutto il pacchetto.
Su rcgroups il metodo è descritto molto dettagliatamente.


Approfitto per "pubblicizzare" una campagna di test che stiamo effettuando con altri amici di rcgroups. E' una prova molto semplice, che richiede una ventina di minuti principalmente per scopi "statistici".
Chi è interessato mi mandi un messaggio privato (@davinja, nel pomeriggio ti chiamo e te ne parlo).

Ciao Ciao

Marco

[absinth84]

Originalmente inviato da mpresi

si, appunto, per quanto ci è dato sapere non è logaritmico (su ACCST). Più che una forma di BER (Bit Error Ratio) è una misura del rapporto della percentuale di pacchetti corrotti sul totale dei pacchetti ricevuti nell'unità di tempo (lost frames rate). Quale sia la formula con cui i due dati vengono "miscelati" non è dato sapere....

Il sensore di cui sopra, misura il numero di pacchetti corrotti in tempo reale. La misura, è fatta in questo modo: la trasmittente viene programmata in modo da generare su un canale una forma d'onda triangolare che si ripete all'infinito. Il sensore confronta la forma d'onda triangolare con quella attesa, ed in base a questo confronto determina quanti pacchetti non sono stati ricevuti correttamente. Parlo di pacchetti, non di bit, perchè se c'è un errore, il protocollo scarta tutto il pacchetto.
Su rcgroups il metodo è descritto molto dettagliatamente.


Approfitto per "pubblicizzare" una campagna di test che stiamo effettuando con altri amici di rcgroups. E' una prova molto semplice, che richiede una ventina di minuti principalmente per scopi "statistici".
Chi è interessato mi mandi un messaggio privato (@davinja, nel pomeriggio ti chiamo e te ne parlo).

Ciao Ciao

Marco

Ho dato un'occhiata al progetto e è piuttosto interessante.. purtroppo non ho sotto mano un arduino pro mini potrei tentare il porting su un ESP8266/32. Unica cosa bisogna passare tutto a FW 2.x

[mpresi]

No, funziona anche col v1.

..e cmq visto i bug che risolve (e che a me ha risolto...) Perché non passare?



Inviato dal mio Redmi Note 8T utilizzando Tapatalk

[marcodef]

Originalmente inviato da mpresi

si, appunto, per quanto ci è dato sapere non è logaritmico (su ACCST). Più che una forma di BER (Bit Error Ratio) è una misura del rapporto della percentuale di pacchetti corrotti sul totale dei pacchetti ricevuti nell'unità di tempo (lost frames rate). Quale sia la formula con cui i due dati vengono "miscelati" non è dato sapere....



Il sensore di cui sopra, misura il numero di pacchetti corrotti in tempo reale. La misura, è fatta in questo modo: la trasmittente viene programmata in modo da generare su un canale una forma d'onda triangolare che si ripete all'infinito. Il sensore confronta la forma d'onda triangolare con quella attesa, ed in base a questo confronto determina quanti pacchetti non sono stati ricevuti correttamente. Parlo di pacchetti, non di bit, perchè se c'è un errore, il protocollo scarta tutto il pacchetto.

Su rcgroups il metodo è descritto molto dettagliatamente.





Approfitto per "pubblicizzare" una campagna di test che stiamo effettuando con altri amici di rcgroups. E' una prova molto semplice, che richiede una ventina di minuti principalmente per scopi "statistici".

Chi è interessato mi mandi un messaggio privato (@davinja, nel pomeriggio ti chiamo e te ne parlo).



Ciao Ciao



Marco

Interessante.

Ci guarderò bene, non capisco una cosa però: se misuri l’uscita di un canale di fatto stai misurando degli eventi di interferenza. I transceiver per forza di cosa filtra i pacchetti persi, altrimenti che senso ha ?

Mi sono perso qualcosa?




Sent from my iPhone using Tapatalk

[absinth84]

Originalmente inviato da mpresi

No, funziona anche col v1.

..e cmq visto i bug che risolve (e che a me ha risolto...) Perché non passare?



Inviato dal mio Redmi Note 8T utilizzando Tapatalk

Perchè in aggiunta alla taranis ho appena preso radiomaster tx16s con modulo multiprotocollo e accst 2.1.0 è appena stato aggiunto al supporto, volevo essere un po cauto.