Hardware wise this project is very simple, nothing more than a serial LCD being driven by an Arduino Pro Mini. As all I'm doing is collecting data from a serial stream and formatting it onto a LCD, this could be done with much much less.
At first blush the data appeared to be your typical RS-232 or RS-485. However, upon closer inspection it was obvious that a couple things were missing. Primarily a start or stop bit and no obvious formatting; just raw bytes. A plea was tossed out to twitter and caught a surprising amount of wind thanks to the Hackaday staff, but the protocol has still not been identified. By all intents and purposes it appears to be proprietary.
The good news is that it's at a very slow rate of around 200-300 bits per second, meaning a lowly 8 mhz micro-controller can easily collect the data the simple way (using the digitalRead function and if statements). After beating my head against a wall to find a protocol, I finally said to hell with it and decided to just do it the hard way. Here's the important bits found after a few nights of testing and observation:
-23 bytes of data
-No start or stop bits; only 8 bit of data separated by a small delay
-Two communication lines; complimentary data. 0 bits are signaled by pulling one line high and 1 bits by pulling the other line high
-Both lines are pulled high at the same time to denote the start of a block of bytes; most of the time
Ultimately here is what the data looks like:
This being at a division of only 20 ms. The two comm lines are offset from one another to better identify the 1's and 0's.
The code to read this is pretty simple:
-Add a 1 or 0 to the byte in progress based on whether one or the other comm line is high.
-If too much delay occurs between bits, clear out the register and begin anew. This is how the bytes are initially synced and kept in sync.
-If both comm lines are high, go back to the start of the array of 23 bytes and begin repopulating it again. This is how we sync to the data so the correct bytes are associated with the correct variables.
-Since the above only occurs about 98% of the time, also keep track of how many bytes have been stored and go back to the start of the array if it grows over 23.
From there the array will get processed to produce varies figures such as voltage, duty cycle, amperage, temperature, etc. For now the raw data is just dump to a serial terminal while I try to decipher in Excel what everything is. So far I've got a loose understanding of about half the bytes (and at least those being the core necessary), but there is certainly more that are an unknown.