My personal version of an expansion board

[TBI_Master]

Just finished building a little expansion board.

I used an AVR ATmega128
Two DB9 connectors one male, one female
one MAX232
one DB25 to connect power and I/O signals.

The board is connected in the middle of the serial cable between the laptop and the MegaSquirtII. Female DB9 conn to Laptop, Male DB9 to the MS

The ATmega128 has 2 USART ports, USART0 reads the data from the laptop and is always sending the received byte to the MS throught the USART1, and whatever is received in USART1 is sent back to the laptop thru USART0, but at the same time it is "analyzing" what is being received in both ways. Everything is interrupt based, so there are no delays and TS connects perfectly. The processor clock is 18.432 MHz.

The ATmega128 has 8 A/D inputs and a lot of digital I/O and other built-in communication features... to log the data in a SD card for example (next).

For now, I am using it to add the VSS signal to my dash in TunerStudio. My car has a "speed pulser" which generates 1.25Hz/MPH so a timer is "counting" the frequency of the pulser, the laptop-side-receiving interruption is waiting for an 'A', and the MS-side-receiving interruption is waiting for an specific byte number after 'A' received, then my software replaces such byte with the pulser's frequency (vehicle speed).

I selected the gpioadc0-7 bytes to be replaced since I am not using those ones in my application and they are always zero in my datalogs. Now, gpioadc0 is my car speed, gpioadc1 is my fuel level, and I turn on and off my low level warning light through one of the I/o ports of my expansion board.

Just wanted to share how nice little things can be done once we have a MS in the car.

[TBI_Master]

You might say "those 3 things can be done w/o expansion board" and you will be right. What I have completed is just the beginning, the SD card datalog is something that has no question about, but I plan to add things that we can't currently do, like store trips data in eeprom, oil change reminder, miles to empty, and any other features the modern cars have. I have previously installed all types of displays in my car, from text-only to graphic Displays, I even have an HUD so as soon as I complete the SD card datalog I will get rid of the laptop.

[smokeysevin]

Sounds cool.

Sean

[TBI_Master]

The first hardware improvement are the noise filters to the 12V line and after the 5V regulator, I noticed the ATmega128 got reset several times during my test trip this morning, due to the harsh electrical environment of a running car.

Another improvement is to add an odometer that keeps the total miles independently of the on/off cycles of the car and tunerStudio. One option would be to add a big capacitor to keep the power to the 128 for a few seconds after ignition is turned off, to give it some time to write to the eeprom after ignition removed. Any thoughts about it?

I finished my routines to write and read from the SD card (well, I just adapted some code found in the net), but now I am deciding what format to use. I guess I will use simple CSV since I know nothing about FRD format... unless somebody here is willing to teach me the basics, Please?

[devojet]

Re the odometer, I wrote odometer code for my LCDash. It uses an AVR controller and stores the odometer in an external eeprom using an "O Buffer". Do a google search for Atmels Application note Appnote2526.pdf, which describes how an "O Buffer" can be used to extened the write life of eeprom.

Cheers

Daniel.

[TBI_Master]

Thanks Daniel, Do you have an example of a .frd file you can upload for me?

[devojet]

PM me your email address.

[TBI_Master]

My expansion board is working pretty good, I have even made difference reports and wrote to the controller through my board with no issues.
There is no need for circular buffers when using interruptions for the USART.

[TBI_Master]

Re the odometer, I wrote odometer code for my LCDash. It uses an AVR controller and stores the odometer in an external eeprom using an "O Buffer". Do a google search for Atmels Application note Appnote2526.pdf, which describes how an "O Buffer" can be used to extened the write life of eeprom.

Cheers

Daniel.

How often do you write the data to the eeprom? I guess everytime the car stops, but how about longer non-city drives?

[devojet]

I write the odometer to the eeprom every kilometer or Mile depending on what units you are using. My O buffer is very large as I am using an external eeprom chip dedicated to the o Buffer. I would have to do over 330,000,000klm's before I get anywhere near the write cycle life of th eeprom.

[TBI_Master]

I am writing to the eeprom every 1 mile too plus everytime the car comes to a stop, and I'm replacing only those bytes that changed from the last eeprom write.
Didn't follow exactly the o-buffer concept, but my upper value of the odometer is the pointer to the location of the lower part. So i will be writing 1000 times into the same location and move to the next when I have reached 2000 miles, and move again in the mile 3000. With this, my EEprom endurance is for 100 million miles.

[devojet]

That is simular to an O buffer except the O buffer you write to a new location every time you write to EEPROM until you reach the end of the buffer. Then you go back to the start of the buffer again.

[TBI_Master]

The digital odometer is ready and also added a trip meter that don't get reset with the vehicle's power cycles.
When a push button in my expansion board case is pressed and held for 5 seconds, the current odometer value is stored in EEprom.
Both values, the odometer and the one stored with the button are inserted into the RS232 stream in place of the gpioadc bytes.
Then an output channel in a custom.ini is created to subtract the saved trip value from the current odometer to get the trip miles since the button was pressed.
Having a lot of fun with this little toy!

[Huey]

Interesting project. Care to share more

Huey

[TBI_Master]

Interesting project. Care to share more

Huey

Sure! but I warn you that my project is a first grader, compared with yours.

This is how the PCB will look like after I added the filters, right now the PCB I have installed in the car has some reworks I made to filter the 12V line
The size is kind of big because everything is through hole & single sided, excepting atmega.

I made the PCB myself using the toner transfer technique. In order to update the firmware I use a SPI programmer and edit the C source code in Atmel Studio.

mypcb.JPG

[Wergilius]

Hi,

You can read about the FRD format here:
http://www.efianalytics.com/TunerStudio ... talog.html

I guess you know about the A cmd and so on.

[aarc240]

Use the uP itself to hold an alternate power source on for a short time at shutdown to allow writing to the EEPROM. Beats trying to use a capacitor.
One i/o IN is needed to sense power status and an i/o OUT to control a small SPST relay.
Board power is sourced from switched ignition through a blocking diode, relay contact 1 is sourced from battery, relay contact 2 connects to board power in (K side of diode).
Firmware does the rest by switching the relay on at start up. It continues to hold it on while ignition is on and then for a predetermined time, or until a code segment (such as EEPROM write) completes, after the code detects a loss of ignition source on the 'power status' input. It then switches the i/o OUT off thus turning off the relay (and therefore the alternate supply).
It is possible to save the i/o IN by using a capacitor to drive the relay on at power down but that gets a bit hoky when trying to hold the relay up with an i/o OUT before the pulse from the cap disappears.
The blocking diode is essential, otherwise that poor little relay tries supplying ignition and all the rest on ignition switch off - either no shut down occurs or the relay fries.
The power status IN must pick up from the ignition switch side of the diode (A side) so it doesn't see the alternate source.

So, some code, two i/o pins, a small relay and a couple of diodes (you were going to use a flyback diode across the relay coil, weren't you?).