Plot 2 graphs in one XY graph with two BaudRates

[ShaneJ007]

Dear Forum Members, 

Although I have read many posts on a similar issue, I think this differs as I'm looking for either a statistical solution or a measurement solution. Earlier I had software bugs but now most are free.

Problem: I have a force sensor (10 measurments/s @9600 Baudrate) and an arduino module - measures pressue (500,000 Baud rate) When I plot the two, I see as follows. 

The force sensor has a low sampling rate as well as a low Baud rate hence the change compared to pressure is very slow. 

I also log them to a txt file. Below is a screenshot of the text file. 

As you may see, for 0.39s, the force sensor doesn't change but the pressure changes over a span of 14 units. Notice the shift in time as well...

After data capturing, then I did a moving average of the pressure for 10 units. then I can almost get rid of the time shift and becomes smoother. (I also tried to up sample the force signal and interpolate) 

Solutions I thought: 

1. Is there a statistical approach to solve this?

2. I was also thinking of getting a better force measurement device (with 1000measurments/s and much higher BaudRate)

3. Is there an easy LabVIEW approach to solve this?

Am I in the right direction of thinking ? Attached is also the VI if someone wants to take a quick look. 

Thanks a lot. 

 Regards, 

Shane. 

[Alexander_Sobolev]

Are you reading with 30 ms steps, and force sensor is giving the same value, or are you reading from it at 0.4s rate and just filling array to match the number of measurements of the faster one? In both cases it seems out of 0.1s spec, but on different reasons.

If your slow sensor is always late, you can subtract this delay from time scale after getting data, but obviously you can not respond to change earlier than it happens.

The need of the faster sensor is determined by your time requirements. How fast do you need to respond to force change? Will you have short pulses that this sensor can miss due to this time constant limit? 

When you do smoothing, draw original and processed graphs on the same scale to make sure you do not induce phase shift.

[Kevin_Price]

I'm on LV 2016 and can't open the code.  For the moment, I'm assuming it works like the advice I gave in prior threads where the two different serial interfaces provide data updates at different rates.  Hence, the slower one retains its prior value during several updates of the faster one.

To a certain extent, there is nothing to "solve" here.  You're simply seeing the visual representation of your system's actual latency.  The inherent problem of latency *is* that the moment you become aware of a sensor's value is NOT the same moment when it was actually true.  A sensor that reports its changes less often simply *will* appear to lag behind a related sensor that updates more often.

On the other hand, there are different factors that can lead to latency.  In some systems, the amount of latency is pretty consistent and can be characterized (though this is not always trivial to do).  When you can characterize it, then you can use this info to help "solve" the time-shift you observe.  You can shift the data in time (as already mentioned by Alexander_Sobolev), the key point being that you should first have *good justification* for doing so.

So in summary, I'd say that just fiddling with stats and algorithms to try to make things look like they line up is not really a good approach.  There should be more rationale behind what you're doing to your data.  Getting a faster-responding force sensor seems like a *much* more beneficial approach.  And further, whenever possible, I would try to avoid serial communication entirely and instead look to use analog sensors that can be captured with a data acq device.

-Kevin P

[ShaneJ007]

---

@Alexander_Sobolev wrote:

Thank you for your input. The force sensor is only capable of 10 Measurements/s and Tx @ a rate of 9600. Both loops run independently but parallel. (yes of course on the windows scheduler).

The need of the faster sensor is determined by your time requirements. How fast do you need to respond to force change? Will you have short pulses that this sensor can miss due to this time constant limit? 

---

Max would be 1ms and at least 20-30ms. Yes. this misses because of the sampling speed. 

I will look into this with a much better sensor + capturing device which can capture @ a rate of 1000M/s and has a Baudrate of around 900k. Is it in your opinion that this will work?

[ShaneJ007]

---

@Kevin_Price 

Thanks a lot Kevin. Yes the loops run with a lag in the order of several milliseconds. Parallelizing works. 

As menitoned previously, I will look into this with a much better sensor + capturing device which can capture @ a rate of 1000M/s and has a Baudrate of around 900k. As for what I've read from you, this is also in your direction of solving this. (To reduce the latency)

Thanks for the tip on the statistical approach. After a few trials I also think that it's not the best to implement.

[Kevin_Price]

I'd just reiterate that as long as you're looking to replace the sensor anyway, an analog signal captured via data acq has significant advantages over anything based on serial communication, especially when focused on the issue of latency.

If the device can stream serial data at a fixed rate, that'd be a better operating mode than query/response.  With query/response, you've got the following possible contributors to timing latency and uncertainty:

- regularity of time between queries in your loop (based on Windows scheduling)

- the time to transmit the query (not much at high baud rates, but still...)

- the time for the instrument to recognize the query and know it's time to act on it (on well-behaved instruments, this may be negligible.  But not all instruments are equally well-behaved...)

- the time for the instrument to *act* on the query.  On some instruments, a query initiates a whole cycle of activity to prepare to take a new sample and then wait for some amount of capture time before determining a new value

- the time to transmit the result

- the time until you receive the result after it's transmitted (negligible if you use a line-termination protocol, not so much if you're using bytes-at-port and accumulating characters)

I realize you can't always go analog instead of serial, but it's nice when you can.

-Kevin P