Data Logger.

I originally wrote the program in Python as the quickest path to log data on the computer. I have had a heck of a time getting any MicroPython working on the M5. So I decided to go with C Code instead, using Arduino IDE. C code is much more efficient anyways. I wasn't concerned about processing power on a laptop, but the M5 might be a bit constrained comparatively. That said, I'm not certain what all the differences are between Python and MicroPython.

Funny you mention smartphones and weather. I've been riding with my phone on the handlebars exposed to sun/wind/rain/bugs for 3 years. I've had to scrap bugs off the case. I've had to drain water from the case. And I've had the phone shut off from cold/low battery when I forgot to plug it in. In all, the phone (LG V30) has held up well! I did notice after my iron butt trip, that the screen now has a slight burned in image of the Calimoto navigation screen. Probably the 103F direct sunlight for hours is what did it in. I should have turned the screen off when I didn't need it. Most phone issues though seem to come from vibration messing up the camera focus motors. I haven't had any issues myself though. As for the M5, I'll make it removable so I can take it inside when parked.

For GPS, they make a GPS add-on for the M5. Some GPS receivers can calculate speed. Others only tell you location and you have to calculate speed based on distance over time. I don't know which one this is yet. For my use, I just need GPS speed to be in the ballpark and I can calculate exact speeds from RPM. My computer based logger already calculates speed off RPM. I just assume 5th gear and no clutch at all times.

The gent from New Zealand found a universal knock sensor that he's putting on his bike. He's wanting to interface that to the M5. Whenever a knock is detected he wants the M5 to trigger an input on the Ignitech which will then retard the ignition. He's also getting an exhaust temperature probe to measure exhaust gas temperature. I'm not sure his plan with that one yet. Maybe just logging it? Either way, the M5 is going to by BUSY.

Today I got the screen printing text. I figured out the 3 touch buttons. And I wrote a routine to set the internal clock time and date. I plan to time/date stamp all the logs. Next I'm going to try a serial port loopback test (tie RX and TX together) to try out the serial interface. The Python code should be fairly straightforward to port over once I get some of these details hammered out.

OminousDarkness said:

Glad to hear that sunlight exposure didn't completely ruin your phone. I just remember hearing something about direct sunlight blah blah blah, so I've always tried to avoid it. Considering you've had no major problems with your screen, I have an interesting suggestion (which may or may not have occurred to you already....)

I wonder if you'd be better off using a rooted Android cell phone. Especially for the price point and capabilities. I'm assuming you're familiar with Java, but you can also use C++...

I started delving deeply into Android app development about three years ago (I had what I thought was a million-dollar-idea but someone beat me to it...) and found that it was very intuitive and relatively easy. Plus, there's already a massive library of code templates, and, via Reddit and other social media platforms, there's a veritable plethora of extremely experienced coders out there eager to help people.

Possibly worth checking into, maybe?

Regarding the knock sensor you mentioned... What conditions need to occur to produce a knock? I've never experienced it with any vehicle I've owned, but I've heard about it enough times to know that it's concerning. And, what does retarding the ignition have to do with it?

Sorry, I threw a lot at you at once. Take your time answering!

Click to expand...

In short, if you advance ignition too much, it can cause the temperature/pressure to rise too high and cause spontaneous combustion elsewhere in the cylinder. AKA Detonation or pinging or knocking. I think technically pinging, knocking and detonation are different, but I don't recall the difference.

I had some pining on my F150 during low RPM acceleration. It fires cylinder 7 and 8 one right after the other. These two are the furthest cylinders from the distributor. It turns out that when the two wires are run parallel, the spark will jump from one wire to the other...even with new wires! Thus, a cylinder is fired 90 degrees too early! Ford put out a TSB telling shops to reroute the wires so they are no longer next to each other. Problem solved and no blown engine.

As for using a phone, my concern is physical interface to devices. How would I connect a SPI, UART and I2C device to a phone? Unless, are you talking about using a phone just as a touchscreen and letting the M5 do the heavy lifting?

Thorn said:

Always interested in the gadgetry!

Might be worth noting that the accelerometer won't really tell you the lean angle, since from your frame of reference as you move through a turn you & the bike will perceive 'down' as skewed towards the outside of the curve. You'd need to mount a gyro & encoder to the frame to get a proper lean angle. Might be able to fudge it using overall g-forces as long as you assume you're running on flat ground? Will be curious where that calculation lands.

Click to expand...

Many accelerometers (including the ones in this device) also include gyros. So I'd be using the gyros for lean angle.

Spockster said:

The accelerometer should allow a horsepower number, of sorts. The ScanGauge has a code I could input that would let it read horsepower. Maybe not a very precise reading but you could see if the number changed after tuning.

Click to expand...

I'd be curious to run a WOT pull from 2k-8.5k and graph G-force vs RPM. I would expect it to roughly trace out the torque curve found on the dyno sheet that someone once posted here on the forum. It'd probably have to be 1st gear to avoid the effects of wind. But F = MA, so if we know A and M, we can calculate F. After more maths and gear ratios and tire diameters, you can get an approximate dyno run graph. Somewhere I have my bike weight written down. I rolled it 1 tire at a time onto a bathroom scale.

OminousDarkness said:

I found nothing negative about your last reply! Don't be so hard on yourself.

So, just how far down the path are you? Because now that we've been having this discussion, I'm trying to convince myself that I need something that I probably don't!

Seems like Eleanor is running very well. I like your idea of a shift indicator, but where would you put it? On a HUD? Because it seems like having to look at the instrument cluster for a cue on the exact right moment to shift would be wildly distracting to me.

Keep in mind, my one and only accident was t-boning a Honda Element (looks like a toaster on wheels) at 35mph, and if I hadn't taken an extended glance at my left rearview mirror, I could have avoided that lady. My point being that I try to keep my eyes on where I'm going, with occasional quick glances at the rearview. (I should also mention that the mirrors were mounted on the ends of the handlebars, and I'd never recommend those to anyone.

I'm eager to hear your reply, because I have a novel idea for a great helmet HUD. I don't know if it's been done, I tried looking on Google, but saw nothing specific.

I have a Samsung Galaxy watch that my brother gave me last year. It's the very first version they made, and it was brand new when he gave it to me. His excuse for deciding he no longer wanted it was "I don't like stuff on my wrists." I asked "Why'd you buy it, then?" His response was "Because it looked cool."

Nowadays this same version can be found easily for $50, many of them new. Coding apps for Android isn't too difficult, so I think it would be neat to use the watch as a HUD. Or, just as a display for real-time data. I've considered places to mount it, where I could see it easily, and I think it would work great above and between the speedo and tach. I'd like to make one of those panels that Knifemaker made. It would work great there.

I dunno. Just spitballing.

Once again, no offense was taken. It takes quite a bit to get me rattled.

Click to expand...

What I have for a shift light is a small amber LED mounted to my windshield frame, quite close to the redline on my tach. It's driven directly from the Ignitech module. I have it set to start blinking at 7500, getting more rapid until it's solid on at 8500. If I ignore that, the rev limiter kicks in at 8700. I found while it could stand to be a bit brighter in full daylight, it can be seen without looking at it. I actually put it on to keep my eyes on the road more under hard acceleration. I don't have to stare down at the tach to make sure I'm not shifting too soon or overreving. At night, it's too bright and almost blinding. But I don't ride as aggressive at night anyways and I usually shift at 7500 max. Most of the time, I'm shifting well before the light anyways. But it's nice when overtaking a car.

Where I'm at is I'm slowly working through a lot of the lower level things. I have the real time clock running along with a routine to set the date and time. This will be needed for log timestamps. I set up a variable to track processor load. It's a dual core processor, but I have to manually assign tasks to one of the cores. The load tracking helps me balance the tasks between cores. I started setting up different screens to display on the touchscreen. So far, it's just a screen that shows date, time, and processor load. I just started working on the serial data. The Ignitech data packets are 152 bytes but the serial buffer is 128 bytes. So I have to split the packets into two pieces. I hope to be reading data from the Ignitech this weekend.

I plan on a diagnostic screen that shows RPM and engine vacuum. This allows me to adjust idle speed. And it allows me to sync the carbs by pinching one carb vacuum hose, than the other and compare readings. I might build some dashboard screens for use while riding, but realistically this device will probably live under the side cover.

I plan on the device running in sleep mode, periodically waking up to poll the Ignitech. Upon response, it will wake up and start logging. I was going to automatically delete the oldest log files as space runs out.

OminousDarkness said:

Sounds like you really know your stuff! What I still quite don't understand is the why of it. What's the advantage of shifting at a specific moment? And, when that light blinks, by the time you react to it that moment is long past, right?

It almost seems to me like it's an awful lot of investment for little/inconsequential return.

Click to expand...

I think you have to see it to fully get it. WOT in first gear, redline comes really quickly! It keeps me from running into the rev limiter and allows for better acceleration. If I'm passing on a two lane road, I'm very near the top of 2nd gear. I can then shift to third as needed without taking my eyes off the road.

I put the dyno chart and gear ratios into a spreadsheet and found the 750 accelerates fastest by holding right to redline vs shifting early.

Here's a few updates. The RPM and KPA is just test data for now, not actual reported data. The GPS data, core load and battery data is real though. The module battery, not motorcycle battery.

I have the data lines tied together, so it loops the data output back to the input. This suggests that the data interface is working correctly. I just haven't connected it to my Ignitech yet. Nevertheless, I was getting 38 samples per second, on par with what my laptop would do. That should translate to over 30 samples per second when connected to the Ignitech. I don't have the SD card working yet. I'm hoping that doesn't slow it down too much.

I have GPS data working. I have a screen setup with 4 parameters shown (out of 10 or so). I'm still waiting on my serial adapter so I'm working on all the other parts of the logger.

Since I'm partnering with a guy out of New Zealand, I set it up with both US and international units. Today I set it up to read parameters from the SD card. Bike specific things like Redline, gear ratios, tire size etc. I have it calculating speed from RPM to form a gear indicator. When calculated speed is within 10% of GPS speed, I pick that gear to indicate on the display. I can also display the calculated speed, but only when it's within 10% of one of the gear's calculated speed.

I haven't started messing with the accelerometers yet. I'm testing writting to the SD card now.

Here's a picture of it out on the road in New Zealand. There's some rounding issues. It's displaying the compass heading, elevation, speed, and unit (not vehicle) battery percentage.

He's probably thinking of something like this?


Basically this works by putting a reflector on a shaft and it measures the time between reflection pulses. It would be hard to do on the 750 since it doesn't have any exposed shafts. The hard tail bike that someone posted had an exposed driveshaft, but that wouldn't give RPM, only speed.

I could measure the pick up coil signals to determine RPM. That would be fairly easy. Or the stock tech measures the frequency of the ignition coil pulses. If I added either of these RPM options, it would make it work with bikes that don't have the Ignitech installed. At least somewhat. It wouldn't have advance numbers, manifold pressure, etc.

I'm thinking of adding a rev counter, as in total revs. Like an odometer? Since I'm not able to count revs directly, I was going to take the reported RPM and multiply it by the time since the last data packets to guess on the number of revs. I don't know what I'd learn from it, but it'd be interesting.

OminousDarkness said:

Very cool! My phone does the same thing. I use it every time I ride. It also records my speed when moving. I decided to start doing this after my friend Caleb's accident. There was debate about what had happened, and how. This way, if something happens to me, at least they'll be able to see exactly what I was doing.

Click to expand...

I use Calimoto to record every ride. It leaves a marker on the in app map for every ride you've ever taken. And it's possible to export each ride as GPX data.


As for more updates, I have my serial data level converter now.
I tested it with a computer simulation of the Ignitech and it's working! Tonight I test it on Veronica!
I've started working on the accelerometer. Lean angles should be pretty easy to come by.
It can sense horizontal rotation (yaw), so I set it up to self-calibrate to GPS heading data.
Whenever I'm moving above a certain speed, it displays GPS heading data and calibrates Yaw.
Below that speed, it displays the Yaw data.
Thus, turning around it will act like a compass.

I have the log files working well now too.

The video should work now.

Here's a log from this morning's ride.
When it works, the calculated speed lines up almost perfectly with GPS speed.
Since I don't have any way of directly detecting the clutch or neutral, it get's a bit flaky at times.
Around 325 seconds, I was coasting and revving the engine.
It tries desperately to find a gear that matches.
Rapid acceleration also causes issues as there's a bit of lag in the GPS response.

The top graph is my calculated speed, with gaps where it doesn't know what gear it's in.
The middle is GPS vs calculated speed. It's spot on most of the time.
The bottom shows what gear it thinks it's in.
I need to set a minimum RPM for when I'm coasting at idle, so it doesn't try to guess a gear.



During this particular stretch, you can see the calculated speed wasn't consistently available until about 30 MPH.
The shift from 3rd-4th shows a speed drop from 33 MPH to 30 MPH and back to 33 MPH as it reselects the next gear.
Same thing happens 4th-5th dropping from 38 MPH to 33 MPH and back to 38 MPH.
The blip at time 80 was me pulling the clutch to see what the calculated speed would do.
The GPS speed shows some lag, most prominent around time 120. The lag is also visible at the beginning when I am decelerating in gear.
Zooming in closely, the lag seems to be about 0.5 - 0.6 seconds.
At time 54 and 154, I pull in the clutch to stop and the calculated speed goes away.
However the calculated speed briefly comes back at time 60-64 as it finds a gear that matches that GPS speed at idle RPM.


Battery usage is about 16% per hour, or 6 hours on a charge.
The G forces are very noisy with road bumps. I need to add some filtering before I can get usable G-forces and lean angles.

I added a new speedometer option.

It will read the RPM and calculate the speed in all 5 gears. It compares these values to the GPS speed.
Whatever one is closest, it picks as the gear in use.
I found the GPS speed had about 1/2 second delay, so rapid speed changes confused the gear indicator.
So now I have it compare the RPM data with a 1/2 second delay to the GPS speed data to pick the current gear.
If the gear is known, it will display the calculated speed with no delay.
If the gear is unknown, it will revert back to displaying GPS speed.

Because of the 1/2 second delay, gear changes result in the gear indication being incorrect for 1/2 second.
Also for that 1/2 second, the indicated speed is off by the amount the RPM changed.
So normal acceleration shows momentary rapid drops in speed.
In practice, it's so brief as to be a non-issue.
Using the calculated speed instead of GPS speed shows a much more steady speed.
It also is more up-to-date.
The GPS speed wanders +/- 2 MPH when your actual speed isn't changing.

I've also implemented the thermocouples.
One was taped to the engine block and the other is just hanging out in the air.
I hope to stuff one inside a radiator hose at some point.
I considered using two more for EGT on both pipes.
Ambient air temp is read from the main unit, or any of the thermocouple units.

All of this has actually been useful.
I found that my current ignition settings are still giving some advance over stock at full throttle. The intent was stock timing at WOT.
I've noticed elevated temperatures when riding for awhile at 80 MPH.
I'm wondering if I'm getting a bit of detonation, and extra heat.
I first noticed it on my trip to CO, but it was nearly 100 degrees and sunny.
But a recent ride, the temperature was below 70 and it was at night.

I refined the calculated speed to better accommodate gear changes.
If the RPM changes by more than 12% within 1/2 second, it assumes a gear change and calculates the speed based on the expected new gear.
After 1/2 second, the GPS speed again matches the calculated speed.
This keeps the displayed speed from jumping around.
It's not perfect, and the graph will sometimes show small spikes in speed, but it's much better than before.

I added 2 resettable trip meters that track miles, engine revs and running time.
I might add a 3rd: one for oil change intervals, one for fuel ups, and one for a particular trip.

I'm working now on rotating the accelerometer data to accommodate non-level mounting.
Once this is done, it'll be possible to estimate speed by integrating acceleration over time.
GPS speed not only has the 1/2 second delay in reported speed, it also has a longer and somewhat variable delay in showing speed when accelerating from a stop.
As a result, the gear indicator isn't reliable until about 3rd gear on spirited accelerations.
Rotating the accelerometer data will also allow me to record lean angles.
Using acceleration data for speed would allow me to maintain speed should I lose GPS reception.
Eventually, I should be able to corelate changes in RPM to acceleration to determine speed and gear without GPS.

Somewhere along the way, my GPS stopped updating 10 times a second and is only updating 1 time a second.
It might have been when I told it to use multiple GPS networks (GLONASS, Beidou, Galileo etc).
Some GPS units lose reporting frequency when using multiple networks.

I put one thermocouple into a radiator tube while I was doing a coolant flush.
Unfortunately, the probe is in contact with the metal housing and it's shorting to ground.
So I'm not getting a proper temperature reading.
I put it in the hose between the thermostat housing and the fill cap from the cap side, but I couldn't get the probe to go past the lip.

I added a grade calculator that compares the altitude every 1/10 of a mile to determine the grade of the roadway.

I added lifetime max speed and min/max altitude.

I modified the physical power button to function as a physical sleep button (short press) and a soft power button (3 second hold) in addition to a hard power button (6 second hold).
This allows for power down with gloves on. Previously it required the touch screen to safely power off (save all variables to memory).
Waking up from sleep happens either by screen touch, or key on/kill switch off.
Sleep happens either by a short press of power button, or 2 minutes of inactivity (key off/kill switch on) and GPS speed under 3.5 MPH.