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 ![:man_facepalming: :man_facepalming:](https://forum.contextualelectronics.com/images/emoji/twitter/man_facepalming.png?v=12)
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!