Hi Schallas,

I bought this but am struggling to get anything from RS485 or CANBUS after wiring up to Daly (A to A, B to B, Can-L to L, Can-H to H):

https://www.robotics.org.za/W14882?search=485

I'm not sure if I should attach the ground from the Daly to the ground of this board, which I think is the ground of the Raspberry Pi, I was worried about something going wrong and it killing my Pi, which is why I haven't connected it 😕

I don't have a /dev/ttyUSB0/ but the Rs485 examples from Waveshare for my hat use /dev/ttyS0/ so I'm not sure if I should be able to just change this reference in your code and mine should then work?

I also tried the Can examples for my hat and did get some reading back when calling can0.recv(10.0), but nothing that looked useful. 

Just wondering if anyone can shed some light on this, maybe I just need to connect the ground from Daly to the Pi ground?

Thanks.

 

I managed to get some data from canbus when I finally set the correct baudrate (I think i ended up on 9600). I seem to get data that is constantly broadcasted, doesn't seem like I can't request anything specific though.

I can't tell what the data is, converting to int doesn't give me anything that looks like the battery or cell voltages. But interesting that one of the values spells out LBSACOZA (lithiumbatterysa.co.za) when converted to ascii, so looks like the data is being read correct, see attached image.

@Schallas, your code seems to use Rs485, not canbus, but I think the Rs485 hat that you have on your PI runs in full duplex and this is why your code never gives me any values back. My hat is half duplex and I have to switch a gpio pin between sending and receiving. I also found I get more data back if I send with baud rate of 9600 and receive with 28800. However, the data I get back fails the checksum and most of the times I don't get the full 13 bytes back. Even when I do get 13 bytes back it doesn't look anything like I expect. I suspect that after requesting data by sending the bytes to the BMS that I miss some of the data transmitted by the BMS as my code is still busy switching to receive and changing my baud rate.

I'm not sure if anyone knows a better way of doing this with half duplex?

 

3 hours ago, Lindsay said:

I managed to get some data from canbus when I finally set the correct baudrate (I think i ended up on 9600)

For anyone interested, I realise I didn't use 9600, actually initialised as: "sudo ip link set can0 type can bitrate 500000"

For anyone still following, the Canbus output above didn't seem to give me the data I wanted, instead I tried modifying Schallas's code for the Daly Smart BMS (https://github.com/tomatensaus/bms) to use the half-duplex RS485 connection on the PI hat I ordered from Micro Robotics (www.robotics.org.za/W14882).

I had to modify the code so that I could send a command while in transmit mode then quickly switch to receive to get the response, however I would often miss the first few bytes so I had to allow for this (by filling in the missing bytes if we just missed the first couple since these are always the same) as well as modifying it to retry until the checksum is correct. However although I could get it to work there were a lot of retries which slowed down getting all the data I wanted. 

So instead I ended up buying an external USB to RS485 module (https://mantech.co.za/ProductInfo.aspx?Item=15M5345) which seems to handle the transmitting and receiving automatically. Then I was able to use more of the original code, but left the retry loops I added as occasionally the checksum does still fail.

I have attached the Python code if anyone is interested, by default it should work for the USB to RS485 module, but see the comments in the script for instructions on how to modify it if you want to try use it with the half-duplex hat.

 

dalyUsbRetry.py

@JustinSchoemanet Al

 

Most intrigued by your protocol conversion project between Daly BMS  and   inverter . Well done my learned friend 👍  I will be proud owner of a similar lifepo4 / smart Daly setup soon , and looking forward in hacking the Daly in order to extract the exposed SOC parameters from the BMS .  So I am going to fork your code  to anchor myself here.  But I can see that you have done some awesome work here. 

Is your protocol conversion stable and functional , that you are utilising it , or is merely proof of concept still? Just very curious. Kind regards.

Working 24/7 for 11 months now without any issues.

While SOC monitoring is nice, the most important role is to manage charge rate when nearly full, otherwise small cell imbalances trip out the BMS long before it is fully charged.

1 hour ago, JustinSchoeman said:

Working 24/7 for 11 months now without any issues.

While SOC monitoring is nice, the most important role is to manage charge rate when nearly full, otherwise small cell imbalances trip out the BMS long before it is fully charged.

Thank you , I am still on the learning curve here regarding the Lithium cell characteristics , so that input is well received and appreciated.

1 hour ago, JustinSchoeman said:

Working 24/7 for 11 months now without any issues.

While SOC monitoring is nice, the most important role is to manage charge rate when nearly full, otherwise small cell imbalances trip out the BMS long before it is fully charged.

I agree with you 100%... I now set the charge current to 0 when the SOC passes 95% otherwise the BMS starts sending a whole bunch of incorrect stuff out. Chances are good that I just don't understand it as well... 

@JustinSchoeman, @Lindsay

 

Again great work here !

I have notice sporadic complaints re RS485  head packet data lost , timeouts etc in random fashion. I want to share previous experience I had with undeterministic RS485 behavior on non-realtime OS like Linux, which may or may not be the cause of your problem. When the RS485 DE line is controlled in userland in linux  , like with the py environment, there may be a severe latency between the time the last byte byte is transmitted and when the DE line is released (jitter by kernel preemting the userland code).  this is further compounded by the receiver (DALY) , which may have  fast response and opens its driver to transmit back to the pi , before the latter has released its DE line , and collision occurs  as a result.

This of course can be easily verified with either dual channel scope or logic analyzer. If indeed there is random , sloppy jitter, there is not a lot one can do , except using an FTDI HS usb driver that has hardware level RS485 arbitration, or finding a kernel mode software driver that toggles DE line in kernel space.  I have used the FTDI  to solve such problem. 

 

Again this may or may not be relevant, but I thought it good to mention this failure mode anyway.

 

Kind Regards

 

 

 

The DALY does seem to share a lot of hardware functions.  So you will find some lost packets if you are using multiple protocols (like RS485 and WiFi) at the same time. But losing a packet every now and then should not really be an issue.

With the dedicated Rs485 on the Arduino I don't have any losses, except when I open the WiFi app - but even then it is only one or two packets a minute.

Interesting....I have the LCD touchscreen plugged into the Daly as well as RS485, maybe that causes me to occasionally lose bytes as well. I've only monitored it during the night, but will at some point start monitoring it all the time and see if I also see odd values when it's almost fully charged.

 

Talking about SOC, when I got the Daly BMS the RemainingCap shown on the LCD was set to 29.8Ah. I noticed that the SOC meter on the LCD almost always showed 100% SOC. It was only after a couple of days of rain, where the batteries were low that RemainingCap changed and went below 29.8Ah in total, that the SOC value started moving lower. 

So I thought if I set the RatedCap (total capacity) in the SetParameter page on the LCD touchscreen from 29.8Ah to 200Ah, my actual capacity, it would show correctly. However now it sits on 100% SOC all the time, even when it's down to less than half the capacity. There is also a SOC value on the SetParameter page, I'm not sure why you'd set that, but it always says 100% and if I adjust it and save it jumps back to 100%.

I know SOC is never completely accurate, but seems pointless for this big meter in the middle of the LCD to always show 100%. 

Just hoping someone has some experience with this and can help me out here! Thanks.

bonjour.

Je tente en vain de réaliser ce montage mais rien a faire je ne reçoit rien du bms auriez vous un schéma de câblage ?

De plus j'ai beau avoir passé la carte sous minicore mais le chien de garde se met toujours en route après plusieurs essais de communication échoués.

merci