Naza Telemetrie für FrSky D4R-II und D8R
- Themenstarter der-Frickler
- Beginndatum
- Status
So, NSEW wurde gefixt:
GPS Fix ist bei T2 ja mit drin, bzw ja ich les es aus und schreibs mit rein.
Sat * 10 + GPS Fix (1 = GPS, 2 = DGPS)
Code räum ich noch bissl auf, wird Teil des Trackerprojekts. Kannste dann haben.
Sag mal weißt du ob ich den ACC kram usw. rausschmeißen kann, und stattdessen die GPS Daten in 5Hz übertragen kann? Sollte ja noch unter den 1200bps liegen dann?
GPS Fix ist bei T2 ja mit drin, bzw ja ich les es aus und schreibs mit rein.
Sat * 10 + GPS Fix (1 = GPS, 2 = DGPS)
Code räum ich noch bissl auf, wird Teil des Trackerprojekts. Kannste dann haben.
Sag mal weißt du ob ich den ACC kram usw. rausschmeißen kann, und stattdessen die GPS Daten in 5Hz übertragen kann? Sollte ja noch unter den 1200bps liegen dann?
Zuletzt bearbeitet:
Hi Rangarid, gehe ich richtig, dass du nicht an der Naza Decoder Version bastelst sondern an einer welche direkt an das GPS anzuschliessen ist?
Besteht also noch Interesse an der Decoder variante oder baust du da auch rum und ich muss nichts mehr machen?
Ansonsten würde ich den Code für die Naza auch noch etwas entrümpeln und hier veröffentlichen, GPS wird ja korrekt übertragen bei mir.
5hz ist denke ich jedoch etwas zu viel, ich würde mal so 2hz anpeilen für die GPS Daten und den "Rest" 1x
Besteht also noch Interesse an der Decoder variante oder baust du da auch rum und ich muss nichts mehr machen?
Ansonsten würde ich den Code für die Naza auch noch etwas entrümpeln und hier veröffentlichen, GPS wird ja korrekt übertragen bei mir.
5hz ist denke ich jedoch etwas zu viel, ich würde mal so 2hz anpeilen für die GPS Daten und den "Rest" 1x
Hi aargau,
Ja, SAM bastelt nur an der NMEA nach FrSky Implementierung für ein eigenes GPS Modul. An deiner Variante bin ich und auch andere hier weiterhin interessiert. Ich wäre vor allem an der korrekten Umwandlung/Umrechnung der GPS Daten interessiert.
Wenn ich das richtig verstehe hast du den FrSky Encoder jetzt geändert so das sie weniger und dafür öfters sendet?
Ja, im Prinzip könnte man bei dieser Implementierung die beiden nicht benötigten FrSky Frames weglassen und das GPS Frame öfters senden, man muss beim FrSky nur aufpassen das man die Funkstrecke nicht überfordert.
Die Schnittstelle hat zwar 9600 baud, aber zumindest früher war es so das nur deutlich weniger Zeichen/sec übertragen werden konnten. Wenn man also zu schnell auf den Empfänger schrieb dann gingen Zeichen verloren.
2Hz und nur das GPS Frame sollte aber drin sein denke ich.
P.S. Hoffe du findet deinen Kopter wieder!
Ja, SAM bastelt nur an der NMEA nach FrSky Implementierung für ein eigenes GPS Modul. An deiner Variante bin ich und auch andere hier weiterhin interessiert. Ich wäre vor allem an der korrekten Umwandlung/Umrechnung der GPS Daten interessiert.
Wenn ich das richtig verstehe hast du den FrSky Encoder jetzt geändert so das sie weniger und dafür öfters sendet?
Ja, im Prinzip könnte man bei dieser Implementierung die beiden nicht benötigten FrSky Frames weglassen und das GPS Frame öfters senden, man muss beim FrSky nur aufpassen das man die Funkstrecke nicht überfordert.
Die Schnittstelle hat zwar 9600 baud, aber zumindest früher war es so das nur deutlich weniger Zeichen/sec übertragen werden konnten. Wenn man also zu schnell auf den Empfänger schrieb dann gingen Zeichen verloren.
2Hz und nur das GPS Frame sollte aber drin sein denke ich.
P.S. Hoffe du findet deinen Kopter wieder!
Zum Thema umrechnen kann ich euch folgendes geben:
latitude/longitude liegt im Format Integer DDMMMMMM (Original Koordinate DDMM.MMMM) vor
deg = latitude / 1000000;
deg = longitude / 1000000;
raw => N50.12345, E 8.12345
raw = deg + ((double)latitude/10000.0 - deg*100)/60.0;
raw = deg + ((double)longitude/10000.0 - deg*100)/60.0;
min = latitude/10000 - deg*100;
sec = ((double)latitude/10000.0 - latitude/10000) * 60;
min = longitude/10000 - deg*100;
sec = ((double)longitude/10000.0 - longitude/10000) * 60;
rad = raw * PI/180.0;
rad = raw * PI/180.0;
latitude/longitude liegt im Format Integer DDMMMMMM (Original Koordinate DDMM.MMMM) vor
deg = latitude / 1000000;
deg = longitude / 1000000;
raw => N50.12345, E 8.12345
raw = deg + ((double)latitude/10000.0 - deg*100)/60.0;
raw = deg + ((double)longitude/10000.0 - deg*100)/60.0;
min = latitude/10000 - deg*100;
sec = ((double)latitude/10000.0 - latitude/10000) * 60;
min = longitude/10000 - deg*100;
sec = ((double)longitude/10000.0 - longitude/10000) * 60;
rad = raw * PI/180.0;
rad = raw * PI/180.0;
Zuletzt bearbeitet:
So, ich denke ich habe den Code mal soweit gebracht, dass nun alles sauber Funktioniert.
Angepasst habe ich im Groben:
Geblieben ist die Ausgabe bei 1hz GPS, falls jemand mehr braucht kann er ja mal testen ob das Protokoll 5hz verkraftet, 1hz sollte aber eigentlich für die Telemetrie reichen?
Wäre cool wenn ihn mal ein paar Testen würden und falls Fehler gefunden werden diese hier melden würden.
Habe übrigens herausgefunden wieso mein Copter nicht da lag wo er laut Telemetrie liegen sollte... War ein kleiner Bug der die Daten falsch berechnet hat und somit um ca. 10m falsch lag ^^
Für die Zukunft könnte ich mir jetzt noch vorstellen den Stromverbrauch runterzufunken, dazu bräuchte man ja nur einen Sensor und etwas Code
Interessant wäre auch noch eine Zellenüberwachung... Aber durch den 8bit DAC vom Arduino war dies in meinen Versuchen viel zu ungenau, ev. hat da ja jemand eine Idee?
Anhang anzeigen Naza2FrskyHubv2.rar Achtung: Angepasste Version für den ProMicro, da Serial1 nur via USB erreichbar. Einfach korrekte Version flashen ^^ Hoffe auf dem Pro Mini läuft der Code so auch noch!
Angepasst habe ich im Groben:
- Naza Decoder ausgabe in Long statt double (erspart mehrfaches umrechnen...)
- Umrechnen der Dezimal Koordinaten in Grad Minuten
- Senden der Höhe sowohl als GPS Alt als auch als Vario Alt (wird für die Berechnung auf der Taranis verwendet)
- Unnötige (leere) Daten werden nicht mehr gesendet
Geblieben ist die Ausgabe bei 1hz GPS, falls jemand mehr braucht kann er ja mal testen ob das Protokoll 5hz verkraftet, 1hz sollte aber eigentlich für die Telemetrie reichen?
Wäre cool wenn ihn mal ein paar Testen würden und falls Fehler gefunden werden diese hier melden würden.
Habe übrigens herausgefunden wieso mein Copter nicht da lag wo er laut Telemetrie liegen sollte... War ein kleiner Bug der die Daten falsch berechnet hat und somit um ca. 10m falsch lag ^^
Für die Zukunft könnte ich mir jetzt noch vorstellen den Stromverbrauch runterzufunken, dazu bräuchte man ja nur einen Sensor und etwas Code
Interessant wäre auch noch eine Zellenüberwachung... Aber durch den 8bit DAC vom Arduino war dies in meinen Versuchen viel zu ungenau, ev. hat da ja jemand eine Idee?
Anhang anzeigen Naza2FrskyHubv2.rar Achtung: Angepasste Version für den ProMicro, da Serial1 nur via USB erreichbar. Einfach korrekte Version flashen ^^ Hoffe auf dem Pro Mini läuft der Code so auch noch!
Super, danke, ich schaue es mir mal an.
Stromsensor und auch Spannungssensor gehen recht einfach am Arduino. Spannung habe ich bei den alten Empfängern aber eh am analogen Port und Strom brauche ich für mich nicht wirklich.
Auch driften die Einzelzellen bei meinen Akkus so wenig das es bei 3S keinen großen Sinn macht diese einzeln zu überwachen.
Der A/D Wandler des Arduino hat übrigens 10 bit. Da er normalerweise mit 5V Referenz läuft kannst du diese per Spannungsteiler so anpassen das es zur Gesamtspannung passt. Für den Stromsensor steht dir aber meist nur ein teil des Bereiches zur Verfügung, da diese meist nicht von 0-5V ausspucken. Bei Einzelzellenüberwachung hast du das Problem das die Zellen ja keine gemeinsame Masse haben, sondern das + der einen die Masse der nächsten ist. Du musst die Messungen also entweder galvanisch trennen oder eben an AD1 Zelle 1, an AD2 Zelle 1+2 usw.. messen, damit wird es dann eben auch nicht soo genau.
Stromsensor und auch Spannungssensor gehen recht einfach am Arduino. Spannung habe ich bei den alten Empfängern aber eh am analogen Port und Strom brauche ich für mich nicht wirklich.
Auch driften die Einzelzellen bei meinen Akkus so wenig das es bei 3S keinen großen Sinn macht diese einzeln zu überwachen.
Der A/D Wandler des Arduino hat übrigens 10 bit. Da er normalerweise mit 5V Referenz läuft kannst du diese per Spannungsteiler so anpassen das es zur Gesamtspannung passt. Für den Stromsensor steht dir aber meist nur ein teil des Bereiches zur Verfügung, da diese meist nicht von 0-5V ausspucken. Bei Einzelzellenüberwachung hast du das Problem das die Zellen ja keine gemeinsame Masse haben, sondern das + der einen die Masse der nächsten ist. Du musst die Messungen also entweder galvanisch trennen oder eben an AD1 Zelle 1, an AD2 Zelle 1+2 usw.. messen, damit wird es dann eben auch nicht soo genau.
Also ich habe bei mir GPS mit 5Hz gelesen und mit 4Hz an Frsky rausgegeben. Das ist kein Problem.
Frsky kann bis zu 1200bps senden, was zufällig eh der Baudrate von 9600 entspricht...
9600 baud = 72,00 KB/min= 1,20 KB/s= 9,60 Kbps= 1,17 KiB/s= 4,32 MB/h
Ich bin mir aber grad nicht ganz sicher, ob es nicht weniger war, jedenfalls laut Anleitung sind es 1200bps.
Bei der Taranis kann man Flight/Telemetry zurücksetzen. Das setzt dann die Starthöhe und Distance auf 0. Schau mal ob es sowas bei der 9X auch gibt.
Frsky kann bis zu 1200bps senden, was zufällig eh der Baudrate von 9600 entspricht...
9600 baud = 72,00 KB/min= 1,20 KB/s= 9,60 Kbps= 1,17 KiB/s= 4,32 MB/h
Ich bin mir aber grad nicht ganz sicher, ob es nicht weniger war, jedenfalls laut Anleitung sind es 1200bps.
Bei der Taranis kann man Flight/Telemetry zurücksetzen. Das setzt dann die Starthöhe und Distance auf 0. Schau mal ob es sowas bei der 9X auch gibt.
Ja, das ist ja einfach zu testen:
Teiler ändern und gut is.
Weiß gerade nicht wie oft das Naza Updated, aber es wird deutlich öfter als 1Hz sein.
Ist halt immer die Frage wie gut die Parser am Boden damit klarkommen, laut Protokoll Definition erwarten die eben nur ein GPS Paket pro sec vom Hub. Auch das weglassen der nicht benötigten Felder könnte hier evtl ein Problem machen.
Klar geht das zurüksetzten auch, aber wenn man schon die GPS Daten ins Baro Feld schreibt, dann könnte man es ja auch im selben "Stil" machen.
Code:
// 1000ms (1s) payload, construct Frame 2 on every 5th loop
if((msCounter % 5) == 0) {Weiß gerade nicht wie oft das Naza Updated, aber es wird deutlich öfter als 1Hz sein.
Ist halt immer die Frage wie gut die Parser am Boden damit klarkommen, laut Protokoll Definition erwarten die eben nur ein GPS Paket pro sec vom Hub. Auch das weglassen der nicht benötigten Felder könnte hier evtl ein Problem machen.
Klar geht das zurüksetzten auch, aber wenn man schon die GPS Daten ins Baro Feld schreibt, dann könnte man es ja auch im selben "Stil" machen.
Zuletzt bearbeitet:
Hi
Also zumindest bei der Taranis wird das von der Funke berechnet, heisst er nimmt die ersten Daten (z.B. 310m) als 0Punkt und rechnet dann darauf die höhe, bei 320m Baro Daten wären es also dann 10m welche die Taranis anzeigt.
Edit: hab dich falsch verstanden, du meinst, das man abwartet bis die Daten einigermassen genau sind, korrekt? Und erst dann diese überträgt?
Ups stimmt, sind 10bit, jedoch auch nicht immer nicht wirklich genau Selbst um eine Autobatterie zu messen kriege ich keine 0.01V hin (theoretisch 0.015V pro Bit, jedoch rauscht das Ding noch also wohl eher 0.05V genauhheit...)
Für die Zellenüberwachung habe ich mal mit Spannugnsteilern was versucht, jedoch kriege ich da eben auch nicht eine so genaue Zahl hin, Zelle 1 ist noch sehr genau auszulesen, bei Zelle 4 wirds dann doch schon wieder recht ungenau (4:1 Teiler).
Mir würde es da auch weniger um die Überwachung gehen, dafür reicht mir mein Wächter, viel mehr aber einfach ums Logging, wenn auch wohl kaum dauerhaft wirklich gebraucht. Da könnte man sich schon mal ein 16bit DAC zulegen für Messungen, welchen man ja dann wieder entfernen kann.
Also zumindest bei der Taranis wird das von der Funke berechnet, heisst er nimmt die ersten Daten (z.B. 310m) als 0Punkt und rechnet dann darauf die höhe, bei 320m Baro Daten wären es also dann 10m welche die Taranis anzeigt.
Edit: hab dich falsch verstanden, du meinst, das man abwartet bis die Daten einigermassen genau sind, korrekt? Und erst dann diese überträgt?
Ups stimmt, sind 10bit, jedoch auch nicht immer nicht wirklich genau
Selbst um eine Autobatterie zu messen kriege ich keine 0.01V hin (theoretisch 0.015V pro Bit, jedoch rauscht das Ding noch also wohl eher 0.05V genauhheit...) Für die Zellenüberwachung habe ich mal mit Spannugnsteilern was versucht, jedoch kriege ich da eben auch nicht eine so genaue Zahl hin, Zelle 1 ist noch sehr genau auszulesen, bei Zelle 4 wirds dann doch schon wieder recht ungenau (4:1 Teiler).
Mir würde es da auch weniger um die Überwachung gehen, dafür reicht mir mein Wächter, viel mehr aber einfach ums Logging, wenn auch wohl kaum dauerhaft wirklich gebraucht. Da könnte man sich schon mal ein 16bit DAC zulegen für Messungen, welchen man ja dann wieder entfernen kann.
Zuletzt bearbeitet:
OK, sicher mit den Baro Daten? Das kann natürlich sein das die Funke diese automatisch nullt.
Ich sehen bei mir bei APM und Hub eben nur das GPS ALt die absolute Höhe anzeigt, der Baro aber die relative, sprich beim Start steht der automatisch auf 0.
0.05V reicht doch aus, selbst 0,1V wäre noch ok. Meines Wissens überträgt FrSky die analogen Sensoren auch nur mit 8 bit -> 0,05V bei 1/4 Teiler (bis 13.2V)
Ich sehen bei mir bei APM und Hub eben nur das GPS ALt die absolute Höhe anzeigt, der Baro aber die relative, sprich beim Start steht der automatisch auf 0.
0.05V reicht doch aus, selbst 0,1V wäre noch ok. Meines Wissens überträgt FrSky die analogen Sensoren auch nur mit 8 bit -> 0,05V bei 1/4 Teiler (bis 13.2V)
Kann dir leider nicht genau sagen wie deien Funke das handelt, bei mir ist es so, dass sowohl GPS als Baro Relativ angezeigt werden. Heisst wenn ich den Copter einschalte wird die erste höhe als 0m angezeigt, wenn der GPS Fix dann noch schlecht ist, kann da schon mal ordentlich was falsches stehen nach ein paar Minuten. Ich Resete dann die Telemetrie einfach nochmals kurz.
Alternativ könnten wir natürlich einbauen, dass erst ab X Satteliten die Daten übertragen werden und dann ev. noch ein paar durchgänge warten. Nachteil daran ist aber, dass du gar keine Daten kriegst wenn das Wetter dann eben mal zu schlecht für GPS ist. Ansonsten hättest du wenigstens noch die Koordinaten die einigermassen stimmen.
naja, ich hatte das Problem, dass es einfach so stark gerauscht hat, das es eben schon mal zwischen 0.1 und 0.3V geschwankt hat. Habe mich da aber auch nicht weiter mit befasst, ev. war auch mein Teiler einfach zu gross
Alternativ könnten wir natürlich einbauen, dass erst ab X Satteliten die Daten übertragen werden und dann ev. noch ein paar durchgänge warten. Nachteil daran ist aber, dass du gar keine Daten kriegst wenn das Wetter dann eben mal zu schlecht für GPS ist. Ansonsten hättest du wenigstens noch die Koordinaten die einigermassen stimmen.
naja, ich hatte das Problem, dass es einfach so stark gerauscht hat, das es eben schon mal zwischen 0.1 und 0.3V geschwankt hat. Habe mich da aber auch nicht weiter mit befasst, ev. war auch mein Teiler einfach zu gross
OK, werde ich nochmal schauen mit der Höhe.
Ja, ich hatte das ja anfangs drin das nur bei 3D-Fix Sat Daten übertragen werden, Idee war auch das beim Absturz oder je nach Liegeposition keine neuen Daten mehr kommen wenn evtl nur noch sehr wenige Sats empfangen werden - die Daten wären dann wahrscheinlich "falscher" als die letzten 3D Fix Daten. Hier war aber noch ein kleiner Bug, da ich auf = "3"D Fix geprüft habe und somit beim "4" DGPS nix mehr kam.
Die Anzeige der Gesamtspannung über die Analogen Eingänge funktioniert bei mir recht gut mit 4:1 Teiler. Probleme gibts teilweise nur wenn an Stecker oder Akkukabel schon Spannungsverluste auftreten. Besser gehts am Balancer Stecker.
Ja, ich hatte das ja anfangs drin das nur bei 3D-Fix Sat Daten übertragen werden, Idee war auch das beim Absturz oder je nach Liegeposition keine neuen Daten mehr kommen wenn evtl nur noch sehr wenige Sats empfangen werden - die Daten wären dann wahrscheinlich "falscher" als die letzten 3D Fix Daten. Hier war aber noch ein kleiner Bug, da ich auf = "3"D Fix geprüft habe und somit beim "4" DGPS nix mehr kam.
Die Anzeige der Gesamtspannung über die Analogen Eingänge funktioniert bei mir recht gut mit 4:1 Teiler. Probleme gibts teilweise nur wenn an Stecker oder Akkukabel schon Spannungsverluste auftreten. Besser gehts am Balancer Stecker.
Die wird ja sowieso gesetzt, aargau hatte nur zusätzlich die Baro Höhe im FrSky Protokoll gesetzt, da hier eben kein Baro (Wert) vorhanden ist.
Kann ja jeder handhaben wie er will, Zeile ein oder auskommentieren im Sketch sollte drin sein für jeden der das nachbauen will....wobei, ist ja für an die Naza, nicht fürs Multiwii ;_)
Kann ja jeder handhaben wie er will, Zeile ein oder auskommentieren im Sketch sollte drin sein für jeden der das nachbauen will....wobei, ist ja für an die Naza, nicht fürs Multiwii ;_)
- Status
