Treffpunkt DIY Multiplex Sensor-Entwickler (und die es werden wollen)
- Ersteller ingo_s
- Erstellt am
Reinhardt Werbik
User
Eine Bridge vom Jeti Sensorprotokoll auf den MSB ist ein interessanter Gedanke.
Die Jeti Sensoren wären natürlich eine Super-Ergänzung zum M-Link System, und das Protokoll ist ja auf der Jeti Homepage downloadbar.
Mal sehen, wenn mein Demonstrator mal läuft, vielleicht befasse ich mich ja mit diesem Thema, statt eigene Messroutinen zu basteln.
Diese gibt es ja schon von diversen Modellbaukollegen, z.B. von Ingo.
Mal schauen ob es Atmels mit zwei HW USARTs gibt.
Gruß
Reinhardt
Die Jeti Sensoren wären natürlich eine Super-Ergänzung zum M-Link System, und das Protokoll ist ja auf der Jeti Homepage downloadbar.
Mal sehen, wenn mein Demonstrator mal läuft, vielleicht befasse ich mich ja mit diesem Thema, statt eigene Messroutinen zu basteln.
Diese gibt es ja schon von diversen Modellbaukollegen, z.B. von Ingo.
Mal schauen ob es Atmels mit zwei HW USARTs gibt.
Gruß
Reinhardt
geilerflieger
User
Tanksensor
Tanksensor
So einen Adapter von der Jeti Sensorik zu MSB hätte ich auch gerne!!!
Melde hiermit verbindlich Interesse an!
Siehe auch Post 2, 4, 8 usw.. zum Thema Tanksensor, da warte ich schon sehr lange auf was brauchbares...
Bei meinem Schlepper (Bulli von Vogt) ist der Rumpf geschlossen, ich kann von außen nicht einmal erahnen wieviel Sprit noch drin ist....
Bitte dranbleiben!
Grüße,
Stefan
Tanksensor
So einen Adapter von der Jeti Sensorik zu MSB hätte ich auch gerne!!!
Melde hiermit verbindlich Interesse an!
Siehe auch Post 2, 4, 8 usw.. zum Thema Tanksensor, da warte ich schon sehr lange auf was brauchbares...
Bei meinem Schlepper (Bulli von Vogt) ist der Rumpf geschlossen, ich kann von außen nicht einmal erahnen wieviel Sprit noch drin ist....
Bitte dranbleiben!
Grüße,
Stefan
Reinhardt Werbik
User
Also ich habe mir jetzt mal das Protokoll der Jeti Telemetrie-Übertragung ein wenig angeschaut.
Ich fürchte, den Umsetzer auf MSB kann man knicken, wenn ich das richtig sehe.
Das Jeti Protokoll ist erst einmal ziemlich unorthodox (9 Datenbits, 2 Stoppbits, Parity).
Aber was das ganze wohl zum Scheitern verurteilt ist die Tatsache, dass den Daten keine Werteklassen zu Grunde liegen.
Es werden nur Vorzeichen, Stelle des Dezimalpunktes und Zahlenwerte übertragen.
Es ist somit nicht ohne weiteres möglich, herauszufinden, welche Größe da eigentlich übertragen wird.
Erst mit dem immer mit übertragenen Text-Paket wird ein Sinn aus dem Ganzen, z.B. für die Anzeige auf der Jeti-Box.
Tja, da werde ich mich dann doch lieber dem Basteln von Sensoren für den MSB widmen.
Gruß
Reinhardt
Ich fürchte, den Umsetzer auf MSB kann man knicken, wenn ich das richtig sehe.
Das Jeti Protokoll ist erst einmal ziemlich unorthodox (9 Datenbits, 2 Stoppbits, Parity).
Aber was das ganze wohl zum Scheitern verurteilt ist die Tatsache, dass den Daten keine Werteklassen zu Grunde liegen.
Es werden nur Vorzeichen, Stelle des Dezimalpunktes und Zahlenwerte übertragen.
Es ist somit nicht ohne weiteres möglich, herauszufinden, welche Größe da eigentlich übertragen wird.
Erst mit dem immer mit übertragenen Text-Paket wird ein Sinn aus dem Ganzen, z.B. für die Anzeige auf der Jeti-Box.
Tja, da werde ich mich dann doch lieber dem Basteln von Sensoren für den MSB widmen.
Gruß
Reinhardt
Hi,
na so ganz ist das nicht richtig.
Bei Jeti-EX werden zu jedem Sensorwert Name und Einheit übertragen als Texte im EX-Stream. Jeder Wert hat dann Wert und Skalierung.
Dadurch ist die Jeti-Telemetrie einiges fllexibler als MSB. Das was für die JetiBox übertragen wird muß keinen Zusammenhang mit den EX-Daten haben.
Es bleibt das Problem der Zuordnung der Sensordaten zu den Werteklassen des MSB. Diese müßte wohl nahezu für jeden Sensor, evtl. jede seiner Sprachversionen programmiert werden.
Gruß
gecko
na so ganz ist das nicht richtig.
Bei Jeti-EX werden zu jedem Sensorwert Name und Einheit übertragen als Texte im EX-Stream. Jeder Wert hat dann Wert und Skalierung.
Dadurch ist die Jeti-Telemetrie einiges fllexibler als MSB. Das was für die JetiBox übertragen wird muß keinen Zusammenhang mit den EX-Daten haben.
Es bleibt das Problem der Zuordnung der Sensordaten zu den Werteklassen des MSB. Diese müßte wohl nahezu für jeden Sensor, evtl. jede seiner Sprachversionen programmiert werden.
Gruß
gecko
Reinhardt Werbik
User
Hallo gecko,
genau das hatte ich gemeint.
Es wäre natürlich möglich, für einen ganz bestimmten Sensor (z.B. MUI) einen Umsetzer zu machen.
Dieser müsste dann aus den übertragenen Strings für Wert und Einheit die Werteklasse ermitteln.
Ja, und wahrscheinlich muss er auch wissen welche Sprache vorliegt.
Obwohl, wenn man nur auf die Einheit schaut, müsste es theoretisch sprachunabhängig sein.
Jedenfalls, einen universalen Umsetzer für jegliche Jeti-Sensoren, das würde wohl ziemlich
schwierig (und anfällig für Änderungen) sein.
Der MSB wurde halt konsequent als Übertragungsprotokoll für Sensordaten ausgelegt,
während das Jeti-Protokoll zum Übertragen aller möglichen Daten, z.B. Konfigurationsdaten, dient.
Ich hoffe ja, dass MPX hier irgendwann das bestehenden Erweiterungspotential des MSB in diese Richtung nutzt.
Die Sensoren unterstützen ja schließlich die Konfiguration über den MSB, z.B. mit der Multimate.
Gruß
Reinhardt
genau das hatte ich gemeint.
Es wäre natürlich möglich, für einen ganz bestimmten Sensor (z.B. MUI) einen Umsetzer zu machen.
Dieser müsste dann aus den übertragenen Strings für Wert und Einheit die Werteklasse ermitteln.
Ja, und wahrscheinlich muss er auch wissen welche Sprache vorliegt.
Obwohl, wenn man nur auf die Einheit schaut, müsste es theoretisch sprachunabhängig sein.
Jedenfalls, einen universalen Umsetzer für jegliche Jeti-Sensoren, das würde wohl ziemlich
schwierig (und anfällig für Änderungen) sein.
Der MSB wurde halt konsequent als Übertragungsprotokoll für Sensordaten ausgelegt,
während das Jeti-Protokoll zum Übertragen aller möglichen Daten, z.B. Konfigurationsdaten, dient.
Ich hoffe ja, dass MPX hier irgendwann das bestehenden Erweiterungspotential des MSB in diese Richtung nutzt.
Die Sensoren unterstützen ja schließlich die Konfiguration über den MSB, z.B. mit der Multimate.
Gruß
Reinhardt
Hi,
wenn Du nur einen bestimmten Sensor umsetzen willst brauchst du dich um die Strings nicht zu kümmern da die Adressen der einzelnen Werte bisher nicht konfigurierbar sind. Also bei Sensor x kommen zB Ampere immer an Adresse 3. Die Einheit alleine wiederum nutzt dir nichts da sie in einem Sensor mehrfach vorkommen kann - zB Spannungssensor mit 3 Spannungen.
Konfiguriert werden die Sensoren über die JetiBox-Daten, nicht über das EX-Protokoll. Nicht zu verwechseln mit dem EX-Bus - da ist wieder alles anders ...
Gruß
gecko
wenn Du nur einen bestimmten Sensor umsetzen willst brauchst du dich um die Strings nicht zu kümmern da die Adressen der einzelnen Werte bisher nicht konfigurierbar sind. Also bei Sensor x kommen zB Ampere immer an Adresse 3. Die Einheit alleine wiederum nutzt dir nichts da sie in einem Sensor mehrfach vorkommen kann - zB Spannungssensor mit 3 Spannungen.
Konfiguriert werden die Sensoren über die JetiBox-Daten, nicht über das EX-Protokoll. Nicht zu verwechseln mit dem EX-Bus - da ist wieder alles anders ...
Gruß
gecko
Reinhardt Werbik
User
Hallo gecko,
das ist interessant, was Du da sagst. ich nehme mal an, mit Adresse meinst Du den Identifier gemäß Jeti Protokoll.
Das Protokoll schreibt keine bestimmten Identifier vor, diese dienen hier erst mal als Schlüssel zum Verknüpfen von Daten- und Textpaketen.
Wenn aber z.B. bei allen MUIs der Strom, die Spannung, die Kapazität, etc. immer jeweils den gleichen Identifier haben,
könnte man ja darauf aufsetzen und einen Umsetzer für alle MUIs machen, den Text müsste man dann gar nicht auswerten.
Damit erhebt sich natürlich die Frage, welche Identifier sind das genau, hast Du hier nähere Informationen?
Da die MUIs ja auch Min und Max Werte für Strom und Spannung ausgeben, käme man ja schon auf mindestens 7 Identifier, wenn ich richtig gezählt habe.
Wenn man mit einem Umsetzer alle MUIs bedienen könnte, das wäre möglicherweise schon interessant.
Die große Auswahl an MUIs ist nämlich etwas, das ich bei M-Link vermisse.
Gruß
Reinhardt
das ist interessant, was Du da sagst. ich nehme mal an, mit Adresse meinst Du den Identifier gemäß Jeti Protokoll.
Das Protokoll schreibt keine bestimmten Identifier vor, diese dienen hier erst mal als Schlüssel zum Verknüpfen von Daten- und Textpaketen.
Wenn aber z.B. bei allen MUIs der Strom, die Spannung, die Kapazität, etc. immer jeweils den gleichen Identifier haben,
könnte man ja darauf aufsetzen und einen Umsetzer für alle MUIs machen, den Text müsste man dann gar nicht auswerten.
Damit erhebt sich natürlich die Frage, welche Identifier sind das genau, hast Du hier nähere Informationen?
Da die MUIs ja auch Min und Max Werte für Strom und Spannung ausgeben, käme man ja schon auf mindestens 7 Identifier, wenn ich richtig gezählt habe.
Wenn man mit einem Umsetzer alle MUIs bedienen könnte, das wäre möglicherweise schon interessant.
Die große Auswahl an MUIs ist nämlich etwas, das ich bei M-Link vermisse.
Gruß
Reinhardt
Hi,
da kann ich eher nicht weiterhelfen da ich keine MUI's besitze.
Aber wenn du bei den Jeti-DC/DS Besitzern rumfragst und sie dir ein paar Logs zur Verfügung stellen dann hast du alles beisammen was du brauchst. Die Informationen stehen im Klartext in den ersten Zeilen des Logs.
Gruß
gecko
da kann ich eher nicht weiterhelfen da ich keine MUI's besitze.
Aber wenn du bei den Jeti-DC/DS Besitzern rumfragst und sie dir ein paar Logs zur Verfügung stellen dann hast du alles beisammen was du brauchst. Die Informationen stehen im Klartext in den ersten Zeilen des Logs.
Gruß
gecko
PhoniLog
PhoniLog
Liebe Telemetriefans,
ich fliege seit vielen Jahren eine mittlerweile nicht mehr ganz taufrische Graupner MX-22 mit Futaba FASST Modul und bin mit diesem System eigentlich sehr zufrieden.
Als bei Futaba und Graupner Telemetrie noch nicht mal auf Powerpoint Präsentationen in Sicht war, griff ich als E-Kunstflieger zur Selbsthilfe habe eine Bluetooth Verlängerung zwischen Unilog und UniDisplay gebaut:
http://goldeneye.ethz.ch/elektronik/flight_data/btunilog
Vor Kurzem habe ich mir ein UniSense und einen GPS-Logger zugelegt.
Leider zeigten sich nun zwei Probleme:
1. Die Anzeige der Kapaziät am UniDisplay ist viel kleiner und schwerer zu lesen, wenn man das UniSense anschiesst.
2. Wenn man das UniSense mit dem GPS-Logger verbindet, bleibt für das UniDisplay kein Anschluss mehr frei
Also war eine gute Idee gefragt.
Per Zufall bin ich dann auf die iPhone App iMSB http://www.imsb.ch/ gestossen, sowie auf ein Stück Software von
Jochen Tuchbreiter, das einen UniLog Sensor mit mit einem FrySky Sender verbindet (http://fpv-community.de/showthread.php?31352-Telemetrie-Konverter-HOTT-gt-FrSky und https://code.google.com/p/telemetry-convert/ ).
Besonders interessant an Jochen's Konverter ist die Verwendung eines Teensy Moduls http://www.pjrc.com/teensy/index.html . Man kann es mit der Arduino-Entwicklungsumgebung programmieren, aber das Ding ist VIEL leistungsfähiger als der Original-Arduino (ARM ARM Cortex-M4 32 Bit CPU, 3 (!) HW-UARTS, 3.3V).
Mittlerweile habe ich Code, der auf dem Teensy läuft, den UniSense im MSB Modus ausliest und die Daten via WLAN Modul (Roving Networks RN-VX https://www.sparkfun.com/products/10822 ) zum iPhone funkt:
https://www.youtube.com/watch?v=PxBpLRBnDOg
Nun sind wieder ein paar Infos und neue Ideen gesucht:
Vielen Dank für Eure Unterstützung
Wolfgang
PhoniLog
Liebe Telemetriefans,
ich fliege seit vielen Jahren eine mittlerweile nicht mehr ganz taufrische Graupner MX-22 mit Futaba FASST Modul und bin mit diesem System eigentlich sehr zufrieden.
Als bei Futaba und Graupner Telemetrie noch nicht mal auf Powerpoint Präsentationen in Sicht war, griff ich als E-Kunstflieger zur Selbsthilfe habe eine Bluetooth Verlängerung zwischen Unilog und UniDisplay gebaut:
http://goldeneye.ethz.ch/elektronik/flight_data/btunilog
Vor Kurzem habe ich mir ein UniSense und einen GPS-Logger zugelegt.
Leider zeigten sich nun zwei Probleme:
1. Die Anzeige der Kapaziät am UniDisplay ist viel kleiner und schwerer zu lesen, wenn man das UniSense anschiesst.
2. Wenn man das UniSense mit dem GPS-Logger verbindet, bleibt für das UniDisplay kein Anschluss mehr frei
Also war eine gute Idee gefragt.
Per Zufall bin ich dann auf die iPhone App iMSB http://www.imsb.ch/ gestossen, sowie auf ein Stück Software von
Jochen Tuchbreiter, das einen UniLog Sensor mit mit einem FrySky Sender verbindet (http://fpv-community.de/showthread.php?31352-Telemetrie-Konverter-HOTT-gt-FrSky und https://code.google.com/p/telemetry-convert/ ).
Besonders interessant an Jochen's Konverter ist die Verwendung eines Teensy Moduls http://www.pjrc.com/teensy/index.html . Man kann es mit der Arduino-Entwicklungsumgebung programmieren, aber das Ding ist VIEL leistungsfähiger als der Original-Arduino (ARM ARM Cortex-M4 32 Bit CPU, 3 (!) HW-UARTS, 3.3V).
Mittlerweile habe ich Code, der auf dem Teensy läuft, den UniSense im MSB Modus ausliest und die Daten via WLAN Modul (Roving Networks RN-VX https://www.sparkfun.com/products/10822 ) zum iPhone funkt:
https://www.youtube.com/watch?v=PxBpLRBnDOg
Nun sind wieder ein paar Infos und neue Ideen gesucht:
- Erste Reichweitentests vom Balkon aus sehen schlecht aus ...
Wer weiss, welche Reichweite man zwischen einem - in diesem Fall fliegenden - Access Point und einem iPhone erwarten kann. Was kann man tun, damit die Reichweite grösser wird ? Hat jemand schon mal eine WLAN-Repeater auf Flugplatz ausprobiert ? - Frägt der Original-Multiplex Empfänger immer alle MBUS Adressen nacheinander ab, oder checkt das Ding, wo welche Sensoren angeschlossen sind und frägt dann nur mehr die vorhandenen ab ?
- Welche Transceiver ausserhalb des 2.4 GHz Bandes gibt es noch, die man für einen Datenlink (38400 Baud) verwenden kann ?
Vielen Dank für Eure Unterstützung
Wolfgang
Reinhardt Werbik
User
Hallo Wolfgang,
der Empfänger frägt alle 6 ms eine Adresse ab, und zwar reihum immer alle.
Er prüft nicht, was am Bus alles angeschlossen ist.
Gruß
Reinhardt
Der Teensy 3.0 + 3.1 kann eigentlich 9 Bit.
http://pjrc.com/teensy/teensy31.html#specs
http://forum.pjrc.com/threads/23873-serial-9-bit-on-the-t3/page2
Allerdings, weiss ich nicht, ob man 2 Stoppbits verwenden kann.
Aus der Jeti-Doku:
"Physical layer
Communication is realized by serial asynchronous interface (UART) in a half-duplex mode. Communication speed 9600-9800 Baud
Number of data bits 9
Number of stop bits 2
ODD parity"
Der Teensy 3.1 ist der Arduino, den ich mir schon immer gewünscht hatte
Gruss, Wolfgang
geilerflieger
User
Tanksensor
Tanksensor
Mit diesem Sensor http://www.conrad.de/ce/de/product/150391/Durchflussmesser-Flow-Meter-FCH-m-POM-LC-001-35-lmin-BIO-TECH-eK-FCH-m-POM-LC-mit-Duese-1-mm-001-10-lmin müsste doch so etwas machbar sein. 2500 Impulse / Liter. Bei einem 1 Liter Tank, müsste mann dann die "Elektronik" rückwerts Zählen lassen....
Dann die Ausgabe in Prozent, oder eben in "Verbrauchten ml"..
Wenn das hier jemend umsetzen könnte, interesse besteht wohl bei einigen hier...
Ich kanns leider nicht..
Grüße aus (derzeit beruflich) Riga,
Stefan
Tanksensor
Mit diesem Sensor http://www.conrad.de/ce/de/product/150391/Durchflussmesser-Flow-Meter-FCH-m-POM-LC-001-35-lmin-BIO-TECH-eK-FCH-m-POM-LC-mit-Duese-1-mm-001-10-lmin müsste doch so etwas machbar sein. 2500 Impulse / Liter. Bei einem 1 Liter Tank, müsste mann dann die "Elektronik" rückwerts Zählen lassen....
Dann die Ausgabe in Prozent, oder eben in "Verbrauchten ml"..
Wenn das hier jemend umsetzen könnte, interesse besteht wohl bei einigen hier...
Ich kanns leider nicht..
Grüße aus (derzeit beruflich) Riga,
Stefan
Hi,
die Umsetzung ist kein Problem, der Sensor muss nur wirklich für die geringen Mengen geeignet sein. Ausprobieren ist also angesagt.
Wenn mir jemand so einen Sensor zur Verfügung stellt, bin ich gerne bereit einen meiner Sensoren auf das Zählen der Durchfluss-Impulse anzupassen und eine entsprechende MSB Ausgabe der verbrauchten Menge zu machen.
Ich habe da keine Verwendung für, da ausschließlich E-Flieger.
Gruß Ingo
die Umsetzung ist kein Problem, der Sensor muss nur wirklich für die geringen Mengen geeignet sein. Ausprobieren ist also angesagt.
Wenn mir jemand so einen Sensor zur Verfügung stellt, bin ich gerne bereit einen meiner Sensoren auf das Zählen der Durchfluss-Impulse anzupassen und eine entsprechende MSB Ausgabe der verbrauchten Menge zu machen.
Ich habe da keine Verwendung für, da ausschließlich E-Flieger.
Gruß Ingo
geilerflieger
User
Hallo Ingo,
ich stelle sehr gerne den Durchflusssensor zur Verfügung... melde mich per PN bei Dir wegen Adressenaustausch...
Melde mich wieder,
Stefan
ich stelle sehr gerne den Durchflusssensor zur Verfügung... melde mich per PN bei Dir wegen Adressenaustausch...
Melde mich wieder,
Stefan
geilerflieger
User
Hallo Ingo,
hab nochmal ein wenig Nachgelesen...
Dieser ist noch genauer:
http://www.conrad.de/ce/de/product/155374/?insert_kz=VQ&hk=SEM&WT.srch=1&WT.mc_id=google_pla&gclid=CNuSsdOtvbwCFcHhcgodry8AvA
10500 Impulse / Liter
Hat auch eine erstaunliche ähnlichkeit mit dem Jeti Sensor
Ingo, hast gleich ne PN
Stefan
hab nochmal ein wenig Nachgelesen...
Dieser ist noch genauer:
http://www.conrad.de/ce/de/product/155374/?insert_kz=VQ&hk=SEM&WT.srch=1&WT.mc_id=google_pla&gclid=CNuSsdOtvbwCFcHhcgodry8AvA
10500 Impulse / Liter
Hat auch eine erstaunliche ähnlichkeit mit dem Jeti Sensor
Ingo, hast gleich ne PN
Stefan
Für die Benziner-Flieger / Schleppiloten bahnt sich jetzt zumindest eine Tank-Pegel Überwachung an.
Die Pegelmessung erfolgt über einen neben dem Tank angebrachten Schlauch, der den Tank-Pegel widerspiegelt und an dem spezielle Schlauch-Gabellichtschranken angegbracht sind.
Versuche mit zwei 6,3mm Lichtschranken und passendem Tygon Schlauch und 2Takt-Sprit haben gezeigt, das zwischen vollem und leerem Schlauch eine ausreichend große Stromänderung des analog Signals vorhanden ist um den Zustand zu erkennen.
Als nächstes werde ich auf Basis einer vorhandenen Leiterplatte mal einen Test-Sensor aufbauen.
Gruß Ingo
Die Pegelmessung erfolgt über einen neben dem Tank angebrachten Schlauch, der den Tank-Pegel widerspiegelt und an dem spezielle Schlauch-Gabellichtschranken angegbracht sind.
Versuche mit zwei 6,3mm Lichtschranken und passendem Tygon Schlauch und 2Takt-Sprit haben gezeigt, das zwischen vollem und leerem Schlauch eine ausreichend große Stromänderung des analog Signals vorhanden ist um den Zustand zu erkennen.
Als nächstes werde ich auf Basis einer vorhandenen Leiterplatte mal einen Test-Sensor aufbauen.
Gruß Ingo
Reinhardt Werbik
User
Hallo zusammen,
nachdem das Projekt eine Zeit lang vor sich hingedümpelt ist, gibt es jetzt eine erste kleine Erfolgsmeldung.
Ich habe als erste Übung mal das einfache Jeti Textprotokoll auf dem alten 8er ATmega implementiert.
Und siehe da, nach der Beseitigung eines kleinen Fehlers im Assemblerprogramm konnte ich einen von mir definierten Text auf der Jetibox erscheinen lassen.
Aber das Thema hier ist ja M-Link, daher habe ich diese Zwischenübung zu den Akten gelegt.
Mit den mittlerweile von Reichelt gelieferten ATmega88 habe ich dann heute tatsächlich meinen M-Link Demo-Sensor dazu bringen können,
über einen RX-5 die Werte für Spannung, Strom und Kapazität auf dem Display meiner Royal Pro anzeigen zu lassen.
Das Interrupt gesteuerte Senden hatte ich ja schon mit der Jetibox Demo getestet, jetzt kam also das Empfangen und Auswerten der Masterabfrage vom Rx dazu.
Im Prinzip hätte das ganze auf Anhieb funktioniert, wenn, ja wenn nicht der ATmega88 im Vergleich zum 8er eine zusätzliche Fuse hätte.
Mit dieser lässt sich ein Vorteiler für den externe Takt aktivieren, und dummerweise ist diese Fuse im Lieferzustand des uC programmiert.
Damit hat natürlich die konfigurierte Baudrate des USART überhaupt nicht gepasst, sprich sie war viel zu niedrig.
Durch Auskommentieren des Programmcodes zum Prüfen ob eine gültige Masteranfrage vorliegt, konnte ich das Programm zwar dazu bewegen,
eine Antwort auf dem MSB zu schicken, aber mit dem Oszi war schnell klar ersichtlich, dass die Baudrate viel zu klein war.
Durch nochmaliges Nachlesen im Datenblatt bin ich dann schließlich auf die Geschichte mit der zusätzlichen Fuse gekommen.
Und nachdem ich diese abgewählt hatte, erschienen prompt die Sensorwerte auf dem Royal Pro Display.
Wahrscheinlich werde ich jetzt erst mal mit konventionellen Bauteilen einen echten Spannungssensor aufbauen.
(Obwohl mir Ingo seine letzten SMD Sensorplatinen günstig überlassen hat, aber das SMD Löten schiebe ich noch ein klein wenig auf.)
Danach könnte man sich vielleicht doch dem Thema Jeti/M-Link Interface zuwenden, um die ganzen schönen MUIs nutzen zu können.
Es gibt mittlerweile einen neuen ATtiny mit zwei HW USARTs, und da nur wenige externe Bauteile nötig wären,
könnte man ein solches Interface wahrscheinlich direkt ins Verbindungskabel zum Rx integrieren.
Ich habe mir mal vorsichtshalber zwei ATmega 324 mitbestellt, die ebenfalls zwei HW USARTs haben.
Diese kann ich auf meinem STK500 Entwicklungs-Board betreiben und damit die Firmware entwickeln.
Die neuen ATtinys sind hier noch nicht erhältlich, aber das Programm ließe sich später sicher relativ einfach portieren.
Mal sehen, wie viel Zeit ich in den nächsten Wochen für die Geschichte aufbringen kann, um weiterzukommen.
Die Flugsaison hat ja am Wochenende auch schon wieder begonnen.
Grüße und bis dann
Reinhardt
nachdem das Projekt eine Zeit lang vor sich hingedümpelt ist, gibt es jetzt eine erste kleine Erfolgsmeldung.
Ich habe als erste Übung mal das einfache Jeti Textprotokoll auf dem alten 8er ATmega implementiert.
Und siehe da, nach der Beseitigung eines kleinen Fehlers im Assemblerprogramm konnte ich einen von mir definierten Text auf der Jetibox erscheinen lassen.
Aber das Thema hier ist ja M-Link, daher habe ich diese Zwischenübung zu den Akten gelegt.
Mit den mittlerweile von Reichelt gelieferten ATmega88 habe ich dann heute tatsächlich meinen M-Link Demo-Sensor dazu bringen können,
über einen RX-5 die Werte für Spannung, Strom und Kapazität auf dem Display meiner Royal Pro anzeigen zu lassen.
Das Interrupt gesteuerte Senden hatte ich ja schon mit der Jetibox Demo getestet, jetzt kam also das Empfangen und Auswerten der Masterabfrage vom Rx dazu.
Im Prinzip hätte das ganze auf Anhieb funktioniert, wenn, ja wenn nicht der ATmega88 im Vergleich zum 8er eine zusätzliche Fuse hätte.
Mit dieser lässt sich ein Vorteiler für den externe Takt aktivieren, und dummerweise ist diese Fuse im Lieferzustand des uC programmiert.
Damit hat natürlich die konfigurierte Baudrate des USART überhaupt nicht gepasst, sprich sie war viel zu niedrig.
Durch Auskommentieren des Programmcodes zum Prüfen ob eine gültige Masteranfrage vorliegt, konnte ich das Programm zwar dazu bewegen,
eine Antwort auf dem MSB zu schicken, aber mit dem Oszi war schnell klar ersichtlich, dass die Baudrate viel zu klein war.
Durch nochmaliges Nachlesen im Datenblatt bin ich dann schließlich auf die Geschichte mit der zusätzlichen Fuse gekommen.
Und nachdem ich diese abgewählt hatte, erschienen prompt die Sensorwerte auf dem Royal Pro Display.
Wahrscheinlich werde ich jetzt erst mal mit konventionellen Bauteilen einen echten Spannungssensor aufbauen.
(Obwohl mir Ingo seine letzten SMD Sensorplatinen günstig überlassen hat, aber das SMD Löten schiebe ich noch ein klein wenig auf.)
Danach könnte man sich vielleicht doch dem Thema Jeti/M-Link Interface zuwenden, um die ganzen schönen MUIs nutzen zu können.
Es gibt mittlerweile einen neuen ATtiny mit zwei HW USARTs, und da nur wenige externe Bauteile nötig wären,
könnte man ein solches Interface wahrscheinlich direkt ins Verbindungskabel zum Rx integrieren.
Ich habe mir mal vorsichtshalber zwei ATmega 324 mitbestellt, die ebenfalls zwei HW USARTs haben.
Diese kann ich auf meinem STK500 Entwicklungs-Board betreiben und damit die Firmware entwickeln.
Die neuen ATtinys sind hier noch nicht erhältlich, aber das Programm ließe sich später sicher relativ einfach portieren.
Mal sehen, wie viel Zeit ich in den nächsten Wochen für die Geschichte aufbringen kann, um weiterzukommen.
Die Flugsaison hat ja am Wochenende auch schon wieder begonnen.
Grüße und bis dann
Reinhardt
