So 60.ish to have the ability to have an SDcard logg data that EVOScan can display? Sounds like a great option.Quote:
Originally Posted by BlackStealth
Printable View
So 60.ish to have the ability to have an SDcard logg data that EVOScan can display? Sounds like a great option.Quote:
Originally Posted by BlackStealth
So 60.ish to have the ability to have an SDcard logg data that EVOScan can display? Sounds like a great option.Quote:
Originally Posted by BlackStealth
http://www.youtube.com/watch?v=ujINS...ature=youtu.beHi mate,Quote:
Originally Posted by BlackStealth
some how I missed this reply !!??
I have just checked back through the log I sent you and the battery voltage before corruption is 13.34V and the next voltage measured is 13.63V. those figures were taken when logged through the LCDBC so its not dropping out due too voltage.
I have just checked logs of the wifes and my car from BEFORE the lcdbc was fitted and it appears on WOT runs were are dropping about 0.5>1v MAX on boost with a lowest voltage reading of 12.8V's
I have run a jumper lead directly from the negative of the battery directly to the chassis the ECU bolts too and its the same, in fact I can obtain corruption while stationary just by blipping the throttle to 4K. I video'd it but youtube is being a fanny tonight so I will try upload it later.
I haven't done the longer pause update yet but will do it when I get 5 minutes !
http://www.youtube.com/watch?v=ujINS...ature=youtu.be
Cheers
Elton :)
I think the OBD chip in the boxed version i partially to blame. When I switched to that filter thing and disabled the onboard OBD chip my disconnect issues went away almost completely and the reconnect function started working for the first time.
However I still see slowdown/freezes just like Elton's video shows. Sometimes my unit goes completely unresponsive for several seconds.
http://i782.photobucket.com/albums/y...SerialData.png
MUT communication is 15625 baud, or 64 uS pulse (0.000064 seconds). The microcontroller looks at the voltage sag, and if the duration is 8 uS or longer it considers this as a start bit and accepts this as valid data, and this is where the corruption begins. Because the time interval to detect this voltage sag is incredible short, it will be undetected most of the time. Having an oscilloscope or something with high speed monitoring can only reveal this. Now if the voltage sag lasts a long time it can be detected by other tools.
From your video I could see that once the data corruption had begun, it would take approximately 2 - 2.5 seconds for the LCDBC & ECU to recover. This is because once the LCDBC received corrupt data, it will make the next ECU request not knowing the ECU has not yet replied. Think of a CB radio where only one person is allowed to speak at once -- both the LCDBC and ECU are talking simultaneously and neither can hear each other, and it takes a few moments to recover.
Did anyone get a chance to run the LCDBC off a separate power source (ie. 9v battery) ? This will determine if a ground loop is an issue with OBD2/MUT corruption.
Quote:
Originally Posted by BlackStealth
I haven't had a chance too try a totally spate battery, although I did jump an earth from my battery directly to the ECU chassis with no difference.
Today I was out setting the car up and was logging a 45 min thrash direct from Evoscan with NO corruption or drop outs etc. I will try another battery in a minute if I can.
:)
Quote:
Originally Posted by BlackStealth
Ok so today I ran the power wires to a fully charged spare car battery sitting in the foot well. ALL the faults are exactly the same with zero improvement..
I still cannot connect to Evoscan via unit unless I follow my 10 steps posted previously
I still have drop outs which wont reconnect
I still get scrambled corrupt logs on boost through evoscan if logging through the lcdbc
I still get slow frozen screens even though refresh is set too lowest point (this is a fairly new addition to my list of glitches though?)
I logged battery voltage and I am seeing less than 0.3v drop on a log.
given three separate cars of different spec are all having the exact same faults im sorry to say but its the lcdbc/cables..
Can we work towards some resolution please as I have now exhausted all tests to work out where the fault lies, all I know is it is definitely NOT with both of my cars (and unlogics)
Cheers
Elton
The reconnect issue is already fixed with v3.11 software.
Any feedback from the software I provided with the variable delays? When you add in delays, this will give your ECU more time to respond to LCDBC requests. It could be that when your ECU gets more busy (higher RPMs) it needs the delays before any new requests are made.
I'm still waiting for the PCB boards I ordered from china to arrive to so I can compare the USB OBD2/MUT cable to the serial resistor/transistor OBD2/MUT cable, this usually takes 2-3 weeks to ship. If necessary I will copy the USB OBD2/MUT cable design because you said it works better. If anyone can find a better serial OBD2/MUT cable, the LCDBC will accept it.
The screen will appear frozen when the LCDBC does not receive data from the ECU, this is the same issue. RPM and knock are given a 0 value when no response came back from the ECU, I will change this to keep the previous value if no response is given to keep it consistent.
Here's a pic of the USB OBD2/MUT cable I have. Can you tell me if this is the same USB OBD2/MUT cable insides as yours?
The center chip LM339 does the magic in interfacing with the OBD2/MUT bus. The bottom FTDI chip converts serial data into USB virtual serial port, so we can ignore that.
http://i782.photobucket.com/albums/y...UTcable002.jpg
No interest in my #1058 post from three weeks ago :dontknow:
Quote:
Originally Posted by Jimvr4