I thought we were in PM with @MaSh all this time… seems thats not the case. Here is definitely not the place for this kind of discussion indeed.
I was following you through all the rest of the sentence, but I can’t accept classifying turtles as amphibians
I have no idea what you’re referring to, but it’s clearly a part of your sick climate change conspiracy
side note; I had no idea that amphibian was an actual category that excludes reptiles, I thought it just meant wet little guys who go between land and water
is there a FightClub Section in this forum? That “environment is totally fine” issue should go there I guess…
anyways, @ENNOID just sent me liberally a new PCB. Would have been much easier if @ENNOID would have checked PM. ride on
In this corner or derail jail are fair game
Linux BMS Tool v5.04 worked fine, v6.00 doesn’t.
Any idea why?
./ENNOID-BMS-ToolV6.00.appimage
Inconsistency detected by ld.so: dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL’ failed!
linuxdeployqt related issue
Use windows if it does not work with your linux distro. Even better, use vesc tool.
The 24s BMS is able to communicate with any Vesc and if so if there is irregular voltage among the cells is it possible to slow down the controllers?
I’ve been hoping vesc firmware gets support for this kind of bms integration for a long time.
Instead of voltage cutoff start/end if it coudl be cell voltage cuttoff start/end that would be awesome.
It is already somehow partially implemented in VESC. It is SOC based, but SOC is itself based on the lowest cell voltage.
Users using a “balance” device e.g. onewheel, disable the protections for SOC and temperature in VESC tool so they don’t get thrown away when a cell gets low or when cell temperature gets too high. Surfdado implemented something in his float package to mitigate this for balance application.
can you expand on that?
I thought being SOC based meant it was on total pack voltage? what exactly is implemented in vesc that enables usage of a lowest cell voltage?
There are a few settings related to this in the VESC tool general section, BMS tab
BMS sends the calculated SOC & temperatures, so the VESC react accordingly.
So with this protocol the BMS sends a percentage SOC?
that makes sense. so… it’s now possible. that’s awesome.
has been possible for more than a year or two, just need to connect CAN bus
Edit: answered my first question
the skp solo i am using only has a single can output/input with no 12v&gnd - can I just use the canh/canl to tie to the can bus as i want to display bms data on the new megan telemetry display. Possibly just tie the megan and xlite via can and use uart to connect the megan to the solo and have two separate networks?
If you have any insight I would appreciate it - The Megan SHOULD be able to connect to the xlite but I haven’t done anything yet
I don’t know if MEGAN works with XLITE VESC protocol. You should ask @janpom on that topic.
The DAVEGA implementation was using the old DieBieMS protocol which is not the default CAN bus protocol anymore for the XLITE.
If I remember correctly, last time I looked into your firmware code, Ennoid BMS-es respond to the DieBieMS-style requests correctly regardless of how the CAN bus protocol is configured. Specifically, it works even if the protocol is set to VESC style. Unless that has changed, all should be good.
I use Megan with XLITE myself and all works fine.
OK, good to know. Wasn’t sure about it, preferred to ask.
Thank you
I believe setting the protocol to VESC only affects how the BMS actively sends its status data. It does not affect how it responds to requests. That’s at least how I understood it last time I looked at the code.
Megan ignores the status data. It relies solely on request-response communication.
That’s promising. Thanks for the quick response. I’m preparing my build for the final component arrangements and realized I hadn’t really thought through the actual compatibility of the components on my wishlist .
Just to confirm some details on my plan as i pace around waiting for connector to arrive. I still feel tentative on my understanding of can communication networks