How to synchronize data from two serial ports at different sample rates?

[jdeters79]

---

@johnsold wrote:

Some things to consider:

- You have termination characters enabled. If your serial devices are sending termination characters, use them to end the reads and get rid of the Bytes at Port nodes.  You should never use both at the same time - they fight each other.

---

Lynn,

I'm failing to see how to get rid of the bytes at port?  The VISA Read requires "byte count"  Are you simply stating to get rid of the "Property nodes"?  VISA read would still require a byte count to be wired in.  Also, how does one terminate a read using termination characters?  Is that accomplished through the "VISA Configure Serial Port"?  Looks like the default is true, which as you said, means termination characters are already enabled in the reads in my VI.  So in the end, do I need to just get rid of the "Property Nodes" that are reading bytes at port to accomplish what you suggest?

Thanks again,

Jordan

[johnsold]

Jordan,

When using termination characters you just set a constant at Byte Count which is larger than the expected length of the message. If you expect 10 bytes you might set the value to 25 or 50.  The Read will generate warning about the possiblilty of more bytes being available than the number read, but you can just ignore that.  Those bytes will be part of the next message.

Remove the property node and use a constant at Byte Count.

Lynn

[jdeters79]

Lynn,

Made those changes but still running into the issues with the GPS data.  Removed the Bytes at Port property node, and created a constant for the byte count. 

I have an older VI that I used as the foundation for the one in question.  The main difference is, it does not have two VISA Serial Read inputs.  It has a single VISA Serial Read, along with a "LabJack" USB input.  That one runs with no problems (i.e. GPS data is logged at 5 Hz, with no buffer issues.  I still don't understand why the "OSM" data is collected at an appropriate rate (and matches the clock) while the GPS seems to get stored in and fill a buffer?

Jordan

[billko]

---

@jdeters79 wrote:

Lynn,

Made those changes but still running into the issues with the GPS data.  Removed the Bytes at Port property node, and created a constant for the byte count. 

I have an older VI that I used as the foundation for the one in question.  The main difference is, it does not have two VISA Serial Read inputs.  It has a single VISA Serial Read, along with a "LabJack" USB input.  That one runs with no problems (i.e. GPS data is logged at 5 Hz, with no buffer issues.  I still don't understand why the "OSM" data is collected at an appropriate rate (and matches the clock) while the GPS seems to get stored in and fill a buffer?

Jordan

---

Maybe it's the COMMANDS that are being buffered?  Maybe the serial port set up to flush the write buffer only when full?

[jdeters79]

---

@billko wrote:

 

Maybe it's the COMMANDS that are being buffered?  Maybe the serial port set up to flush the write buffer only when full?

---

Interesting.  I added a VISA Flush I/O Buffer to each device, set to "Flush Receive Buffer (No I/O)" and it improved performance, although still not perfect.  Now it appears that the program "freezes" intermittent (~1 second) occasionally, but while writing, it is logging GPS data at 5 Hz.  Attached is a sample of the captured output.  I added a couple columns to show the time steps (0.2s) and where the logging hangs (~1 s).

[jdeters79]

Update. 

While testing the VI, I'm using the actual GPS for the first serial port device, and a simulated serial port for the second (using COM Port Data Emulator and Virtual Serial Port).  I found some interesting behavior.  With the Com Port Emulator, I am able to specifiy the interval between messages.  Previously, I have been using 167 ms as that is the rate (6 Hz) of the actual device I will be monitoring.  I decided to change the rate in the emulator to investigate what happens (if anything).  If the emulator rate is changed to a multiple of 5 Hz, then it works just fine.  But if it is not an integer multiple, then it occasionally hangs as previously described. 

Hopefully this provides some more useful info for an answer...

[jdeters79]

It turns out that my previous statement is only true when the COM Port emulator rate is a multiple greater than the GPS update rate. 

Updated VI attached for those who may be interested in helping.

Thanks.

[johnsold · Accepted solution]

Jordan,

I think the problem reduces to basic dataflow.  In the main while loop you read from both serial ports.  If the GPS port gets a message 5 times per second (200 ms) and the OSM port gets 6 messages per second (167 ms) and everything else takes negligible time (probably not a valid assumption but sufficient for the explanation), then the loop can NEVER complete in less than 200 ms. So, after 1 second five messages will have been received from the GPS and five messages will have been received from the OSM. After 10 seconds you will have 50 messages from each port, even though the OSM has transmitted 60. At some point you will get a buffer overflow.  I did not look at your latest data but your earlier version was taking 700-800 ms for each iteration, probably due to a combination of serial port timing and file write times.

The solution is to put each of the serial port reads into its own parallel loop and pass the data to a slower loop which can parse and save the data.

Lynn

[jdeters79]

Lynn,

That worked.  I had the program set up that way previously, but I think I had some producer/consumer issues going on that was preventing it from running correctly.  That being said, this does create an issue with some functionality that I was hoping to create.  I now have a GPS loop, and a separate OSM loop.  There is a calculation that resides in the OSM loop that relies on the GPS altitude to be completed.  It appears I cannot directly pass the GPS altitude from one loop to the other (no value passed until GPS loop is stopped).  This prevents having a real time calculation that is used to drive a "warning-type" display.  Any thoughts on that?

Thanks again for all of your help!

Jordan

[jdeters79]

Lynn,

Disregard my last message.  Should've actually put some effort into figuring it out before posting.  I figured out how to make it work using a local variable.  

Again, thanks for your help with the parallel loop issue!

Jordan