Datalogging/telemetry with a wireless router
Posted: Fri Dec 09, 2011 9:49 am
It's been a bit quiet here recently, so thought i'd post something about my latest project that I've been working on.
Not sure what sub-forum this thread should go in (aldl logging? custom code? tool development? hardware modification? "festy's dodgy hacks"?) so off topic it is, unless a mod has a better idea...
It's based around a wireless router, this one is an Asus WL500gp. It has a 266MHz processor, 32MB ram, 8mb flash, 2 USB ports and 2 TTL serial port headers.
A wireless router (aka wireless access point, or AP) is a great hardware platform for a datalogger - as they're small, cheap, solid state (i.e. have no moving parts) and run from 5 or 12v DC usually. Plus running a cut down embedded linux, they're very flexible.
I replaced the original firmware with OpenWRT, which is an opensource linux distribution for routers. I've been playing with OpenWRT for years, but couldn't find anyone who had tried to teach an AP to speak ALDL before, which kind of surprised me.
I could have used any AP that has a USB port and was supported by OpenWRT (or one of the other linux WRT systems, i.e. DD-WRT) but I have a couple of WL500gs laying about so that's what I used.
My ECU is an 808, running 12P with one of my 'DSfesty' NVRAM boards and a CP2102 USB-TTL module for high speed comms.
I was going to wire the 808's RX/TX lines into one of the AP's onboard UART headers, but as the CP2102 is supported by OpenWRT I just plugged it into the USB port instead.
Add a USB stick for storage and a serial LCD, and it makes a pretty decent platform for datalogging and basic telemetry as well (seeing as it is a wireless AP after all).
I'm writing the logger code in perl, and keeping it as cross-platform compatible as possible. It will even run on windows by changing 3 lines of code.
It's intended purpose is for circuit racing logging, and one of the features I'm aiming for is lap overlay - which is more for developing the driver and/or car setup than the engine tune.
This is where the log is split up per lap, and then specific traces (TPS, brake, gear, accelerometers etc) are compared between different laps, so see where time is lost or made up.
i.e. the impact of braking later into a specific corner affecting exit speed, or where the driver is not getting back on the throttle efficiently, or the impact of a suspension change on corner exit speed etc...
What I've got working so far:
* reads adx from usb stick
* connects to ecu and logs timestamped data (only csv format so far)
* 90% of the adx maths is working for logging/dispalying real values
* lcd displays some chosen data values, MALFs etc
* data is streamed over wifi (port 808 of course!) for remote telemetry
* basic 2 way telemetry/telecommand, i.e. remote clearing of MALFs from wifi
* logging start/stop from the router's hardware buttons (red button in the pic above)
Still to come:
* log in xdl format instead of csv
* add buttons to lcd dash for control and menu navigation
* write basic lcd menu for choosing adx, display params etc (currently uses a config file on the usb stick to choose adx and other settings)
* add lap beacon support using a spare digital input on the ECU, to be able to display best/last lap times on the dash and enable lap overlay
* come up with a method of overlaying laps from data logs - kind of important
* try to speed up the loading, it currently takes about 15 seconds to start logging but once it starts it logs message6 at about 22Hz (compared to 32Hz when running on a 2GHz linux box, and it starts instantly)
Ideas to possibly implement, or maybe not:
* cal/bin upload and download from the dash
* TCP->serial glue for TP5 connection over wifi
* integrate GPS for position logging, (and possibly as an alternative to a lap beacon) and maybe even to feed back a VSS signal to the ECU
* any other ideas I get distracted by
The logger code is still a long way from being ready for publishing, but I'm pretty happy with the way it's working so far.
As usually happens, it started out structured, neat and well commented - but as more functionallity was added it became a bit of a dogs breakfast so it's due for a bit of a cleanup now.
I'll post some photos when I remember to take some - but apart from some numbers on the LCD, there's not much to see.
It's just a boring looking wireless router plugged into an '808 after all
Not sure what sub-forum this thread should go in (aldl logging? custom code? tool development? hardware modification? "festy's dodgy hacks"?) so off topic it is, unless a mod has a better idea...
It's based around a wireless router, this one is an Asus WL500gp. It has a 266MHz processor, 32MB ram, 8mb flash, 2 USB ports and 2 TTL serial port headers.
A wireless router (aka wireless access point, or AP) is a great hardware platform for a datalogger - as they're small, cheap, solid state (i.e. have no moving parts) and run from 5 or 12v DC usually. Plus running a cut down embedded linux, they're very flexible.
I replaced the original firmware with OpenWRT, which is an opensource linux distribution for routers. I've been playing with OpenWRT for years, but couldn't find anyone who had tried to teach an AP to speak ALDL before, which kind of surprised me.
I could have used any AP that has a USB port and was supported by OpenWRT (or one of the other linux WRT systems, i.e. DD-WRT) but I have a couple of WL500gs laying about so that's what I used.
My ECU is an 808, running 12P with one of my 'DSfesty' NVRAM boards and a CP2102 USB-TTL module for high speed comms.
I was going to wire the 808's RX/TX lines into one of the AP's onboard UART headers, but as the CP2102 is supported by OpenWRT I just plugged it into the USB port instead.
Add a USB stick for storage and a serial LCD, and it makes a pretty decent platform for datalogging and basic telemetry as well (seeing as it is a wireless AP after all).
I'm writing the logger code in perl, and keeping it as cross-platform compatible as possible. It will even run on windows by changing 3 lines of code.
It's intended purpose is for circuit racing logging, and one of the features I'm aiming for is lap overlay - which is more for developing the driver and/or car setup than the engine tune.
This is where the log is split up per lap, and then specific traces (TPS, brake, gear, accelerometers etc) are compared between different laps, so see where time is lost or made up.
i.e. the impact of braking later into a specific corner affecting exit speed, or where the driver is not getting back on the throttle efficiently, or the impact of a suspension change on corner exit speed etc...
What I've got working so far:
* reads adx from usb stick
* connects to ecu and logs timestamped data (only csv format so far)
* 90% of the adx maths is working for logging/dispalying real values
* lcd displays some chosen data values, MALFs etc
* data is streamed over wifi (port 808 of course!) for remote telemetry
* basic 2 way telemetry/telecommand, i.e. remote clearing of MALFs from wifi
* logging start/stop from the router's hardware buttons (red button in the pic above)
Still to come:
* log in xdl format instead of csv
* add buttons to lcd dash for control and menu navigation
* write basic lcd menu for choosing adx, display params etc (currently uses a config file on the usb stick to choose adx and other settings)
* add lap beacon support using a spare digital input on the ECU, to be able to display best/last lap times on the dash and enable lap overlay
* come up with a method of overlaying laps from data logs - kind of important
* try to speed up the loading, it currently takes about 15 seconds to start logging but once it starts it logs message6 at about 22Hz (compared to 32Hz when running on a 2GHz linux box, and it starts instantly)
Ideas to possibly implement, or maybe not:
* cal/bin upload and download from the dash
* TCP->serial glue for TP5 connection over wifi
* integrate GPS for position logging, (and possibly as an alternative to a lap beacon) and maybe even to feed back a VSS signal to the ECU
* any other ideas I get distracted by
The logger code is still a long way from being ready for publishing, but I'm pretty happy with the way it's working so far.
As usually happens, it started out structured, neat and well commented - but as more functionallity was added it became a bit of a dogs breakfast so it's due for a bit of a cleanup now.
I'll post some photos when I remember to take some - but apart from some numbers on the LCD, there's not much to see.
It's just a boring looking wireless router plugged into an '808 after all