Moar data
 

I have a strange fondness for data, and quantified data at that. To that end, I've progressed a standalone data logger unit, predominantly with a EP vehicle focus. It is not finished and rain ruined my trip to the club meet last weekend, but I am excited to talk about it.

Feel free to ignore and move on.

Across a range of parameters, it captures and logs data at 150 samples/sec. Why 150Hz? It's because it's the lowest common multiple of 25 and 30 and makes for easier visualisation over common video formats. That's a future thing, but seems like it would be a fun thing to do.

The other reason for higher speed sampling is that I want to explore transient phenomena, such as voltage drop in response to throttle at different RPM. Capturing short duration events across an entire run lets you know how your battery is performing under real world conditions.

Easily deals with over 6 mins of data and yields a CSV file on a microSD card. Drop into your favourite tool and analyse away.

There's already a new board on the way, and that's potentially obsolete too, but the current one captures:

• Battery voltage
• Throttle input
• Steering input
• Motor RPM
• 3-axes of acceleration (x, y, z). Leveraging free-fall detection, you could add a speaker module that screams whenever you get airborne.
• Red, green & blue LEDs, because LEDs are a must on any project of mine.

The new board adds current sensing capabilities via a daughter board (up to 100A at this stage) and an accelerometer chip that hasn't been obsoleted...

Things that are close to being commited:

• Motor temp
• BEC output (see comment above regarding battery - this would show BEC performance under load)

Future ideas:

• Bluetooth instead of microSD (needs someone to build an app for different platforms though)
• Real-time clock to track date & time of day
• GPS module (this could eliminate the above, but there are already solutions for this)

The board weights around 7g with a card inserted, but wiring in a vehicle starts to get a little messy. Wiring OCD people need not apply.
https://cimg9.ibsrv.net/gimg/www.rct...b5d46fbf94.jpg

If you need help with the Android side of an app, let me know. Though Bluetooth instead of microSD might not be a great idea, the board will still need to save data during the run for download later because it'll lose Bluetooth signal during the run.

Thanks for the offer to help with an app. If I get to that point, you'll know ;)

The data is all cached during a run, and only written to the card after a button press. Same approach would be used with Bluetooth. The *highly* variable latency of writing to SD cards drove me to use a cached data model. Even with the additional stuff I might add in the future, there's room for over 20 mins of data at 150Hz.

As it stands, and it's not optimised in any way, a single cycle of data capture is well under 2ms, so it would be possible to up sampling to close to 500Hz and maybe beyond for specific use cases.

Probably not much point increasing the sampling rate unless the sensors are rated at providing data updates at that rate.

Would it be viable to periodically flush the cached data to the microSD card?

The ADC for voltage and the accelerometer are well capable of operating in the tens of kHz range. Much of the other stuff doesn't change fast enough.

The code complexity to deal with card writes that could block for hundreds of milliseconds or longer isn't worth it. If I was looking to capture more than ~20 mins of data in a single run, I'd look at other options.

I was thinking more along the lines of protecting against data loss. Either battery losing connection mid run or just forgetting to extract the data before turning it off.

That's reasonable. The version prior to this one had a flash memory chip - I just found that the extra steps to manage writes (you have to erase sectors *every* time), dealing with sector boundaries blah blah (although, in hindsight, I've now got code that would make that issue go away).

Something to think about.