Working on Eboard again!

The exams are finished and all the study projects are done, so I can spend more time on my own creations. It’s high time I resumed my fantastic Eboard project. For the last 9 months the board was hidden under my desk, covered in dust. Not anymore!


I plan to us the Eboard project as my Bachelor’s Thesis. To do that I need to improve electronic systems on board. Right now they are a mess. Ugly protoboards, unreliable connectors, messy software, difficult debugging and so on.

The plan is as follows:

  • assemble the board in its current form to test drive system once again (and to ride it as soon as possible, who am I trying to cheat 😉 )
  • create solid overview of electrical and electronic systems. Decide what parameters should be measured, what should be displayed, what should be logged (and how) etc.
  • select microcontrollers. STM32s are on my mind, tied together with CAN interface…
  • electronics schematics, PCB design and manufacturing
  • port code to STM (if selected instead of AVRs), refactor it, add useful logging

I hope to have the project finished by the end of summer holidays (new term starts in October), but it’s difficult to make any estimates now. We’ll see.

Electric mountainboard – post #4 Electronics finished, software in progress

Hello, it’s been a while since my last update on Eboard project.

Last time I wrote about mechanical part being more or less finished. Since then I focused my efforts on developing electronics and software.


Electronics basically consists of three main parts: Drivers Unit, Battery Unit and Control Unit.

Drivers Unit


Unit is composed of custom board and two ESCs. Board is used to distribute power and signal from receiver to ESCs, measure current drawn by controllers, measure temperatures (of motors, ESCs and current sensors – 6 thermometers in total), control the rear lights and fans. Initially I wanted to use just one microcontroller (uC) in this project, but I decided that it would require too many wires going thorugh the board (analog signals, power, etc.), so I added Arduino Pro Mini clone board (with ATmega328p), which reads all the sensors and sends the data over serial port to uC located in Control Unit.



To mount this board to deck I designed a simple “case” (no top yet)


As you can see I added four slots for small fans to increase airflow – I don’t know if they will be necessary, I will have to carry out a few field tests.

Battery Unit

It will be mounted in middle of the board. I had a little bit of a problem with deciding how to design it so that I could easily remove batteries, mount it properly to the deck (only two holes in it, I don’t want to drill any additional) and first of all it should reliably hold the batteries. As far as electronics goes I built a board with four MOSFETs, which will be used to turn on and off the ESCs. I did that in order to limit “startup” actions just to turning the key in front part of the board.


I additionally installed thermometer on one of the heatsinks to measure the temperature and possibly display a warning on a LCD when certain threshold is exceeded. At higher currents quite a lot of heat can be generated on these transistors (their resistance in on state is 15mOhm). I did a bit of math and at current of 20A ( ~25 km/h on flat ground) 1,5W is generated on each of them, which should result in temperature around 45C (at 20C ambient temperature). Again – tests will confirm or negate my calculations and assumptions.

Control Unit

Main purpose of this unit is to display data on embedded LCD and control a few things (turning MOSFETs in Battery Unit on and off, lights, etc.). Right now ATmega328p is used, but in near future I’m planning to switch to ATmega2560 (graphical LCD requires many pins and I will need additional serial port to receive data from GPS).

CU connected to DU during initial software testing:



Main task on DU’s side is to get readings from sensors, prepare a “packet”, convert it to character string and send it over serial. So far, so good. CU’s task is a bit more difficult, since it needs to perform parsing of received data, check if everything is correct and display data and so on.

Debugging AVRs can be a bit troublesome, so I first wrote PC “emulation” of aforementioned system. I implemented a class “MyString” to create additional layer of abstraction and avoid playing with pointers everywhere in my code. The whole source code is about 600 lines long and is available at my Github. After eliminating initial bugs I uploaded slightly modified version to DU (sending data is easier 😉 ). When I had sending part sorted out, I moved on to CU’s software. Again I had to do a bit of debugging, but eventually the system is working. I guess I reinvented the wheel a bit with creating my own string class, but I’ll treat it as an exercise 😉 Also I made slightly stupid decision when choosing sent data format- packet string is  in format “sIaxx.xIbyy.yTazz.z …  “, where ‘s’ indicates start of packet. Now I think I needn’t have included all the Ia, Ib and so on, since in my parser class I don’t even look at these characters – I just “jump” from one number to next, so these characters just increase transmission time and take unnecessary space in uCs’ memory.

There are a few things to be added, but hopefully in next few days I will assemble everything and finally do some real riding 😀