The firmware covers the code that runs on the remote and board microcontrollers (ATmega8’s, or PSoC 5’s, depending on which version).
The firmware is public and can be downloaded as a Mercurial repo on www.bitbucket.com from https://bitbucket.org/gbmhunter/electric-skateboard-firmware. Note that this is quite a large repo, as it contains the most recent and old versions of code, which were for different platforms.
(link to comms code here)
Remote To Board Package Format
where: MS1 = motor speed high byte MS0 = motor speed low byte
Board To Remote Package Format
or in hex
The remote initiates the communication. The board listens for a package sent from the remote (starts with ‘skt’). If there is one present in the comms buffer, the in-range bit is set in the status byte and the board moves into the in-range state. The remote listens for a return packet, and if the in-range bit is checked, it also moves into the in-range state.
The remote then flashes the ‘in-range’ LED, and waits for the user to press the on button. When this occurs, the remote sets the on status bit high. The board waits for this bit in the received packages to go high, and then itself goes into the on state.
Battery Charge Monitoring
The state of both the 48V 10Ah LiFePO4 skateboard battery and 9V Ni-MH remote battery is measured with ADCs, using resistor voltage dividers to scale the voltage down to a level safe for the microcontrollers. Voltage measurement provides an O.K. estimate of the batteries state-of-charge, however, the 48V battery’s voltage drops when gunning it, making the display jump around a bit. The batteries charge is displayed using a 3-LED bar graph-type kind of setup on the remote. The LED’s are flashed to increase the resolution of the graph (the flash rate of one LED increases as the voltage drops, before moving down to the next LED).
Speed control is performed with a fixed-frequency, variable duty-cycle PWM peripheral. This is then low-pass filtered and amplified with a bit of external circuitry before going into the DC motor controller (which was designed for POT control, hence the LPF).
AVR Studio was used to program the ATmega8 chips used for prototyping (they come in a prototype board loving DIP package). That was until communication crapped out between the AVRISPmkII and the new AVR Studio 5 (I’m not the only one who has had this problem.. From that point on I uninstalled the AVR Jungo drivers for the AVRISPmkII and used the command line programmer avrdude to program the chips, using the following command:
<filename> was either remote.hex or board.hex
The Final Version
The final version of the PCBs used non-DIP-package-but-slightly-more-powerful PSoC 5 microcontrollers. The firmware from the prototyping boards was ported and developed further in PSoC Programmer.
This work is licensed under a Creative Commons Attribution 4.0 International License .