Cycle Analyst V3 interface to Arduino Nano33 IOT

[HillCruiser]

The Cycle Analyst throttle input is steady as a rock using the analog output of the nano33; I'm sold on these little boards.

I also managed to get the throttle signal of one board to be read from the other board.
(First I tried to parallel the nano output; both to the CA and the other nano's analog input but couldn't get it to work.)

So instead, I used MCP4725 boards (analog output via I2C) to take one's board throttle counts to an analog input of the other board.
This provides near instantaneous coordination between the front and the rear motors
It also frees up the serial port 1 on each nano so I ordered a 5-3.3v level adjuster and will again try to bring the Cycle Analyst's
log stream directly in...

 

[HillCruiser]

So now I'm in the phase of ride, fine tune, ride...
I'm just using the front wheel control right now to get it calibrated.
It's responding well to the inclines and backing off power when leaning. Nice!
The handling is markedly improved with the extra weight and a driven wheel on the front.
There's also some type of gyro effect from the big, spinning unsprung mass in the front that tends to keep the bike upright.

But that's not to say there haven't been some glitches
The raspberry pi would switch which serial port it attaches to each nano at startup.
So I added a prefix ("F" or "R") to the serial stream from the nano and the when a complete sentence is received by the pi,
I just check if it's reporting front or rear by the prefix.

Also, on some boots, there would be only one nano attached by the pi.
It got worse when I started running a tiny little 5v fan so I figured it was a power issue.
It's a 5v, (reported) 3a power supply but the inrush was too much, so insead of powering the nanos off the pi's serial port,
I supplied 12v to the nanos Vin. Now, the nanos boot at powerup before the pi has even thought about assigning them serial ports and all is good.

 

[HillCruiser]

I finally received level shifters to change the cycle analyst ttl output from 5v to 3.3v so the nano33 IOT could read the logging directly.
Turns out it was one of the rare mods that worked the first time Now that the nano has the direct power feedback from the CA,
I can set up a closed loop control on the throttle based on power rather than just throttle voltage.

The magnets for the traction control also arrived so I stuck them around steel spoke ring on the front drive and now making a hall sensor to read the pulses:

 

[HillCruiser]

Just for the record, I wanted to sum up my experiences with the Nanos and where the design finally ended up.
I went through several pairs of Nano's and it always ended the same; failure of one of the nano's to upload and intermittent failure to have a usb port assigned by the raspberry pi. I kept one nano in the design for its excellent and stable IMU and it's analog output (for one of the throttles) and used an arduino Mega2560 to replace the other Nano.
The Mega is connected to a serial stream from each cycle analyst, the serial data from the nano supplying inclination and roll (and sending it a throttle request) and a USB connection to the raspberry. This configuration gives the Mega access to all the data and it makes the calculation for both throttles; one sent to the nano and the other to a MCP4725.
All the comm links have been proven to be highly reliable and the throttles signals to the cycle analysts are rock steady. Due to the much larger physical size of the Mega, a new control enclosure was used; it houses the Pi and it's ssd, the Arduino Mega, two throttle relays and a couple of enviro sensors. The Mega is of course an overkill for this project but it having four serial ports was expeditious.

 

[amberwolf]

Were the failed nanos 3.3v I/O? Or any of them 5v? (am curious because I intend to use some Nanos for various itty bitty project things both ebike and not, if I ever learn enough programming to start the projects).

Or do you suspect some other problem as the cause?

 

[HillCruiser]

The nano33 iot's are 3.3v boards. The mega I had laying around, and am now using, is a 5v board and works perfectly.
The main issue was the usb port on the nanos. I tried powering from USB and then tried powering them with 12v directly because I thought it was a USB power issue.

Both nano were plugged into a raspberry USB port for communication. They would work for a while but then become like ghosts on the Pi's serial ports; sometimes there, sometimes not; sometimes they would swap ports; then they wouldn't upload unless the reset was pushed and finally they wouldn't upload at all as they became even ghostier on the pi.

The arduino mega 2560 I'm using now seems to be almost bullet-proof; I would definitely recommend it to someone just getting started. (I bought a new one for this project but my older one continues to work after a couple years of prototyping; which in my garage meant a lot of abuse; I was just learning myself It has enough serial ports to pull data logs from two cycle analysts, from the IMU data from the one remaining nano and still communicate with the raspberry when it transfers all the data over for display and logging in a database.

 

[amberwolf]

The nano33 iot's are 3.3v boards. The mega I had laying around, and am now using, is a 5v board and works perfectly.
The main issue was the usb port on the nanos. I tried powering from USB and then tried powering them with 12v directly because I thought it was a USB power issue.

Both nano were plugged into a raspberry USB port for communication. They would work for a while but then become like ghosts on the Pi's serial ports; sometimes there, sometimes not; sometimes they would swap ports; then they wouldn't upload unless the reset was pushed and finally they wouldn't upload at all as they became even ghostier on the pi.

That sounds wierd. My first guess is a possible OS bug in the Nano core software combined with something in hardware. If the serial ports on the 3.3v are also 3.3v, but the serial on the other is 5v, that could cause a problem--the 3.3v signal might be barely readable by the 5v end, and the 5v signal might be damaging to the 3.3v end. (depends on the buffer design they use; it's one reason I prefer optoisolated current-loop comms like MIDI uses).

The arduino mega 2560 I'm using now seems to be almost bullet-proof; I would definitely recommend it to someone just getting started. (I bought a new one for this project but my older one continues to work after a couple years of prototyping; which in my garage meant a lot of abuse; I was just learning myself It has enough serial ports to pull data logs from two cycle analysts, from the IMU data from the one remaining nano and still communicate with the raspberry when it transfers all the data over for display and logging in a database.

Which specific Mega and Pi are you using? (from which seller)

I ask because I will probably end up needing one or both of those at some point for one of my non-ebike projects, to read some sensors and respond by controlling what will amount to a database of sounds to be played back by little dedicated sound playback boards, and send signals to motor-control boards.

 

[HillCruiser]

That sounds wierd. My first guess is a possible OS bug in the Nano core software combined with something in hardware. If the serial ports on the 3.3v are also 3.3v, but the serial on the other is 5v, that could cause a problem--the 3.3v signal might be barely readable by the 5v end, and the 5v signal might be damaging to the 3.3v end. (depends on the buffer design they use; it's one reason I prefer optoisolated current-loop comms like MIDI uses).




Which specific Mega and Pi are you using? (from which seller)

I ask because I will probably end up needing one or both of those at some point for one of my non-ebike projects, to read some sensors and respond by controlling what will amount to a database of sounds to be played back by little dedicated sound playback boards, and send signals to motor-control boards.

I have the Arduino Mega 2560 and Pi 4b 8gb purchased from X2Robotics here in Canada; The arduino connects to the Pi using USB; both of these are really robust and play together well. They are both powerful versions that can pretty much handle anything you throw at them. I've been using SQLite for the database running on the Pi and it works great. For the display I use a 7" hdmi monitor attached to the Pi and QT Designer for the screens. Each board by itself works good, but the combination of the two of them is awesome; the Arduino is great for sensors and comms and the Pi provides the database, displays, wifi and higher end capabilities. The Pi natively uses an sd card but mine is now running on an external SSD that really speeds it up.

 

[amberwolf]

Thanks. I made some notes in my project file for this when I get far enough to need those.

 

[HillCruiser]

maybe best to pick up an arduino and pi now as the supply chain for these was seriously disrupted and only now is recovering.
It's going to take a while until you're comfortable with using them so a little winter tinkering before you actually need them might be a good idea.
The biggest issue I had was making robust connections for a moving vehicle but as my soldering skills got better; so did the reliability of the systems Both the pi and the arduino can be purchased with "shields" that provide screw terminals which really helped as well. Everything wire now is either under a screw or soldered...
A good power supply system really helps as well; I'm always amazed at how many tiny black wires are needed for power supply common, also quite a few for 5v sensors. I cut up arduino mega shields to make my power distribution; you can solder on the bottom and screw on the top!

 

[amberwolf]

It would be "spring, summer, fall tinkering" here. With up to >120F highs in summer, and still >100F for too much of the rest, winter is when everything outside gets done.

I've been making lists of handy bits and bobs with links to sales pages for them, but ATM I don't know enough about exactly what i will need to buy any of them; I don't have the budget to just buy whatever looks good in the hopes I can use it later (I have done that far too often in the last several years and have a pile of projects to do with them that I am not even sure I can do now, with various intervening events some of them have become irrelevant).

But it probably wouldn't hurt to have a better base computing / control unit than I would ever "need"...I just don't understand the differences between them all well enough yet to pick one out.

BTW, if the supply chain was disrupted and presumably costs went up, but it's recovering now, wouldn't it be more cost-effective to wait until the supplies are fixed up and costs go back down? (if it wasn't recovering, I can see how it would be better to get something now rather than not being able to get anything at all later)


I have some Nanos that I have done some very few experiments with, but never worked with Pi anything. (I have a small older linux laptop with ubuntu? that I have begun learning a tiny bit about, that's as far as I have gotten there).

Power supplies I have plenty of good and not so great, in many voltages and power/current capability, including adjustable ones like one giant Sorenson and a few smaller ones.

For the non-ebike project, it won't be really mobile, though parts of it will move around a small amount, the MCUs won't be in the moving parts (wherever possible I'll be using cable-operated robotics, so no motors/etc actually inside it for various reasons, all the actual controlling electronics and mechanics in a separate box). The Nano stuff for the SB Cruiser will probably have it's own battery supply or run off the stable lighting battery via it's own DC-DC.

Thankfully my wiring, soldering and crimping skills have some decades behind them--they're far better than my welding skills.