oldswamm
100 W
What I’ve been working on for the last 3 or 4 months is a whole bicycle control system. I’m concentrating on circuit/board design, as I intend to order boards out of China in mid Oct, so I’ll have time to get started on the programming while I wait on them (I think I have a pretty good idea for most of the routines). Anybody have experience with dirtypcbs.com?
Other than batt+ to the controllers, and the phase wires, the only wiring on most of my bike will be a 3 wire harness. +12 volts, G (not really ground, but labeled so), and a serial LAN.
Beyond simplified wiring, my goals are better control and integration for multiple motors, improved (safer) 3 way, improved cruise control, good voltage based regen control (Lebowski did the work for me there), antispin/traction control. I’ll elaborate more toward the end of this post. I’ll also put a zip at the very end of this post with gerbers, renders, schematics, etc.:
I (mostly) have boards designed for the following:
A handlebar display, which would also be the master controller, and would serve ALL handlebar electrics, with inputs for 4 buttons, 4 throttles, a 3way, and turn signals, and outputs for 2 separate displays.
Motor controllers using Lebowski’s controller chips.https://endless-sphere.com/forums/viewtopic.php?f=30&t=72728&p=1098267
A BMS.
A battery charger.
Turn signals, head, and tail lights. I just narrowed this one, so it still needs major work. No schematics or pcb drawings yet (soon), but there’s an image with the current LED layouts.
A board for in the motors, which will put hall and temperature data on the LAN, and will also be capable of controlling fans (or a relay). I just finished the first version of this one since realizing that it couldn’t be done in through hole (to thick), and it’s probably functional, but a messy looking pc board.
Since the system is basically open, almost anything could be added, such as GPS, compass, anemometer, camera control, even an integrated motion alarm and audio.
The boards are designed for everything solid state to be through hole (other than a few diodes, and the board in the motor), and most of the caps and resistors to be surface mount.
Following are a few details on individual modules:
The handlebar unit uses a 40 pin PIC16F1719 (tentatively). There is provision for a temperature compensated real time clock, as well as battery backup to keep it current. There is a circuit to switch the power to throttles and other current drains, as well as another transistor to switch an external 5 volt source for higher current loads such as displays (I would like an LED display (for cold), and would use a separate 5v DC-DC in the battery box), and yet another one to switch the LCD’s LED power. There are pilot holes and space so I could easily drill holes to match a large number of displays, from 122mm to 185mm (outputs for 2 separate displays). I have provision for an iButton interface on this board, which I intend to use both for a key, and for data retrieval. I also made provision for a sparkfun BlueSmirf, so maybe I can interface to a cell phone’s Bluetooth, and hopefully control music and phone functions, and possibly even use it for a display (I know little about Bluetooth, and less about what it would take to write the app(s).
The BMS uses a separate processor for each cell, in a chain of attached boards, which can be ‘broken’ into blocks to match the balance connectors. The processors only draw around 25uA in sleep mode, which is how they will spend virtually all their time, so current draw is miniscule. They communicate daisy chain from one to the next, simply adding data to the end of the received data string, the first word of which would be the command, followed by a ‘cell count’ byte, and sending it on (with a new CRC). The negative end processor is the master and communicates with the bikes LAN and/or the charger. Each cell’s processor takes an ADC measurement of a 2.5v voltage reference, using the cell voltage as the ADC reference (actual cell voltage has to be calculated). I would also measure the cell voltage (Vdd) using the internal reference, mostly for a check. Both ADC results, as well as a temperature measurement, and of course the cell # and a CRC, would compromise one packet of data sent out on the LAN. By breaking it up, into packets, I can help avoid collisions, and easily control the data flow. These processors would expect a cell with 4.200V (or as close as I can get) connected to them on first power up, or after getting a ‘recalibrate on next power up’ command. There’s no provision for current control other than communication with the bikes processor. Oh yea, they can discharge up to 35mA for balancing (if 35mA, (up to24hr a day), isn’t enough, you need a new battery…). The processor, transistor, and references are mounted from below, so they will provide a relatively smooth surface against the battery, and the processor’s temp sensor will give a good approximation of cell temps. Any differences in temp would indicate trouble, and it might be interesting to see how cold the battery actually gets, and how much performance actually suffers.
The battery charger has its own serial interface and power supply, so can function with the battery on or off the bike. It has triacs to control up to 3 AC sources, for automatic current selection. There’s provision to measure the charge current (10A max as drawn), and of course battery voltage. Since each BMS is uniquely serial numbered, the charger (or bike) can recognize which battery is connected, and also retrieve charge/discharge-rate/limit data which would be stored in the BMS master.
The In Motor board has inputs for the 3 halls and 2 thermistors. The hall data would be given priority on the LAN, but with Lebowski controllers, I would probably only use hall info for tire speed, for slippage detection, and possibly for a speed control mode in the controller. There’s also a mosfet to control fans (or a relay), and a shunt to measure the fan current.
The light board consist of 16 LEDs arranged as an arrow on each side and 21 LEDs in an array for a head light with white LEDs, or the tail/stop light with red LEDs. There’s also provision for side markers with 4 or 8 LEDs which can be separately controlled so they can flash out of sync with the arrows. I put a current shunt on the LEDs, so they could maybe be programmed for current, rather than just pulse width, for more voltage independence.
I also have a couple boards partly designed to switch current via a mosfet, to use as high power switch, for a headlight for example, and for a low voltage cutout on the 12v backup battery which also has provision for a simple on/off charge control for the 12v batt.
Each board in the system will have a unique serial #, or address, which will also indicate its general function.
What do I hope to accomplish with this system?
Good control of 2 (or more) motors for off road use.
Programmability. If I want something to function differently I can change it later on.
For example, it should ‘learn’ the throttle, then allow full throw less a programmable dead band.
For the 3 way, I think shifting to a less aggressive throttle curve should be immediate, but to a more aggressive curve should require the throttle to be backed off till it matches the new setting (back off till you feel a slight reduction in power, then you can go for it). Or it could be programmed how you think it should work, if you have a better idea.
The cruise control should control the bikes speed, period (unless you hit a current limit of course). A single click slows N mph (N being programmable) and a dbl click increases a like amount.
I’ve included a button specifically for limit override. I’ve too many times gone for an opening in traffic, only to remember to late that I had a speed or current limit set. The limit override would make full power available no matter what.
I want to be able to control everything from limits and other setup parameters, to what music I’m listening to without taking my hands off the handlebars. I not only have single and dbl clicks available on my 4 buttons, but I can also use the long hold and even triple clicks for alternate functions.
One operating mode I want to include, as well as ‘legal’, ‘economy road’, ‘HP road’, and a couple off road modes, would be a speed controlled mode. Set the throttle to 5mph and that’s the speed it goes, uphill or down, through mud, snow, or on packed ground, over obstacles or through depressions. No coming up against an obstruction, stopping and having to power/push/lift over from a dead stop, especially when I’m ‘walking’ the bike through the rough. If traction control is off, and the bike did stop moving, the tires would continue to grind away at the set speed.
For traction control, I was thinking I would set up maximum acceleration tables for several different currents (I can extrapolate for others), and if either wheel accelerated faster than that, it’s spinning. I can also compare the 2 motor speeds, but that would have limitations too. My tentative plan, at least for one traction control mode, when spinning is detected, would be to send a command to the relevant motor controller, telling it to go to a specific speed, or to resume the stored speed from a specified number of milliseconds ago, then, when spinning stops, go back to a fraction (all such parameters are programmable) of the previous current, then gradually ramp it back up.
When accelerating or climbing, where the front wheel has minimum ground pressure, its speed could be limited to say, 103% of the rear. Feedback from the front suspension sensor could also be used to sense when the front wheel was nearly off the ground and limit the rear wheel torque (anti flip/anti wheelie, selectable of course). If either wheel leaves the ground, the speed should be maintained till contact is resumed.
If I get a one wheel trailer, it would have its own motor, fully integrated into the system. I think an AWD 3 wheeled bicycle (or is it an inline tricycle?) would be great in the snow, as long as things were kept under control (wouldn’t want the trailer pushing you too much).
I would like to have a sophisticated ‘fuel gauge’, that would be capable of estimating, and implementing the current and speed limits necessary to get home on a remaining charge, based on stored and realtime GPS data including altitude changes, and possibly wind speed from a simple propeller type anemometer (and readjusted based on actual current draw, after starting back up the hill against the wind toward home). It would also give me a low battery warning with more charge left, the farther I am from home. I said 'like', not necessarily 'will'.
I don’t need the serial interface on the bike to be very fast. It’s my intention to write the program so it tests the speed to every board at startup, and occasionally during operation, then operate at maybe 10% of the slowest. Also, if the test speeds drop, it’s an indication that something’s wrong (possibly just external noise, but a record of its effect would be interesting for the prototype).
Sorry again for being long winded, but I still didn’t include a tenth (or even 1/100) of what I could have…
View attachment gerbers etc.zip
Other than batt+ to the controllers, and the phase wires, the only wiring on most of my bike will be a 3 wire harness. +12 volts, G (not really ground, but labeled so), and a serial LAN.
Beyond simplified wiring, my goals are better control and integration for multiple motors, improved (safer) 3 way, improved cruise control, good voltage based regen control (Lebowski did the work for me there), antispin/traction control. I’ll elaborate more toward the end of this post. I’ll also put a zip at the very end of this post with gerbers, renders, schematics, etc.:
I (mostly) have boards designed for the following:
A handlebar display, which would also be the master controller, and would serve ALL handlebar electrics, with inputs for 4 buttons, 4 throttles, a 3way, and turn signals, and outputs for 2 separate displays.
Motor controllers using Lebowski’s controller chips.https://endless-sphere.com/forums/viewtopic.php?f=30&t=72728&p=1098267
A BMS.
A battery charger.
Turn signals, head, and tail lights. I just narrowed this one, so it still needs major work. No schematics or pcb drawings yet (soon), but there’s an image with the current LED layouts.
A board for in the motors, which will put hall and temperature data on the LAN, and will also be capable of controlling fans (or a relay). I just finished the first version of this one since realizing that it couldn’t be done in through hole (to thick), and it’s probably functional, but a messy looking pc board.
Since the system is basically open, almost anything could be added, such as GPS, compass, anemometer, camera control, even an integrated motion alarm and audio.
The boards are designed for everything solid state to be through hole (other than a few diodes, and the board in the motor), and most of the caps and resistors to be surface mount.
Following are a few details on individual modules:
The handlebar unit uses a 40 pin PIC16F1719 (tentatively). There is provision for a temperature compensated real time clock, as well as battery backup to keep it current. There is a circuit to switch the power to throttles and other current drains, as well as another transistor to switch an external 5 volt source for higher current loads such as displays (I would like an LED display (for cold), and would use a separate 5v DC-DC in the battery box), and yet another one to switch the LCD’s LED power. There are pilot holes and space so I could easily drill holes to match a large number of displays, from 122mm to 185mm (outputs for 2 separate displays). I have provision for an iButton interface on this board, which I intend to use both for a key, and for data retrieval. I also made provision for a sparkfun BlueSmirf, so maybe I can interface to a cell phone’s Bluetooth, and hopefully control music and phone functions, and possibly even use it for a display (I know little about Bluetooth, and less about what it would take to write the app(s).
The BMS uses a separate processor for each cell, in a chain of attached boards, which can be ‘broken’ into blocks to match the balance connectors. The processors only draw around 25uA in sleep mode, which is how they will spend virtually all their time, so current draw is miniscule. They communicate daisy chain from one to the next, simply adding data to the end of the received data string, the first word of which would be the command, followed by a ‘cell count’ byte, and sending it on (with a new CRC). The negative end processor is the master and communicates with the bikes LAN and/or the charger. Each cell’s processor takes an ADC measurement of a 2.5v voltage reference, using the cell voltage as the ADC reference (actual cell voltage has to be calculated). I would also measure the cell voltage (Vdd) using the internal reference, mostly for a check. Both ADC results, as well as a temperature measurement, and of course the cell # and a CRC, would compromise one packet of data sent out on the LAN. By breaking it up, into packets, I can help avoid collisions, and easily control the data flow. These processors would expect a cell with 4.200V (or as close as I can get) connected to them on first power up, or after getting a ‘recalibrate on next power up’ command. There’s no provision for current control other than communication with the bikes processor. Oh yea, they can discharge up to 35mA for balancing (if 35mA, (up to24hr a day), isn’t enough, you need a new battery…). The processor, transistor, and references are mounted from below, so they will provide a relatively smooth surface against the battery, and the processor’s temp sensor will give a good approximation of cell temps. Any differences in temp would indicate trouble, and it might be interesting to see how cold the battery actually gets, and how much performance actually suffers.
The battery charger has its own serial interface and power supply, so can function with the battery on or off the bike. It has triacs to control up to 3 AC sources, for automatic current selection. There’s provision to measure the charge current (10A max as drawn), and of course battery voltage. Since each BMS is uniquely serial numbered, the charger (or bike) can recognize which battery is connected, and also retrieve charge/discharge-rate/limit data which would be stored in the BMS master.
The In Motor board has inputs for the 3 halls and 2 thermistors. The hall data would be given priority on the LAN, but with Lebowski controllers, I would probably only use hall info for tire speed, for slippage detection, and possibly for a speed control mode in the controller. There’s also a mosfet to control fans (or a relay), and a shunt to measure the fan current.
The light board consist of 16 LEDs arranged as an arrow on each side and 21 LEDs in an array for a head light with white LEDs, or the tail/stop light with red LEDs. There’s also provision for side markers with 4 or 8 LEDs which can be separately controlled so they can flash out of sync with the arrows. I put a current shunt on the LEDs, so they could maybe be programmed for current, rather than just pulse width, for more voltage independence.
I also have a couple boards partly designed to switch current via a mosfet, to use as high power switch, for a headlight for example, and for a low voltage cutout on the 12v backup battery which also has provision for a simple on/off charge control for the 12v batt.
Each board in the system will have a unique serial #, or address, which will also indicate its general function.
What do I hope to accomplish with this system?
Good control of 2 (or more) motors for off road use.
Programmability. If I want something to function differently I can change it later on.
For example, it should ‘learn’ the throttle, then allow full throw less a programmable dead band.
For the 3 way, I think shifting to a less aggressive throttle curve should be immediate, but to a more aggressive curve should require the throttle to be backed off till it matches the new setting (back off till you feel a slight reduction in power, then you can go for it). Or it could be programmed how you think it should work, if you have a better idea.
The cruise control should control the bikes speed, period (unless you hit a current limit of course). A single click slows N mph (N being programmable) and a dbl click increases a like amount.
I’ve included a button specifically for limit override. I’ve too many times gone for an opening in traffic, only to remember to late that I had a speed or current limit set. The limit override would make full power available no matter what.
I want to be able to control everything from limits and other setup parameters, to what music I’m listening to without taking my hands off the handlebars. I not only have single and dbl clicks available on my 4 buttons, but I can also use the long hold and even triple clicks for alternate functions.
One operating mode I want to include, as well as ‘legal’, ‘economy road’, ‘HP road’, and a couple off road modes, would be a speed controlled mode. Set the throttle to 5mph and that’s the speed it goes, uphill or down, through mud, snow, or on packed ground, over obstacles or through depressions. No coming up against an obstruction, stopping and having to power/push/lift over from a dead stop, especially when I’m ‘walking’ the bike through the rough. If traction control is off, and the bike did stop moving, the tires would continue to grind away at the set speed.
For traction control, I was thinking I would set up maximum acceleration tables for several different currents (I can extrapolate for others), and if either wheel accelerated faster than that, it’s spinning. I can also compare the 2 motor speeds, but that would have limitations too. My tentative plan, at least for one traction control mode, when spinning is detected, would be to send a command to the relevant motor controller, telling it to go to a specific speed, or to resume the stored speed from a specified number of milliseconds ago, then, when spinning stops, go back to a fraction (all such parameters are programmable) of the previous current, then gradually ramp it back up.
When accelerating or climbing, where the front wheel has minimum ground pressure, its speed could be limited to say, 103% of the rear. Feedback from the front suspension sensor could also be used to sense when the front wheel was nearly off the ground and limit the rear wheel torque (anti flip/anti wheelie, selectable of course). If either wheel leaves the ground, the speed should be maintained till contact is resumed.
If I get a one wheel trailer, it would have its own motor, fully integrated into the system. I think an AWD 3 wheeled bicycle (or is it an inline tricycle?) would be great in the snow, as long as things were kept under control (wouldn’t want the trailer pushing you too much).
I would like to have a sophisticated ‘fuel gauge’, that would be capable of estimating, and implementing the current and speed limits necessary to get home on a remaining charge, based on stored and realtime GPS data including altitude changes, and possibly wind speed from a simple propeller type anemometer (and readjusted based on actual current draw, after starting back up the hill against the wind toward home). It would also give me a low battery warning with more charge left, the farther I am from home. I said 'like', not necessarily 'will'.
I don’t need the serial interface on the bike to be very fast. It’s my intention to write the program so it tests the speed to every board at startup, and occasionally during operation, then operate at maybe 10% of the slowest. Also, if the test speeds drop, it’s an indication that something’s wrong (possibly just external noise, but a record of its effect would be interesting for the prototype).
Sorry again for being long winded, but I still didn’t include a tenth (or even 1/100) of what I could have…
View attachment gerbers etc.zip
