I've used autostart & autostop loads of times, on various DL1s and it's never failed to work. I personally use :-
AUTOSTART > 300
AUTOSTOP < 300
Which seemed lopgical to me (never read the manual).
I've never really used the other settings although I would REALLY like to have the facility (maybe already there) to not only start logging when the AUTOSTART trigger is met BUT ALSO LOG THE PREVIOUS x seconds of data (assuming it is still in memory/buffer).
The reason being, if I use it for a race I lose the start data which I'd really like to have, would probably only need about 5 secs of "pre-trigger" data.
Is this already possible?
Maxx
PS. On thinking about Dan's issue I'm wondering if a momentary loss of GPS signal would trigger the autostop. It may be coincidence but Silverstone GP circuit has 3 major bridges. When I examine GPS poss acc I do see a significant drop in GPS pos acc when I go under these.
Help pls - autostart stop problem
I like Maxx's thinking re bridges.
Was DanH at Silverstone or another momentarily challenged circuit?
The pre-trigger should capture Maxx's starts. As I apply an Auto-Start without an Auto-Stop, the start is captured because logging starts on the parade or warmup lap, even if the car has been under cover before this. Thus, I have never attempted the pre-trigger.
Do we have many users successfully pre-triggering
Danh's issue does seem buggy. We are raising possibilities in the hope that they trigger a solution. Perhaps we are miles off the root cause. At the risk of rubbing his nose in it, Martin has suggested the bug possibility. Perhaps this new unit, noting DanH's original postscript, has snuck out with a new bug.
I have several new units about to be put into service. If Danh has "triggered" a bug, I hope Martin has the opportunity to confirm it and in due course post a warning and remedy.
Was DanH at Silverstone or another momentarily challenged circuit?
The pre-trigger should capture Maxx's starts. As I apply an Auto-Start without an Auto-Stop, the start is captured because logging starts on the parade or warmup lap, even if the car has been under cover before this. Thus, I have never attempted the pre-trigger.
Do we have many users successfully pre-triggering
Danh's issue does seem buggy. We are raising possibilities in the hope that they trigger a solution. Perhaps we are miles off the root cause. At the risk of rubbing his nose in it, Martin has suggested the bug possibility. Perhaps this new unit, noting DanH's original postscript, has snuck out with a new bug.
I have several new units about to be put into service. If Danh has "triggered" a bug, I hope Martin has the opportunity to confirm it and in due course post a warning and remedy.
I did a little test run in my road car this morning.
Autostart Speed > 50
Autostop Speed < 50
pre-trigger 1 minute
post trigger 5 minute
Triggered fine. The pretrigger time worked. I'd started by reversing off my drive, with the DL triggering as I pulled away. The log included the reversing, so I'd say that worked.
One oddity though. I didn't set off until I had GPS lock, but the file was dated as back in 2004. I'm guessing the pretrigger means the file is created at power on and isn't redated with the correct start date/time when logging commences. If that assumption is correct it might be nice to have the option for the pretrigger to not start recording until there's a gps lock, or for the data/time to be updated when logging triggers.
The current logic with start/stop tends to create quite a few small file at times.
It looks like if autostart triggers while the DL is waiting to doing post-trigger recording then it starts a new log. If there was an for autostart to just continue if there's recording in progress that would stop getting lots of little files.
The other option would be if autostop had a time variable - so give a time in seconds for the autostop condition to be true before it triggers. For example even 30 seconds would cover most periods of GPS dropout.
So with my test today, I'd say I didn't find any bugs, but there is scope for improving the user friendliness and usefulness though.
-Brian.
Autostart Speed > 50
Autostop Speed < 50
pre-trigger 1 minute
post trigger 5 minute
Triggered fine. The pretrigger time worked. I'd started by reversing off my drive, with the DL triggering as I pulled away. The log included the reversing, so I'd say that worked.
One oddity though. I didn't set off until I had GPS lock, but the file was dated as back in 2004. I'm guessing the pretrigger means the file is created at power on and isn't redated with the correct start date/time when logging commences. If that assumption is correct it might be nice to have the option for the pretrigger to not start recording until there's a gps lock, or for the data/time to be updated when logging triggers.
The current logic with start/stop tends to create quite a few small file at times.
It looks like if autostart triggers while the DL is waiting to doing post-trigger recording then it starts a new log. If there was an for autostart to just continue if there's recording in progress that would stop getting lots of little files.
The other option would be if autostop had a time variable - so give a time in seconds for the autostop condition to be true before it triggers. For example even 30 seconds would cover most periods of GPS dropout.
So with my test today, I'd say I didn't find any bugs, but there is scope for improving the user friendliness and usefulness though.
-Brian.
-
- Posts: 65
- Joined: Fri Jul 06, 2007 10:26 pm
- Location: Saint Louis, Missouri, USA
Crikey, Dan
Was that a rough road, some jalopy, new automotive imprecision, or unfortunately R-T's "out of the box" hardware not quite "up to scratch"
There are so many ways that we can be "bitten on the bum".
If we use Poirot's little grey cells and examine the quotation, the card has filled up - "99" is it...
This seemingly happened systematically, if "about 1/3rd lap length" has sufficient repeatability.
Is "length" time, or distance?
Does a repeating time equal the added pre & post trigger times?
Are the physical lengths discernable portions of the circuit?
Perhaps what is recorded is just junk
I hazard to suggest that Dan's contact bounce would be more random than repeating, unless corresponding to significant circuit features, but it is still good thinking and a valuable warning.
I believe that the help wiki has information on the serial message/data format ( http://www.race-technology.com/wiki/ind ... efinitions ) that is the same as on the card:
http://www.race-technology.com/wiki/ind ... DataFormat
It's all Dutch to me
- but I'm sure some Softy could recover some data...
Cheers
Mike
Was that a rough road, some jalopy, new automotive imprecision, or unfortunately R-T's "out of the box" hardware not quite "up to scratch"
There are so many ways that we can be "bitten on the bum".
If we use Poirot's little grey cells and examine the quotation, the card has filled up - "99" is it...
This seemingly happened systematically, if "about 1/3rd lap length" has sufficient repeatability.
Is "length" time, or distance?
Does a repeating time equal the added pre & post trigger times?
Are the physical lengths discernable portions of the circuit?
Perhaps what is recorded is just junk
I hazard to suggest that Dan's contact bounce would be more random than repeating, unless corresponding to significant circuit features, but it is still good thinking and a valuable warning.
I believe that the help wiki has information on the serial message/data format ( http://www.race-technology.com/wiki/ind ... efinitions ) that is the same as on the card:
http://www.race-technology.com/wiki/ind ... DataFormat
It's all Dutch to me
- but I'm sure some Softy could recover some data...
Cheers
Mike
-
- Posts: 65
- Joined: Fri Jul 06, 2007 10:26 pm
- Location: Saint Louis, Missouri, USA
faraday wrote:Crikey, Dan
Was that a rough road, some jalopy, new automotive imprecision, or unfortunately R-T's "out of the box" hardware not quite "up to scratch"
Can't blame it on R-T, as they did not provide either connector of the cigarette lighter circuit.
Rough road? You might say that. We had occasion to test a locking device for big trailers, and part of the testing involved attempting to hook up by backing the tractor at 3 MPH into the stationary trailer in an attempted "hook-up." It was alleged that the lock would deform in the receiving slot and provide enough friction for the tractor-trailer combination to drive away.
It did not.
Automotive imprecision? Well, the truck driver lined up the receiver slot perfectly in every test.
--Dan in Saint Louis
Thanks for the help guys.
Pretty sure its not the connection as it has worked fine that way on a couple of occasions with manual triggering, even at the same circuit.
Both my unsuccessful logging days were at Silverstone, so Maxx you may be onto something with that bridge comment although I don't think the traces stopped at the same point each time. It shouldn't drop out with just a momentary signal interruption anyway as it should wait for <30kph for a minute before stopping logging.
Maxx - pretrigger time does exactly what you describe (if it works!)
As to 99 files, yep it generated all of those over a very short space of time as you can imagine! The card was empty apart from the config at the start of day however.
I'm inclined to think it's a firmware issue.
Still, at least by having no data I can kid myself my laps were the best ever and who can challenge me! Just gutted I lost the supercup drivers traces as that would have been great for comparison
Pretty sure its not the connection as it has worked fine that way on a couple of occasions with manual triggering, even at the same circuit.
Both my unsuccessful logging days were at Silverstone, so Maxx you may be onto something with that bridge comment although I don't think the traces stopped at the same point each time. It shouldn't drop out with just a momentary signal interruption anyway as it should wait for <30kph for a minute before stopping logging.
Maxx - pretrigger time does exactly what you describe (if it works!)
As to 99 files, yep it generated all of those over a very short space of time as you can imagine! The card was empty apart from the config at the start of day however.
I'm inclined to think it's a firmware issue.
Still, at least by having no data I can kid myself my laps were the best ever and who can challenge me! Just gutted I lost the supercup drivers traces as that would have been great for comparison
I still haven't had a chance to look at the autostart firmware, I've been up to my neck in DASH3, IMU06 and SPEEDBOX mk2 work.
I read that somebody had data corrupted when power got turned off. What generally happens here is that the file length as shown by the file allocation table (FAT) and the directory entry are out of sync. If you have newish firmware on your DL1 and you have found this happened with your last recorded file, put the card back in the DL1 and turn the power on, wait about 10 seconds then turn it off again. Check the card again on your PC.
When the DL1 is turned on it checks to see if it can find the last file it stored, if it can it checks that the FAT and directory entries are consistent. If not it updates the directory entry to make the file readable.
The DL1 does keep the directory entry updated as the file size increases, but since it can only write to either the FAT or the directory sector there are times when they are out of sync, and if you get unlucky with having the power pulled you can lose data this way.
The other issue mentioned of the time stamp being the time at which the file was started rather than the time at which the loop mode ended has been changed in the latest firmware, it is now updated to the time when the loop mode exited. Come to think of it, this is the last modification which was done the pretrigger code and now I am getting a few reports of problems. At least I know where to start looking.....
If anybody does get a corrupt file and they REALLY want the data. Stick the card in the post to me at RT HQ and I'll see what I can do. I can usually get most or all of a file off the card so long as it isn't physically damaged.
Martin
I read that somebody had data corrupted when power got turned off. What generally happens here is that the file length as shown by the file allocation table (FAT) and the directory entry are out of sync. If you have newish firmware on your DL1 and you have found this happened with your last recorded file, put the card back in the DL1 and turn the power on, wait about 10 seconds then turn it off again. Check the card again on your PC.
When the DL1 is turned on it checks to see if it can find the last file it stored, if it can it checks that the FAT and directory entries are consistent. If not it updates the directory entry to make the file readable.
The DL1 does keep the directory entry updated as the file size increases, but since it can only write to either the FAT or the directory sector there are times when they are out of sync, and if you get unlucky with having the power pulled you can lose data this way.
The other issue mentioned of the time stamp being the time at which the file was started rather than the time at which the loop mode ended has been changed in the latest firmware, it is now updated to the time when the loop mode exited. Come to think of it, this is the last modification which was done the pretrigger code and now I am getting a few reports of problems. At least I know where to start looking.....
If anybody does get a corrupt file and they REALLY want the data. Stick the card in the post to me at RT HQ and I'll see what I can do. I can usually get most or all of a file off the card so long as it isn't physically damaged.
Martin
Is it possible to get a firmware update then please? Currently using version 7-5 on a green connector Mk1 DL1.
Regarding the corruption if power is lost, I don't suppose you know how long the DL1 needs to be powered when it's told to stop for it to finish writing the file/directory?
I'm thinking of a couple of options. I could autostop off the battery voltage.
Then I've two choices. Either a use a permament 12v that a circuit switches off after a certain time to allow the DL1 to finish writing, or use either capacitors or a battery to provide power for a short time.
With a circuit switching a live 12v that could easily be rigged to only power the DL1 some time after it's seeing alternator voltage (instead of battery voltage) so the DL1 wouldn't be switched on during cranking.
Just thinking of simple ways to 'idiot proof' it somewhat!
-Brian.
Regarding the corruption if power is lost, I don't suppose you know how long the DL1 needs to be powered when it's told to stop for it to finish writing the file/directory?
I'm thinking of a couple of options. I could autostop off the battery voltage.
Then I've two choices. Either a use a permament 12v that a circuit switches off after a certain time to allow the DL1 to finish writing, or use either capacitors or a battery to provide power for a short time.
With a circuit switching a live 12v that could easily be rigged to only power the DL1 some time after it's seeing alternator voltage (instead of battery voltage) so the DL1 wouldn't be switched on during cranking.
Just thinking of simple ways to 'idiot proof' it somewhat!
-Brian.
It is not easy to say how long the DL1 needs to stop logging, as it depends on so many factors. It will automatically stop logging at somewhere around 8-9v, so to give it the maximum time you could set it to stop based on battery voltage being <11v. The DL1 has 2200uF on the input side after the protection diode, so if you wanted to put another diode on the input and a further capacitor you would want to use something significantly larger to get much benefit.
Martin
Martin
I had a look over the autostart/autostop today. I did find something of interest which could cause problems on any units which have the 20Hz ability. The suppiers of the GPS modules have changed the firmware in the unit, as a result the speed accuracy value is reported in a different way from before. The DL1 checks that the speed accuracy is good before using the value for either autostart or autostop. The newly calculated values were basically saying that the speed accuracy was a load of rubbish, even when it was actually very good. I have changed the threshold on the speed values which should improve things considerably.
I have done some testing with autostart and autostop with both pre and posttrigger on the bench without any problems.
If anybody has a DL1 with the version 6 bootloader and wants the new firmware to try out drop me an email to mhill at race-technology.com
Martin
I have done some testing with autostart and autostop with both pre and posttrigger on the bench without any problems.
If anybody has a DL1 with the version 6 bootloader and wants the new firmware to try out drop me an email to mhill at race-technology.com
Martin
Have we resolved the issue of auto start / stop parameters having to be identical (as per the wiki - http://www.race-technology.com/wiki/ind ... topControl) or logical (as per discussed by users earlier in this topic which seem to work) ?
Also if the speed is used as the trigger, from what you say above, the speed accuracy is used such that the logging will only commence when a good GPS lock is achieved (ie decent time /date stamps for files...) ?
Also if the speed is used as the trigger, from what you say above, the speed accuracy is used such that the logging will only commence when a good GPS lock is achieved (ie decent time /date stamps for files...) ?
Give me a break, a post appears at 10:20pm and I am getting told off because there is still no reply at 6:40am the next morning. I'm only human you know!!!
Anyway, in answer to the question... The details in the knowledge base are correct. You can use the autostart / stop with what are seen as most logical parameters. I.E. Start > 20kph, stop <10kph and you will get what you would expect. You can also set them to have exactly the same conditions and this then becomes a special case for use with the pre and post trigger times. When set, logging will continue until the pre-trigger time after the conditions were last met.
You are also correct with what you say about using speed as a trigger. Remember though that in pre-trigger mode the logging by definition will start before the trigger conditions are met, so the initial file time / date may well be incorrect. This should be updated when coming out of the pre-trigger mode.
Martin
Anyway, in answer to the question... The details in the knowledge base are correct. You can use the autostart / stop with what are seen as most logical parameters. I.E. Start > 20kph, stop <10kph and you will get what you would expect. You can also set them to have exactly the same conditions and this then becomes a special case for use with the pre and post trigger times. When set, logging will continue until the pre-trigger time after the conditions were last met.
You are also correct with what you say about using speed as a trigger. Remember though that in pre-trigger mode the logging by definition will start before the trigger conditions are met, so the initial file time / date may well be incorrect. This should be updated when coming out of the pre-trigger mode.
Martin
Return to “General support questions”
Who is online
Users browsing this forum: No registered users and 40 guests