Newsgroup: it.hobby.elettronica.digitale
Titolo: NMEA: come memorizzare i dati

Ciao,
domanda forse ingenua. Sto scrivendo una libreria per gli AVR per 
decodificare i pacchetti NMEA (non solo GPS). A differenza di quanto si 
fa su macchine piï¿œ performanti o addirittura su un PC c'ï¿œ da tenere in 
considerazione lo spazio occupato in memoria.
Prendiamo per esempio una classica stringa:
$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a*hh
  1) Time (UTC)
  2) Status, V = Navigation receiver warning
  3) Latitude
  4) N or S
  5) Longitude
  6) E or W
  7) Speed over ground, knots
  8) Track made good, degrees true
  9) Date, ddmmyy
10) Magnetic Variation, degrees
11) E or W
12) Checksum
Quale modo furbo conviene utilizzare per memorizzare i dati ricevuti?
Potrei semplicemente memorizzare i campi in stringhe, ma poi quando 
dovrï¿œ utilizzarli dovrï¿œ convertirli ogni volta in numeri.
L'ideale sarebbe memorizzarli nel formato corretto, ad esempio:
* time e date in una struct che contenga i campi hour, minute, second ecc...
* coordinate e velocitï¿œ in float
Non mi piace perï¿œ usare la virgola mobile. Volendo evitarla dovrei usare 
un intero a 32 bit per la longitudine e longitudine e a 16 per gli altri 
rendendo poco uniformi i vari dati.
Ultima perplessitï¿œ: visto che i vari progetti faranno uso di stringhe 
NMEA diverse e quindi difficilmente saranno usate tutte assieme vorrei 
evitare di allocare lo spazio per poi lasciare i campi inutilizzati.
Perï¿œ, viceversa, la routine di decodifica vorrebbe avere il puntatore 
alla struttura ricevente.
Mi ï¿œ venuto in mente di utilizzare una serie di #define e successivi 
#ifdef per escludere a livello di compilazione la dichiarazione dei 
campi stringa e il blocco di decodifica relativo ma mi sembra poco elegante.
Suggerimenti? :)
Marco

 Suggerimenti? :)
Ti sei giï¿œ suggerito tutto da solo :-)
P.S.
Fra un po' anche io dovrï¿œ parsare dati NMEA su un AVR!
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org

 Fra un po' anche io dovrï¿œ parsare dati NMEA su un AVR!
Benvenuto! Io con l'NMEA ci gioco un po' ovunque: PC, Rabbit, ARM e ora AVR.
Marco

 rendendo poco uniformi i vari dati.
Tieni presente che un float a 32 bit non ti fornisce la sufficiente
risoluzione per memorizzare qualsiasi coordinata generata dalle sentenze
NMEA. In alcune condizioni (che ora su due piedi non ricordo) c'� un errore
vicino al mezzo metro; in molte applicazioni pu� essere irrilevante,
comunque � bene tenerlo a mente.
-- 
emboliaschizoide.splinder.com

 comunque � bene tenerlo a mente.
A parte che lo standard non mi � chiaro: riporta appunto llll.ll per la 
latitudine e yyyyy.yy per la longitudine quindi con 2 cifre decimali. Ma 
ho qui un log di un GPS che ha 3 cifre decimali...
Comunque nel caso peggiore avrei 18000000 (180� 00.000') che dovrebbe 
starci in un float o sbaglio?
Ad ogni modo se anche volessi usare un int32 dovrei sapere se moltiplico 
per 100 o per 1000, non voglio mettermi via anche un campo dove inserire 
il moltiplicatore! Per� lo standard dice 2 cifre decimali, questo GPS ne 
da 3.
Ognuno fa a modo suo?
Marco

 starci in un float o sbaglio?
Non � una questione di starci, � una questione di risoluzione. Rispetto ai
fixed point, i numeri floating point ovviamente sacrificano risoluzione in
favore di un range estremamente pi� grande. Puoi fare degli esperimenti con
questa calcolatrice online:
http://babbage.cs.qc.cuny.edu/IEEE-754/Decimal.html
Prendiamo ad esempio le coordinate di Roma indicate su Wikipedia: 41.893056
N, 12.483333 E. Con la calcolatrice sopra citata puoi vedere che i punti
(41.893054,12.483333) e (41.893056,12.483333) sono indistinguibili; se li
convertiamo in UTM, ad esempio con questo tool:
http://www.apsalin.com/convert-geodetic-to-universal-transverse-mercator.aspx
Otteniamo le coordinate (291219.612045562,4640965.05372734) e
(291219.618563301,4640965.27580443), cio� due punti che distano
(-0.006517739,-0.22207709), cio� circa 22 cm. E questo a Roma, figurati a
Berlino o a Reykiavik o come diavolo si scrive, da qualche parte
dev'esserci una j. :)
-- 
emboliaschizoide.splinder.com

 convertiamo in UTM, ad esempio con questo tool:
[cut]
Ricevuto!
Marco

 intero che mi dice quanto cifre ho dopo la virgola? Argh...
Non � necessario farlo a runtime, anche questo pu� essere 
configurabile a compile time con una macro.
Poi ti devi fare anche delle macrettine di accesso ai membri della 
struttura che dividono/moltiplicano per il numero giusto ed il gioco � 
fatto.
Questa soluzione, come dicevo in un post precedente, funziona finch� 
la tua libreria non deve interfacciarsi con il mondo esterno, 
altrimenti la precisione con cui fornisci i dati conta e deve essere 
nota a priori.
Comunque, anche in questo caso, io stabilirei una precisione che va 
bene per la mia applicazione e userei quella.
Se a te bastano 2 cifre e un GPS ne fornisce 3, scarterai la terza; 
viceversa se ne gestisci 3 e un GPS ne ha solo 2, la terza sar� sempre 
a 0.
In definitiva io non mi complicherei la vita fino a quando non � 
necessario.


 viceversa se ne gestisci 3 e un GPS ne ha solo 2, la terza sar� sempre a 0.
Si, in effetti � forse pi� semplice questa via. Definisco la precisione 
e poi nella routine di decodifica agisco di conseguenza.
Marco

 e poi nella routine di decodifica agisco di conseguenza.
Forse come prima versione � pi� saggio fare il minimo indispensabile. 
Una volta testato il funzionamento si fa sempre in tempo ad espandere.

 Una volta testato il funzionamento si fa sempre in tempo ad espandere.
Penso anche io. Per ora mi accontento di definire la precisione con una 
define, poi una volta capiti bene i limiti di ciascun campo vedr� di 
impostare la migliore possibile!
Ciao!
Marco

 parte quale potr� essere la massima rilevata :(
Se per profondit� intendi l'asse z (la quota, insomma) se non sbaglio 
questa ha precisione minore rispetto alle altre due coordinate. Quindi 
anche se fossero date con lo stesso numero di cifre decimali queste non 
sarebbero tutte significative. In ogni caso il tuo apparecchio non andr� 
nello spazio (o s�? :-o) o nella fossa delle Marianne (nella quale, mi 
dicono, la ricezione � un po' scadente:-)
Comunque fino a 12000m (mi sembra sia questo il limite imposto dalla 
NASA) con 16bit avresti la precisione del mezzo metro.
Ciao!
Pasu

 NASA) con 16bit avresti la precisione del mezzo metro.
Il DBT o il DBT sono dati che normalmente vengono generati dagli 
ecoscandagli quindi misurano la profondit� del fondale dall'imbarcazione 
  di superficie o immersa.
Normalmente arrivano a 100 m di range utile, con la precisione (o meglio 
risoluzione) al decimetro.
Per� il mio era un esempio per dire che bisogna sempre sapere 
concretamente che utilizzo si fa del dato e poi ragionarci sopra per 
trovare il compromesso migliore. Insomma, lo standard non aiuta!
Ma come fanno gli altri? Meglio che provo a vedere qualche codice gi� 
scritto...
Marco
ps. comunque il mio funziona, solo che ha le limitazioni appena esposte!

 scritto...
Ottima idea...Reinventare la ruota non aiuta quasi mai.
Ciao
Pasu

 Ottima idea...Reinventare la ruota non aiuta quasi mai.
Infatti le persone serie utilizzano float o double :o)
Ho appena trovato 3-4 sorgenti (anche per AVR) in cui utilizzavano 
comodamente una scanf e in una riga di codice si mettevano via tutto il 
pacchetto :(
Si, per� cos� non vale...
Sgrunt, ma ci vuole un'enormit� di RAM (e anche una discreta velocit� di 
calcolo) per fare ci�!
Marco

 calcolo) per fare ci�!
Infatti, sarebbe interessante confrontare il codice macchina generato 
dal tuo metodo ed il loro...
Ciao!
Pasu