DIYBMS v4

Hello, I just solder together my first controller circuit. I flashed it with the controller firmware and it boots up and wants to set up wifi. That all seems good. But then I flashed in the “Controller Board Test” software with NodeMCU Pyflasher. This left the controller unresponsive. When I connect with putty it outputs this message:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

If I understand correctly it is missing some flash boot? Did I do it wrong by flashing it with NodeMCU? Does anyone know what this issue is?
Any advice is appreciated.

cheers

Ok, found it but no success so far…

Will habe to check cabling.

Thx

…and another update!
having modded the controller board with DIP connectors in parallel to the SMD ones, I fitted a DIP8 MCP2562 CAN chip and soldered the CAN terminator jumper on the pcb.
On the other side a Raspberry pi4 running VenusOS using a PEAK USB can controller.
Wired CAN-H and CAN-L, enabled canbus messages on the webinterface of diybms and run on the first try!
well impressed!
Minor issue is that I already have a CAN-hat running NMEA2000, signalK, etc with different settings (250kbps speed fe) so now struggling a bit trying to get two CAN inputs on same raspberry and configuring them right…
Other minor issue is that I took the lot to the boat to test in a dual can setup and forgot how to reset the wifi (in order to connect to the boat wifi) Anyone? Thought it was reboot button on the ESP32 for xsecs, nada!

again, v.well done to all involved, I will have some comments and ideas (possibly!) for this once I get it running on the boat.

cheers

V.

Reset of WiFi is easier if you connect to usb serial port to ESP32 and just press space bar after resetting the esp.

Then you can enter the new WiFi details. On screen.

1 Like

thanks Stuart, going in a while to test it, but to be safe, got a spare ESP32 programmed at home PC as a backup. Actually I’ll probably have one ESP for the boat wifi and one at home for testing :slight_smile:

V.

14 posts were split to a new topic: 84 diybms modules - not working as expected

I am pretty sure i didnot insert the #38 code commit in my post…but, i am think i am already running the 5 october 2021 code…or am I missing or not understanding something ?

anyone tried to relocate the TFT touch screen say 20cm away from the board?
I’m asking as I’d rather have the controller board safe and close to the battery and cut a hole in a panel and fit the touch screen there. Would save my back and the hassle of lifting a hatch that my wife usually has lots of stuff on. Should be OK, no?
will try from some old IDE or scsi h/d cables as they look similar spacing but haven’t got any here atm

cheers

V.

I did it about 25 cm with standard dupont cables, without problems

1 Like

Could you please explain in more in detail the connection pinout on the Peack usb can to raspberry pi venus. .
I have tried with my IPEH 002022 connecting canH , canL and ground but only get ignored can messages and nothing on rasp. Venus.

Also the same DIYBms has been proofed to work on another installation with Victron Control GX
Thanks

hi,

mine is a PEAK IEPH-002021 (so non isolated!)
wired only canH and canL (haven’t bothered with GND yet!)
did put a blob of solder on the JP1 to enable termination - have you done that?
then on the raspberry pi 3B+ (also works on an early 4) I’m running v2.80~21 Large. Didn’t have much luck with 2.73, but didn’t try that much.
On Settings/Services/CAN-bus (1) (or (2) in my case) I have
CAN-bus profile CAN-bus BMS(500kbit/s)
Mind network status (next line in Venus gui) always shows ERROR-ACTIVE, but it works.
Useful to have GitHub - kwindrem/VeCanSetup: Manages Victrion VenusOs VeCan (aka CANbus) ports installed (via the SetupHelper) are you familiar with his work? really good!

Also seems that you have to have the PEAK USB connected to rpi, reboot rpi, connect the other side to the diyBMS and then you may have to reboot the BMS as well…
Once comms are established reboots don’t mess with things.

good luck!

V.

also note that a decent connection/comms between the rpi and the PEAK means the red led on the PEAK is flashing constantly (at slightly different rates…)

Hi,
Indeed the led is constantly red , so no comms. at the moment.
In v2.80 do you need to write anything else except the venus image on the sd card to enable the CAN capability ?
I can’t find the CAN bus profile in Settings/Services

OK, start by the basics then!

install:

and then through it, the VECANSetup (same guy)
once you do that, system should be configured and you should be able to see the canbus(1) on the Settings/Services
V.

Indeed  V.

Starting from the root always gives another perspective.
Thanks for the tips and patience.
Much appreciated,

Now all working as expected!

1 Like

since you got it running, I’d appreciate some feedback in a day or so, if diyBMS remains “visible” on the rpi.
Testing with influxDB also posting, seems that diyBMS stops communicating with rpi after 4-5h.
Now stopped influx and testing again this morning. Hope it’s related to influx and stuart can find a solution to that.
so any info on uptime would be appreciated!

cheers
V.

for about 19 hours the connection has been maintained visible in rpi
And I was able to check that in VRM also.

The only problem I can see is the temperature sensors showing wrong values.

13h and still running with canbus communicating with the rpi! :smiley:
Re temp sensors, be aware that the values presented in Victron are for the EXTERNAL temp sensors. Internal ones for each module are NOT exported and are of no interest to Victron. They are interested about the temp of the cells, not the temp of the control boards which are doing the passive balancing.
So if you don’t have a ext. temp sensors installed, there wont be any values reported (at least that’s what happens on mine!)

Are you by any chance able/planning to log stuff on influxDB? Would be interested to see how many hours diyBMS lasts broadcasting in a local (or remote) influxDB!

cheers

V.

fwiw,
22h and counting, influxDB OFF, just CANBUS to VictronOS running raspberry.
So looks like influxDB also affects CANBUS. Will update the issue on github.

V.

I don’t think there is a direct connection between the two modules, BUT, there is a strong possibility that the underlying http client used by the influxDB integration point is causing a leak of memory which could impact many other areas of the BMS.

To triage that further it would be extremely helpful to have console dumps and backtraces to confirm when/why the BMS goes down, I believe some of this has been captured in the GitHub issue already but more testing is likely required.