Reinhardt Werbik
User
No Data bedeutet, dass OpenTX keine gültigen Telemetriedaten bekommt.
Es ist für den Konverter kein Problem, wenn auf Adresse 1 kein LQI anliegt.
OpenTX - Multiplex MLINK Konverter
- Ersteller Donaufisch66
- Erstellt am
Es ist für den Konverter kein Problem, wenn auf Adresse 1 kein LQI anliegt.
Reinhardt Werbik
User
Danke für das Feedback.
Ich würde für das Vario die Prioritätsadresse aktivieren, der Konverter unterstützt das.
(hat aber nichts mit Deinem Problem zu tun)
Ich werde während des Winters über ein Update nachdenken, um die feste Adress-Zuordnung für den LQI rauszunehmen.
Momentan muss dieser auf Adresse 1 liegen, damit er als RSSI in den RVLQ Frame gepackt wird.
(Ansonsten taucht er als "normaler" Parameter auf.)
Da der LQI eine eigene Werteklasse hat, ist diese Einschränkung eigentlich nicht nötig, da der Parameter an der Werteklasse erkannt werden kann.
Man könnte also einfach den LQI Wert mit der niedrigsten MSB Adresse nehmen und als RSSI in den RVLQ Frame packen.
(Mehr als einen LQI wird es wohl ohnehin nicht geben.)
Mal schauen, ob/wann ich Zeit dazu finde.
Trotzdem solltest du auch berücksichtigen, dass mehrere Werte mit der lqi Klasse ankommen könnten: Bei meinen Eigenbau-Sensoren hab ich die Klasse ganz gerne für Diverses genutzt, wofür es keine fertigen Einheiten gab 
Nochmal zurück zu NoData: wie definiert Opentx "keine gültigen Telemetrie Daten? Wenn also z.b. vom xjt über S.port keine Daten kommen? Ist das nicht equivalent zu Rssi = 0?
Nochmal zurück zu NoData: wie definiert Opentx "keine gültigen Telemetrie Daten? Wenn also z.b. vom xjt über S.port keine Daten kommen? Ist das nicht equivalent zu Rssi = 0?
Reinhardt Werbik
User
Der Konverter verarbeitet alle LQI Werte, die am MSB anliegen.Trotzdem solltest du auch berücksichtigen, dass mehrere Werte mit der lqi Klasse ankommen könnten: Bei meinen Eigenbau-Sensoren hab ich die Klasse ganz gerne für Diverses genutzt, wofür es keine fertigen Einheiten gab
Nochmal zurück zu NoData: wie definiert Opentx "keine gültigen Telemetrie Daten? Wenn also z.b. vom xjt über S.port keine Daten kommen? Ist das nicht equivalent zu Rssi = 0?
Da er aber nur einen als RSSI im RVLQ Frame übertragen kann, nimmt er derzeit den an Adresse 1 (falls dort einer ist).
Alle anderen LQI Werte kommen als normale Parameter ebenfalls in OpenTX an.
Warum sollte RSSI = 0 äquivalent sein zu dem Fall, dass gar keine Telemetriedaten ankommen?
Der Konverter benutzt zur Übertragung das D-Protokoll, dh. No Data bedeutet, dass OpenTX keinen RVLQ Frame bekommt.
K_A
User
Konverter funktioniert einwandfrei
Konverter funktioniert einwandfrei
Nachdem wir den Fehler fanden, folgten die Testflüge. Es gab noch einiges zu verbessern und auszutesten. Ich probierte die Adressen 0 und 1 im MPX RX auf "aus" zu stellen und anderes aus. Fazit: Nur mit den MPX Werks- (Default) Einstellungen funktioniert der Konverter einwandfrei. @Reinhardt: Du musst meiner Meinung nach nichts mehr ändern. Ich stellte alles um und werde dabei bleiben. Unten noch die Tipps und Einstellungen aus meinen Flugversuchen.
Nachdem nun alles funktioniert stellt sich die Frage:
Lohnt sich so ein Umbau?
Ja, auf jeden Fall. Als ich vor einem Jahr meine erste open-TX fähige Fernsteuerung kaufte, war meine Idee folgende:
- Wie kann ich meine bewährten und sehr sicheren Multiplex HF Module und Empfänger weiter verwenden?
- Open-TX war für mich ein muss und es gab und gibt kein zurück mehr.
- Das JR PCM 10X/9Xll Sendergehäuse (baugleich Graupner MX-22/24 und Frsky X9D) ist für mich bezüglich Haptik immer noch das Mass aller Dinge (ich wollte die 10S kaufen, entschied mich jedoch für die besser in der Hand liegende X9D plus).
Dank des Konverters kann ich nun diese Kombination nutzen, auf 4 Seiten je 9 Telemetrie Werte darstellen und das monochrome Display bei Sonnenlicht mit Sonnenbrille sehr gut lesen (die Farbdisplays sind da viel schlechter). Die Sprachausgabe der Open-TX Software ersetzt mir den bewährten MPX Souffleur. Alles in allem eine gelungene Lösung.
Vielen Dank an alle, welche zu dem Konverter beigetragen hatten.
Konverter funktioniert einwandfrei
Nachdem wir den Fehler fanden, folgten die Testflüge. Es gab noch einiges zu verbessern und auszutesten. Ich probierte die Adressen 0 und 1 im MPX RX auf "aus" zu stellen und anderes aus. Fazit: Nur mit den MPX Werks- (Default) Einstellungen funktioniert der Konverter einwandfrei. @Reinhardt: Du musst meiner Meinung nach nichts mehr ändern. Ich stellte alles um und werde dabei bleiben. Unten noch die Tipps und Einstellungen aus meinen Flugversuchen.
Nachdem nun alles funktioniert stellt sich die Frage:
Lohnt sich so ein Umbau?
Ja, auf jeden Fall. Als ich vor einem Jahr meine erste open-TX fähige Fernsteuerung kaufte, war meine Idee folgende:
- Wie kann ich meine bewährten und sehr sicheren Multiplex HF Module und Empfänger weiter verwenden?
- Open-TX war für mich ein muss und es gab und gibt kein zurück mehr.
- Das JR PCM 10X/9Xll Sendergehäuse (baugleich Graupner MX-22/24 und Frsky X9D) ist für mich bezüglich Haptik immer noch das Mass aller Dinge (ich wollte die 10S kaufen, entschied mich jedoch für die besser in der Hand liegende X9D plus).
Dank des Konverters kann ich nun diese Kombination nutzen, auf 4 Seiten je 9 Telemetrie Werte darstellen und das monochrome Display bei Sonnenlicht mit Sonnenbrille sehr gut lesen (die Farbdisplays sind da viel schlechter). Die Sprachausgabe der Open-TX Software ersetzt mir den bewährten MPX Souffleur. Alles in allem eine gelungene Lösung.
Vielen Dank an alle, welche zu dem Konverter beigetragen hatten.
Reinhardt Werbik
User
Danke für das ausführliche Feedback.
Ich werde über den Winter die beiden jetzigen Konverter-Versionen zu einer zusammenfahren.
Im Zuge dieses Updates werde ich dann auch die feste Adresszuordnung für den LQI rausnehmen.
Diese ist schlicht nicht nötig und wurde von mir mehr aus Bequemlichkeit eingebaut.
Der Konverter wird dann einfach den LQI Wert mit der niedrigsten MSB Adresse als RSSI ausgeben.
Was die Verwendung der FrSky IDs angeht, habe ich lange überlegt und werde letzlich folgendes machen.
Die vordefinierten IDs für die beiden Temperaturen werden nicht implementiert.
Die Temperaturwerte müssen also zukünftig immer so wie bei der jetzigen Version ohne FrSky IDs konfiguriert werden.
Da wegen der unterschiedlichen Auflösungen am MSB und im D-Protokoll eine Änderung der OpenTX Konfiguration
ohnehin erforderlich ist, stellt das keinen Nachteil dar.
Für Spannung (VFAS), Strom (Curr) und Vertikalgeschwindigkeit (VSpd) wird bei der neuen Version jeweils für die
niedrigste gefundene MSB Adresse mit passender Werteklasse die vordefinierte FrSky ID verwendet.
Da in diesen Fällen die OpenTX Konfiguration des Sensorwertes passt, macht das Sinn.
Außerdem werden dann zusammen mit den Parametern des RVLQ Frames (A1, A2 und RSSI/LQI) die wichtigsten Parameter
schon bei der Sensorsuche mit leicht erkennbaren Namen gefunden, was der Übersichtlichkeit zugute kommt.
Ich muss dann in Zukunft nur noch eine Version pflegen, und die Umstellung ist nur mit einigen kleineren Konfigurationsänderungen in OpenTx verbunden.
Watch this space...
Ich werde über den Winter die beiden jetzigen Konverter-Versionen zu einer zusammenfahren.
Im Zuge dieses Updates werde ich dann auch die feste Adresszuordnung für den LQI rausnehmen.
Diese ist schlicht nicht nötig und wurde von mir mehr aus Bequemlichkeit eingebaut.
Der Konverter wird dann einfach den LQI Wert mit der niedrigsten MSB Adresse als RSSI ausgeben.
Was die Verwendung der FrSky IDs angeht, habe ich lange überlegt und werde letzlich folgendes machen.
Die vordefinierten IDs für die beiden Temperaturen werden nicht implementiert.
Die Temperaturwerte müssen also zukünftig immer so wie bei der jetzigen Version ohne FrSky IDs konfiguriert werden.
Da wegen der unterschiedlichen Auflösungen am MSB und im D-Protokoll eine Änderung der OpenTX Konfiguration
ohnehin erforderlich ist, stellt das keinen Nachteil dar.
Für Spannung (VFAS), Strom (Curr) und Vertikalgeschwindigkeit (VSpd) wird bei der neuen Version jeweils für die
niedrigste gefundene MSB Adresse mit passender Werteklasse die vordefinierte FrSky ID verwendet.
Da in diesen Fällen die OpenTX Konfiguration des Sensorwertes passt, macht das Sinn.
Außerdem werden dann zusammen mit den Parametern des RVLQ Frames (A1, A2 und RSSI/LQI) die wichtigsten Parameter
schon bei der Sensorsuche mit leicht erkennbaren Namen gefunden, was der Übersichtlichkeit zugute kommt.
Ich muss dann in Zukunft nur noch eine Version pflegen, und die Umstellung ist nur mit einigen kleineren Konfigurationsänderungen in OpenTx verbunden.
Watch this space...
kalle123
User
Wird gemacht, Reinhardt!
LG - KH
Zur Zeit beschäftigt mit UEFI, AMD Ryzen und ...... WIN 10
Wolfgang Wallner
User
Ein neuer Interessent für den MLINK Konverter
Ein neuer Interessent für den MLINK Konverter
Hallo Reinhardt
Ich habe über den Jahreswechsel mir die Zeit genommen und den kompletten Thread gelesen. Vorab muss ich dir für deinen Einsatz bei dem Projekt meine Hochachtung aussprechen.
Als langjähriger Modellflieger, mit Hauptanteil Segelflug habe ich bis auf Jeti alle gängigen Hersteller von 2,4 Ghz Anlagen selbst verwendet. Schlussendlich habe ich Graupner Hott und MPX in Verwendung. Durch die neue kleine X-Lite von FrSky bin ich jetzt auch bei Open-TX gelandet. Der kleine Sender ist derzeit Einzigartig am Markt wenn man Möglichkeiten in Verbindung mit 380 g Gewicht betrachtet. Das Missing-Link für meine kleinen Nurflügel und Segler im Rucksack zum Wandern. Nachdem ich die Vorteile von Open-TX dabei zu Schätzen gelernt habe möchte mir zusätzlich eine HORUS X12S zulegen. Sie soll meine PRofi-TX von MPX ersetzen. Dazu habe ich noch ein HF-MG3 Modul neu erstanden. Was fehlt? Natürlich der Konverter für die Telemetrie für die HORUS. Die Anzahl meiner MPX Empfänger und dazu passende Sensoren von MPX und SM-Modellbau verlangt einfach nach diesem Teil. Leider habe ich gelesen, dass du die Variante 3,3V nicht mehr weiter verfolgen willst. Ich sehe die Unterbringung im HF-MG3 Modul und der Versorgung daraus als großen Vorteil. Verwendet man MPX wird das HF Modul eingesetzt und alles ist erledigt. Verwendet man FrSky spart man ohne dem HF-Modul Gewicht und eine abstehende Antenne. Die X12S ist schwer genug. Ist die Umsetzung mit dem 3,3V wirklich gestorben? Wirst du das SPort Protokoll für die Überarbeitung des Konverters integrieren? Fakt ist, wenn ich die X12S kaufe und das wird vielleicht schon nächste Woche sein, dann brauche ich auch einen Konverter. Löten am HF Modul ist für mich kein Problem, das Flashen mit ISP ist ein anderes Thema. Habe bis jetzt mit Arduino und Co keine Erfahrung dafür mit Analogtechnik umso mehr, das Alter lässt grüßen!
Könnte ich bei dir einen programmierten Arduino eventuell erhalten?
Liebe Grüße aus Österreich
Wolfgang
Ein neuer Interessent für den MLINK Konverter
Danke für das ausführliche Feedback.
Ich werde über den Winter die beiden jetzigen Konverter-Versionen zu einer zusammenfahren.
Im Zuge dieses Updates werde ich dann auch die feste Adresszuordnung für den LQI rausnehmen.
Diese ist schlicht nicht nötig und wurde von mir mehr aus Bequemlichkeit eingebaut.
Der Konverter wird dann einfach den LQI Wert mit der niedrigsten MSB Adresse als RSSI ausgeben.
Was die Verwendung der FrSky IDs angeht, habe ich lange überlegt und werde letzlich folgendes machen.
Die vordefinierten IDs für die beiden Temperaturen werden nicht implementiert.
Die Temperaturwerte müssen also zukünftig immer so wie bei der jetzigen Version ohne FrSky IDs konfiguriert werden.
Da wegen der unterschiedlichen Auflösungen am MSB und im D-Protokoll eine Änderung der OpenTX Konfiguration
ohnehin erforderlich ist, stellt das keinen Nachteil dar.
Für Spannung (VFAS), Strom (Curr) und Vertikalgeschwindigkeit (VSpd) wird bei der neuen Version jeweils für die
niedrigste gefundene MSB Adresse mit passender Werteklasse die vordefinierte FrSky ID verwendet.
Da in diesen Fällen die OpenTX Konfiguration des Sensorwertes passt, macht das Sinn.
Außerdem werden dann zusammen mit den Parametern des RVLQ Frames (A1, A2 und RSSI/LQI) die wichtigsten Parameter
schon bei der Sensorsuche mit leicht erkennbaren Namen gefunden, was der Übersichtlichkeit zugute kommt.
Ich muss dann in Zukunft nur noch eine Version pflegen, und die Umstellung ist nur mit einigen kleineren Konfigurationsänderungen in OpenTx verbunden.
Watch this space...
Hallo Reinhardt
Ich habe über den Jahreswechsel mir die Zeit genommen und den kompletten Thread gelesen. Vorab muss ich dir für deinen Einsatz bei dem Projekt meine Hochachtung aussprechen.
Als langjähriger Modellflieger, mit Hauptanteil Segelflug habe ich bis auf Jeti alle gängigen Hersteller von 2,4 Ghz Anlagen selbst verwendet. Schlussendlich habe ich Graupner Hott und MPX in Verwendung. Durch die neue kleine X-Lite von FrSky bin ich jetzt auch bei Open-TX gelandet. Der kleine Sender ist derzeit Einzigartig am Markt wenn man Möglichkeiten in Verbindung mit 380 g Gewicht betrachtet. Das Missing-Link für meine kleinen Nurflügel und Segler im Rucksack zum Wandern. Nachdem ich die Vorteile von Open-TX dabei zu Schätzen gelernt habe möchte mir zusätzlich eine HORUS X12S zulegen. Sie soll meine PRofi-TX von MPX ersetzen. Dazu habe ich noch ein HF-MG3 Modul neu erstanden. Was fehlt? Natürlich der Konverter für die Telemetrie für die HORUS. Die Anzahl meiner MPX Empfänger und dazu passende Sensoren von MPX und SM-Modellbau verlangt einfach nach diesem Teil. Leider habe ich gelesen, dass du die Variante 3,3V nicht mehr weiter verfolgen willst. Ich sehe die Unterbringung im HF-MG3 Modul und der Versorgung daraus als großen Vorteil. Verwendet man MPX wird das HF Modul eingesetzt und alles ist erledigt. Verwendet man FrSky spart man ohne dem HF-Modul Gewicht und eine abstehende Antenne. Die X12S ist schwer genug. Ist die Umsetzung mit dem 3,3V wirklich gestorben? Wirst du das SPort Protokoll für die Überarbeitung des Konverters integrieren? Fakt ist, wenn ich die X12S kaufe und das wird vielleicht schon nächste Woche sein, dann brauche ich auch einen Konverter. Löten am HF Modul ist für mich kein Problem, das Flashen mit ISP ist ein anderes Thema. Habe bis jetzt mit Arduino und Co keine Erfahrung dafür mit Analogtechnik umso mehr, das Alter lässt grüßen!
Könnte ich bei dir einen programmierten Arduino eventuell erhalten?
Liebe Grüße aus Österreich
Wolfgang
Reinhardt Werbik
User
Hallo Wolfgang,
erst mal meine Hochachtung, dass Du den ganzen Thread gelesen hast.
Was die 3,3 V Variante angeht, dafür habe ich in der Tat gar keine Zeit mehr.
Und es ist eben gar nicht sicher, ob es letztendlich überhaupt möglich ist, mit 8 MHz Taktfrequenz hinzukommen.
Man kann aber auch problemlos die Standard-Variante des Konverters im HFMG3 Modul unterbringen,
siehe hier
Mit der 3,3 V Variante hätte man halt nur eine einzige Lötverbindung zum Modul gebraucht.
Aber wenn man eh schon lötet, kann man es genauso gut so machen wie im verlinkten Beitrag.
Was das Umstellen auf S-Port angeht, das würde keinen wirklichen Vorteil bringen, solange OpenTX das D-Protokoll noch unterstützt.
Wenn die Jungs das aber mal rausschmeißen sollten, muss ich allerdings ernsthaft darüber nachdenken.
Ich arbeite mich gerade in das S-Port Protokoll ein.
Wenn alle Stricke reißen, kannst Du sicher von mir ein programmiertes Board erhalten.
Je nachdem wo in Österreich Du wohnst, ist es aber vielleicht einfacher (und sicher billiger was den Versand angeht),
wenn Du Dich mit Roland aus Wien kurzschließt.
Roland ist einer der ersten Stunde, was den Konverter angeht.
Er ist ein fleißiger Tester aller Versionen gewesen und ist fit, was das Flashen angeht.
Da Roland hier immer fleißig mitliest, wird er sich sicher zu meinem Vorschlag äußern.
erst mal meine Hochachtung, dass Du den ganzen Thread gelesen hast.
Was die 3,3 V Variante angeht, dafür habe ich in der Tat gar keine Zeit mehr.
Und es ist eben gar nicht sicher, ob es letztendlich überhaupt möglich ist, mit 8 MHz Taktfrequenz hinzukommen.
Man kann aber auch problemlos die Standard-Variante des Konverters im HFMG3 Modul unterbringen,
siehe hier
Mit der 3,3 V Variante hätte man halt nur eine einzige Lötverbindung zum Modul gebraucht.
Aber wenn man eh schon lötet, kann man es genauso gut so machen wie im verlinkten Beitrag.
Was das Umstellen auf S-Port angeht, das würde keinen wirklichen Vorteil bringen, solange OpenTX das D-Protokoll noch unterstützt.
Wenn die Jungs das aber mal rausschmeißen sollten, muss ich allerdings ernsthaft darüber nachdenken.
Ich arbeite mich gerade in das S-Port Protokoll ein.
Wenn alle Stricke reißen, kannst Du sicher von mir ein programmiertes Board erhalten.
Je nachdem wo in Österreich Du wohnst, ist es aber vielleicht einfacher (und sicher billiger was den Versand angeht),
wenn Du Dich mit Roland aus Wien kurzschließt.
Roland ist einer der ersten Stunde, was den Konverter angeht.
Er ist ein fleißiger Tester aller Versionen gewesen und ist fit, was das Flashen angeht.
Da Roland hier immer fleißig mitliest, wird er sich sicher zu meinem Vorschlag äußern.
Reinhardt Werbik
User
Hallo zusammen,
ich habe jetzt den Code für die neue Konverter-Version mit drei vordefinierten IDs (VFAS, Curr, VSpd) und freier Adresswahl für den LQI soweit fertig.
Mal schauen, wann ich Zeit habe, ihn zu testen und dann hier einzustellen.
Das ist absolut nicht eilig, da dieses Update nichts wichtiges beinhaltet, es dient mehr dazu, mir das Leben zu erleichtern, da es dann nur noch eine Version gibt.
Bei der Gelegenheit habe ich im Atmel Studio gesehen, dass ich seinerzeit den Code für die 8 MHz Version (ATtiny 841 Board) schon fertiggestellt hatte.
Ich habe ihn dann aber nicht mehr getestet und natürlich auch nicht hier eingestellt.
Zur Erinnerung, es geht um dieses schnucklige Board.
Ich habe daher meine Pläne geändert.
Ich werde den "umgekehrten" Konverter, von dem ich weiter vorne gesprochen habe, erst mal zurückstellen.
Er war mehr als Lückenfüller gedacht, um nicht ganz aus der Übung zu kommen mit der C-Programmierung.
(Man glaubt gar nicht, wie schnell man da wieder draußen ist, wenn man eine Zeit lang nichts macht.)
Einen wirklich großen Nutzen hätte dieser Konverter ohnehin nicht gehabt.
Stattdessen werde ich doch die Portierung des "normalen" Konverters auf das ATtiny 841 Board zu Ende bringen.
Es wäre einfach auch schade, wenn ich den Code umsonst umgeschrieben hätte.
Allerdings ist immer noch offen, ob der SW UART mit 115,2 kBaud bei 8 MHz Taktfrequenz zu realisieren ist.
Es kann eine Weile dauern, denn ab Montag muss ich wieder arbeiten, und bald schon steht der Skiurlaub ins Haus.
Und auch die Standardversion mit Arduino Mini Pro lässt sich ja im HFMG3 Modul unterbringen, wie weiter vorne gezeigt.
Ich werde berichten.
ich habe jetzt den Code für die neue Konverter-Version mit drei vordefinierten IDs (VFAS, Curr, VSpd) und freier Adresswahl für den LQI soweit fertig.
Mal schauen, wann ich Zeit habe, ihn zu testen und dann hier einzustellen.
Das ist absolut nicht eilig, da dieses Update nichts wichtiges beinhaltet, es dient mehr dazu, mir das Leben zu erleichtern, da es dann nur noch eine Version gibt.
Bei der Gelegenheit habe ich im Atmel Studio gesehen, dass ich seinerzeit den Code für die 8 MHz Version (ATtiny 841 Board) schon fertiggestellt hatte.
Ich habe ihn dann aber nicht mehr getestet und natürlich auch nicht hier eingestellt.
Zur Erinnerung, es geht um dieses schnucklige Board.
Ich habe daher meine Pläne geändert.
Ich werde den "umgekehrten" Konverter, von dem ich weiter vorne gesprochen habe, erst mal zurückstellen.
Er war mehr als Lückenfüller gedacht, um nicht ganz aus der Übung zu kommen mit der C-Programmierung.
(Man glaubt gar nicht, wie schnell man da wieder draußen ist, wenn man eine Zeit lang nichts macht.)
Einen wirklich großen Nutzen hätte dieser Konverter ohnehin nicht gehabt.
Stattdessen werde ich doch die Portierung des "normalen" Konverters auf das ATtiny 841 Board zu Ende bringen.
Es wäre einfach auch schade, wenn ich den Code umsonst umgeschrieben hätte.
Allerdings ist immer noch offen, ob der SW UART mit 115,2 kBaud bei 8 MHz Taktfrequenz zu realisieren ist.
Es kann eine Weile dauern, denn ab Montag muss ich wieder arbeiten, und bald schon steht der Skiurlaub ins Haus.
Und auch die Standardversion mit Arduino Mini Pro lässt sich ja im HFMG3 Modul unterbringen, wie weiter vorne gezeigt.
Ich werde berichten.
Wolfgang Wallner
User
Hallo Reinhardt und Kalle
Danke für eure Antworten und Hilfestellung mit den Link und Seitenangabe. Reinhardt ich habe soeben gelesen, dass du doch den 8 MHz mit dem neuen Board umsetzen willst. Dann werde ich mit der Umsetzung des Konverters noch warten, vielleicht geht es ja mit dem kleinen Board und ich kann dann für dich mit meinen Sensoren in den Modellen gleich mal testen wie es in der Praxis funktioniert! Bedeutet es, dass dieses Board mit den 3,3V Versorgung auskommt?
Ich habe gerade meine HORUS bei Engel bestellt. Es ist jedoch die HORUS X10S geworden, nach einem Gespräch mit Andreas Engel sind für mich das wesentlich geringere Gewicht, Li-ion Akku und bessere HF-Übertragung durch die zwei Antennen ausschlaggebend und ich lebe mit dem Display unterhalb der Knüppel. Es ist einfach der aktuellere Sender von der Hardware.
Bin schon neugierig auf die nächsten Infos von Reinhardt
LG Wolfgang
Danke für eure Antworten und Hilfestellung mit den Link und Seitenangabe. Reinhardt ich habe soeben gelesen, dass du doch den 8 MHz mit dem neuen Board umsetzen willst. Dann werde ich mit der Umsetzung des Konverters noch warten, vielleicht geht es ja mit dem kleinen Board und ich kann dann für dich mit meinen Sensoren in den Modellen gleich mal testen wie es in der Praxis funktioniert! Bedeutet es, dass dieses Board mit den 3,3V Versorgung auskommt?
Ich habe gerade meine HORUS bei Engel bestellt. Es ist jedoch die HORUS X10S geworden, nach einem Gespräch mit Andreas Engel sind für mich das wesentlich geringere Gewicht, Li-ion Akku und bessere HF-Übertragung durch die zwei Antennen ausschlaggebend und ich lebe mit dem Display unterhalb der Knüppel. Es ist einfach der aktuellere Sender von der Hardware.
Bin schon neugierig auf die nächsten Infos von Reinhardt
LG Wolfgang
K_A
User
M-Link Adressen Null und Eins, Zusatz zu Beitrag 16.12.2018
M-Link Adressen Null und Eins, Zusatz zu Beitrag 16.12.2018
Ich testete den RX-7-DR Wingstabi Empfänger von MPX. Dabei kann man nur noch die Adresse "Null" im Launcher fest vergeben. Das ist kein Problem, alles funktionierte einwandfrei, das heisst kein "no data". (für Test verwendet: Taranis X9Dplus M-Link HF Modul HFMG2, Arduino mit Softwarestand April 2018, RX-7-DR Wingstabi, Adresse "Null" auf RX-Volt wie Werkseinstellung belassen, SM GPS Logger 2 für Telemetrie Daten, Vario, etc.).
M-Link Adressen Null und Eins, Zusatz zu Beitrag 16.12.2018
Ich testete den RX-7-DR Wingstabi Empfänger von MPX. Dabei kann man nur noch die Adresse "Null" im Launcher fest vergeben. Das ist kein Problem, alles funktionierte einwandfrei, das heisst kein "no data". (für Test verwendet: Taranis X9Dplus M-Link HF Modul HFMG2, Arduino mit Softwarestand April 2018, RX-7-DR Wingstabi, Adresse "Null" auf RX-Volt wie Werkseinstellung belassen, SM GPS Logger 2 für Telemetrie Daten, Vario, etc.).
K_A
User
M-Link Konverter für "Nicht Arduino Spezialisten"
M-Link Konverter für "Nicht Arduino Spezialisten"
Hallo Wolfgang
Wir haben da einiges gemeinsam. Zum Beispiel Wandern zum Startplatz in den Bergen, Segelfliegen, X-Lite, Multiplex, Feinmechanik und löten ja, Arduino lieber fertig bestellen. Das mit der X12 für Hangflieger hast du gut entschieden, bzw. wurdest gut von Engel beraten. Sie ist einfach zu schwer (wie Jeti auch). Die X10 war mir persönlich immer noch zu gross. Die X9D ist nochmals leichter und liegt viel besser in meinen Händen. Das mit dem Display unten ist im ersten Moment gewöhnungsbedürftig und ist nur ein kleines Problem, wenn du beide Varianten fliegst.
Deine Sorge wegen 3,3V:
Das war auch mein Gedanke, denn dann hätte man die Spannung vom MPX HF Modul abgreifen können und das Arduino wäre nur dann mit Strom versorgt worden. Ist jedoch auch so kein Problem. Ich holte die Spannung nicht wie beschrieben vom Daten Port, sondern vom Plus Pin im Modulschacht. Der wird ja nur gepowert, wenn im Modellspeicher "externes Modul" angewählt wurde. Sonst ist er stromlos. Da könntest du etwas missverstanden haben. Das MPX HF Modul musst du bei Nichtgebrauch nicht ausbauen, es sendet nur bei den Modellen, wo auch "externes Modul" angewählt wurde. Fliegst du mit einem andern Modell und internem Modul, bleibt es stromlos. Das gilt auch für das Arduino, falls es von diesem Pin mit Spannung versorgt wird. Achtung: Im Modulschacht bei meiner X9D liegt die volle Sender Akku Spannung an und nicht 6 Volt wie bei JR oder Graupner. Das muss mit den Komponenten verträglich sein, was bei 6 Eneloop oder 2S meist der Fall ist.
Das Arduino platzierte ich im Modulschacht über dem HFMG Modul (siehe Bild 30.11.2018).
X-Lite:
Gefällt mir sehr gut, aber hier kommt ein Umbau wegen der Grösse vorerst nicht in Frage. Infos folgen, falls ich mich anders entscheiden würde.
Kurt
M-Link Konverter für "Nicht Arduino Spezialisten"
Hallo Wolfgang
Wir haben da einiges gemeinsam. Zum Beispiel Wandern zum Startplatz in den Bergen, Segelfliegen, X-Lite, Multiplex, Feinmechanik und löten ja, Arduino lieber fertig bestellen. Das mit der X12 für Hangflieger hast du gut entschieden, bzw. wurdest gut von Engel beraten. Sie ist einfach zu schwer (wie Jeti auch). Die X10 war mir persönlich immer noch zu gross. Die X9D ist nochmals leichter und liegt viel besser in meinen Händen. Das mit dem Display unten ist im ersten Moment gewöhnungsbedürftig und ist nur ein kleines Problem, wenn du beide Varianten fliegst.
Deine Sorge wegen 3,3V:
Das war auch mein Gedanke, denn dann hätte man die Spannung vom MPX HF Modul abgreifen können und das Arduino wäre nur dann mit Strom versorgt worden. Ist jedoch auch so kein Problem. Ich holte die Spannung nicht wie beschrieben vom Daten Port, sondern vom Plus Pin im Modulschacht. Der wird ja nur gepowert, wenn im Modellspeicher "externes Modul" angewählt wurde. Sonst ist er stromlos. Da könntest du etwas missverstanden haben. Das MPX HF Modul musst du bei Nichtgebrauch nicht ausbauen, es sendet nur bei den Modellen, wo auch "externes Modul" angewählt wurde. Fliegst du mit einem andern Modell und internem Modul, bleibt es stromlos. Das gilt auch für das Arduino, falls es von diesem Pin mit Spannung versorgt wird. Achtung: Im Modulschacht bei meiner X9D liegt die volle Sender Akku Spannung an und nicht 6 Volt wie bei JR oder Graupner. Das muss mit den Komponenten verträglich sein, was bei 6 Eneloop oder 2S meist der Fall ist.
Das Arduino platzierte ich im Modulschacht über dem HFMG Modul (siehe Bild 30.11.2018).
X-Lite:
Gefällt mir sehr gut, aber hier kommt ein Umbau wegen der Grösse vorerst nicht in Frage. Infos folgen, falls ich mich anders entscheiden würde.
Kurt
Reinhardt Werbik
User
Hallo zusammen,
Kurt hat es ja schon ganz richtig erklärt, aber vielleicht nochmal eine kleine Zusammenfassung zur 3,3 V Variante des Konverters.
Der Grund für eine solche Variante war, dass man dann die Versorgungsspannung vom M-Link Modul über die Stiftleiste holen könnte.
(Dort liegen schlichtweg nur 3,3 V an.)
Beim Einbau in das Modul könnte man eine Buchsenleiste verwenden, bei der sich die Stifte ganz durchschieben lassen.
Da könnte man dann ohne an der Modulplatine zu löten die Versorgungsspannung, Masse und das Telemetrie-Signal abgreifen.
Lediglich zum Kontaktieren des Modulschacht-Pins zur Einspeisung der Daten in den Sender müsste man an der Platine selbst löten.
Dass der Konverter dann mit dem Modul ein- und ausgeschaltet wird, ist ein netter Nebeneffekt, der aber auch dann gegeben ist,
wenn man die Versorgungsspannung vom entsprechenden Modulschacht-Pin holt.
Es ist aber auch gar kein Problem, wenn der Konverter dauernd eingeschaltet ist, die Software ist dafür ausgelegt.
Taranis X9D und X9E haben eine separate Schnittstelle, über die der Konverter versorgt wird und die Daten einspeist.
In dieser Konfiguration ist der Konverter auch immer in Betrieb (außer wenn der Sender aus ist natürlich).
Bei 3,3 V Versorgungsspannung lassen sich die Atmel AVR Mikrocontroller nach Spezifikation nicht mehr mit 16 MHz Taktfrequenz betreiben.
Daher die Idee, ein Nanite 841 Board mit ATtiny 841 Controller und 8 MHz Taktfrequenz zu verwenden und die Software dafür umzuschreiben.
Dieses Board ist wirklich winzig, aber auch ein Pro Mini lässt sich locker im M-Link Modul unterbringen.
Und nun zu den schlechten Nachrichten:
Ich habe mir heute mal das Schaltbild des von mir weiter oben verlinkten Nanite 841 Boards angeschaut.
Leider hat dieses Board keinen Quarz, sondern nutzt den internen Oszillator des Mikrocontrollers.
Dieser hat aber ab Werk nur eine Genauigkeit von 2%, das ist zu ungenau, um einen SW UART mit 115,2 kBd zu realisieren.
Das Nanite Board scheidet damit für den Konverter aus.
Es gibt eine Pro Mini Variante mit 8 MHz Taktfrequenz, allerdings kenne ich nur eine Bezugsquelle dafür (die gleiche wie im obigen Link).
Der Takt dieses Boards ist quarzgenau, aber es könnte sein, dass bei 8 MHz die Laufzeiten des Interrupt-Handlers für den SW UART zu groß werden.
In diesem Fall wäre es schlicht nicht möglich, eine Konverter-Version für 3,3 V Versorgungsspannung zu bauen (jedenfalls nicht mit einem Atmel AVR Controller).
Ich werde vielleicht die Durchlaufzeiten des Interrupt-Handlers mal mit einer instrumentierten Testversion des Konverters messen, rein interessehalber.
Es macht aber keinen großen Sinn, die SW auf ein langsameres Pro Mini Board zu portieren, nur um eine Lötstelle zu sparen.
So, ich hoffe, dass ich nun nicht endgültig alle Klarheiten beseitigt habe.
Kurt hat es ja schon ganz richtig erklärt, aber vielleicht nochmal eine kleine Zusammenfassung zur 3,3 V Variante des Konverters.
Der Grund für eine solche Variante war, dass man dann die Versorgungsspannung vom M-Link Modul über die Stiftleiste holen könnte.
(Dort liegen schlichtweg nur 3,3 V an.)
Beim Einbau in das Modul könnte man eine Buchsenleiste verwenden, bei der sich die Stifte ganz durchschieben lassen.
Da könnte man dann ohne an der Modulplatine zu löten die Versorgungsspannung, Masse und das Telemetrie-Signal abgreifen.
Lediglich zum Kontaktieren des Modulschacht-Pins zur Einspeisung der Daten in den Sender müsste man an der Platine selbst löten.
Dass der Konverter dann mit dem Modul ein- und ausgeschaltet wird, ist ein netter Nebeneffekt, der aber auch dann gegeben ist,
wenn man die Versorgungsspannung vom entsprechenden Modulschacht-Pin holt.
Es ist aber auch gar kein Problem, wenn der Konverter dauernd eingeschaltet ist, die Software ist dafür ausgelegt.
Taranis X9D und X9E haben eine separate Schnittstelle, über die der Konverter versorgt wird und die Daten einspeist.
In dieser Konfiguration ist der Konverter auch immer in Betrieb (außer wenn der Sender aus ist natürlich).
Bei 3,3 V Versorgungsspannung lassen sich die Atmel AVR Mikrocontroller nach Spezifikation nicht mehr mit 16 MHz Taktfrequenz betreiben.
Daher die Idee, ein Nanite 841 Board mit ATtiny 841 Controller und 8 MHz Taktfrequenz zu verwenden und die Software dafür umzuschreiben.
Dieses Board ist wirklich winzig, aber auch ein Pro Mini lässt sich locker im M-Link Modul unterbringen.
Und nun zu den schlechten Nachrichten:
Ich habe mir heute mal das Schaltbild des von mir weiter oben verlinkten Nanite 841 Boards angeschaut.
Leider hat dieses Board keinen Quarz, sondern nutzt den internen Oszillator des Mikrocontrollers.
Dieser hat aber ab Werk nur eine Genauigkeit von 2%, das ist zu ungenau, um einen SW UART mit 115,2 kBd zu realisieren.
Das Nanite Board scheidet damit für den Konverter aus.
Es gibt eine Pro Mini Variante mit 8 MHz Taktfrequenz, allerdings kenne ich nur eine Bezugsquelle dafür (die gleiche wie im obigen Link).
Der Takt dieses Boards ist quarzgenau, aber es könnte sein, dass bei 8 MHz die Laufzeiten des Interrupt-Handlers für den SW UART zu groß werden.
In diesem Fall wäre es schlicht nicht möglich, eine Konverter-Version für 3,3 V Versorgungsspannung zu bauen (jedenfalls nicht mit einem Atmel AVR Controller).
Ich werde vielleicht die Durchlaufzeiten des Interrupt-Handlers mal mit einer instrumentierten Testversion des Konverters messen, rein interessehalber.
Es macht aber keinen großen Sinn, die SW auf ein langsameres Pro Mini Board zu portieren, nur um eine Lötstelle zu sparen.
So, ich hoffe, dass ich nun nicht endgültig alle Klarheiten beseitigt habe.
Reinhardt Werbik
User
Das habe ich heute Nachmittag getan, da es ohnehin fast den ganzen Tag geschneit hat.
Nach meinen Versuchen müsste es sich bei 8 MHz gerade so ausgehen mit dem SW UART.
Zufälligerweise habe ich noch ein oder zwei der Pro Minis mit 8 MHz rumliegen.
Vielleicht mache ich mir ja doch den Spaß, den Konverter darauf zu portieren.
Da es der gleiche µC ist, ist die Portierung wesentlich einfacher als beim Nanite Board.
kalle123
User
Hallo Reinhardt, ich lese ja immer interessiert mit.
Hatte mich schon gewundert, wie ich mir den Plan dieser Nanites angeschaut habe.
https://github.com/cpldcpu/Nanite
Sehr viel ist da ja nicht dran. Wozu überhaupt da noch ein shield benötigt wird?
Ich bin absoluter Handsender Fan und liebe die Taranis X9D. Und dann DAS Preis <> Leistungsverhältnis! Die X9D kann und macht was sie soll und ich haben will und ich muss auch gestehen, bin immer noch bei 2.1.9
Und du hast ja gesehen, wie ich den Teensy bzw. jetzt die Arduinos unter die Taranis "pappe". Also kleiner muss für mich der Konverter nicht werden.
Aber wenn du nen Code für nen Attiny raus gibts, werde ich mir wohl auch mal so Käferchen anschaffen und auf nen breadboard stecken und mal hier versuchen.
Grüße und viel Spass im Skiurlaub - KH
Hatte mich schon gewundert, wie ich mir den Plan dieser Nanites angeschaut habe.
https://github.com/cpldcpu/Nanite
Sehr viel ist da ja nicht dran. Wozu überhaupt da noch ein shield benötigt wird?
Ich bin absoluter Handsender Fan und liebe die Taranis X9D. Und dann DAS Preis <> Leistungsverhältnis! Die X9D kann und macht was sie soll und ich haben will und ich muss auch gestehen, bin immer noch bei 2.1.9
Und du hast ja gesehen, wie ich den Teensy bzw. jetzt die Arduinos unter die Taranis "pappe". Also kleiner muss für mich der Konverter nicht werden.
Aber wenn du nen Code für nen Attiny raus gibts, werde ich mir wohl auch mal so Käferchen anschaffen und auf nen breadboard stecken und mal hier versuchen.
Grüße und viel Spass im Skiurlaub - KH
Reinhardt Werbik
User
Hallo Kalle,
das von Dir verlinkte Board ist ein Nanite 85 mit einem ATtiny 85 Controller.
Dieses Board kommt ohnehin nicht in Frage, da der ATtiny 85 zu wenig Timer hat.
Das von mir weiter oben verlinkte Board ist ein Nanite 841, das den wesentlich moderneren ATtiny 841 verwendet.
Dieser hat einen 8-Bit und zwei 16-Bit Timer, sowie zwei HW USARTs.
Ähnliche Themen
