BBL Delay Issues

[swingtan]

Hi Guys,

I have a question regarding the use of the V2 for BBL. As you know, I use BBL a lot. Actually I use it almost exclusively now as it's so much easier to log a trip when I don't have to take the laptop out. However, there has been one thing that has always bugged me about it.

If you reset the V2 ( soft or hard reset ), which includes just plugging it in for the first time, then selecting PIDs and starting the log happens quite quickly. After that however, the V2 seems to hang when starting new logs and can take 30 or more seconds to actually start the logging process. Giving it a soft reset returns it to "speedy" operation, which is not too bad as I think a recent update resulted in the current date / time surviving a soft reboot. But it just seems strange that it hangs after the first log.

Is this known about and is there a known reason for it?

Simon.

[Blacky]

Are you logging to internal memory or an SD card?
Either way, try re-formatting the file system (SD card or internal memory) and see if that helps. Reformatting would be more likely to help on the internal memory not on an SD card, since an SD cacrd is specifically designed for FAT32 file systems, the internal memory is not.

Also, can you reproduce the problem in the following manner:
1. Cause FlashScan to start logging the speedy way (for only a second or two)
2. Then cause FlashScan to start logging with the delay - only let it log for a second or two.
3. Then save the trace file: F2 Scan Tool->F3 Scan Options->F1 Save Trace file.

Copy the trace file from FlashScan to your PC using EFILive Explorer and email it to me with a link to this thread. (paul@efilive.com)

Regards
Paul

[Tre-Cool]

I noticed this issue yesterday on the way home myself. first time starting logging was quick. when i went to start logging the 2nd time it took a good 20 or so seconds before it had created the log file ,then started showign all the logging parameters.

I log to SD card.

[swingtan]

As with Tre-Cool, I'm logging to the SD card. I've reformatted a couple of times and it's had no effect in the past. I also remove the card regularly to download data via a card reader, so the filesystem is OK. I'll document the whole process this afternoon and give you a step by step description of it, but I get the feeling it is storage related. Perhaps the V2 saves the file offset details between logging events and then tries to find the file end again. Anyway, I'll save the trace files and send them as well.

Simon

[swingtan]

OK, here's the details....

I logged on the tip home today, about 15 min worth. When I got home I closed the current log and then go out the stop watch ( Nokia N95 with a stopwatch application ) and timed a few logs.


No Reboot, New Log:


Hit "Start" 00.00
Please Wait 16.42
Creating Log File 34.23
Starting Scanner 34.75
Logging starts


Soft Reboot, New Log:


Hit "Start" 00.00
Please Wait 00.00 ( may flash up but basically it skips this screen )
Creating Log File 19.43
Starting Scanner 20.01
Logging starts


Hard Reboot, New Log:


Hit "Start" 00.00
Please Wait 00.00 ( may flash up but basically it skips this screen )
Creating Log File 19.37
Starting Scanner 20.11
Logging starts


Formated SD card and Soft Reboot, New Log:


Hit "Start" 00.00
Please Wait 00.00 ( may flash up but basically it skips this screen )
Creating Log File 07.91
Starting Scanner 08.63
Logging starts


Formated SD card and Soft Reboot, 2nd Log:


Hit "Start" 00.00
Please Wait 16.20
Creating Log File 22.40
Starting Scanner 22.81
Logging starts



So I've already learnt that having over 100 logs on the SD card slows the "Creating Log" step down significantly, so I'll be keeping that low from now on. However you can see that any time you log after a reboot, it's much faster than subsequent logs. The logs after the first one seem to hang on the "Please Wait" step.

Simon.

PS: I hope I got the names right on the log files. We had another earthquake just as I was organising all the data and it distracted me a tad...

[gmh308]

Any further feedback on this delay?

Am latest FW etc., first log always starts up pretty quickly, subsequent logs suffer delay unless V2 is powered off.

tks.

[swingtan]

I've found that it's very specific to SD card size. Because "bigger is always better".... I had purchased a 2GB SD card for BBL work. I figured that I could leave as many logs on the card as I could so I have a "backup" after copying them to the PC. The times I measured above are with the 2GB card.

Recently though, my wife bought herself a little camera that came with a fairly useless 32MB SD card, ( I have no idea why camera companies still do that, it would fit about 4 pictures on it! ), so I tried that for BBL. Instantly the delays went. So I'm pretty sure that it's to do with the V2 checking the SD card parameters and the bigger the card, the longer the check takes.

So the quick easy fix for now is to use a small SD card rather than a big one.

Simon

[gmh308]

mmmmm.......interesting.....Or unplug the cable momentarily :) each time the log is terminated.

[swingtan]

Yes, but that screws with the internal date/time.....

I'm looking for a 128MB or 256MB SD card to see how that runs. I think it will be a good compromise between capacity and delay times.

[gmh308]

Yes, but that screws with the internal date/time.....



:doh:! Good point. Pity it will never have an RTC anyway. Se la vie.

[Blacky]

:doh:! Good point. Pity it will never have an RTC anyway. Se la vie.
We tried hard during development to have a battery backed RTC - even a large capacitor to backup the clock for just a few minutes to allow reboots. But we could not fit it in.

FlashScan V3 (if/when we make one) will have a battery backed clock.

Regards
Paul

[Blacky]

Sorry Guys,

I dropped the ball on this. I meant to add some diagnostic trace info into the firmware so we can catch exactly where it is slowing down.

I'll add it to the next AutoCal beta update.

Regards
Paul

[gmh308]

We tried hard during development to have a battery backed RTC - even a large capacitor to backup the clock for just a few minutes to allow reboots. But we could not fit it in.

FlashScan V3 (if/when we make one) will have a battery backed clock.

Regards
Paul

At least you all tried hard there Paul. Not to give you too much of a sense of comfort, but it is still arguably the best of its kind on the market. :) At least IMHO.

[gmh308]

:blahblah:
Sorry Guys,

I dropped the ball on this. I meant to add some diagnostic trace info into the firmware so we can catch exactly where it is slowing down.

I'll add it to the next AutoCal beta update.

Regards
Paul

ThankYOU!