PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Treffpunkt DIY Multiplex Sensor-Entwickler (und die es werden wollen)



ingo_s
18.02.2011, 20:24
Hi,
außer den mir bekannten Personen, wird es sicher noch andere geben, die im stillen Kämmerlein MPX Sensoren entwickelt haben, oder noch dabei sind.

Also meldet euch bitte doch mal hier, bin mal gespannt wie viele es nun sind und sich in die Öffentlichkeit wagen.

Ich habe im wesentlichen Lipo-Saver Sensoren entwickelt, in letzter Zeit auch als Multi-Sensor mit zusätzlicher Strom, Drehzahl und Temperatur Messung.

Ein Problem ist ja die Parametrisierung der eigenen Sensoren, das muss ja auch abgedeckt werden. Dafür gibt es von Helmut und mir eine universelle Lösung die im Moment im Endstatium der Entwicklung ist. Bei Interesse gibt es darüber gerne mehr Information.

Gruß Ingo

geilerflieger
22.02.2011, 22:54
Hallo Ingo,

schade das sich hier niemand meldet. Ich gehöre leider auch nicht dazu. Wobei ich immer wieder gedanklich an einem Tanksensor arbeite. Habe dazu auch schon ein altes Servopoti ausgegraben und tüftle immer wieder mal ein wenig rum. (Nur die mechanische Seite....)

Auswerten würde ich das Teil im moment einfach über einen Spannungssensor. (Linearer Regler 5V über das Poti zu einer (oder 2) Leuchtdioden. Die Spannung dann an den Leuchtdioden messen. Dann wüsste ich zum Beispiel bei
~ 4,5Volt = Tank voll und bei
~ 3,0 Volt = Tank leer.

Aber......... Ich weiß noch nicht wie ich das mit dem Schwimmer nach außen übertragen soll, das ganze muß ja auch noch 100% dicht sein und der Schwimmer darf ja dem Tankpendel auch nicht im Weg sein. Evtl. mit Magneten.

Ob bei Kunstflug der Sensor falsche angaben macht ist Nebensache, mir geht es bei meinem Schlepper (Bully von Vogt) nur darum ob er nach z.B 3 Schleppvorgängen noch genug Sprit im Bauch hat oder nicht. (Rumpf ist geschlossen, von außen nicht einsehbar)

Oder ich hatte das Teil (http://cgi.ebay.de/Bashan-Tankgeber-Enduro-Motocross-Pit-Dirt-Mini-Bike-/400192210434?pt=Motorrad_Kraftradteile&hash=item5d2d508602) schon ins Auge gefasst. Leider gibt es dazu keine Techn. Daten wie Ohm oder Wirkungs - Länge (Hub).

Hat jemend schon andere Ideen dazu?

Weiß jemand wann ACT seinem angekündigten Füllstandsensor liefern kann?

Grüße, Stefano

ingo_s
22.02.2011, 23:06
Hi,

was ist dann drin im Tank Benzin, oder Methnol?

Einen Schwimmer würde ich nicht einsetzen wollen, eher Leitfähigkeits-Fühler, Licht, kapazitive Messung, Ultraschall oder Durchfluss Impulsgeber je nach Medium.

Gruß Ingo

geilerflieger
22.02.2011, 23:13
Hallo Ingo,

im Tank ist Benzin, somit scheidet der Leitfähigkeits-Fühler oder die kapazitive Messung schon aus. Oder liege ich da falsch?

Für einen Durchflussmesser ist der Durchfluss / min wohl eher zu klein. (ZG62) 1 Liter bei Vollgas ~ 24 Minuten

Licht oder Ultraschall? Das ist für einen Maschinenbauer mit elektrischem "Halbwissen" nicht machbar. Wenn jemand aber was brauchbares entwickelt, würde gerne so etwas haben...:p

Grüße, Stefano

ingo_s
23.02.2011, 11:22
Hallo Stefano,

mit E10 Sprit könnte die Leitfähigkeits Messung evtl. gehen. Kapazitiv müsste auch gehen falls die Dielektrizitäts Konstante sich genug von Luft abhebt, nur ist da der Bau des Fühlers wohl kritischer.

Wenn der E10 Sprit auf dem Markt ist könnte man ja mal eine Leitfähigkeits Messung als Versuch in einem Becher machen. Die notwendige Elektronik als MPX Sensor zu bauen ist kein Problem.

Gruß Ingo

Sebastian St.
27.02.2011, 17:54
Moin ,

beim meinem Motorrad ist imTank ein Thermowiederstand eingebaut , der so lange er vom Sprit umspült wird kalt bleibt , sobald er nicht mehr gekühlt wird ändert er seinen Widerstand und dardurch wird dann die Investitionsleuchte ( Reserveleuchte :D ) eingeschaltet . Alternativ könnte ich mir einfache Pegelschalter vorstellen die so eingebaut werden das sie schalten wenn die kritische Menge erreicht / unterschritten wird

Flieger Georg
28.02.2011, 12:59
Hallo,
Was ist denn wenn man die Spritmenge über die Membranpumpe misst?
Die Pumpe selber pumpt ja immer die gleiche Menge ob schnell oder langsam.
Man bräuchte also ein Zähler ( Zündung oder Umdrehungen der Kurbelwelle)
der dann die Spritmenge umrechnet.
Angenommen man hat 10000 Impulse = Zündungen und man weiß das man bei 10000 Impulsen 500ml verbraucht hat , kann man doch die Menge umrechnen ODER?
Für Benziner denke ich, wird das gehen für Methanoler hab ich noch keine Idee.
Die Turbinenflieger haben ja Zahnradpunpen wieweit das mit dennen geht weiß ich nicht
da die Pumpen bei hoher Drehzahl ein bestimmten schlupf haben ( Sprit kommt nicht so schnell nach) .wenn das linear ist, ist auch bestimmt das umzurechnen.
Als Mechaniker hab ich s aber nicht so mit dem Strom
Der turbinenheli kennt sich da bestimmt besser aus.

Gruß Georg

geilerflieger
07.03.2011, 18:11
Hallo Zusammen,

so, habe mal ein wenig getüftelt und mir einen Tanksensor mit Red-Kontakten (3 Stck) gebastelt. Auswertung über Spannungssensor.

Funktion:
Red-Kontakt 1 = Voll (ca. 60 - 100%) Spannung 5Volt
Red-Kontakt 2 = Halbvoll (ca 50%) Spannung 4 Volt
Red Kontakt 3 = Reserve (ca. 35%) Spannung 3 Volt (Tanken!)
Kein Red Kontakt = Leer Spannung 0 Volt

Als "Verbraucher" habe ich einen 10KOhm Wiederstand eingesetzt und dann jeweils Vorwiederstände mit Potis (ca. 2KOhm Eingesetzt. Somit ist die Stromaufnahme zwischen 0,3 und 0,5mA
Die Eingangsspannung ist von einer Akkuweiche, somit Konstant 6 Volt

Hier die Bilder Dazu:

geilerflieger
07.03.2011, 18:17
Jetzt bräuchte ich nur noch jemanden der einen Spannungssensor so "umprogrammiert" das er bei 4,5-5,5 Volt 100% und bei 3,5 - 4,49 Volt 50% und bei 2,5 - 3,49Volt 35% oder Reseve und bei 0 Volt leer am Display anzeigt. Ist das realisierbar?

Grüße, Stefano

ingo_s
07.03.2011, 20:18
Hi Stefano,

einen Sensor zu bauen, der die unterschiedlichen Spannungen umgerechnet als %Tank ausgibt, ist kein Problem.

Nur würde ich anstelle der Reed-Kontakte, Hall-Sensoren einsetzen (z.B. TLE 4905L, A1120, AH3761). Man findet die auch in den kleinen BL Lüfter-Motoren aus dem PC Bereich.
Ob die Schwimmer Mechanik auf Dauer funktioniert muss dann die Praxis ergeben.

Gruß Ingo

geilerflieger
07.03.2011, 21:55
Hallo Ingo,

was hätten denn Hall Sensoren bei diesem Anwendungsfall für Vorteile? (Achtung, bin Mechaniker mit gefährlichen Elektro Halbwissen:D)
Zitat:
einen Sensor zu bauen, der die unterschiedlichen Spannungen umgerechnet als %Tank ausgibt, ist kein Problem.

Wenn Du das machen könntest währe klasse. Melde mich per PN,

Grüße, Stefano

ingo_s
10.03.2011, 13:39
Hallo Stefano,

ich möchte möglichst wenig mechanisch bewegte Teile im System haben, und die Hall-Sensoren eliminieren schon mal wenigstens die Reed-Kontakte und sind auch viel kleiner und leichter.

Ist die PN angekommen?

Gruß Ingo

foobar
25.03.2011, 08:20
Hallo,



Ein Problem ist ja die Parametrisierung der eigenen Sensoren, das muss ja auch abgedeckt werden. Dafür gibt es von Helmut und mir eine universelle Lösung die im Moment im Endstatium der Entwicklung ist. Bei Interesse gibt es darüber gerne mehr Information.


ja, daran besteht sicherlich allgemeines Interesse. Berichte doch mal;)

ingo_s
25.03.2011, 11:02
Hallo Norbert,

die Sicht auf den Sensor wurde in 5 Ebenen oder auch Schichten unterteilt. Jede Ebene wird durch eine "C" Struktur beschrieben. Die Parameter Beschreibung und die Parameter Daten werden getrennt gehalten.
Für die Parametrierung muss der Sensor nicht einzeln angeschlossen werden. Er wird gezielt mit einer Parameter-Adresse angesprochen. In der ersten Phase liefert er nur einen kurzen Text, damit man weiss, welchen Sensor man anspricht. Will man diesen Sensor dann parametrisieren, liefert er auf Anforderung die Parameter Beschreibung und getrennt die Parameter Daten. Da Parameter Beschreibung und Daten getrennt sind, kann die Beschreibung im Flash gehalten werden. Nach Änderung der Einstellungen werden die Paramter Daten dann an den Sensor geschickt.

Stand der Entwicklung ist folgender, Helmut und ich haben eine gemeinsame Grundstruktur geschaffen, auf dessen Basis ich aus Zeitgründen Strukturen und Parameter festgelegt habe um schon jetzt eine funktionierende Lösung zu haben. Helmut arbeitet noch an einer Verfeinerung der Strukturen um noch mehr Sonderfälle abdecken zu können.
Die jetzige Lösung ist aber schon so ausgereift, das man mit dieser nicht nur alle MPX Sensoren abbilden kann, sondern auch z.B. Sensoren mit einem universellen analog Eingang, an dem unterschiedliche Messgrößen wie Temperatur oder alternativ Beschleunigung gemessen werden können.
Für die Parametrierung gibt es in Form einer umprogrammierten "robbe Programmer V2" Box auch schon eine fertige Lösung. Mittlerweile habe ich alle meine Sensoren auf das Verfahren umgestellt und bin mit dem Ergebnis mehr als zufrieden. Ein PC Programm zur Parametrierung ist in Planung.

Gruß Ingo

ingo_s
25.03.2011, 11:44
Hier mal anbei einige Bilder vom SetUp Vorgang mit der kleinen umprogrammierten Box und ein Bild des angeschlossenen Multi-Sensors. Der Sensor agiert als Lipo-Zellen Einzelzellen Überwachung, Strom, Stromverbrauchs und Drehzahl Sensor.

623462 623463 623465 623461623460 623459623464

Gruß Ingo

foobar
25.03.2011, 11:46
Hallo Ingo,



Stand der Entwicklung ist folgender, Helmut und ich haben eine gemeinsame Grundstruktur geschaffen, auf dessen Basis ich aus Zeitgründen Strukturen und Parameter festgelegt habe um schon jetzt eine funktionierende Lösung zu haben. Helmut arbeitet noch an einer Verfeinerung der Strukturen um noch mehr Sonderfälle abdecken zu können.
Die jetzige Lösung ist aber schon so ausgereift, das man mit dieser nicht nur alle MPX Sensoren abbilden kann, sondern auch z.B. Sensoren mit einem universellen analog Eingang, an dem unterschiedliche Messgrößen wie Temperatur oder alternativ Beschleunigung gemessen werden können.
Für die Parametrierung gibt es in Form einer umprogrammierten "robbe Programmer V2" Box auch schon eine fertige Lösung. Mittlerweile habe ich alle meine Sensoren auf das Verfahren umgestellt und bin mit dem Ergebnis mehr als zufrieden. Ein PC Programm zur Parametrierung ist in Planung.


nur, damit ich das richtig verstehe: Ihr habt im Prinzip eine "offene" Loesung geschaffen, die den SensorManager/Multimate von Multiplex ersetzt? Woher habt ihr die notwendigen Informationen bzgl. der Sensor-Parametrierung? Aus der Spezifikation zum "Multiplex Sensor Bus" geht diese ja nicht hervor... Reversed?

(Kleiner Exkurs: Das ist - fuer mich - im Moment die groesste Kritik an der Offenlegung: Das man diese zwar prinzipiell von MPX erhaelt, aber niemand so richtig mit dem Sourcen rausrueckt. Wenn die Spezifikation komplett offenlaege, koennte man damit "ohne Ende" und ohne Gewissensbisse/Unsicherheiten github et al fuellen! Oder uebersehe ich wesentliche Ressourcen?)

ingo_s
25.03.2011, 12:07
Nein, das ist ein Missverständnis!

Parametrieren geht nur für die eigenen Sensoren, als offene Lösung. Mit "alle MPX Sensoren abbilden" war nur gemeint, das mit dem Verfahren eigene Sensoren mit den gleichen Komplexität der Einstellungen wie die bisher auf dem Markt befindlichen MPX Sensoren damit parametriesiert werden können, unter der Voraussetzung das diese dieses Verfahren implementiert haben.

Multiplex hat da eine proparitäre eigene Lösung. Wir wollten eine universelle Lösung, die nicht bei jedem neuen Sensor ein Update der Parametrierer Seite erfordert.

Gruß Ingo

foobar
25.03.2011, 12:39
Hallo Ingo,


Parametrieren geht nur für die eigenen Sensoren, als offene Lösung. Mit "alle MPX Sensoren abbilden" war nur gemeint, das mit dem Verfahren eigene Sensoren mit den gleichen Komplexität der Einstellungen wie die bisher auf dem Markt befindlichen MPX Sensoren damit parametriesiert werden können, unter der Voraussetzung das diese dieses Verfahren implementiert haben.


ok, vielen Dank fuer diese Klarstellung; jetzt habe ich es verstanden... Werdet ihr das Softwarepaket dann irgendwann zur Verfuegung stellen? Und welche (Mikro-)Prozessorbasis verwendet ihr?

ingo_s
25.03.2011, 13:23
Hallo Norbert,

ja das ganze werden wir zur Verfügung stellen, es fehlt nur noch an einer ausführlichen Dokumentation. Wer nicht warten will muss mit der jetzigen Doku in Kurzform und den Informationen in den Sourcen klar kommen. Bisher wird es auf Atmel AVR mit WinAVR Basis eingesetzt, ist aber eigentlich Prozessor unabhängig. Wenn Zeit ist und auch eine entsprechene Nachfrage da ist, wollten wir auch mal eine Referenz Implementierung machen.

Gruß Ingo

Helmut Stettmaier
25.03.2011, 20:32
Hallo Freunde,
jetzt melde ich mich auch mal...

Ich stelle zuerst die wesentlichen Eigenschaften der angestrebten Parametrierung vor:
Es werden Datenstrukturen definiert mit dem Ziel zu beschreiben was für Parameter der Sensor hat und wie sie darzustellen und zu verändern sind. Ebenso soll ein Protokoll festgelegt werden für ein einheitliches Auslesen der Parameter-Werte und -Beschreibungen und zum Zurückschreiben der veränderten Parameterwerte.
Es soll mehrere Implementierungen geben für die erforderlichen Geräte und Software:
Absolut genial ist die Verwendung des robbe-Schlüsselanhängers Nr. 8642, der hardwaremäßig ziemlich genau alles mitbringt was man für diese Aufgabe braucht. Ingo hat da schon vorzeigbares geschaffen.
Selbstverständlich muss es auch eine echte PC-Lösung geben; Teil meiner Arbeiten ist es, eine sehr einfache PC-Implementierung (Konsolprogramm) zu machen, die z.B. über den Multiplex-USB-Adapter (85149) Parametrierungen vorzunehmen.
Darüber hinaus soll es erweiterte Implemenierungen geben, z.B. eine schicke GUI für das PC-Konsolprogramm oder für andere Hardware (z.B. eine Bluetooth-Anbindung ans Handy und ein Java-MIDP-Programm o.ä.). Hier sind wir beide jedoch nicht aktiv, es macht genug Arbeit eine grundlegende Implementierung auf die Beine zu stellen. Hier gibt's reichlich Möglichkeiten für weitere Entwickler...
Es ist klar, dass ein Sensor, der mit diesem System parametriert werden soll, gewisse Anforderungen mitbringen muss: Die Datenstrukturen und das Protokoll. Man muss also Funktionen einbauen, die vorgegeben sind, und man muss sich mit der Speicherung und Verarbeitung der Parameter an Vorgaben halten, die vielleicht nicht 100%ig genau so aussehen, wie man sich das schon immer gewünscht hat...
"Unser" Verfahren kann sicherlich nicht so komfortabel wie das von Multiplex sein. Eines wollen wir jedoch "besser" machen: Ein neuer Sensor, der die Vorgaben korrekt einhält, soll "sofort" und ohne Updates mit den vorhandenen Parametrierern (robbe-Schlüsselanhänger und PC) eingestellt werden können. Dies ist erforderlich wenn ein unstrukturierter Haufen von MSB-Sensor-Entwicklern (smile) dieses Verfahren gemeinsam nutzen möchte. Bei Multiplex sieht dies anders aus: Alle Entwickler sind in der gleichen Firma (und haben den gleichen Chef und gemeinsame Vorgaben und Ziele) und diese Firma hat eine eingespielte Infrastruktur um ihre Kunden mit Updates und Parameter-Infos zu versorgen - dort läuft das also sinnvollerweise anders und insbesondere sicherlich bequemer für den Kunden ab als "wir" das je können.
Man wird nicht nur Sensoren mit dieser Methode parametrieren wollen sondern möglichst viele ähnliche Geräte; dazu gehören z.B. auch spezielle Aktoren wie Drehzahlsteller (wie viele "Programmer-Cards" gibt's eigentlich schon für die vielen Drehzahlsteller?) oder auch die Haptik-Render-Engine, die ich letztes Jahr in meinen Sender eingebaut habe.
Es ist nicht einfach, sicher genug in die Zukunft zu schauen um zu sehen, was für Parameter denn in ein paar Jahren in den Sensoren etc. sein werden, die mit dieser Methode dann eingestellt werden können sollen - das wird sicherlich jeder glauben. Eine Liste von Parametertypen aufzustellen, die "alles abdeckt", ist ein langwieriger Job.
Eine weitere Anforderung an dieses Verfahren, wenn es sich durchsetzen sollte, ist die Überprüfung der Einhaltung der Standards oder, besser, Hilfsmittel zur einfachen Einhaltung der Standards. Je mehr DIY-MSB-Junkies es geben wird (kann süchtig machen!) umso dankbarer wird man für Hilfsmittel sein, die Fehler vermeiden helfen.
Also: Ein gewisses Maß an Komplexität und Fehlerfreiheit - das muss unter ein Dach. Und das alles muss in eine Hardware rein, die g'rad mal ein paar KBytes Code zulässt. Es macht richtig Spaß.
Ingo hat schon was auf die Beine gestellt. Wir haben leider viel zu spät korrespondiert um jetzt schon eine gemeinsame Lösung zu haben. Ich habe inzwischen ein Tool entwickelt, das das Problem der Unterstützung zur Fehlerfreiheit angeht - es ist selbst noch nicht ganz fehlerfrei (lautes Gelächter). Sobald mein Zeugs, das in der kommenden Flugsaison was tun soll, das auch tut, mach' ich an dem Tool weiter.
Dieses Verfahren ist dort, wo Code im Flash-Speicher steht, dem von Ingo sehr (sehr!) ähnlich und es besteht selbstverständlich nach wie vor das feste Ziel, beide Verfahren zusammen zu führen, die Unterschiede liegen nur in den Datenstrukturen (und dem Tool). Hierfür gibt es eine allererste Beschreibung, der Ingo meint, sie sei viel zu lang... na gut, richtig leichte Kost ist's nicht, da hat er schon recht - aber wenn's was werden soll muss man irgendwann hingehen und sorgfältig aufschreiben was man will und wie's gehen soll. Wer sich ernsthaft dafür interessiert möge mich bitte anschreiben, der kriegt dann 31 Seiten pdf. Bitte etwas Geduld mitbringen, ich lese zur Zeit nicht allzu oft hier im Forum.

Ich würde mich freuen, wenn sich mehr Leute, die MSB-Sensoren entwickeln wollen, auch an diesem Thema beteiligen. Es gibt vielleicht immer noch Lücken in unser beider Überlegungen, Tricks, die wir übersehen haben und es gibt durchaus noch Gelegenheit, Code beizutragen (z.B. Bluetooth & Handy-Java, Muster-Implementierungen der Update-Funktionen für verschiedene uController-Plattformen).

Ich will noch ganz kurz auf die Frage nach den verwendeten Controllern eingehen:
Der robbe-Schlüsselanhänger ist, ganz klar, ein ATMEL-Gerät.
Ich selbst programmiere zur Zeit mit den kleinsten Freescale-Controllern; falls da jemand mitmachen will (ernsthaft): Ich kann einen SpYder-Debugger den ich auf der electronica gekriegt habe, abgeben - damit ist ein sehr kostengünstiger Eintieg möglich. Ich habe auch noch die Absicht, TI-Controller einzusetzten. Bei beiden Lieferanten schätze ich sehr, dass sie billige Debugger zur Verfügung stellen.

Genug für heute.
Schöne Grüße aus Olching,
Helmut

sbuhre
10.11.2011, 09:38
Hallo,

ich bin gerade dabei einen MSB-Sensor zu entwickeln, der Daten aus der Flight-Control (FC) des Mikrokopter ausliest und und per MSB bereit stellt. Ein erste Version existiert schon.

http://forum.mikrokopter.de/topic-post346969.html

Als nächstes baue ich das Parametrierverfahren von Ingo in den Sensor ein. Dazu habe ich eine Windows GUI in C# erstellt, mit der man dann prinzipiell jeden Sensor konfigurieren kann. Das Konzept von Ingo und Helmut ist sehr flexibel aber auch relativ komplex. So viel Aufwand hat nicht mal MPX betrieben, die haben alles hart kodiert und machen dann halt bei jedem neuen Sensor ein Update für Ihre Config-GUI.

Das ganze lohnt sich aber nur, wenn es wirklich auch Sensoren gibt, die man nicht bei MPX oder ACT ( günstiger ) kaufen kann. Preislich kann man gegen eine Massenherstellung ohnehin nicht ankommen. Aber es gibt eben auch besondere Ideen, die wird MPX nie realisieren...

Gruss


Stephan

Bernd FMC
13.11.2011, 09:22
Nach direktem Kontakt zu Ingo melde ich mich dann auch mal hier an ;-) .

Geplant ist erstmal, ähnlich Ingo´s Sensor, eine Einzelzellenüberwachung mit
Strom/Kapazitätsmessung und Alarmausgabe via Alarmbit von MPX.
Letzteres in Intervallen, um das Überhören im Falle eines lauten Vorbeifluges
im Moment des Alarmsound´s zu verhindern ( das halte ich für ein Denkproblem
bei MPX bei der Firmware der Royal Pro und auch Cockpit ( 3.42/3.08 ).

Mein Sensor soll mind. 10 Zellen können.

Ich muss mich aber noch in die Pic Materie einfinden, ASM Erfahrung ist aber
vorhanden ( und das nötige Elektronik KnewHow auch .. ) .

Evt. könnte man auch ein Sprachausgabemodul in Erwägung ziehen, derzeit
nutze ich aber auch schon das Linkvario in der Royal Pro.

Mir geht es vor allem um eine praktikable Accuüberwachung.

Das Problem der Tanküberwachung ist für mich nur tech. interessant, da wir eh
nur E-Flug dürfen/machen, ein Bekannter hat aber Arbeitsmäßig auch viel mit
entsp. Sensorik zu tun und meinte es gäbe eine Möglichkeit die Resonanz des
freien Luftraumes zu messen, und damit den Füllstand zu brechnen.
Klingt sehr theoretisch, aber der von dem es kommt ist absoluter Praktiker ;-) .

Grüße Bernd

Edit: ein Anzapfen der MSB Daten im Sender für Sprachsgabe a la wstech in der
Cockpit wäre auch nett, dort müsste man mal forschen.
( eine Cockpit 2.4 habe ich im Umfeld )
Beim HFM4-MLink liegt das ja an, HFM3-Mlink wird folgen ( Update MPX )

Helmut Stettmaier
22.12.2011, 23:28
Hallo,
dann will ich mich auch mal wieder melden...

Die letzten Monate hat sich nicht allzu viel getan denn erst musste ich eine andere Aufgabe zu einem gewissen Abschluss bringen:
Nach etlichem Brainstorming mit Ingo habe ich ein wenig Grundlagen-Arbeit geleistet und Ideen entwickelt wie man aus den Messdaten von modernen, voll-integrierten Druck-Sensoren das leider üppige Rauschen filtern kann. Die heute dafür verwendeten Techniken können verbessert werden (Stichwort "Ansprechzeit").
Es handelt sich hierbei nicht um ein konkretes Vario/Altimeter-Projekt aber es kann noch eines daraus werden - ich mach's nicht, denn die erforderliche Elektronik (mit einem wirklich leistungsfähigen uController) trau' ich mir nicht zu - aber vielleicht findet sich ein Team?
Es wird zur Zeit nicht allzu viele Kameraden interessieren: Zur Filterung von Drucksensor-Daten (http://www.fmsg-alling.de/tipstec/MS5611-Vario.pdf).

Jetzt habe ich ein recht konkretes Projekt angefangen: Die Energie-Überwachung im Segelflugmodell.
Die Anforderungen an so einen Sensor habe ich schon mal zusammengeschrieben: Energie-Monitoring in Segelflugmodellen (http://www.fmsg-alling.de/tipstec/EnergieMonitor.pdf).
Der Ingo meint, ich hätte wieder mal viel zu viel geschrieben, aber irgendwo muss man doch mal seine Gedanken sortieren, oder? :)
Wenn sich jemand dafür interessiert: Ich bin für Kritik und Anregungen selbstverständlich offen.
Ich überlege gerade, diesen Sensor mit einem MSP430-Controller zu implementieren (wenn der extrem kleine Programmspeicher dafür reicht).

Ach ja: Mein Inclinometer habe ich letzte Saison erprobt.
Leider ist die Telemetrie-Übertragung mit dem M-Link-System nicht besonders schnell; Multiplex sieht das j auch und hat einen Kanal durch Priorisierung in der Übertragung beschleunigt.
Allerdings wird man über diesen Kanal praktisch immer das Variometer übertragen und für andere Sensoren, die unmittelbar das Fliegen(lassen) beeinflussen, gibt's immer noch zu wenig Bandbreite.
Der Sensor als solcher funktioniert, allerdings nützen die Daten "unten" nicht allzu viel, weil sie nur gelegentlich ankommen.
Aussedem hat sich gezeigt, dass die Stabilität um die Längsachse auch bei "heftigeren" Modellen (MiniMach) so gut ist, dass auch beim Thermikkreisen (das kann der auch) nur geringe Fehler im Rollwinkel vorkommen.
Somit ist dieser Sensor überflüssig. Friede seiner Asche. Als Phönix kann ja mal ein Teil der Funktionalität, das g-Meter, auferstehen.
Das Thema ist für Multiplex allerdings noch nicht ausgestanden: Es wird weitere Sensoren geben, deren Werte "unten" rasch und in großer Zahl erwünscht sind, z.B. der IAS-Sensor. Es wird sicherlich interessant werden, wenn man mehrere Telemetrie-Kanäle (2 oder 3?) priorisieren könnte.

Ok, genug für heute,
Helmut

P.S.: Bernd, für Dich gibt's eine PM.

Bernd FMC
23.12.2011, 06:38
Hallo Helmut ( und nat. alle anderen ),

bei mir ließ die Arbeit auch nicht viel zu an vorankommen, ist auch nicht so relevant.
( Erst mal musste der neue Shocky fertig sein - der hat seinen Jungfernflug aber nun
erfolgreich hinter sich ).

Bei mir ist der Status: Hardware fast komplett ( Platine muss noch gefertigt werden ),
und auf der Softwareseite hab ich mich erst mal eingelesen, fand aber auch alle Info´s
die ich benötige.

Zuerst baue ich für die Praxis den Differenzialverstärker auf um an einem Ausgang
die niedriegste Spannung zu haben ( Einzelzellenüberwachung ) - das wird dann
erst mal ausgiebig am MPX Spannungssensor ( 2. Eingang ) getestet.
Wenn der Prototype gut funktioniert, wird diese Sache dann in meinen Sensor
integriert, so das ich nicht unbedingt alle Zellen mit den AD´s der Proc´s messen muss.
( Und damit die Probleme bei hohen Zellenzahlen umschiffe ).

Prototype kommt in DIL/Konventionell, Endversion als SMD ( evt. nur als Teil meines Sensors ).

Mein Sensor ist erst mal nur als Accuüberwachung geplant:
Spannungsüberwachung der Einzelzellen, Strommessung und Berechnung der verbrauchten
Ladung, soweit nichts neues, kann UNILOG, WSTech und Strom/Spannungssensor von MPX auch.
Ich dachte mir aber das Alarmbit im Intervall zu setzen, damit die Std. Akustik besser "nervt".
Zudem mal zum Test eben eine Ausgabe des Alarmwertes immer auf Adr. 0 als Spannung um
auch nicht upgedateten HFM3 Modulen den Alarm zu entlocken ( Ext. Display lässt ja auf sich warten ).

Sinn dabei ist: anschließen, fliegen, wenn irgendwas faul ist Piept der Sender, was der Grund war kann
man am Sender nat nicht sehen ;-) .

Wenn ich mal zuviel Zeit habe würde ich auch gerne eine Sprachausgabe für die CockpitSX realisieren,
das wäre aber schon mal 2 Nummern höher ( vor allem wo bekomme ich die Seriellen Daten und
vor allem ohne Hardwareconfus/Betriebsstabilität aus der Cockpit ).

Schöne Weihnacht, evt. mal nun auch mehr Zeit zum löten :D

Bernd

ingo_s
23.12.2011, 21:24
Da melde ich mich dann auch mal ;-)

Bei mir war in den letzten Monaten auch nicht so viel neues. Vorwiegend etwas Software Pflege an den bestehenden Sensoren, Überlegungen für kleine Updates und Vergleichen der 32Bit ARM3 uP Varianten als Basis für neue Sensoren. Zwischendurch Rohdaten Aufzeichnungen vom BMP085 und dem neuen MS5611 Drucksensor als Futter für Helmut's spezial Vario Filter.
Stephan arbeitet übrigens an einer Windows GUI für die Parametrierung, die die Strukturen jetzt schon korrekt anzeigt und sehr gut aussieht. Übrigens habe ich das Bus Konzept (auch wenn da noch Wünsche sind) des MSB und das Parametrier Verfahren in den letzten Monaten sehr zu schätzen gelernt.

Für diesen Winter habe ich viel Zeit für neues vorgesehen (Ich hoffe das klappt).
Die Sensoren mit Lipo-Einzelzellen Überwachung bekommen ein kleines Redesign. Wunsch ist, den Balancer Stecker vollkommen wahlfrei aufstecken zu können. Das betrifft vor allen Dingen den Kombi-Sensor, der bis 6 Zellen geht und bei dem oft 2x 3S angesteckt wird. Bisher gibt es den Kombi-Sensor einmal bis 6 Zellen mit Strom und Drehzahl-Messung und einmal nur bis 4 Zellen aber dafür mit zusätzlichem Analog-Eingang für Temperatur-Messung und Drucksensor für Höhe. Unter Verzicht auf die Temperatur-Messung soll die Variante bis 6 Zellen optional mit Drucksensor für Höhe (evtl. auch Vario) bestückbar sein.

Der neue Filter Algorithmus von Helmut soll in Verbindung mit dem MS5611 Vario Drucksensor ausprobiert werden und Erkenntnis bringen, ob dafür ein 32Bit uP zwingend eingesetzt werden muss. Einen Test-Sensor mit dem MS5611, Attiny85 und mit einem einfachen Tiefpass-Filter habe ich schon fertig gestellt, der schon sehr gute Vario Werte ausgibt. Bisher existiert ein Air-Speed Sensor, der optional mit einem BMP085 Drucksensor für Höhen und eingeschränkter Vario Messung bestückt werden kann. Dieser wird mit dem MS5611 Redesigned und je nach Ergebnis der Filter Erkenntnisse mit einem STM32 oder AVR bestückt werden.

Falls noch Zeit bleibt, soll mit dem STM32 der bisherige Kombi-Sensor in größerer Ausführung für mehr Zellen und mehr Funktionen noch entstehen.
Die Zeit wird zeigen, ob alle Pläne umgesetzt werden können, zumal zuerst die Einarbeitungs-Hürde in den STM32 noch genommen werden muss.

Gruß Ingo

ingo_s
23.12.2011, 22:03
Hallo,

hier mal einige Bilder der momentan aktuellen Sensoren:

Der bekannte Kombi-Sensor bis 6 Zellen von oben:
748447
ist erfolgreich bis 100A Spitzenstrom im Einsatz.
Die Strommessung kann Abhängig von der Shunt Bestückung bis 120A ausgelegt werden und der Shunt Bereich kann bei Bedarf auch abgetrennt werden.

Hier die Variante bis 4 Zellen mit bestücktem optionalem Drucksensor von unten gesehen:
748444
Der Drucksensor ist auf einer Mini-Breakout LP untergebracht.

Der kleine Lipo-Saver bis 3(4) Zellen und optionalem sehr hellem 1W Alarm-Blitz
748445
Der Blitz kann bei fehlender Telemetrie eingesetzt werden.

Der Air-Speed Sensor bestückt mit optionalem BMP085 Drucksensor für Höehe (+Vario)
748443 748446

Sollte jemand die Sensoren Nachbauen wollen, bis auf den Speed-Sensor kann ich noch einzelne Platinen abgeben.
SMD (Paste) lässt sich übrigens einseitig auch auf einem alten Bügeleisen (ohne Dampf) oder ähnlicher Wärmequelle löten.

Gruß Ingo

Tempo
26.12.2011, 11:00
Hallo Ingo,

ich bin auch einmal wieder aktiv.
Gerade bin ich dabei ein "openaltimeter" als MSB-Sensor umzurüsten, den ich bei meinem Schleudersegler (DLG) im Einsatz habe .

Da ich mit dem Arduino-Konzept arbeite (ATMEL-Kontroller) , habe ich es dort eingestellt:
http://www.rc-network.de/forum/showthread.php/281006-M-Link-Sensor-mit-Arduino?p=2624962&viewfull=1#post2624962

Viele Grüße

Tempo

P.S.:
Im Falle der Parametrierung werde ich Euer Konzept gerne übernehmen.
Ich melde mich dann zur passenden Zeit bei Dir.

Bernd FMC
07.01.2012, 09:24
Moin,

erstmal @ Tempo, hab auch gelesen bzgl. deiner Arduino libs - coole Sache.

An den letzten Abenden war ich nun auch wirklich angefangen, wohl wegen Konzentrationsmangel
machte ich da noch ein paar Denkfehler, danke noch an Ingo und Wolfgang für die Hilfe für
die Geistesblitze ;-) .

Status: Erstmal grundsätzliches - Basis bei mir Microchip Pic - erstmal Pic18F45K20 auf dem Demoboard.
- MSB Empfang funktioniert
- senden auch
- Idle Timeout Routine noch nicht ganz perfekt -> das ist die nächste Baustelle

- Hardware wird später auf einem kleineren Pic18 laufen ( wohl PIC 18F1220-I/SO - ca. 2.70€ )
- MSB geht auch bei mir nur über einen Pin
mit nur einem Widerstand zum MSB

Erstes Projekt wird wohl eine Variante sein, die den MSB monitort, und bei Auftreten eines Alarmes eines
MPX Sensors diesen als Spannugsalarm auf Sensoradresse 0 zu schicken, Sinn ist, das dann ProfiMC
User mit HFM-3 Mlink Modul dann zumindest Warnungen eben nicht nur bei einer einzigen Spannung
( im Allgemeinen RX-Spannung ) haben, zudem werde ich auch eine weitere Spannungsmessung für
z.B. den Flugaccu einbauen, der auch mir überwacht wird ( das ist keine Sache ).

MPX kommt ja nicht mit dem Telemetriedisplay in die Füße... ;-) .
Zudem ist das für mich eh das wichtigste an Telemetrie - sinnvolle Warnungen, nicht nur Spielerei.
( Naja, meine Telemetriespielereien habe ich eh, ein Flieger hat von Spannung bis Staudruckspeed fast
alles onboard, nur ( noch ) kein GPS :D - das Ganze mit Sprachausgabe durch wstech in Royal Pro )

Also es stagniert nicht ;-)

Bernd

Sebastian St.
07.01.2012, 11:24
Ob die Schwimmer Mechanik auf Dauer funktioniert muss dann die Praxis ergeben.



Hi ,

ich habe in meinem Benzintank einen Korkkorken ( der Wein war lecker ;) ) als Schwimmer , funzt seit über 8 Jahren problemlos . An dem Schwimmer ist ein GFK Stab befestigt , der in einem Schau(glas)schlauch sichtbar ist , ähnlich wie die Gießanzeigen bei Hydrokulturpflanzen .

ingo_s
30.03.2012, 10:57
Hi,

dieses Jahr bin ich zwar etwas später dran, aber nun sind die Multinutzen Leiterplatten meiner Sensoren endlich angekommen.
800403

Darauf sind 5 verschiedene Sensoren.
Als Update:
1. Lipo-Saver mit Strom (bis 120A) und Drehzahlmessung bis 6 Zellen optional Höhe oder Vario (ATmega168)
2. Speed-Sensor nun mit optionalem MS5611 Vario-Sensor bestückbar oder nur als Vario/Höhe einsetzbar (Tiny85)
Neue Versionen:
3. Lipo-Saver bis 4 Zellen und max. 50A Strommessung (klein und wenig Bauteile) (Tiny84)
4. BEC Überwachungs-Sensor, BEC Spannung, Strom optional Temperatur oder 2. Spannung (Tiny85) Dieser Sensor soll ganz kurze Spannungseinbrüche und Stromspitzen erfassen und synchron mit dem MSB Abholzylus arbeiten, so das diese Daten vom zukünftigen MPX-Logger erfasst werden können.

5. Dann ein Sensor mit STM32F103 für den Einstieg in die ARM3 Umgebung ausgeführt als Lipo-Saver für Zelle 1-6 oder 7-12, Strom, Drehzahl, Temperatur optional Höhe/Vario. Das ist aber als langfristige Beschäftigung eingeplant, zuerst werden die AVR Version fertiggestellt.

Die Lipo-Saver Funktion meiner Sensoren zeigt die kleinste Zellenspannung, die Akku Spannung und vor dem Start den Ladezustand an. Die Schutzfunktion regelt den Antrieb belastungs abhängig runter und hat eine gleitende (einstellbar) Vorwarnschwelle.

Bei dieser Gelegenheit möchte ich nochmal für die anderen Sensor-Entwickler auf die universelle Parametrier Lösung hinweisen.
Stephan hat eine super schöne PC-Lösung dafür entwickelt, die die internen Einstellmöglichkeiten des Sensors sehr schön anzeigt. Gut zu sehen in dem angefangenem Blog http://sensiq.blogspot.de/. Von mir gibt es die im Anfang des Threads beschriebene Lösung mit der kleinen umprogrammierten Box und eine PC-Minimallösung.

Gruß Ingo

Bernd FMC
30.03.2012, 11:16
Hallo Ingo ( und die anderen ),

jetzt wo mein letzt verletzter Daumen fast wieder ok ist, sollte ich ja mal
die Papierform meiner Sensoren auch in Epoxy wandeln.

Ich hatte in den Varianten die Einzelzellenmessung für nicht so wichtig erachtet,
aber in den letzten Flügen das ( bei älteren 4S Accus ) doch wieder revidiert.

Also geht´s zuerst wohl doch an das "OP-Grab" ( Ingo weiß was ich meine )
Und das für 10S :eek: .

Für die Strommessung warte ich noch auf meinen "INA" Stromshuntbaustein.

SenderHF-Modulseitig gibts im Protokoll wohl jetzt auch ne Checksumme.

Gruß Bernd

ingo_s
01.04.2012, 11:18
Hallo Bernd,

ja die Einzelzellen Überwachung kann schon mal in der Praxis recht wichtig werden und Schaden verhindern. Für eine wirklich aussagekräftige Bewertung der Spannung muß diese aber lastabhängig betrachtet werden.
Wenn man schon die Zellenspannung misst, kann man auch noch so schöne Sachen wie Ladezustandsprüfung beim Einschalten machen.

Dein OP-Grab ist allerdings nicht so mein Ding, das sind mir zu viele Bauteile und ich kann nur in der Hardware kalibrieren. Allerdings sind 10S aber auch schon eine Herausforderung das über einen uP mit ausreichender Genauigkeit zu machen. Ich bin mal gespannt wie sich da der ADC des STM32F103 mit seinen 12 Bit Auflösung in der Praxis eignet. Bis zum Sommer werde ich das wohl wissen, die Leiterplatte liegt ja schon hier.

Gruß Ingo

Bernd FMC
01.04.2012, 11:50
Allerdings sind 10S aber auch schon eine Herausforderung das über einen uP mit ausreichender Genauigkeit zu machen. Ich bin mal gespannt wie sich da der ADC des STM32F103 mit seinen 12 Bit Auflösung in der Praxis eignet. Bis zum Sommer werde ich das wohl wissen, die Leiterplatte liegt ja schon hier.

Gruß Ingo

Eben, deshalb das "Grab" - ich mach jetzt erst mal ne kleine Variante fertig ( für 3S im 450er Heli )

Bernd

Bezugsquellen hab ich dank deiner Info jetzt ja, dumm ist nur: der eine hat das, der nächste das :eek: .

Für das OP Grab hab ich aber alles schon hier.

ingo_s
01.04.2012, 14:07
Das ist der kleinste Kombi-Sensor, für E-Antriebe mit Lipo-Akku, der neuen Leiterplatten Auflage.
Hier ist nun der bestückte Prototyp zu sehen (ich habe ihn mir als erstes vorgenommen):

801399 801398

Mit dem Tiny84 und nur 5 Spannungsteilern ist die Bauteilgröße und deren Anzahl noch überschaubar und sollte für etwas in SMD löten geübte Nachbau-Interessenten noch gut bestückbar sein. (der kleine Quarz muss nicht sein).

Weiteres demnächst hier....

Gruß Ingo

Bernd FMC
01.04.2012, 16:17
Teils schwer zu bekommen, ich hab welche gefunden, aber rel. viel Mindestbestellwert, wer braucht noch welche ?
( ist der 168er = "HV" )

Bernd

ingo_s
01.04.2012, 16:30
Hi Bernd,

INA138 habe ich nachbestellt, sind für 10S aber nicht geeignet.
INA168 benötige ich demnächst auch, hast Du die gegenüber HBE noch wo anders entdeckt?

Übrigens muß der 0-Offset einmal in der Software abgeglichen werden.

Gruß Ingo

Bernd FMC
01.04.2012, 16:38
straschu Elektronik

Ok, wenn du auch welche brauchst ordere ich einfach mehr !

ich will zuerst aber LV Sensoren bauen, das geht mit den 168 ja wohl auch.

2.14 / Stk, evt. excl. Märchensteuer

Bernd

Bernd FMC
01.04.2012, 16:49
nun habe ich die letzten Sachen in Bestellung laufen.

0.002 R´s habe ich dann von dem CSD Laden, die 2W Variante.

Vorgesehen ist ein ca. max 80A ( für max 6S ) und ein max 100A ( für 10-12S ) Sensor.

Die Strommessung muss ich aber sicher noch erst austüfteln, wie das genauest möglich ist.

0 Offset, meinst du eine minimal vorhandene Spannung am INA-Out ?

Ich wollte eh entspr. Ströme durchjagen und messen wie linear das ist.

Bzw. welche Spannung am ADC dann welchem Strom wirklich entspricht.

Gruß Bernd

KurtHarders
01.04.2012, 18:33
INA138 habe ich nachbestellt, sind für 10S aber nicht geeignet.
INA168 benötige ich demnächst auch, hast Du die gegenüber HBE noch wo anders entdeckt?

Hallo,
bei Farnell gibt es beide:
INA138 2,35€, 1,77€, 1,33€ (1, 10, 100) + Mwst.
INA168 3,58€, 2,53€, 2,10€ (1, 10, 100) + Mwst.
Grüße, Kurt

Bernd FMC
01.04.2012, 18:43
Dann gibts die ja doch noch noch hier und da.

Ich habe mir 17 Stück bestellt (168) weil das dann mit den anderen Teilen die Mindestbest.menge gab.

Der Preis scheint ja ok.

Alle brauche ich nicht, evt. kann ich ja welche abgeben.

5-6 Combisensoren baue ich aber sicher selber für mich, dazu localer Vereinsbedarf.

Gruß Bernd

KurtHarders
01.04.2012, 20:06
Hallo,
welche Tools, Bibliotheken... gibt es für Nicht-Arduiono-Nutzer und wo? Ich habe die Protokollbeschreibung bei MPX angefragt, mal sehen, wann die kommt. Aber bei den Sensoren muss man das Rad ja nicht neu erfinden. Mich würde z.B. der Stromsensor interessieren.
Grüße, Kurt

KurtHarders
01.04.2012, 20:08
Hallo,
da Farnell ja nur an Gewerbetreibende verkauft, das Angebot, im Pool zu bestellen. Farnell ist bei Einzelstücken zwar recht teuer, aber die Verfügbarkeit und Liefergeschwindigkeit ist unglaublich gut. Und bei größeren Stückzahlen normalisieren sich die preise ;).
Grüße, Kurt

ingo_s
01.04.2012, 21:10
@Bernd
Der INA138 hat laut Datenblatt eine Offset Voltage von +/-2mV, ist halt nur ein modifizierter OP-Amp. Bei max. 100mV Input sollte man diesen schon ausmessen für die Korrektur des Ausgangswertes.

@Kurt
Bei mir die klassische "C" Umgebung AVR Studio 4 mit WinAVR (GCC) und der "C" WinAVR Lib und dem Dragon fürs Debuggen im Target.
Für die MSB Anbindung und die typischen Sensor Funktionen habe ich mir eine eigene Funktionslib erstellt inclusive einer universellen Parametrierung (siehe Anfang diesesThreads). So kann ich schnell neue Varianten und Funktionen realisieren und muß nur die Sensor Seite anpassen.

Gruß Ingo

KurtHarders
01.04.2012, 22:05
Hallo Ingo,
bin ich blöd oder blind? :confused: Ich finde in diesem ganzen Thread keinen Link auf Deine Bibliothek oder das Parametrierungsprogramm. Ich würde gern an Sensorprojekten mitarbeiten und evtl. auch auf der Anzeigenseite etwas tun, auch wenn die von MPX nicht offengelgt wird.
Grüße, Kurt

ingo_s
01.04.2012, 22:15
Hi Kurt,

weder noch, kein Link nur eine allgemeiner Hinweis/Beschreibung, das so etwas existiert.
Schau mal für die PC-Seite bei http://sensiq.blogspot.de/ vorbei.

Infos kannst Du per PN haben.

Gruß Ingo

Bernd FMC
01.04.2012, 23:05
@Bernd
Der INA138 hat laut Datenblatt eine Offset Voltage von +/-2mV, ist halt nur ein modifizierter OP-Amp. Bei max. 100mV Input sollte man diesen schon ausmessen für die Korrektur des Ausgangswertes.

Gruß Ingo

... mach ich ja auch, sobald ich den habe ;-)

Ich neige in solch Sachen eher zur Übertreibung ...

Bernd

ingo_s
20.05.2012, 20:10
Hi,

mein kleinster Kombi-Sensor (siehe #34) hat nun den Praxistest mit Erfolg absolviert.
Auch die neue Funktion der Restkapazitäts Berechnung aus der kleinsten Zellenspannung und die Akku Wiedererkennung funktioniert nach einer kleinen Anpassung sehr zufriedenstellend.

825397 825398

Den Shunt Bereich habe ich abgetrennt, damit komme ich in meinen Modellen besser klar.

Gruß Ingo

Bernd FMC
20.05.2012, 21:33
Cool - klein ;-)

R in dem Shunt ? 2mOhm ? oder was hast da ?

Accuwiedererkennung ? - Bitte erklären was du da gemacht hast !
( Bin grad am überlegen wie/warum/was du wiedererkennst "BID ;-) " )

INA 168 schon getestet ( nat. nicht im kleinen Sensor ) ?

Bernd

ingo_s
20.05.2012, 22:31
Shunt ist 1mOhm aufgebaut aus 2x mOhm, oben und unten je einer. Die 2,5W Verlustleistung bei 50A teilen sich so auf die beiden 2W Shunts auf.

Seit einem guten Jahr ermittle ich beim Einschalten den Ladezustand in Prozent (wie die üblichen Lipo-Checker) aus der kleinsten Einzelzellen-Spannung, bis vor kurzem aber nur als Info und mit Alarmschwelle ausgestattet.
Nachdem festgestellt habe, das das recht gut (im Vergleich zu einem Lipo-checker mit besserer Auflösung) funktioniert kam der nächste Schritt/Versuch einen vorher teilentladenen Akku an seinen Werten wiederzuerkennen. Im stromlosen Zustand speichere ich nach einer gewissen Zeit die Werte ab und vergleiche sie beim Einschalten mit einer Toleranzgrenze ob der vorherige Akku wieder angesteckt wurde und führe dann die ehemalige Restkapazitätsberechnung weiter. Soweit im Groben, intern sind noch ein paar Feinheiten mit im Spiel.

Den INA168 brauche ich nicht testen, bis auf die Spannungsfestigkeit ist der ja mit dem INA138 identisch und den habe ich schon lange im Einsatz ;-)
Der INA168 kommt auf meinen Multi-Sensor mit dem STM32F1xx für den Einsatz bis 12S.

Gruß Ingo

Bernd FMC
21.05.2012, 05:28
Seit einem guten Jahr ermittle ich beim Einschalten den Ladezustand in Prozent (wie die üblichen Lipo-Checker) aus der kleinsten Einzelzellen-Spannung, bis vor kurzem aber nur als Info und mit Alarmschwelle ausgestattet.

Den INA168 brauche ich nicht testen,.

Gruß Ingo

Danke für die Info´s, den Ladezustand aus der Spannung herauszurechnen hielt ich bisher für zu gewagt, wenn das aber so funktioniert
ist das ne tolle Sache - d.h. auch ein teilgeladender Accu kann genutzt werden, ohne die Kapazitätsübernahme, welche auch nur
funktioniert, wenn der Accu der gleiche bleibt ( MPX Stromsensor, der nicht resettet wird, oder Linkvario dem man die Kapazitätsübernahme
bestätigt - und bei dir wird denn eben auch bei falschem Accu ( leeren gegriffen ) schon vor dem Start gewarnt.

Tolles Feature, was sonst wohl noch keiner hat ;-) .

Ina nicht Testen, hast Recht :mad: ist ja nur die Version mit der höheren Spannungsbelastbarkeit.

Ich hab jetzt erst ( mal wieder ) ne harte Woche vor mir, keine Zeit / Kopf für Elektronik/Microchips :cry: .

Bernd

ingo_s
25.05.2012, 20:16
Hi,
besteht hier Interesse an C-Sourcecode für ATMega/ATtiny eines Muster/Demo Sensors für das AVR Studio4?

Ich dachte an eine minimal Verson, die aber schon das universelle Parametrier-Verfahren mit abdeckt.

Was soll die minimal Version ausser der MSB Anbindung beinhalten?
Beispiele einer Spannungs-,, Temperatur-, Drehzahl-Messung ...?
Soll auch der ATtiny mittels Software UART abgedeckt werden?

Bei entsprechender Resonanz bin ich bereit so einen Source-Code zur freien Verfügung zusammenzustellen.

Gruß Ingo

foobar
25.05.2012, 20:25
Guten Abend Ingo,

ja, ich habe auf jeden Fall Interesse (mir reicht ATMega)! Und vielen Dank fuer das Angebot,

Bernd FMC
25.05.2012, 21:12
Bei entsprechender Resonanz bin ich bereit so einen Source-Code zur freien Verfügung zusammenzustellen.

Gruß Ingo

Gute Sache für Arduino User um einzusteigen, wäre ich noch bei Facebook würd ich gefällt mir
klicken ;-)

Mein Microchip Pic18 Code ist evt. noch zu Spagetti und ASM als das ich den derzeit veröffentlichen
würde, zudem habe ich auch die selben Bedenken bzgl der Nutzung oder auch der Kommentare
der "Experten" ;-) .

Zeit ist eh keine im Moment bei mir, aber im Grunde sollte das insgesamt eine Art Open Source
werden, das würde die Sensorik weit voranbringen.

Hochachtung für deine Arbeit Ingo.

Bernd

landebahnpflug
25.05.2012, 22:36
bei code gilt doch
take it or leave it
but if you take it try to love it

ingo_s
16.06.2012, 12:14
Hi,

die Resonanz war zwar nicht besonders groß, aber ich habe nun doch mal mit dem Source-Codes eines Demo Sensor angefangen, den ich dieses WO fertigstellen will.
Basis ist ATmega88/168/328 entwickelt mit AVR Studio4 in "C" bzw. WinAVR.
Der Sensor misst eine Spannung und eine Temperatur (mittels KTY11), die universelle Parametrierung ist natürlich auch integriert.

Der "C" Grundgerüst lässt sich natürlich auch an andere uP's anpassen.

Gruß Ingo

Flying Tiger
16.06.2012, 12:48
Hi,
besteht hier Interesse an C-Sourcecode für ATMega/ATtiny eines Muster/Demo Sensors für das AVR Studio4?

Ich dachte an eine minimal Verson, die aber schon das universelle Parametrier-Verfahren mit abdeckt.

Was soll die minimal Version ausser der MSB Anbindung beinhalten?
Beispiele einer Spannungs-,, Temperatur-, Drehzahl-Messung ...?
Soll auch der ATtiny mittels Software UART abgedeckt werden?

Bei entsprechender Resonanz bin ich bereit so einen Source-Code zur freien Verfügung zusammenzustellen.

Gruß Ingo


Hi,

also ich hätte Interesse an dem Quellcode. :)


Gruss
Aleks

JamBo_Ac
25.08.2012, 17:03
Hi,

also ich hätte auch großes Interesse an dem Quellcode. :-)

Lg Philipp

ingo_s
25.08.2012, 20:03
Hi,
den Source Code (ATmega) habe ich fertiggestellt und auch getestet. Erstellt ist er mit AVR Studio4 und WinAVR.
Im Moment liegt er noch nicht auf einem Server zum download, daher einfach mit PN (Email Rückadr.) an mich anfordern.

Falls jemand unbedingt eine ATtiny Anbindung haben will, kann ich dazu HIlfestellung geben bzw. den alternativen UART Code bereitstellen. Es wird allerdings ein 8bit timer belegt und die anderen ISR's müssen den Interrupt sofort wieder freigeben (Attribut ISR_NOBLOCK).

Schaut nicht nur wegen der Parametrisierung auch bei Stephan "http://sensiq.blogspot.de/" vorbei.

Gruß Ingo

cyblord
05.09.2012, 18:24
Gibts eigentlich irgendwo Infos zum Protokoll der Verbindung Sender->Telemetrie-Display?

Grundsätzlich ist das ja kein Hexenwerk, normalerweise wird ein 20 Byte langer Datensatz, alle 100ms gesendet:

02 00 30 34 34 00 40 06 31 78 00 41 8C 00 00 00 00 00 AB 03

Ab Byte 9 (hier 0x31) beginnen die Sensorwerte. Es werden immer 2 Werte (=2x 3 Bytes) übertragen. Format ist identisch mit dem vom SensorBus.
Soweit so gut. Jeder Datensatz beginnt mit 2 (Ascii STX) und endet auf 3 (Asci ETX). Das vorletzte Byte könnte eine Checksumme sein.

Nur manchmal bekomme ich auf dem 2. Sensorwert nur Müll und manchmal werden auch 21 Bytes gesendet.

02 00 30 34 34 00 40 06 51 A0 00 61 B4 00 00 00 00 00 1B 3B 03

Hat jemand weitergehende Infos dazu?

viele Grüße
cyblord

gecko_749
05.09.2012, 19:27
Moin,

weil den Bytes 0x02 und 0x03 eine besondere Bedeutung zukommt werden sie maskiert. Daher auch die unterschiedlichen Datensatzlängen.

Gruß

gecko

cyblord
06.09.2012, 00:24
Moin,

weil den Bytes 0x02 und 0x03 eine besondere Bedeutung zukommt werden sie maskiert. Daher auch die unterschiedlichen Datensatzlängen.

Gruß

gecko

Hallo, danke für die Antwort.
Was meinst du mit "maskiert"? Sowas wie escaped? Aber warum nur manchmal? In meinem Beispiel kommt die 0x3 in den Nutzdaten nicht vor, also müsste hier nichts escaped werden.

Und warum bekomme ich manchmal beim 2. Sensorwert eine 0-Klasse?

Beispiel:
2 0 30 34 34 0 0 6 88 1b 22 0 93 ee ff 0 0 0 0 57 3

Hier habe ich für Wert 1: 88 1b 22 und für Wert 2: 0 93 ee was fehlerhaft ist, da es eine Klasse 0 nicht gibt und auch kein Sensor auf dem Bus eine Sonderfunktion ausgeben will. Außerdem gibt es IMO keine Unterklasse 0xee.

gruß cyblord

gecko_749
06.09.2012, 00:40
Moin,

in den Daten darf es kein 0x02 oder 0x03 geben da diese Zeichen das Datensatzende / -anfang bedeuten würde. Sie werden durch 2 Bytes ersetzt. Welche das sind findet man recht einfach wenn man sich die Daten mal genau anschaut.

Zu Deinem 2. Problem habe ich keine Lösung - nur den Hinweis das einige Femdsensorhersteller auch Werteklassen verwendet haben die nicht spezifiziert waren und MPX die Spec irgendwann noch mal speziel für die Turbinen-ECUs erweitert hat. Irgendwo in dem Umfeld könnte die Erklärung liegen.

Gruß

gecko

cyblord
06.09.2012, 01:05
Moin,

in den Daten darf es kein 0x02 oder 0x03 geben da diese Zeichen das Datensatzende / -anfang bedeuten würde. Sie werden durch 2 Bytes ersetzt. Welche das sind findet man recht einfach wenn man sich die Daten mal genau anschaut.

Das Prinzip ist mir natürlich vertraut, die konkrete Umsetzung in diesem Fall ist mir allerdings noch nicht klar. Werde mir die Daten nochmal in Ruhe ansehen. Allerdings synronisiere ich im Moment sowieso auf die Pause zwischen den Datensätzen, das geht ganz gut. Allerdings hätte ich das Protokoll schon gerne komplett verstanden.

Danke dir schonmal für deine Hilfe.


gruß
cyblord

ingo_s
15.09.2012, 10:56
@cyblord
Was willst Du denn mit denn Daten machen? Besondere Alarm-Töne oder sogar eine haptische Anzeige?

Gruß Ingo

ingo_s
15.09.2012, 11:11
Damit auch mal wieder etwas Hardware zu sehen ist :cool:
Hier ein Prototyp eines speziell auf BEC Messung ausgerichteten Sensors.

Spannungs Minimum und Strom Maximum (gemessen im 10ms Raster) wird Zyklus synchron zum MSB Zyklus erfasst und ausgegeben. Stromverbrauchsmessung wird natürlich auch gemacht, der Messbereich ist 5A oder 10A je nach Bestückung. Ein weiterer freier Analog Eingang ist für Temperatur Messung vorgesehen, kann aber auch für eine 2. Spannungsmessung vorgesehen werden.

In Verbindung mit Logging der MSB Daten hat man dann die Stromspitzen und Spannungseinbrüche im 100ms Raster für weitere Auswertungen.

Gruß Ingo

cyblord
15.09.2012, 19:13
@cyblord
Was willst Du denn mit denn Daten machen? Besondere Alarm-Töne oder sogar eine haptische Anzeige?

Gruß Ingo

Naja erstmal nur ein externes Telemetriedisplay. Mit Beleuchtung und Touch evt.
Aber ehrlich gesagt, so ganz schlau werd ich aus dem Protokoll noch nicht. Der Witz ist, ich bekomme die meiste Zeit alle Werte korrekt aus dem Sender raus. Aber manchmal passieren komische Dinge. z.B. die Temperatur ist bis ca. 26 Grad kein Problem, danach springt sie auf 345 Grad. Und das Obwohl ich a.) die Temperatur selber reingebe (also die Rohdaten ja kenne) und b.) die Temperatur auf dem internen Display völlig korrekt dargestellt wird. Nur im Telegramm aus dem Sender raus, werde eindeutig "falsche" Daten gesendet.
Dann werden manche Adresse irgendwann gar nicht mehr übertragen. Bzw. dann wohl an Stellen im Datenstrom die ich nicht kenne.

gruß cyblord

Patman
08.01.2013, 16:38
Hallo zusammen!

Dank der Unterstützung einiger User aus dem Forum versuche ich gerade den Einstieg in die Sensor-Entwicklung.
Mein Ziel ist ein einfaches aber brauchbares Vario.
Zur Kommunikation des AVR-uC (ATtiny oder ATmega) mit den Druck-Sensoren wird oft das I2C-Protokoll verwendet. Hat jemand eine Quelle für einen schönen Treiber für mich?

Grüße,
Patman

ingo_s
08.01.2013, 17:10
Ich habe da einen Software I2C Treiber für beliebige Pins und eine Lib für den BMP085 incl. Höhen und Vario-Funktion.

Gruß Ingo

M.E.
18.02.2013, 12:33
Hallo Ingo,

ich wäre auch an dem Mustersourccode interessiert,
Wo kann ich den herunterladen?

Viele Grüße

Micha

ingo_s
22.11.2013, 18:45
Hi,
ist jetzt im Winter noch jemand aktiv im Sensor-Bau oder hat es geplant? Es war ja sehr ruhig geworden hier.

Im Laufe des Jahres habe ich meine Lipo-Saver Kombi-Sensoren noch mit einem Akku Management ausgestattet und erfolgreich getestet. Es erkennt den zuletzt vorher angeschlossenen Lipo und führt die Verbrauchsmessung fort. Zusätzlich wird bei einem unbekannten Akku aufgrund der Lipo-Check Funktion von einer berechneten Restkapazität ausgegangen.
Von den Atmel basierten Sensor Versionen habe ich genug Varianten erstellt, die meine meine Anforderungen abdecken.

Um erweiterte Ansprüche abdecken zu können setze ich nun auf einen ARM Core0/Core3 uP. Im Moment ist die STM32 Linie mein Favorit, glücklicher Weise gibt es jetzt auch kleine Gehäuse-Varianten wie TSSOP20 und LQPF32. Eine Multisensor LP mit STM32F103 liegt schon bestückt seit April hier rum und wartet geduldig auf die Firmware. Einige Basics, wie MSB-Anbindung, Parametrierung, ADC usw. funktionieren schon im Teststadium.

Hat hier noch jemand auf die STM32 Linie gesetzt?

Gruß Ingo

Bernd FMC
23.11.2013, 06:06
Meine Sachen stagnieren, nicht genug Zeit und im Grunde ist schon alles so günstig zu bekommen das es kaum lohnt.

In lockerer Produktion habe ich nur eine Art Multimate für PedelecAccuüberwachung basierend auf MSB.
Status seit Wochen aber Layout fertig - rel. klar zum ätzen ( mach nur 1 Stück davon ).

Die nächste Zeit wird hier aber wohl mal etwas entspannter - ich mach das dann aber nur just for Fun.

Meine (teilfertige) Software ist für Microchip, Pic18 der Proc meiner Wahl.

@ Ingo: weisst ja - alle Modelle eh komplett ausgestattet ;-) .

Ein wenig muss man auch sehen wie die Profi TX mit der Zählweise der Sesnsoren bei Kapa zurecht kommt,
MPX arbeitet da ja "anders" herum als die anderen.

Souffleur dito, ich hab die Dinger ja bald, dann kann ich im kalten Winter ja spielen :D .
Aber Shocky will auch ein neuer genaut werden, Haus fordert noch Zeit etc. .... .

Gruß Bernd

ingo_s
23.11.2013, 10:18
Bei MPX wird immer nur der Messwert, der von den Sensoren kommt, angezeigt.
Das die Kapa Anzeige nur runter rechnet ist Sache des MPX Strom-Sensors, bei meinen Sensoren kann ich mir auch alternativ den Verbrauch (mit Alarmwert) anzeigen lassen.

Die Profi TX hat bei den Telemetrie Werten aber eine schöne Erweiterung, bei Drücken der "Enter" Taste wird statt des aktuellen Wertes Minimum und Maximum des Wertes angezeigt.

Gruß Ingo

Reinhardt Werbik
19.01.2014, 17:49
Hallo zusammen,

ich hole diesen Thread mal wieder hoch.
Ich habe mich vor ca. 4 Jahren in die Assembler Programmierung der Atmel AVR uCs eingearbeitet, um eine Steuerung für unseren Dusch-Lüfter zu programmieren.
Also STK500 Board zugelegt, etliche uCs als Anfangsbestand und, wie zu alten Studienzeiten, mit Assembler losgelegt.
Nach einiger Eingewöhnungszeit hat das dann alles auch gut geklappt, irgendwann lief die Steuerung auf dem Entwicklungsboard wie gewünscht.
Mangels Zeit ist dann leider das Ganze wieder eingeschlafen, und eine entsprechende Hardware wurde nie gebaut. :cry:
(Vielleicht hole ich das dann ja jetzt irgendwann mal nach.)

Soweit so gut, mittlerweile bin ich M-Link Nutzer, und was liegt da näher, als eigene Sensoren mit den Atmel uCs zu realisieren.
Ich habe mich daher entschlossen, genau das zu tun, und zwar in Assembler, um wieder in dieses Thema reinzukommen.
Mir schwebt ein kleiner E-Flug Sensor für Strom, Spannung und Kapazitätsentnahme als erstes Projekt vor. :)

Bin gerade dabei, einen entsprechenden Programmrahmen zu erstellen, vorerst noch mit Dummies (sprich konstanten Werten) für die Messparameter.
Es soll erst mal um die Implementierung des MSB Protokolls gehen, als Einarbeitungsprojekt sozusagen.
Daher will ich das jetzt auch nicht irgendwo abkupfern, sondern von Grund auf selbst erstellen.
Wenn dann meine Royal Pro die konstanten Werte auf dem Display anzeigt, werde ich mich an die Implementierung der eigentlichen Messroutinen machen.

Als Entwicklungsumgebung benütze ich nicht das aktuelle Atmel-Studio, sondern das gute alte AVR Studio 4.
Das kenne ich von früher, und eine Front zum Kämpfen reicht mir erst mal.

Ich werde evtl. das Layout des Programms dann hier einstellen, um vor der vollständigen Umsetzung ein wenig Feedback zu bekommen.


Gruß
Reinhardt

ingo_s
19.01.2014, 18:07
Hallo Reinhardt,

schön das Du auch Lust hast MSB Sensoren selber zu entwickeln.
Das AVR Studio4 ist schon ok, ich nutze das auch. Der Vorteil ist bei diesem das man mehrer Instancen davon mit unterschiedlichen Projekten gleichzeitig öffnen kann.
Das geht beim Studio 6 leider nicht mehr.

Aber das mit dem Assembler würde ich noch mal überdenken, das ist viel zu viel Aufwand. Nach den ersten Gehversuchen mit dem WinAVR vor einigen Jahren kommt bei mir Assembler höchsten noch für ein wenig Inline Optimierung zum Einsatz.

Grüße
Ingo

Reinhardt Werbik
19.01.2014, 19:20
Hallo Ingo,

Danke für Dein schnelles Feedback.

Ich möchte aus verschiedenen Gründen mit Assembler anfangen.

Erstens habe ich damit schon eine gewisse Erfahrung, während sich mein Umgang mit höheren Sprachen in den letzten Jahren auf Visual Basic zur Programmierung von Datenbanken beschränkt hat.
(Alles andere wie Fortran, Pascal, etc. ist eine gefühlte Ewigkeit her.)
Anders ausgedrückt, in C/C++ müsste ich mich erst mal von Grund auf einarbeiten, was ja später durchaus noch kommen kann/wird.

Zweitens lernt man durch die Programmierung in Assembler zwangsläufig die Hardware des Mikrocontrollers sehr gut kennen.
Das halte ich für einen unschätzbaren Vorteil, wenn man später auch andere Sachen mit den Dingern machen will.

Und schließlich glaube ich, dass für eine MSB Implementierung mit U/I Messung eine höhere Sprache keinen wirklichen Vorteil bringt.
Bei mehr algorithmisch orientierten Anwendungen (z.B. Ladegeräte) sieht das natürlich anders aus.

Außerdem macht es mir Spaß und erinnert mich an meine Studienzeit. :D

Mal sehen, vielleicht ändere ich ja meine Meinung, wenn ich mich irgendwo festgebissen habe.


Gruß
Reinhardt

Bernd FMC
20.01.2014, 05:40
Gegen Ingo´s Tipps gegenanzuschreiben ist wohl nicht sinnvoll ;-) habe ich auch nicht vor.

Mich hat ja die Zeit überholt, zu wenig Luft um wirklich weiterzumachen, die fertige Hardware funktioniert
und alle Modell sind eh bestückt.

Ich habe einen Teil des Programmcode schon recht lange am laufen ( aber für Microchip, nicht Atmel ),
ich bin auch eher Assemblerlastig und sehe es auch als Gehirnjogging und nicht als Muss.

C(++) ist sicher für größere Programme sinnvoll, Assembler ist "so herrlich nah an der Maschine" hat auch was.

Ich spiele ( s.o. ) eher nur damit - und mein Leben ist aktuell im Umbruch ( eher positiv ) und daher sind die
Pioritäten andere - meine layoutete Platine ( die bereit zum ätzen ist ) war für eine Sache die nun gar nicht mehr
nötig ist, ich werde die aber trotzdem fertigmachen, um die dann als "Experimentalboard" nutzen zu können.

Bei Reinhardt sehe ich auch eher den Spaß daran sich damit zu beschäftigen, das ist auch mein Ding !

Gruß Bernd

Reinhardt Werbik
20.01.2014, 08:26
Bei Reinhardt sehe ich auch eher den Spaß daran sich damit zu beschäftigen, das ist auch mein Ding !

Ich sehe, Bernd, Du hast mich 100% ig verstanden.

Dennoch, ich werde mal anfangen, mich ein wenig mit C/C++ zu beschäftigen.
Wenn ich das MSB Protokoll mit Assembler am Laufen habe, wird man weitersehen.
Vielleicht setze ich das Ganze dann mit C neu auf und mache die eigentlichen Sensorfunkitonen dann gleich damit.
Dauern wird das alles ohnehin, da auch mich mein Job immer wieder einholt.


Gruß
Reinhardt

gecko_749
20.01.2014, 11:42
Hi Reinhardt,

wenn Du einen einfachen Einstieg in C/C++ für µC haben möchtest dann schau dir Arduino an.

Und direkt Speicherzellen bearbeiten oder inline Assembler geht dann trotzdem noch.

Das ist auf jeden Fall ein brauchbares System um mit begrenzter Zeit ein laufähiges Ergebnis zu bekommen. Und es gibt Experimentierboards in vielen Größen.

Gruß

gecko

Reinhardt Werbik
20.01.2014, 13:13
Hallo gecko,

Danke für Dein Feedback, aber ich werde natürlich das vorhandene STK500 verwenden, zunächst mal mit AVR Studio 4.
Da das neuere Atmel Studio die C Umgebung bereits integriert hat, könnte man ja dann überlegen, für die ersten Versuche in C auf das Atmel Studio umzusteigen.
Für die Assemblerprogrammierung ist das ältere AVR Studio 4 völlig ausreichend, es hat halt nicht soviel Ballast an Board, den ich nicht brauche.

Grundsätzlich halte ich es für einen großen Vorteil, die Umgebung vom Hersteller des Controllers zu benutzen.
Man hat dann alles aus einer Hand, und der Hersteller hat natürlich ein vitales Interesse, seinen Kram up-to-date zu halten.
Davon kann man dann eben auch als "Privatentwickler" profitieren, die Fähigkeit mit professionellen Werkzeugen umzugehen vorausgesetzt.


Gruß
Reinhardt

landebahnpflug
20.01.2014, 16:59
was aber bedingt das man alles selber machen muss also auch was andere schon erledigt haben inclusive aller irtümer...
also wenig effizient.
aber ich bin bei dir manche Umgebungen sind schon überfrachtet....

Bernd FMC
20.01.2014, 17:27
Hallo Jan,

es muss nicht immer effizient sein.. Hauptsache man hat Spaß.

Dümmer wird man dadurch ja nicht :D .

Bernd

Reinhardt Werbik
20.01.2014, 17:29
was aber bedingt das man alles selber machen muss also auch was andere schon erledigt haben inclusive aller irtümer...
also wenig effizient.
aber ich bin bei dir manche Umgebungen sind schon überfrachtet....
Genau, aber aus Fehlern lernt man bekanntlich am meisten.
Und effizient muss ich Gott sei Dank nicht sein beim Hobby. ;)


Gruß
Reinhardt

Reinhardt Werbik
22.01.2014, 14:52
Hallo zusammen,

ich habe die Grobstruktur des Programms für den Sensor jetzt mal folgendermaßen implementiert.
(den üblichen Assemblerkram wie Registerdefinitionen, Initialisierung, Interrupt Vektoren, etc. lasse ich hier weg.)

Für den Buszugriff wird der HW USART des uC benutzt, konnte es mir gerade noch verkneifen, das in der SW zu machen,
obwohl man es dann leichter auf uCs ohne HW UART (ATtiny Typen) portieren könnte.

Es wird der RX Complete Interrupt des USART benutzt, um die Anforderung vom Master zu bearbeiten, die entsprechende ISR macht folgendes:

- Einlesen des empfangenen Bytes
- Prüfen, ob eine gültige Abfrage vom Master vorliegt (wenn nicht dann Ende)
- Bei gültiger Abfrage die abgefragte Adresse in einem dedizierten Register ablegen
- Ende

Alles andere erledigt die Programmhauptschleife:


Messen:
- Spannungswert ermitteln (derzeit noch eine Konstante)
- Stromwert ermitteln (derzeit noch eine Konstante)
- Mittelwert aus aktuellem und vorherigem Stromwert bestimmen (könnte man sich eigentlich sparen, aber zwecks Lerneffekt...)
- Zeitdifferenz seit letzter Ladungsbestimmung aus zugeordnetem Timer ermitteln
- Aus Strom-Mittelwert und Zeitunterschied die verbratene Ladung ermitteln und zum letzten Wert hinzuaddieren
- Timer zurücksetzen und neu starten

Ausgeben:
- Prüfen, ob eine gültige Abfrageadresse im entsprechenden Register liegt (wenn nein dann nächster Durchlauf)
- Bei gültiger Abfrageadresse den entsprechenden Wert auf dem Bus ausgeben
- Abfrageadresse zurücksetzen, damit im nächsten Durchlauf nicht erneut gesendet wird

Zurück zum Anfang



Da das MSB Protokoll ja recht simpel ist, sollte es das doch eigentlich tun, oder?
Alternativ könnte man gleich in der ISR den gerade vorliegenden Wert des angeforderten Parameters senden.
Dann würde diese aber relativ lang, was man ja eigentlich vermeiden sollte.

Leider ist mein ganzer uC HW Kram derzeit in einem großen Karton verstaut wegen Umbau in meinem Arbeitszimmer.
Daher bin ich derzeit nur theoretisch, sprich am PC unterwegs.
Das Programmlisting einzustellen bringt nichts, da es teilweise halbfertigen Code zur Implementierung des obigen Konzepts enthält.
Ein Forum ist zur detaillierten Diskussion von SW Source Code vielleicht auch nicht unbedingt optimal.
Aber Feedack zu Obigem nehme ich natürlich gerne entgegen, ggf. natürlich auch per PM.


Gruß
Reinhardt

ingo_s
22.01.2014, 19:41
Hallo Reinhardt,

da der MSB auf dem idle line timeout aufgebaut ist, solltest Du auf der Empfangsseite zwei ISR einsetzen.
Die RX ISR legt nur die Daten in einen Empfangsbuffer, startet die idl Zeit neu und macht sonst nix.
Die idle line timeout ISR prüft wieviel Zeichen lückenlos empfangen wurden und wenn es nur eines war, dann kann dieses auf Master call, Reset oder anderes überprüft werden.

Zum Senden der Sensor-Daten liegen die drei Bytes am besten direkt im richtigen Format im Speicher, so muss dann nur für eine Sende ISR die Adresse der Daten und Länge der Daten aufgesetzt werden.

Gruß Ingo

ingo_s
22.01.2014, 20:20
Hi,
damit mal wieder etwas Hardware zu sehen ist. Hier ein kleiner Multi-Sensor, aber mit dem STM32F050 in der 20pol. SSOP Version.

1109467 1109468
Funktionen:
LiPo Einzellzellen Messung, Lipo-Checker Funktion, Strom, Stromverbrauch, Drehzahl, Höhe und Vario in Verbindung mit dem MS5611 Sensor in guter Qualität.
Im Moment stelle ich die Sensoren, bei denen es Sinn macht, auf STM32 um. Jetzt, wo es die 20pol. TSSOP STM32F050 und die 32pol. TQFP STM32F051 gibt, kann man die Dinger wenigstens wieder einigermaßen löten.

Gruß Ingo

Reinhardt Werbik
23.01.2014, 08:19
Hallo Reinhardt,

da der MSB auf dem idle line timeout aufgebaut ist, solltest Du auf der Empfangsseite zwei ISR einsetzen.
Die RX ISR legt nur die Daten in einen Empfangsbuffer, startet die idl Zeit neu und macht sonst nix.
Die idle line timeout ISR prüft wieviel Zeichen lückenlos empfangen wurden und wenn es nur eines war, dann kann dieses auf Master call, Reset oder anderes überprüft werden.

Zum Senden der Sensor-Daten liegen die drei Bytes am besten direkt im richtigen Format im Speicher, so muss dann nur für eine Sende ISR die Adresse der Daten und Länge der Daten aufgesetzt werden.

Gruß Ingo
Hallo Ingo,

Danke für Dein wertvolles Feedback.
Das mit der Idle Time werde ich so machen, dadurch werden auch die beiden ISRs schön kurz.

Für das Senden hätte ich jetzt gar keine ISR benutzt, sondern in der Hauptschleife geprüft,
ob die Empfangs ISRs eine gültige Anforderung signalisiert haben, dann gesendet und anschließend die Anforderung wieder zurückgesetzt.
Die Anforderung wird durch die zweite Empfangs ISR einfach durch Setzen einer für den Sensor definierte Adresse in einem dedizierten Register signalisiert,
(falls eine solche vom Master angefordert wurde)

Das ganze funktioniert natürlich nur richtig, wenn die Durchlaufzeit der Hauptschleife nicht in die Größenordnung des Abfrageintervalls durch den Master (6 ms) kommt.
(Andernfalls könnten Anforderungen des Masters untergehen.)
Davon bin ich jetzt mal ausgegangen, spricht dann was dagegen, es so zu machen?
Wenn ja, welcher Interrupt wäre denn zu benutzen, um das Senden der Daten zu triggern?


Gruß
Reinhardt

P.S.: Deine Sensoren sehen wirklich absolut klasse aus, Hut ab.

ingo_s
23.01.2014, 18:55
Hallo Reinhardt,

wenn Du das Senden der Daten auch mit ISR machst, kannst Du ganz entspannt in der Haupschleife alles machen ohne auf Laufzeiten achten zu müssen.

Für das Senden benötigst Du zwei ISR, einmal TX Buffer empty und einmal TX shift register empty.
Die idl ISR macht wenn eine Master Anforderung vorliegt folgendes:
RX deaktivieren, Pointer auf Daten und Längencounter der Daten aufsetzen und den TX mit dem TX Buffer empty ISR scharf machen.

Die TX Buffer empty ISR sendet jeweils ein Zeichen bis der Längencounter Null ist, dann deaktiviert sie sich selbst und aktiviert die shift register empty und die idl ISR.
Die Shift register empty ISR deaktiviert den TX und sich selbst und aktiviert den RX.

Gruß Ingo

Reinhardt Werbik
23.01.2014, 20:01
Hallo Ingo,

ok, das leuchtet mir ein, wenn das Senden mit ISRs gemacht wird, kann ich mich in der Hauptschleife ganz entspannt zurücklehnen. :)
Ich muss jetzt Deine Beschreibung erst mal mit dem Datenblatt genau verinnerlichen.

Ich benutze derzeit den ATmega8, mit den Interrupts (Bezeichnungen gemäß Datenblatt) "USART Data Register Empty" und "USART Tx Complete".
Ich nehme an, das korrespondiert zu Deinen Bezeichnungen "Tx Buffer Empty" und "Tx Shift Register Empty" (in gleicher Reihenfolge), oder?

Gruß
Reinhardt

ingo_s
23.01.2014, 20:08
Hallo Reinhardt,

das sollte so in der Reihenfolge passen, es müsste aber auch im Kleingedruckten zu finden sein. Die Bezeichnungen unterscheiden sich etwas zwischen den einzelnen Typen. Den ATmega8 setze ich schon lange nicht mehr ein.

Gruß Ingo

Reinhardt Werbik
23.01.2014, 22:08
Hallo Ingo,

Danke nochmal, dann ist das erst mal soweit geklärt, und ich kann mich daran machen, das Programm weiter auszuarbeiten.
Ich werde mich dann zu gegebener Zeit sicher wieder melden, wenn die nächsten Fragen auftauchen.

Den ATmega 8 habe ich vor 4 Jahren für meine ersten Gehversuche benutzt und bin jetzt erst mal dabei geblieben.
Das wird sich sicherlich mal ändern, wenn ich die ganze MSB Mimik am Laufen habe.

Gruß
Reinhardt

Reinhardt Werbik
24.01.2014, 09:00
Die idle line timeout ISR prüft wieviel Zeichen lückenlos empfangen wurden und wenn es nur eines war,

Hallo Ingo,

wenn ich die Idle Time mit jedem empfangenen Zeichen neu starte, dann muss ich doch beim Auftreten des Timeouts bezüglich empfangener Zeichen gar nichts mehr prüfen.
Denn das Erreichen des Timeouts kann ja nur passieren, wenn eben kein weiteres Zeichen mehr empfangen wurde, da dieses ja die Zeit neu starten würde.
Oder mache ich da jetzt einen Denkfehler?

Theoretisch könnte man ja einfach den Overflow Interrupt des 8-bit Zählers nehmen, wenn man einen entsprechenden Vorteiler benutzt.
Bei 8 MHz Clock und Vorteiler 8 wären das etwa 256 us, gerade mal das Minimum.
Bei Vorteiler 64 käme man auf etwas mehr als 2 ms, ist vielleicht ein bißchen lang, obwohl m.W. kein Maximum spezifiziert ist.
Ansonsten müsste man mit dem Compare Match Interrupt des 16-bit Zählers arbeiten, Idle Time irgendwas zwischen 0,5 und 1 ms, würde ich sagen.
Ich meine, ich habe irgendwo gelesen, dass die MPX Sensoren etwa 1,6 ms warten, bevor sie die Daten zurücksenden.

Ich hoffe, ich nerve Dich nicht mit meinen vielen Fragen.;)

Gruß
Reinhardt

ingo_s
24.01.2014, 09:33
Hallo Reinhardt,

wenn die idle time mit jedem neu empfangenden Zeichen neu gestartet wird, kommt sie nur zum Ende einer Übertragung in Aktion. Bei Master Call also nach einem Byte, bei Daten von anderen Sensoren nach deren drei Byte Antwort. Alle 5 Zyklen kommt auch noch ein 2 Byte Call für das GPS, das dann mit einem längeren Datensatz antwortet.

Ich benutze vorwiegen die ATmega88/168 Serie und für die idl den 8bit Timer2 mit Output Compare auf 100 bei 4us Clock. Bei jedem empfangenem Zeichen wird einfach der Timer2 wieder auf 0 gesetzt und vorsichtshalber das OC ISR Flag gelöscht, da dieses durch Glitches beim resetten des Timers gesetzt sein kann.

Wenn Du willst kannst du es einfacher haben, mit dem Demo-Sensor von mir in "C", die Logig kannst Du dann in Assembler umsetzen.

Grüße Ingo

Reinhardt Werbik
24.01.2014, 10:22
wenn die idle time mit jedem neu empfangenden Zeichen neu gestartet wird, kommt sie nur zum Ende einer Übertragung in Aktion. Bei Master Call also nach einem Byte, bei Daten von anderen Sensoren nach deren drei Byte Antwort. Alle 5 Zyklen kommt auch noch ein 2 Byte Call für das GPS, das dann mit einem längeren Datensatz antwortet.

Hallo Ingo,

Äähhmm, ja jetzt ist mir klar wo mein Denkfehler war. :o

Ich habe Dir eine PN geschickt wegen dem Demo-Sensor.

Gruß
Reinhardt

Bernd FMC
24.01.2014, 14:10
Was lese ich ? GPS wird nun extra angepollt ?

Ich dachte der schickt nur seine Daten wie ein normaler Sensor ?
Ich meine in MSB Specs V2 war da aber nichts zu drin ?

Evt. muss ich dann ja meine Routine auch ummoscheln ?

Bernd

hiwi
24.01.2014, 16:35
Hallo Bernd,
ja das ist neu, bei der Konfiguration z.B.mit dem Launcher kannst Du dem GPS Sensor (ab Firmware 1.3) sagen, dass er GPS Daten auf dem Bus zur Verfügung stellen soll.
Die werden aber nicht per Telemetrie übertragen, sondern können nur auf dem Bus direkt abgefragt werden. So macht das auch der Flightlog,er loggt die GPS Daten mit.
Ralf

ubit
25.01.2014, 00:36
Yepp. Und Multiplex rückt die genaue Spec für das Verhalten des GPS leider nicht heraus. Schon versucht :-(

Ciao, Udo

Bernd FMC
25.01.2014, 06:23
Hmmm aber eigentlich will MPX doch das für Sensorbasteleien offenlegen ?

Naja, das GPS-Sensor ist nicht SO die Priorität bei mir.

Bernd

Reinhardt Werbik
26.01.2014, 13:48
Hallo,

so, ein erster Zwischen schritt ist jetzt erreicht. :)
Das Assemblerprogramm für die MSB Anbindung ist soweit fertig, erst mal mit konstanten Messwerten als Output, alles schön der Reihe nach.
Dank der Tipps von Ingo, und seinem Demo-Sensorprogramm, konnte ich mein Programm relativ leicht vervollständigen.
Der Demo-Sensor ist zwar in C geschrieben, aber die Registerzugriffe sind leicht zu erkennen und in Assembler umzuschreiben.

Ich kann eigentlich jedem nur empfehlen, die ersten Schritte bei der uC Programmierung mit Assembler zu machen.
Man muss sich zwangsläufig sehr ausführlich mit der Hardware beschäftigen und lernt die Features des Controllers wirklich von der Pike auf kennen.
Ich will aber nicht verschweigen, dass ausreichende Englischkenntnisse zum Lesen der Atmel Datenblätter unabdingbar sind.

Beim Debuggen mit dem AVR Studio kann man sehr schön verfolgen, was der Controller macht.
Ich habe auch mein STK 500 ausgegraben und das Programm auf einem ATmega 8 laufen lassen.
Läuft, aber solange kein MSB Master angeschlossen ist, tut sich natürlich nach der Initialisierung nichts.
Bevor ich jetzt einen Empfänger zum Testen anschließen kann, muss ich erst mal neue Hardware beschaffen.
Denn der olle ATmega 8 läuft nicht mit 3,3 V, werde also ein paar 48er, 88er und vielleicht auch 168er beim Reichelt ordern.

In der Zwischenzeit kann ich schon mal das Programm auf die neueren Typen umstricken.
Sind nur geringfügige Änderungen, muss aber doch sorgfältig gemacht werden.

Alles in allem macht es sehr viel Spaß, mal sehen, vielleicht setze ich meine Lüfter-Steuerung, die ich vor vier Jahren programmiert habe, doch noch in echter HW um.


Gruß
Reinhardt

Reinhardt Werbik
26.01.2014, 18:18
In der Zwischenzeit kann ich schon mal das Programm auf die neueren Typen umstricken.
Sind nur geringfügige Änderungen, muss aber doch sorgfältig gemacht werden.
So, ich habe heute Nachmittag den Code für den ATmega88 portiert, waren dann doch ein paar Änderungen mehr als gedacht.
Praktisch alle Register für USART und Timer liegen jenseits dessen, was mit den IN und OUT Befehlen adressiert werden kann.
Daher mussten alle diese Operationen durch LDS und STS ersetzt werden.

Bei der Simulation mit dem AVR Studio hatte ich dann einen unerwarteten Rücksprung an den Anfang nach einer bestimmten ISR.
Ich war schon am Ende mit meinem Latein, bis ich gemerkt habe, dass ich versehentlich den ATmega48 als Target für den Debugger ausgewählt hatte.
Da kann man natürlich lange suchen. :o

Aber jetzt läuft es soweit, um jetzt weiterzukommen, muss ich die 88er allerdings erst beschaffen.
Nächste Woche wird leider nicht viel passieren, da ich beruflich unterwegs bin.


Gruß
Reinhardt

konsul
31.01.2014, 16:38
Hallo Fraek's,

fachlich kann ich zu eurer Gesprächsrunde leider nicht's beitragen,aber vieleicht habe ich hier die Chance den Sensor-Traum vieler Schlepppiloten zu nennen.

Eine zuverlässige Kraftstoffverbrauchsmessung,idealerweise über einen Durchflusssensor.

Den wird es jetzt wohl auch in Kürze geben-leider von Jeti-könnt Ihr da was machen? So eine Art Adappter das man diesen Sensor dann unter M-link verwenden könnte!?

Gruß Konsul.

steinix
31.01.2014, 18:19
das optimale wäre eine schnittstelle von der projet-ecu zum multiplex-sensorsystem. gibts da schon was taugliches?
gruß thomas.

ingo_s
31.01.2014, 22:22
Da gibt es das ACT Fuel Watch für die Jet-Fraktion, hat aber auch Jet-Preise.

Gruß Ingo

Reinhardt Werbik
01.02.2014, 07:30
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

geilerflieger
01.02.2014, 20:04
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
01.02.2014, 22:41
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

gecko_749
02.02.2014, 00:06
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

Reinhardt Werbik
02.02.2014, 09:39
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

gecko_749
02.02.2014, 09:48
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

Reinhardt Werbik
02.02.2014, 12:48
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

gecko_749
02.02.2014, 13:48
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

wkorosec
02.02.2014, 15:10
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 :cry:

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
02.02.2014, 15:48
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 ?

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

wkorosec
02.02.2014, 17:39
Das Jeti Protokoll ist erst einmal ziemlich unorthodox (9 Datenbits, 2 Stoppbits, Parity).


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 :D

Gruss, Wolfgang

geilerflieger
08.02.2014, 17:25
Hallo Fraek's,

fachlich kann ich zu eurer Gesprächsrunde leider nicht's beitragen,aber vieleicht habe ich hier die Chance den Sensor-Traum vieler Schlepppiloten zu nennen.

Eine zuverlässige Kraftstoffverbrauchsmessung,idealerweise über einen Durchflusssensor.

Den wird es jetzt wohl auch in Kürze geben-leider von Jeti-könnt Ihr da was machen? So eine Art Adappter das man diesen Sensor dann unter M-link verwenden könnte!?

Gruß Konsul.


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

ingo_s
08.02.2014, 18:46
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

geilerflieger
08.02.2014, 21:17
Hallo Ingo,

ich stelle sehr gerne den Durchflusssensor zur Verfügung... melde mich per PN bei Dir wegen Adressenaustausch...

Melde mich wieder,

Stefan

geilerflieger
08.02.2014, 21:33
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

ingo_s
08.02.2014, 22:28
Der sieht gut aus, fängt aber auch erst mit seinem Messbereich umgerechnet bei 0,9l/h an und geht bis 48 l/h im Maximum.

Gruß Ingo

ingo_s
09.03.2014, 12:11
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

Reinhardt Werbik
11.03.2014, 21:42
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. :eek:
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

Reinhardt Werbik
23.03.2014, 09:56
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

1137850

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
07.04.2014, 21:36
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
07.04.2014, 21:50
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.

1144890

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

Reinhardt Werbik
07.04.2014, 22:16
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
07.04.2014, 22:38
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

Reinhardt Werbik
08.04.2014, 08:19
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

cyblord
01.06.2014, 19:51
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
05.06.2014, 13:08
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

Reinhardt Werbik
11.07.2014, 21:36
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.

cyblord
11.07.2014, 21:53
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
12.07.2014, 14:27
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

cyblord
12.07.2014, 14:47
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.

Reinhardt Werbik
04.10.2014, 20:03
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.

1232050

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
28.10.2014, 10:23
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).

k_wimmer
29.10.2014, 13:07
1245642

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
30.10.2014, 10:08
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

Reinhardt Werbik
31.10.2014, 23:31
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

Reinhardt Werbik
02.11.2014, 19:53
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
02.11.2014, 22:43
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
03.11.2014, 08:41
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.

E-Segler
03.11.2014, 12:12
Hallo Reinhardt

Warum machst du nicht eine automatische Erkennung beim anstecken. 2Zellen max 8,4V. 8,4V sind bei 3 Zellen 2,8V/Zelle. So leere Zellen wirst du nicht haben. Dann kanst du den Jumper die sparen und nicht falsch gesteckt lassen.

gruß Heinz

Reinhardt Werbik
03.11.2014, 17:30
Hallo Heinz,

Danke für den Tipp, Du hast recht, 2 oder 3 Zellen kann man problemlos an der Spannung unterscheiden.
Wenn man mit 2,8 V pro Zelle startet, das merkt man ziemlich schnell. :D

Der Jumper hat den Vorteil, dass ich ihn einfach nach jeder Messung abfragen und dann die Alarmschwelle berechnen kann.
Sprich es funktioniert auch dann, wenn ich den Messeingang bei schon eingeschaltetem Sensor anstecke.
Mal sehen, man müsste halt den Fall des späteren Ansteckens des Messeingangs in der SW abfangen, sollte kein Problem sein.
Den einen freien I/O Pin des ATtiny könnte man dann für eine optische Rückmeldung per LED benutzen.
Ich werde das auf jeden Fall mal implementieren, schon allein zu Übungszwecken, ich programmiere nämlich meine Sensoren in Assembler. :cool:


Gruß
Reinhardt

Reinhardt Werbik
03.11.2014, 19:22
So, ich habe es schnell programmiert, und es funktioniert einwandfrei.
Ab 8,6 V geht der Sensor von einem 3-zelligen Akku aus, das schafft ein 2-Zeller sicher nicht.
Letztlich läuft es darauf hinaus, dass der Alarm gesetzt wird, wenn die Spannung unter 7 V (bei 3,5 V/Zelle) oder zwischen 8,6 und 10,5 V liegt.

Wenn keine Spannung an den Messeingang angeschlossen ist, gibt es somit immer Alarm, wie vorher auch (macht ja auch Sinn).


Gruß
Reinhardt

Reinhardt Werbik
24.03.2015, 12:52
Hallo zusammen,

in der Zwischenzeit habe ich ein bisschen an dem Projekt "kleiner Spannungssensor für E-Segler" weitergemacht.
Und zwar habe ich die Ausgabe der Minimalspannung auf einer zweiten Adresse implementiert.
Allerdings habe ich da ein wenig getrickst. ;)

Es kommt ja durchaus vor, dass man den Messeingang erst anschließt, wenn der Sensor schon läuft.
Jedenfalls dann, wenn man die Spannung zum Messen wie ich am Balanceranschluss abgreift.
Das führt dann dazu, dass als Minimalspannung 0 V herauskommen, was sich natürlich im Flug auch nicht mehr ändert. :(

Das macht logischerweise wenig Sinn, also habe ich im Sensor eine Initialphase implementiert,
während der keine Minimalspannung (und kein Alarm) ausgegeben wird.
Erst wenn bei 8 aufeinanderfolgenden Messungen eine vordefinierte Minimalspannung gemessen wird,
werden Umin und Alarm "scharf geschaltet", und somit wird die oben beschriebene Situation vermieden.
(8 Messungen deshalb, damit nicht beim zittrigen Zusammenstecken doch wieder das obige Phänomen auftritt.)

Das ganze funktioniert jetzt für mich praxisgerecht.


Gruß
Reinhardt

Reinhardt Werbik
24.03.2015, 12:58
Nachdem ich jetzt schon ein paar Projekte mit Assembler gemacht habe, ist der Wunsch entstanden, doch mal was in C zu versuchen.
Also habe ich zuerst mal Atmel Studio 6.2 installiert, da ist dann alles was man bracht enthalten.
(Und noch eine ganze Menge mehr. :eek:)

Dann habe ich meinen allerersten Spannungssensor (mit ATmega 88 und HW USART) nach C übertragen.
Ich habe zwar früher schon in verschiedenen Hochsprachen progrmmiert, aber C ist dann doch nochmal etwas anders.
Aber dank Internet kann man ja Detailfragen heutzutage recht schnell klären.
Somit hat der Spannungssensor bereits nach kurzer Zeit genau das getan, was auch die Assemblerversion macht.
(BTW: Der Code ist dabei von ca. 430 auf ca. 750 Bytes angestiegen, bei exakt gleicher Programmlogik (gleiche ISRs etc.).)

Ich habe jetzt ein bisschen Blut geleckt, denn mit C kann man halt doch vieles einfacher, schneller und übersichtlicher machen.
Daher muss sich auch der etwas intelligentere Spannungssensor mit ATtiny 25 derzeit einer C Umwandlungskur unterziehen.
Dann lassen sich weitere Änderungen halt doch leichter einbauen, besonders wenn man erst nach einiger Zeit wieder daran arbeitet.
Mal schauen, ob der dadurch entstehende Code dann noch in die 2 k Flash passt.
Aber zur Not nehme ich halt den 45er, mehr wie 4 k werden es sicher nicht werden.

Und ja, Ingo, Du hast recht gehabt.
Wenn man sich mal an die Annehmlichkeiten von C gewöhnt hat, muss man sich richtiggehend motivieren,
um wieder in die Tiefen der Assemblerprogrammierung hinabzusteigen. :D


Gruß
Reinhardt

ingo_s
30.03.2015, 14:07
Hallo Reinhardt,

wie ich sehe bist Du nun auf dem richtigen Weg ;-)
Es lohnt sich am Anfang, auch mal in das List-File zu schauen, um zu sehen wie der Compiler C nach Assembler umsetzt.

Wenn Du dich mit "C" etwas warm gelaufen hast, könnte mein universelles Sensor Parametrie Verfahren für Dich von Interesse sein.

Grüße Ingo

Reinhardt Werbik
01.04.2015, 11:56
Hallo Ingo,

das habe ich natürlich schon getan, und zwar aus einem naheliegenden Grund.
Der 2s/3s Spannungssensor ist nämlich mittlerweile auch nach C migriert, aber natürlich funktioniert erst mal nichts.
Das hatte ich auch so erwartet, denn da der Tiny 25 keinen HW USART hat, ist ein SW UART implementiert,
dessen Timing angepasst werden muss, um wieder genau die Bitmitte beim Einlesen der Daten zu treffen.
(Das Senden müsste eigentlich passen, aber wird man zu gegebener Zeit sehen.)

Dazu habe ich mir die Assembler Files angeschaut und festgestellt, dass die ISRs vom Compiler durch Prolog und Epilog teilweise ziemlich aufgeblasen wurden.
Ob man das alles sichern muss, was der Compiler da an Push und Pop eingebaut hat, sei mal dahingestellt.
Ich werde da aber nicht mit NAKED rumfummeln, sondern muss halt mit dem Oszi ran, um das Einlesen der Bits wieder genau hinzupfriemeln.

Ich habe witzigerweise auch gleich eine Vereinfachung für die Assemblerversion entdeckt.
Ich hatte das Setzen des ADC Start Flags per Read/Modify/Write gemacht.
Beim Atmega 88 ist das notwendig, da die Adresse des ADC Kontroll-Registers jenseits der Grenze für den SBI Befehl ist.
Beim Tiny 25 ist das aber nicht so, so dass man hier das Startbit mit einem statt drei Assemblerbefehlen setzen kann.
Genau so hat der Compiler das auch umgesetzt.

Ich werde mir die Listings des vom Compiler erzeugten Assembler Codes sicher noch öfter anschauen, ist nämlich sehr interessant.


Gruß
Reinhardt

Reinhardt Werbik
01.04.2015, 20:19
Das hatte ich auch so erwartet, denn da der Tiny 25 keinen HW USART hat, ist ein SW UART implementiert,
dessen Timing angepasst werden muss, um wieder genau die Bitmitte beim Einlesen der Daten zu treffen.
(Das Senden müsste eigentlich passen, aber wird man zu gegebener Zeit sehen.)

Genauso war es, und jetzt läuft der Sensor.
Ich habe den SW UART zum Empfangen ein wenig modifiziert.
Der erste Interrupt während des Start-Bits wurde eliminiert und jetzt wird gleich in die Mitte des ersten Daten-Bits gesprungen.
Macht eigentlich eh mehr Sinn, da das Start-Bit ja bereits detektiert wurde, wenn der Bit-Takt gestartet wird.

Ich werde mir gelegentlich Deine universelle Parametrierung nochmal anschauen, Ingo.

Gruß
Reinhardt

twinking
14.04.2016, 14:14
Hallo zusammen,

ich habe auch nach längerem mal wieder meine Micrcontroller ausgegraben. Momentan arbeite ich mit einem ATmega8A auf einem STK500 mit Atmel Studio 7. Zum Senden und Empfangen nutze ich den HW UART des ATmega8. Insgesamt klappt alles auch schon besser als ich es erwartet hatte. Im Grunde genommen, kann ich dem Bus zuhören und wenn ein Byte reinkommt was ein Masterbyte sein muss darauf reagieren. Prüfen ob das empfangene Byte ein Master Byte ist wird ja mit dem Idle Line Timeout realisiert. Ich benutze dazu zwei Interrupts. Der eine wird immer dann ausgelöst, wenn ein Byte empfangen wurde und startet den Idle Line Timer immer wieder von 0. Zusätzlich zählt dieser einen Counter um eins hoch. Der zweite Interrupt wird ausgelöst, wenn der Timer 300us erreicht. Hier wird nun der Timer angehalten und geprüft, ob der Counter = 1 ist. Wenn dies der Fall ist habe ich ein Byte von einem Master empfangen.
Dieses Byte gebe ich dann an eine Funktion weiter die entscheidet ob es sich um ein Adressbyte handelt (Byte <=15) oder ein Command vom Master war (momentan noch Byte <15).
Nun zu meinem Problem. Starte ich meinen Sensor zeigt dieser kurz einen richtigen Wert an. Das heißt, ein Masterbyte wurde empfangen, als Adressbyte erkannt und ich sende meine Konstanten Sensorwerte. Immer mal wieder kommt es jedoch vor, dass der Sensor mal ein Masterbyte erkennt, dieses jedoch nicht als Adressbyte empfängt, sondern als Commandbyte. Visualisiert habe ich mir das über eine LED, die dann blinkt.
Ich komme einfach nicht dahinter was da verkehrt läuft. Eigentlich dürfte ich ha garkeine anderen Masterbytes als Adressbytes Empfangen, das der Master ausschließlich Adressbytes senden. Das habe ich auch schon über eine USB-UART-Bridge und Hterm mitgeloggt. Irgendwo muss also ein Fehler meiner Masterbyte Erkennung sein (denke ich). Jedenfalls ist meine einzige Erklährung, dass der Sensor ein Sensorbyte als Masterbyte interpretiert.
Alles schwierig zu erklären. Hier mal noch der Code von meinen Interrups. Vielleicht sieht einer von euch auf anhieb den Fehler.
Wichtig ist vlt noch zu sagen, dass ich momentan noch den RX und TX Pin des Sensors direkt miteinander verbunden habe. Um zu verhindern, dass der TX Pin den Bus auf high zieht, wenn keine Daten im gesendet werden sollen, wird dieser nur aktiviert, wenn auch wirklich gesendet werden soll. Mein Timer Interrupt wird durch einen Compare Match ausgelöst. Mein uC taktet mit 8Mhz, der Prescaler des 16-bit Timers steht auf 1. Demnach löst der Interrupt aus, wenn der Timerstand etwa 2400 erreicht hat. (8MHz^-1 = 0,125us zwischen jedem Timer Count. 300us/0.125us=2400) Evtl. stimmt meine Rechnung auch nicht. Wenn ich den Compare Interrupt Wert auf z.B. 5000 erhöhe, kommt es im übrigen seltener dazu, dass ein falschen Masterbyte erkannt wird.


ISR(USART_RXC_vect){
last_byte = UDR;
Timer_reset(); // Timer auf 0 setzten
Timer_start(); // Timer starten
received_bytes_counter ++; // zählt mit wie viele Bytes seit dem letzte Idle Line Timeout empfangen wurden // speichert das letzte empfangene Byte
}

ISR(TIMER1_COMPA_vect){
UCSRB &= ~(1 << RXEN); // RX deaktivieren
UCSRB |= (1 << TXEN); // TX aktivieren
Timer_stop();
if(received_bytes_counter == 1){
mb_last_Byte_of_Master(last_byte); // Diese Funktion entscheidet ob es sich um ein Adressbyte oder Commandbyte handelt
received_bytes_counter = 0;
}
else{ // Wenn received_bytes_counter != 1 wurde das Byte nicht vom Master gesendet
received_bytes_counter = 0;
}
UCSRB &= ~(1 << TXEN); // TX deaktivieren um zu verhindern, dass er den Bus auf high zieht
UCSRB |= (1 << RXEN); // RX aktivieren
}

So viel unverständlicher Text. Würde mich trotzdem freuen, wenn jemand durchsteigt und mir helfen kann :). Versuche auch gerne nochmal mich klarer auszudrücken.

Liebe Grüße
Fabian

twinking
14.04.2016, 23:33
Hi,

ich habe heute noch ein wenig rumprobiert und mal einen externen 8Mhz Quarz verwendet. Bis jetzt hatte ich immer den internen des ATmega8 benutzt. Mit dem externen Quarz habe ich bis jetzt noch nicht ein falsches Bit empfangen. Anscheinend war das also das Problem. Ich werde die Tage mal noch etwas weiter basteln und dann evtl. berichten, wenn ich was vorzuzeigen habe. Mein Ziel ist es im übrigen einen Staudruck Sensor zur Geschwindigkeitsmessung zu bauen. Bis dahin ist es aber noch ein langer Weg.

LG

k_wimmer
15.04.2016, 09:04
Hallo Fabian,

da ich nun auch offiziell zu diesen Controllern etwas sagen darf, möchte ich dir nahelegen dass du dir mal das Datenblatt des ATMega8 mal genauer anschaust.
Da findest du dann auf Seite 270 folgenden Graph:
1587315

Da siehst du dann, dass je nach Spannung und Temperatur du weit über die max. Toleranz einer RS232 mit +/-2% rausläufst.

Da ist es nicht verwunderlich, dass du keine Übertragung hin bekommst.

Reinhardt Werbik
15.04.2016, 14:48
Hallo Fabian,

auf Anhieb sind mir folgende Dinge aufgefallen, die ich vielleicht ändern würde.

Ich würde für den Idle Line Timeout nicht den 16-Bit Timer "vergeuden".
Vielleicht brauchst Du den mal für eine Sensor-Applikation (z.B. um Zeiten zu messen).
Ein 8-Bit Timer mit entsprechend eingestelltem Vorteiler tut es auch.

300 µs sind an der unteren Grenze für den Timeout, nimm 400 bis 600 als Timeout.
Die echten Sensoren warten glaube ich sogar noch wesentlich länger, bevor sie antworten.

Unterprogrammaufrufe in ISRs sind eher sub-optimal, da sie einen signifikanten Overhead an zusätzlichen Befehlen erzeugen,
den man sich in einer ISR nicht immer leisten kannn, nur mal so als Anregung.

Ich werde mal gelegentlich meine MSB C-Module anschauen, ob da signifikante Unterschiede zu Deinem Code sind.


Gruß
Reinhardt

Stefan Kähne
10.05.2016, 20:17
Hallo zusammen,

ich hatte gerade eine Idee für einen DIY Sensor als ich mich mit meinem Segler beschäftigt habe. Ich benutze derzeit immer mein Unilog2 als Variometer. Allerdings gibt es hierbei keine TEK (Totalenergiekompensation), was die Nutzung in der Thermik nicht so ganz einfach macht. Der Einbau einer TEK-Lösung ist recht aufwendig. Man benötigt eine gute Düse, Schläuche und eine sinnvolle Einbauposition. Das ganze muss dann auch gut kalibriert sein.

Folgende Idee hätte ich:

-Arduino (Nano) Board (so klein und günstig wie möglich)
-Drucksensor (statischer Druck, möglichst direkt am Board wie auch beim Unilog)
-Beschleunigungssensor (eine Richtung würde reichen)

Für die Totalenergiekompensation ist immer die Kentniss über Höhenänderung und Geschwindigkeitsänderung notwendig. Beides könnte man nun mit den Sensoren errechnen. Der Rest müsste Mathematik sein.

Nachdem ich schon mit meinem Arduino problemlos Sensordaten für die MPX-Schnittstelle gernerieren konnte, müsste ich nun nur brauchbare Sensoren finden. Hat jemand eine solche Lösung schonmal irgendwo gesehen?

Am Ende hätte man einen TEK-Kleinstsensor, der relativ unabhängig im Flieger verbaut werden kann. Ledigleich die Beschleuningungsachse muss in Flugrichtung zeigen. Keine Schläuche, keine verstopften Düsen die bei Unachtsamkeit abbrechen können.

tembaine
05.08.2016, 18:18
Hallo
Mit Interesse habe ich eure Beiträge gelesen, da sind richtige Profis am Werk.
Ich suche ein Vario für M-Link, das ich nachbauen könnte. Platinen ätzen und SMD löten sind für mich kein Problem.
Hat jemand von euch so ein Projekt, das ich verwenden dürfte?

Gruss
René

kalle123
05.08.2016, 19:16
Hallo René.

Gehört zwar nicht so ganz hier hin, aber die "Eierlegende Wollmilchsau" openXsensor kennst du?

Vario, Strom, Spannung, Drehzahl, Temperatur ....

Vario mit 1 oder 2 MS5611 Sensoren ...

Gruß KH

tembaine
06.08.2016, 15:12
Hallo Kalle
ich finde unter dem von dir genannten Begriff kein "Nachbauvario". Kannst du mir mit einem Hinweis helfen?

Gruss
René

kalle123
06.08.2016, 17:07
Hallo René.

Schau einfach mal hier http://www.rclineforum.de/forum/board49-zubeh%C3%B6r-elektronik-usw/board50-fernsteuerungen-und-telemetrie/311808-openxsensor/ rein.

Code findet sich hier https://github.com/openXsensor/openXsensor Einfach "Branch master" runter laden und entpacken. Die ganze notwendige Doku findet sich eigentlich in der Datei oXs_config_description.h

Der eigentliche thread zum Thema oXs findet sich -> http://openrcforums.com/forum/viewforum.php?f=86

Lohnt sich ...

Gruß KH