Max Simmonds Build Log

[maxsimmonds1337 (Max)]

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 https://theengineeringocto.wixsite.com/website/ ). 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 (Kunteng controllers) 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!)

[ChrisGammell]

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.

[maxsimmonds1337 (Max)]

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,
Max

[ChrisGammell]

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

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

[kvk (Klaus Kragelund)]

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

[maxsimmonds1337 (Max)]

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 (www.theengineeringoctopus.co.uk) as well as the Tinde line (https://www.tindie.com/products/theengineeringoctopus/oscilloscope-tester-keyring/) . Someone also took my instagram post, and made a write up on hackster.io which I thought was pretty cool ( This Oscilloscope Tester Keyring Puts 'Scope Troubleshooting Powers in Your Pocket - Hackster.io )

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

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 - Speedo for ebike controller using hall effect sensor · GitHub

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!

[maxsimmonds1337 (Max)]

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 GitHub - maxsimmonds1337/EBIKE and my site is www.theengineeringoctopus.co.uk.

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

Ebike_Controller.pdf (203.1 KB)

[kvk (Klaus Kragelund)]

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

[kvk (Klaus Kragelund)]

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

[kvk (Klaus Kragelund)]

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

[maxsimmonds1337 (Max)]

Wow, thanks @kvk! I’ve had far less thorough reviews from some companies I’ve worked at! You pointed out a few things I totally forgot to look at, and in some cases (capacitor footprints!) would have gone to copper, so thanks very much. I’ve addressed each point below:

R4 etc is 20mOhm, guess that is a typo

Yep - typo a copy and paste error on my part, I’ll change that to around 5 Ohms, it’ll be a placeholder anyway, but 20m is very misleading so I’ll change that.

D1 is zener. Replace with schottky. Zeners are sloooooow, so your gate boost turn of will dripple current through the parasitic cap

I think I chucked down any diode from the library - I should have spotted this is the symbol for a zenner! I was going to use something like this Buy Electronic Components Online - LCSC Electronics an SMD UF4007.

R20 is not nessesary, NRST has internal pullup. Normally when using external resistor is should be of 10k or less (avoid glitches)

I did not know that! I guess I should have guessed by the ‘N’ prefix, assuming that’s active low, and therefore has an internal pull up? Looking in the datasheet just now, it does state it has a permanent pull up, but could I have guessed by the ‘N’ prefix?

U2 has abs max 55V, but zener D7 is 56V type, so that won’t protect the module

D7 was there mainly so that the BLDC doesn’t generate a significant voltage to overcharge the battery. Let’s say that the battery is already at 55V (it’s maximum) and I’m going down a hill freewheeling, I wanted to ensure I don’t over charge the battery?
But you make a good point regarding it not saving the IC, however, the absolute max is 65V, so I think it should be okay.

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. I think the MCP6c61 is a rail-to-rail opamp, though (https://ww1.microchip.com/downloads/en/DeviceDoc/20005367B.pdf). But I’m not sure what stage current is, is that an auto correct error and should be stall current?

You’re totally right about the negative current’s - I forgot entirely about that. I’ll add a schottky diode in series with the filter, to prevent any reverse current flow from the Opamp.

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

DOH - again, copy paste error, but I would have taken that to copper! Thanks for pointing this out. I also haven’t yet spec’d the diode, I forgot about that. So I’ll find that too.

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

DS1 is a placeholder for a random LCD module I have at home, but I will check that it’s 3v3 compatible, because I just assumed it would be, nice spot. The IO expander (U3) seems to be fine at 3v3.

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

Yeah this is totally a personal thing - I want to, at some point, write my own drivers for the F030, hence why I have the Hall effect sensors connected, but I don’t really need them for the control (since the driver will be doing that for me). But, to speed things up, I thought I’d start off with a driver. I can then probe the driver, see how it drives things, and replicate it in software at a later date, and, like you say, remove the driver and possibly the hall effect sensors if I go for FOC.

Thanks very much for the review!

[Bikkel (Ruud de Vaal)]

If you got spare pins on your micro I would put some parallel to the SDA and SCL pin. I used it in a IIC design to get rid of the pullups resistors altogether. If you need more pullup you just change the software by make more pins pullup instead of tri-state.

[Bikkel (Ruud de Vaal)]

you got very little headroom for the LCD backlight. I suggest you use a logic drive N-channel mosfet to avoid the Vce(on) of an NPN transistor. It also saves you the base resistor. Note that the Anode and Cathode of LCD displays are floating and normally not connected to GND or VCC. This means if you could connect them somewhere else. Personally I would have gone for a micro version with more pins. You could simplify the circuit by doing away with the bus extender and add more features like PWM the backlight and the contrast.

[kvk (Klaus Kragelund)]

@maxsimmonds1337

You’re totally right about the negative current’s - I forgot entirely about that. I’ll add a schottky diode in series with the filter, to prevent any reverse current flow from the Opamp

The voltage is too small, so a series diode won’t work

Add one accross the input, with a resistor in front. Then you divert current away from the opamp
Also, add a resistor network to offset bias the input to the opamp. Then you can actually measure negative currents

[maxsimmonds1337 (Max)]

@kvk you’re, again, totally correct haha. I’ve gone for the following, what do you think?

(I don’t mind yet about measuring any negative currents, so I’ve kept it simple for the time being)

@Bikkel I agree with what you’re saying, the Vce will definatly reduce the available voltage, so, as per you suggestion, I’ve gone for a logic level FET. I kept a base resistor, just to ensure I don’t draw too much current from the IO expander, I also added a pull down to ensure it’s off when things are turning on:

Thanks a lot guys, I really appreciate it, it helps me learn a lot!

[kvk (Klaus Kragelund)]

@maxsimmonds1337

you’re, again, totally correct haha. I’ve gone for the following, what do you think?

Looks good
But you should change that opamp to a rail to rail one…

[maxsimmonds1337 (Max)]

Are you sure its not rail to rail? I think the datasheet says it is but if it’s not I’ll change

[kvk (Klaus Kragelund)]

Sorry for the misunderstanding

It is indeed rail to rail

[maxsimmonds1337 (Max)]

No worries! You helped me out a bunch, thanks a lot

[maxsimmonds1337 (Max)]

It’s been a few weeks now, and I thought I’d give a small update on what’s going on for those interested.

The eBike controller is now finished (!) and I’m about to send to JLC, check it out:

I’ve designed it so that I can develop the code for them STM32 with the LCD attached, then snap it off and place it on the handlebars as the speedo when it’s done. I can connect it to the controller via a harness, to the LCD board with only for wires, as the LCD board has an IO expander that’s controlled over I2C.

I’ve gone with push fit power terminals, to hopefully mitigate any broken solder joints due to vibrations, and also used some thermal jumpers on the FETs to an internal ground plane for heat dissipation. In terms of grounding, I split the plane up into power ground, digital ground, and analogue ground, with a star point:

I might pull back the analogue ground plane under the SD card, as that really ought not to be there, but other than that, I think it’s done!