Hardware debug instruction?

[wolfgangr]

great work .... but not what I want. I'd like to write the data to a database, but that does not have to bother you.

However, I got inspired by your work to read COM3 from a debian box, but could not yet manage to get any response.

So - do I understand correctly: The signal is neither correct TTL - serial - because it is inverted, nor is it RS232, because it is 0 - 5 V, not symmetric?

Are the manuals in the Doc-Section from Chargery or is this from you? I could not find anything else

Do I have something wrong in my setting?

root@kellerkind:~$ stty -F /dev/ttyChargery -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany
-imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho
-extproc

oops, sorry, shame on my head: I think I found my mistake and leave it here for reference:

The data comes in hex format and obviouly does not yield anything printable. So the common quick and dirty serial test cat /dev/ttyChargery does not display anything.

When I try a hexdump, however, I see stuff coming in:

root@kellerkind:~$ xxd < /dev/ttyChargery 
00000000: 005b 55eb 83ff ff07 ff31 0000 5b55 eb83  .[U......1..[U..
00000010: ffff 07ff 3100 005b 55eb 83ff ff07 ff31  ....1..[U......1
00000020: 0000 6c2c 56eb 0000 5b55 eb83 ffff 07ff  ..l,V...[U......

I used a generic RS232 - USB-serial cable with DB9 connector. Black = GND -> Pin 5 Red = TX(Chargery) -> RX (Dongle) -> Pin 2 No reprogramming, no special brand requirement (so I hope....)

[wolfgangr]

... nope. looks like I just collected garbage on the line. Does not resemble the data format of tobi's docs. PL2303 seem to be quite unstable. Will go for a genuine FTDI.

[wolfgangr]

update: what did (not) work for me in a reliable manner

• reverse connection of a RS 232 level serial dongle (tried different brands)
• inverter using pc 817 optocoupler (too slow?)
• inverter using 74 LS 00 (wrong level / impedance?)

What seems to work at the moment: inverter using 1/6 part of a 74 HC 14 inverter-schmitt-trigger with 4k7 pulldown at the input generic PL2303 (5V-Type), powering the inverter stty -F /dev/ttyChargery 11520raw xxd < /dev/ttyChargery

May be the data arrive in inverted manner, but I still have to check

[wolfgangr]

next loop. Coming at the limit of RTFM. RTFI...nternet... stty relatet stuff suggests, that to get rid of all tweaking with binary data, you might want to get close to RS485. Hang on - R 485? differential lines? 5V ? negative polarity? weird behaviour of the output due to (if not expected) differential driver?

Grab a RS 485 dongle, plug it in and alas:

root@kellerkind:~$ xxd < /dev/ttyChargery 
00000000: 2424 570d 0abe 0000 007f 007d 7024 2457  $$W........}p$$W
00000010: 0d0a be00 0000 7f00 7d70 2424 570d 0abe  ........}p$$W...
00000020: 0000 007f 007d 7024 2456 3609 f524 2457  .....}p$$V6..$$W
00000030: 0d0a be00 0000 7e00 7a6c 2424 570d 0abe  ......~.zl$$W...
00000040: 0000 007e 007a 6c24 2457 0d0a be00 0000  ...~.zl$$W......

Doesn't this look like the data format outlined here in the doc folder? Heureka?

just for reference - from demsg:

[48276.071968] usb 4-3: new full-speed USB device number 32 using ohci-pci
[48276.265073] usb 4-3: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63
[48276.265175] usb 4-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[48276.265247] usb 4-3: Product: USB2.0-Serial
[48276.292617] usbcore: registered new interface driver ch341
[48276.294011] usbserial: USB Serial support registered for ch341-uart

[wolfgangr]

for ease of reference:

I just changed the title of my issue to resemble the essence: Treat Chargery COM3 as RS485 and have an easier life.

electrical: Just wire the red line to A+, the black one to B- software: call stty -F /dev/whatever 115200 raw and be happy.

Well, why does chargery not tell us such a secret? They point to tobi's instruction on their official page :-\\

anyway, have fun :-)

[wolfgangr]

still fine tuning.... I could read (most ... ~ 90 % ... of) the shorter "57" commands, but none of the longer "56" commands passed the CRC check. I could see that always 1...3 bytes were missing, so the start of the following commands dropped into the data length frame.

First I suspected line noise. I changed the dongle (same type, other batch) - no effect. I measured the signal with an oscilloscope: clean, 8 V p-p pulses with some mV ripples. Added 120 Ohm terminal: Signal amplitude dropepd to 5 V, but still same behaviour.

There is https://www.kernel.org/doc/html/latest/driver-api/serial/serial-rs485.html but the perl bindings of ioctl seem to lack some documentation.

So I tried to refine stty settings. Just hacked together by gutt feeling and bunched it into a script for reproducibility. I think, echo'ing might cause disturbance on the line. I also added 2 ds of timeout to cut the 1s-bursts into pieces and some other....

:~/chargery/test$ cat ./setstty-RS485.sh 
DEVICE="-F $1"
DEVICE="-F /dev/ttyChargery"
stty $DEVICE -a
echo "------ apply changes -----"
stty $DEVICE 115200 raw
stty $DEVICE time 2
stty $DEVICE -echo -echoe -echok -echoctl -echoke
echo "------ done -------"
stty $DEVICE -a

echo "----- simple output -----"
stty $DEVICE

This is what I get:

speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 2;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
----- simple output -----
speed 115200 baud; line = 0;
min = 1; time = 2;
-brkint -icrnl -imaxbel
-opost
-isig -icanon -echo -echoe -echok -echoctl -echoke

and alas - a first test yields clean long command "56" lines

[wolfgangr]

just updated my Chargery BMS to version 4.02 (LCD) / 4.03 (main unit) Was 1.03 before. Did not match data structures as documented here:
https://github.com/Tobi177/venus-chargerybms/blob/master/docs/bms24_additional_protocol%20V1.25.pdf

However, I found surplus data at cmd 56: The docs say there are 2 x 4 bytes of trailing data (Wh and Ah) but I found 12 bytes in excess of per-cell voltage data.

here is my pre-parsed reading:

'24'24'56 - 57 bytes of raw data:  09 ea 0a 07 0a 10 0a 29 0a 1e 0a 07 0a 1f 09 ff 0a 0d 0a 13 09 fb 0a 1e 0a 0a 0a 10 0a 03 0a 13 0a 31 09 ea 0a 39 09 e9 0a 0b 0a 20 00 00 00 00 2b 05 28 01 a0 eb 05 00 d9
checksum: d9 , cmp d9 
        calling command processor for 56 $VAR1 = {
          'Ah?' => '19399.979',
          'gww???' => '388',
          'Wh?' => '0',
          'cell_volts' => [
                            '2.538',
                            '2.567',
                            '2.576',
                            '2.601',
                            '2.59',
                            '2.567',
                            '2.591',
                            '2.559',
                            '2.573',
                            '2.579',
                            '2.555',
                            '2.59',
                            '2.57',
                            '2.576',
                            '2.563',
                            '2.579',
                            '2.609',
                            '2.538',
                            '2.617',
                            '2.537',
                            '2.571',
                            '2.592'
                          ],
          'num_param' => 56
        };

I'm referring to the sequence 00 00 00 00 2b 05 28 01 a0 eb 05 00 12 bytes, excluding reasonable voltage data from a 22S battery and excluding the CRC. The Pack is 50 V 400 Ah equals 20000 Wh. Just fresh data after firmware update, no charge / discharge yet.

Any idea how to assign the data?

[frams]

its strange you are having so many issues, i use a generic pl2303 serial cable from amazon with no issues at all.

I'm using Docker with a custom made container to get all the data and sending them to influxdb to be used.

The only issue i had was that the code is written in python2.7 and so I had a hard time at the beginning getting all the modules for 2.7 but after that I never any issues.

If you need any help hit me up.

I'm not a programmer but i do my best to get things to work.

[wolfgangr]

Just received response from chargery support. They say data format does not consider the number of cells as configured (22 in my case), but the capability the BMS is designed for (24 in the case of a 24T) So I simply had to scrap the data for cell 23 and 24. Sounds reasonable ;-)

[wolfgangr]

script runs for hours now, without any complaints. looks like the garbage on the line is just a startup problem. Maybe there were a fix, but I don' really care. I collect into RRD, which is pretty tolerant against missing points.

I still see an issue with boguous(?) h::3\cr\lf stanzas on the wire. No idea whether they arise from the chargery, the USB thingie or the linux machine. I skip them in my code, and by doing so, I got rid of any other read errors: https://github.com/wolfgangr/chargery2PERL/blob/f58f6b3cd87e43ae6a0869ee2aa57df29b7a1aae/update.pl#L195

I think it's fair to consider the hardware questions as "solved" and close the issue here. My software goes a different way, as one may find out following the link above,

Many thanks to Tobi, again.