Replacing the dash cluster with a lcd screen

[csxtra]

<thread hijack>

An update: I got the Netduino microcontroller to successfully communicate with the Logic module. I ended up getting an oscilloscope (always wanted one, just never had justification to pull the trigger). Anyway, I must have been juggling too many variables and couldn't figure it out without seeing it visually.

The end result is that the simplest approach worked. All I had to do was use two gates of a SN74LS04 to invert both the send and receive lines between the Logic Module's Diagnostic connector and the Netduino UART. It turns out that the Netduino can handle a 5V input signal with no issues, the 74LS04 will work with the 3.3v output signal from the Netduino UART, and the LM will handle the output of the 74LS04. Not sure why I had such a problem before, but it is definitely working now.

Out of the Netduino UART transmit pin, idle and zero bits are high (3.3v), and 1 bits are low (0v). I looked at the output from my working RS232 adapter and it was opposite with idle and zero bits as low (0v), and 1 bits as high (5v). Running each of the signals through one of the gates of the inverter switched things around and made the Netduino signal the same as the RS232 adapter (although the peak voltages are different) and it started working.

I hope this helps someone else in the future.

</thread hijack>

[acannell]

<thread hijack>

An update: I got the Netduino microcontroller to successfully communicate with the Logic module. I ended up getting an oscilloscope (always wanted one, just never had justification to pull the trigger). Anyway, I must have been juggling too many variables and couldn't figure it out without seeing it visually.

The end result is that the simplest approach worked. All I had to do was use two gates of a SN74LS04 to invert both the send and receive lines between the Logic Module's Diagnostic connector and the Netduino UART. It turns out that the Netduino can handle a 5V input signal with no issues, the 74LS04 will work with the 3.3v output signal from the Netduino UART, and the LM will handle the output of the 74LS04. Not sure why I had such a problem before, but it is definitely working now.

Out of the Netduino UART transmit pin, idle and zero bits are high (3.3v), and 1 bits are low (0v). I looked at the output from my working RS232 adapter and it was opposite with idle and zero bits as low (0v), and 1 bits as high (5v). Running each of the signals through one of the gates of the inverter switched things around and made the Netduino signal the same as the RS232 adapter (although the peak voltages are different) and it started working.

I hope this helps someone else in the future.

</thread hijack>

weee!!

now if you can poll the ECU for some live sensor data and then display that data live on an LCD screen, you'll have joined a very small club of people who have done so! post a pic if you do!


and post up the schematic so other arduino junkies can follow your lead!! and the source code lol

[iangoround]

weee!!

now if you can poll the ECU for some live sensor data and then display that data live on an LCD screen, you'll have joined a very small club of people who have done so! post a pic if you do!


and post up the schematic so other arduino junkies can follow your lead!! and the source code lol

Yeah, I'd love to see a schematic and source code. My car is finally back in my garage after 2 years so I can actually work on it and this is something I'd love to do.

[csxtra]

Well, actually, I'm not using an LCD screen, this is my 5th generation Logic Module data logger, the first gen ran on a Palm Pilot and I first had it working at SDAC 16. The second gen was a PC-based logger (LM -> RS232 adapter -> Laptop). Gen 3 replaced the laptop with a netbook and used wifi to talk to a remote Android display. This worked fine, but I wanted something that was always in the car and didn't require hooking up cables and powering a laptop.

Gen 4 was a Netduino using Ethernet to talk to the android remote display (not reliable due to firmware issues on the older Netduinos), and finally Gen 5 is a Netduino with a Bluetooth transmitter on it and either a windows-based logger running on a netbook, an Android remote display, or both (the Android daisy-chained off of the netbook running the windows logger).

I used the Netduino over the arduino because it runs the Microsoft .Net Micro Framework which allows programming in C# .Net, which I already knew, and it contains 3 UARTs. I'm sure this could be made to run on an arduino instead, but the code would be completely different.

Here is the schematic showing just the SCI to SN74LS04 to Netduino connections:



And I just figured out tonight why I couldn't get it to work during my testing: For some reason the Netduino didn't communicate reliably when powered by the USB input needed to flash and debug your code. If I power it through the power socket or Vin pins and then connect the USB cable, it communicates successfully.

[wowzer]

warren - how do you handle the LM baud rates?

[acannell]

Well, actually, I'm not using an LCD screen, this is my 5th generation Logic Module data logger, the first gen ran on a Palm Pilot and I first had it working at SDAC 16. The second gen was a PC-based logger (LM -> RS232 adapter -> Laptop). Gen 3 replaced the laptop with a netbook and used wifi to talk to a remote Android display. This worked fine, but I wanted something that was always in the car and didn't require hooking up cables and powering a laptop.

Gen 4 was a Netduino using Ethernet to talk to the android remote display (not reliable due to firmware issues on the older Netduinos), and finally Gen 5 is a Netduino with a Bluetooth transmitter on it and either a windows-based logger running on a netbook, an Android remote display, or both (the Android daisy-chained off of the netbook running the windows logger).

I used the Netduino over the arduino because it runs the Microsoft .Net Micro Framework which allows programming in C# .Net, which I already knew, and it contains 3 UARTs. I'm sure this could be made to run on an arduino instead, but the code would be completely different.

Here is the schematic showing just the SCI to SN74LS04 to Netduino connections:



And I just figured out tonight why I couldn't get it to work during my testing: For some reason the Netduino didn't communicate reliably when powered by the USB input needed to flash and debug your code. If I power it through the power socket or Vin pins and then connect the USB cable, it communicates successfully.

palm pilots!! do you still have that setup somewhere?

[ShelGame]

I had a PalmPilot (intermittently) logging using a RS232 serial converter with a logic inverter, much like yours Warren. Do a search for 'MiniDash' if you want to read about it. I probably still have some of the files...

[csxtra]

palm pilots!! do you still have that setup somewhere?

The Palm Pilot setup takes me down memory lane...I'm not sure if I still have a machine with the source code still on it, I know that I wrote it up in HB++. The Palm Pilot I used to have was a Tungsten T3, which had a larger screen and Bluetooth. I used a serial cable to connect to my SCI to RS232 adapter to communicate to the Logic Module, and a Serial to Bluetooth adapter connected to my LM-1 and LMA-3 Auxbox.

The app on the palm pilot handled the LM communications (check for low-speed, send 0x12 to switch to high-speed, then start requesting points) over the serial connection, and used Bluetooth to receive the Innovate WB and sensor data stream. The data was displayed on the screen, and when WOT was detected, it logged the LM and Wideband data to an HTML table file on an SD card, and I used the browser to view the log files.

warren - how do you handle the LM baud rates?

Morris, here is a simplified overview of the state machine I'm using for initializing communications with the LM:

NOTE: The Comm port is open in high speed mode (7680 baud) at all times except when sending 0x12 bytes to signal the LM to switch from low-speed mode (976 baud) to high speed mode.

1. Open the comm port in high speed mode (7680 baud), set a timer and set state to LowSpeedCheck.
2. Regardless of state, when bytes are received on the serial port, save the contents of the buffer and keep track of how many bytes have been received during the time period, then zero the count after checking for the next time interval.
3. Regardless of state, if no bytes are received during the timer period, assume communication has been lost, close and reopen the port in high-speed mode and go back to LowSpeedCheck state.
4. LowSpeedCheck state:

a. If the LM is in low-speed mode (976 baud), it will be sending a stream of 0x12 bytes. I figured out that a stream of 0x12 bytes sent at 976 baud looks like a stream of 0x80 0x00 pairs when received at 7680 baud, so I always receive at 7680 baud - this simplified the code and made it more reliable when reconnecting after restarting the car or toggling the ignition.

b. If I see a stream of 0x80 0x00 pairs the LM is in low speed mode. Close the comm port, reopen in low-speed mode (976 baud), send three 0x12 bytes, and close and reopen the comm port in high-speed mode (7680 baud).

c. If no 0x80 0x0 pairs, send three 0x12 bytes in high-speed mode, which will cause the LM to send a string of 0x12 bytes.

d. If I see a stream of 0x12 bytes, I know for sure the LM is in high-speed mode and ready to take points requests, go to Connected state

5. Connected state:

a. Go down the list of data point addresses, sending the data point address, throwing away the first byte received after sending the request, and saving the second byte received as the value to convert for display/logging.
This is where I am having some intermittent bogus data returned due to a timing problem. Sometimes the second byte received may still be for the previous point instead of the point I just requested.
I tried using the OTC scanner approach which sends the address, receives the first byte, sends the address again, then uses the first byte received after sending the second request as the value of the data point. When I made my code work that way, accuracy improved, but it still occasionally gets the bogus previous value.
I could to a third request/receive cycle, but it would slow down the number of frames I can process per second.

b. When all points in a frame have been requested, scale the points in the frame and display or log them.

c. Lather, rinse, repeat.

[wowzer]

warren - was that a mistype when you indicated high speed mode of 7680? did you mean 7812? either way, i gather that the netduino natively supports those rates?

[csxtra]

warren - was that a mistype when you indicated high speed mode of 7680? did you mean 7812? either way, i gather that the netduino natively supports those rates?

No, I'm pretty sure that 7680 is the baud rate I have used since the first Palm Pilot app years ago. Is 7812 the true baud rate for a Logic Module, or is there a difference between the LM and the other ECUs (SMEC/SBEC)? Now you have me wondering.

I haven't seen anything that says it doesn't natively support odd baud rates, and it appears to work about as well as my old PC-based Windows Forms version did. But that isn't to say that there may not be some hidden issue that I've overlooked.

[wowzer]

warren - the baud rates are typically the clock rate divided by some power of 2. i think the max baud rate of an LM with a 1 mhtz clock and the available scalers is 62500 (1000000 / 16) and the high baud is set at 7812.5 (1000000 / 128) and the low baud is 976 (1000000 / 1024). for the smec with a 2 mhtz clock and using the chip prescalers the max baud rate is 125000 (2000000/16), with the default low baud at 125000 / 16 (7812.5) and the high baud is 125000 / 2 (62500).

i don't have a lm ecu to test so i don't know if the 62500 baud rate is doable. in theory you could change the lm code to use different scalers so the low and high baud rates would be the same as the smec.


****edit*****

fyi - the LM scaler byte value for the clock divider is:

0 = / 16
1 = / 128
2 = / 1024
3 = / 4096

basically it is telling the chip how many e-cycles are used per bit

[wowzer]

...
I used the Netduino over the arduino because it runs the Microsoft .Net Micro Framework which allows programming in C# .Net, which I already knew, and it contains 3 UARTs. I'm sure this could be made to run on an arduino instead, but the code would be completely different.

Here is the schematic showing just the SCI to SN74LS04 to Netduino connections:



And I just figured out tonight why I couldn't get it to work during my testing: For some reason the Netduino didn't communicate reliably when powered by the USB input needed to flash and debug your code. If I power it through the power socket or Vin pins and then connect the USB cable, it communicates successfully.

i'm gonna get me a setup like this and see if there is a reasonable way to integrate the ecu scanning and some a2d inputs. thanks for the info.

[moparman76_69]

$9 dollar 1 Ghz SBC with 512 MB of DDR3 and 4GB of onboard flash memory? Yes please. Available HDMI out? Uh huh.

http://nextthing.co/

http://www.zdnet.com/article/the-9-d...at-do-you-get/

[BIGBRUDDA]

asa,

what is required to get a microcontroller to talk to the sci bus? I've got a logging project i'm working on and i haven't yet been successful getting the mcu (actually a netduino) to talk to the sci without using an ancient sci to rs-232 converter then a rs-232 to ttl converter.

It works fine with the rs-232 in the middle, but i'd like to figure out how to eliminate the extra hardware and use a more direct connection between the netduino and my logic module.

Thanks in advance for any help you can give.

sounds like the flux capacitor warren ....................or the dilithium chrystals.

[boost geek]

hey JAMES we might have to give LEONARD a call HE can build anything