Ardyno on steroids!

This is going to be in several parts. I’ve been working on this for several months and I was hoping to get it all written about in one go but it’s become a bit more in-depth as it’s progressed.

So I’m just going to try and get what I can posted and then follow up as soon as I have the spoons to do so.

Background:

Ok so as you may have gathered I built a dyno/roller, then built the Ardnyo shield (designed by 2strokestuffing [2SS]) for the arduino Uno and linked it to the computer.

Like 2SS I was using SimpleDyno but I was getting quite a lot of variation in the results, so I’d do 3 runs on the same bike and get 3 totally different results. Not tremendously helpful.

The problem seemed to be to do with defining what constitutes “a run” and consequently how I’d start each run. The roller takes some getting going so from stationary so if you’re in 3rd or 4th it either needed a clutch drop (which was inherently unpredictable) or to start the run with it rolling a little already (which was also difficult to repeat). Essentially that ended up meaning that the start of each run was different.

Apparently some dynos have an automatic start and stop RPM but I wasn’t seeing how to do that with SimpleDyno.

FWIW the “instant power/torque” readings were pretty consistent and plausible, so I suspect the data from the sensors was fine, it’s just about how i start and stop each run and how SimpleDyno then interpreted that data.

I also don’t really like having to have a laptop on the bike. There’s stuff spinning and sometimes there’s debris or something pings off and that’s not what I want near my nice work laptop screen. Also if you’re using the PCV software then it’s two laptops, which is way too many laptops for on a motorbike.

There was another consideration too, namely that my roller speed is limited by the bearings to 5000rpm, and since it’s quite a small roller (vs a “proper” dyno) it reaches that max rpm quite quickly. I’d also prefer to limit to 4000rpm so there’s a safety margin.

That means I can go to about the top of 4th, maybe 5th, depending on the gearing but no further because I don’t want 38kg of steel breaking loose at 5k+ rpm in a confined space. That would likely be Quite Bad, specifically for me.

Idk, it was all rather complicated and there were too many variables to get meaningful results which was frustrating.

So is there another way?

Then I was thinking about tuning for drag racing. All I care about there is getting to the finish as quick as possible. Why couldn’t we just test that.

The roller has a circumference, say a foot, and 660 feet in an 1/8th mile so can’t we just measure the time to complete 660 revolutions of the roller (effectively the ground)?

Actually…..yes! (but)

The only limitation here is the roller max rpm, and since within 660 revolutions we may well get over the 5k bearing limit. hmm.

So how about instead of distance (660 roller revolutions) we measure time to get the roller from 0 to 4000rpm, or 500-4000rpm if you want a rolling start?

That could work.

Also then we’d have like-for-like comparisons for any bike, effectively the same as drag racing (but not quite). It would maybe also allow testing different gear/shifting combos too, and measuring the effect of a quickshifter vs manual (for example).

And presumably if you take a roller of known mass, and spin it from one rpm to another rpm in a known time, then I guess someone smarter than me could make any horsepower/torque calculations from that, if they were needed.

Additionally we’d have the time logged for every single roller pulse and ignition pulse, so we could export those as a CSV and graph them in something like google sheets or some custom program.

The spec

I want fully automated testing and I want it in hardware. No booting, no laptops, no goddamn windows.

The moment the roller passes 500rpm (or 0rpm for a standing start), it should start logging the time of every roller pulse (and ignition pulse) until you reach 4000rpm, unless you drop below the cancel rpm, at which point the run cancels and you start over. Any successful run should be automatically saved to a file on an sdcard and once saved it should be ready to do another run right away without any interaction with the device.

This should allow rapidly running a number of tests without having to mess about coming up with filenames for each run or having to manually start each run.

That way I can have the Tuneboss app up on my phone, looking at the live feed from the engine, tweak a setting, do a run. Is it better or worse than previous runs? The whole process should take only a few seconds and allow many, many runs in a session and rapid tuning progression.

So I’ve tried to simplify things somewhat. No laptop, do everything in hardware on the arduino, Treat it like a mini drag run with a (settable) roller rpm for the start of a run, and a settable finish rpm, and the “challenge” is basically to accelerate this roller of known mass (~38kg) from (e.g) 500rpm to 4000rpm for a rolling start, or 0-4000rpm for a standing start.

I want a small display with the relevant info for the run, as well as clear indication of whether we’re in a run or not, as well as some sort of summary of each run (e.g. the time taken and max rpm).

On top of that I don’t want to have to mess about with a computer to see the data or to be messing about with SDcards which inevitably ping off into infinity. I want to be able to access the device via a browser on my phone via wifi and as soon as the run is logged i should be able to pull the logfile off the device as a CSV (spreadsheet) file so that i can take the run and shove it into some graphing software, or maybe see a little graphed preview on the phone browser.

Having the individual times of each roller pulse, along with every ignition pulse should let us plot the entire run too, so that you could (e.g.) just look at the first half of the run, or between x and y motor rpm, or the run as a whole.

[about 3 months later]

So….. quite a lot of experimentation later…here it is (work in progress).

The logging bit is based on an arduino Uno with the Ardyno shield designed by 2SS, and of course once its plugged into the arduino you can’t plug anything else in.

However I noticed that not all the digital pins were used, so I found some extra long pins and extended them through the board so I could add extra modules onto the arduino whilst leaving the shield in place…like a nice RGB-backlit 2-line LCD screen, which could use the backlighting colour to indicate whether we’re in a run or not (e.g. red: in a run, green: run completed) as well as display a few key details like the run duration and RPM.

I managed to do everything I needed on the arduino except the wifi connectivity – so it was able to write to an SD card, the screen worked, but wifi just wasn’t happening. I tried with an ESP-01s wifi board (basically a little ESP8266 module which is set up to work as a wifi “modem”) but I wasn’t happy with how it was working.

The ESP8266 has wifi built in but is 3.3v vs the Arduino’s 5v and given many automotive/bike sensors are 0-5v I don’t think rewiring the shield to run on an ESP8266 would really work.

Also I was getting concerned about speed. The more the arduino has to do the more chance there is of timing inaccuracy. So for example if we want to log a pulse do we just log that to a variable or try to log each pulse to file as it happens?

If we’re logging to a variable you quickly run out of onboard memory (1-2kb available if you’re lucky), but if you write to an SDcard, well that might be slower than the <1ms response times we’re wanting. We’re working in microseconds with the pulses so a couple of milliseconds to write to a file is potentially a big deal.

But then I realised I can just have two boards. The Arduino has the Ardyno shield and the RGB screen, and all it does is log very fast and spew that data to the serial bus, and then show the results of each run on the screen. All the sensor inputs stay 5v and compatible with bike stuff.

Then we have a separate ESP8266 which has the SDcard and the wifi connectivity and the webserver and all it needs to do is listen to the serial bus and put whatever it receives in a file and make it available to download via the browser.

I’ve previously used ESP8266s to build little webservers, and they worked great. Also then we’re not trying to multiplex between Logging-as-fast-as-possible and trying to write to an SDcard at the same time.

I also built a minature test dyno so I don’t have to do programming with a running motorbike and can thoroughly test the inputs I’m getting.

So does it work?

Well, actually, kinda Yes!

It’s not finished yet, but most of it is working:

• It can set start and stop rpm for the roller (e.g 0-4000 or 500-4000)
• Runs/logging start and stop automatically and work intuitively. No user interaction required, it’s all done by detecting roller RPMs.
• It logs the time of every single roller pulse in microseconds (I’ve just redone the logging logic to further improve timing accuracy. Every roller pulse within testing boundaries is now accounted for)
• The screen colour changes to red once you’re in a run and it’s recording data, then turns green when the max roller rpm is reached (run completed) and resets back to blue once it’s ready for the next run – so you only need to have half an eye on the screen colour to know what it’s doing while you’re focussing on the tuning app and live engine data.
• It shows the time taken to complete the run in milliseconds/ms and the max roller rpm achieved (irrespective of run)
• It automatically cancels a run if you drop below a specifiable rpm (e.g 500)
• It resets automatically once the run is completed or cancelled and is ready to start logging again right away
• It can dump the logging data to serial for the ESP8266 to pick up
• ESP8266-part: can log data to files on the SDcard
• ESP8266-part: connects to my wifi or can work standalone (ad-hoc) where it makes it’s own wifi (e.g. for trackside or in the field where there is no wifi)
• ESP8266-part: Can read files off the SDcard and serve them over wifi via a small in-built webserver, so you can use a standard web browser on either phone or laptop to pull the files off. It reads files in chunks so it bypasses the ESP’s available 1-2kb memory limits and it happily serves files 20+mb with the correct content disposition so files appear as a download with the correct filename, rather than trying to open in the browser.

What doesn’t work yet:

• Logging ignition pulses (the functionality is there, I just haven’t found a way to simulate the input yet)
• Display ignition rpm (depends on above)
• ESP8266-part: can’t listen for logging data yet
• ESP8266-part: tested logging to file but nothing to log yet (depends on above)

Additionally I’ve realised that I’d like to be able to determine the test settings (e.g. start/finish RPM) via the web interface so I need to find a way to send settings to the arduino board via the serial bus (but in the other direction), and the arduino can then store those settings in its onboard NVram so that they persist even when the device is powered off. That would be *super* convenient.

I may also make a basic graphing thing which runs in the browser and shows a basic graph of any selected run over time (roller rpm + ignition rpm, maybe some power calculations)

Summary so far:

There have been a LOT of challenges along the way – even just how to lay the boards out and divide tasks between the boards, managing the voltage difference between the boards, as well as stuff like bypassing the memory limits on the ESP8266, where you have maybe 1-2kb to play with, and files that may well be bigger than that (and then segfault the machine if you try to process them) took quite a while to figure out.

I think I’ve also just tonight improved the accuracy of the logging, so that every pulse is logged and accounted for. This code is meant to run *really* fast so just dividing tasks up within the program in such a way that it doesn’t slow the program down, or introduce variation in the execution speed, has itself been..challenging.

I found that the delay between the main program loop executing and the sensor interrupts was meaning we were missing pulses, and whilst the overall timings were right not every pulse was accounted for in the logs and also it wasn’t counting the last pulse after a run was completed etc. Not counting the last pulse is only a little imperfection with maybe less than 2ms effect on a run, but it’s still an inaccuracy and I’d like this done right.

However, now I do seem to have a system which is super easy to use and on my test rig which does 500-5000rpm in under less than half a second I’m getting results within a few ms of each other…i.e. REPEATABLE 🙂

The test rig isn’t perfect and it’s a very low tech improvised switch, and how you contact it affects the acceleration, and the plastic spinny lid can get a wobble on too so there is some variation within the rig (like there is on a bike) so it’s actually not a terrible simulation of a bike, but even so the results are pleasingly close if you do the same motion/pressure each time.

So as far as I can tell so far, this seems quite a bit better than the old setup!

What’s next?

The next things to do are to build some means of generating ignition pulses (that isn’t a motorbike) so I can test the ignition input at the same time as the roller rpm input and get that maths and display logic in place for that.

I also need to get the ESP8266 listening for incoming serial data and logging it to a file for download,

Then I think we can test on the actual dyno and see how repeatable the results are on a real bike

Then if that works, I can take readings from my gen1 so I can finally re-do it onto Tuneboss management, and be able to compare the results \o/ (which is what started this whole rabbithole)

Here’s a few more pics from along the way..

Below is not the best or newest video of it logging a run but it shows the general idea, and the video I shot tonight didn’t turn out right. In the video below it was on a makeshift spindle so accelerated rather slowly and struggled to achieve full rpm (hence the weird noise too). It shows the general idea though, and it works better now.