For about the last year now, it's been one of the side goals of my dabbling with my ELM327 OBDII reader to build a datalogger, which I can then feed to a set of virtual gauges and then overlay it on top of a dash cam video. The original plan was to use one of the myriad gauge controls in a C# application, on top of a background that's a solid colour suitable for chromakeying, and then record a screencast of it, and merge the two using something like Sony Vegas.

Fast forward to a couple of weeks ago, when I found someone else using a piece of software made by a company that's now owned by GoPro, called DashWare... which purports to do exactly what I was looking for. They support data in .CSV format, the gauges look lovely, what could go wrong?

Windows 10, apparently. DashWare doesn't want to import videos after a recent Windows 10 update, because one of the video processing DLLs got updated, and the app doesn't ship with it's own one. The worst part is, because GoPro are looking to integrate this stuff in a future camera at some point, it doesn't look like the software will receive another update. After several hours of mucking about with it before discovering this, I went in search of an alternative.

I found another piece of software called RaceRender. The free version of it limits you to three minutes, and has a massive logo in the top corner - but I can live with those limitations. RaceRender also has the rather annoying behaviour of being super-picky about the encoding of the CSV file - I have to open the file in Sublime Text, save it again in DOS encoding, then import it. At present, instead of writing the file myself, I'm dumping it to the console and then capturing it with the > operator in Powershell, which seems to write a file in an encoding that RaceRender doesn't like (it supposedly works with UTF-8 too, which is what I thought powershell would output).

Anyway, I have a console C# project which imports a C# library I'm writing to support the ELM327 (eventually to be used in a GUI application that's also open source), which currently polls three PIDs at approximately 1Hz. This is too slow for a satisfactory throttle gauge, and will frequently miss peaks on the tachometer, but it's acceptable for a first try. There's plenty of ways to improve the polling rate, which shouldn't take very long to implement.

I'm pretty happy with the results though:

Horsham, VIC, Australia fwaggle




Filed under:


Horsham, VIC, Australia

Navigation: Older Entry Newer Entry