My LCD screen project, boost, WBO2, Knock, etc

[CoopKill]

Just got a plx one...

[BlackStealth]

That video uses the 4dsystems graphics screens, here are their prices.

TFT 4.3" screen $99
4D Systems | Turning Technology into Art

OLED 3.2" screen $189
4D Systems | Turning Technology into Art

OLED 1.7" screen $65
4D Systems | Turning Technology into Art

To display graphics on those screens, they require a separate SD Card to store images, as you cannot transmit images from your microprocessor. Only simple graphic and text commands are sent from the micro, because of the slow communication speed (115200 baud) of the graphic screen. Graphic images are called by name and the graphic screen looks at the SD card for it and displays it. Performing software updates would be more challenging because data is stored in two different places. To make use of those screens, you need to purchase additional hardware, a programming adapter. They charge $91 for the OLED 1.7" screen with programming adapter and 2GB SD card. Shipping from Australia is about $18. For me to take delivery in Canada, I would see $35-$60 extras in brokerage fees, 13% taxes, and COD charges for collecting taxes. I did purchase one of their screens about 3 years ago when I was evaluating it and concluded it was too expensive. Very fast screen because of the built-in graphics chip.

Both the raspberry pi and beagleboard black would fail once temperatures reached 0C and below.

Graphic screens require a lot of the microprocessor. Lets take a 1.8" TFT screen for example, with a resolution of 160x128, it has 20,480 pixels. It's about 20,000 times more burden some than an alphanumeric lcd screen. Get a graphic screen that has more resolution, and the problem only gets worse. I spent a couple months interfacing the 1.8" TFT screen onto the LCDBC and concluded the microprocessor needs more muscle if it were to do anything fancy. It could only achieve about 7 frames per seconds, do able but not impressive.

I purchased and evaluated other microprocessors. Spent couple months learning other microprocessors, and came to a dead end on some of them. The graphic speed improvements weren't all that great by the time I got the TFT screen working on them, and their costs were about 4-8 times higher.

I did however find a microprocessor that produced about 14 frames per second, and the cost was $2 cheaper. I have successfully ported over the LCDBC software on it. There are no built in fonts, so I spent a lot time evaluating font editing programs for microcontrollers and found one that kinda did what I wanted. Made my own large size font, and looked at ways of making the font more appealing to the eye.

The 1.8" TFT screen original purpose was to fit it inside of a gauge, but here I am experimenting with it inside the air vent.

[Streamln1]

Hey if you can make one work with the 3.2" screen, I really don't care what the cost is, I want it. I live in AZ so I am never going to see even close to 0* C

[Unlogic]

The LCDBC setup in my car is finally working as it should. After several months of trial and error I bought a flash ECU and as previously reported by other members that solved the problem.

As soon as I installed my flash ECU and removed the various filters I've tested everything worked smoothly even at high RPM's and the refresh rate is much quicker now.

My verdict is that the LCDBC is incompatible with some of the older, slower ECU's. I suspect that the reason why the LCDBC has problems communicating with these ECU's is due to the fact that it doesn't use hardware interrupts for it's serial communication with the ECU. As the revs increase the slower ECU's take longer time to respond and than in turn causes the communication with the LCDBC to go out of sync.

I even bought an EvoScan license today and tested it using the LCDBC's pass through mode and a FTDI-based USB serial cable. It worked flawlessly and logged just fine, here is a screenshot:



The original ECU in my car was a MD325528, if your car has the same ECU consider it incompatible with the LCDBC until Antero comes up with a fix.

[ukyo]

What year model was your original ECU? Just curious if this issue is with the hybrid ECUs and possibly older.

[Unlogic]

It was a 1996 eurospec ECU.

[TurboSinceBirth]

I'll have to try and swap the flashed ecu in for my 95 to see if it solves the issue once I get my car on the road again.

[BlackStealth]

The LCDBC microcontroller has a built in hardware serial device, so when a serial byte arrives it is stored in a 1-byte register buffer. This is done independently of the microprocessor when it is busy doing other tasks. An interrupt can be generated to notify the microprocessor that a serial byte is ready to be read, or it can just wait there until the microprocessor is ready to read it.

Interrupt serial:
-Good for multiple bytes of incoming data, so you don't overrun the single byte hardware buffer.
-Extra overhead in terms of CPU cycles

Polling based serial:
-Good for single byte of incoming data
-Zero overhead

Originally the LCDBC software did use interrupt based serial communication, but this offered no advantage because our ECU only replies back a single byte, and never says anything more until we ask it again. This means there is no advantage to using interrupt over polling method. I switched to a polling method a while back when I optimized it.

So I'm sure someone is going to ask me next, "What about 2-byte Load then?". To ask for the results of the 2-byte Load, you have to ask it twice. One asks the ECU for the high-byte, waits for a reply, and then asks for the low-byte, and waits for a reply. So as you see, it still functions like all other 1-byte requests, and 1-byte replies.

Generally a 94-95 ECUs take 11ms - 12ms to respond to an ECU request, and 98-99 ECU is about 3ms - 5ms. I've chosen a 20 ms as a timeout value, so if the ECU has not replied back within that time frame, it is not going to respond. Unlogic has theorized that as the RPMs has increased on the ECU it needs more time. This can be easily proven by increasing the 20 ms timeout value.

Facts:

(1) High RPMs or high engine loads triggers the noise problem.
(2) While the LCDBC waits for a reply from the ECU, the longer the wait the greater the chance noise will show up.
(3) To reduce this wait from the ECU and therefore minimize noise also, a delay of 10ms or so is added. Apparently if 10ms of time has passed since the last request, the ECU will respond almost immediately, whereas if the ECU is constantly responding to requests it adds a long delay before it replies, and this long delay gives the chance of noise appearing and being interpreted as the reply.
(4) Someone had a 94/95 generation ECU with zero problems, and swapped to a 98/99 flash ECU and they had noise problems.
(5) Unlogic had 96 ECU with noise problems and swapped to a 98/99 flash ECU and the problems went away.

So it is true that changing ECUs can fix the noise problem. I am just curious to know which electronic component in the ECU is the problem. With age, capacitors are known to get weaker.

[Jimvr4]

I could be completely wrong about this but I don't think 94/95 ECUs have the same response characteristics as 96 ECUs. 94/95 cars are sort of OBD 1.5 - they use the OBD2 connector but don't talk OBD2. 96 cars were the first ones to support OBD2 however I *think* OBD2 support was done at a software emulation level, not hardware and therefore response to a request was significantly slower. The later ECUs respond much faster because OBD2 is implemented in hardware.

I do know that 96 ECUs will not communicate with Evoscan v2.6 although they would with v2.5 or v2.7. When communicating over a 1.3 cable with v2.7 the 95 ECU responds MUCH fast than the 96 ECU.

It may be the 20ms timeout is not sufficient for the 96 ECUs.

[BlackStealth]

The reason OBD2 sucks is because it uses several bytes of header information, and each byte has to be separated by a 5ms delay or longer. And before you can ask the ECU anything, a 55ms of delay must occur before you're allowed to ask again. The reply is painfully slow also, it takes 25ms-50ms before the first reply byte is received, and each byte thereafter can take between 0-20ms. The reply also comes back with many bytes of useless header information also. This is essentially why OBD2 is about 10 times slower than OBD1.

Some ECU manufactures will bend the OBD2 rules a bit, meaning you don't have to separate each byte by 5ms delay, or have a 55ms delay before each new request, this results in an increase in performance.

An OBD2 reply can be as long as 11 bytes, so if a low end ECU introduces a lot of inter-byte delay there can be big performance difference between two OBD2 ECUs.

I bet our 1996/1997 ECU is very strict on the OBD2 required timings, and is not forgiving if it is slightly off. This is perhaps where Evoscan v2.6 went wrong.