What to do when you have data coming in at different rates over the same COM port?

[superomario]

I have a 4 Zigbee node set up, 3 transmitters (identifiers are 333,444,555), 1 receiver. The reciever is read by Labview using the serial read. Each transmitter has a unique identifier and I can parse out who sent what packet when. Since I only have the one receiver, if I am getting a packet from one transmitter it ignores the other 2. My issue is that 1 of the transmitters runs at 20Hz, while the others at 1Hz. I think i am forced to run at the speed of my slowest component, so taht would mean my VI needs to be timed to run at 1Hz. What I would like to do is average all 20 samples from the faster transmitter, then record/perform calculations/display my data with the other two at a rate of once per second.

As far as I can tell from the packets received the data rate is fast enough that losing 1 or 2 packets from the faster sensor is a negligible loss if I do end up averaging them:

08-22-2016 13:36:04.196,6126,RECV,7E00178100002B00205A203030303230207A2030303031350D0A00
08-22-2016 13:36:04.252,6127,RECV,7E00178100002B00205A203030303230207A2030303031350D0A00
08-22-2016 13:36:04.296,6128,RECV,7E00178100002B00205A203030303230207A2030303032300D0A04
08-22-2016 13:36:04.346,6129,RECV,7E00178100002C00205A203030303230207A2030303032320D0A01
08-22-2016 13:36:04.346,6130,RECV,7E00178100002F00205A203030303230207A2030303032320D0AFE
08-22-2016 13:36:04.436,6131,RECV,7E002E81000032004F20303230362E332054202B32352E38205020313031382025203032302E3237206520303030300D0AC4
08-22-2016 13:36:04.436,6132,RECV,7E00178100003200205A203030303230207A2030303032300D0AFD
08-22-2016 13:36:04.486,6133,RECV,7E00178100003600205A203030303230207A2030303031350D0AF5
08-22-2016 13:36:04.536,6134,RECV,7E002E81000032004F20303230362E362054202B32362E38205020313031392025203032302E3237206520303030300D0ABF
08-22-2016 13:36:04.596,6135,RECV,7E00178100003800205A203030303139207A2030303030380D0AE9
08-22-2016 13:36:04.596,6136,RECV,7E00178100003300205A203030303138207A2030303030380D0AEF
08-22-2016 13:36:04.652,6137,RECV,7E00178100003100205A203030303139207A2030303032320D0AF4
08-22-2016 13:36:04.652,6138,RECV,7E00178100002F00205A203030303139207A2030303032340D0AF4
08-22-2016 13:36:04.738,6139,RECV,7E00178100002F00205A203030303139207A2030303032310D0AF7
08-22-2016 13:36:04.786,6140,RECV,7E00178100003000205A203030303139207A2030303032300D0AF7
08-22-2016 13:36:04.836,6141,RECV,7E00178100003200205A203030303139207A2030303032320D0AF3
08-22-2016 13:36:04.886,6142,RECV,7E00178100003200205A203030303139207A2030303031380D0AEE
08-22-2016 13:36:04.946,6143,RECV,7E00178100003200205A203030303139207A2030303031330D0AF3
08-22-2016 13:36:04.996,6144,RECV,7E00178100002E00205A203030303138207A2030303031310D0AFA
08-22-2016 13:36:05.046,6145,RECV,7E00178100002C00205A203030303138207A2030303031360D0AF7
08-22-2016 13:36:05.096,6146,RECV,7E00178100002C00205A203030303139207A2030303032350D0AF6
08-22-2016 13:36:05.146,6147,RECV,7E00178100002E00205A203030303138207A2030303031340D0AF7
08-22-2016 13:36:05.146,6148,RECV,7E00178100002F00205A203030303138207A2030303031330D0AF7
08-22-2016 13:36:05.236,6149,RECV,7E00178100003000205A203030303138207A2030303032300D0AF8
08-22-2016 13:36:05.286,6150,RECV,7E00178100003300205A203030303138207A2030303032320D0AF3
08-22-2016 13:36:05.346,6151,RECV,7E00178100003700205A203030303138207A2030303031360D0AEC
08-22-2016 13:36:05.396,6152,RECV,7E00178100003900205A203030303138207A2030303031320D0AEE
08-22-2016 13:36:05.446,6153,RECV,7E002E81000032004F20303230362E332054202B32352E38205020313031382025203032302E3237206520303030300D0AC4
08-22-2016 13:36:05.446,6154,RECV,7E00178100002A00205A203030303138207A2030303031360D0AF9
08-22-2016 13:36:05.506,6155,RECV,7E00178100002600205A203030303138207A2030303032320D0A00
08-22-2016 13:36:05.506,6156,RECV,7E00178100002300205A203030303138207A2030303031380D0AFE
08-22-2016 13:36:05.566,6157,RECV,7E002E8100002E004F20303230362E362054202B32362E37205020313031392025203032302E3237206520303030300D0AC4

Since it is a stream that is continously running, slowing down the read loop with a wait crashes everything. The idea I have to make this work is to use reception of the 3rd sensor as my timing marker. So when 555 is received, take last 20 data points from 333, average them and then use that for other phases of the VI.

1) is this a good idea?

2) how do I implement it?

My VI is attached for reference. Ignore the switch case it does not work in this version, but everything is correct.

[Wolleee]

Im not sure i fully understand your problem, but i dont know why averaging 333 would be a problem.  Youll have to trigger on 555 as you stated and then use a shift register to store the last 20 data points from 333.  When 20 are recieved perform your calcuations and clear the shift register to prepare for the next 20 data points.

[crossrulz]

---

@superomario wrote:

1) is this a good idea?

2) how do I implement it?

---

1) Sounds like a good idea to me

2) Store the running sum and the number of samples you acquired in shift registers.  Then in the 0x0555 case, you can divide the sum by the number of samples and you have your average for the faster channel.

[Henrik_Volkers]

additionaly add a timeout in your capture loop. If after x ms not tree valid values are read, decide what to do...

in your log file I would add a last column to also log these events..    RF transmissions tend to fail time by time 😄

[superomario]

Tried to add in the shift registers and runnign average, but the whol VI does not udpate at 1Hz ,it just runs at the same speed as before. the averaging seems to be working on the plot though. 

[Wolleee]

There is no need to time your loop to the transmitter.  You will collect data as it becomes available, so the timing will essentially come from the transmitter.

[superomario]

Right but the transmitter is sending data at 20Hz, and the labview VI is updating that fast as well. So my slower 1Hz channels are just updating at 20Hz because there is always a data point to replot due to the shift registers. How do I avoid this and make everything run at 1Hz? 

[superomario]

I think the issue is that I am doing a running average, when I would really only like to average the 20Hz sensor in blocks every time a 0x555 case turns up. Not sure how to do a block average as opposed to a running one though. 

[Wolleee]

Youll need to put it into a shift register and take the array size.  When you get the sample from 555 just average the array, send to chart and reinitialize the shift register array.

[crossrulz]

---

@superomario wrote:

Tried to add in the shift registers and runnign average, but the whol VI does not udpate at 1Hz ,it just runs at the same speed as before. the averaging seems to be working on the plot though. 

---

Why the FOR loop?  That makes no sense at all.  You need to keep the running sum on the WHILE loop.