Max Simmonds Build Log

Hey Guys,

I’m new to the forum, I’m not a consultant, but I do a lot of home projects for fun. I thought, to give something to the CE forums, I could post my builds here. I usually get stuck somewhere and eventually find some form of solution, and I thought I’d post those struggles here to help people in the future.

Current projects I have are:

Oscilloscope key ring tester

This is just a bit of fun, and a way for me to learn the struggles of actually making a product. I designed a simple keyring that allows people to test out oscilloscopes without probes or large equipment. You simply carry it on your keys (showing off to the world that you’re an electronics engineer!) and use it as and when. I don’t expect it to be of much use, other that having something cool on your keys.

So far, I’m on rev B. The PCB was designed in KiCAD, and made by JLCPCB. Its actually the first time I’ve panelised my own board with V-scoring! (pictures to follow).

Dutch E-Bike

This is a new one - so it’ll be fun to capture the whole project here. I have wanted an Ebike for ages, but I don’t want to pay so much for one! However, I worked in the Netherlands for a while and whilst I was there I picked up a Dutch bicycle. One of my previous projects, back when I was an undergrad at uni, was a self balancing electric unicycle. For this I made a pretty poor 1KW 3 phase inverter, to control a BLDC hub motor.

I hacked apart an old unicycle, welded a new frame and made a (somewhat) self-balancing unicycle. I’ve learnt a lot since then, and I’ve been wanting to redesign it, but my time is quite limited (I want to derive the equations of motion, and design the control loop in a more sophisticated manor, instead of a manually tuned PID controller I used at uni).

Hence, I thought, why not make an E-bike?! I can then develop the controller, I already have the hub motor, and attach this to my Dutch bicycle. I can have an E-bike and prototype the controller while I find some time to design the control loop. Eventually, I’ll add the new controller to the unicycle.

Also, publicly writing about it might give me the stimulus I need to follow through with a project!

1 Like

Hi Max!

Welcome to the forum! You e-uni-bike project sounds like it might be a lot of fun. What were you planning to do in the way of better control algorithms for that? Is it a lean-to-go/stop/steer thing?



So with the unicycle, what I did was use the BLDC hub motor as the input to the system, to apply a force to move the centre of mass back over the pivot point (the axel of the unicycle). That means if the user leans forward, the motor tries to fix the angle error, and drives forwards. Likewise, leaning back applies a “brake”.

It only stabilised in one axis (the direction on travel) but, much like a bicycle, once the wheel is spinning, you have some gyroscopic effect that somewhat stabilises the other axis (perpendicular to the direction or travel). Here’s a picture of my 3rd year uni project - it weighed a tonne and hence the redesign!


So, it’s been about a week since I last posted about this, and I think a week is a good check-in point. It’ll give me some soft deadline needed to keep going with these projects!

Regarding the Oscilloscope key ring tester, I received my panelised PCBs from JLC, and I’m happy to say that they arrived with perfect v-scoring, and no cut traces! I was a little concerned, since space was quite tight, that I hadn’t left enough room between the traces and the v-score, but all was good.

I soldered one up, and it works as expected. I’ve got a dedicated website which I’m going to attempt to sell a few on, along with Tindie.

Regarding the ebike controller, I’ve made a fair bit of progress. I decided to go with a dedicated BLDC driver, and decided upon the MP6535. It’s a great IC, has Hall sensor inputs (I don’t want to go sensorless), overcurrent protection, and a built in buck converter. Also, I was able to get free samples so even better.

I’m now capturing the schematics with KiCAD. I’m looking at integrating some memory IC so that I can save currents, and other things, and then retrieve the data at a later data over PC.

This lead me to a question, what’s the best way of doing this? I suppose I’ll have to write some C that interfaces between my memory IC and the micro, and commands it to dump the data over UART? (I’m going for a STM32f03)

Any help on the last question would be awesome!

And here’s a couple of photos of the oscilloscope tester! I’m particularly happy with my solution to interfacing with the scope, using a BNC pin and a circular trace as the ground connection!


How much data do you expect to capture?

If you just need a simple and portable interface for data capture, could maybe look at adding a micro SD card if there’s room?

Hey Chris,

That’s a great idea, I didn’t think of that. I don’t have any experience with SD cards, but then again I have little experience with reading/writing to memory so it doesn’t make a difference!

I hadn’t fully thought out the memory requirements, it was a more of a nice to have because I’d be interested in looking back over the data, so an SD card would be more than sufficient, and give me the chance to work on something new. Thanks!


Another small update - I’ve been working mainly on the ebike controller as that’s what’s taken my interest at the moment (plus moving houses means that the solder station is not setup, and the oscilloscope testers require soldering. I’m hoping to do this in the next week and get a batch ready).

Regarding the Ebike controller, I’m still capturing the schematic and scope of the controller. I’ve been looking into Ebike braking, and whether I want to incorporate regen. It seems for a bike, given the little momentum it has, regen does not give you a lot.

The BLDC controller I have chosen has a “brake” input, which apparently shorts all the low side MOSFETs of the 3 phase inverter. I’m a bit hesitant to use this as a method of braking, especially at high speeds - but I’m wondering what might happen if I PWM this pin, would it give the effect of braking without causing too much damage to the motor (1000W)? In order to speed things up, I’ll route a line to the uC to the brake line, and have a push button input on the handlebar to use if necessary, but I think I will be relying on mechanical brakes (which are required in any case, as e-braking only works when the motor is turning, unless you want to run the motor in reverse, which is another option I have).

Overall, I think I have now decided on all inputs/outputs I need, number of ADCs, I2C and SPI lines (SPI solely for the SD card, which Chris mentioned).

It’s very much in a draft state, but I thought I’d share the KiCAD schematic - I haven’t used hierarchical layout before in KiCAD, or buses, so it was fun to incorporate them here.

Hopefully in a weeks time I’ll have more to show!

ebike_controller.pdf (185.9 KB)

Another week! Man, do they come around fast. I’ve made some small progress, both with the oscilloscope tester and ebike controller.

The oscilloscope tester is slowly moving forwards - I’ve soldered a few up boards, but before I launch them on their website I’d like a good batch, just on the off chance a few people might buy them!

Therefore, I’ve ordered enough components to make 50 or so. One issue I was having was my liquid flux ‘baking’ on. I tried to remove it with IPA, and a few other things, but nothing would budge it:

Then I came across “Flux-Off” by chemtronics. And it worked wonders:

After some IPA (to remove the dull shine you can see above) it’s perfectly clean. The flux was #835 by mgchemicals, it’s a great flux but damn is it hard to move.

ebike_controller_update1.pdf (279.2 KB)

I’ve recently been working on the IO of the STM32 - usually these pins are already assigned in the projects I work on, so it’s been fun trying to see what pins have what alternate functions, and swapping them such that I can get all the functionality I want.

One thing I’d like is to measure the battery voltage and currents (and, at some point, write them to the SD card) and so I’ve been looing into that this past week. For work, I’ve been designing a ultra precise current measurement circuit. Overall accuracy isn’t an issue, but precision was paramount. So, I’m quite familiar with the types of parameters for op amps that affect current measurements. It didn’t take me long to find a cheap, but suitable current amplifier op-amp. I’ve added a filter, a decade below the motor switching frequency.

For the voltage measurement, that’s quite simply a potential divider, with another filter. I added a zenner since this is a direct connection from battery to MCU.

The next steps are to add the SD card electronics, LCD electronics, the interface to the throttle and add the connectors to the outside world, until next week!


Very interesting projects

About the current measurement, it might be a good idea to go a lot further down than just a decade below the switching frequency, to make sure you are free of the motor ripple

Thanks! That’s a good point, I’ll probably go another decade. I suppose I could do the low pass filter in software, but where’s the fun in that!

Well, here we are again. I think I realised this may be in the wrong section of the forum, but I don’t know how to change it so I guess it’ll have to stay here.

I’m supposed to update this log every week, on a Wednesday, however, I’m consistently a day late so let’s just say this is new Wednesday.

I got a bunch of parts arrive 2 days ago for the OTK - I now have 15 or so ready made. I think I’ll launch the site officially soon (and by that I mean pay Wix so I can use the URL I have, at the moment the site is just like this ). I’ll also make the Tindie page go live, and I’m thinking of putting them on eBay too - who knows, maybe someone will buy one!

The ebike is still the thing I most excited about. The 2 things that have been updated last week are the SD card and LCD. The SD is pretty basic:

I’ve added the 0Ohm resistor as jumpers, just in case I mess up the lines (my first time using SD cards, don’t want to cut traces if I don’t have too!)

And the LCD section:

Why the current mirrors you ask? Well, my logic (which is quite possibly wrong), is that if my LCD is going to be in a different place to my controller (which is likely), then I need to run the I2C lines over some short distance. Now, I’m sure that this would be fine with a simple pull up resistor, but my logic is that using a current mirror will help as the length of the lines, and the capacitance associated with it, won’t introduce an RC time constant, because there’s no R (the pull up). I’d be interested to know what you guys think on this method? I can set the current to be around 1mA, and this’ll act as a pull up resistor.

Finally, this is more for the pcb layout, but I think i’m going to design something such that the LCD section is connected to the rest of the circuit (for SW dev purposes) but snaps off, breaking the I2C lines, and then I can run cables up to the LCD when it’s fitted on the bike - but that’s a future issue.

One thing I haven’t yet figured out, is the DC link capacitors between the battery and the inverter. I know that for harsh acceleration, it’ll be good to have some energy stored in the caps, but I have no idea how to determine the capacitance (any one got any ideas?). I can blindly copy some capacitance from a chinese controller schematic ( I found online, but I’d rather know the logic behind it). I think for now, i’ll also have an ideal diode to prevent regen charging, I don’t want my battery to go on fire because of that!

For now, I need to add the connectors, and I think the schematic is mostly done. A few decoupling caps here and there and I think it’ll be good to go to layout!

Thanks for reading (if anyone’s still following!)

There is a “Build log” section of the forum and I can help move the post over there. However, that will make this post public, as only the Consulting part of the forum is semi-private. If you’re OK with that, I’m happy to help move it.

Hey Chris,

Thanks for the help - I think that’s fine to make it public, I would like to make this an open project at some point (the ebike) so I see no issues with moving it over.

Thanks very much,

Great, well I have been enjoying the updates, please keep them up! Love me some 0 ohm resistors too! :slight_smile:

The current mirror idea is interesting. How far a distance do you expect the LCD to be from the rest of the circuit?

am not sure the current mirror is a good idea.

Did you check the compliance range, how far to the rail it works. Also, coming into and out of current feed, the transistor delay can be significant

A standard pull up works good due to the margin of the positive trigger with respect to the 3. 3V rail

Hey Guys!

Before the update I’ll respond to the messages from before, sorry the replies are delayed!

Chris - I don’t expect the distance to be too far, a meter at most. I know I2C can be okay at 100Khz for some longer distances, but I thought it was a neat thing to try. I’ll probably add some pull up resistor footprints, so I can compare the waveforms I get from the two methods.

kvk - I haven’t done much testing, but I did google the idea afterwards and it does seem to be a method others have used. Like I said, I think the main benefit is that you eliminate the ‘R’ value from the RC filter circuit you get, with the parasitic capacitance the wires introduce. I’ll post my findings here as to whether it makes a difference or not.

Regarding the update, the Oscilloscope tester keyrings went live about 24 hours ago, and I’ve actually already sold a couple which I’m super happy about, having never sold any electronics before! The website is now live too ( as well as the Tinde line ( . Someone also took my instagram post, and made a write up on which I thought was pretty cool ( )

Regarding my ebike project, I decided to play around and see what’s the likely voltage I’ll see when I throttle back, and the motor turns into a generator. Since I’m using the triple H bridge configuration for generating the AC waveforms for the BLDC motor, the MOSFETs internal body diode will act as a crude 6 diode rectifier. I was interested to see whether the generated voltage would be sufficent to charge the battery. I’m not (yet) interersted in harvesting this generated power, rather I want to ensure that I don’t over charge the LiFePO4 and cause a fire.

I bodge together a 3 phase rectifier, and hooked this up to a scope to see what it’s likely to be:

The generated voltage reached ~20V. The horrific spikes after the ramp is when the BLDC hub motor fell off the bench :man_facepalming:

Of course, this generated voltage is proportional to the speed, and this is a constant defined by the motor. It would be best for me to determine this constant, and then I can use it to estimate the generated voltage at a particular speed, for example the max speed of the bike. If this voltage it over the battery voltage, then charging will of course happen. I will then calculate the amount of kinetic power, and see how much electrical power is available, and therefore the available current. Hopefully this will be less than the C rating of the batteries. I believe it will be, but I think this is a good learning exercise and also a good sanity check.

That then got me thinking about how I will measure the speed, since that’s needed for determining the motors constant I mentioned above. I decided to take the BLDC’s internal hall effect sensor, and use that. It generates a pulse each time 1 of the 23 poles is over it, primarily used for commutation. This occurs every 15 degrees the wheel rotates. Therefore, I should be able to count the number of pulses in a particular amount of time (lets say, 500ms) and then get an average speed over this time.

I’m a fan of the STM32 series micros from ST. I used them at uni, and I have a dev board to hand. It’s the prime reason why I chose the STM32f0 MCU for the ebike project. I quickly through together some code (I prefer to get down to the register level and twiddle bits myself, I can’t seem to get my head around all this high level abstraction libraries for MCUs), and managed to get two interrupts going: one for the 500mS delay, and the other for counting pules of the hall effect sensor. I have a simple board with a pull up resistor (the hall effect sensors are open collector outputs) and a capacitor for low pass filtering. This goes into one of the MCUs GPIOs, and a rising edge trigger an inturpt, which increments a counter.

When the 500mS interrupt triggers, it takes the value of the counter, and converts this into MPH (by knowing the diameter of the wheel, and the fact that 23 pules = 1 full rotation, this is quite simple to calculate). I haven’t yet implemented the code for calculating the MPH, but the 2 interrupts and such I have uploaded here for anyone who’s interested -

And that’s about me done! I’m now going to go finish the code and see if I can get the MPH reading done. I think I will then use the ADCs to measure the voltage generated by the motor, and divide this by the speed, and print out the motor speed constant. I’ll need to have the code written for the Ebike’s firmware anyway, so I guess it’ll be good practise!

A little later than usual, but unfortunately not a lot has changed since the last post, and I can’t imagine my schematic updates are all that riveting.

I’m now at the stage of assigning footprints to the schematic symbols, so it won’t be too long before I can start the 4 layer board, hopefully I can get the designs into JLCPCB before xmas is over, and get their 4 layer + SMT assembly deal, for something like 2$!

Attached is the current schematic, I’m going to make it available, with the board manufacturing files, code and BOM, on my site at some point, as I think it’ll be cool to make this open source. The github link is and my site is

Let me know if there’s any glaring mistakes in the schematic!

Ebike_Controller.pdf (203.1 KB)

Nice looking schematics

Some comments, maybe Error 40 from my side:

R4 etc is 20mOhm, guess that is a typo
D1 is zener. Replace with schottky. Zeners are sloooooow, so your gate boost turn of will dripple current through the parasitic cap
R20 is not nessesary, NRST has internal pullup. Normally when using external resistor is should be of 10k or less (avoid glitches)
U2 has abs max 55V, but zener D7 is 56V type, so that won’t protect the module
U4 is is not a rail to rail opamp, so you cannot measure the stage current. Also, you need protection on that input, the motor currents can be negative

C23 is 0.47n, you need minimum 22uF for the buck converter
D8 should be schottky

DS1 datasheet is hard to find, but AFAICS LED must be supplied from 5V. So no R34 and you need to drive it higher than 3.3V. The controller also seems to be needing 5V

A side comment. BLDC has more noise than FOC. The F030 can handle 3 phase FOC with the ST motor control library, so you could remove the need for the motor controller and hall sensors. Don’t know if you have other specific reasons for BLDC control. Maybe sourcing issues