Re: GPS-Daten und RTC über CAN-Bus übertragen
Verfasst: Mo Jul 27, 2015 1:15 pm
ich frage mich gerade nur, wo genau im MS3 Source Code das Rückrechnen stattfindet.
Weil teilweise ist die Übertragung ziemlich suboptimal gelöst.
Beispielsweise bei den GPS-Sekunden.
Die GPS Koordinaten in Dezimalformat müssen vor dem Senden erst in Sekunde, Minute und Grad umgerechnet werden.
Die MS berechnet dann hierraus dann wieder das ursprüngliche Dezimalformat. Normal kein Problem, da Minute und Grad eh nur ganzzahlige Werte sind.
Die Sekundenwerte können aber bei U16 drei Nachkommastellen haben. Was auch Sinn macht wenn eine hohe Genauigkeit möchte.
Normal würde ich den Wert (z.B. 59.476) einfach *1000 multiplizieren und dann nach dem Empfangen wieder durch 1000 teilen.
Weil größer als 59.999 muss ich eh nicht übertragen.
Aber die MS multipliziert den Eingangswert mit (6/1000).
Das multiplizieren mit *6 ist ja eigentlich total unnötig und kostet mir letztendlich Genauigkeit, da ich ja vor dem Senden deswegen auch erst durch 6 teilen muss.
Im Idealfall würde ich den Source Code einfach abändern, dass nur noch /1000 geteilt wird.
Finde die Umrechnung dort aber nirgends.
Ähnliches gilt für den GPS Speed.
Der wird ja eigentich schon als km/h-Wert übertragen lt. I/O-Extender bzw dieses Online Source Codes von jbperf.
Die Megasquirt zeigt den auf zwei Nachkommastellen an. Also würde man normal annehmen *100 und in der MS /100.
Aber leider rechnet die MS da mal wieder mehr um als sie eigentlich soll.
Wenn ich z.B. "1000" übertrage, zeigt mir die MS 277.56 kmh an.
Also Umrechnungsfaktor (27756/1000)=27,756
22233 übertragen für "222.33 km/h" zeigt sie mir 7956.72 (km/h) an.
Also Umrechnungsfaktor (795672/22233)=35,787
Vondaher scheint die Umrechnung hier etwas seltsam zu sein. Bzw. kann man damit nichts anfangen.
Möchte das gerne auf *100 und /100 beschränken. Wäre ja viel besser.
Weil teilweise ist die Übertragung ziemlich suboptimal gelöst.
Beispielsweise bei den GPS-Sekunden.
Die GPS Koordinaten in Dezimalformat müssen vor dem Senden erst in Sekunde, Minute und Grad umgerechnet werden.
Die MS berechnet dann hierraus dann wieder das ursprüngliche Dezimalformat. Normal kein Problem, da Minute und Grad eh nur ganzzahlige Werte sind.
Die Sekundenwerte können aber bei U16 drei Nachkommastellen haben. Was auch Sinn macht wenn eine hohe Genauigkeit möchte.
Normal würde ich den Wert (z.B. 59.476) einfach *1000 multiplizieren und dann nach dem Empfangen wieder durch 1000 teilen.
Weil größer als 59.999 muss ich eh nicht übertragen.
Aber die MS multipliziert den Eingangswert mit (6/1000).
Das multiplizieren mit *6 ist ja eigentlich total unnötig und kostet mir letztendlich Genauigkeit, da ich ja vor dem Senden deswegen auch erst durch 6 teilen muss.
Im Idealfall würde ich den Source Code einfach abändern, dass nur noch /1000 geteilt wird.
Finde die Umrechnung dort aber nirgends.
Ähnliches gilt für den GPS Speed.
Der wird ja eigentich schon als km/h-Wert übertragen lt. I/O-Extender bzw dieses Online Source Codes von jbperf.
Die Megasquirt zeigt den auf zwei Nachkommastellen an. Also würde man normal annehmen *100 und in der MS /100.
Aber leider rechnet die MS da mal wieder mehr um als sie eigentlich soll.
Wenn ich z.B. "1000" übertrage, zeigt mir die MS 277.56 kmh an.
Also Umrechnungsfaktor (27756/1000)=27,756
22233 übertragen für "222.33 km/h" zeigt sie mir 7956.72 (km/h) an.
Also Umrechnungsfaktor (795672/22233)=35,787
Vondaher scheint die Umrechnung hier etwas seltsam zu sein. Bzw. kann man damit nichts anfangen.
Möchte das gerne auf *100 und /100 beschränken. Wäre ja viel besser.