Data

Data

The main point of this whole exercise is data. Acquiring it from the analog sources, converting it to something digital in the Arduino, acquiring the digital data in the Pi and displaying that in a timely fashion.

Arduino

If this were a C/C++ application, I would define some kind of data structure that would be shared on the Arduino and the Pi. One would fill one, transmit it, the other decode it and read it. Unfortunately the Arduino language is C based, it doesn’t offer structs. Best we can do is arrays.

Values

Lets first enumerate the values we have to transmit:

  1. Speed
  2. RPM
  3. Fuel level
  4. Boost pressure
  5. Engine temperature
  6. Indicator right
  7. Indicator left
  8. Check engine
  9. Parking brake
  10. Check oil level
  11. Check oil pressure
  12. Check fuel level
  13. Check ABS
  14. Check air bag
  15. Fog light
  16. Hazards

So that’s 16 values and most of them are only Boolean values. Yet a few of them offer a range.
Let’s expand that list into something more useful.

Value Type Range
Speed float 0-300km/h
RPM Int 0-10000
Fuel level Range Empty-full
Boost pressure Range –+
Engine temperature Range Cold-Hot
Indicator right bool 0-1
Indicator left bool 0-1
Check engine bool 0-1
Parking brake bool 0-1
Check oil level bool 0-1
Check oil pressure bool 0-1
Check fuel level bool 0-1
Check ABS bool 0-1
Check air bag bool 0-1
Fog light bool 0-1
Hazards bool 0-1

Size consideration

If we express every value as a singular item in the array, we have to make everything as big as the biggest value in terms of resolution, which would be either speed or RPM. We need at least integers to capture those values.
An int is 2 bytes on a Arduino with each byte being 16 bits, so 11×2 bytes would be 22 bytes, or 352 bits. That’s a bit inefficient.

Luckily the Arduino language has bit operators, so we can compress the 11 bool values into one int.

It is worth bearing in mind that the analog resolution of the arduino is 1024 levels, so while a char would be too small, an int is way too big.

Other considerations

The above is all good and well but I can of course change my mind, so we need something to identify, a header. Maybe something timing is a good idea? The timestamps provides by milli() and micro() are unsigned longs. Making the entire array to be longs just to fit a timestamp for debugging would be crazy. Let’s just reserve one int, so we can create diff timestamps or serial numbers or something?

Make it so

So we can have an array of ints:

  1. Header
  2. Timestamp
  3. Speed
  4. RPM
  5. Engine temp
  6. Boost pressure
  7. Fuel level
  8. Flags

This gives us 8x 2 bytes, or 16 bytes and 256 bits. Based on 9600bps, which is the standard rate of the serial port, that would give us 37 updates a second. Which would be a bit disappointing. The port on the Leonardo and Pi should both be able to do 112500bps, which would be 439 updates a second, which would give an update every 2.3ms.

It’s worth bearing in mind, that no matter how quick the transmission is, the screen should refresh at 60fps, which is every 16ms. At 112500bps, the most we can transmit in a 16ms window is 1800 bits, that gives us enough space, no matter what.

Acquisition

There are 6 analog inputs and 11 digital ones (13 pins, minus 2 for the serial port). So given the table above, that lives us with no extra pins for any other flags and 1 space analog data acquisition port. Eek!
Eek! The cat.

Or as Ace would say..
Like a glove..

The only problem now is that I don’t have any inputs to test.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: