OpenTX - Multiplex MLINK Konverter
- Ersteller Donaufisch66
- Erstellt am
Reinhardt Werbik
User
Hallo zusammen,
jetzt ist es soweit, die neue Version des Konverters ist fertig und läuft auf meinem Testsender.
Bzw. es gibt jetzt (zumindest vorübergehend) zwei Versionen:
- ganz ohne vordefinierte FrSky IDs
- mit FrSky IDs für einige wenige Parameter (Spannung, Strom, zwei Temperaturen und Vario)
Beiden Versionen gemeinsam ist die Zuordnung bestimmter MSB Adressen zu den Parametern im RVLQ Frame:
- A1 Spannung: Adresse 0 (normalerweise die Empfängerspannung)
- A2 Spannung: Adresse 2 (eine weitere Spannung bis 25,5 V)
- RSSI Wert: Adresse 1 (repräsentiert den M-Link LQI)
Außerdem werden die Telemetriewerte auf Wunsch von Chrissie jetzt auch während des Reichweitentests übertragen.
Beide Versionen der SW haben jetzt die Versionsnummer 1.00 bekommen, sind also jetzt sozusagen "offiziell".
Viel Spaß damit, gemeldete Fehler werden zeitnah behoben.
Außerdem denke ich, dass die Version mit den verbliebenen FrSky IDs irgendwann aussterben wird.
Aktuelle Anleitung folgt demnächst.
jetzt ist es soweit, die neue Version des Konverters ist fertig und läuft auf meinem Testsender.
Bzw. es gibt jetzt (zumindest vorübergehend) zwei Versionen:
- ganz ohne vordefinierte FrSky IDs
- mit FrSky IDs für einige wenige Parameter (Spannung, Strom, zwei Temperaturen und Vario)
Beiden Versionen gemeinsam ist die Zuordnung bestimmter MSB Adressen zu den Parametern im RVLQ Frame:
- A1 Spannung: Adresse 0 (normalerweise die Empfängerspannung)
- A2 Spannung: Adresse 2 (eine weitere Spannung bis 25,5 V)
- RSSI Wert: Adresse 1 (repräsentiert den M-Link LQI)
Außerdem werden die Telemetriewerte auf Wunsch von Chrissie jetzt auch während des Reichweitentests übertragen.
Beide Versionen der SW haben jetzt die Versionsnummer 1.00 bekommen, sind also jetzt sozusagen "offiziell".
Viel Spaß damit, gemeldete Fehler werden zeitnah behoben.
Außerdem denke ich, dass die Version mit den verbliebenen FrSky IDs irgendwann aussterben wird.
Aktuelle Anleitung folgt demnächst.
ChrissieShay
User
Hallo Reinhardt,
Ich habe jetzt mal kurz die Version ohne FrSky IDs ausprobiert. Soweit ich das gesehen habe funktioniert alles
. Beim Reichweitentest werden jetzt die Werte auch angezeigt, so daß
hier der LQI auch beobachtet werden kann.
Vielen Dank für die Erfüllung meines Sonderwunsches!!!
Ich habe jetzt mal kurz die Version ohne FrSky IDs ausprobiert. Soweit ich das gesehen habe funktioniert alles
. Beim Reichweitentest werden jetzt die Werte auch angezeigt, so daßhier der LQI auch beobachtet werden kann.
Vielen Dank für die Erfüllung meines Sonderwunsches
!!!
Reinhardt Werbik
User
Gern geschehen, es war ja eine sinnvolle Änderung.Vielen Dank für die Erfüllung meines Sonderwunsches
Übrigens war in Deiner Aufstellung der zu berücksichtigenden Werte des Status-Bytes ein kleiner Fehler.
Die Werte, die der Konverter jetzt als gültig erkennt, sind:
0x06 -> normaler Betrieb ohne Fast Response
0x04 -> normaler Betrieb mit Fast Response
0x46 -> Reichweitentest ohne Fast Response
0x44 -> Reichweitentest mit Fast Response
Diese Werte setzen jeweils einen gebundenen telemetriefähigen M-Link Empfänger voraus.
Ich hatte bisher nur das High Nibble auf 0 geprüft, jetzt werden explizit die obigen 4 Werte des ganzen Bytes berücksichtigt.
kalle123
User
Seh gerade, Tobi hat sich wieder gemeldet.
http://openrcforums.com/forum/viewtopic.php?f=96&t=7275&p=133032#p133032
Da ich nicht weiß, ob man als Gast das zip file laden kann, bitte PM an mich.
Vielleicht interessiert es ja.
Grüße KH
http://openrcforums.com/forum/viewtopic.php?f=96&t=7275&p=133032#p133032
Da ich nicht weiß, ob man als Gast das zip file laden kann, bitte PM an mich.
Vielleicht interessiert es ja.
Grüße KH
Hallo Kalle
Ich hab mich vor 4 Tagen da angemeldet, es scheint so, dass man nach einem Post (hab ich jetzt) den Zip laden kann.
Danke noch mal für deine Nachricht mit der Adresse.
Ansonsten starte ich morgen mal die neue Version.
Sigi
gruni
User
Hallo Jungs,
download geht auch ohne login.
Grüsse aus NZ, Gruni
Wird Zeit, dass Winter wird und ich den Lötkolben mit der kleinen Spitze wieder anschmeissen kann...
Reinhardt Werbik
User
Hallo zusammen,
ich wollte gerade die Anleitungen für die beiden Konverter-Versionen nochmal durchgehen und fertigstellen.
Dabei habe ich gemerkt, dass ich das schon vor zwei Wochen, vor meinem Wanderurlaub, gemacht habe.
Tja, man wird alt.
ich wollte gerade die Anleitungen für die beiden Konverter-Versionen nochmal durchgehen und fertigstellen.
Dabei habe ich gemerkt, dass ich das schon vor zwei Wochen, vor meinem Wanderurlaub, gemacht habe.
Tja, man wird alt.
kalle123
User
Nicht nur du, Reinhardt
Mal eine Frage an den Fachmann.
Häng hier gerade mit Sigi https://fpv-community.de/showthread.php?81744-ACT-Telemetrie-Konverter-a-la-Tobi&p=1012207&viewfull=1#post1012207
Dort diese Aussage
Kann es sein, Reinhardt, das sich da UNO, Nano und Pro mini unterscheiden? Als Laie und bei Betrachtung der Schaltpläne kann ich das nicht nachvollziehen.
Grüße KH und Danke!
Reinhardt Werbik
User
Hallo Kalle,
die drei Boards haben den gleichen Controller und damit alle eine HW Schnittstelle.
Beim MINI ist diese nackt, während der NANO und UNO eine USB Anbindung haben.
(Beim NANO über eine USB/UART Bridge, beim UNO über einen eigenen µC)
Ich habe keine Ahnung, wie die Arduino IDE und die darauf basierenden Projekte die serielle Schnittstelle einbinden.
Möglich, dass es da Unterschiede gibt, die durch die verschiedene USB Peripherie bedingt sind.
Ist aber reine Spekulation, da ich selbst die USB Anbindung nur zum Flashen über Bootloader verwende (beim UNO, NANOs habe ich nicht im Einsatz).
Ich mag die Arduino IDE nicht, da man nie weiss, was da genau passiert.
Ein voll transparenter C Source Code ist mir erheblich lieber, daher nutze ich eben die Atmel Umgebung zum Programmieren.
So nebenbei ist auch der resultierende Speicherplatzverbrauch wesentlich kleiner (z.B. ca. 2,7 kB beim Konverter ohne FrSky IDs).
Im M-Link Konverter sind übrigens aus triftigen Gründen beide UARTs in SW realisiert, der HW UART ist unbenutzt.
Mit der Arduino IDE wäre bei 16 MHz ein SW UART mit 115,2 kBd zum Einlesen der Daten vom M-Link Modul m.W. gar nicht möglich.
Mit direkter Programmierung in C kriege ich ihn (wahrscheinlich) sogar mit 8 MHz hin.
Ich kann Euch also nicht wirklich weiterhelfen, da ich wie gesagt die Arduino IDE nicht benutze.
kalle123
User
Danke für die Einschätzung Reinhardt.
... und Tobi geht über die IDE.
Gruß KH
PS. Hatte meine "blöde" Frage auch Tobi gestellt. Hier seine Antwort
http://openrcforums.com/forum/viewtopic.php?f=96&t=7275&start=150#p133093
... und Tobi geht über die IDE.
Gruß KH
PS. Hatte meine "blöde" Frage auch Tobi gestellt. Hier seine Antwort
http://openrcforums.com/forum/viewtopic.php?f=96&t=7275&start=150#p133093
Günter_W
User
Hallo zusammen,
Ich versuche schon seit Tagen ein Problem zu beheben, komme aber gerade nicht weiter. Ich habe auf dem Konverter die Version 2017-10-02 drauf, der Sender ist ein Mega2560, mit HFM-G1(?) Modul. Bin mir bei dessen Bezeichnung nicht ganz sicher. Daten kommen von einem openXsensor Vario. Das ist schon lange erprobt und funktioniert zusammen mit dem Souffleur wunderbar.
Was aber in der jetzigen Kombination nicht klappt ist, ich bekomme keine Höhenwerte in den Telemetrie Screen. Sinkrate, Empfängerspannung, alles andere ist i.o. ,nur Höhe fehlt....das Vario sendet sie, wie auch die max Höhe, sie scheint irgendwie entweder vom Konverter nicht erkannt zu werden, oder es gibt noch einen Trick sie bei openTX zu detektieren, ich komme nur nicht dahinter....
Es gab im Verlauf des Threads schon mal ein ähnliches Problem , ich finde aber die damalige Lösung nicht.
Grüße Günter
Ich versuche schon seit Tagen ein Problem zu beheben, komme aber gerade nicht weiter. Ich habe auf dem Konverter die Version 2017-10-02 drauf, der Sender ist ein Mega2560, mit HFM-G1(?) Modul. Bin mir bei dessen Bezeichnung nicht ganz sicher. Daten kommen von einem openXsensor Vario. Das ist schon lange erprobt und funktioniert zusammen mit dem Souffleur wunderbar.
Was aber in der jetzigen Kombination nicht klappt ist, ich bekomme keine Höhenwerte in den Telemetrie Screen. Sinkrate, Empfängerspannung, alles andere ist i.o. ,nur Höhe fehlt....das Vario sendet sie, wie auch die max Höhe, sie scheint irgendwie entweder vom Konverter nicht erkannt zu werden, oder es gibt noch einen Trick sie bei openTX zu detektieren, ich komme nur nicht dahinter....
Es gab im Verlauf des Threads schon mal ein ähnliches Problem , ich finde aber die damalige Lösung nicht.
Grüße Günter
Reinhardt Werbik
User
Hallo Günter,
die Höhe wird seit einiger Zeit nicht mehr mit der vordefinierten FrSky ID übertragen,
da diese das Senden von zwei Daten Frames für ganzzahligen Anteil und Nachkommastellen erfordert.
Da die entsprechende MSB Werteklasse eine Auflösung von 1 m hat, würde mit dem FrSky Format immer ein
Daten Frame für die Nachkommastellen ohne Informationsgehalt übertragen werden.
Im Zuge der Latenzoptimierung zur Unterstützun einer Prioritätsadresse auf dem MSB habe ich daher die FrSky ID für die Höhe eliminiert.
Ich kann es mir jetzt schlichtweg nicht mehr leisten, Daten ohne Informationsgehalt an OpenTX zu schicken.
(Die 9600 Bd lassen grüßen.)
Die Höhe wird jetzt als "zusätzlicher" Parameter mit einer ID übertragen, die die MSB Adresse reflektiert (gemäß Tabelle in der Anleitung).
Schau doch mal, ob bei Dir ein Parameter auftaucht, dessen Low Nibble die MSB Adresse der Höhe repräsentiert.
Dieser Parameter wäre dann direkt die Höhe in m, den Namen kannst Du dann z.B. in Alt o.ä. andern.
Es gibt übrigens mittlerweile die Version 1.00 des Konverters in zwei Varianten.
Eine davon verzichtet ganz auf die vordefinierten FrSky IDs.
Falls Du die Höhe trotzdem nicht findest, dann stell doch mal eine Liste aller belegten MSB Adressen mit Werteklasse ein.
die Höhe wird seit einiger Zeit nicht mehr mit der vordefinierten FrSky ID übertragen,
da diese das Senden von zwei Daten Frames für ganzzahligen Anteil und Nachkommastellen erfordert.
Da die entsprechende MSB Werteklasse eine Auflösung von 1 m hat, würde mit dem FrSky Format immer ein
Daten Frame für die Nachkommastellen ohne Informationsgehalt übertragen werden.
Im Zuge der Latenzoptimierung zur Unterstützun einer Prioritätsadresse auf dem MSB habe ich daher die FrSky ID für die Höhe eliminiert.
Ich kann es mir jetzt schlichtweg nicht mehr leisten, Daten ohne Informationsgehalt an OpenTX zu schicken.
(Die 9600 Bd lassen grüßen.
)Die Höhe wird jetzt als "zusätzlicher" Parameter mit einer ID übertragen, die die MSB Adresse reflektiert (gemäß Tabelle in der Anleitung).
Schau doch mal, ob bei Dir ein Parameter auftaucht, dessen Low Nibble die MSB Adresse der Höhe repräsentiert.
Dieser Parameter wäre dann direkt die Höhe in m, den Namen kannst Du dann z.B. in Alt o.ä. andern.
Es gibt übrigens mittlerweile die Version 1.00 des Konverters in zwei Varianten.
Eine davon verzichtet ganz auf die vordefinierten FrSky IDs.
Falls Du die Höhe trotzdem nicht findest, dann stell doch mal eine Liste aller belegten MSB Adressen mit Werteklasse ein.
Donaufisch66
User
Hallo,
die Adressen der Höhe MUSS in ALT oder Höhe umbenannt werden, sonst erkennt OpenTX Höhe nicht und du kannst im Telemetriemenü ALT für Höhe nicht auswählen. Selbiges gilt für VARIO in der Konverterversion ohne vordefinierte Frksy Adressen.
die Adressen der Höhe MUSS in ALT oder Höhe umbenannt werden, sonst erkennt OpenTX Höhe nicht und du kannst im Telemetriemenü ALT für Höhe nicht auswählen. Selbiges gilt für VARIO in der Konverterversion ohne vordefinierte Frksy Adressen.
Reinhardt Werbik
User
Hallo Roland,
ich denke mal, wenn Du beim Konverter ohne vordefinierte FrSky IDs den Default-Namen beibehältst (z.B. 0036 wenn die Höhe auf Adresse 6 liegt),
wird der Parameter unter eben diesem Default-Namen gefunden.
Definitiv kann das Umbenennen in "Höhe" keine Auswirkung haben, das ist für OpenTX genauso ein fremdes Wort wie der Default-Name.
Es würde micht schon sehr wundern, wenn es anders wäre.
Intern werden die Telemetrie-Parameter nicht über den Namen angesprochen,
sondern über die ID oder die Position in der Liste (da bin ich mir jetzt nicht ganz sicher).
Donaufisch66
User
Hallo Reinhardt,
Ich habe den Sender nicht bei mir.
Ich kann mich erinnern, dass ich mit deinem Konverter anfangs in openTx keine Quelle für Höhe auf Seite13 hätte.
Ich glaube mich zu erinnern, dass ich den NAMEN der entsprechende ID der Höhe auf "Alt" oder eben "Höhe" ändern musste.
Oder war es die Einheit?
Ich bin mir sicher dass OpenTX auf Seite13 - Telemetrie- in den Abschnitten Höhe und Vario NUR den Namen oder die Einheit prüft.
Ich hatte damals nämlich auch das Problem dass ich keine Höhe hatte bis ich den NAME und Einheit umgestellt hatte.
Sorry! Es könnte auch die Einheit gewesen sein! Entweder Name auf Alt oder Einheit auf "m" stellen.
Jetzt glaube ich fast dass es die Einheit war!
Einheiten die nicht "m" sind, werden nicht im Höhe Auswahl Menü angezeigt!
LG Roland
Ich habe den Sender nicht bei mir.
Ich kann mich erinnern, dass ich mit deinem Konverter anfangs in openTx keine Quelle für Höhe auf Seite13 hätte.
Ich glaube mich zu erinnern, dass ich den NAMEN der entsprechende ID der Höhe auf "Alt" oder eben "Höhe" ändern musste.
Oder war es die Einheit?
Ich bin mir sicher dass OpenTX auf Seite13 - Telemetrie- in den Abschnitten Höhe und Vario NUR den Namen oder die Einheit prüft.
Ich hatte damals nämlich auch das Problem dass ich keine Höhe hatte bis ich den NAME und Einheit umgestellt hatte.
Sorry! Es könnte auch die Einheit gewesen sein! Entweder Name auf Alt oder Einheit auf "m" stellen.
Jetzt glaube ich fast dass es die Einheit war!
Einheiten die nicht "m" sind, werden nicht im Höhe Auswahl Menü angezeigt!
LG Roland
Reinhardt Werbik
User
Hallo Roland,
der Name ist es definitiv nicht.
Ich benenne alle Telemetrie-Parameter grundsätzlich um.
Was soll ich mit Curr, VFAS, etc., bei mir heißt das I, U, Urc, etc.
Und alle diese umbenannten Parameter werden problemlos gefunden.
Wenn es nur um die Anzeige in einem Telemetrie-Screen geht, spielt auch die Einheit keine Rolle.
Lediglich bei der Auswahl der Quelle für die Höhenanzeige wird OpenTx vermutlich die Einheit prüfen.
Donaufisch66
User
Vielleicht habe ich mich missverständlich ausgedrückt.
Es gibt doch auf der Telemetrie Seite unter den erkannten Sensoren, für Höhe und Vario eigene Bereiche in denen diverse Einstellungen vorgenommen werden können.
Dort kann man auswählen welche Quelle für Höhe und Vario verwendet wird.
Wenn der empfangene Sensorwert für Höhe nicht richtig eingestellt wird, erscheint er nicht in dem Auswahlmenü für "Höhe", detto Vario.
Man kann also nur Quellen angeben, die "Höhe" sein könnten!
Andere Werte oder Werte ohne Einheit erscheinen gar nicht in diesem Auswahlmenü!
Es gibt doch auf der Telemetrie Seite unter den erkannten Sensoren, für Höhe und Vario eigene Bereiche in denen diverse Einstellungen vorgenommen werden können.
Dort kann man auswählen welche Quelle für Höhe und Vario verwendet wird.
Wenn der empfangene Sensorwert für Höhe nicht richtig eingestellt wird, erscheint er nicht in dem Auswahlmenü für "Höhe", detto Vario.
Man kann also nur Quellen angeben, die "Höhe" sein könnten!
Andere Werte oder Werte ohne Einheit erscheinen gar nicht in diesem Auswahlmenü!
Ähnliche Themen
