irony_delerium
New here
So... current state of things:
I've got a 24" tricycle (relatively generic used thing), that I've already taken the time to set up with a TSDZ2B, lighting, oversized battery box, etc.
Now, I'll be honest - the VLCD5 that it came with is kinda crap. I've gone to OSF, which helps a bit (the speedometer and battery meter are both closer to correct, the former because the display wouldn't save changes to the wheel size since it's slightly damaged, having gotten water damage a few years ago when it was installed on my previous bike, the latter because LFP's discharge curve is different enough from NMC's that the meter doesn't end up working well anyway) but since it's a VLCD5 display and not something else like, say, an 860C, it's still kinda crap.
I've got the following kit here or on it's way:
- 3 x ESP32 modules. One is of the "cheap yellow display" variety, a 2.8" backlit color LCD, resistive touchscreen, with frame, and enough minor ports to connect to other devices; the other two are IdeaSpark ESP32 modules with a 1.14" OLED display. The display on the other two modules is more intended to be for debugging purposes than anything, since I fully expect to be writing firmware for all 3 of these. (I won't be bothering with the WiFi or Bluetooth radios - the choice was made more because it was easy to find ESP32 devices relatively inexpensively with displays.)
- 3 x CAN to SPI adapter modules.
- A pile of level shifters, so that the various 5V signal lines off of the motor can be connected without frying the ESP32s.
- 16 x 20AH A123 pouch cells and most of the necessary hardware to build a pack - suitable sized fiberglass sheet and long bolts to make compression panels for the pouch cells, clamps and copper strip for connecting the tabs together and for a suitable place to solder the BMS balance leads. Need to get some silicone pads for between cells and Kapton tape to insulate the exposed tab ends.
- 1 x JBD BMS for 16s LFP, with a CAN bus module on it (model OH17SA01, the 60A variant).
Target configuration:
- Update the TSDZ2B to use the 860C variant of OSF. (The VLCD5. variant that's current installed would work, I guess, but if I'm not mistaken, the 860C variant allows changes to happen at runtime and provides more information, whereas the VLCD5 variant is hard-coded using the configuration tool.)
- One IdeaSpark ESP32 connected to the 8 pin and 6 pin ports on the TSDZ2B. The firmware on this one will serve as a virtual 860C display to the motor, broadcasting the motor status over CAN, and listening for frames indicating brake / throttle / rotation / desired assist level or motor configuration.
- One IdeaSpark ESP32 on the handlebars, with the brake, throttle, and wheel sensor leads connected to it. This will broadcast brake, throttle, and rotation sensor values over CAN.
- The BMS and battery pack in the rear mounted battery box. The CAN bus extends here as well, for providing the current battery status. (I've found documentation which looks like CAN bus identifiers and data formats for a JBD BMS, so this shouldn't be a big deal.)
- The CYD on the handlebars, connected to the CAN bus as well. This would, obviously, be the user's primary output device; the only controls that I need here personally, besides for "go to settings", are assist up / down (my lights are wired permanently on).
Most of the wiring up and down the frame for these electronics ends up being a 4 core cable, since the only signals required are +5V, GND, CANH, and CANL; I end up with a total of 4 cables running the frame entirely since there's also a 12V/GND pair for lights, another is the power cable for the dashcam unit I have installed, and the last is the rear camera (it's nice to be able to glance down and see if there's anyone approaching).
I suspect much of the output off of the motor could be ignored at this point: current speed (wheel sensor is broadcast over CAN and so is accessible to the display), battery percentage (comes directly from the BMS), etc - the only output that might be desired directly on the speedometer display as motor _output_ is the current assist level, details like cadence, motor RPM, and power draw, and possibly details about what the motor is acting on (throttle position, brake status), or configuration data. If it's on the VLCD5 variant of OSF, then I know it's even less that's relevant (the only thing is the assist level) and there really isn't anything to change, either.
I've been thinking about the various firmware bits to put together and the hardest one will be the display:
- The one at the motor does two tasks: communicate the display protocol and bridge relevant parts to CAN; receive sensor and assist level broadcasts from the sensor module and display module (aborting if the sensor module disappears by signaling to the motor that the brake has been engaged, canceling all assist and throttle operations).
- The sensor module observes changes on it's GPIO pins and sends out regular frames indicating the status of all of those on a regular schedule.
- The display module observes the CAN bus (also interrogating the BMS, since the JBD BMS doesn't look like it broadcasts without being queried, based on the documentation I can find) and really does most of the work generating a UI out of that data.
Does my architecture seem reasonable (if overkill) and does it seem like there's anything I might have missed?
I've got a 24" tricycle (relatively generic used thing), that I've already taken the time to set up with a TSDZ2B, lighting, oversized battery box, etc.
Now, I'll be honest - the VLCD5 that it came with is kinda crap. I've gone to OSF, which helps a bit (the speedometer and battery meter are both closer to correct, the former because the display wouldn't save changes to the wheel size since it's slightly damaged, having gotten water damage a few years ago when it was installed on my previous bike, the latter because LFP's discharge curve is different enough from NMC's that the meter doesn't end up working well anyway) but since it's a VLCD5 display and not something else like, say, an 860C, it's still kinda crap.
I've got the following kit here or on it's way:
- 3 x ESP32 modules. One is of the "cheap yellow display" variety, a 2.8" backlit color LCD, resistive touchscreen, with frame, and enough minor ports to connect to other devices; the other two are IdeaSpark ESP32 modules with a 1.14" OLED display. The display on the other two modules is more intended to be for debugging purposes than anything, since I fully expect to be writing firmware for all 3 of these. (I won't be bothering with the WiFi or Bluetooth radios - the choice was made more because it was easy to find ESP32 devices relatively inexpensively with displays.)
- 3 x CAN to SPI adapter modules.
- A pile of level shifters, so that the various 5V signal lines off of the motor can be connected without frying the ESP32s.
- 16 x 20AH A123 pouch cells and most of the necessary hardware to build a pack - suitable sized fiberglass sheet and long bolts to make compression panels for the pouch cells, clamps and copper strip for connecting the tabs together and for a suitable place to solder the BMS balance leads. Need to get some silicone pads for between cells and Kapton tape to insulate the exposed tab ends.
- 1 x JBD BMS for 16s LFP, with a CAN bus module on it (model OH17SA01, the 60A variant).
Target configuration:
- Update the TSDZ2B to use the 860C variant of OSF. (The VLCD5. variant that's current installed would work, I guess, but if I'm not mistaken, the 860C variant allows changes to happen at runtime and provides more information, whereas the VLCD5 variant is hard-coded using the configuration tool.)
- One IdeaSpark ESP32 connected to the 8 pin and 6 pin ports on the TSDZ2B. The firmware on this one will serve as a virtual 860C display to the motor, broadcasting the motor status over CAN, and listening for frames indicating brake / throttle / rotation / desired assist level or motor configuration.
- One IdeaSpark ESP32 on the handlebars, with the brake, throttle, and wheel sensor leads connected to it. This will broadcast brake, throttle, and rotation sensor values over CAN.
- The BMS and battery pack in the rear mounted battery box. The CAN bus extends here as well, for providing the current battery status. (I've found documentation which looks like CAN bus identifiers and data formats for a JBD BMS, so this shouldn't be a big deal.)
- The CYD on the handlebars, connected to the CAN bus as well. This would, obviously, be the user's primary output device; the only controls that I need here personally, besides for "go to settings", are assist up / down (my lights are wired permanently on).
Most of the wiring up and down the frame for these electronics ends up being a 4 core cable, since the only signals required are +5V, GND, CANH, and CANL; I end up with a total of 4 cables running the frame entirely since there's also a 12V/GND pair for lights, another is the power cable for the dashcam unit I have installed, and the last is the rear camera (it's nice to be able to glance down and see if there's anyone approaching).
I suspect much of the output off of the motor could be ignored at this point: current speed (wheel sensor is broadcast over CAN and so is accessible to the display), battery percentage (comes directly from the BMS), etc - the only output that might be desired directly on the speedometer display as motor _output_ is the current assist level, details like cadence, motor RPM, and power draw, and possibly details about what the motor is acting on (throttle position, brake status), or configuration data. If it's on the VLCD5 variant of OSF, then I know it's even less that's relevant (the only thing is the assist level) and there really isn't anything to change, either.
I've been thinking about the various firmware bits to put together and the hardest one will be the display:
- The one at the motor does two tasks: communicate the display protocol and bridge relevant parts to CAN; receive sensor and assist level broadcasts from the sensor module and display module (aborting if the sensor module disappears by signaling to the motor that the brake has been engaged, canceling all assist and throttle operations).
- The sensor module observes changes on it's GPIO pins and sends out regular frames indicating the status of all of those on a regular schedule.
- The display module observes the CAN bus (also interrogating the BMS, since the JBD BMS doesn't look like it broadcasts without being queried, based on the documentation I can find) and really does most of the work generating a UI out of that data.
Does my architecture seem reasonable (if overkill) and does it seem like there's anything I might have missed?
