Switch Network Protocol to JSON

[egtoney]

Change the network protocol between the car and this program to JSON as opposed to the current custom network protocol. This allows us to avoid complicated REGEX and also allows us to change the data sent over the network.

[egtoney]

For those interested, a real telemetry network log with the CarEmulator has been uploaded to this project to give a good idea of what the new network protocol looks like. Subject to change but close when it comes to format.

here is a link!

This still needs to be implemented.

[dcambron]

Ethan,

Looks good. Keep in mind though that whatever is implemented, it needs to
re resilient to lost and corrupted data over telemetry. We often lose
symbols or recieve extra characters. Telemetry will go in and out of range,
etc.
On Jun 9, 2015 11:29 PM, "Ethan Toney" notifications@github.com wrote:

For those interested, a real telemetry network log with the CarEmulator
has been uploaded to this project to give a good idea of what the new
network protocol looks like.

here is a link!
https://github.com/KentuckySolarCar/Telemetry-GUI/blob/development/example_data/example_telemetry_data.txt

This still needs to be implemented.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[egtoney]

What would you say is the most common error that occurs? Partial messages, insertions of extra bytes, or swapped bytes. This will help me chose the best data format to use.

[dcambron]

There are two things that commonly happen:

1st) Often the car will go out of range of telemetry. The telemetry boxes
seem to be able to buffer some data. When the car comes back in range, I'll
get a bunch of data really quickly over the port (I'm assuming the
telemetry box is emptying its buffer), but depending on when the buffer
filled up, there will be a partial message somewhere.

2nd) I think we get corrupted bytes sometimes. Not necessarily that bytes
have been left out, but just have been corrupted to a non-printing symbol.
Occasionally some extra symbols will be inserted.

As far as I can tell, we've never had an issue with swapped bytes.

On Sat, Jun 20, 2015 at 12:54 PM, Ethan Toney notifications@github.com
wrote:

What would you say is the most common error that occurs? Partial messages,
insertions of extra bytes, or swapped bytes. This will help me chose the
best data format to use.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[egtoney]

Okay, I'm not quite sure just how bad the corruption is for the bytes but if you think it is necessary I can throw together a quick script that uses Hamming Encoding to fix one bit error every 8 bits.

As far as the partial messages go there isn't really much I can do to prevent that. The only way I could really do that is by doing what I assume the telemetry boxes already do, by adding the message to the buffer if the receiver doesn't respond saying it got the message.

[dcambron]

I don't think it's bad enough to mess with Hamming Encoding. Just make sure
the program gracefully handles it by not updating any values to something
really weird. Like, If the current received is like 10000 amps or the
temperature is 2540 C, then we shouldn't trust that data.

I don't think it's worth messing with extra message hand-shaking either for
now. Lets just get all of the number crunching going, and if it turns out
to be a problem later then we might even just buy better telemetry boxes.
I've been wanting to go to something not rs-232 for a while.

On Sat, Jun 20, 2015 at 1:30 PM, Ethan Toney notifications@github.com
wrote:

Okay, I'm not quite sure just how bad the corruption is for the bytes but
if you think it is necessary I can throw together a quick script that uses
Hamming Encoding to fix one bit error every 8 bits.

As far as the partial messages go there isn't really much I can do to
prevent that. The only way I could really do that is by doing what I assume
the telemetry boxes already do, by adding the message to the buffer if the
receiver doesn't respond saying it got the message.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[egtoney]

Okay sounds good!