OpenTX - Multiplex MLINK Konverter

Hallo Reinhardt,
diese Parameter würden wirklich alles abdecken!

JST PH Stecker, Buchsen und Crimpkontakte gibt es beim Conrad. Mit der Nessel Crimpzange und dem beiliegenden Einsatz kann man auch JST Kontakte sehr gut crimpen.
Ansonsten ist Flinko die einzige Bezugsquelle die ich kenne.

LG
Roland
 
Hallo Roland,

das Einbinden einer SD Karte zum Loggen habe derzeit nicht auf meiner to do Liste, da müsste ich mich komplett von vorne einarbeiten.
Außerdem bin ich der Meinung, dass das Loggen am besten im Modell erfolgt, dort wo die Daten entstehen.

Was die zusätzlichen Parameter angeht, da lässt sich wie gesagt drüber reden, ich würde folgende Ergänzungen vorschlagen:

- zweimal Temperatur auf die IDs 0x02 und 0x03, wie vom FrSky Hub Protokoll vorgesehen
- Drehzahl auf die ID 0x03, ist auch schon so vorgesehen

Geschwindigkeit könnte man als GPS Speed ausgeben mit IDs 0x11 und 0x19 (Wert vor bzw. nach dem Dezimalpunkt).
Als Einheit sieht das FrSky Protokoll Knoten vor, ich würde das aber eher in km/h ausgeben.
m/s wäre auch möglich, aber die Auflösung auf dem MSB beträgt 0,1 km/h, da bringen m/s jetzt nicht so viel.

Bezüglich der MSB Adressen würde ich dann eine automatische Ermittlung implementieren nach folgenden Regeln.

- LQI wird auf Adresse 1 erwartet.

- A1 Spannung ist die niedrigste Adresse eines Spannungswertes (normalerweise also die Empfängerspannung auf Adresse 0).
- A2 Spannung ist die zweitniedrigste Adresse eines Spannungswertes oder unbenutzt, falls nur zwei Spannungswerte existieren.
- VFAS ist die drittniedrigste Adresse eines Spannungswertes oder die zweitniedrigste, falls nur zwei Spannungen existieren.

Wenn nur zwei Spannungen übertragen werden, werden diese somit nach A1 und VFAS konvertiert.

- Temperatur 1 ist die niedrigste, Temperatur 2 die zweitniedrigste Adresse eines Temperaturwertes.

- Strom, Ladung, Höhe, Steigrate, Drehzahl und Geschwindigkeit werden jeweils aus der niedrigsten Adresse mit der entsprechenden Werteklasse abgeleitet.

Würde das so passen?


Gruß
Reinhardt

Hallo,
ich habe zwar weder ein kompensiertes Vario noch GPS, aber wenn neue Interessenten kommen, die GPS einsetzen wollen, würde wegen der GPS Parameter schnell bei dir angefragt werden. (Entfernung und Richtung, Geschwindigkeit) Entfernung und Richtung könnte auch beim Wiederfinden eines "davongeflogenen" Modells hilfreich sein, falls man ein GPS drinnen hatte! :-)

Wenn ichs mir aussuchen dürfte, würde ich natürlich alle möglichen Parameter empfehlen! (inkl. zwei Geschwindigkeiten. Einmal barometrisch über Staudruck, einmal vom GPS). Für Piloten mit großen Maschinen, könnten auch 2 Ladungen interessant sein. (Motorakku und Empfängerakku). Einzelzellenüberwachung ist für mich nicht wichtig. 2xLadung und 2xSpannung fände ich bei 2 Akkus aussagekräftiger. Ich glaube es fallen mehr Flieger vom Himmel wegen leerem Akku als wegen einer defekten Zelle.

Ich persönlich freue mich über jeden Wert und bedanke mich für jeden Wert den ich übersetzen darf! Mir war eigentlich nur das VARIO wichtig. Der Rest ist Luxus, macht aber unheimlich viel Spaß und wertet das ganze FrSky System natürlich enorm auf!! :)

Die automatische Reihung der Parameter klingt gut!


LG
Roland
 

kalle123

User
Wir haben in der Version von Dieter auch Einzelzellenspannung bei 6S realisiert. Siehe mein posting #17 hier im thread.
Muss aber sagen, sooo interessant finde ich diese Möglichkeit inzwischen nicht mehr. Mir reicht die Lipospannung.

Roland, zum GPS. MPX hat in seinem (recht teuren GPS) nen eigenen Prozessor mit properitärer Firmware drin, der etwas "seltsame" Daten transferiert.
Üblich ist ein serielles GPS von U-Blox, welches NMEA Datensätze ausspuckt.

Schau dir das mal an. Vor 3 Tagen aus China zu 9$. Funktioniert einwandfrei. (8 Gramm. Das ist ne 1 Cent Münze im Bild!!!)

screenshot #25.jpg



cu KH
 

eisi

Vereinsmitglied
Tach zusammen,

bewundernd lese esse ich Eure Beschreibungen über Euer Vorgehen und frage mich immer, warum ich das nicht kann oder begreife. Meine Hochachtung.

Da ich mich eher zu den Anwendern als zu den Entwicklern zähle, möchte ich ganz vorsichtig fragen, zu welcher Lösung Ihr mir raten würdet? Einen Konverter würde ich als alter MULTIPLEXer mit dem neuen Floh im Hirn "TARANIS" gerne nachbauen und nutzen.

Über Eure Empfehlung würde ich mich sehr freuen.

Gruß
Frank
 
Hallo Frank,
für den Teensy Konverter brauchst du nur den Teensy und 2 Stecker. (1x JR Stecker und 1x JST PH4 Stecker zb von Conrad).

Für Reinhardts Konverter brauchst du einen Arduino pro mini oder nano, 2 Stecker und einen ISP Programmer. ISP Programmer kostet rund 30€. Beide Konverter funktionieren. Für die X9E funktioniert Reinhardts besser! Für X9D ists vollkommen egal! Wenn du nichts zu Hause hast, wird der Teensy rund 20€, Reinhardts vielleicht 45€ kosten.

Lg
Roland
 
Hallo Frank,
für den Teensy Konverter brauchst du nur den Teensy und 2 Stecker. (1x JR Stecker und 1x JST PH4 Stecker zb von Conrad).

Für Reinhardts Konverter brauchst du einen Arduino pro mini oder nano, 2 Stecker und einen ISP Programmer. ISP Programmer kostet rund 30€. Beide Konverter funktionieren. Für die X9E funktioniert Reinhardts besser! Für X9D ists vollkommen egal! Wenn du nichts zu Hause hast, wird der Teensy rund 20€, Reinhardts vielleicht 45€ kosten.

Lg
Roland
Hallo zusammen,

da das Bootloader Problem mittlerweile ja gelöst ist, werde ich beim nächsten Update meines in der Taranis eingebauten Boards
den Optiboot Bootloader draufspielen, dann braucht's keinen ISP Programmer mehr, sondern nur ein USB/FTDI Kabel.

Zur Zeit würde ich meinen Konverter aber noch nicht für den Praxiseinsatz empfehlen (außer zum Testen natürlich),
da die feste Zuordnung von MSB Adressen nicht wirklich praxistauglich für eine größere Anzahl von Usern ist.
Da bin ich aber im Moment dran, das auf automatische Erkennung umzustellen (neben der Implementierung zusätzliche Parameter).


Gruß
Reinhardt
 

kalle123

User
Hallo Frank,
für den Teensy Konverter brauchst du nur den Teensy und 2 Stecker. (1x JR Stecker und 1x JST PH4 Stecker zb von Conrad).

Für Reinhardts Konverter brauchst du einen Arduino pro mini oder nano, 2 Stecker und einen ISP Programmer. ISP Programmer kostet rund 30€. Beide Konverter funktionieren. Für die X9E funktioniert Reinhardts besser! Für X9D ists vollkommen egal! Wenn du nichts zu Hause hast, wird der Teensy rund 20€, Reinhardts vielleicht 45€ kosten.

Lg
Roland

Dann will ich meinen "Senf" auch noch dazu geben. ;)

"ISP Programmer kostet rund 30€"

Roland, ich hab doch gerade hier demonstriert, dass es mit dem USBasp auch geht. Der kostet in der Bucht aus D ~ 4€, aus China ~1.50€.

Und Reinhardt schreibt ja auch "Zur Zeit würde ich meinen Konverter aber noch nicht für den Praxiseinsatz empfehlen (außer zum Testen natürlich)"

Also wenn du einen Konverter jetzt mal in der Praxis so wie ich benutzen willst, nimm den Teensy LC. Und du brauchst ein USB Kabel mit Micro Stecker.

Hier mal ein Log.

A1 ist die RX Spannung, RSSI heisst jetzt LQI und Cons steht für die verbrauchten mAh. Rest dürfte bekannt sein. Sensorik ist oXs.

Gruß KH
screenshot #26.png
 
Hallo Reinhardt,
Wird es in der neuen Version möglich sein, mehrere Sensoren eines Typs zu verwenden?
Zb 4x Vario oder 4x Strom?
Sprich, der Konverter erkennt ohne Einschränkungen jeden Kanal unabhängig davon ob ein Parameter schon gefunden wurde?
4 Varios sind vielleicht sinnlos, für Temperaturen, Strom oder Spannung gäbe es sicher sinnvolle Anwendungen.
Lg Roland
 
Hallo Reinhardt,
Wird es in der neuen Version möglich sein, mehrere Sensoren eines Typs zu verwenden?
Zb 4x Vario oder 4x Strom?
Sprich, der Konverter erkennt ohne Einschränkungen jeden Kanal unabhängig davon ob ein Parameter schon gefunden wurde?
4 Varios sind vielleicht sinnlos, für Temperaturen, Strom oder Spannung gäbe es sicher sinnvolle Anwendungen.
Lg Roland
Hallo Roland,

die nächste Version wird die weiter oben aufgelisteten Parameter können (hoffentlich).

Grundsätzlich kann man natürlich für alle Parameter Mehrfachbelegungen vorsehen.
Es gibt aber hier Beschränkungen bzgl. des FrSky Hub Protokolls, wo halt nur bestimmte IDs vorgesehen sind.
Man könnte natürlich mal sehen, was passiert, wenn man eine ID außerhalb des derzeit definierten Bereichs verwendet.
Vielleicht wird der Parameter dann von OpenTx einfach ohne Namen, nur mit der ID, durchgereicht.
Das ist z.B. für die Ladung (die im Hub Protokoll nicht vorgesehen ist) mit der ID 0x29 der Fall, muss man halt im Sender alles frei konfigurieren.
Wenn man aber den von FrSky vorgesehenen Bereich an IDs verlässt, was passiert dann, und was ändert sich da in der Zukunft.
Ich würde da kein Konzept für einen Multi-Sensor drauf aufbauen wollen, zumal das Hub Protokoll selbst ja eigentlich auch schon veraltet ist.
Das wäre eher ein Fall für die S-Port Telemetrie, die aber derzeit für Selbstbau-Konverter nicht verfügbar ist.

Ganz ehrlich, ein zweiter Strom-/Ladungssensor für einen Empfängerakku macht auch keinen Sinn.
Denn diesen legt man nicht so aus, dass man (außer der Spannung) da irgendwas im Flug überwachen müsste.

Spannung und Temperatur sind ja in obiger Liste schon 3- bzw. 2-fach vorhanden


Gruß
Reinhardt
 
Hallo zusammen,

ich würde gerne am Wochenende die nächste Version des Konverters fertigmachen.
Da ich aber nicht alle Sensoren zum Testen der neuen Parameter habe, bin ich da auf Eure Mithilfe angewiesen. ;)

Für die Drehzahl stehen in der MSB Spezifikation zwei Definitionen:

Auflösung 100 1/min, Min. 0, Max. +500
Auflösung 10 1/min, Min. 0, Max. -5000

Ich interpretiere das so, dass bei positivem Sensorwert die Auflösung 100 rpm beträgt.
Um die später eingeführte bessere Auflösung von 10 rpm zu kennzeichnen, wird der Wert mit negativem Vorzeichen versehen.
In beiden Fällen würde sich eine max. darstellbare Drehzahl von 50000 ergeben, das Vorzeichen ist ja hier für die Anzeige egal.
Ihr habt doch mit der Drehzahl ziemlich rumgemacht, bis es gepasst hat, könnt Ihr meine Annahme bestätigen?

Die automatische Adressermittlung sollte funktionieren, wird aber noch getestet, bevor die neue Version hier auftaucht.


Gruß
Reinhardt
 
Hallo Reinhardt,
Ich habe noch keine Erfahrungen mit der Drehzahl, könnte aber einen Unisense E Sensor am Wochenende in einen E-segler einbauen und dir dann ein Feedback zur Funktion des Konverter geben.
Zur Interpretation deiner Frage kann ich nichts beitragen, klingt aber logisch.
Lg Roland
 

kalle123

User
Reinhardt, deine Frage kann ich so direkt nicht beantworten.

Wir haben Versuche mit der Drehzahl Messung gemacht. Ich einmal mit Unisens-E und mit nem DIY Sensor und oXs.

Wenn du deinen neuen Code einstellst, bin ich gerne bereit, Versuche hier zu fahren.

Gruß KH
 

Anhänge

  • screenshot #34.png
    screenshot #34.png
    107,2 KB · Aufrufe: 174
  • screenshot #35.jpg
    screenshot #35.jpg
    25,9 KB · Aufrufe: 168
Hallo zusammen,

nachdem heute genau das richtige Sch...wetter dafür ist, habe ich die nächste Version des Konverters fertig gemacht. :)

Die Liste der übertragenen Parameter wurde deutlich erweitert:

- LQI
- Empfängerspannung
- Spannung 1
- Spannung 2
- Strom
- Ladung
- Drehzahl
- Temperatur 1
- Temperatur 2
- Höhe
- Steigrate
- Geschwindigkeit

Außerdem werden die MSB Adressen jetzt automatisch nach folgenden Regeln ermittelt:

Die Adressen für LQI (Adresse 1) und Empfängerspannung (Adresse 0) sind fest zugeordnet.
Für alle anderen Parameter werden jeweils die niedrigsten vorhandenen Adressen mit passender Werteklasse verwendet.
Bei den Spannungen gibt es eine Besonderheit für den Fall, dass (neben der Rx Spannung) nur eine Spannung auf dem Bus vorliegt:
- ist die Adresse 2, bleibt sie der Spannung 1 zugeordnet (RVLQ Frame, max. 25,5V)
- ist die Adresse größer als 2, wird sie für Spannung 2 verwendet (User Data Frame, voller Messbereich)

Ich konnte die Adressermittlung mit einem E-Sense für alle Parameter außer Temperaturen und Geschwindigkeit testen.
Es gibt aber keinen echten Grund, warum das nicht für alle Parameter funktionieren sollte (außer ein blöder Tippfehler im Code :eek:).

Was die Messung von Temperatur und Geschwindigkeit angeht, bin ich leider blank (mangels Sensoren :cry:).
Die Drehzahl werde ich später noch mit dem MSB Expert Regler in meiner FunCub testen.
Aber generell ist hier natürlich Euer Feedback höchst willkommen.

Ich habe übrigens die Geschwindigkeit nicht in Knoten umgerechnet, sondern die MSB Einheit und Auflösung beibehalten (0,1 km/h).
Auch habe ich bei den Spannungen A1 und A2 von einer Skalierung auf den 13,2 V Default Darstellungsbereich der Taranis abgesehen.
Eine zweifache Skalierung ist technisch sub-optimal, es ist besser, den Skalierungsbereich im Sender auf 25,6 V zu ändern.

Beim Start dauert es ein paar Sekunden, bis die Telemetrie aktiviert wird.
Da das M-Link Modul nach dem Einschalten immer kurzzeitig gültige Telemetriedaten signalisiert (auch bei ausgeschaltetem Empfänger),
wird nach dem Start zunächst eine definierte Anzahl von M-Link Datenpaketen ignoriert.
Dann wird eine definierte Anzahl von M-Link Datenpaketen mit gültigen Telemetriedaten zur Ermittlung der MSB Adressen ausgewertet.
(Dabei werden auch noch keine FrSky Telemetriedaten gesendet.)
Erst Danach wird die Telemetrieausgabe aktiviert.

Erstaunlicherweise erkennt der Konverter sogar, wenn während des laufenden Betriebes einzelne Sensoren ab- und wieder angesteckt werden.
(mit gewissen Verzögerungen, die vom Verhalten des M-Link Sendemoduls bestimmt sind)
Das kann ich mir aus dem Code allein nicht wirklich erklären, es muss damit zu tun haben, was das M-Link Modul in so einem Fall sendet.

Wird der Empfänger komplett ausgeschaltet, werden die Telemetriedaten nach wenigen Sekunden abgeschaltet und die entsprechende Warnung kommt.
Beim erneuten Einschalten des Empfängers passiert natürlich genau das umgekehrte.

Wichtig ist noch, dass die MSB Adressen nur einmal beim Hochfahren ermittelt werden.
Wenn man also den Empfänger ausschaltet, ohne den Sender (mit Konverter) auszuschalten, und dann mit anders konfigurierten Sensoren
wieder einschaltet, erkennt der Konverter die geänderte Konfiguration nicht.
Das dürfte aber auch kein in der Praxis relevanter Fall sein (man könnte es sicher ändern, im Moment sehe ich da aber keine Bedarf).

Viel Spaß beim Testen. :D


Gruß
Reinhardt
 

Anhänge

  • Konverter_2016-06-19.hex.txt
    8,8 KB · Aufrufe: 95
So, ich habe jetzt mit der FunCub mal probiert, was da so auf dem Display der Taranis ankommt.
Und erfreulicherweise waren bis auf die Drehzahl alle angezeigten Werte plausibel.
Der MSB Expert gibt auch die Temperatur aus, was ich ganz vergessen hatte, so dass ich diesen Parameter ebenfalls testen konnte.
Die Temperatur wurde anfangs mit 21 °C angezeigt und ging dann durch die kurzen Testläufe ein paar Grad rauf, das passt offensichtlich.

Die angezeigte Drehzahl war allerdings viel zu hoch, da würde jede Turbine vor Neid erblassen. :D
Ich bin natürlich von einem Programmierfehler ausgegangen, aber dem scheint nicht so zu sein.
Ich habe nämlich eine Testversion des Programms geladen, bei der die Drehzahl einfach auf einen konstanten Wert gesetzt wird.
Ich konnte bei zwei verschiedenen konstanten Werten feststellen, dass der angezeigte Wert um den Faktor 60 zu hoch ist.
(Also sozusagen statt Umdrehungen pro Minute Umdrehungen pro Stunde)

Mit dem Bus-Analyser konnte ich verifizierten, dass der Konverter den richtigen Wert an die Taranis ausgibt.
Entweder muss man da noch irgendwo was am Sender einstellen, oder OpenTx macht an dieser Stelle was merkwürdiges.
Der angezeigte Wert von 600000 (bei einem ausgegebenen Konstantwert von 10000) lässt sich mit dem Hub-Protokoll gar nicht erzeugen.

Muss ich wohl mal etwas nachforschen, was hier los ist.
Oder ist es etwa ein bekannter Bug?


Gruß
Reinhardt
 
In der FrSky Protokoll Spezifikation habe ich jetzt folgenden Satz gefunden:

"Real RPM value should be the RPM value in Frame1*60."

Das interpretiere ich jetzt so, dass (warum auch immer) das LSB des Drehzahlwertes 60 ist.
Das würde sich mit meinen Versuchen decken, macht aber letztlich den RPM Wert mit ID 0x03 für den Konverter nutzlos,
da man ja die Auflösung von 10, die Multiplex und SM-Modellbau bieten, nicht nutzen kann.

Ich denke, ich werde (wie bei der Ladung) einfach eine unbenutzte ID verwenden und dann Namen und Einheit im Sender einstellen.


Gruß
Reinhardt
 
BOOTRST

BOOTRST

Hallo Reinhardt,
im Atmel Studio unter "Device Programmierung" unter "FUSES" ist BOOTRST standardmäßig ausgewählt. Das war auch bei der ersten Version so. Soll ich diese Option nun raus nehmen? Dein Hinweis dies zu deaktivieren, kam erst nachdem ich es damals programmiert hatte. Hat jedenfalls tadellos funktioniert.
Soll ich nun das "Hackerl" bei BOOTRST wegnehmen oder dort lassen? Atmelstudio sagt bei beiden Optionen (angehakt und abgewählt) "Boot Reset Vector Enabled High Bit 0". Mir ist deshalb nicht klar, wann diese Option deaktiviert ist.
LG
Roland
 
Hallo Reinhardt,
ich habe dein neues HEX File getestet. Soweit ich es beurteilen kann, dürften ALT, VSped, RSSI und Temp tadellos funktionieren. Der Sender erkennt alle Parameter, unabhängig von der definierten Adresse.
Drehzahl und Strom werde ich prüfen, sobald ich mal alleine zuhause bin. Motoren in der Wohnung sind von meiner Frau nicht gerne gesehen.

Min/MAX Einstellungen im Sensor müssen deaktiviert sein, sonst "hupft" der angezeigte Wert zwischen aktuellem Wert und Maximalwert. Im Sensor habe ich auch alle Alarme deaktiviert. Alarme im Sensor sind bei FrSky nicht notwendig, da diese im Sender definiert werden können.

Bein einigen Parametern ist im Sender die Option "Filter" aktiv. Wozu sind diese Filter?

Bei der X9E wird RSSI sofort erkannt und am oberen Display dargestellt, sobald der Sender diesen Parameter findet. Auch wenn keine Sensoren im Telemetriemenü definiert sind. Das hat vielleicht nichts mit dem Konverter zu tun. Trotzdem sehr angenehm, da man sofort erkennt ob Telemetrie verfügbar ist.

Deine erwähnte "Wartezeit" beim Konverterstart, fällt nicht störend auf! Es dauert keine 2 Sekunden bis die RSSI Anzeige am Display auf 100% springt. Sobald RSSI am Display erscheint, gibt der Lautsprecher -wahrscheinlich vom Vario- für 5 Sekunden einen Dauerton aus. Danach geht das Vario in den "Ruhe" Moduls und Sender/Konverter dürften einsatzbereit sein. Keine Ahnung ob der Dauerton vom Sender selbst oder vom Konverterstart ausgelöst wird. Der Dauerton kann als akustischer Hinweis angesehen werden, wann der Sender einsatzbereit ist.
Schalte ich den Empfänger aus, dauert es 4 Sekunden bis RSSI vom Dispay verschwindet.

Es erscheint jedoch kein Hinweis: "Telemetrie verloren". Ich glaube Reinhardt hatte erwähnt, dass der Sender solch einen Alarm ausgibt. Gibt es für den "Telemetrie verloren" Alarm eine eigene Einstellung am Sender oder macht ihr das über einen "normalen" Alarm? zB wenn Rssi=0


Reinhardt, vielen Dank nochmal!!!


Eine Frage hätte ich noch. Kann man die INPUTS der beiden internen LEDs (grün/rot) am Arduinoboard zusätzlich oder fix auf freie PINS legen, sodaß man eigene LEDs anhängen könnte? Bei der X9E habe ich genug Platz um die Status LEDs des Konverters auf der Oberseite zu montieren. Zumindest die grüne LED wäre sinnvoll, da sie die Funktion des Konverters meldet.


LG
Roland
 
Hallo Reinhardt,
im Atmel Studio unter "Device Programmierung" unter "FUSES" ist BOOTRST standardmäßig ausgewählt. Das war auch bei der ersten Version so. Soll ich diese Option nun raus nehmen? Dein Hinweis dies zu deaktivieren, kam erst nachdem ich es damals programmiert hatte. Hat jedenfalls tadellos funktioniert.
Soll ich nun das "Hackerl" bei BOOTRST wegnehmen oder dort lassen? Atmelstudio sagt bei beiden Optionen (angehakt und abgewählt) "Boot Reset Vector Enabled High Bit 0". Mir ist deshalb nicht klar, wann diese Option deaktiviert ist.
LG
Roland
Hallo Roland,

die BOOTRST Fuse muss auf jeden Fall dann gesetzt sein, wenn Du einen Bootlader verwendest.
Wenn Du über ISP programmierst, muss diese Fuse normalerweise gelöscht sein, da dann ja in der Regel kein Bootlader vorhanden ist, zu dem beim Start gesprungen werden kann.

Wenn das Programm bei gesetzter BOOTRST Fuse started, muss ein Bootlader vorhanden sein, anders ist das nicht möglich.
Wenn der Bootlader das Laden eines Programms beendet hat, oder gar keines laden muss, startet er nach einer gewissen Zeit die Applikation.
Das ist aber nur möglich, wenn Du bei Programmieren mit ISP nicht vorher den Speicher gelöscht hast, ansonsten wäre der Bootlader ja weg.


Gruß
Reinhardt
 
Das ist aber nur möglich, wenn Du bei Programmieren mit ISP nicht vorher den Speicher gelöscht hast, ansonsten wäre der Bootlader ja weg.

Ok, also müsste ich mit "Erase Chip" zuerst den Speicher komplett löschen und erst dann das Programm hochladen. Ich glaube das hatte ich beim ersten mal nicht gemacht, da ich angenommen hatte, das beim hochladen zuerst der Chip gelöscht wird, weil die Option "Erase device before prorgamming" aktiviert war.
Egal, Wenn die BOOTRST Fuse ohne bottloader nicht gesetzt sein darf, muß ich es wohl doch anders gemacht haben! :-) sonst hätte es wohl nicht funktioniert


Danke für die Infos!
 
Hallo Roland,

erst mal vielen Dank für Dein schnelles Feedback, das hört sich ja gar nicht so schlecht an.
Einige Punkte Deines Posts muss ich mal aufgreifen, da sie auf evtl. Fehler im Programm hindeuten könnten.

Min/Max Werte:
Ein Hin- und Herspringen darf nur auftreten, wenn alle Werte auf der gleichen Adresse übertragen werden.
Bei MPX Sensoren gibt es dafür normalerweise separate Adressen, da sollte kein Hin- und Herspringen zu beobachten sein.
Vielleicht musst Du nochmal schauen, welche Adressen genau konfiguriert sind.

Ob Sensoren im Sender definiert sind, spielt keine Rolle, sobald zumindest der RVLQ Frame am seriellen Port anliegt, wird die Telemetrie erkannt.
Das ist auch bei meiner X9D so, dann erscheint das entsprechende Symbol oben am Display.
(Ob da auch der RSSI Wert irgendwo zu sehen ist, weiss ich jetzt gar nicht.)
Was mich etwas wundert ist die Zeit von nur 2 Sekunden.
Eigentlich werden insgesamt etwa 60 M-Link Datenpakete für Start-Up und Adressenermittlung "verbraten".
Das müsste eigentlich länger als 2 s dauern, muss ich mir nochmal genau ansehen.

Die 4 s bis zum Deaktivieren der Telemetrie decken sich mit meinen Beobachtungen.
Da muss der Konverter warten, bis vom M-Link Modul keine gültigen Telemetriedaten mehr kommen, da er selbst das ja nicht beurteilen kann.
Dann ist da noch eine kleine Hysterese eingebaut, aber das mit den 4 s kommt hin.

Warum bei Dir keine Sprachausgabe "Telemetrie verloren" kommt, weiss ich nicht, kann eigentlich nur an den Einstellungen im Sender liegen.
Bei mir kommt diese Sprachmeldung einige Sekunden nach dem Ausschalten des Empfängers.
Wenn der Empfänger dann wieder eingeschaltet wird, kommt dementsprechend "Telemetrie aktiv".
Diese Meldungen haben nichts mit dem RSSI Wert zu tun, sondern nur damit ob serielle Telemetriedaten am Port ankommen oder nicht.

Was die LEDs abgeht, da müsste man sich mal das Schaltbild des Boards ansehen...

Übrigens scheint sich das "Problem" mit der vordefinierten ID für die Drehzahl tatsächlich als Feature zu erweisen.
Das Hub Protokoll sieht hier wohl die Übertragung von Umdrehungen pro Sekunde vor, Gott weiss warum.
(Das hat natürlich was mit der Implementierung des FrSky eigenen Drehzahlsensors für das Hub Protokoll zu tun.)
Open Tx multipiziert das dann mit 60 (und macht ggf. noch andere Anpassungen wegen Blattzahl etc.).
Ich will natürlich nicht die Auflösung von 10 1/min verlieren, indem ich den Wert vor der Ausgabe durch 60 teile.
Ich werde daher für die Drehzahl eine nicht vordefinierte ID (0x07) verwenden, dann wird einfach der Wert ohne Veränderung durchgereicht.
Man muss dann halt einmalig im Sender den Namen und die Einheit einstellen.

Gruß
Reinhardt
 
Ansicht hell / dunkel umschalten
Oben Unten