Continous serial Reading In labVIEW

[VenkataRajasekhar]

Removed 5 instances and modified path releated things.

[VenkataRajasekhar]

Now i have modified all those please check the code for finding the reason behind data lost.

[GerdW]

Hi Venkata,

don't open the file in each iteration of the inner loop.

Open the file once before the loop and close it after loop. Inside the loop you only need the WriteFile functions!

You still didn't answer my questions:

- Which data is missing?

- How many data is missing?

[VenkataRajasekhar]

1 byte data coming more.\n hex value is coming more.

As well as when UUT is sending data continuously i am loosing some data.That i came to know while extracting data from binary file.

[GerdW]

Hi Venkata,

1 byte data coming more.\n hex value is coming more.

Did you enable the TermChar for that "binary" reading? Don't do that…

i am loosing some data.

Please define "some" with meaningful numbers…

[Frozen]

As GerdW has pointed out, disabling the Termination Char will probably solve your missing data problem.

[VenkataRajasekhar]

Please have a look on the csv file in the last column i have to get 0.2 or lesser than 0.2 but i am getting more when continuously reading for long time like 13 hours.

[VenkataRajasekhar]

I have disabled term char but still its happening.

[GerdW]

Hi Venkata,

what is the meaning of that last column (without a header entry)?

The total amount of entries are ~82700: most of the values in this column are ~0.2. Only 4 entries have negative values and about 4900 entries are >=1 (but all multiples of 0.2!) with just 2 entries larger than 40.

I guess those data show some time intervals: what accuracy do you expect on a standard Windows OS?

[Frozen]

Very interesting problem you have there! It has me intrigued.

Looks like the last column is the time difference in seconds. So 0.2 seconds is reasonable expectation for Windows to maintain... Unless of course the virus scanner kicks in. Or doing some heavy compiling. Or running MemTest86. Installing Windows Updates...

Graphing out the time diff shows an increasing problem...

It is interesting the problem is evenly spaced between samples, but not in time. IE every 9th sample is irregular, but the time between them varies. Is there a way to coordinate the data to absolute time? Is it time-of-day dependent?

At this point I would start suspecting the sending unit. Are you sure the unit is not having some kind of problem acquiring the GPS info? Are you capturing ALL the data coming from the unit, including error messages?