Treffpunkt DIY Multiplex Sensor-Entwickler (und die es werden wollen)

Hallo zusammen,

es ist vollbracht, mein erster M-Link "Sensor" funktioniert und kann eine Spannung bis 25,5 V messen.
Zum Einbau in ein Flugmodell ist das ganze aber noch nicht wirklich geeignet: :D

IMG_8000 (800x600).jpg

Als nächstes also jetzt den Spannungssensor (in konventioneller Bauweise) aufbauen und im Modell testen.
Danach werde ich dann das Thema SMD angehen, damit ich Ingo's schöne Platinen verarbeiten kann.
Die Firmware muss ich dazu noch um die Kleinigkeit einer Strom- und Kapazitätsmessung erweitern.;)

Zum Thema Jeti/M-Link Bridge ist mir übrigens noch ein sehr guter Grund eingefallen, so etwas umzusetzen.
Und zwar könnte man dann ja auch die telemetriefähigen Jeti Regler für M-Link nutzen, das hätte schon was.

Bisher war es übrigens überhaupt kein Problem, die Firmware in Assembler zu machen.
ich würde sogar behaupten, dass bei dem was bisher zu programmieren war der Assembler Code übersichtlicher ist als ein entsprechendes C-Programm.
Und die Hardware der Atmels kenne ich dadurch mittlerweile auch recht gut.
Meine Empfehlung an Interessierte ist nach wie vor, mit Assembler in die uC Programmierung einzusteigen.


Gruß
Reinhardt
 

ingo_s

User
Hallo Reinhardt,

Das sieht ja schon mal gut aus. Hattest Du schon Zeit am Projekt weiter zu machen?

Wie Du schon anmerkst, sollte man die AVR Hardware schon recht genau kennen, Fallen gibt es genug.
Grundkenntnisse in Assembler sind meiner Erfahrung nach ausreichend, um in "C" zu programmieren und überprüfen zu können, was der Compiler aus dem Code so gemacht hat.
Ich habe auch so einige Jahre nicht nur AVR's in Assembler programmiert. In "C" hat man aber wesentlich schneller ein Ergebnis. Allerdings hat "C" doch so einige Haken, vor allen Dingen beim Einsatz in Verbindung mit uP's. Wenn man "C" noch nicht beherscht, ist man mit Assembler besser dran.

Gruß Ingo
 

ingo_s

User
Tank Pegel Überwachung für Benziner

Tank Pegel Überwachung für Benziner

Hi,

ich habe die Tank Pegel Überwachung nun soweit, das sie in den Praxis Test gehen kann.

Basis des Messprinzip sind spezielle Schlauch Gabel-Lichtschranken, die einen sehr großen Unterschied im Ausgangsstrom des Fototransistors zwischen leerem und vollem Schlauch (durchsichtiges Medium, hier Benzin) haben. Der Strom steigt bei vollem Schlauch um das drei bis funf-fache gegenüber einem leerem Schlauch an.
Das ganze wurde mit Tygon Schlauch und Stiel-Sprit ausprobiert. Der Schlauch muss natürlich so angebracht werden, das er den Pegel des Tanks widerspiegelt.
Die Lichtschranken haben eine sehr große Exemplar Streuung, die eine einmalige Kalibrierung bedingt, was aber kein Problem darstellt.
Für die Pegel Überwachung sind im Moment 2 Lichtschranken vorgesehen, eine unten (Reserve) und eine im Mittleren Bereich.

Als Hardware habe ich eine meiner Lipo-Saver Leiterplatten genommen, die mit etwas anderer Bestückung für das Projekt gut geeignet war.

SpritSensor_k.jpg

Im Bild sieht man die kleine Sensor Elektronik und eine der Gabel-Lichtschranken.
 
Hallo Ingo,

ich bin gerade dabei, die Firmware-Erweiterungen für die Strom- und Kapazitätsmessung zu machen.
Dazu habe ich die Firmware für den Spannungssensor erst mal ein klein wenig optisch verschönert und übersichtlicher gestaltet.
(Makros, Unterprogramme, systematische Namen für die Register, etc.)
Dadurch ist es jetzt einfacher, die Erweiterungen einzubauen.

Parallel will ich dann den reinen Spannungssensor in flugfähiger Ausführung bauen.
(Und dann kommen deine SMD Platinen dran...)

Aber das Thema MSB/Jeti Bridge lässt mich irgendwie auch nicht los. ;)

Werde weiter berichten.


Gruß
Reinhardt
 

ingo_s

User
Hallo Reinhardt,

der ATtiny1634 mit 2 UARTs wird wohl bald erhältlich sein. Bei digikey ist er schon auf Lager.
Am liebsten würde ich einen uP mit weniger als 20 Pins und mind. 2 UARTs einsetzen. Den gibt es auch schon, in der LPC800er Serie, aber einen weiteren Hersteller mit weiterer IDE will ich mir nicht antun.

Wenn es 32 TQFP sein darf, der ATxmega32E5 hat 2 UARTs und 16 ADC 12Bit Inputs, auch nicht verkehrt.

Gruß Ingo
 
Hallo Ingo,

weißt Du, ob es den ATtiny1634 auch im konventionellen Gehäuse gibt, so dass man ihn mit dem STK500 betreiben kann?
Die von Atmel angeküpndigten 441er und 841er Tinys gibt es ja nur noch in SMD Ausführung (bzw. derzeit wohl überhaupt noch nicht).
Die kleinsten "normalen" Atmels mit zwei USARTs im konventionellen Gehäuse, die ich gefunden habe, haben bereits 40 Pins.
Für die Entwicklung der SW kein Problem, aber dann müsste man später wieder portieren, denn das 40Pin Monster ist für reale HW zu groß.

Gruß
Reinhardt
 
Also der Tiny 841 ist super geeignet für MSB Sensoren. Hab jetzt schon ein paar davon im Einsatz. Die HW-UART sorgt halt für eine niedrige Prozessorlast. Und der eingebaute RC-Oszillator sollte nun (laut Datenblatt) genau genug sein damit man keinen externen Quarz mehr braucht. Erste Tests bestätigen das auch.
Ja den gibts nur als SMD, aber ich seh da kein Problem. Im Sensor hab ich sowieso nur SMD Elemente und fürs Steckbrett kann man eine Adapterplatine nehmen.

Weiß inzwischen eigentlich jemand wie man die GPS Positionsdaten bekommt? Habe einen MSB-Logger gebaut und würde natürlich auch gerne die Position loggen, so wie das Original.

viele Grüße
cyblord
 

ingo_s

User
Der Empfänger fügt als Master in den MSB Zyklus ca. alle 500ms eine 2 Byte GPS Abfrage ein, auf die der MPX GPS Sensor dann die Koordinaten ausgibt.
Der Logger speichert dann diese Koordinaten-Daten.

Hast Du oder willst Du einen original MPX GPS Sensor einsetzen oder was eigenes?

Gruß Ingo
 
Hallo zusammen,

vielleicht is es ja anderen schon früher aufgefallen, ich bin heute erst darüber gestolpert.
Und zwar kann man jetzt die MSB Spezifikation einfach von der Multiplex Homepage unter Downloads runterladen.
Haben sie jetzt wohl eingesehen, dass das die einfachste Lösung ist. :)

Gruß
Reinhardt

P.S.: Mein MSB Projekt dümpelt leider derzeit vor sich hin, hoffentlich habe ich nach dem Urlaub wieder mehr Zeit dafür.
 
Der Empfänger fügt als Master in den MSB Zyklus ca. alle 500ms eine 2 Byte GPS Abfrage ein, auf die der MPX GPS Sensor dann die Koordinaten ausgibt.
Der Logger speichert dann diese Koordinaten-Daten.

Hast Du oder willst Du einen original MPX GPS Sensor einsetzen oder was eigenes?

Gruß Ingo

Weißt du welche 2 Bytes das genau sind? Da muss ich nicht 2^16 Möglichkeiten durchprobieren ;-)

Ich will den Original GPS-Sensor auslesen. z.B. um einen eigenen Recorder zu bauen.
 

ingo_s

User
Den Wert habe ich nicht mehr in Erinnerung, weil es meine Sensoren nicht tangierte.
Man kann das aber an einem MPX Telemetrie Empfänger mittels Terminal oder Analyser feststellen.
Du hast doch sicher einen oder? Wenn nicht, müsste ich nochmal nachsehen.

Gruß Ingo
 
Den Wert habe ich nicht mehr in Erinnerung, weil es meine Sensoren nicht tangierte.
Man kann das aber an einem MPX Telemetrie Empfänger mittels Terminal oder Analyser feststellen.
Du hast doch sicher einen oder? Wenn nicht, müsste ich nochmal nachsehen.

Gruß Ingo

Klar ich hab genügend MPX Empfänger. Aber mir war nicht klar dass der Empfänger von sich aus die Positionsausgabe triggert. Ich dachte das macht der MPX Recorder irgendwie selber. Dann werd ich mal nachschauen.
Danke für die Infos.
 
Hallo zusammen,

nachdem mein Sensorprojekt jetzt eine ganze Weile auf Eis lag, hat es mich kürzlich doch wieder gepackt.
Ich wollte schon länger das Senden/Empfangen in der SW implementieren, um flexibler bei der Auswahl des Controllers (Größe) zu sein.
(bzw. im Hinblick auf eine Jeti/MSB Bridge, die mir irgendwie nicht aus dem Kopf will und die zwei UARTs bräuchte)

Da ich mich zum SMD Löten noch nicht durchringen konnte, kämen da natürlich vor allem die Tinys mit 8 oder 14 Pins in Frage.
Und diese haben nun mal keinen HW USART, also war ein wenig Programmieren angesagt.
Das Senden/Empfangen war dann eigentlich wesentlich leichter zu implementieren als ich gedacht hatte (z.B. gibt es kein Parity Bit).
Es gibt auch einige Atmel Application Notes zu diesem Thema.

Da die Tinys auch nur zwei Timer haben, musste ich das Programm noch etwas "streamlinen".
Die bisher angewandte Methode, den Idle Line Timer immer nudeln zulassen (außer wenn der Sensor sendet) ging nicht mehr,
da der selbe Timer für den Bit-Takt beim Senden/Empfangen eines Bytes gebraucht wird.
(Ein Timer ist fest für das Takten der Messungen mit dem ADC reserviert, das ja ständig im Hintergrund läuft.)
Ich habe das jetzt sauberer gelöst (lösen müssen), d.h. die Idle Time wird jetzt immer nur dann gestartet, wenn sie gebraucht wird (nach dem Empfang eine Bytes).
Wenn sich am Bus nichts tut, oder wenn der Sensor gerade empfängt oder sendet, gibt es auch keine Idle Time Überwachung.

Als es dann ans Testen ging, habe ich leider eine kleine Überraschung erlebt. :eek:
Und zwar kann das von mir verwendete STK500 die 14-Pin Tinys nicht direkt betreiben (keine Fassung vorgesehen).
Also habe ich auch angefangen, ein eigenes Testboard aufzubauen.

IMG_8873 (800x600).jpg

Einige Bauteile hatte ich nicht in meinem Fundus, daher läuft gerade eine Bestellung, bevor ich den Spannungssensor auf dem Board fertigstellen kann.
Wie man sieht, finden auf dem Board noch mindestens zwei weitere Sensoren Platz, eine zentrale Stromversorgung kommt auch noch.
Alles wird schön per Jumper geschaltet, so dass beliebige Kombinationen der Sensoren parallel betrieben und getestet werden können.
Da ist dann allerdings noch etwas Lötarbeit angesagt.

Ich werde weiter berichten.


Gruß
Reinhardt
 

k_wimmer

User
Elektronischer Schalter mit Weiche und MSB

Elektronischer Schalter mit Weiche und MSB

Hallo,

ich habe schon vor geraumer Zeit mal einen elektronischen Schalter entwickelt.
Später kam dann noch eine Akkuweiche dazu und zum Schluss noch eine MSB-Schnittstelle.

Leider habe ich gerade festgestellt, dass man wohl keine .zip Dateien hochladen kann.
Kann das sein, oder mache ich was falsch?

Würde dann nämlich das gesamte Projekt sharen (Soft- und Hardware).
 

Anhänge

  • Front.jpg
    Front.jpg
    144 KB · Aufrufe: 119
  • Rueck.jpg
    Rueck.jpg
    166,3 KB · Aufrufe: 100

k_wimmer

User
Anhang anzeigen Voltage_Sensor.X.dat

habe die Datei einfach mal .dat umbenannt, ist aber eine .zip.
also download und umbenennen, das wars.

Das Softwareproject ist mit Microchip MPLABX 2.20 aufgesetzt.
Der Compiler ist Microchip XC16 V1.23.
Der Controller ist ein Pic24F04KA200.
Das Schaltbild/Layout habe ich mit Eagle V5.11 gemacht.

Viel Spass damit !
 

ingo_s

User
Hallo Kai,

interessantes Projekt, werde es mir am WE mal in Ruhe ansehen, auch wenn ich nicht zusätzlich auch noch eine PIC Umgebung zusätzlich zur AVR und STM32 aufbauen will.

Gruß Ingo
 
Hallo zusammen,

so, heute gab es bei mir ein größeres Erfolgserlebnis. :)

Ich hatte ja angefangen, ein eigenes Testboard aufzubauen wegen der 14-poligen Tinys und bin da auch schon recht weit gekommen.
Aber irgendwann hat es mir dann gedämmert, dass das STK500 zwar keine 14-poligen, wohl aber die 8-poligen Tinys aufnehmen kann.
Also fix das Programm auf den 8-poligen ATtiny25 portiert, was kein großer Aufwand war.
(Glücklicherweise hatte ich auch eine Anzahl 25er und 45er beim Reichelt mitbestellt.)

Und heute kam dann der spannende Moment.
uC in das Board und alle notwendigen Verbindungen hergestellt, sowie den M-Link Empfänger angeschlossen.
Zuerst tat sich natürlich nichts, aber mit dem Simulator/Debugger des AVR Studios konnte ich recht schnell den Fehler finden und beheben.
Und schon konnte ich auf meiner Cockpit SX den Spannungswert ablesen (ok, waren nur 0 V der Einfachheit halber).

Auf Grund der wenigen Anschlüsse können beim ATtiny25 nur zwei I/O Pins (einer davon wird für den MSB gebraucht) und ein ADC Eingang verwendet werden.
Das reicht aber für einen Spannungssensor aus und den werde ich jetzt als nächstes in modelltauglicher Größe aufbauen.

Für den verbleibenden I/O Pin ist mir auch schon was eingefallen.
Und zwar könnte man damit das Motorsignal überwachen und so die Motorlaufzeit ermitteln und zurücksenden.
Jetzt werden einige einwenden, dass man das doch ganz einfach im Sender per Timer machen kann.
Stimmt, aber wenn man es im Modell macht, ergeben sich zwei Vorteile.
Erstens sind damit automatisch alle Mischungen auf den Gaskanal, sowie Gas NOT-AUS berücksichtigt.
(Die Royal hat leider keine logischen Schalter um das im Sender zu machen.)
Und zweitens hätte man dann die Akkuspannung und die Motorlaufzeit auf einem Display schön beisammen.
Für Elektrosegler eine Super-Lösung (bei Motormodellen fliege ich in erster Linie nach entnommener Ladung).
Damit werde ich mich dann in den nächsten Tagen beschäftigen, für heute soll es jetzt gut sein.


Gruß
Reinhardt
 
Hallo zusammen,

jetzt habe ich den freien Pin des ATtiny25 dazu genutzt, um per Jumper zwischen zwei oder drei Zellen umzuschalten.
Das ist nämlich genau der Einsatzzweck für diesen kleinen Spannungssensor, kleine E-Segler mit zwei- oder dreizelligem Antriebsakku.

Die Zellenzahl habe ich gebraucht, um in die Firmware einen Spannungsalarm einzubauen, denn ohne diesen wäre das Teil etwas praxisfremd.
Dazu habe ich eine Minimalspannung pro Zelle als Alarmschwelle fest als Konstante codiert (derzeit 3,5 V).
Die Sensoradresse ist ebenfalls als Konstante in der Firmware vorgegeben.

Damit beschränkt sich die Konfiguration des Sensors auf einen Jumper, um von drei (Default) auf zwei Zellen umzuschalten.
Ich muss mir dann nicht den Kopf zerbrechen, was jetzt wohl gerade im Sensor konfiguriert ist.
Und zum Ändern der Adresse oder Alarmschwelle müsste das Teil ohnehin an den PC angeschlossen werden,
da kann ich dann auch genauso gut gleich eine Konstante ändern und die Firmware neu aufspielen.
(Das Protokoll zum Konfigurieren mit der Multi-Mate ist mir leider nicht bekannt.)

Soweit so gut, jetzt muss ich halt mal einen bauen.


Gruß
Reinhardt
 

ingo_s

User
Hallo Kai,

habe mir eben mal das Schaltbild angesehen. Gute Kombination des Schalters mit Strommessung und Spannungsmaessung der beiden Akkus, so hat man alles notwendige zusammen.
Beim Schaltungsdesign ist allerdings noch so einiges an Einsparpotential, wenn ich das richtig auf die schnelle erfasst habe.

Grüße Ingo
 

k_wimmer

User
Hallo Ingo,

große Teile der Schaltung stammen aus diversen Industriedesigns die ich für Großserieneinsatz designed hatte.
1. An der Schnittstelle lässt sich mit sicherheit einiges einsparen, wenn man z.B. die UART des Micros mit mehr Software überwacht,
und die Pins direkt mittels Software steuert.
2. Ich würde mittlerweile keine Low-Side Strommessung mehr machen, sondern in der High-Line mittels Current-Sensor messen.

Beim Schalter selber kann man vielleicht V5 und V7 durch Mos-Fets ersetzen, was den Spannungsabfall für die Spannungsmessung positiv beeinflusst.

Die Software würde auch auf einem kleineren Micro problemlos láufen, aber da es sich hier um eine Plattformentwicklung handelt muss man diesen Punkt über
die ganze Sache übergreifend betrachten.
Aber das ist wie mit allen Sachen: Perfekt gibt es nicht !

Außerdem ist das nur ein Vorschlag und deine Diskussionsgrundlage, von daher:
Kritik und Anregungen sind IMMER wilkommen.
 
Ansicht hell / dunkel umschalten
Oben Unten