search

rdancer / Color_LCD

0 stars 0 forks source link

Connect to smart BMS #6

Open rdancer opened 3 years ago

rdancer commented 3 years ago

Either via UART, UART over power line, or Bluetooth

UART -- nRF52840 has 2 UARTs, so we can use the other one UART over powerline -- save on cabling, and reuse the existing power connection

rdancer commented 3 years ago

image

We need to be able to connect multiple batteries in parallel, so instead of UART, use

rdancer commented 3 years ago

To make it "over powerline", use a coupling capacitor & something like

Edit: do I still need a bus controller like MCP2515 (SPI<->CAN logical layer), or is that built in?

rdancer commented 3 years ago

https://www.researchgate.net/profile/Johannes-Wolf-2/publication/224101282_Assessment_of_CAN_performance_for_Powerline_Communications_in_dc_differential_buses/links/557058dc08ae193af41ff411/Assessment-of-CAN-performance-for-Powerline-Communications-in-dc-differential-buses.pdf?origin=publication_detail

rdancer commented 3 years ago

https://electronics.stackexchange.com/questions/50522/how-to-couple-a-signal-on-to-a-dc-line

rdancer commented 3 years ago

https://www.ti.com/lit/an/slla336/slla336.pdf

rdancer commented 3 years ago

The BMS is somewhat cheap and popular with multiple battery pack vendors, as well as DIY. Have 3rd-party iOS and Android app(s?), development resources on their website, and some open source implementations.

Note: Unfortunately, while UART over Bluetooth is part of the legacy standard (Serial Port Profile (SPP)), Bluetooth Low Energy (BLE) doesn't have that, and every manufacturer / chip maker implement their own, which only works if you have two serial-BLE adapters from the same manufacturer, running the same software. Further, BLE doesn't describe its services in English, or with standardised code numbers, but rather uses 128-bit magic numbers that are again proprietary. So whenever a new vendor comes up with yet another implementation of BLE serial, they have to assign it, and its API endpoints, a series of magic UUIDs. Unsurprisingly, the UUIDs are not even particularly unique.

We have to implement both the BMS protocol (which is rather easy, as we only need a fractional subset to begin with). And we also have to implement the BLE protocol (which is not even documented, but at least in theory should only be two FIFOs and associated interrupt vectors and let the BLE PHY layer handle retransmissions, ordering, and other hairy stuff).

We could add our own bluetooth adapter, but that is about as much effort, and we ideally want off-the-shelf compatibility with a wide range of battery vendors' products anyway, so will need to implement whatever they happen to have chosen to use. We don't want to have to open battery packs and void warranties, if we don't have to.

Bluetooth is great for zero-cost comms link setup and maintenance, but we still need a reliable way of identifying which battery is actually electrically connected, as opposed to sitting in storage somewhere in the house, on the bike riding next to us, or God forbid if we have more than one battery on a bike, or even more than one battery connected in parallel. The DS18B20 that MSpider65 uses in his TSDZ-ESP32 project has a 1-Wire comms interface, and each of them has a unique ID. They're also incredibly cheap, so we can use one just for the ID, even if we are not using it for temp readings subsequently. Conversely, can also wire them in parallel and have multiple temp reading points around the bike as well as the battery.

rdancer commented 3 years ago

I've asked LTT if they would provide bluetooth protocol spec / sample implementation.