Style A is meant to allow stacking both boards ? Erf, both stles have their pros and cons. What about “Style C” with vertical pin but not crossed ? Is the length between boards critical ?
Also I guess it’s more convenient to have the USB port vertically like VESC 6. Our enclosure are often messy, lot’s of components/wires everywhere so it’s not that easy to plug a USB cable on the side.
The connectors could always be unsoldered and changed if desired
Sure, but the PCB layout will changed between crossed and not crossed style, right ?
Yep, good call
This ^^
I’ll make a new poll shortly with new images to demonstrate the styles clearly.
Okay. New connector poll time. with hopefully better pictures this time.
Here are our mock-up boards.
Vertical connectors:
Boards can be right next to each other with a connector PCB, like so: Or you can use a reasonable length ribbon cable to have some distance and angle between the boards, like so: FYI, this is a ribbon cable:
Horizontal connectors:
Simpler with no additional parts needed to connect the boards. There will be a gap left between the boards, like so:I would like to use:
0 voters
@SimosMCmuffin I like where this is going, with the ribbon The flexibility increases a lot since you can cram the power board somewhere else
About the balance port, couldn’t it also be vertical? If reduces the footprint a bit but reduces the used space a lot since there are no wires going to the side
Best of both worlds, since we touched the topic, a vertical usb would also be better suited for onboard programming
Thanks
I’m looking at the possibility of using double footprint for that as well, so it can fit either horizontal or vertical connector.
EDIT: Yes, it’s possible to stack the footprints
I think it doesn´t matter much because you have the battery tabs on this side too - so a ballance connector this way shouldn´t use much more space.
Thanks, if you would like me to look at your schematic I would love to! Good work anyways ^^!
Am I overlooking the CAN transceiver or is it intentionally left out?
No CAN at the moment and there isn’t space on the board to add it. I’m intending the main comms to be the HM-10 type bluetooth modules (serial bridges) during a ride, but I’m not explicitly saying that CAN can’t be added in some future iteration, if people request it.
I think there is enough un-tested stuff on this iteration to do a board 
With serial would be easy to hook it to an arduino or similar right? Having all info on the remote would be great, pack temperature, energy used, individual cell voltage
I would not overcomplicate version 1, let’s see how it works first and how the community responds
It’s a standard USART bus, RX and TX lines that work with a certain baudrate. Can be an arduino on the other end for example. The USART pins on the STM32 are also 5V tolerant, so 5V arduino won’t blow them up, although if you’re taking power also from the module, it’s 3,3V.
Some info on the shutdown/wake-up logic on the board:
I have implemented it in a way, that allows the MCU to shut off the 3V3 regulator (which consumes relatively large amount of current, even with no load) completely, which then also shuts down the 3V3 supply. The MCU is not in hibernation, it is off. In this state the module should use less than 100µA of current, which is about 90 times less than in normal standby mode. The only way to wake-up the board is to use an on-board button, which essentially re-latches the 3V3 regulator back online and the MCU can then keep itself powered up.
The reason I want this feature is to protect the battery from a deep discharge when for example putting it in winter storage or other such thing. I intend to add to software configuration to allow to set the time before the module goes to deep sleep and would also allow to discharge the battery to storage voltage after the module would turn itself off.
Thoughts?
Please, please make the default delay for entering sleep mode at least 10 hours. That will still protect from deep discharges. Also is it possible for it to be disabled if the charge port has power?
Certain commercial boards, ahem Evole, go into sleep mode after like 4 minutes or something, it’s even happened at traffic signals before. It’s ridiculous, super-annoying, and dangerous
Great improvements ! I like the way you make it collaborative ! Thank you for that ! Few inputs :
Please put the CAN !!! I think it’s even better than UART as you can use the CAN forward command of the VESC to dial with the BMS using only the BLE of the VESC. I wouldn’t add another BLE module just for BMS plus the one for the VESC although we can use the same one. And it’s not a big deal to integrate a communication between BMS and VESC to switch power off smoothly in case of low voltage on a cell or whole battery. -Shut off mode is great ! As @b264 said, of course it needs to be hours unit for sure. Dn’t you want to get inspiration from the Battman design for that ? I found the power management pretty well designed.
May you tell the interface passing between 2 boards (main and power) ? Which signals are exchanged ?
So excited to see what’s coming next ? 
