Public release, March 29, 2012

[Blacky]

Anyway they are working again now but it was a WTF is going on moment for a while. (I even have a log from a car where lambda is changing but afr is at 0 jumping up to 25, 6 etc)

In one of the RC versions we added the option to specify a stoich value that is used to convert from Lambda (i.e. the value from the WO2) into AFR. It had a bug that caused the stoichiometric value to default to 0 instead of 14.7 IT was corrected in a later firmware version.

You should check that the stoich value is set correctly in the settings for FlashScan for the fuel you are using - as shown below:



If it is/was set to 0 (i.e. has never been set by you) it will now correctly default to, and show up in the settings, as to 14.7 instead of 0.

Regards
Paul

[minytrker]

I'd guess that if you disconnect the FlashScan device, it should boot up without blue screening.
Can you confirm that when the laptop was failing to boot after the blue screen that the FlashScan was still connected?

Regards
Paul

I always unplug the V2 if the laptop crashes, and I never boot up the laptop with anything plugged in. I always wait until the laptop is done booting up before plugging in the v2 or anything else.

[bobo]

Bobo, sorry but I was wrong, the Van OS does not support DSP5 (or DSP2). The Van's OS had different table structures to the trucks, yet it retained the same OS number, I'll try to explain the issue.
The problem with that was a couple of the DSP tables in the trucks (just as examples) may have been defined as say 17 x 17 in size, the van OS for the same table used 14 x 17, or 14 x 14, something along those lines. So we couldn't put the DSP tables in the Vans OS because they didn't match in size. This would not have been a problem IF GM had given the Van a different OS number, but they didn't, it's the same as the trucks and so we could not distinguish what maps would need to be used when the DSP upgrade patch was done, truck style or van style. Sorry Bobo.

There is some way to distinguish between a van and a truck. The van os says no DSP 5 upgrade available and the same os in a truck config allows a dsp5 upgrade.

When a dsp5 upgrade is done, the operating system is changed. Why can't the van dsp5 os be different than the truck dsp5 os even if they originate from the same stock os?

[GMPX]

Bobo, it's subtle but the .calz file number isn't the same. I remember back when we first saw this problem and couldn't believe Bosch would designate the same OS number to tunes that are different. I had (and still haven't) ever seen any other GM controller do this.
In the end we had to look for specific markers in the file to know that we had to load an alternate .calz file that showed the right tables to match the Van.
Notice how the OS number is 12632483, but the .calz file we load is called 12632484.



Unfortunately though V7.5 still see's both files as 12632483, so we can't Upgrade the OS to DSP to match the Van because the patch can't pick the difference between them.
There is also an LMM OS we don't do DSP for, 12620015, this is used on Motorhomes and the 5500's.

[Laychut]

Hi,
I have tried to down load the latest V8 software, but the link seems to be down. I have tried on two different computers.

Cheers,
Laychut

[joecar]

Try downloading builds 201 and 192 from here: EFILive downloads page

[Blacky]

FWIW Dept...
I have 4 FTDI devices and 2 programmable FTDI devices to control my radio equipment.
After installing the newest FTDI device drivers from FTDI,
and then installing the EFILive software, the computer would blue screen over and over.
If I completly removed all of the FTDI device drivers, and only install the EFILive drivers, everything would work just fine,
If I completly removed all of the FTDI device drivers, and only install the FTDI device drivers from FTDI, everything would work just fine,
So it seems that the EFILive drivers are not compatable with FTDI's.
My solution was to install EFILive on a different laptop.

The EFILive drivers are FTDI's drivers. They are digitally signed by Microsoft and certified to be identical to FTDI's drivers. In fact FTDI supplied the drivers to EFILive that we get digitally signed by Microsoft under our own name. EFILive does not make any modifications to the drivers -we are not allowed to or Microsoft will not and cannot sign them. We just package them and have them re-signed under our own name.

Regardless, I think the problem is a conflict between the old and new drivers supplied by FTDI. EFILive V7.5 must use the older drivers, EFILive V8 can use the older or newer drivers. However, if you have other devices that use the newer drivers and you install the older drivers (for V7.5) then the FTDI driver set gets messed up. I've tried contacting FTDI support about it but they are not much help, they just tell me to upgrade the drivers to the newer ones. That's understandable from their point of view, but that breaks the V7.5 software.

In other news, once EFILive V7.5 is retired and V8 takes over the scanning and tuning duties then the old/new driver conflict will no longer be a problem.

Regards
Paul

[bobo]

Is there a way to make v7.5 default to check the try alt keys and use high speed boxes when tuning. Also default V8 to check try alt keys, assume lock is faulty, and use high speed. I think it might be a good idea to move those check boxes to a settings button and only make it show up if a flash fails kind of like the vin unlock button shows up after a failed flash. I guess what I'm getting at, is why would you not use try alt keys and why is the check box there? I have my customers check it all the time on the diesel stuff. Some new customers get confused or forget/accidentally uncheck it. It's not a big deal, but having software that defaults to the most common settings when it is first downloaded would make it easier to use for a new customer.

[bobo]

If v7.5 can't tell the difference, can I get a separate tab that can make a dsp5 van os?

Bobo, it's subtle but the .calz file number isn't the same. I remember back when we first saw this problem and couldn't believe Bosch would designate the same OS number to tunes that are different. I had (and still haven't) ever seen any other GM controller do this.
In the end we had to look for specific markers in the file to know that we had to load an alternate .calz file that showed the right tables to match the Van.
Notice how the OS number is 12632483, but the .calz file we load is called 12632484.



Unfortunately though V7.5 still see's both files as 12632483, so we can't Upgrade the OS to DSP to match the Van because the patch can't pick the difference between them.
There is also an LMM OS we don't do DSP for, 12620015, this is used on Motorhomes and the 5500's.

Right now it gives a dsp2 and a dsp5 option, how about a dsp5-van option?

[Blacky]

Is there a way to make v7.5 default to check the try alt keys and use high speed boxes when tuning. Also default V8 to check try alt keys, assume lock is faulty, and use high speed. I think it might be a good idea to move those check boxes to a settings button and only make it show up if a flash fails kind of like the vin unlock button shows up after a failed flash. I guess what I'm getting at, is why would you not use try alt keys and why is the check box there? I have my customers check it all the time on the diesel stuff. Some new customers get confused or forget/accidentally uncheck it. It's not a big deal, but having software that defaults to the most common settings when it is first downloaded would make it easier to use for a new customer.

Hi Bob,

If your customers cannot read/flash their controllers without using the alt keys or assume lock is faulty options, then you should be telling your customers to use the unlock option to set up a standard GM seed/key in their controller. That way in future they won't need to select that option.

As for the factory default settings for those settings, t takes 10 seconds per failed key to unlock an ECM. Trying the alternate keys can slow down the process by as much as 30-50 seconds for stock controllers. The alt keys and "assume lock is faulty" are for the very small number of ECMs that have had their locking systems messed up somehow. The vast majority of controllers can be unlocked without using those options.

I might be missing something on the "use high speed" option, but are you saying that your customers cannot read/flash their controller unless the "use high speed" option is off? In that case it is most likely a rogue module that is not switching to high speed. In that case pulling the module's fuse would help. Using low speed mode is 4 times slower, so I guess its a trade off between how long it takes to pull/replace a fuse compared to how much longer it takes to read/flash in low speed mode.

Regards
Paul