Auswerten des EMUS Datenstroms

Das musste ich jetzt einfach mal hier posten.........
Erste Gehversuche beim Auswerten des EMUS Datenstroms!

Das Emus BMS sendet ständig alle relevanten Werte über die serielle Schnittstelle

Ich wollte da jetzt einfach mal die Spannungen rausfiltern,
und die verstecken sich in der Zeile, die mit BV1 beginnt: (Battery Voltage Sentence)

BV1,2D,94,A0,9D,3EDA,9F9C9F9F9EA09E9E9F9D9FA0A09F9E9E9E9F9E9E9FA09FA09F9E9E9F9E9E9F9D9E9F9D9F9E9E9E9F9697979496,D2

BV1 die Kennung   (Zum Sortieren der Daten)
2D Anzahl der Zellen   (2D Hex   =    45 )
94 min     ( 94 Hex   =   148 Dez   ;  +Offset 200 ergibt 3,48V )
A0 max   ( A0 Hex  =  160 Dez    ;  +Offset 200 ergibt 3,60V )
9D Durchschnitt (9D Hex  = 157,  gibt 3,57V
3EDA Gesamtspannung   (3EDA  Hex = 16090 Dez = 160,90V)




















....und dann die 45 Einzelspannungen und zuletzt die Checksumme.
Das BV5 in der ersten Zeile ist einfach eine "andere" Meldung um zu schauen,
ob die verworfen wird.

Ich will nur ganz kurz die Vorgehensweise erklären
Das Programm ist in Bascom entstanden und noch weit davon entfernt,
fertig zu sein, ich zeige hier nur die entscheidenden Befehle.

Ich lese immer alles in einen String ein, bis ein LF oder CR kommt (1.Zeile)
Vorerst mal per:

If Ischarwaiting() = 1 Then
S0 = Inkey()
Gosub Onrxd
End If

...........das geht natürlich normalerweise auch noch wesentlich eleganter per
Interrupt-gesteuertem Empfang, aber irgendwas lief da nicht ganz so wie erwartet......
Ich hatte aber keine Lust, den Fehler zu suchen.
Die erste Zeile klappte,  aber wenn zu viel zu schnell  kam gabs Abstürze
und das Display zeigte wirres Zeug.
Ich vermute, dass ich irgendwo auf Daten zugegriffen habe als ich das nicht durfte,
oder das vom Interrupt gestartete Unterprogramm brauchte einfach zu lange,
oder womöglich wurde zuviel in einen zu kurzen String geschrieben???
ich werds schon noch rausfinden.........
momentan muss ich die aufgezeichneten Daten per Terminal an den
Freeduino senden, und da ist wohl so manches anders als das EMUS die
Daten normalerweise sendet. Also erstmal kein Grund zur Panik
Dieses "Polling"-Empfangsverfahren habe ich einfach mal aus einem anderen lange
erprobten Programm so übernommen weils fürs Erste schon mal den Zweck erfüllt.
Mit "Ischarwaiting" kann man hier arbeiten, weil das
hier lauter lesbare Zeichen sind, ausser CR und LF.

für binäre Daten wo auch mal ein "Nullbyte" vorkommen könnte
ist das aber unbrauchbar.

Onrxd:
If S0 = 13 Then '13=CR 10=LF
Z = Left(strx , 3)
If Z = "BV1" Then Bv1 = Strx
Cls
Locate 2 , 1
Lcd "Z=" ; Z
Locate 1 , 1
Lcd Strx
Locate 2 , 1
Lcd Bv1
Locate 3 , 1
Lcd Cells ; " " ; Cmin ; " " ; Cmax ; " " ; Cav ; " " ; Ctot
Locate 4 , 1
Lcd Valcells ; " " ; Valcmin ; " " ; Valcmax ; " " ; Valcav ; " " ; Valctot
Led = 0
Strx = ""
Return
End If

Str00 = Chr(s0)
Strx = Strx + Str00

......wieder mal gäbe es hier viele Möglichkeiten, und ein Array wäre sicher
vom Programm her die efektivere Lösung, aber ich arbeite einfach lieber mit einem
String, weil es so viel übersichtlicher ist, und auch die verschieden langen Zeichenkolonnen
besser verarbeitet werden können. Falls es zu "Performance-Problemen" kommt
kann ich immer noch nachbessern......

Nachtrag:
Natürlich kam es zu "Performance Problemen"..........
Allerdings hatte ich zwischendurch auch noch was ins Display geschrieben,
und das geht hier überhaupt nicht! Mehr ganz am Ende dieses Posts
Lesenswert:
http://www.rn-wissen.de/index.php/Bascom_UART_Input

Dann wird nachgeschaut, wie der String beginnt, und wenn da BV1 steht,
wird der String gespeichert.(2.Zeile)

Z = Left(strx , 3)
If Z = "BV1" Then Bv1 = Strx

Dann hole ich von da die wichtigsten Werte raus, auch als String (3.Zeile)


Cells = Mid(bv1 , 5 , 2)
Cmin = Mid(bv1 , 8 , 2)
Cmax = Mid(bv1 , 11 , 2)
Cav = Mid(bv1 , 14 , 2)
Ctot = Mid(bv1 , 17 , 4)


und zuletzt werden die Strings in Zahlen gewandelt.

Valcells = Hexval(cells)
Valcmin = Hexval(cmin)
Valcmax = Hexval(cmax)
Valcav = Hexval(cav)
Valctot = Hexval(ctot)

In diesem Fall: 45Zellen, min 3,48V (offset 200) max 3,60V,
Durchschnitt 3,57V und Gesamtspannung 160,9V

Die Offsets etc sind hier noch nich umgerechnet,
das war einfach mal ein erster Versuch, aber es klappt ganz gut!

Vielleicht kann ich das ja noch in die Franzbox reinpacken,
Die Anzeige dieser Werte ist ja schon drin, aber nicht aus dem EMUS
ausgelesen sondern aus meinem Versuchs-BMS.
aber andererseits ist das ja ein Widerspruch in sich......
Wer ein EMUS hat braucht ja keine Franzbox mehr, sondern nur
ein Display für die wichtigsten Werte! Die Franzbox
könnte dann nur noch die Stromstärke auf den Drehzahlmesser übertragen,
 aber alles Andere ist im EMUS bereits "drin"

Ich brauche für meine gang spezielle Anwendung nur ein paar Daten aus dem
gesamten Datenstrom, aber so als eine Art "Nebenprodukt"
fällt hier auch noch ein kleines Display für die EMUS-Daten ab,
das dann ganz dezent die wichtigsten Infos anzeigt.
Das fehlt dem EMUS noch, wunderbar grafisch per Bluetooth
auf ein Tablet gibt es schon, sogar sehr preiswert, aber das ist dann halt ein Problem,
wo baut man das hin, und will man das wirklich immer alles wissen?

Ich meine, wichtig ist vor allem, dass man bei Fehlern benachrichtigt wird,
und dann auch finden kann wo es hapert, aber wenns nicht nötig ist, dann
braucht man nicht mit Infos überschwemmt werden.
Was nutzt der schönste Zeiger, wenn man nicht hinschaut wenn er langsam auf 0 geht.
Ich ziehe eine Warnleuchte jedem Zeiger vor, aber wenn die Leuchte mich warnt,
oder bei Bedarf auch jederzeit zwischendurch will ich natürlich alle Daten abfragen können.
Aber ich will nicht ständig irgendwelche Werte beobachten müssen
um dann darauf zu reagieren. Zu überwachen und aufzupassen ist
Aufgabe des BMS und nicht des Fahrers.

Ein bisschen umformatiert schaut das gleich viel besser aus
Die oberen beiden Zeilen sind Infos für mich,
einmal der zuletzt empfangene String
und der zuletzt gespeicherte String (Datenmüll wird aussortiert ;-) )
Und dann halt die Inhalte der Daten
Zellenzahl, Gesamtspannung
Minimum, Durchschnitt, Maximum

Für andere Werte muss ich andere Datenstrings auswerten
Ich überlege noch, was alles wichtig ist,
Wegabschätzung und SOC vor allem,
das ist aber dann eher eine
Art Fleißaufgabe und viel Schreiberei......
aber für die Chargersteuerung
brauche ich ohnehin völlig andere Werte........

.........ein bisschen habe ich noch rumgespielt, es wird allmählich......
So ginge es notfalls auch auf 2 x 16 Zeichen darzustellen wenn man
auf die Klamern und "SOC" verzichtet. Der Strom ist hier nicht so sehr
wichtig,weil der Wert nur etwa einmal pro Sekunde aktualisiert wird.

Ist das so verständlich? 56.8Vgesamt, 14Zellen Durchschnittlich 4,05V
niedrigste 4,04V höchste 4,07V SOC100%
Die Temperaturen abzufragen macht beim EMUS wenig Sinn,
da sieht man nur die Temperaturen der Balancer-Platinchen.

Die Evolution schreitet voran.......
mittlerweile sieht man auch den Strom, und ich hab auch noch einen Timeout
drin, wenn die Daten ganz ausbleiben sollten,
und auch eine fehlende Kommunikation oder
Fehler der Zellenkommunikation werden erkannt und gemeldet
Entweder sendet das EMUS dann BV1,,,,,,,,, das kann man abfragen, oder
der Offset von 2V würde gleich nach dem Einschalten angezeigt
wenn noch keine Daten angekommen sind. Das habe ich auch unterbunden.

Momentan ist noch eine Menuestruktur vorgesehen, aber ob die drinbleibt
ist fraglich.Aber für die Chargersteuerung brauche ich das noch.
Das Ding soll ja in etwa so primitiv werden wie das Curtis 840
Anklemmen, einschalten, Werte ablesen, sonst nichts, keine Bedienung.

..........Der soll das alles mal steuern!
Geniales Teil! Ich hab den zwar noch nicht getestet, aber das geht gewiss!

Ich lese zwar immer noch die Daten per "Polling" und großem
Eingangspuffer ein, aber da der Prozessor ansonsten sowieso
kaum was zu tun hat geht das in diesem Fall recht gut.Immerhin 16MHz!
Bevor ich hier allzuviel Zeit verschwende will ich es erst mal in der
Praxis testen. Die paar Zeichen sollten kein ernsthaftes Problem sein.
Morgen Abend bin ich dann schlauer!

Nachtrag 24.März 2013:
Tja........ganz so wie erhofft lief es dann doch nicht.........Da kommen sehr viele Zeichen,
und die kommen auch noch sehr schnell, und offenbar auch ohne Pausen zwischen den Zeilen!
Man kann zwar die Pause zwischen den Datenblöcken einstellen, aber das Datenpaket kommt
immer als Gesamtpaket. Jetzt wirds interessant, wie ich das im Programm gelöst bekomme.
Die Anzeige der Spannungen hat geklappt, aber Ampere und SOC kamen nicht
zuverlässig an, weil das Programm noch mit anderen Dingen beschäftigt war.
Zum Beispiel habe ich die empfangenen Zeichen im Display angezeigt, das dauert viel zu lang
Ich habe schon mal die ganzen Anzeigen aus dem Display entfernt, die ich für
Kontrollzwecke in den ersten Zeilen drin hatte, und damit läuft es schon um ein vielfaches
schneller, aber das konnte ich halt jetzt nicht mehr testen.
Aber ich habe eine Möglichkeit gefunden, ein weitgehend komplettes Datenpaket
zu simulieren. (ich habe kein EMUS in greifbarer Nähe, aber mit dem "COM-Terminal"
kann ich einige Zeilen "am Stück" senden) Mal schauen, eine Möglichkeit wäre,
bei jeden Durchlauf auf eine andere Zeile zu warten, aber das gefällt mir jetzt gar nicht!
Ich muss halt möglichst viel zwischenspeichern und dann in der Pause auswerten,
falls ich es nicht in "Echtzeit" schaffe, und da ist die "Polling-Methode" gar nicht sooo
schlecht. mir hat gestern leider die Zeit gefehlt, das Programm vor Ort zu ändern
und zu testen. Die andere, viel effektivere Möglichkeit ist natürlich,
die Daten ohne Umweg über einen String in ein Array zu legen und dann
in der Pause auszuwerten. Ich muss mal allles nochmal genau durchdenken........
Die ganzen Versuche, das Einlesen per Interrupt-gesteuert ablaufen zu lassen haben bis jetzt noch
in sehr seltsamen Abstürzen des Displays geendet, die ich mir noch immer nicht wirklich
erklären kann. Da kommen plötzlich Zeichen an Stellen die überhaupt nicht angesteuert wurden.
Ich habe nicht übers Ende der Strings hinausgeschrieben, und die einzelnen
Programmsegmente einzeln funktionieren, aber sobald der Empfang neuer Daten das
Schreiben ins Display unterbricht gibts Probleme, die ich bei der "Polling-Methode" nicht habe.
Ich werde also für jeden Datensatz ein Array anlegen müssen und einfach mit Berechnungen und
Anzeigen warten müssen, bis zwischen den Datenpaketen eine Pause ist.
Ins Display zu schreiben, während eingelesen wird muss unbedingt vermieden werden.
Und das Zwischenspeichern ist gar nicht so unkompliziert, wenn man bedenkt dass
ein Maximalausbau von 255 Zellen allein für die Zellenspannungen einen Satz aus etwa
550 Zeichen am Stück liefern würde...... das sprengt jeden normalen Puffer!
Da ich die Einzelspannungen aber gar nicht auswerten will, Min, Max, Durchschnitt und Gesamt
sollten reichen für unterwegs reicht mir aber der Anfang des Spannungspakets


Meine Pläne gehen hier in zwei Richtungen. Zum Einen brauche ich ein Steuergerät,
für eine Chargersteuerung. Dafür muss aber auch die Auswertung funktionieren.
und das sehe ich am schönsten durch Darstellen der Werte auf einem Display.
Zum anderen will ich eine möglichst simple, kleine und billige Anzeige
für die wichtigsten Daten schaffen. Das wird ein EA DIP204 Display sein, auf das
direkt ein Wattuino pro mini draufkommt. Das ist dann 68 x 27mm x 15mm groß
und kostet ca 30 Euro.........
Da braucht man dann nur noch einen Inverter für den seriellen Eingang.
und ein kleines Poti für den Kontrast
Aber weil ja hier nur gelesen wird, ist das Invertieren kein allzugroßes Problem,
zur Not geht da sogar ein simpler Transistor,
oder ich bin ein "wilder Hund" und nutze einen Interrupt-Eingang des Atmega
zum Invertieren des Signals (nur mal eine Idee, keine Ahnung obs klappt)
die +-12V werden ggfs. durch einen Vorwiderstand(10k) und die Dioden im Atmega auf
0-5V begrenzt. Das ist auch ein bisschen "grob", aber erfolgreich erprobt

So was in der Art habe ich schon mal irgendwo gesehen, da wurde der Komparator
eines PIC genutzt. Ein Optokoppler 6N 137 wäre natürlich auch eine Möglichkeit.
(wohl die "edelste") ein MAX232 ist hier einfach zu aufwändig, weil ich ja nichts
auf RS232 senden muss.