BID2NFC als Nachrüstlösung

onki · 1. März 2017

Hallo,

wenn ein neuer, bisher unbeschriebener NFC Tag verwendet wird dann gibt es beim ersten lesen logischerweise eine Fehlermeldung mit dem Hinweis, das die Daten nicht stimmern und der Chip neu formatiert werden kann. So ist es zumindest beim Twin Lader gelöst. Nach der Eingabe der Daten wird dann der Chip damit gefüttert und die LED blinkt als Hinweis den NFC Tag vorzuhalten, damit die Daten im Tag aktualisiert werden können. Danach sollte alles problemlos funktionieren.
Bitte schau mal ob der NFC Tag gelesen werden kann und die LED danach leuchtet (ggf. über das serielle Terminal die Meldungen überprüfen). Das bedeutet dann der Lesevorgang war erfolgreich.
Sollte es beim Auslesen des I2C Bus Probleme geben hilft zur entkopplung entweder ein Optokoppler (wurde schon bereichtet) oder ggf. ein Pull-Up Widerstand.
Die Meldungen am Gerät sind natürlich vom jeweiligen Gerät abhängig. Da ich nur den TWIN hab, kann ich es leider nur anhand dessen Meldungen beurteilen.

Gruß
Onki

pipif · 1. März 2017

For the initialization of the first Bid, you have an error message Ok
Then press the "ESC" key for 2 seconds and then program the data.
That's how I do with my Power Peak Twin.
I wish it worked for you
Paul

tüftelwilli · 1. März 2017

Hallo Onki,
danke; das beim ersten Start eine Fehlermeldung kommen muss ist klar. Das hast du in deiner Anleitung sehr gut beschrieben (Kompliment!).
Habe das Auslesen eines Tags mehrfach über den seriellen Monitor getestet. Der Chip wird erkannt, die Seriennummer angezeigt, für alles 16 Blocks erscheint die Meldung "block was read" (Inhalt wird nicht angezeigt). Dann kommt die Meldung "Lesen Ende", read Errors: 0 - und das Ganze geht von vorne in einer Endlosschleife los: Chip gefunden, block was read, Seriennummer ausgelesen, Chip gefunden etc.
Die Leuchtdiode blinkt während des Vorgangs, kein Dauerleuchten.
Ein Pull-up Widerstand bringt nichts, im Ladegerät sind auf der SDA bzw. SDL-Leitung 10k-Widerstände eingebaut (habe nachgeprüft und gemessen). Beim Starten sind beide Leitungen hochgesetzt (3,3V).
Ein anderer Versuch war interessant: pull-down-Widerstände von 500Ohm. Dann bleibt nach dem Anstecken die erste Fehlermeldung am Display des E7 anstehen, man kann die ESC-Taste drücken und kommt in das Programmiermenü des BID-Chips. Das war's dann leider auch; die Daten werden zwar gepuffert, aber nicht auf den Chip übertragen, egal was und wie ich es anstelle.
Habe leider keinen passenden Optokoppler im Fundus, sonst hätte ich das auch probiert. Die 3,3V Spannungsversorgung nehme ich vom E7; sie ist kräftig genug. Bei einem Strom von 70mA stehen immer noch 3,27V an. Auch eine externe 3,3V-Versorgung wurde probiert, mit demselben (negativen) Ergebnis.
Noch ein Wort zur Software: habe die beiden INO-Dateien mit Stand 10.10.2016 verwendet.
Werde weiter forschen.

Gruß vom Bodensee, Tüftelwilli

onki · 2. März 2017

Hallo,

Steffen hatte mit dem D7 ja auch seine liebe Mühe und hat letztlich leider aufgegeben.
Ich vermute das Problem liegt in der Art und weise, wie der BID-Chip gelsen wird.
Das kann damit zusammenhängen das nur die BID-Speicherstruktur nicht aber die Ausleseweise vorgegeben ist und alle Robbe-Lader OEM-Geräte von verschiedenen Herstellern waren.
Daher könnte der Arduino hier Probleme bekommen weil der Code den BID-Chip immer komplett am Stück ausliest. So ist es halt im Twin realisiert. Mag sein das andere Hersteller nur die jeweils notwendigen Speicherblöcke auslesen.

@ Ralf: Korrigiere mich bitte falls ich hier Unfug schreibe.

Gruß
Onki

tüftelwilli · 2. März 2017

BID2NFC an MPX PP E7

BID2NFC an MPX PP E7

Hallo Onki, Ralf,

das vermute ich auch! Und nicht nur das Auslesen (der Blöcke?), sondern auch der Zugriff auf das E7 ist wohl anders. Der I2C-Bus ist ja nur Mittel zum Zweck. Am seltsamsten erscheint mir dass der Zugriff auf das E7-BID-System (Programmierung) nur dann stabil erfolgt, wenn die SDA-Leitung mittels pull-down-Widerstand von 500 Ohm bis ca. 2,7k auf Low gesetzt wird. Keine Ahnung warum, elektronisch gesehen ist das eigentlich Unsinn bzw. widerspricht dem was ich bisher darüber wusste und gelernt habe.
Aber wenn dem so ist, versuche ich was Drumherum zu stricken - Versuch macht bekanntlich klug...
@Ralf, gibt es von den beiden INO-Dateien eine neue Version?

Grüße vom (heute sonnigen) Bodensee, Tüftelwilli

Steffen · 2. März 2017

tüftelwilli schrieb:
Am seltsamsten erscheint mir dass der Zugriff auf das E7-BID-System (Programmierung) nur dann stabil erfolgt, wenn die SDA-Leitung mittels pull-down-Widerstand von 500 Ohm bis ca. 2,7k auf Low gesetzt wird.

Das ist im I2C-Protokoll durchaus logisch. Es ist halt ein permanent und auf allen Adressen antwortendes I2C-Gerät.

Wenn das wirklich die Hardware des D7 ist dann sei Vorsichtig. Das Ding ist nicht im mindesten ESD-Fest.

funktioniert hat es bei mir übrigens durchaus, allerdings nicht mit der TWI-Lib aus Arduino, ich habe mit einer anderen Erfolg gehabt. Aber eben nur solange, bis I2C tot war...

brueggen2 · 2. März 2017

onki schrieb:
Hallo,

Steffen hatte mit dem D7 ja auch seine liebe Mühe und hat letztlich leider aufgegeben.
Ich vermute das Problem liegt in der Art und weise, wie der BID-Chip gelsen wird.
Das kann damit zusammenhängen das nur die BID-Speicherstruktur nicht aber die Ausleseweise vorgegeben ist und alle Robbe-Lader OEM-Geräte von verschiedenen Herstellern waren.
Daher könnte der Arduino hier Probleme bekommen weil der Code den BID-Chip immer komplett am Stück ausliest. So ist es halt im Twin realisiert. Mag sein das andere Hersteller nur die jeweils notwendigen Speicherblöcke auslesen.

@ Ralf: Korrigiere mich bitte falls ich hier Unfug schreibe.

Gruß
Onki

Servus zusammen,

Also Ausgelesen erfolgt Prinzipiell nicht Blockweise, sondern Byte für Byte. Also wenn der Lader das Byte 14 fordert wird auch Byte 14 geliefert. Der Twin fragt aber einfach Byte 0-255 der Reihe nach ab, egal ob lesen oder schreiben(Byte 0-128 identisch mit 129-255). Aber das ist Anforderung des Laders, der Arduino Code kann auch durcheinander, bzw einzeln sein. Habe leider immer noch keinen D7 da zum rumbasteln. Allerdings aufgrund der Tests von Steffen denk ich mal das es eher an einer verdammt sensiblen Schaltung liegt.

PS: Falls wer mit einem Logic Analyser, Scanalogic o.ä ein Log von einer Kommunikation zwischen Lader und EEProm hat währe super.

Grüße Ralf

Steffen · 3. März 2017

Mööp,

MPX will die Doku nicht rausgeben, wie die Daten von der seriellen Schnittstelle aussehen. Das ist eine glatte sechs in meinen Augen.

Dann wird es vielleicht sogar Zeit ein WBID for Junsi zu bauen :-)

onki · 3. März 2017

Hallo Steffen,

Tero von RC-Thoughts.com arbeitet nach seinen Worten an einer WBID Lösung für die Junsi-Schnittstelle.
Aufgrund einiger Beschränkungen des Kommunikationsprotokolls soll die Lösung aber nicht ganz so komfortabel wie das BID2NFC-System sein (wenn ich ihn richtig verstanden hab).
Mein USB-Oszi kann als Logic Analyzer mit I2C Dekodierung arbeiten jedoch fehlt mir der benötigte Lader.

Echt traurig das kein Hersteller so etwas auf die Beine stellt. Auch bei Revolectrix ist es ziemlich still geworden hinsichtlich Ladern mit integriertem Bump.
Auch die aktuell neuen Lader können kein Bump. Die Bump-Box ist eigentlich eine Verschlimmbesserung weil extern. Aber zumindest ein Ansatz.

Gruß und ein schönes WE

Onki

Steffen · 3. März 2017

onki schrieb:
Aufgrund einiger Beschränkungen des Kommunikationsprotokolls soll die Lösung aber nicht ganz so komfortabel wie das BID2NFC-System sein (wenn ich ihn richtig verstanden hab).

kann ich jetzt kaum glauben. soweit ich das lese, kann man beim Junsi einfach alles steuern und auslesen. Siehe zB hier

onki · 6. März 2017

Hallo,

so - der Magazinbericht ist online.
http://www.rc-network.de/forum/content.php/710-bid2nfc

Gruß und Danke an Konrad
Onki

tüftelwilli · 7. März 2017

Hallo zusammen,

falls uns das weiterhilft: im E7 wird der C8051F380 verwendet. SDA und SCL-Leitungen gehen direkt auf den Chip.
Im Datenblatt von Silicon Labs ist der SMBus beschrieben; bin aber kein Experte drin. Vielleicht einer von euch?

Grüße, tüftelwilli

onki · 8. März 2017

Hallo,

vielleicht ist es auch noch sinnvoll für weitere Anwendungen und Interessenten die BID-Speicherstruktur hier nochmal im Detail zu erklären.
Was bekannt ist wird auch gerne angenommen.
Es gab da doch mal dieses PC-Programm zum auslesen der BID-Chips. Da war die Spicherstruktur ja schon bekannt. Ich hab mal was am Arduino gemacht auf der Basis. Das sollte für eine entsprechende Aufdröselung doch reichen.
Oder hat jemand das schon gemacht und kann es hier reinstellen?

Gruß
Onki

Steffen · 8. März 2017

onki schrieb:
Es gab da doch mal dieses PC-Programm zum auslesen der BID-Chips. Da war die Spicherstruktur ja schon bekannt.

das habe ich leider nicht gefunden.
Gefunden habe ich ein paar Fragmente und aktuell bin ich so weit:

Code:

#pragma pack(push, 1)
typedef struct {
  endian16  checksum;         // [0..1]  Checksum, sum up bytes from 2..127
  endian16  act_charge;       // [2..3]
  endian16  max_charged;      // [4..5]
  endian16  chg_cycles;       // [6..7]
  uint8_t   unknown_8[63-7];  // [8..63]
  uint8_t   year;             // [64]
  uint8_t   month;            // [65]
  uint8_t   day;              // [66]
  uint8_t   acctyp;           // [67]
  uint8_t   cells;            // [68]
  endian16  capacity;         // [69..70]
  endian16  chg_current;      // [71..72]
  endian16  dischg_current;   // [73..74]
  endian16  dischg_limit;     // [75..76] discharge limit in mv/Cell
  uint8_t   d_peak;           // [77] delta peak value
  uint8_t   cut_temp;         // [78] cut off temperature
  uint8_t   unknown;
  uint8_t   unknown75[128-80];
}tBID_data;
#pragma pack(pop)

Charge_limit kann ich nicht identifizieren, weil das Twin das nicht kann.

BOcnc · 8. März 2017

Ich hatte mal ein Programm gemacht. Finde aber nur den Windowsteil wieder.
Wenn ich mich recht erinnere stand das Jahr bei mir auf einer anderen Adresse.

brueggen2 · 8. März 2017

Ihr meint das hier ?
https://www.rc-heli-fan.org/post955301.html

tüftelwilli · 9. März 2017

Hallo zusammen,

habe das Programm etwas angepasst (reine Kosmetik) und einen BID-Chip ausgelesen. Das EEPROM im Chip ist der 24LC02, er lies sich ohne weiteres "anfahren"! Ergebnis im Anhang; Daten in HEX und binär.
Anhang anzeigen Auslesen eines BID-Chips.pdf
Anhang anzeigen Auslesen eines BID-Chips_Daten binär.pdf

Aus dem PP E7 konnte ich allerdings damit nichts auslesen.

Grüße, tüftelwilli

BOcnc · 9. März 2017

Hallo tüftelwilli,

von welchen Gerät kommt das BID?

Die Daten von 0 - 127 müssten die selben sein wie von 128 - 255.
Bei mir war das so.

tüftelwilli · 9. März 2017

Hallo,

die Daten kommen vom MPX Power Peak E7. Das ist ein "halbes" D7. Der C8051F380 wird verwendet, SDA und SCL-Leitungen gehen direkt auf den Chip. Die intern verbauten pull-up-Widerstände betragen 10k.
Lt. Datenblatt von Silicon Labs hat er zwei I2C-kompatible SM-Busse. Wenn ich allerdings diverse threads zum Thema SM-Bus und I2C lese und meine bisherige Erfahrung dazu berücksichtige, dann hat anscheinend die Wire.h von Arduino Probleme damit. Weiß im Moment nicht, wo ich ansetzen soll und welche lib passt.
Die Daten 0-127 sind nicht 100% identisch mit 128-255; z.B. hat das Byte 0 den HEX-Wert 2A und 128 den HEX-Wert 3.

Gruß, tüftelwilli

tüftelwilli · 9. März 2017

Ich muss mich korrigieren: lediglich die Daten der Bytes 0 und 128 sind verschieden. 1-127 und 129-255 sind identisch. Sorry!

Gruß vom tüftelwilli

BID2NFC als Nachrüstlösung

User

User

User

User

User

User

User

User

User

User

User

User

User

User

User

User

User

User

User

User

Ähnliche Themen