ni.com is currently undergoing scheduled maintenance.
Some services may be unavailable at this time. Please contact us for help or try again later.
06-10-2022 09:27 AM - edited 06-10-2022 09:31 AM
@Norick17 wrote:
The question is HOW I can improve my vi to solve the problem.
You have been told by three users that this is not a good idea. You have been given a link to a presentation that will help you improve your serial communication that you just proved you did not watch.
I doubt that you woke up this morning and decided to take timing measurements of a serial communication out of pure personal pleasure. Your motivation to do so is not irrelevant. In fact, it is the most important thing to tell us to provide any useful help.
In fact, what you are trying to do might just be utterly impossible.
06-10-2022 09:33 AM
The timing pattern looks mostly similar to this one here, probably for the same reason -- quantization. Hard to guess where it's coming from, though I wouldn't rule out the possibility that's it's down in the VISA / serial drivers. We regularly see similar timing fluctuations for receiving lines of serial data when reading from a serial device that definitely writes at a constant clock rate.
Meanwhile, it will help if you provide more clarifying info. The code you posted puts a single scalar measure of dt into an indicator named TimeArray. The graph you post has units of Hz. You talk about measuring time with a scope -- is it a protocol analyzer? Else, what's the signal you feed to the scope to get time or frequency measurements? There are a lot of unknowns because you haven't filled in the blanks for us enough.
-Kevin P
06-10-2022 09:35 AM
@pincpanter wrote:
Serial reading is not appropriate for precise timing. Remark however that the average frequency is about 10.05 as expected.
Thus not only the lower values are wrong, but the higher are (less) wrong too.
although the average of about 10.5 is ok, the problem are still the values at about 9 Hz. What also is strange that it looks like a constant pattern which is not seen when measuring with a scope. Therefore it looks for me the problem is the vi itself or HOW to read correctly the serial data stream.
06-10-2022 09:48 AM - edited 06-10-2022 09:52 AM
@Norick17 wrote:
You are asking about "why" but this is absolutely irrelevant for my problem (question), because I need to know the timestamp between the "<" chars. It does not matter if it is 1, 3 or 10Hz.. The question is HOW I can improve my vi to solve the problem.
You could try this
06-10-2022 09:53 AM - edited 06-10-2022 09:55 AM
Sure the vi is not optimized. If you switch to the term char technique, it's important to get the timestamp after the VISA Read.
You don't really need two loops. Use only one loop and store the previous timestamp in a shift register: you will also spare half of the timestamp readings.
EDIT: as shown by Jay14159265
06-11-2022 07:23 PM
Is this by any chance a USB serial converter? Ftdi and other converters have a polling rate settable in device manager which is 16mS by default. I have dropped this to 1ms before to solve a similar issue.
06-13-2022 03:30 AM
@pincpanter wrote:
Sure the vi is not optimized. If you switch to the term char technique, it's important to get the timestamp after the VISA Read.
You don't really need two loops. Use only one loop and store the previous timestamp in a shift register: you will also spare half of the timestamp readings.
EDIT: as shown by Jay14159265
This makes sense to get the timestamp after the reading. I used the proposed vi from Jay14159265 although I could not import the code shared. Therefore I attached my current vi.
The outer loop is only for stopping the reading in my case (blue).
The reading for this vi with 5 Hz looks like this now:
I verified this reading in parallel with a logic analyzer which runs at 500 MHz. This shows for all readings 5 Hz +/- 1% accuracy.
06-13-2022 03:41 AM
You have set up a termination character AND read one byte at a time. If you are reading one byte at a time, termination character setup is of no use anyway. I still suggest you make use of the termination character and read enough bytes to catch that instead. Reading one byte at a time is not very efficient.
06-13-2022 05:01 AM
you are right reading one char is not the best. So when using outside the termination char and reading about 25 chars at once, how to I set the timestamp in following vi?
Would you suggest to search in the string of 25 chars and check for the ">" char?
06-13-2022 05:11 AM
When you set a term char, the VISA Read outputs a timeout error if this char is not there.
As I already suggested, require a large number of characters (e.g. 1000), then check for the error output. If there is no error, you are sure that the term char is there.