How to handle lossy data stream?

[LTBALAZS]

Hello,

I was asked a questuon 'How to handle lossy data stream?'

I've found an example in LV as Lossy Stream.vi

Is there a simplier way to do it? Can i do it with queue? Is it related to FIFO?

Balazs

[crossrulz]

---

@LTBALAZS wrote:

Is there a simplier way to do it? Can i do it with queue? Is it related to FIFO?

---

If you are using Queues, then you would use the Lossy Enqueue Element when adding data to the FIFO.  If the queue if full, as determined by the queue size when you initialize it, then the oldest element is dropped.

[GerdW]

Hi Balazs,

---

@LTBALAZS wrote:

I was asked a questuon 'How to handle lossy data stream?'

---

What did you answer?

I would say: You handle lossy streams the same way as you handle non-lossy streams by reading the data from the stream. You just need to be aware there might be lost data packets…

---

@LTBALAZS wrote:

Is there a simplier way to do it? Can i do it with queue? Is it related to FIFO?

---

Channel wires can be replaced by queues or notifiers (or vice-versa).

A queue (or a stream) is implement FIFO behaviour.

(Are you still doing homework? :D)

[RTSLVU]

---

@LTBALAZS wrote:

Hello,

I was asked a questuon 'How to handle lossy data stream?'

I've found an example in LV as Lossy Stream.vi

Is there a simplier way to do it? Can i do it with queue? Is it related to FIFO?

Balazs

---

I don't understand your question. Do you mean What is a Lossy Stream used for?

Think of a "Lossy Stream" as a buffer that holds the last X number of acquired data points.

I used one in an application where I was acquiring lots of data from an instrument every 10mS (input/output V,I,W, etc.) but for long tests data logging was only once a minute.

In my case as the data was acquired the UUT input and battery current were compared to maximum safe operating limits, logged if it was time to log, then all the measurements were put in the Lossy Stream and sent to my Control Loop.

The Lossy Stream was sized to hold the last 10 seconds of acquired data.

If either current exceed the limit the test is shutdown and the Control Loop would dump the entire Lossy Stream contents (the 10 seconds prior to the limit trip) to a file for troubleshooting.

Also I have to say I find Streams much easier to understand and more intuitive than Queues and Notifiers...

[Bob_Schor]

---

@RTSLVU wrote:Also I have to say I find Streams much easier to understand and more intuitive than Queues and Notifiers...

---

I completely agree!  But to my great surprise (because I've not yet tried to use Lossy Streams), they do not work as smoothly as the Lossy Queue when used as a "circular buffer" (or "the most recent 10 seconds of data" example that RTSLVU just described).  That's because they are missing a convenient "Dump Stream" command (but we have the Lossy Queue for that.

Bob Schor

[rolfk]

Some would argue that a lossy stream is actually a paradox. When you look at the IP suite of protocols you have the TCP/IP protocol which is considered a Stream and the UDP which they call datagram. TCP/IP guarantees that the data arrives in the right order and fully or not at all, while UDP only gurantees that a datagram arrives completely or not at all and a later datagram can arrive before an earlier one, as they may each take completely different routes and UDP does not reorder packages as they arrive.

So a stream in networking is usually considered an ordered and complete transmission of bytes and the opposite of lossy.

[Bob_Schor]

---

@rolfk wrote:

Some would argue that a lossy stream is actually a paradox.

---

@Rolf,

     I believe the Original Poster was talking about the Lossy Stream Channel Wire, which in the Old Days we'd call a "Circular Buffer".  Unlike the other "Stream" Channel Wires that stop accepting inputs (and thereby "blocking" Data Flow) when their Buffer (by default, of "unlimited size") is filled, the Lossy Stream does not block, but either discards the incoming Element or adds it to the Circular Buffer, replacing the oldest element.  It is analogous to the "Lossy Queue", except it does not have the convenient "Dump the Queue Contents" function that turns the Lossy Queue into a handy "Box-Car Averager".

     I tend to use Messenger Channels the most, and can't remember whether (out of "Queue" habit) I usually specify a "Size" parameter for my Stream Channel Wires (thus far, I've only used the "vanilla" flavor).  However, despite the awesome talents of the Developers of Asynchronous Channel Wires, I think I would take an "unlimited size" claim with a grain of NaCl ...

Bob Schor