Ok, new revision with LEDs for the I²C on both sides of the insulator, with a port for the motor temp sensor and a second sensor for the bridge temp (there’s 2 heat sinks per bridge). At the moment not providing for the external speed sensor. Using a Hall or other type where we have to count pulses requires having a crystal clock which the bridges don’t have, so they suffer from +/- 1% jitter at the temps we’re supposed to work at (~5ºC .. 45ºC). This variation can be at different degrees in each bridge, and can occur despite the same utilization of the vehicle (starting while cold, then warms up with use, then a pause will cool it, you step on the gas and curve more to the right than left, etc.) My question is: does this variation cause trouble in measuring the RPM? If it is relevant, I’m tempted to put in another micro on this add-on board, with a crystal, hanging on the I²C bus. Eventually we could off-load something from the main bridge micro (like reading the temps, or external sensors like reading regenerative current). It would be an extra part with firmware. I can also draw it but never actually place it.
We also can design an expansion board for the RasPi so it can control pins (like for the “ignition”/pre-charge board), and there we could interface the 2 speed sensors but that’s a pain because we’d need more cables and from a logical point of view this is a function that belongs at the motor controllers. This expander would connect to the RasPi by I²C and could monitor it and act as watchdog with the power to reset it. We could use an Arduino Mini that I’ve got here. What’s your view over all of this?
On a slightly lateral topic, the Faire registration ends this month. We better start thinking about the text we will submit so they will accept us. I already wanted to go there with 1 or 2 projects; my idea was to pull together yours and my projects to show there, the Trike would be one of them. They want stuff that’s working, it should be “complete” projects (I would say “stuff that does something”). We can’t go there develop things. So, taking another 3 or 4 projects there will always be something that “moves” that we can show there.
Ok, let’s forget about the speed sensor in this iteration. It’s just fine like that. 🙂 We’ll leave the whole data acquisition idea for another time. My goal for September is just to get it running robustly and that’s it! Fun fun fun!
About the registration, go ahead! I’ve only got the trike, so that’s that. If you’ve got the other projects lined up, write it up and send me the text, I’ll complement if necessary. Something tells me that there isn’t going to be a lot of competition to get in there and that we won’t have to “sell” our projects too much. 😉 And they probably want as many participants as possible to launch the event this first time. We’ll just say we have the stuff working and that’s all. We can cancel our participation if we can’t fulfil the promise. Anyway that’s the intention, to have the Trike running long before the event. About the others, you’re the boss. We already have the online videos, both with the trike running and our “makerspace” meetings, so it shouldn’t be complicated to convince them. Plus your curriculum with AltLab…. man, it’s in the bag. 😀
(to be continued…)