Hi James, thanks again for your reply.
The Sevcon won’t be online during charging, so it cannot be used for this purpose.
The Sevcon does have a ‘standard’ object dictionary and you can read and write to these depending on the access level. The BDI remaining charge has no access level and could be written without programming PDOs.
This is completely separate of the programmable PDOs (which is a cyclic transmit data and possibly receive data). There are no predefined messages for this, however it’s very customisable so we/you could create a frame which can be received by the Sevcon, call it the new standard and post it on the Wiki. I think this would be preferential. Probably just the BDI would be sufficient, the other values can be set or be dependant on BDI%. They might be interesting once the battery reaches temperatures which are outside of spec if derating can be programmed into the Batrium.
The Sevcon can independently estimate and map battery% based on the battery voltage, and cutback when this is below certain voltages / estimated %. However for an LFP setup I expect this to be quite far off in the middle 80% of the capacity range. To prevent pulling 400A at a low SoC it would be ideal to communicate the battery% beforehand.
The idea of the Victron was to only read out data from the Sevcon (there’s a plugin made for it) and Batrium and show these on display. I haven’t got it yet and the idea is to not need it for an MVP either.
So ideally the Batrium would control the charger completely and then also transmit the full package every now and then to be received by the Victron. Ideally including a custom frame for the Sevcon to control the BDI.
Some more questions regarding physical stuff, which I hope you can answer!
My idea was to have a key switch which then closes a relay if the BMS allows discharge. This will be the actual ‘key’ input for the motor controller(s). The main power contactor will be driven by the motor controllers (as this may only close if the motor controller allows it and has charged the bridge)
ideally if the charger is online (and charging), the Batrium will close another relay (Expansion) and will automatically force open the discharging key-relay (to prevent propulsion with the charger connected).
I’ve read the wiki Expansion settings on the logic, to my understanding the easiest way would be to set an SSR to CriticalBattOK, chain it to an SSR set to Charging OFF and then the key switch closes the circuit for a precharge contactor.
For the charging contactor - use the Charging Remote Running setting to open and close the charger contactor.
Now when using the TC which is connected over CAN, I don’t quite understand what the “Charging OFF” and “Charging remote running” mean. Could you elaborate if these settings would work for my goal? Will the Charging remote running close the relay once the TC comes online, so it can start charging? And does charging OFF mean it’s not allowed to charge or just its currently not charging?
Thanks again!
Best,
Wout