Creatieve ideeën Bas!
Hoe het werkt:
- elk NMEATemplate is er 1 van, en die worden gelezen uit de NMEATemplatesfile.
- Dus er wordt 1 RPM ingelezen, geen twee. Ik zou er twee kunnen maken (RPM,E,1 en RPM,E,2)
- Dat vereist wat aanpassingen aan het programma, het is het toevoegen van een nieuw recordtype (bij inlezen, vullen, loggen en naar USB zenden). Het kan. Zelf 2 RPMs in de Templates zetten zal er toe leiden dat alleen de laatste van de twee wordt gebruikt.
-let op, de RPM in N2K is 1 byte groot. Max waarde is 124 (hoger is voor foutmeldingen). 124 is m.i.te weinig voor Performance.
Dan XDR.
In een XDR kunnen maximaal 4 groepen van 4 velden. Dat komt door het maximum aantal posities in een NMEA183 bericht, uit mijn hoofd 82 characters incl $ etc.
De layout is nu $UPXDR,G,%sogperf,P,SailPerf voor de 1e groep van 4.
De G is voor Generic, de %sogperf is een getal, de P staat voor Procent en de SailPerf is de Transducer ID. Dit is allemaal officieel NMEA; een XDR hoort die 4 velden te hebben.
DIt voorbeeld heeft (van de eerste , tot het eind) zo'n 19 characters Payload, ex de header.
De %sogperf wordt een getal van 4 posities, en 'SailPerf' zou korter kunnen, dus het kan ietsje korter.
En dit soort blokjes van 4 kan er dus 3 a 4 keer in, in 1 XDR.
Als SignalK netjes de hele XDR kan parsen dan kan er meer mee in 1 XDR.
Voor XDR geldt hetzelfde als voor RPM: er wordt er 1 gelezen. Geen twee. Ook dat zou wel kunnen, maar vereist dezelfde wijzigingen aan het programma als een extra RPM. Het kan.
Dan nog dit: bij het inlezen van de NMEATemplates wordt hard gecontroleerd of er geen teksten in staan waar het programma niets mee kan. Een tikfout in een $variabele, of een schrijffout in SailPerf, wordt afgevangen. Dat is nodig om ergere fouten tijdens uitvoering te voorkomen.
SailPerf bijvoorbeeld staat daar zo omdat het plan is om daarmee in een Miniplex een Proprietary bericht over performance te maken. Dan moet die transducer, SailPerf, wel herkend worden door de miniplex.
Hetzelfde geldt voor de Signal K Parser.
Een tikfout (SailPref) zou ertoe kunnen leiden dat mensen denken dat het programma of hun mux of hun display het niet doet, terwijl het hun eigen tikfout is
Tik op de vingers dus bij inlezen:
In het programma dat de templates leest staat:
allowed=""," ","A","K","N","M","C","T","E","L","W","V","S","R","$xte","$dts","$shiftmsg","$curang","$curgeo","$curkts","$targetheel","$heel",
"$actleeway","$leeway","$bestdown","$bestup","$DAoff","$UAoff","$diffdeg","$dtl","$ete","$ttl","$vmgwp",
"$sogperf","$sogperfci","$stwperf","$vmgperf","$cursog","$orthospd","$speedshort","$targetspeed","$targetvmg","$vmg","$rsa",
"$awa","$aws","$geo","$nexttwa","$shift","$twa","$tws","G","P","SailPerf","1","2","$bestangle"
Zoals je ziet, nogal een controle. Alle letters die in een NMEA183 kunnen voorkomen, de 1 en de 2 voor motornummer, de G en P en SailPerf uit de XDR. En alles met $ is een variabele uit het programma.
Ik kan simpel deze lijst uitbreiden met de keywords die Signal K herkent.
Maar de controle blijft wel nodig.... we moeten de gebruiker een beetje tegen zichzelf beschermen
De XDR zelf aanpassen in de templates is eenvoudig.
Als jij een lijstje van wat door Signal K herkende variabelen levert stop ik ze in de XDR.