I need a reality check

So for the past week or two, I've had a design slowly evolving for a Pretty Damn Cool project. I need a reality check on whether I can even attach all this stuff to a single arduino and have a shot in hell at any reasonable speed. I know I can physically connect it all. Hell, I have pins left over. This is also my first arduino project, but not my first time on a uC. It is, however, my first time connecting up the hardware.

I'm an amateur race car driver on a very ambitious team competing in a highly competitive endurance racing series. My team's primary financial support comes from the generosity of an Internet community, and we try to keep them sated with boatloads of pictures, in-car video, the works. Our effectiveness there is kind of limited because many race tracks aren't known for having readily available electricity and indoor plumbing, much less Internet connections or cell coverage.

Anyway, this planned device serves four purposes: 1) It collects handy statistics and Science(TM) that would make for pretty graphs to share with our supporters. 2) It collects important data that allows us to fine-tune the performance of the car and monitor for impending failures in real-time so we can pit BEFORE it blows up or catches fire 3) It resolves some nagging communications issues (I'll explain this more later) 4) It gives us a neato piece of kit that we might sell a few copies of to our competition. Naturally they could always build it themselves from schematics and source, but just because you can weld doesn't mean you can solder.

So, starting with the Arduino Mega2560, I'll be adding: 1) An independent 5v, 3v3 and 12vDC/DC converter (1 amp each) - 12v driving the VIN pin, 5v and 3.3v supplied as necessary to all the other ICs and boards 2) An ELM327 and all its associated circuits to talk to all the various flavors of OBD2 computer. This outputs to hardware serial 2. (Serial 0 is reserved for debugging) 3) Hardware serial 1 and some power to an RJ45, to which any of a bazillion GPS modules could be connected. The module itself will live in a weatherproof box on the roof. 4) I2C to another RJ45. This RJ45 carries both 5v and 3v signal levels (shifted by a MAX3372) along with both flavors of power, a ground, and an interrupt pin. Planned for connection to this bus are breakout boards for:

  • Two ADXL345 3-axis accelerometers, one mounted low and one mounted high
  • Two ITG-3200 3-axis gyroscopes, again one mounted low and one high
  • Roughly a half dozen MLX90614 IR temperature sensors pointed at various things - brake discs, tires, engine parts
  • Possibly some EEPROMs if I run out of configuration space on the internal one. These will be on-board, however.

5) Broke out a 1-wire pin to an as-yet-undetermined connector. This will connect to more mundane temperature probes covering things like air temperatures. 6) An HD44780-based LCD, again with an RJ45. They're damned handy connectors. This will be part of a modification of the HUD system our car came from the factory with to make it actually include all the relevant information. 7) A radio comms subsystem. This one bears some explaining.

Communications between the pit and a driver are extremely dicey when you're trying to do it on a budget and without FCC licenses. Oddly enough, FRS/GPRS radios seem to work better than more expensive systems anyway. The driver's helmet is wired with a mic and earpiece, and a PTT button is on the steering wheel. We'd like the arduino to be able to talk to a computer back at the pit to notify us when certain alarm conditions are reached, and for those of us in the pit to be able to have our computer tell the arduino to flip on a light telling the driver to pit in. Just like Formula One! At first, this seemed stone cold impossible using FRS/GPRS - and then I happened to use a landline phone. DTMF tones! You can even encode hex in them!

So this subsystem involves a digital pin driving the PTT (in parallel with the driver's button), a Holtek HT9200B DTMF tone generator connected to the microphone line and an MT8870 DTMF decoder connected to the earpiece line. Naturally there will have to be some protocol work here to handle retries and prevent multiple cars from responding to one another's signal, but that's fairly easily worked out.

8) An on-screen display style video overlay produced by an MAX7456 on SPI. Video in, video out. Pretty simple. It'll get speed, acceleration, and position data. Maybe lap count and driver name or something like that.

9) An SD card for logging all this data. I'd like SDHC and FAT32 compatability, so I've decided not to do it directly in the Arduino - so a second atmega32 will be running this: http://www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-fat32.html I may keep his serial interface, or I may convert it to SPI since those pins are waaaay closer to where it physically fits on the board.

10) A breakout header for 5 LEDs (with onboard resistors) to be used for indicators like 'pit now you idiot' and 'GREEN FLAG GOGOGOGO'

11) A breakout header for 5 driver-actuated switches/buttons meaning to tell the system to send out DTMF tones for 'I'm pitting' or 'I crashed' or 'I got a penalty' or whatever.

12) An RTC, preferably shared between the arduino and the other atmega.

All of this on a through-hole (except a few ICs that don't come in through-hole format) oversized shield under 5x5 inches. Through hole because I suck at soldering. It'll all be breadboarded as individual subsystems first, of course - the last thing I need is to drop $90 on a junk PCB :P

Here's some psuedocode. If I can achieve ~60 loops per second I'll be happy:

   lastSensorTime = millis()
   getGPSData() //serial
   checkSwitchStates() //direct digital pins
   get1WireSensorStates() //OneWire library.
   getStateFromI2CSensorsWithoutInterrupts() //This only gets from the non-interrupt-capable sensors for speed. The MLX supposedly doesn't work with the stock I2C lib, so I'm not sure what I'm going to do here
   pollOBDForSensorData() //serial

   updateLCD() // LiquidCrystal. 4-bit mode on the LCD controller
      setDashLEDs() // via direct digital pins
      sendDTMFTones() //via direct digital pins
   logToSD () //fast serial
   if(debug) logToSerial() //Spit out everything that goes into the log to Serial 0.

onVsync() //Interrupt generated by the onscreen display chip indicating it's safe to change text without 
   if(lastSensorTime > lastOSDRefresh)
      refreshOSD() // Over SPI
   lastOSDRefresh = millis()

onI2CInterrupt() //From shared interrupt line from the I2C sensors
   //Maybe rate-limit this.
   lastSensorTime = millis()

onDTMFTone() //Interrupt generated by DTMF decoder when it hears a valid tone
   if(millis() - lastDTMFTime  > timeout) clearDTMFBuffer()
   lastDTMFTime = millis()
   addToDTMFBuffer() //Direct digital pins.

   if(DTMF buffer contains a valid command for this car)

Man it makes my eyes water just thinking about the amount of work in this project.

a Holtek HT9200B DTMF tone generator connected to the microphone line and an MT8870 DTMF decoder connected to the earpiece line.

Won't this drive the driver crazy? Or will the PTT switch between voice and data and disconnect the driver's earpiece. But if you do this you'll have to have a "phone home" indicator for him. Also your protocol will have to handle a packet being cut in half by the driver.

I'm not sure I2C is a good choice for a sensor network in such an environment. It's good in some ways because the addressing is built in, but not great for long lines. You can beef it up with chips like the P82B715 though.

Here's some psuedocode.

If you get out of this in under 10,000 LoC I'll eat all my data sheets.

An RTC, preferably shared between the arduino and the other atmega.

It will be hard to share without getting into multi-master.

I have no idea if a Mega could do all this. My guess is that it's worth looking at 2-3 processors, you already said one for the SD logging, maybe one for the sensor network and a master controller.


I'm doing a car project at the moment - not aspiring quite as large as you but mine has automatic motor and gearing control (gearing through a CVT hub gear controlled by a servo), temp sensors, car speed, motor speed, battery voltages, current draw, logging to SD card, optional display, wireless telemetry to base station, RTC and quite a bit of code.

I was at about a thousand lines of code last time I checked (but there are a load of libraries not included in that count) and I have a lot more to do.

I'm running this all on an ATmega1280 but the SD card logging is controlled by an external processor on a uMMC board from Rogue Robotics so I don't have to worry about how much time writing to the SD card might take - I just send it over serial and the board logs it to the file(s).


I'm doing something of equal complexity.

I have only about a 1000 lines of code on the Arduino so far (22K binary -- uses 2.5K RAM) -- but the storage and stuff is on a PC on the network -- all the pretty analysis and graphing is on a second. and the The UDP collection system is on a third PC.

So only 4-5K lines of code so far -- I have not counted.

A day gives me about 2GB of data from ONE sensor set. I have a second Make Controller that can collect independently -- so it is actually 2 embedded systems and three PC's -- but I use the built in OSC on the Make V2 system -- so that code is negligible -- I just use what is there and activate it.

So split the tasking consolidate final data "presentation" at the PC level and no sweat!

That project would not frighten me -- but two or three programmers and a lead might be required to get it up quickly with documentation and so on.

Something of that complexity without documentation is likely to become useless within weeks -- so it is an important part of the project -- as are the design docs!

Is that what you wanted to hear?

I'm doing something of equal complexity.

Yours sounds like it has perhaps a bit more too it.

My code is also very similar (about 22K - not checked the RAM but it's not too bad)

In roughly sequential order:

  • Good point about the DTMF driving the driver up the wall. Probably worth doubling up on the radios and just using a different privacy code for the DTMF. This also solves the issue of having to recalibrate the input level on every driver change because we all have different preferences for radio level. Pit-to-car DTMF shouldn't occur under normal circumstances more often than once every two hours, but car-to-pit might be substantially more often (once a lap has been suggested) - so the bigger issue would be the crew being driven mad by tones in their ear all weekend. If we can't find two working channel+privacy code combinations, we can always fall back to the uncomfortable single-radio condition.

  • On other transmissions stomping on top of the DTMF: Pit-side decoding is being done with a really powerful software decoder on a full-sized PC. It should be able to pull prettymuch anything out. Nonetheless, everything will need an ACK and provisions for retransmissions since there are still tracks that will put the car out of radio contact for part of a lap.

  • On I2C: This will be tested extensively. There should be significantly less electrical noise in this car versus a regular roadgoing car since all the fancy electronics have been ripped out - but yeah, there are still bus length issues with some of the trickier sensors (like the IR thermometers attached to the steering knuckle to cover brakes and tires) I'm aware of the P82B715, but I'd like to try to avoid it because you need one at both ends of the line, and adds an appreciable cost to the (potentially disposable) sensor board.

  • On 10K lines of code: No bet. The uSD code is already 2100 lines - and if you count the pit-side software, just the GUI code will be more than 10k.The combined total for both uC's might be under 10k, though - assuming no unexpected challenges arise.

It's also come to my attention that, in the labyrinthine FCC rules governing FRS and GMRS, only certified transmitters themselves can generate non-voice transmissions. So I guess I'm looking into other radio systems.

Edit: Upon further examination, FRS and GMRS are both totally out the window - but MURS (which I'd never heard of until today) is essentially the same thing with less market penetration, more power, and data transmissions allowed with no serious restrictions. They're also bloody expensive.


Have you seen these?? http://arduino-direct.com/sunshop/index.php?l=product_detail&p=65

They are supposed to be good for 1 Km or more...

I'm working on a How-To for these; if anyone has seen a good one, please let me know....

DISCLAIMER: I mentioned stuff from my own Shop...

If you’re in the US then the 900MHz ZBees are probably good to look at for data. If you’re in Europe then don’t go thinking the 868MHz ones are a drop in replacement (they’re limited to 10% duty cycle over an hour :frowning: )