Thread: Nanocom Evo data/poll logging rate?

Colin will hopefully jump in with a definitive answer, but I think it captures at roughly 1 second intervals. I had a feeling the EVO added a timestamp to the log, but I would need to dig out one of my old logs to be sure

It has a log time stamp but these are all the same at 16/05/2005 2:19PM, but there is no time or timings in the actual data. A Nissan OBD1 logging program I have, records minutes seconds and milliseconds in the data log.

I assume the nanocom has no form of clock at all as all logs have the above timestamp regardless of when the unit was powered or the data collected.

But hopefully if the data is collected at a specific rate, even if this is (for example) 836 mS per csv line I can add a column to calculate the timings.

Cheers
Marc

My understanding is a 1 second interval as well. The unit doesn't have a clock chip or a battery back-up so hence the 2005 file creation date for all files.

Cheers

steve

Ive been doing some data logging last few days and posted results in this thread
http://www.aulro.com/afvb/electronic...yota-head.html

when you compare the csv file to the dashcam footage 1 sec per log event does not match up

below csv file has 103 rows, corresponding video runs 73 seconds ,
even when you remove 13 rows from the file when car wasnt moving at the end it still does not match.

(1 second log timings should equal 1:40 video, not 1:13 as in the youtube clip)

Test Run Nanocom CSV log file = http://goingbush.com/landy/nanocom/ram.csv


[ame="http://www.youtube.com/watch?v=V2wlWQFHCTE"]Snorkle Test - YouTube[/ame]


.

Colin will hopefully jump in with a definitive answer,

Happy to oblige Peter

The logging rate is not set to any fixed time and the exact time may well vary between individual logs entries, different logging sessions and even be different between vehicles. It will also be different on the different vehicle ECU's.

In each log cycle, a series of diagnostic requests for the various pieces of information are made, so of course the more pieces of information are gathered the longer the cycle will take. The time the ECU actually takes to reply to each request will vary between ECU's Data requested, and at random depending on what else the Processor of the ECU is doing at that moment. In critical systems like ABS this is why diagnostic communications are not provided when the vehicle goes above 7KPH.

Of course if you ask too much, too quickly, things go wrong, you get errors and communications break down. Many will remember that we had this issue with the TD5 instrument mode, where certain ECU's could not keep up with the information request rate.

Even when the ECU replies, then there is the overhead of converting the reply from Hexadecimal to whatever value it represents, transporting this, and displaying or writing this to an SD card.

The best i can suggest for anyone interested in the logging timing is to run a timed logging session for a few minutes, then count the number of log entries to give a good general average for their ECU.

I hope this helps

Colin

Thanks Colin, makes perfect sense, I might try and get an average poll time for my Discovery over several trips and use that as my approximate poll time.

Cheers
Marc.

Hiya Marc

Happy to help and so glad my input comments made sense to you.

Off subject Don but what EGT were you getting during the latter part of that run??

Originally Posted by goingbush

Ive been doing some data logging last few days and posted results in this thread
http://www.aulro.com/afvb/electronic...yota-head.html

when you compare the csv file to the dashcam footage 1 sec per log event does not match up

below csv file has 103 rows, corresponding video runs 73 seconds ,
even when you remove 13 rows from the file when car wasnt moving at the end it still does not match.

(1 second log timings should equal 1:40 video, not 1:13 as in the youtube clip)

Test Run Nanocom CSV log file = http://goingbush.com/landy/nanocom/ram.csv


Snorkle Test - YouTube


.