June 9th: The Project Evolves & my learning continues...

I've started mounting mini switches in the pegboard lid of the project box. I think I'll teach Adam to solder and have him practice on all those switch leads soon :) The pegboard worked out really well since I didn't have to drill any holes, and I get a nice alignment grid...

I've been doing lots of thinking in my "in between time" this week - and "picking the brains" of some people I interact with. I'm using this post to document those thoughts and I'll share some parts I've ordered, as well as some tools / books that I think will increase my learning.

Thinking:
Most of my thinking has been about the "configuration" for a specific car. How will an input trigger lead to output commands on a specific slave? I don't want this logic co-mingled with all the send / receive code on the master, and I'd rather not mess with reflashing the gator+ each time I want to change the behavior of a specific output.

For now, I have an array structure in mind that I think will do the trick.

Example:
Pin 5 on the master is wired to the headlight switch.

In the master's main loop(), all inputs are read >50 times per second

A Pin 5 read returns LOW showing that the switch has been turned on (You can switch ground instead of 12v+ so you reduce the possibilities of short circuits under the dash and the size of the wires to switches, etc)

The array is read to locate all rows where the first integer is 5 (for pin 5)

In this case 3 rows are found:

Input Pin, Slave, Command, Var1, Var2, Var3, Var4 

[05][01][01][01][07][00][00]

[05][01][01][01][09][00][00]

[05][02][01][01][11][00][00]

So, this means that three commands should be sent (these are hypothetical...)

[05][01][01][01][07][00][00]

Input Pin: 5

Slave: 1

Command: 1 (this is the on/off command)

Var1: 1 (this means turn ON the output pin)

Var2: 7 (output pin 7 is the pin to be turned on, and output 7 on slave 1 are the headlights)

Var3: 0 - parameter not used for this command

Var4: 0 - parameter not used for this command

[05][01][01][01][09][00][00]

Input Pin: 5

Slave: 1

Command: 1 (this is the on/off command)

Var1: 1 (this means turn ON the output pin)

Var2: 7 (output pin 9 is the pin to be turned on, and output 9 on slave 1 is the dash lighting)

Var3: 0 - parameter not used for this command

Var4: 0 - parameter not used for this command

[05][02][01][01][11][00][00]

Input Pin: 5

Slave: 1

Command: 1 (this is the on/off command)

Var1: 1 (this means turn ON the output pin)

Var2: 7 (output pin 11 is the pin to be turned on, and output 11 on slave 2 are the taillights)

Var3: 0 - parameter not used for this command

Var4: 0 - parameter not used for this command

This would be a very simplistic "if input" "do something" without any real logic. My goal sometime soon would be to try to map out the full operation of a car in this structure to see if I need something more fancy. I have another more complex structure in my head that would maintain a state machine and then allow commands that modify the state machine, allow if / then logic, etc. but that might be overkill.

Once I know the size of this array, I can determine if searching it for a high pin number is CPU prohibitive. I may need to add an index to the array and then have a lookup table like

Input Pin, Start Index, End Index

This would allow me to quickly go to the commands for that input pin. However, if the total command list is only 50-100 items, the other array may not be worth the overhead.

This array structure could easily be read from EEPROM, SD Card, etc - which would allow changing of the car's configuration without reprogramming. For now I'll just build have the array setup in code, but it seems like a good way to go. I can't help but feel like I'm reinventing the wheel here with a command structure and array storage, so I need to look around to see what others have done before. For those with automotive knowledge, there are standards for this stuff - my I2C network & messaging is really a simplified CAN. I don't plan to interface this stuff with other hardware, so I figured CAN was overkill.

I've also been considering the power consumption of the 3 gator+ boards since they will be on all the time on a car that doesn't get much use. There is a sleep mode I'll investigate and I may need to switch the LCDs in some way to reduce their power consumption. It may also be possible to leave just the master on and power down the slaves until needed.

Parts:
LCDs - I know I want the master node to have a serial LCD for output of important items, I'm not sure about the slaves. The "control panel" used a bare LCD and took WAY too many I/O pins, so I spent a little more money and ordered serial / I2C 20x4 blue / white displays. I bought 3, even though I may not use them for slaves long term, they are really handy for debug output, so why not have them for now. I will try them in I2C mode, but I'm not sure I want any extra traffic on that bus, so they will likely get connected to the spare UART on the gator+ boards. This way, I have the option.

I2C Buffer ICs - I found these last weekend - the I2C network is working great now, but for future projects, I really like the idea of I2C instead of ethernet over long runs of cat5. I almost ordered them, and was already designing the perfboard in my head when I saw this line - "Breakout board available soon. This board will enable easy remote I2C bus extensions with standard cat-5 cable. With RJ-45 connector, breakouts for unused cable pairs, option for providing remote power and selectable bus pull-up resistors."  Perfect. I'll wait for those boards to be available, and if I suddenly have I2C problems on this project, then I'll grab the ICs at that point. This type of learning is so awesome, I just keep adding to the toolbox of components I know exist and I know how to use if needed.

Storage - I want some way to store the car-specific configuration and read that configuration at system startup. I'm looking at several options - SD Card, USB Flash Drive, and EEPROM. SD and USB Flash are easily removable and readable via computer, they also give me storage for logging - BUT they consume lots of precious memory space with the libraries that read / write. It might not be an issue... EEPROM is inexpensive, but not so easy to unplug and connect to the computer to update the configuration. I need to keep thinking on this one to determine a) how important is logging, and b) how would an end user that isn't an arduino coder update their car's configuration...


Tools:
Power Supply - I've been wanting to get a selectable voltage benchtop power supply for some time. I'm sure there are less expensive options, but I'm eyeing this one from SparkFun. Once it cools down a bit, I want to setup one of my garage workbenches properly to be able to  work in the garage on this stuff without creating  a room full of wires & parts.

Logic Analyzer - The more I'm learning, the more I want to be able to troubleshoot faster and see what is happening at a lower level. Adding tons of debugging Serial.println() statements and reflashing the arduino program gets old fast. I've learned about logic analyzers and want to get the analyzer from Saleae Logic. I think this will also be a great way to learn more and to help my sons see how digital circuits work.

Inexpensive Oscilloscope - Never owned one, always wanted one - this portable o-scope is a great start without spending $2k :)

Books:
I purchased "Make: Electronics - Learning Through Discovery". I think it will be perfect for teaching the boys in a "lab" type setting. The book has a great line on the cover "Burn things out, mess things up - that's how you learn."

I also grabbed "Practical Electronics for Inventors". I've looked at it a few times before, but wasn't ready. Now that I need to go deep into some MOSFET circuits, I'm ready to get more into the theory and try to do it right. Should be a good way to kill some upcoming airport / airplane travel time.

Not a book, but still interesting, I've been reading the Atmel ATMEGA 324p (cpu in the gator+ board) documentation. Now that I've worked with Arduino-compatible boards for a while, it is interesting to see the process schematic and go one level deeper. I might have to get out my microprocessor design book from  my Computer Science degree - that was one of my favorite classes. Yes, I am a geek in case that wasn't brutally obvious by now.

June 6th - Woodworking!

Today we (both boys & my friend Lou helped in various ways...) built this prototype case for the new project.

The top panel will have a top view of a 68 Firebird, with the major electrical items labeled and an LED for each one indicating that it has power. White LEDs for headlights, RED for brake lights, Yellow for turn signals, etc. Maybe blue for all the other stuff, who knows :)

The top will also have a mock dashboard with an ignition switch (keys & all), a headlight switch (a real one that pulls out for parking lamps, headlamps, and has a rotary dimmer for interior lights...) and a bunch of small switches to activate turn signals, brakes, hazards, windows, door locks, etc.

The bottom panel (it is raised 1/2 inch off the bottom to provide mounting hardware & wiring space underneath) will contain the three microcontrollers and show how the car is divided into the engine compartment controller, the under dash controller and the trunk controller.

June 6th - It's Alive - Part 2!



After adding the CRC16 checking, I added a button on the master and a test LED on each slave. The master's main loop detects the button press and sends one message (to both slaves) if it is not pressed, another if it is pressed (there is no debounce or state management to reduce messages...). The slaves are watching for a specific command with an on / off parameter and turning that pin on or off based on the parameter. The LEDs are VERY responsive to the switch as you can see in the video.

I let the system run overnight and have logged 3.4M messages with ZERO failures at 84.62 messages per second. :)


June 7th Update: Just crossed 10M messages with ZERO failures at 84.63 messages per second. I'm just letting it run at this point until I start coding again...


June 8th Update: 17M messages, still ZERO failures at 84.50 messages per second (interesting that the rate trended downward just slightly in the last 24 hours.) I doubt I will be coding on the system until next week, so I might just leave it running until then :)

June 5: It's Alive!

This is a 3 node I2C network with one master and two slaves.

The board with 4 side LEDs is the master. The side LEDs indicate Slave 1 TX / RX and Slave 2 TX/ RX. 

The slave side LEDs indicate TX / RX with the master. There is no slave to slave communication.

The on-board LEDs on all boards flash to indicate a heartbeat main loop still running...

The master is sending 5 byte "packets" to each slave, and after it sends, it is requesting a single byte acknowledgement from the slave.

I added some diagnostics last night to indicate pass / fail for each transmission / ack pair. I then went to bed.

8 hours later, I have 4.7M transmissions, with ZERO failed packets at an average rate of 149.66 messages per second.

I am VERY pleased with these results. I've tried to increase the speed by removing code, and the best I can do is ~ 160 messages per second by shortening the packet length. The limiter appears to be the selected I2C bus speed at this point, because transmitting to only one node or both still averages the same messages per second. I don't need more speed, this is responsive enough, I just wondered where the bottleneck might be.

Next step is to try longer wire lengths to see if it works and if it affects speed or reliability.

Update:

After lots of trial & error + googling, I now having the network working over 25 foot lengths of cat 5 (longer than should be needed in an automotive application). For longer lengths, termination resistors (I used 4.5k Ohm) are needed. Once I figured out what to use, I went to longer & longer cable lengths. I can do 3 foot without the resistors, anything longer needs them. I also found some inexpensive ($3) buffer ICs designed for running I2C over long lengths, but at the moment they don't appear to be needed. I'm still powering them all via USB, so next step is to get a 12v power supply connected and try running power & ground over the cat5 as well.  I've logged 400k transmissions (5 byte command + 1 byte ack) without failure at ~165 messages / sec with ZERO failures.

I'm very happy with the progress so far - the networking was the part that concerned me most about this concept.

Update - More progress:

I now have CRC16 checksums being added to the outgoing 5 byte command packet. The slave uses this checksum to validate it received the packet correctly, and then as the acknowledgement, sends  back the checksum bytes. The master validates the checksum bytes, and the command is believed to have been sent with integrity. This increases a single message to 5+2+2 bytes or 9 bytes total. The increase in byte count and the CRC computation now has the transmission rate down to ~85 messages per second. This is still quite adequate, but I'm hoping it doesn't drop much more as I add input / translate / command send on the master and command receive / translate / output on the slaves.  I'll leave it running over night to see a few million messages go through with no error, but at the moment, this seems completely plausible for use in a vehicle. 

May 31: The boys and I have a new project.


We have a 1968 Firebird that needs a new wiring harness. I could put in a cheap aftermarket one for $500ish, a really nice aftermarket one for $700, or the new fancy ISIS Power microcontroller-based harness for ~$1500.

I was ready to spend the money on the ISIS system when I realized that while you can buy the "programmer" it just uploads code that you get from the manufacturer. Want to change the operation of the system - you call them, ask nicely and wait for them to send you a .hex file. That is a deal-breaker for me. In the true DIY spirit, I thought - I can build that system! Fundamentally it is the same concept as the "Control Panel" we built before, it just adds the concept of networked microcontrollers to split the output circuits by location in the car.

To get started, I've purchased 3 Gator + boards from ruggedcircuits.com.

They are "hardened" arduino-compatible microcontrollers. Since there are life-safety considerations involved with this adventure I wanted to get boards that were the least likely to fail (or be damaged by me along the way!).

I've got the Arduino development environment loaded & I've uploaded my first simple program to a gator+. Over the coming weeks, the plan is to:

1) Build a reliable wired communication network (I2C?) between 3 nodes (the gator+ boards).


2) Determine the bandwidth of the network so that I can ensure I don't have a delay on a brake light activation for example.

Update - June 1: 


I built a 3 node I2C network last night using the wire library examples. I can send hundreds of short (8 byte) messages per second to both nodes. Right now the limiting factor is my serial output of the messages for debugging. This is one-way communication from one master to two slaves. 


Next I will try two way communication so that both nodes can send and receive. At a minimum I can use this capability for returning status or warning information to the master. If it worked really well, I could do data logging from all boards. 


Update - June 5: Network fully functional - see my newer post...

3) Develop a terse communication protocol and control structure between the nodes.


Update - June 3:
Design considerations floating in my head...


Does the master send "events" and the slaves respond to events OR does the master process the events and send "commands" to the slaves?


What events exist?

• External inputs:
• Ignition: On / Off
• Input: On / Off (Do I need to handle expected momentary different than expected latching to keep protocol terse? Don't need to resend stuff over & over)
• Analog Input: Value  (Will I have analog inputs for things like interior light brightness, fan temps, or am I sticking with digital?) 

• System Events:
• Warning
• Error / Problem
• Critical Failure
• Heartbeat

What are the "commands" needed? 

• Standard Outputs
• ON (Output, Max Duration)
• OFF 
• BLINK (Brightness, Rate)
  
• PWM Outputs
• FADE (Start Brightness, End Brightness, Rate) 
• PULSE (Start Brightness, End Brightness, Rate, Delay)
  
• RGB LED (Likely commands are going to separate microcontroller(s) via I2C)
• LED_ON (R, G, B)
• LED_FADE (Can get complicated...)
• LED_PULSE (Can get complicated...)
• LED_CYCLE (Color cycling...very complicated)

4) Design / construct a fused output module capable of 20+ amp loads at 12v. I haven't found an output board that fits the bill, so it looks like I will be designing one. The Parallax Digital IO board is the closest I've found, but isn't rated for enough current.


Update - June 4:
I still can't find a ganged power output board that meets my needs, and I think I want to custom design it anyway to be able to have the automotive fuse holders on the board, detect blown fuses, open circuits, overtemp on the mosfets, etc. I'll prototype everything on hand-soldered perf board, and if it works well, I may have some boards professionally made :)


MOSFET selection: I'm ordering the IRLZ44N, based on this arduino forum article. They are technically capable of 47A, but I'm thinking heat management in the TO-220 case will be the actually limiter. I think the failure testing part of the project will be FUN!


5) Build a benchtop test car with all circuits present. Benchtop testing will save LOTS of headaches later.

The boys will be learning all about the electrical system of a car including switches, relays, lamps, etc. I think they will LOVE building a working benchtop car model. I'll probably leave it intact as a testing platform and just order more gator+ boards as needed :)

Update June 4:

I will be building the test "car" using a top view of the Firebird printed on paper and glued to peg board. I have an enclosure design for the pegboard that gives me two layers of pegboard - the car picture, all indicator lights & switches will be on the top board which will be hinged to allow access to the bottom board. The bottom board will have the microcontrollers & output boards. I plan to make it run from a 12v jumpstarter style battery. I think the boys are going to LOVE building this thing and playing with it. I have it sketched out - I'll get it in diagram form to share soon.

Stay tuned!

Over the Thanksgiving holiday my son's cousins were in town, so he had little interest in working on the Control Panel with me. I changed gears and worked on the Firebird. My younger son and I took the car to the Turkey Run car show in Daytona. It was a great week...

Thanks to my buddy Lou who pulled a late night with me on the car prep, riding over with us and for taking these pics.