MPX Display mit Adruino

Gast_7088

User gesperrt
also das es kein MPX Display aktuell gibt und ich als "Umrüster" ( ja ja ich habe MPX in eine MC22 gebaut) ohne Display kein Telemetriedaten sehen kann möchte ich langsam anfangen ein eigenes Display zu bauen. Zunächst ist die Frage wer hätte noch Lust dazu?

Mein Vorstellung ist ein Display das entweder 4 zeilig ist. dann bracht es noch ein paar Knöpfe für die üblichen Verdächtigen rauf runter Seite runter rauf
Was noch mal geschaut werden müsste ist, was denn MPX macht mit den Daten die vom Sensor kommen ausser sie in die richtige Zeile zuschreiben und bei gesetztem Alarm Bit zu piepen... ggf noch das richtige Einheitezeichen anzuheften.
Was einen Unterschied machen könnte, ob man an einem MPX Sender abgreift oder an einem Nachrüstmodul.

Klar ist auch das MPX für solche Umbauten keine Haftung über nimmt. Ok ich auch nicht...
Allerdings kann das natürlich nur für Probleme gelten die durch den Anbau verursacht werden....

ich denke wir starten mit der Wunschliste :
  1. Monocrom ( wenn sein soll auch bunt, dann aber umschaltbar auf monochrom wegen Lesbarkeit)
  2. gut ablesbar
  3. preiswert
  4. gut zu montieren
  5. Temperatur stabil ( gaaaanz wichtich)
  6. mehrfach piepen bei anstehendem Alarm ( hihi)
  7. ganz schwierig ist die geliebte Sprachausgabe und steht deshalb hinten an, sei den jemand stürzt sich drauf
Wenn MPX die Daten vom Sensor nur roh durch die Telemtrie Strecke durch routet wäre das cool, weil dann "all doors open " könnte man Sensoren und Anzeigen /Töne machen wie man es für geschickt hält und es könnte ein echtes open Source Projekt werden.
das müsste man noch mal schauen ... aber ich fürchte so flexibel ist es dann doch nicht.
Und was wird empfangen wenn zwei Empfänger die nicht verbunden sind ( was eben sowie so nicht gemacht werden soll) MPX hat keine Zuordnung von Empfänger zum Modell.
Vielleicht kann man da ja den geneigten Piloten warnen das es so ist ...
 
Nu wohl Ruhe... hihi

Nu wohl Ruhe... hihi

So, nun back to Topic - Display:

Wie schon in dem Threat geschrieben ist ein Display bei mir auf der langen Bank.

Mein Sensor läuft in elementaren Dingen - eigentlich kein Problem.

Hardware soweit auch, ich will nur noch Probeschaltungen in Spagettischaltung testen.
( Genauigkeit der Analogschaltung, die eben auch 12S Einzelzellenmessung ermöglicht ).

Ok, das ist auch hier oot - also Display:

Ich finde Sprachausgabe weit sinnvoller als große Display, im Flug habe ich keine Zeit
zum Display zu schauen, ich nutze das Display praktisch nur beim Einschalten ( ist die Accuspannung
so wie erwartet ? ) und kurz vor dem Ausschalten ( wie weit ist der Accu nun entladen usw. ) .

In der Praxis nutze ich das ja eh ( Royal Pro mit Linkvario ).

Die Daten des M-Link Modules sind wohl ausreichend bekannt ( Stöckli und andere ).

Ein Anzapfen der Daten ist aber evt. auch nicht so ungefährlich wie mit Sensoren
rumzuspielen. ( Meine ersten Seriellen Sendeversuche haben die RX7 wohl auch gebeutelt - aber er
ließ sich nicht beirren, das Multimate wurde voll ausgebremst ) .

Beim Display müsste man ja nur die Daten lesen und interpretieren, eigentlich nicht so die Sache.
Ausgabe auf einem Display ist auch nicht so die Problematik, Sprachausgabe eigentlich auch nicht.

Letzteres würde ich aber auf Hilfe eines befreundeten Kollegen zurückgreifen, der das grade macht.
Dafür müsste aber der Pic genug Wumms haben, und wohl Fileformate unterstützen ( Pic24 u.a. ) .

Für das abspielen von Samples gibts auch fertige Routinen.

Aber wie auch im anderen Threat geschrieben: So was ist nicht unbedingt in Foren sinnvoll durchzukauen.

Wenn du eh in der Nähe wohnst, sollte man einfach mal direkten Kontakt aufnehmen.
Löten und Co. muss man eh.

Zudem werde ich aufwendigen Code nicht im Netz verbreiten, erstens ist das auch viel Arbeit, zweitens
wird es von Halbwissenden eh zerrissen, drittens kann man die Zeit eher zum programmieren nutzen.

( Und komerzieller Mißbrauch ist auch nicht ausgeschlossen )

Ich les nur eben oft beim Kaffee in den Foren, sollte ich wohl auch eher reduzieren :D .

Auch die Sensorgeschichte ist bei mir nur Spielerei, mit evt. späterem Nutzen, ich bin ja eh
schon gut versorgt - hab nur die alten ASM Kenntnisse wieder ausgegraben, und es macht auch Spaß ;-) .


Gruß Bernd
 
Moin,

na das erste Problem dürfte sein dem HF-Mlink-Modul die Telemetriedaten zu entlocken.

Das geht nur bei dem für die Evo und hoffentlich denen für Graupner.

Bei letzteren ist dann ein 3 poliger Anschluß mit den Daten. Da kann man dann den MPX-USB-Adapter anstöpseln und erste Erfahrungen sammeln.

Die Eckdaten des Protokolls sind bekannt, MPX gibt sie auf Nachfrage auch raus und schon gehts llos.

Ich frage mich aus meiner Erfahrung nur was Du mit einem Display anfangen willst ? Im Flug ist das so hilfreich wie 2 linke Hände - und auch das piepsen nutzt einem nicht wirklich da man nicht orten kann ob es der eigene Sender ist oder ein anderer. Einzig Sprachausgabe und evtl. Vibratoren sind hier hilfreich wenn man nicht ganz alleine in der Landschaft rumsteht.

Es gibt schon ein Projekt das MPX eine Sprachausgabe näherbringt ( Google ... ) oder halt das käufliche wstech-Vario. Das funktioniert auch mit Graupner Sendern und MPX-Funkstrecke.

Gruß

gecko
 
Moin,

na das erste Problem dürfte sein dem HF-Mlink-Modul die Telemetriedaten zu entlocken.

Das geht nur bei dem für die Evo und hoffentlich denen für Graupner.

gecko
Die HFM-3 Module müssen erst upgedatet werden, das dauert wohl auch noch ( ok wissen alle hier ).
Es sind schon einige inoffiziell so fertig.

Test wäre auch das HFM-4 in ProfiMC zum laufen zu bringen, das könnte evt. gar nicht so
unmöglich sein.

Eine Entwicklung des Modules sollte mit HFM-4 schon mal startbar sein.

( denke nicht das MPX da verschiedene Protokolle macht )

Das MPX auch diese Daten preisgibt wäre mir neu ( es sei den an Profi´s ) .

Bernd

Edit: Ich habe im Grunde ja alles zur Hand, weil P4000 mit HFM-3 und Royal Pro 16 mit HFM-4 in Besitz
 
Einen noch beim Kaffee...

Einen noch beim Kaffee...

Und: Ich verwende Microchip - also darf ich hier nicht mitmachen :D

So Kaffee alle, ich mach mir nen Vanillepudding !

Bernd
 
Hi zusammen,

bin auch am Überlegen, ob das nicht der richtige Job für ein AVR/Display Board wäre, das bei mir seit zwei Jahren in der Schublade rumliegt. OK, wenn's denn das Display sowieso demnächst fertig gäbe hätte das ganze eher nur "sportlichen Charakter" ... aber wer weiß, wann das ist :rolleyes:

Hexenwerk sollte es eigentlich keins sein, das Protokoll zu knacken; ich hab mir mal angeschaut, was mein MC-22 Umbaumodul am COM Port so erzählt. Neben einigen wiederkehrenden Bytefolgen sehe ich da tatsächlich eine 44 ( Staudrucksensor an Adresse 4, zweite 4 für Kmh ?), gefolgt von 00 00; beim reinblasen in den Schlauch steigen die Werte an und gehen danach auf 01 00 runter - würde eigentlich passen ( Vmin Alarm Bit ) .

Nur aus dem restlichen Geflüster werd ich nicht so recht schlau, weiss jemand, ob die Empfängerbatteriespannung ebenfalls quantitativ übertragen wird, oder nur ein Warnsignal ? Dazu hab ich noch keine "passende" Sequenz gefunden - müsste wohl mit 00 anfangen ( Kanal 0 , zweite 0 für V ?).

Gruß
Rudi
 

Gast_7088

User gesperrt
dazwischen

dazwischen

soll der adruino..... der muss die erzähle vom MPX com port in display freundliches strukturiertes gerede umsetzen....
und natürlich noch ein wenig drum rum machen ...... so piepen und erzählen.... aber ich warte aktuell auf die Displays
und überlege wie man das ganz in ein Gehäuse implantiert. Und dann muss noch die Sexy Stimme vom Vario umgesetzt werden ....
oder ein freundliches " he du hast gleich kein saft mehr" oder "dein Motor steht" statt ein Piiiiiiiiieeeep wäre auch cool

aber erstmal die Grundlagen und ja es ist reine Sportlichkeit.....
 
Beim FunJet Heizen wäre so ein briefmarkengroßes LCD wahrscheinlich ziemlich witzlos, seh ich ähnlich. Wie wär's mit nem -> Netzhautprojektor ? :eek:
Dann wirklich lieber eine nette Offstimme ( die Sirius-Kybernetik-Corporation hätte da sicher tolle Ideen :rolleyes: ), für AVR Sprachausgabe gibt's doch bestimmt schon Lösungen, die die Erfindung des Rotationskörpereinsatzes zur Verminderung des Kraftaufwandes beim Lastentransport auf festem Untergrund vorwegnehmen.
 

ubit

User
Hi,

meine Ideen hierzu:

1. Alarmschwellen im Display einstellbar
Finde ich wichtig. Dann muss man nicht immer die Sensoren einzeln umprogrammieren, wenn man die z.B. in ein anderes Modell setzt.

2. Logging
Auf eben dieser Speicherkarte könnte man auch gleich die Telemetriedaten loggen.

3. Modellspeicher
Damit man auf dem Flugplatz zwischen verschiedenen Modellen mit entsprechenden Alarmschwellen umschalten kann.

4. Modellvarianten
Wäre natürlich super, wenn ich für jedes Modell auch noch Varianten speichern und abrufen könnte. Ist ja ein Unterschied, ob ich im Modell gerade einen 3000 mAh oder einen 4000 mAh Akku eingebaut habe. Kann man natürlich auch über unterschiedliche Modellnamen (T-Rex 500 - 3000 mAh, T-Rex 500 - 4000 mAh) regeln - wäre aber komfortabler, wenn man in den Varianten nur gezielt einzelne Werte "überschreiben" könnte. Die Überwachung der Akkuspannung bleibt ja bei allen Varianten auf z.B. 21 V - nur die Kapazitätswarnung ändert sich.

5. Sound- und Sprachausgabe
Finde ich beide wichtig. Werte die Alarm zeigen, sollten dabei besonders prominent dargestellt werden. Z.B. könnten die übrigen Werte "nach unten" rutschen und oben gibt es dann invertiert den Alarmwert. Soundausgabe sollte einstellbar sein, ob sie dauernd wiederholt wird (mit einstellbarem Intervall) oder nur 1x, 2x, 3x ... piepsen/Ansage. Diese Einstellung sollte für jeden Wert getrennt machbar sein, damit ich z.B. bei Überschreiten einer bestimmten Höhe 1x piepsen lasse, bei niedriger Akkuspannung 3x piepsen + Sprachansage. Statt "piepsen" dürfen es auch gerne "Samples" sein die man via PC selbst aufspielt oder auf der Speicherkarte ablegt (Windows Alert-Sound beim Auslösen des Aufschlagsensors...).

6. Man sollte auch - wie z.B. beim Picolario talk - eine regelmäßige Ansage programmieren können. Zum Beispiel: Alle 500 mAh entnommener Kapazität => Sprachansage oder alle 50 m Höhe => Sprachansage (also bei 50 m, 100 m, 150 m, 200 m...).

7. Kopfhöhreranschluss
Natürlich - man will ja auf dem Platz nicht als akustischer Umweltverschmutzer gelten.

8. Alarmfunktion bei Übertragungsfehler
Wenn eine (einstellbare) Zeit lang ein Wert nicht übertragen wird, wird ebenfalls akustisch Alarm ausgelöst. Sonst merkt man ja nicht, wenn z.B. der Stromsensor plötzlich ausfällt (muss ja nur ein Wackelkontakt sein).

9. Faktoren/Maßeinheiten
Insbesondere für den Drehzahlsensor. Multiplex überträgt Drehzahlen offenbar nur in 100er Schritten. Das ist für den Heli eher mager. Es sei denn, man überträgt die Motordrehzahl und rechnet erst im Display das Untersetzungsverhältnis dazu. Dazu müsste man den Telemetriewert nur um einen Faktor x multiplizieren. Das kann man dann natürlich auch direkt nutzen um unabhängig von der Einstellung des Sensors zwischen °C und °F, Metern und Fuß, m/s und km/h etc. umschalten zu können.

Das Display wäre bei diesem Konzept natürlich vor Allem für die Einstellerei nützlich. Und im Alarmfall für einen schnellen Blick auf's Display um zu schauen, was für ein Alarm das war (kann natürlich dann auch der Copilot machen).

Nett wäre noch, wenn man das Display auch drahtlos an den Sender koppel könnte - aber das ist ja nur eine Umsetzung seriell->Irgendwasfunk. Dann könnte der Copilot das Teil ablesen.

Insgesamt also weniger ein Telemetrie-Display als mehr ein universeller Telemetrieempfänger.

Ich wäre an dem Projekt sehr interessiert, habe aber keine Erfahrung mit Adruino. Allerdings bin ich Softwareentwickler von Beruf und traue mir durchaus zu an der Software mitzuwerkeln. Löten kann ich natürlich auch *g* Ich habe im Moment eine Cockpit SX und keinen einzigen Multiplex-Sensor - "nur" das Unilog mit Temperatur, Höhe, Drehzahl und Stromsensor. Im Moment noch Unilog 1 - ich plane aber ein Upgrade auf Unilog 2 (gut, dann bräuchte ich die Logfunktion nicht mehr).

Ciao, Udo
 
Moin Udo,

abgesehen das es so ein ähnliches Gerät ( bis auf die Drehzahlmessung ) schon zu kaufen gibt - ich erwähnte es in dem anderen Thread schon mal - wäre mein Tip für einen Softwareentwickler sich

a) ein Bluetooth - Modul das SSP kann - können aber viele und ist preiswert ( 10 - 20 € )

b) ein Android Handy oder Tablet - gibt es auch schon für lau

zu kaufen.

Mit dem Android ist alles was Du oben angeregt hast möglich. Es hat sogar eine Sprachsynthese. Graphisches Display, Wlan und noch vieles mehr. Nur Java muß man halt können. Und mögen ;)

Software zum entwickeln ist umsonst.

Aber wenn es denn Arduino sein soll - nur zu. Das ist ein sehr einfacher und leichter Zugang zum programmieren von MicroControllern. Sehr ähnlich zu C++. Aber auf das wesentliche beschränkt da der Platz für Programme und RAM sehr knapp ist.

Gruß

gecko
 

ubit

User
Android tablet für lau? Wo? *g*

Nö. Smartphone und/oder Tablet ist zu schwer und unhandlich. Und der Reiz bei so einem Projekt liegt ja nicht nur in der Funktionalität die man damit erreicht, sondern auch im Spaß beim "machen". Ich bin schließlich auch nicht nur Modellflieger, sondern auch Modellbauer;-)

Ciao, Udo
 

ubit

User
Hi zusammen,

ich will das Thema jetzt doch mal angehen. Und zwar mit einem Arduino. Den habe ich mir gestern bestellt. Samt Display, Joystick, Buzzer und SD-Cardreader. Mal schauen, ob und wie das alles zusammenpasst. Und vor Allem, wie viel "Logik" man mit dem kleinen Controller realisieren kann, wenn da noch die Bibliotheken für das Display, die serielle Schnittstelle und den Cardreader rein müssen.

Ein erstes grobes Konzept habe ich mir auch schon gebastelt. Den SD-Reader brauche ich, weil der EEProm im 328 für meine Zwecke einfach zu klein ist. Zunächst werde ich auf Sprachausgabe verzichten und versuchen die Alarme durch unterschiedliche Töne unterscheidbar zu machen. Das Konzept beinhaltet aber bereits eine Option auf eine wie ich finde recht universelle Sound- und Sprachausgabe. Das dürfte im 328er Chip allerdings sehr eng werden. Notfalls könnte man einen zweiten Arduino als reine "Audiomaschine" ankoppeln z.B. mit dem WaveHC-Modul. Weiß jemand, ob man damit mehrere Samples einigermaßen unterbrechungsfrei hintereinander abspielen kann? MP3 Breakout wäre auch eine Option. In beiden Fällen würden die Sounds auf einer SD-Karte abgelegt und bei Bedarf nur abgespielt - bzw. für die Sprachausgabe zusammengebastelt (also auch nur hintereinander abgespielt).

Meine Cockpit SX habe ich heute auch einfach mal aufgeschraubt. Wenn - wie Multiplex das ja in den Neuheitenprospekten angibt - das Telemetrie-Display auch an der Cockpit SX angeschlossen werden kann, dann gibt es dafür nur 2 Möglichkeiten:

Entweder via Din-Buchse
Dann bräuchte das MPX-Display einen Adapter und die Cockpit wohl eine Firmwareänderung

Oder über die 3 Pinne die in der Cockpit SX prominent aus der M-Link-Platine ragen. Ein Pin davon ist leicht als Masse zu identifizieren. Die beiden übrigen Pins zeigen am Multimeter ca. 3,3 Volt. Oszi hab' ich leider keins :-( Ich vermute aber mal, dass der äußere Pin - wenn man die Kabelfarben des MPX-Display anschaut - Masse und Signal sind. DIe Baudrate soll wohl nach einigen Berichten im Netz bei 115200 Bd liegen? Zumindest bei den Royal-Sendern. Der mittlere Pin wäre dann als Stromversorgung für das Display möglich. Oder als "Rückkanal" für die serielle Kommunikation. Weiß da jemand Näheres?

Die Ansteuerung von Display, die Aufbereitung der Daten, Entwurf und Implementierung einer brauchbaren Benutzeroberfläche traue ich mir zu. Bei der Ankopplung an die Cockpit habe ich Bauchschmerzen. Wenn da jemand vielleicht schon was Fertiges für den Arduino hat, wäre das natürlich super.

Mein "Arduino" wird wohl mit 3,3 Volt laufen (ist eine umschaltbare Version 3,3/5V) und scheint damit wunderbar zu den Pegeln an den 3 Pins zu passen. Ergo brauche ich vermutlich nicht mal irgendwelche Hardware um das Ding an die Cockpit anzuschließen. Ganz naiv stelle ich mir vor, dass ich nur Masse + Signal einfach verbinde.

Als Display habe ich zunächst mal eine absolute Billigversion genommen: Nokia 5110 mit 84 x 48 Pixeln. Damit sind locker 4 Zeilen mit 14 Zeichen drin. Genug Platz für
1. 5 Zeichen langer "Name" des Telemetriewertes (Alti, Speed, Recv., Lipo1, Lipo2 etc.)
2. 5 Zeichen langer Wert
3. 4 Zeichen lange Einheit (mAh, V, A, rpm, m, km/h, m/s, feet...)

Da das Display während des Flugs ohnehin nicht wirklich ablesbar sein muss, könnte man sogar bei der geringen Größe bleiben. Alternativ ließen sich im Alarmfall der "dringendste" Alarm auch formatfüllend anzeigen (oder er nutzt 2 Zeilen, womit man 2 "dringende" Alarme gleichzeitig anzeigen könnte.

Im Moment arbeite ich mich in die Arduino doku ein. Schaut ja alles sehr, sehr simpel aus. Ich freu' mich schon auf's Basteln. Nächste Woche soll es ja noch saukalt sein...

Ciao, Udo
 

Gast_7088

User gesperrt
AVR

AVR

und ich mich auf dein Fluchen... :)

selbst mit dem klein die aufgabe lösbar...
so wohl in Speed als auch in Code grösse
Tonausgaben geht einfacher von der Hardware ---- sei denn du braucht dolby suround :rolleyes:

Und ich weis ned was du das alles aberlegen willst aber im 328 ist genug raum ... und die sd benötigt man max für die Sampels
 
Pin´s

Pin´s

Ja, 115KBaud, 3 Pins am Comport, Mitte ist + Spannung eine Seite ist GND, die andere Serielles Signal.
Das wird auch bei der Cockpit so sein, weil das Display ja wohl an allen funktioniert.

Evt. musst du aber auch ein Firmwareupdate abwarten, bis dor Signale kommen.

Bernd
 

ubit

User
und ich mich auf dein Fluchen... :)

selbst mit dem klein die aufgabe lösbar...
so wohl in Speed als auch in Code grösse
Tonausgaben geht einfacher von der Hardware ---- sei denn du braucht dolby suround :rolleyes:

Und ich weis ned was du das alles aberlegen willst aber im 328 ist genug raum ... und die sd benötigt man max für die Sampels
Fluchen? Warum? Etwas Erfahrung mit PICs habe ich noch von früher. Gekauft habe ich einen Iteaduino v2.1.

Und den Platz brauche ich für die "Modellspeicher". Ich will in dem Ding mindestens so viele Konfigurationen speichern können wie die Cockpit SX Modellspeicher hat. Dazu dann für jedes "Modell" unterschiedliche Varianten für z.B. verschiedene Akkugrößen mit entsprechenden Warnschwellen.

Allein für die Konfiguration der Alarme werde ich einige Dutzend Bytes verbraten. Die Alarme sollen sehr weitgehend konfigurierbar sein. Insbesondere im Bezug auf eine spätere Sprachausgabe will man ja nicht unnötig vollgequatscht werden, sondern es sollen nur die Infos gesprochen werden an denen man auch interessiert ist. Also soll man z.B. folgendes einstellen können:

Beginnend bei 0 soll alle 500 mAh ein "Pieps" kommen.
Bei 2000 mAh soll eine Sprachausgabe "Akkuwarnung" ausgegeben werden.
Ab 2000 mAh alle 100 mAh ein Piep
Bei 2400 mAh Sprachausgabe "Akku leer"
Bei 2600 mAh soll der Sound "Alarmstufe rot" abgespielt werden

Wenn man das alles einigermaßen konfigurierbar macht, braucht man halt ein paar Bytes pro Sensor (obiges Beispiel braucht schätzungsweise 15-20 Byte). Dazu noch die Benennung von Sensorwert und die Einheit (über das von MPX vorgesehene hinaus) sowie ein Umrechnungsfaktor (float, 4 Byte) um z.B. die Geschwindigkeit wahlweise in m/s oder in km/h anzeigen zu können.

Zusammen für einen Sensor:
15 bis 20 Byte für die Warnungen
5 Byte Benennung
4 Byte Einheit (ok - könnte man auf Kosten der Flexibilität kürzen)
4 Byte Umrechnungsfaktor

Macht schonmal 28-32 Bytes. Bei nur 4 angeschlossenen Sensoren sind das dann schnell grob 100 Bytes. Modellname 8 Byte. 2 Modellvarianten mit unterschiedlichen Warnschwellen (+40 Byte) + Name der Variante (8 Byte). Da ist man zusammen schon bei 160 Byte bei nur teilweiser Nutzung der Möglichkeiten.

1024 Bytes EEProm hab' ich beim 328, oder? Reicht dann für 6 Modellspeicher... Und wenn man "spielen" will und mehr Alarme/Info möchte, wächst das schnell weiter. Ergo: Modellspeicher auf die SD-Karte. Da lassen die sich dann später mit einem PC-Programm auch komfortabel verwalten und die Anzahl der "Modellspeicher" ist fast unbegrenzt.

Ciao, Udo

P.S.: Das mit dem Firmwareupdate kann natürlich sein. Das muss dann aber eh bald kommen. Das Display wird doch Ende Februar/Anfang März ausgeliefert, oder? Wobei ich ja "den Rest" schon mal programmieren kann. Ist genug "Arbeit" (Vergnügen)
 

ubit

User
Hi zusammen,

jetzt habe ich mir mal mein Geraffel vorgenommen und versucht mit dem PC Daten zu "erlauschen". Am Empfänger war das auch gar kein Problem. Wie bereits anderswo beschrieben wurde, fragt der Empfänger den MSB regelmäßig ab (alle Adressen). Seltsam fand ich nur, dass der Empfänger auf Adresse 1 sich "selbst antwortet" - er überträgt den LQI-Wert auf den Sensorbus. Mit der Empfängerspannung macht er das nicht.

An der Cockpit SX komme ich leider so einfach nicht weiter. Ich habe mal versucht dort "mitzuhören", aber wenn ich das USB-Interface auf die 3 Kontakte stecke, startet die Cockpit SX nicht mehr. Stecke ich das Interface nach dem Start drauf, passiert auch nix - keine Daten. Wobei mich die "Startverweigerung" etwas beunruhigt...

Entweder "wasimmer" man dort anschließt muss sich zum Start irgendwie "melden" oder der Anschluss ist nicht so belegt wie ich mir das gedacht habe (außen Signal + Gnd). Weiß da jemand mehr?

Inzwischen habe ich mir mit dem Arduino System beschäftigt und Zeichensätze "entworfen" für die Darstellung auf dem Display. Erste Tests mit der Programmlogik habe ich erstmal mit php gemacht und dafür auch einen "Simulator" für das Display geschrieben. Das ist nicht gar so einfach, weil ich das Ding nicht - wie eigentlich vorgesehen - mit 6 Zeilen sondern nur mit 4 Zeilen nutzen möchte (die dann halt 12 statt 8 Pixel hoch sind). Damit kann ich die Zahlenwerte deutlich hervorheben (größerer Zeichensatz) und die "Belanglosigkeiten" (Einheiten, Sensorbezeichnung) etwas weniger prominent darstellen. Hier mal ein Draft wie sowas dann auf 84x48 Pixeln aussehen könnte:

Aufzeichnen.JPG

Die Zahlenwerte werde ich wohl noch rechtsbündig formatieren oder zentriert setzen. Muss ich mal schauen. Prinzipiell wäre es mit diesem Display auch möglich 6 Telemetriewerte pro Bildschirmseite darzustellen. Das wird mir persönlich dann allerdings zu klein.

Ciao, Udo
 
... Seltsam fand ich nur, dass der Empfänger auf Adresse 1 sich "selbst antwortet" - er überträgt den LQI-Wert auf den Sensorbus. Mit der Empfängerspannung macht er das nicht.
Kann evtl aus der Zusammenarbeit mit SM kommen - für das Unilog war angekündigt das alle Adressen des MSB im Modell geloggt werden können. Wieso jetzt wieder die RX-Spannung nicht verstehe ich aber auch nicht. Ist der RX auf dem neuesten Stand ?

An der Cockpit SX komme ich leider so einfach nicht weiter. Ich habe mal versucht dort "mitzuhören", aber wenn ich das USB-Interface auf die 3 Kontakte stecke, startet die Cockpit SX nicht mehr. Stecke ich das Interface nach dem Start drauf, passiert auch nix - keine Daten. Wobei mich die "Startverweigerung" etwas beunruhigt...

Entweder "wasimmer" man dort anschließt muss sich zum Start irgendwie "melden" oder der Anschluss ist nicht so belegt wie ich mir das gedacht habe (außen Signal + Gnd). Weiß da jemand mehr?
...
Software Updates bei meiner 35MHz SX gehen über die Schnittstelle auf der Multifunktionsbuchse. Versuch mal die plus-Leitung abzuklemmen und einen Widerstand in die Signalleitung zu setzen. Kann aber auch gut sein das für die SX erst noch ein Update erforderlich ist.

Gruß

gecko
 

ubit

User
Hi,

jo. War ein RX-5 mit Firmware 1.20. Mehr geht laut Launcher nicht ;-) Der Sender ist auch auf dem aktuellen Firmwarestand.

Ich hab' leider kein Oszilloskop und bin was die Nutzung der Schnittstelle im Sender anbetrifft weitgehend auf Vermutungen angewiesen und auf die Ergebnisse Anderer mit besserer Hardwareausstattung :-(

Müsste halt mal jemand mit einer "nativen M-Link Cockpit SX" nachschauen bzw. durchmessen. Kann gut sein, dass ich da noch mit Widerständen arbeiten muss und ggf. auch noch 'ne Diode brauche wie das beim MSB im Empfänger ja wohl auch ist. *grummel* Hoffentlich liefert Multiplex das Display bald aus - spätestens dann muss ja das Update rauskommen, falls eines benötigt wird.

Eventuell kann ich ja den Arduino auch zur "Signalanalyse" einsetzen. Der hat ja einige analoge Eingänge.

Ciao, Udo
 
versuch mal:

versuch mal:

Irgendwas war mit niederomig beim Einschalten = programmiermodus zum flashen des Modul´s.
Cockpit hatte ich heute nicht unter den Fingern, war mir einfach zu kalt das Auto deshalb
freizumachen.

Evt. also mal mit Widerständen in der Leitung testen.

Oder etwas Geduld...

Bernd
 
Oben Unten