It sounds like somebodies tapping on the dash sometimes. lol
Printable View
It sounds like somebodies tapping on the dash sometimes. lol
Antero, got it installed, working great, except for this. Check out the link.....
http://www.3sgto.org/f2/so-many-cels-9648.html
Antero,all of a sudden my lcd has a problem,kind of strange,it was working fine then yesterday it would not connect with the key on engine running,it says connection failed,but with key on engine off it connects,i was hoping u or someone else has ran into this problem,any help would be appreciated Thanks
Sounds like the calibration could be off? I will release v2.26 firmware tomorrow, it will tell you if your calibration off, and still connect. :)Quote:
Originally Posted by dferguson
As soon as I finally start my build I will be sending mine back to you for a look see. Will PM the particulars when ready.
Which evoscan XML file is everyone using with this? In preparation for going flashed ECU I was using the chromed xml file but a number of different readings are either off, don't make sense, or almost seem to lag behind a data cell or two it seems like. I can't get a clean datalog of a pull almost like it isn't able to take enough samples per second through the lcd bc.
v2.26 update is up. If your calibration is slightly off, it will still successfully connect as MUT. Also added EvoX map sensor.
When datalogging, it's best to keep the number of datalog parameters low because the more you add the worse it gets. For example, lets say we can achieve 70 samples/sec from the ECU. If you datalog just Knock, you will have a very nice graph. But now if you datalog two parameters, Knock and RPM your sampling speed for each is 35 samples/sec. Datalog seven parameters, and now you're only getting 10 samples/sec for each. Some datalog parameters are way more important than others and we can change it's scan priority. Coolant temp and intake temp values don't generally change quickly so they can be scanned at a low priority, giving up it's spot to more important Knock and RPM parameters requests.
The LCDBC datalogs Knock, RPM, Coolant temp (low priority), and Intake temp (low priority) parameters so when Evoscan requests this info, the data is returned instantly without asking the ECU again. All other requests are interleaved in this fashion to the ECU: LCDBC request, Evoscan request, LCDBC request, Evoscan request, LCDBC request, etc. Now if you don't datalog Knock, RPM, Coolant temp, Intake temp you will see your sampling speed drop in half. If you do include these four parameters datalog speed should be decent. Next, if you datalog LCDBC's Boost and LCDBC's WBO2, the data requests are instantly returned with values because it does not have to ask the ECU, and this will bump up the overall sampling speed average. This is why I don't datalog Boost or WBO2 data through the flashECU, as it will compete against other ECU data requests and reduce individual parameter sampling speed.
Recently I discovered how much faster the 98-99 flashECU are at communicating, and the LCDBC isn't taking advantage of this because of hardware constraints. The LCDBC processor is configured to run at 8Mhz using it's internal oscillator -- this was the only way I could get it run reliably, if I used an external oscillator it would crash when it received serial communication. I looked if there was a solution to this problem on the internet yet and there finally was, the processor's documentation was wrong! Sweet, I slapped a 16Mhz crystal oscillator and it works correctly. Not only does the processor now run double the speed, it also fixed a strange hardware bug ( two simultaneous incoming serial data would corrupt each other ). With this strange hardware bug gone, I could remove delays from the code and saw a 30% increase in Evoscan sampling speed. There are also other benefits: (1) No more calibration needed, (2) Temperature is no longer influencing oscillator speed, (3) Connecting MUT will always be consistent.
Here's a picture of my external 16Mhz crystal + 2 capacitors soldered onto three pins, it doesn't look pretty, I was just excited to try this out with much success!
http://i782.photobucket.com/albums/y...talVersion.jpg
This blue circuit board will be an easy way of introducing a crystal oscillator and surface mount version of the same processor.
http://i782.photobucket.com/albums/y...tProcessor.jpg
How much would it be to upgrade an existing board? Haven't even installed mine yet. Something we could do ourselves? Seems like it for someone with soldering experience.
Sent from my Galaxy Nexus using Tapatalk 2
I've ordered the blue circuit board and expect it to arrive in 3-4 weeks and test it out. If it doesn't work, I'll have to design my own PCB board adapter and then have it manufactured (another 3-4 weeks). The black 40 pin microprocessor is socketed, and is easy to remove. It would just be a matter of popping this in its place without any soldering. I would expect cost to be around $25 for this method.
Edit: PCB board adapter version will not be available, too hard to solder.