VFRFlight forum, Aviazione Generale, VDS, Ultraleggeri

TCASP = traffic collision avoidance system dei poveri.

l'ispirazione mi e' venuta quando, partendo da LFSA in direzione est per poco non mi sono preso con un eli che veniva in senso opposto

2014, e ancora un anticollisione accessibile a non-nababbi non esiste? assurdo.

dopo una lunga telefonata col berta, esperto totale in materia, ho deciso di costruire un POF (proof of concept) basato ovviamente su un arduino. si tratta di un dimostratore e non certo di un dispositivo finale, ma vorrei dimostrare come costruire una specie di TCAS stand-alone sia possibile anche per amatori, usando hardware off-the-shelf che costa pochi euro

ma siccome non ho tempo per ravanare, e sto scrivendo un libro, mi servono collaboratori che scrivano il codice e che mi consiglino su questioni di trigonometria.

eventualmente da proporre per esempio alla EMF


l'idea e' di fare un progetto open hardware/software, quindi soldi pochi ma gloria potenzialmente molta. se poi qualcuno volesse provare a farci qualche lira sopra e trova il sistema, welcome

chi fosse interessato si faccia avanti.

se trovo complici che mi scrivano un po di codice arduino, vi espongo l'idea di base

l'arduino per programmare e provare il codice ve lo regalo.

(http://www.gliffy.com/go/publish/image/6404160/L.png)

Faccio relay con i nostri potenti mezzi.

racconta, racconta...

Il progetto e' interessante e particolarmente semplice, ma solo una domanda: il broadcast cosa sarebbe? Ovvero con cosa "broadcasti"?

Mario

Il diagramma di flusso non è fantastico ma rende l'idea! Lo inoltrerò ai miei colleghi informatici.

e' un periodaccio. quindi accontentatevi dei diagrammi scadenti :D che comnunque sono molto di massima e vanno raffinati.


broadcast: un tcasp che trasmette a tutti gli altri la sua posizione/quota/velocita'/direzione di movimento.


ogni tcasp ha un ricetrasmettitore, che nornalmente e' in ricezione, per ricevere i broadcast di eventuali aerei intorno

ogni tot secondi, tre e' un numero sparato a caso, il ricetrans va in trasmissione e fa un broadcast di posizione, quota, rotta e veocita'

si presume che i trasmettitori abbiano una portata di qualche km, di piu' non serve

i ricetrans che conto di utilizzare gia' possiedono di loro meccanismi che evitano "collisioni", cioe' trasmissioni mentre qualcunaltro sta gia' trasmettendo
una trasmissione dura pochi millisecondi, in tre secondi ce ne stanno centinaia, ergo le probabilita' di collisione sono minime. un ritardo/anticipo random del broadcast impedisce ulteriormete le collisioni di packets

sto producendo alcuni dump NMEA, che comunque ognuno puo' prodursi usando il suo smarphone e le app apposite

se per esempio registrate il dump NMEA percorrendo una strada in auto in un senso e poi in senso opposto potete produrre due dump utilizzabili per simulazioni

ho gia' trovato alcune librerie  utili per fare i calcoli

appena ho tempo posto info aggiuntive

Sposto in hi-tech?

no, lascialo qui che cosi posso mantenere il controllo

caso mai in hi-tech puoi mettere un post che redirige qui

comunque vedi tu che sei il padrone della baracca

Quanto costerebbe meno di un FLARM?

http://www.flarm.com/ (http://www.flarm.com/)

(http://www.flarm.com/images/ECW100_3D_freigestellt_210x195.png)

molto meno

ma non e' solo quello

sarebbe innanzitutto una dimostrazione di cosa e' possibile fare con economica elettronica off-the-shelf  e con iniziativa privata

magari solo una cosa da nerd, ma poi magari qualcuno prende l'idea e la industrializza, e costringe i flarm a scendere di prezzo....

scommetto che un cinese riuscirebbe a produrre e vendere un tcap a 99 euro, guadagnandoci bene

Qui http://geomalgorithms.com/a07-_distance.html (http://geomalgorithms.com/a07-_distance.html) trovi tutta la matematica e il codice che ti serve. A te interessa solo il capitolo tre "Closest Point of Approach (CPA)", in cui si calcola la minima distanza tra due oggetti in R^n con velocità costante; non sono neanche 30 righe di testo.

Al capitolo quattro trovi l'implementazione del metodo, in C++.

grazie mille!!

Io ho un background forte di HW/SW realtime in ambito militare, avendo fatto più volte il percorso dall'idea vaga alla realizzazione dei prototipi, allla validazione hands on, al test in campo (mica in un paio di settimane, però... lol). Mi metto ben volentieri a tua disposizione per consulenza o quello che ti serve, ad esempio per la trasposizione di algoritmi floating point trigonometrici in matematica intera realtime. A me risulta che il codice di Arduino sia C realtime però, non un C++. Buon peso: una bella discussione tecnica critica prima di consolidare il sistema sulle modalità, gli algoritmi, le scelte è sicuramente un'area nella quale il mio porco contributo te lo posso dare. So programmare perfettamente sistemi realtime, ma non ho il tempo per assumermi l'onere complessivo. Che cmq continui il cercasi, dunque.

cosa ha di diverso dal power flarm ? o vorresti creare un terzo modo di broadcastare la tua posizione ?
So che arduino é una figata, ma riceve/trasmette anche sul 1 ghz, la frequenza del transponder ?

Se sei in formazione potrebbe darti la posizione degli altri ?




Luigi

Il flarm fa esattamente la stessa cosa. Calcola posizione e velocità col gps. Invia il segnale sulla 868MHz. Riceve gli altri segnali. Prevede le collisioni.

Arduino (20€) non riceve ne trasmette nulla... devi abbinargli un hardware che gestisce le trasmissioni radio (10€). Oltre all'hardware che gestisce il gps (15€). A 'sto punto, fallo interoperabile coi flarm. Il software del flarm è protetto, ma non sarà un problema riscriverlo. Il protocollo radio del flarm è protetto ma è stato crackato anni fa e lo trovi qui http://www.dotmana.com/weblog/wp-content/uploads/FLARM-RADIO-PROTOCOL-VERSION-4-2008.txt (http://www.dotmana.com/weblog/wp-content/uploads/FLARM-RADIO-PROTOCOL-VERSION-4-2008.txt) .

Eheh, vedo che determinate eccezioni che ho fatto a GM nella lunga telefonata che abbiamo fatto qualche giorno fa (1h30'!) sono state riproposte anche da altri...  ;)

Su FLARM, e' stata fatta anche una implentazione su GNUradio:
https://github.com/argilo/gr-flarm (https://github.com/argilo/gr-flarm)

e su RTL-SDR, che fa SDR (software defined radio) usando stick USB da 10 euro o giu' di li':
http://www.rtl-sdr.com/receiving-decoding-flarm-tracking-gliders-helicopters-etc-using-rtl-sdr/ (http://www.rtl-sdr.com/receiving-decoding-flarm-tracking-gliders-helicopters-etc-using-rtl-sdr/)

Il protocollo e' quindi ben noto. Potrebbe essere interessante trasmettere sulla 868 MHz invece che solamente ricevere... un FLARM open source ed open hardware, in buona sostanza.

wow, diventerebbe anche un ottimo aggeggio da mettere in tasca volando col parapendio, paracadute ecc.
Magari sfruttando il Bluetooth e il GPS dello smartphone. Il passo successivo è per i modellini e droni.
Invece mi chiedo se sarebbe il caso di orientare 3 antennette per captare anche la direzione di provenienza di un segnale transponder C mode.

Attendo ansioso l' arduino di Crono.

grazie per i contributi

ovviamente mi sono chiesto anche io perche' non il flarm? non lo so, sta di fatto che per qualche motivo la comunita ulm non lo ha mai preso in considerazione. personalente ho visto qualche pcas, ma mai un flarm su un ulm

l'idea e' quella di fare un dimostratore che provi che sia possibile costruire un simil-flarm a costi superbassi. se poi e' possibile implementare interoperabilita' col flarm  ma a un quinto o meno del costo, sono certo che molta piu' gente lo prenderebbe in considerazione.

cosi a spannometro costruire un tcasp basato su hardware off-the-shelf dovrebbe essere piuttosto semplice, e certamente economicissimo

se poi non se ne fa nulla, perlomeno potremmo dire che lo abbiamo fatto e che funzionava

a questo punto chiedo, chi di voi non aliantisti ha il flarm, e chi non lo ha, perche' non lo ha?

Da anni uso un pcas funziona egragiamente con una limitazione importante. Infatti mi segnala il traffico nelle vicinanze in un raggio di 3/5 miglia danomi solo la quota ma non la posizione.

Non ho il flarm, perchè in Italia non lo ha praticamente nessuno. Finora ho conosciuto solo 1 aliantista con flarm montato. Anche lui però non lo usa, se lo è ritrovato assieme all'aliante di seconda mano acquistato in Germania.
Io sarei disposto ad acquistare un avvisatore, e pagarlo al massimo 1500€, a patto che mi segnasse tutti i Flarm,  la direzione e quota dei transponder C ed interpreti il protocollo dei trx S.
Penso che sarebbe realistico piazzarne 3000 in Europa in 4 anni a 700€+iva = 2.100.000 €
oppure 12.000 a 200€+iva =2.400.000 €

Per contro, in Germania, gli elicotteri dell' esercito e della polizia hanno montato il Flarm. Hanno trovato una scappatoia legale per montarlo sui loro mezzi certificati. Qui si vede il diverso modo di ragionare.

Sul FLARM c'è da dire che nasce e si diffonde essenzialmente nel mondo degli alianti.
Anche lui, come la radio, ha il problema che segnala alcuni traffici e ne omette altrettanti (tutti gli alianti senza impianto).
Questo può dare un falso senso di sicurezza, esattamente come la radio: non tutti i traffici nelle vicinanze sono in contatto.

Volando vicino alle nubi io l'ho trovato veramente utile visto che ti segnala:
- la direzione rispetto al tuo aereo del velivolo più vicino
- se l'altro è sopra o sotto di te
- se è vicino o lontano (lampeggiando)

I difetti sono appunto:
- che non tutti gli alianti lo hanno
- che ti fa concentrare su UNA possibile collisione ma potrebbero esserci altri aerei
- che tende ad assorbire la tua attenzione e ti porta a guardare meno fuori per cercare gli altri traffici (questo è in realtà un difetto del pilota e non dello strumento!).

Dove volo io non è diffuso mentre mi dicono che in Germania lo hanno tutti.
Per chi non lo conosce è fatto più o meno così
http://www.ediatec.ch/pdf/Betriebshandbuch_V_5_1i.pdf (http://www.ediatec.ch/pdf/Betriebshandbuch_V_5_1i.pdf)

Per l'idea di Crono, che io trovo molto molto interessante, valgono le stesse considerazioni ...

Saluti Arturo

Non ho capito bene come funziona.
Rileva solo i mezzi che hanno  il FLARM o come il PICAS  rileva i mezzi con TRASPONDER?.

Il FLARM fa specie a se: rileva solo i mezzi che lo hanno.
Normalmente gli alianti non hanno trasponder (non hanno una grossa capacità di alimentazione di carichi elettrici e non vanno in zone controllate).

Ciao Arturo

Sarà un sistema a sé stante e rileverà solo gli apparecchi dotati del medesimo impianto.
A cosa servirà? GM lo ha già affermato un paio di volte:

se poi viene sviluppato abbastanza (cosa non complicata) e qualche federazione nazionale lo adotta, voita'.

mariko, hai installato quell'allarme?

 :( ti spiegherò  :(

Su PostFrontal si parla di qualcosa molto simile:
http://www.postfrontal.com/forum/topic.asp?TOPIC_ID=7700&whichpage=1 (http://www.postfrontal.com/forum/topic.asp?TOPIC_ID=7700&whichpage=1)

Fantastico!

molto interessante, lo devo leggere con calma

Da quel bel thread sul forum degli aliantisti ho trovato questo repo su GitHub che ha una bella presentazione con dei prototipi che sono stati realizzati e testati in volo.

Qui il repo su GitHub:
https://github.com/lyusupov/Argus

Qui la presentazione, vale la pena di leggerla:
https://github.com/lyusupov/Argus/raw/master/doc/Presentation_of_DIY_Airborne_Proximity_Warning_Device.pdf

Molte delle cose di cui abbiamo parlato sono presenti qui, GM, dacci un occhio.

L

you bet

ma non questa settimana, sono onsite sino a venerdi

volevo puntualizzare una cosa a proposito del tcasp, flarm, ads-b etc

giustamente al telefono il berta mi faceva presente che non avrebbe senso mettersi a ideare e costruire un aggeggio alternativo o concorrente alla soluzione "ufficiale" gentilmente concessaci dagli onnipotenti enti: l'ads-b

http://en.wikipedia.org/wiki/Automatic_dependent_surveillance-broadcast (http://en.wikipedia.org/wiki/Automatic_dependent_surveillance-broadcast)

invece secondo me il senso c'e'.
innanzitutto l'ads-b non e' un anticollisione ma un sistema di gestione e controllo centralizzato del traffico aereo.

secondo, e' la tipica soluzione studiata da enti governativi. spaventosamente complessa e dai tempi di implementazione biblici.

terzo, essendo basata su frequenze dedicate e ufficiali, potranno essere usati solo aggeggi certificcati, ergo c'e' il grosso rischio che si finisca come per i vetusti transponder mode C, che tuttora costano cifre ridicole.

quarto, la soluzione attualmente utilizzabile implica l'installazione di un xpndr mode S, nonche' di un ricevitore ADS-B, e un gps e' anche necessario. siamo sui 4000 euro nella migliore delle ipotesi. e passeranno anni prima che tutta la flotta di AG si doti di xpndr mode S, mentre la flotta di ulm e altri aggeggi volanti non se ne dotera' mai, a questi costi, ingombri e burocrazia.
io non mi metterei un mode S anche solo per evitare di dover far sapere a mezzo mondo dove vado a farmi i cazzi miei. 

da quel che vedo. ancora molti enti aeronautici non sono equipaggiati per la ricezione di mode S o di ADS-B, il che e' ridicolo, visto che nel frattempo una comunita' di appassionati e hobbisti ha implementato una rete di ricezione ADS-B pressoche globale.
quindi confermo, aspettare che la cosa venga implementata richiedera' anni, non prima del 2020, molto probabilmente di piu' in quanto ci sono ovvie resistenze alla adozione di aggeggi che renderebbero ridondanti certi tizi chiamati controllori.



sia inoltre ben chiaro che tutto questo ambaradan del ADS-B non e' stato pensato per il VDSaro o il parapendista, ma per il volo commerciale ed eventialmente per la AG.

per cui sono pronto a scommettere qualunque cosa che costi e tempi biblici saranno inevitabili.

hanno fatto benissimo quelli che hanno sviluppato il FLARM, che pero' ha un grave difetto: non ha concorrenti.

anche il FLARM costa decisamente troppo per quello che fa, e un po di concorrenza gli farebbe solo bene

quindi penso che la comunita' del volo da diporto debba svilupparsi soluzioni alternative economiche e attraenti, in tempi ragionevoli.

la gestione del traffico aereo attuale e' un tragico e ridicolo anacronismo. la collision avoidance e' una buffonata, che diventa una non entita' nel caso del volo leggero. sarebbe ora di svecchiare e migliorare un po la situazione.

poi che frequenza usare non importa. un transceiver a bassa potenza costa zero. basta che il tutto sia costruito in modo da essere aperto e modulare, e tanto economico da poter regalare  a quei cazzoni dei parapendisti un transponder che almeno trasmetta dove minchia sono. 

Crono se può interessarti il concorrente del flarm c'è ed è pure italiano si chiama DSX ed è compatibile con il flarm ed utilizzato sempre nel volo a vela vai sul sito postfrontral dovresti trovare qualcosa. Ciao Roberto.

Sarebbe interessante implementare la tua idea con il dsx o flarm con visualizzazione dei traffici sul GPS cartografico. Comunque il flarm è diffuso anche in Italia tra i volovelisti. Concordo Per essere efficace dovrebbero averlo tutti. Ho volato a Rieti con il flarm bellissimo ha individuato un altro aliante dietro ad un costone dove non potevo vederlo in più i traffici vicini se non sono in conflitto non li segnala per evitare di suonare in continuazione.

ho fatto una rapida ricerca ed ho trovato il sito di DSX:

http://www.d-s-x.net/ (http://www.d-s-x.net/)

Peccato solo che dia questa risposta...

Comunque è un oggetto che si posiziona anche lui sui 700€
http://www.spina-bac.biz/catalog/index.php?cPath=24_31 (http://www.spina-bac.biz/catalog/index.php?cPath=24_31)

La funzione del modulo è (o era?) quella di rilevare la posizione per poi passarla al computer di volo per visualizzarla e di passarla alle stazioni a terra per poter seguire da remoto una gara o simili.
L'altro prodotto è un logger certificato, elemento fondamentale per tutti gli aliantisti che vogliono farsi omologare i loro voli.
Hanno aggiunto anche una funzione di allarme.
http://yankee-romeo.monsite-orange.fr/page6/index.html (http://yankee-romeo.monsite-orange.fr/page6/index.html)

La cosa importante è che hanno risolto in modo pragmatico il problema della proprietà intellettuale di Flarm dicendo che certe cose non sono brevettabili e hanno implementato un prodotto totalmente compatibile!
Questo è un importante passo avanti nella scelta di una soluzione.

Non so se abbiano chiuso, ma resta il fatto che il mercato di questi oggetti è un mercato troppo piccolo per prodotti industriali e i prodotti di piccole serie devono per forza scaricare sul prezzo di pochi oggetti i costi.
Ricordiamoci che tutto il progetto Flarm fu finanziato in anticipo dagli aliantisti svizzeri che versarono il capitale necessario per lo sviluppo di un prodotto che altrimenti non sarebbe mai nato.
Oggi comunque le componenti di base sono disponibili a prezzi accettabili grazie all'uso su altri mercati per cui un'avventura potrebbe essere anche intrapresa.
Ne è una prova il DYI lincato da Lucaberta che pur penalizzato dalla scelta di essere "senza saldature" potrebbe costare intorno ai 135 €.  
https://rawgit.com/lyusupov/Argus/master/doc/Parts_List_and_Price_Estimate.html (https://rawgit.com/lyusupov/Argus/master/doc/Parts_List_and_Price_Estimate.html)
Visto che i documenti sono fermi ad un anno fa si potrebbe cercare di far ripartire questo progetto.
A mio avviso dovrebbe comunque essere  integrata la compatibilità con Flarm.

Saluti Arturo

Sapete spiegarmi la funzione Flarm in EASYvfr ?

grazie del link al sito del francese, Arturo, ho trovato menzione di DSX anche sul sito attuale che e' qui http://www.yankee-romeo.com/Liens.html (http://www.yankee-romeo.com/Liens.html) ed ho appena scritto un'email per avere maggiori informazioni.

Temo anche io che DSX non esista piu', vediamo che mi risponde il francese. Ma ho come idea che siano di qui vicino, e magari si potrebbe trovare qualche contatto per vedere come DSX aveva fatto certe cose. Vedremo che mi risponde quello di YR.

Ciao, Luca

anche io non sono convinto che ci sia un mercato, perlomeno per ora, ergo la scelta di fare un progetto open.

poi uno non puo' mai sapere. il tizio che ha costruito il moteino, che non e' altro che un clone arduino con saldato un modulo RF commerciale, ha iniziato come progetto open e ora ne vende a vagonate, tanto che si sta industrializzando. niente male per un progetto low cost iniziato nella cucina di casa, con un reflow oven datto modificando una macchina per toasts.

e l'arduino stesso e' basato su processori atmel che erano gia' in circolazione da anni,

l'innovazione funziona cosi', cento provano e falliscono e magari uno ha successo. ma se mai provi...

molto bene: idea e iniziativa da attivista, open source, info aggiuntivi da internet, possibile fai-da-te, possibile piccola serie;

anzi, io meccanico che ha saldato qualche volta una scheda con elementi semplici (non i millepiedi), può fare qualcosa con solo un tester, o ci vuole anche un osciloscopio, attrezzatura da hobbista elettronico?

sono favorevole al 110% a sviluppare qualcosa compatibile col FLARM

putroppo credo sarebbe illegale trasmettere sulle frequenze del ADS-B

sospetto che alla fine diventeranno molto piu' diffusi in aviazione aggeggi "ufficiosi" ma funzionali, economici e user friendly come il FLARM che soluzioni ufficiali, ma costose e complesse, come l'ads-b

Per l'ADS-B penso sia sufficiente integrare la parte "ricezione": noi possiamo sapere dove sono loro anche se loro non ci vedono ....

Il dilemma a questo punto mi sembra che si possa così semplificare:
1- sistema "proprietario" + ricezione ADS-B = GIA' FATTO DIY + FLARM (da sviluppare)
2- ricezione FLARM + ADS-B prendendo la parte FLARM dagli altri progetti lincati ed eventualmente la parte ADS-B da DYI

Personalmente sarei per la 2 perchè il mercato si allarga automaticamente agli alianti (1° installazione o sostituzione di un FLARM obsoleto a costi minimi).
Fondamentale il "riciclo" delle parti già sviluppate.

A voi!

Arturo

per ora l'ADS-B ce l'hanno liners e poco piu'

e piuttosto che essere a migliaia che spendono migliaia per vedere qualche dozzina, penso sia meglio che qualche dozzina spenda un paio di centinaia per vedere migliaia.

Non ho capito.

Il top, ma so già che è praticamente impossibile, sarebbe poter rilevare tutti i trasponder come fa Garmin sul G1000.
E' bellissimo vederti sul display i traffici che hai intorno con la loro quota e la direzione.
So che il rilevamento è fatto in maniera macchinosa e credo che non ci siano dei mezzi allo stato solido per ottenere lo stesso risultato, ma magari mi sbaglio ...
Avere tutti i trasponder significa avere il 100% del traffico AG + Commerciale + gli Avanzati
Avere FLARM da noi vuol dire avere un 70% degli alianti (percentuale molto molto spannometrica)
Avere ADS-B vuol dire avere una apertura sul futuro ma effettivamente poco interessante al momento
Avere un sistema tipo quello del DIY basato su Wi-Fi vuol dire vedere solo chi ha lo stesso dispositivo (e saranno sempre molto pochi).


Come vorresti procedere??

Saluti Arturo

-Vedete realistico captare la direzione di provenienza delle repliche dei transponder ?
-Se un transponder C non riceve segnali radar, ogni tanto emette comunque un segnale ?
- idem per transponder S ?
Sarebbe comodo sapere in quale direzione si trova l'altro,  a quale quota.
Se comunque un transponder non emette nulla, perché fuori campo radar, per esempio tra le montagne, siamo fregati.
Vedo i cercapersone per scialpinismo che hanno 3 antenne ortogonali, che indicano con una apprezzabile precisione sia la distanza che la direzione dell' infortunato sepolto. Riescono anche a separare i vari segnali nel caso di piú persone vicine.

"e piuttosto che essere a migliaia che spendono migliaia per vedere qualche dozzina, penso sia meglio che qualche dozzina spenda un paio di centinaia per vedere migliaia."

tradotto:

a noi interessa il traffico leggero, i liners non sono un problema.

ergo, quei pochi AG che hanno speso migliaia per il modeS/ADS-B possono spendere un paio di 100 per comprarsi un PCASP

fare il contrario non ha senso e non succedera' mai, per svariati motivi.

col tempo sono sicuro che sarebbe semplice implementare una ads-b in per un PCASP o similare. dopotutto, sempre meglio che almeno uno dei due candidati alla collisione veda l'altro.

le cose non miglioreranno mai sinche' gli standard saranno decisi da burocrati che al massimo volano scrivanie e che non hanno alcun riguardo per i portafogli altui

Una possibile soluzione potrebbe essere costruire un hardware (arduino + nordic nrf 905) capace di ricevere e trasmettere broadcast simil-FLARM (mantenendo quindi la compatibilità con FLARM) da usare anche per sviluppare e sperimentare un nuovo protocollo anti collisione completamente open. Tale aggeggio dovrà essere collegato ad un GPS, tanto vale usare LK8000 come GPS che già permette di visualizzare sulla moving map le posizioni degli altri traffici rilevati. L'aggeggio può essere estremamente semplice ed occuparsi solo di ricevere e tramettere broadcast mentre gli algoritmi di predizione e CPA possono essere implementati direttamente in LK. Ecco alcune schermate di come LK mostra ed elenca gli altri traffici flarm rilevati:

(http://lk8000.it/images/phocagallery/screenshots/thumbs/phoca_thumb_l_web022.jpg)

(http://lk8000.it/images/phocagallery/screenshots/thumbs/phoca_thumb_l_web024.jpg)

(http://lk8000.it/images/phocagallery/screenshots/thumbs/phoca_thumb_l_web027.jpg)

interessante, ma io ho gia' diversi gps e non conto di installarne un altro... e penso la stessa cosa accada per molti altri


val certamente la pena studiare la compatibilita', ma la mia prreferenza andrebbe a un sistema stand-alone che non richiede devices esterne e chen non imponga scelte esterne di hw/sw

uscire in seriale usando lo stesso protocollo del FLARM non dovrebbe essere un problema.

se un arduino non dovesse avere abbastanza muscoli per gestire il tutto, ci sono alternative molto potenti come il teensy 3.1

https://www.pjrc.com/teensy/index.html (https://www.pjrc.com/teensy/index.html)

Penso di no. Non avrebbe grosso senso.
Per la prima domanda, già esistono sistemi che lo fanno:

www.youtube.com/watch?v=8ZDfXuulsF4 (http://www.youtube.com/watch?v=8ZDfXuulsF4#ws)

Mi ha risposto il francese, che mi ha detto che fino al mese scorso il sito della DSX era attivo. Si informa e mi fa sapere.

Nel frattempo mi ha girato una brochure di DSX che mostra il loro sistema SaFly, che sembra piuttosto sofisticato. E' comunque qualcosa che si posiziona proprio nello stesso ambito del progetto TCASP di GM.

Qui trovate la brochure:
https://www.slideshare.net/secret/ID0slSzuFZqp9A (https://www.slideshare.net/secret/ID0slSzuFZqp9A)

Ciao, Luca

Speriamo che dsx non abbia chiuso, anche se i numeri sono veramente esigui. Comunque l'implementazione su lk8000 è priva di costi perchè lk8000 (sviluppato in Italia) è completamente gratuito ed installabile su qualunque gps windows mobile quindi non richiede hw e sw specifico, occorre solo fargli arrivare il segnale dal nuovo prodotto che Crono e gli altri stanno cercando di sviluppare e che sicuramente comprerei vista l'utilità. Ricordiamoci che la comunità vds italiana è molto sviluppata quindi abbiamo i numeri per definire noi un nuovo standard (come hanno fatto i volovelisti svizzeri e tedeschi con il flarm) a cui potrebbero accodarsi altre comunità di volo (parapendio e gli stessi volovelisti che comunque iniziano a volare anche loro in spazi aerei controllati o comunque con volo vds e ag) ed altri Paesi. Ciao Roberto.

Mariko, purtroppo son KO!

http://www.avweb.com/avwebflash/news/Portable-traffic-alert-system-maker-Zaon-ceases-operation220938-1.html (http://www.avweb.com/avwebflash/news/Portable-traffic-alert-system-maker-Zaon-ceases-operation220938-1.html)

Arturo

Se ho capito bene, ti immagini un prodotto che contenga già il gps e il display e abbia possibilmente l' antenna interna,un cicalino, una pila ed abbia sostanzialmente solo un interruttore on/off. Un usb giusto per la ricarica delle batterie e per configurarlo.
L' alimentazione esterna (anche solare  ;)  ), il gps esterno, l' interfaccia con un EFIS, l' uscita audio/cuffie, ecc., sono optional per chi li vuole.

NO, se non interrogato il trasponder non emette nulla. Quando volo (e anche a terra) la luce del trasponder che indica l'invio di una risposta lampeggia mediamente ogni 5 - 10 secondi!   Quindi penso che si possa contare su di un segnale quasi costante.
Ovviamente questo non vale nelle valli.

Ciao Arturo

Sei sicuro che il LED, o nel caso mio la R sul display, non indichi solo che stà rispondendo a un interrogazione ?
Voglio dire, se qualcuno mi chiama al telefono rispondo e visivamente alzo la cornetta,
ma questo dice nulla sul fatto che ogni tanto io spontaneamente posso fare uno jodler   :)

esatto

ricapitolo i costi hw:

- arduino dai 3 ai 20 dollari a seconda della potenza del processore
- modulo gps avanzatissimo 20 e ce ne sono a molto meno
- display grafico 128x64 5 o 6 dollari
- transceiver dai 5 ai 40 dollari secondo la potenza di trasmiss

probabilmente la parte piu costosa sarebbe la scatola...

poi l'interoperabilita' con altri aggeggi come un LK8000, gps eccetera e' puramente sw e non richiede hw aggiuntivo

per quello che dico che preferirei una unita' standalone, capace di funzionare da sola, cosi che tutti possano accederci

LK8000 sara' gratis ma un PDA non e' gratis, e come ho detto, non ho intenzione di comprare un altro GPS e installarlo a bordo

nel caso sarebbe da studiare l'uso di uno smartphone come display, via wifi o bt.
i moduli wifi e bt costano zero. ma questa implementazione sw sarebbe gia' complicata

Si Werner, forse non mi sono spiegato.
Per quello che ne so io la "luce" significa che sta rispondendo a qualcuno.
Le risposte possono essere sia verso radar che verso altri aerei dotati di TCAS.
Per questo, anche a terra, se c'è traffico di liner si vede la "luce" o il simbolo "R" accendersi.
In ogni caso la risposta viene trasmessa ed è utilizzabile da chiunque.
Dalla risposta si può ottenere facilmente:
- distanza (misurando il tempo di propagazione)
- quota (leggendo la quota contenuta nella trasmissione)
Dalla distanza si può chiaramente derivare la velocità (edit) RELATIVA e il fatto se l'altro aereo si avvicina o si allontana.
Più difficile, perchè implica antenne direzionali, stabilire la direzione.

Ciao Arturo

xpndr mode C e S sono fuori scopo, period.

Peccato!

Allora vuol dire che vedremo:
- chi ha gia Flarm
- chi si costruirà il progetto nuovo
e nessun altro ....  :(

Ciao Arturo

ho frugato qui:
http://www.radartutorial.eu/13.ssr/sr25.en.html (http://www.radartutorial.eu/13.ssr/sr25.en.html)
Se ho capito bene, il xtsp mode S emette anche spontaneamente ogni secondo.
mentre il mode A/C nò.
Perciò, almeno ricevere e interpretare il messaggio S non lo escluderei, visto che dà tutto quello che ci serve. Il fatto che per ora alcuni non hanno ancora il gps collegato, mi sembra una cosa temporanea.
Poi, sollecitare il Xtsp A/C e capire la direzione, sarebbe un secondo passo...

Werner,
come funziona un trasponder in modalità A+C?
E', fondamentalmente, uno strumento che risponde ad un'interrogazione da parte di una stazione.
Dalla stazione di terra mandano un segnale a cui il nostro trasponder risponde inviando una serie di 4 numeri (quelli che selezioniamo noi manualmente) ed un dato barometrico opportunamente codificato dall'encoder. Il sistema di terra è costituito da due grosse antenne, di cui una rotante direzionale, ed una sistema che è in grado di stabilire direzione e distanza della risposta che il nostro trasponder A+C emette quando riceve l'interrogazione.
Appare chiaro che un trasponder NON deve emettere segnali nei modi A e C quando gli pare, ma solo quando riceve un'interrogazione, altrimenti il sistema non funziona. :)

Integro (o meglio re-integro)
... e risponde anche ai TCAS ovvero ai liner che interrogano tutti.
Questo spiega perchè a terra lui risponde anche se è impossibile che sia visto da un radar.

Da ciò deriva che si può ragionevolmente contare sul fatto che in aria tutti i trasponder emettano la loro risposta in modo piuttosto continuativo.
Ergo si può ragionevolmente contare sul fatto che se c'è un aereo con trasponder nelle vicinanze, anche se non interrogato da me, io possa ricevere le sue trasmissioni.

Ciao Arturo

Proprio per questo a prima vista appare strana la funzione di squitter nel modo S
http://defenseelectronicsmag.com/site-files/defenseelectronicsmag.com/files/archive/rfdesign.com/mag/512RFDSF3.pdf (http://defenseelectronicsmag.com/site-files/defenseelectronicsmag.com/files/archive/rfdesign.com/mag/512RFDSF3.pdf)
Invece, un urlo spontaneo, brevissimo, 1 volta/sec è veramente raro, tanto da sovrapporsi rarissimamente agli altri xtsp.
Potrebbe proprio essere il xtsp ad invocare le interrogazioni da parte del radar.

e chi sarebbe "nessun altro"? i liners a livello 380? o quei quattro gatti di AG che hanno xpnrd mode S e lo tengono acceso?

non confondere il modo S "puro" con quello che ha anche la funzione ADS-B.

ADS-B e' un superset di modo S, quando usato sulla 1090 MHz, ed usa la funzione di "extended squitter" unita al pacchetto DF13. Ma sempre di modo S si tratta.

Se un transponder in modo S *non* ha ADS-B, rispondera' un po' come un modo A+C, senza alcuna indicazione di posizione codificata nel DF13, ergo il sistema proposto da GM non puo' funzionare.

non basta il modo S, serve anche ADS-B se vuoi vedere la loro posizione, quota, track e velocita'.

Comunque sia, il numero di mezzi di GA che hanno ADS-B attivo e' in costante crescita, giusto domenica pomeriggio ho beccato un helo HB che e' venuto ad atterrare all'aeroporto della Cote, vicino a casa mia, per poi riparire attraversando il Lemano in direzione sud, verso la Francia, passando proprio sotto il fascio dell'ILS 23 di GVA, quindi in pieno spazio aereo controllato.

Qui la track su FR24:

(http://i.imgur.com/WhwVBDQ.png)

Qui le informazioni sull'helo:

(http://i.imgur.com/WBnlSQV.png)

Certamente sono ancora pochi i mezzi che usano ADS-B, ma come gia' ti dicevo per me e' da folli non pensare di avere anche l'input di ADS-B, dato che proprio gli helo sono traffico importante da tenere sott'occhio, e loro ADS-B ce lo avranno se vogliono operare in spazi aerei controllati. E gli helo operano molto spesso in spazi aerei controllati.

identificare la posizione di uno squawk in mode C e' assai approssimativo. ho volato su mezzi equipaggiati con uno zaon e non mi e' sembrato molto utile, l'unica info valida e' che c'e' un altro aereo in zona alla tua stessa quota, ma in posizione incerta.

per il momento direi che mettersi ad ascoltare i xpndr mode C sia tempo sprecato

i mode S con extended squitter, quindi collegati a un GPS, sono secondo me pochini

la maggior parte di chi installa mode S lo fa perche' costretto, o senza particolari motivi, giusto perche' costa poco piu' di un mode C, ergo raramente si cura di collegare un GPS, perche' tanto nessuno ha un ADS-B IN che puo' utilizzare questo dato.

eccetto gli amatori di flightradar, ma questo ai fini di un anticollisione e' irrilevante.

ecco perche' al momento ricevere i xpndr mode A/C/S e' poco interessante, e il lavoro richiesto, che e' parecchio, non vale la candela

giusto, ma al momento la cosa mi sembra poco interessante. rispetto agli ULM anche gli elicotteri sono merce rara. al di fuori della svizzera perlomeno. specialmente quelli grossi abbastanza da avere a bordo un ADS-B out.

quindi prima mi preoccuperei del 95% del traffico che ci interessa, cioe' ulm, alianti, parapendii eccetera, il resto puo' aspettare.

in ogni caso, vista la tendenza degli AG a scomparire, ricevere gli ADS-B diventa secondo me sempre meno importante.

"Comunque sia, il numero di mezzi di GA che hanno ADS-B attivo e' in costante crescita"

ma il numero totale di GA e' in costante diminuzione. secondo me il problema si risolvera' da solo :D impossibile collidere con qualcosa che e' a terra da tempo ;-)

Indubbiamente e' più pratico e semplice avere un solo aggeggio che faccia tutto da solo, cosi che possa essere usato subito da tutti.


Un uscita seriale conviene avercela soprattutto per i primi test: essendo che lo sviluppo dovrà iniziare presumibilmente con la trasmissione e ricezione dei braodcast sull'interfaccia RF, una qualche interfaccia con un display o similare per mostrare gli altri traffici può essere fatta più tardi ed inizialmente utilizzare qualcosa che faccia da display. LK8000 potrebbe fare benissimo questa parte.


Avere tutto implementato sull'Arduino, non dovrebbe essere un problema in termini di cicli processore dato che il Flarm usa un AVR ATMega128 come processore.


Un vecchio navigatore Mio usato lo trovi con 20 Euro.


Come già detto LK potrebbe farlo, credo che praticamente tutti i PNA abbiano il bt ed in LK8000 sia Flarm che bt sono già presenti.
Inoltre non sarebbe un problema fagli scrivere dei file di log a parte con tutti i broadcast inviati e ricevuti su RF.

Chi mette qualche link di informazioni aggiuntive su LK8000?

Anche roba tecnica, protocolli usati, porte di comunicazione et similia.

Grazie, Luca

facendo l'avvocato del diavolo,
perchè qualcuno dovrebbe dotarsi di un sistema che non vede gli elicotteri, l'aviazione generale, gli ulm nudi, i parapendio ?
secondo mè, o fai un sistema che vede tutto e quasi tutti, o sprechi energia intelettuale.

secondo mè gli step sono:
-Se ti riuscisse di fare un sistema MOLTO economico che emette in Flarm e riceve solo Flarm, per parapendio ecc. è già un primo passo. Utile e assolutamente necessario per avere successo con gli step successivi. Per questo io pensavo a un aggeggio connesso allo smartphone.
-Poi se fai un prodotto che riceve Flarm e interpreta intelligentemente i Xtrsp C e S nei dintorni, anche se non in contatto radarterra, anche senza ADS-B, sarebbe un successo per gli ULM e per l'AG come prodotto da cosciale o da ventosa. Questo prodotto può anche avere un costo medio. Basta che funzioni praticamente con tutto ciò che vola.
-Se riesci a implementarlo nell Efis sarebbe il top. Ma questo non è veramente necessario.

è evidente che in un futuro ci sarà un unico navigatore GPS che includerà tutto, al prezzo del navigatore più qualche spicciolo.

Ma se fai un prodotto per ULM che trasmette un linguaggio proprio, incomprensibile al 99% di chi vola, e legge solo questo linguaggio esotico, non lo vuole nessuno. Anche se costasse chessò 50€, se ne doterebbero in pochi, almeno finchè non è diffuso.
Una volta diffuso però, le cose cambierebbero.
Mi chiedo se non vi è modo di interscambiare direttamente dati tra smartphone, senza passare da un provider di rete. Sarebbe l'uovo di colombo.

X lucaberta LK8000 ha il suo sito www.lk8000.it (http://www.lk8000.it) inoltre sul forum postfrontal ci sono diverse sezioni di discussione tecniche anche per gli sviluppi tecnici.
X opti temp LK8000 ha già una versione anche per il volo libero e dovrebbe funzionare sui cellulari windows mobile.
X Crono te lo dico in romano dajee
 Ciao Roberto

Trovo difficile fare due passi allo stesso tempo.

Valuterei di usare lo standard flarm abbassando i costi enormemente e portandolo open come obiettivo unico.

Sarebbe già un risultato importante che moltiplica il numero di installazioni, che diventano più interessanti perchè ci sono un numero crescente di installazioni e via così.

Inoltre l'effetto moltiplicativo garantirebbe anche alla flarm di sopravvivere, probabilmente.

Aumentare anche il livelo tecnologico e lo scope del progetto può essere un prossimo passo, che magari farà qualcun altro.

Spesso chi troppo vuole nulla stringe.

snoopy ti ha gia' risposto

innanzitutto io non voglio imporre un sistema e non voglio conquistare un mercato. io voglio implementare una alternativa totalmente open. alternativa alla situazione attuale che e': o ti doti di un flarm, e vedi solo alcuni alianti, o ti metti costosi aggeggi come un ricevitore ads-b che vede solo i liners e qualche ag che ha un mode S con extended squitter attivo.

secondariamente, il perfetto e' nemico del possibile, inutile andare a cercare di costruire l'aggeggio perfetto, che e' un esercizio puramente accademico

interpretare intelligentemente mode C/S: dimmi tu come. con antenne direzionali? ha ha ha

l'unico discorso intelligente e' costruire qualcosa che sia compatibile col flarm. problemino: il flarm usa un protocollo proprietario, e non so che risvolti legali abbia.

allora rimangono due alternative:
- fare un similflarm. e' legale? non so
- fare un sistema nuovo, alternativo, open, che usa componenti off-the-shelf, economico e piu' moderno, magari interfacciabile con flarm.
 
secondo  me tale sistema deve essere standalone, portatile, ed economico. molto economico, e autocostruibile.
vuoi interfacciarlo con efis, gps, con la tv del soggiorno? scrivi il codice, testalo  e mettilo a disposizione.


sett prox, tempo permettendo, scrivero' alcuni requisiti e ci discutiamo sopra.

poi definiremo dei protocolli per i tests pratici dei prototipi che verranno, spero, sviluppati.

Trovare la direzione di provenienza del transponder si puó
http://de.m.wikipedia.org/wiki/LVS-Ger (http://de.m.wikipedia.org/wiki/LVS-Ger)ät
purtroppo in italiano manca il diagramma esplicativo.

La distanza la determini tú, eccitando la risposta.

Sui problemi legali di fare un Flarm compatibile ti ho citato cosa hanno fatto gli altri che hanno controllato anche i brevetti.
Non è brevettato e non è brevettabile.
L'unico problema potrebbe essere l'uso della chiave di cifratura dei dati ma qui da noi non c'è una norma che vieti il reverse ingeneering ...

Fai un Flarm oper a meno di 100€ e vedrai che diventa quasi standard.
Aprilo alla visualizzazione su PDA e GPS.
Aprilo all'ADS-B se prenderà piede.
Rendilo compatibile con A_C per quanto riguarda solo la velocità relativa e la quota (questo è facile!!!).

Basta, non serve altro  ;)

Ciao Arturo

Concordo il nuovo sistema non dovrebbe nuocere al flarm atteso che i volovelisti continuerebbero a comprarlo in quanto è anche un logger certificato dalla FAI cosa che non sarebbe lo strumento in via di ideazione.

Bravo, hai centrato un punto importante per evitare attriti con Flarm
La eventuale funzione di logging (che non credo serva perchè qualsiasi cellulare è in grado di farla) a non non occorre che sia certificata.
I record ci sono automaticamente accreditati se li raccontiamo qui!!

Per gli aliantisti seri avere un logger certificato è fondamentale.

Ciao Arturo

ok, scrivi il codice ;-)

Sapevo che per TE sarebbe stato facile  :)
Ti hanno già postato anche le routines già fatte!

(io per facile mi riferivo solo alla quota!)

Ciao Arturo

chi ha transponder mode C/S che si compri il TCASP.


che sia fattibile gestire gli eco dei mode C/S e' possibile, anche se io ho seri dubbi, avendo usato un paio di volte un zaon, ma e' una strategia perdente tipica del mondo aeronautico, il rifiuto di adottare tecnologie moderne ed economiche ed attaccarsi a roba degna della seconda guerra mondiale.

la funzione dei transponders non e' mai stata quella di prevenire le collisioni.

prima ce li lasciamo dietro, meglio e'. al di la' degli obblighi normativi, gli stessi che hanno proibito le lampadine da 100W, i transponders mode C/S sono costoso antiquariato.

Sugli obblighi legali.

Se esiste un brevetto sul protocollo flarm non si può fare nulla, se non coinvolgendo flarm, e quindi probablmente non si può fare nulla.

Se invece il protocollo è proprietario nel senso che è mantenuto confidenziale o messo sotto segreto industriale... il reverse engineering è sempre permesso in tutte le legislazioni e i risultati del reverse engineering sono utilizzabili tranquillamente sul mercato. Quello che non può essere fatto è fregare una specifica alla flarm o la confidenza di un dipendente o una qualsiasi informazione interna e poi usarla. Quello è reato.

In summa: se sei capace di fare una bevanda con lo stesso gusto della Coca Cola... accomodati.

Sugli obblighi legali cfr
http://www.soaringwear.com/uploadz/02/PDF/T-Advisor_07_12_19.pdf (http://www.soaringwear.com/uploadz/02/PDF/T-Advisor_07_12_19.pdf)
pagina 6
Quando si parla di "licenza" data da Flarm ad altre aziende si tratta dell'intera scatola: HW, SW, FW che tutti utilizzano e che è stata sviluppata da Flarm.
Il protocollo di per se non è brevettato ne brevettabile.
Lo stesso documento fa tutte le analisi che abbiamo fatto e sostiene la inutilità di inventarsi un nuovo "sistema" diverso da Flarm.
Pone anche l'accento sulla differenza tra "antocollision" e "traffic detector / advisor"

Il punto di vista di Flarm
http://www.flarm.com/product/Compatibility_Considerations_1_1.pdf (http://www.flarm.com/product/Compatibility_Considerations_1_1.pdf)
Punti interessanti:
- si preoccupano che pasticcioni possano mettere in pericolo la sicurezza con prodotti non affidabili che possono costituire un pericolo per tutti
- dicono, mentendo, che il protocollo è brevettato
- sono disponibili a "cedere la licenza" di tutto il prodotto per evitare i costi di sviluppo (di una soluzione identica alla loro!)
- Per evitare che il GPS si comporti in modo diverso tra i diversi costruttori tutti usano lo stesso modulo e lo stesso SW
- il sw di calcolo della possibile collisione è particolarmente sofisticato (ndr e dovrebbe dare gli stessi risultati su tutte le unità)
Il documento finisce con:
"Rogue devices that attempt to emulate a FLARM signal but are not fully compatible may disrupt
communication between FLARM devices for a series of technical reasons. The uncontrollable proliferation of
parasitic devices with untested and largely untestable compatibility and performance is undeniably not in the
interest of flight safety and thus contrary to our mission."

Il documento è del 2008 e dal punto di vista dei dispositivi significa che è vecchio di secoli ma per le altre considerazioni deve essere preso in esame.

Se GM riesce a sviluppare un box che funziona, che ha un aspetto accettabile e che costa meno di 100€ aspettiamoci la guerra da Flarm con l'accusa di mettere in pericolo la sicurezza di migliaia di alianti.
E come sapete bene tutti, quando si tratta di SICUREZZA non c'è nulla che si può opporre!

A scanso incomprensioni, io trovo il progetto molto interessate, è impegnativo ma ci sono diversi elementi già disponibili, non ultimo il tipo di display da utilizzare anche se una uscita verso altri visualizzatori è senza dubbio da preferire.
Buona lettura
Arturo

Per non stare a ricercare sempre i soliti link perduti posto i documenti che trattano la cosa:
https://groups.google.com/forum/# (https://groups.google.com/forum/#)!msg/rec.aviation.soaring/UfFBTMU6FK0/oFYDmEdAlIoJ
http://www.volavoile.net/index.php?showtopic=6784 (http://www.volavoile.net/index.php?showtopic=6784)
http://crvvaquitaine.free.fr/download/down/FLARM_v2.pdf (http://crvvaquitaine.free.fr/download/down/FLARM_v2.pdf)
fornitori di Flarm nel 2008 http://www.u-blox.com/en/ (http://www.u-blox.com/en/)
specifiche ver 5 http://www.flarm.com/support/manual/FLARM_DataportManual_v5.00E.pdf (http://www.flarm.com/support/manual/FLARM_DataportManual_v5.00E.pdf)

""Rogue devices that attempt to emulate a FLARM signal but are not fully compatible may disrupt
communication between FLARM devices for a series of technical reasons. The uncontrollable proliferation of
parasitic devices with untested and largely untestable compatibility and performance is undeniably not in the
interest of flight safety and thus contrary to our mission.""

meh

come se uno si mettesse a costruire flarm che trasmettono, con protocollo perfettamente formato, posizioni gps errate. e per farlo bisogna mettersi a volare nelle vicinanze.

aria fritta.

Sugli obblighi legali:

Certo che il protocollo non è, di norma, brevettabile. Si tratta solo di operazioni di trasposizione e mappatura di dati da una forma all'altra (interna al micro (sostanzialmente parallela) al canale radio (sostanzialmente seriale)). Tuttavia potrebbe essere  stato "brevettato" lo stesso perchè incluso accortamente nella presentazione all'interno di un brevetto di apparato e, sebbene ciò non costituisca ostacolo una volta in dibattimento di merito perchè non brevettabile e basta, potrebbe diventare una grana prima di arrivare a quel punto.

Segnare: fare analisi brevettuale della flarm. In EU, non negli USA che non ci frega niente.

Condivido che è assolutamente pretestuoso.
Il problema potrebbe nascere da un diverso calcolo delle traiettorie future che potrebbero essere, o forse sicuramente sarebbero, differenti tra due apparati che usano programmi differenti.
Se non erro ora il Flarm trasmette non solo la posizione ma il singolo apparato fa il calcolo della previsione della traiettoria e la trasmette.
Prevedere la traiettoria di un aereo è banale, prevedere quella di un aliante non lo è affatto!

Saluti Arturo

per la verita' non prevedevo affatto di implementare una previsione di traiettoria, ma semplicemente posizione, quota e direzione di movimento degli altri oggetti

e un allarme in caso di conflitto tra le traiettorie, ma limitato al fatto che gli altri oggetti siano a quote simili e con rotte convergenti.

Crono, che te ne fai della direzione degli altri oggetti se non ti interessa la traiettoria?

• Previsione di ordine 0: solo posizione; posizione costante, gli oggetti sono fermi
• Previsione di ordine 1: posizione, velocità; si suppone che le traiettorie sono rette (velocità costante)
• Previsione di ordine 2: posizione, velocità, accelerazione; si suppone che le traiettorie sono rette o archi di circonferenza (acceleraz. costante)
• Previsione di ordine 3: posizione, velocità, accelerazione, strappo; si suppone una certa traiettoria (strappo costante)
• etc etc per ordini maggiori

In tutti i casi, il sistema suona se gli oggetti saranno vicini entro tot secondi.

Aumentando l'ordine, le traiettorie sono più affidabili nel breve periodo e più inaffidabili nel lungo periodo. Il sistema Crono utilizza la previsione di ordine 0 oppure 1 (ancora da capire quale). Il sistema TCAS ordine 1. Il sistema Flarm probabilmente ordine 3 o superiori (mistero, protetto da brevetto).

Le previsioni potrebbero considerare altri fattori, ad esempio che alcune traiettorie potrebbero essere aerodinamicamente impossibili, oppure che il parametro costante non è costante ma varia di massimo 1% ogni tot secondi, oppure potrebbero valutare e mediare più ordini contemporaneamente.

ok. scrivi il codice ;-)

e testalo, ovviamente.

Se interessa solo la sicurezza, la gloria e non i soldi, allora bisogna mettere in rete un codice o qualcosa che puó essere agevolmente prodotto e/o copiato da tutti.
Dapprima ci vorrebbe un "cinese" che vende meri trasmettitori tascabili flarm per pochi o pochissimi spiccioli. Trasmette posizione e traiettoria presunta, come da protocollo. Magari trasmette anche una seconda stringa open source.
Poi il resto dovrebbe nascere da sé!. :)

Secondo la mie modeste capacitá, la previsione di traiettoria é una specie di piamide quasi orizzontale che si apre
verticalmente a seconda dello spread delle misure precedenti,
il cui orientamento é in funzione della derivata della quota, magari incrementata della derivata seconda.
Lateralmente l' apertura é in funzione dello spread,
 la curvatura anch' essa in funzione della derivata della traiettoria, incrementata della derivata seconda.
praticamente trasmetterebbe:
un identificativo e una posizione copiata nella sostanza all extender squitter xtrsp S, posizione presunta tra 30, 60, 120, 240, ... secondi, comprendente anche larghezza e altezza della piramide.

http://worldwide.espacenet.com/searchResults?ST=singleline&locale=en_EP&submitted=true&DB=worldwide.espacenet.com&query=FLARM+Technology+GmbH
 (http://worldwide.espacenet.com/searchResults?ST=singleline&locale=en_EP&submitted=true&DB=worldwide.espacenet.com&query=FLARM+Technology+GmbH)

I brevetti sono due.

1) IMPROVED METHOD AND DEVICE FOR ESTIMATING A DISTANCE del 2012: An improved method for avoiding mid-air collision in aviation is disclosed. The method relies on a calibration of radio signal intensities I with radio signal encoded position information L. In other words, after a first reception of a radio signal S advantageously comprising remote aircraft position information L, the radio signal intensity I is measured and a correction factor C is derived. During a next encounter of the radio signal S, a second distance estimation d can be derived using the signal intensity I and the correction factor C. Preferably, relative positioning data is acquired together with the correction factor C and a plurality of correction factors for different relative positions is combined in an at least partly continuous correction function. (Esteso a: "Europa")

2) Equipment communicating data between gliders, especially concerning thermals, includes wireless transceiver and computer for data analysis and processing - del 2002 - A transceiver (3) receives wireless data (11, 12, 13) transmissions from other aircraft, and/or transmits data. A computer (2) connected to it, analyses and processes the data. Results are made available at an output (4). An independent claim is included for the corresponding method. - Esteso a: Germania

- Il primo riguarda future estensioni ed è in itinere;
- il secondo è un brevetto di sbarramento, che include codice, protocollo, verifiche sui protocolli e tutto quello che può dare fastidio. Parti sono probabilmente invalide in dibattimento, ma sono lì per dare rogne. Ha un difetto: è valido solo in Germania.

--> Per cui ci si può scatenare senza problemi.

Se poi in Germania qualcuno cerca di introdurre il Rogue Flarm... se ne parlerà allora.

Bel nome!
Per me potrebbe essere quello ufficiale del progetto a meno che non si voglia un acronimo più politically correct tipo:
Flight In_the_sky Collision Avoidance
o altri che il Forum sarà sicuramente in grado di trovare  :)

Arturo

tcasp non ti piace?

vfrcas?

vfrcoso?

VFRCAS ha il suo fascino
Ma pensaci bene perchè anche
Flight In_the_sky Collision Avoidance
ha un suo perchè ...

Bene, scelto il nome ora basta capire cosa fa!  :)

Arturo

Total Operations Plane's Alert no?

vorrei riprendere il discorso interrotto e stabilire dei requisiti per la costruzione di un prototipo dimostratore basato su dei moteino, che sono economici e disponibili.

direi di iniziare con due stazioni che trasmettono la propria posizione leggendo un file contenente uno stream nmea
un output sulla console seriale mostra posizione, velocita', direzione e distanza dell'altra stazione
espandibile a 3 o 4 stazioni per ulteriore testing

Come hanno già fatto questi???

Arturo

in italia se chiedi a un gruppo di persone chi vuole un caffe' un sacco di gente risponde "io no"

se ti piace sto coso costruiscitelo. a me non piace.

Seriamente: ma non è questo il tipo di oggetto che ipotizzi?
O sono le soluzioni già sviluppate da questi che non ti piacciono?

Ciao Arturo

non mi piacciono perche' trovo improbabile, costoso e complesso lo sviluppare un tupperware pieno di dongles, fili e un router in una qualche forma di dispositivo portatile standalone.


ma se tu vedi un possibile modo di svilupparlo, dimmi.

e' certamente una interessante curiosita', ma nient'altro.

Trovo che abbiano fatto un ottimo studio, delle scelte ragionate e documentate e hanno anche costruito un prototipo.
La presentazione di 74 slides è a livello professionale.
Mi sembra risolto egregiamente anche il problema non secondario della visualizzazione.
Poi si sono fatti condizionare dal requisito di "nessuna saldatura" e quindi è venuto fuori il "tupperware".
Per contro in aereo un affare con diverse connessioni è possibile che dia dei problemi.

Se condividi le idee puoi progettare la stessa cosa con strumenti differenti.
Non ho idea di quanto codice possa essere riutilizzabile.
L'applicativo è in Python e la parte di sistema della famiglia Arduino.

Ripeto, a me il progetto sembra molto ben fatto e modulare, ma non è il MIO progetto!

Ciao Arturo

Toh, questi hanno già fatto tutto. Il modello "tupperware" è sicuramente una prima fase di progettazione, per capire se la cosa più stare in piedi!
Comunque, non mi spiego come hanno potuto raggiungere 3.3 km di range con ricetrasmittenti wifi da 0,1W  :o altri grossi dubbi sono sul cpu load all'80% in "uso normale"... quindi se ci sono quattro aerei in circuito, potrebbe saltare tutto. Altra cosa, sarebbe stato interessante (per me!) sapere il loro algoritmo di previsione traiettorie.

se e' pubblicato nel repo su Github, lo si puo' trovare facilmente. Io non ho tempo di farlo, purtroppo.

"e la parte di sistema della famiglia Arduino."

dove, scusa? quello a me sembra un router riciclato che gira linux. il che non ha senso, innanzitutto linux non e' un Os in real-time, secondariamente non mi servono 99% delle funzioni di linux per questo progetto.

a questo punto avrebbe molto piu' senso usare un tablet da 50 euro collegandoci via usb un gps e una interfaccia WIFI come quella usata.

ma sinceramente, sarebbe un po come usare un D9 per fare un castello di sabbia alla spiaggia.

python poi... su su, andiamo.

anche se capisco che in un mondo dove la gente usa excel per fare la lista della spesa certe soluzioni possano sembrare razionali

questo e' un interessante ma abbastanza sterile esercizio di hackeraggio e nerdismo. cappello a costoro che maneggiano routers e interfacce usb come se non fosse nulla, ma questo coso non ha prospettive di sviluppo.

guarda che ho a casa tutto quell'hardware e ci avevo anche fatto un pensierino su, ma sinceramente usare un wifi adapter per fare il broadcast di posizione... mah.

Leggendo la presentazione sembrerebbe che non ci fosse nessuna previsione, solo la posizione.
Dicono di preparare una tabella con tutte le posizioni ricevute e le quote.
Poi trasformano la tabella in vettori (direzione di ogni singolo aereo rilevato rispetto a me e quota)
Visualizzano sul display le posizioni reciproche rapportando la distanza sul display a quella reale.
Non so come codifichino le altezze.
Ritengo che un altro aereo alla stessa altezza, se vicino, venga visualizzato in rosso, se vicino ma ad un'altra quota in verde.

Ripeto che sono ipotesi derivate dalla presentazione.

Ciao Arturo

per vedere come funziona basta guardare il codice no? :D

qui stiamo cadendo nel campo dei soliti slanci eroici alla volta di conquiste impossibili, slanci presto abortiti.

non ti basta avere la posizione del traffico intorno a te? e come faresti a prevedere che vuole fare un altro pilota? solo il mago otelma potrebbe scrivere quel codice

In pratica questi usano i beacon del WiFi mettendo al posto del nome dell'access point: posizione e altitudine e nel campo per le estensioni del produttore: timestamp direzione e velocità che e' un po' come inviare tante e-mail scrivendo solo nel campo per l'oggetto senza usare il campo per il testo vero e proprio...

Concordo con Crono, un'arudino con un un'interfaccia RF appropriata potrebbe fare quanto richiesto più efficientemente, sarebbe molto più semplice, compatto e meno costoso, inoltre volendo permetterebbe di rimanere compatibili anche con il FLARM cosa che usando il WiFi non sarebbe possibile.

Per la mia tesi avevo smanettato parecchio con moduli ZigBee e stavo pensando ad una cosa: di solito quando si riceve un beacon il modulo RF ci da anche il cosiddetto RSSI: Received Signal Strenght Indicator e' un indicazione di quanto e' forte il segnale radio appena ricevuto. Usando l'RSSI e' possibile stimare la distanza a cui si trova la stazione che lo ha trasmesso. Questo potrebbe tornare utile nel caso in cui uno dei traffici ha il GPS fuori uso o senza fix e ricevendo comunque i suoi beacon potremmo stimarne la distanza (non la direzione pero') in modo da non dipendere completamente dal GPS.

Comunque questo progetto mi piace, quindi Crono se vuoi ti posso dare una mano con il codice (quando ho tempo).
Ma niente Java, Python, C# o robe simili, solo "criptico e perverso" C++ che non ha bisogno di virtual machine, framework ecc e che quindi può girare su dispositivi minimali.

esattamente :D

grazie per l'offerta, teniamo sto thread in funzione

sono andati sulla luna e tornati con un aggeggio che un atmega 328 gli fa i cerchi intorno.

Per il discorso della compatibilità con FLARM: potremmo stare solo in ascolto di broadcast Flarm, dato che e' noto come decodificarli, in modo da vedere eventuali traffici Flarm ma senza trasmettere nulla che loro possano riconoscere, in tal modo non si può dire che li stiamo disturbando cercando di emulare la loro codifica; questo pero' significa che il nostro sistema risulterà invisibile a chi usa Flarm. Quello che trasmetteremo sarà in un nostro ipotetico formato open che chiunque altro sarà libero di adottare.

Comunque, cerchiamo di fare una lista della spesa accurata.
Ci serve:

1. Arduino o simile su cui fare girare il programma, avremo bisogno di lavorare con 3 porte seriali:
  * Una posta da cui ricevere e trasmettere dati verso l'interfaccia RF
  * Una porta su cui ricevere uno stream NMEA da un modulo GPS
  * Una porta con cui trasmettere i risultati all'esterno verso un eventuale display o logger ma da usare anche per trasmettere comandi all'accrocchio

Mi sembra di capire che un semplice Arduino dovrebbe essere in grado di lavorare anche con 3 porte seriali, con qualche limitazione ma senza hw aggiuntivo. O e' il caso di cercarne una versione più specifica?

2. Interfaccia RF: NRF 905 per le bande 433, 486 e 915 MHz, può andare bene questa o ce ne sono altre che possono fare al caso nostro?

3. Modulo GPS: qui e' importante trovarne uno che riporti l'altitudine in modo corretto, essendo che in molti casi questi moduli GPS sono ottimizzati per un uso terrestre dove l'altitudine e' di secondaria importanza.

Direi di iniziare ad individuare i modelli esatti di queste tre componenti fondamentali.

come ho detto, vorrei partire usando una piattaforma gia' esistente e funzionante, cioe' il moteino versione alta potenza, che dovrebbe avere un raggio utile di un paio di km, che per i tests sono piu' che sufficienti
la radio RFM69, usata sul moteino, e' assai superiore al datato NRF 905,che tra l'altro ha una gittata molto scarsa per ogni test pratico.

in ogni casi, se il codice e' scritto decentemente, cambiare il trasceiver non sconvolge nulla e basta correggere le routines di trasmissio e ricezione

una porta hw esiste ed e' quella usata anche per debugging, basta definirne un altra sw per gestire il gps,

per il display, dipende da che display si usa non serve una seriale.

per i tests iniziali non mi preoccuperei del display, mi basta vedere dei numeri sensati sull'output seriale.

"3. Modulo GPS: qui e' importante trovarne uno che riporti l'altitudine in modo corretto, "

e' duro a morire sto mito del gps che darebbe indicazioni di quota errate he?

il modulo gps che vorrei usare,

http://www.ebay.com/itm/Ublox-Neo-7M-10Hz-GPS-Module-Built-in-Data-Memory-Replace-NEO-6Mgi-/281443329963?pt=LH_DefaultDomain_0&hash=item41875467ab (http://www.ebay.com/itm/Ublox-Neo-7M-10Hz-GPS-Module-Built-in-Data-Memory-Replace-NEO-6Mgi-/281443329963?pt=LH_DefaultDomain_0&hash=item41875467ab)

a occhio fa barba e capelli a parecchi gps aeronautici commerciali, riguardo la parte ricevitore.

 

Da prove che avevo fatto con un paio di GPS, guardando direttamente l'output in NMEA, avevo notato l'altezza rispetto al geoide WGS84 oscillare anche più di 50 metri pur avendo un buon fix e mantenendo immobile l'unita, invece l'oscillazione della posizione orizzontale era di un paio di metri.

Comunque mi riferivo più che altro al cosiddetto: "track smoothing" operazione che viene fatta da alcune unita' GPS destinate ad un uso stradale ma che risulta ovviamente dannoso per un uso aeronautico. Dai un occhiata qui: http://www.postfrontal.com/forum/topic.asp?TOPIC_ID=6947 (http://www.postfrontal.com/forum/topic.asp?TOPIC_ID=6947)

questo GPS viene usato dai tizi dei droni.

Quindi il moteino ha l'unità RF integrata che è ottimo, ma volendo mantenere la compatibilità con FLARM siamo sicuri che tale interfaccia vada bene? Vedo che quelli di Open Glider Network usano un ricevitore DVB-T su chiavetta USB che però poi hanno bisogno di un RaspberryPi per processare tutti i dati ricevuti e andare a filtrare i broadcast Flarm...

Comunque se lo scopo è quello di fare un dimostratore, tralasciando inizialmente la compatibilità con Flarm, i moteino vanno benissimo.

Il codice in C++ per processare da una porta seriale uno stream NMEA dal GPS ce l'ho praticamente già pronto...

come ho gia' ripetuto almeno 5 volte, questo e' un prototipo dimostratore e non e' una soluzione finale. 

personalmente a me del flarm non mi importerebbe nulla, e' un aggeggio usato tutto sommato da pochi, e non ho mai avuto incontri ravvicinati con alianti.

non vorrei che si finisse, come sempre, per non ottenere nulla alla ricerca della famosa "soluzione ottimale",

tra l'altro il flarm mi pare usi frequenze diverse a seconda della nazione, il che ne rende l'utilita' enormemente inferiore.

conrad micallef nel frattempo si e' dato molto da fare e mi ha mandato del codice per il moteino. spero che si iscriva al forum e partecipi a questa discussione

se mi da l'ok lo metto a disposizione anche qui.

Salve, mi introduco - sono Conrad Micallef - appassionato di volo ed ingeniere elettronico. Ho accolto la proposta di Crono per provare a riprodurre un TCAS usando il moteino.

Una versione iniziale l'ho publicata qui - https://github.com/conradmicallef/TCasp.

Il progetto si basa su un GPS che e utilizzato in configurazione avionica ( aircraft < 4g, fix satellitare ristretto a 3d) per dare piu stabilita e correttezza all elevazione rapportata dal gps

Questo GPS manda update ogni secondo all arduino della posizione attuale.
L'arduino utilizza questa posizione per determinare in quale modalita attivarsi

WAIT - modalita in cui aspetta un segnale fisso dal satellite
LISTEN - modaita in cui laereo e stazionario (<30 km/hr) - modulo fa display dell altro traffico senza trasmettere la sua posizione
ACT - modaita in cui l'aereo e in movimento e trasmette la sua posizione ogni 3 secondi

Ogni volta che riceve un "position report" il modulo utilizza posizione e vettore di velocita 3D piu rata angolare di cambio traiettoria per stimare le posizioni prossime (30 secondi)

Una categorizzazione del traffico viene fatta abbase di questi vettori e si determina in
1) traffico lontano - non da pericolo
2) traffico in formazione ( delta velocita < 0.07 distanza )
3) traffico in potenzialita di collisione < 15 secondi
4) traffico in allerta di collisione < 10 secondi

Tanti spunti li ho ottenuti studiando il sistema TCAS vero, e costruendo modelli di collisione e allerta virtuali.

Per il momento e solo un progetto experimental, ma sono disposto a sentire altre opinioni, e particolarmente impressioni di gente che l'ha fatto girare sull proprio veivolo.  

Conrad

Bellissima iniziativa. Due domande.
- Che te ne fai della previsione a 30 secondi se gli allarmi vengono dati a 15 secondi dal crash?
- Cosa significa aircraft < 4g, fix satellitare ristretto a 3d?
- Stando a wikipedia inglese, il TCAS ha un algoritmo di previsione delle traiettorie piuttosto banale (e inefficace per aerei lenti), ossia si basa su uno spazio intorno all'aereo dipendente solo dalla posizione dell'aereo. Sai per caso se è veramente così?

- Che te ne fai della previsione a 30 secondi se gli allarmi vengono dati a 15 secondi dal crash?
Se e il traffico piu vicino si mostra sul display con un countdown di 30 secondi
il TCAS mostra alert con previsione fino a 48  secondi quando si ha quota do 40000 piedi

- Cosa significa aircraft < 4g, fix satellitare ristretto a 3d?
Un gps utilizza un modello per il mezzo, per ezempio portatile, auto etc. Questo modello e utilizzato per il KALMAN filter. Questo modello, se scelco bene da rilevamenti piu accurati - quello che ho scelto e aircraft < 4g perche dovrebbe dare date realistici per il mio ultraleggiero.
- Stando a wikipedia inglese, il TCAS ha un algoritmo di previsione delle traiettorie piuttosto banale (e inefficace per aerei lenti), ossia si basa su uno spazio intorno all'aereo dipendente solo dalla posizione dell'aereo. Sai per caso se è veramente così?
il TCAS utilizza solo vettore di velocita e posizine, e assume che gli aerei vanno in linea diretta, che tiene per i liner e per cruise, ma non tiene quando si ve con l'ultraleggiero per paesaggi e per montagne.

Conrad

Ciao Conrad e benvenuto,

ho fatto fork del tuo repository su github. Forse conviene che ci sentiamo per metterci d'accordo su come continuare.

benvenuto Conrad, mi sembra che il livello tecnico di questo thread sia eccellente e che qualcosa di concreto possa venire fuori

idealmente vorrei che venissero prodotti alcuni prototipi da testare dal vero

sono ovviamente dispobilie a prestare supporto tecnico, logistico e materiale.

ciao a tutti,
è da tanto che non leggo e scrivo e solo oggi ho trovato questa interessante discussione.

gioco anche io con arduino e la cosa è affascinante oltre che divertente...

avete spent tutto a novembre o vi siete trasferiti altrove a parlare e fare?

ciao
diego

Ciao Diego e benvenuto.

No, e' che ultimamente non c'e' stata molta attivita'.
Il repository su github che stiamo usado e' questo: https://github.com/TCASP/TCASP (https://github.com/TCASP/TCASP)

Finalmente mi sono arrivati i moteini ed il modulo GPS, spero di poter fare qualche prova questo weekend.

anche io mi sto attrezzando per costruirne un paio e provarli dal vero, iniziando da due auto, per esempio

i moteini li ho, sto aspettando i gps

domanda, sarebbe possibile, in via del tutto ipotetica si intende, costruire degli amplificatorini per portare la gittata dei moteino ad alta potenza a 5km?

la RF per me e' sempre stata magia nera

Ah che bello!!!!

ora vado a leggere. ma sarete già avanti da matti.
Io uso tre schedine Arduino uno, Leonardo (ma ora è buono solo a scaldare le uova) e Arduino Due.
Il GPS col quale gioco è il Ricevitore GPS Venus 638FLPx".
avevo anche preso nRF24L01+Module - Modulo radio TX/RX ma non li ho mai aperti dalla scatola...

a presto, vado a leggere cosa avete fatto.
ciao

leggermente OT, e ferme restando le mie perplessita' riguardo l'ADS-B, una interessante iniziativa della CAA inglese


http://nats.aero/blog/2015/01/helping-general-aviation-stand-crowd/ (http://nats.aero/blog/2015/01/helping-general-aviation-stand-crowd/)


"NATS has started a trial promoting the use of ADS-B by General Aviation that encourages pilots to connect a transponder to a non-certified GPS source."

ripetete con me

non-certified GPS source

ovviamente mi aspetto ENAC introduca simili misure a breve  :-X

In fondo alla pagina:
Una seconda fase della nostra iniziativa si chiama LPAT Low Power ADS-B Transceiver.
...
http://www.nats.aero/news/nats-enable-ads-b-transponder-functionality-ga-community/ (http://www.nats.aero/news/nats-enable-ads-b-transponder-functionality-ga-community/)

A second element of the trial will see the introduction of a new prototype device called the Low Power ADS-B Transceiver (LPAT), which is being developed by NATS with Funke Avionics.
LPAT is being positioned as a portable, battery powered and affordable device that will provide the minimum functionality needed to make a GA pilot visible to other airspace users, as well as to provide warnings against other suitably equipped aircraft.

Chi sa perchè loro non hanno deciso di inventare un nuovo dispositivo ma hanno pensato di rendere disponibile un ADS-B economico e portabile ...  8)

Che strani questi inglesi ....

CIAO Arturo

loro possono. tu non puoi. quelle sono frequenze che richiedono certificazione e licenza.

non e' un problema tecnologico, ma meramente legale. ergo solo una CAA o ente similare puo' decidere di fare una cosa del genere, anche avendo le enormi risorse a disposizione.

ovviamente cio' implica che la CAA in oggetto sia lungimirante e pragmatica, il che e' una cosa estremamente rara dalle nostre parti

rimane da vedere cosa si intende per "low cost", e se la cosa rimarra' confinata allo spazio aereo UK.

http://www.funkeavionics.de/45.html?&L=1 (http://www.funkeavionics.de/45.html?&L=1)

"We are currently contracted by UK NATS to develop a prototype of a Low-Power ADS-B Transceiver (LPAT). It is based on our traffic monitor TM250 and our Mode S transponder TRT800H. LPAT shall be suited for temporary installation in ultralight aircraft and other flying sport equipment. It receives traffic information via ADS-B, FLARM and Mode S and displays it to the pilot on its integrated display. ADS-B messages are sent out with reduced power (30W) on 1090 MHz. Evaluation will be performed in a technology project co-funded by the SESAR Joint Undertaking (SJU) starting later in 2014."

low power 30 watt... uff.

che dire,si possono solo applaudire iniziative simili, che sono principalmente per motivi legali totalmente al di fuori della portata dell'industria privata

rimane il punto interrogativo sul costo.
se l'aggeggio costera' nord di 2000 euro, come sospetto costera', rimane un po troppo caro.

Cerchiamo di riesumare questo thread...

Un paio di weekend fa, visto il tempo schifoso di qui, che non mi ha permesso di volare e non avendo proprio nient'altro di meglio da fare, ho fatto qualche esperimento su questo progetto.

Volevo condividere qui alcune considerazioni con chi altro ci stesse sperimentando.

Sul moteiono stiamo usando un paio di uscite digitali come porta seriale (grazie alla libreria SoftwareSerial) per collegarci all'unita' GPS, che quindi non e' una porta seriale vera.
Il GPS che abbiamo scelto (ublox 7M) di default vuole parlare sulla seriale a 9600 bpm, ho pero' riscontrato (almeno nel mio caso, forse le mie saldature non sono proprio il massimo...) che non tutti i caratteri vengono ricevuti correttamente dal moteino con il risultato che molte sentenze NMEA vengono perse, in particolare le GGA (per noi vitali, dato che contengono l'altitudine).
E' possibile inviare alcuni comandi (nella funzione setup()) al GPS per configurarlo ad andare più piano a 4800 bpm, cosi facendo la ricezione di dati dal GPS funziona perfettamente solo che l'ublox non sempre si lascia configurare (qui devo comunque fare delle altre prove).

La libreria che usiamo per fare parsing di NMEA: TinyGPS prende in considerazione solo le sentenze GGA e RMC (che tra l'altro sono proprio quelle che ci interessano, le altre sentenze con le posizioni dei satelliti ecc sono inutili nel nostro caso) e quindi anche qui sarebbe possibile configurare il GPS per inviare solo ed esclusivamente GGA ed RMC. In tal modo sul moteino eviteremmo di perdere tempo a leggere dati che non ci servono.

ciao

ti posso dire che io ho usato la libreria softwareserial a velocita' ben piu' elevate senza nessun problema

devi fare attenzione a non usare porte digitali che siano gia' usate dal moteino per parlare con il trasceiver


D8 sino a D13 sono usati dal transceiver e non li puoi usare per softwareserial

Attualmente sto usando le porte digitali 6 e 7. Il GPS si comporta nello stesso modo, perdendo caratteri, anche se lo collego ad un Arduino normale, invece funziona (anche a 9600) se lo collego direttamente ai pin TX e RX dell'interfaccia USB seriale per programmare i moteini. Boh c'è sicuramente qualche problema (da chiarire) con il mio modulo GPS.

Comunque ho fatto alcune prove ieri sera, inviando questa sentenza NMEA proprietaria della ublox al GPS: $PUBX,41,1,0007,0002,4800,0*12
Lo si può configurare a 4800 bpm e si disabilitano anche tutti gli altri protocolli proprietari ublox in uscita lasciando solo NMEA.
Dopodiché la seriale del GPS può essere chiusa e riaperta a 4800.

Per disabilitare invece le sentenze che non ci interessano (GLL, GSA, GSV e VTG) e tenere solo GGA e RMC occorre usare il protocollo binario ublox, e questo e' il codice per farlo:

   // Disable GLL sentences
   byte cmd[] = {0xB5, 0x62, 0x06, 0x01, 0x08, 0x00, 0xF0, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2A};
   gpsserial.write(cmd,sizeof(cmd));
   gpsserial.flush();

   // Disable GSA sentences
   cmd[7] = 0x02;
   cmd[14] = 0x01;
   cmd[15] = 0x31;
   gpsserial.write(cmd,sizeof(cmd));
   gpsserial.flush();

   // Disable GSV sentences
   cmd[7] = 0x03;
   cmd[14] = 0x02;
   cmd[15] = 0x38;
   gpsserial.write(cmd,sizeof(cmd));
   gpsserial.flush();

   // Disable VTG sentences
   cmd[7] = 0x05;
   cmd[14] = 0x04;
   cmd[15] = 0x46;
   gpsserial.write(cmd,sizeof(cmd));
   gpsserial.flush();

Testato il tutto ieri sera e funziona, ora posso iniziare a fare prove più serie...

io ho usato le porte 5 e 6 e funzionano senza problemi a 19200

aggeggio molto interessante


http://www.pilotaware.co.uk/ (http://www.pilotaware.co.uk/)

Forte, io ho comprato la chiavetta che c'è anche in quel kit e ricevo l'ADS-B sul computer con un antennina ridicola. Si può fare anche SDRadio, una ganzata!
Per dire si riceve anche la temperatura dei sensori termo o le radio DAB: esiste una miriadie di programmi (peraltro praticamente inutili  :D :D :D)

eccone uno "fato in casa" col cugino di Arduino

http://www.eaa.org/en/eaa/aviation-communities-and-interests/homebuilt-aircraft-and-homebuilt-aircraft-kits/resources-for-while-youre-building/building-articles/instruments-and-avionics/live-weather-and-traffic-for-less-than-$120 (http://www.eaa.org/en/eaa/aviation-communities-and-interests/homebuilt-aircraft-and-homebuilt-aircraft-kits/resources-for-while-youre-building/building-articles/instruments-and-avionics/live-weather-and-traffic-for-less-than-$120)

beh insomma cugino no, sono due cose radicalmente diverse

comunque progetto interessante, che dimostra che le cifre chieste per i vari ADS-B certificati sono estorsione

La "estorsione" continua anche se si parla di apparati lontani da qualsiasi omologazione!!

- il progetto usa circa 120$ di pezzi + una scatola stampata 3d
- lo stesso progetto in versione commerciale costa ... OTTOCENTONOVANTANOVE dollari!!
http://www.sportys.com/pilotshop/stratus (http://www.sportys.com/pilotshop/stratus)

E' vero che è montato, garantito e assemblato bene ma mi sembra un tipo prezzo "aeronautico".

Comunque in USA dove puoi avere il meteo in tempo reale è un oggetto veramente interessante.

Arturo

devi considerare anche che a chi costruisce sta roba i 120$ si dimezzano perlomeno
e non e' che c'e' manco tanta ricerca e sviluppo da fare. sta roba e' storia.

Costruirlo, ma forse è più corretto dire montarlo, mi piacerebbe ma loro parlano solo della possibilità di interfacciarlo con un iPad e ForeFlight.
Pensate che sia possibile interfacciarlo ance con qualche programma per Android o comunque qualche cosa di diverso??

Grazie
Arturo

Si, ma senza radar meteo ci fate poco..

spiega

Ero ironico... Mi sembra che sugli ULM, avanzati o meno che siano, si tenda sempre di più a farli somigliare a cockpit di liners, piuttosto che ultraleggeri.

Non lo so, con tutti questi ammennicoli mi sembra che della filosofia ultraleggeristica vi sia ben poco. Ok le macchine performanti, superveloci, ma non chiamiamole ultraleggeri.

Sarà che per me, l'ultraleggero è vento in faccia e tubi & stracci... Ma mi sembra si esageri a riempire le cabine di pilotaggio con luci e cicalini manco fosse il 25 Dicembre..

A proposito di strumentazione Hi Tec... la FAA ha appena approvato una STC per permettere di istallare il Dynon D10, strumento non certificato,anche su 152,172, PA28
Direi che arrivarci a distanza di una quindicina d'anni da quando lo si è cominciato a montare sugli ultraleggeri, è un buon inizio. :)

La "filosofia ultraleggera"? Si evolve in fretta. Quella AG? ;)

la "filosofia ultraleggera" non consiste nel volare sull'aereo piu' sfigato possibile

consiste nel volare sull'aereo piu' figo possibile senza dover essere milionari

Best of!
 ;D

Crono, t'hanno fregato ...  :D :D

http://www.flywatching.com/ (http://www.flywatching.com/)

C'è qualche cosa che mi sfugge ... GPS + internet significa che possono sapere dove sono io ma e gli altri???
Possono usare Flightradar24 ma mi sembra poco ...

Morale: sento puzzo di bruciato.

Arturo

Su airnavpro hai la stessa funzione

ma devi avere il segnale internet, in volo.

Anche con quel programma linkato da bebix

Si, infatti lo segnalavo per entrambi. A occhio sono soluzioni poco utili, salvo determinate zone.

Anche secondo me, lo linkato giusto per conoscenza