discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Clarification on how timing/latency applies to a stre


From: Lundberg, Daniel
Subject: [Discuss-gnuradio] Clarification on how timing/latency applies to a stream mux
Date: Fri, 28 Jun 2019 17:36:38 +0000

I have an application where I am multiplexing signals, and one of those signals requires time to poll a piece of equipment over a serial connection and package that information into what is sent.  I have an OOT module that contains the process to make the serial connection, and then in the work function it sends/receives the various commands and packages the information into an output stream.  The various signals are combined using the stream mux block.  Ideally the serial block would provide this input immediately before its turn in the stream mux block, i.e, I do not want it to run ahead and grab a large number of samples, such that there is latency between its requests over serial and when they are transmitted via the stream mux block.  Assume I do a good job and the serial block makes exactly the number of samples that are needed by the stream mux block for its turn.

 

I am curious how the timing of this is handled within gnuradio.  My understanding is that the work function of the serial block will provide samples per the backpressure from the stream mux block, but I do not know how exactly that should work out in this case.  Is it:

1)      If there is no forcing function to get the information from the serial port at a desired time, will the stream mux block start its work function when the samples run out from the block ahead of it in the stream mux?  In this case I think the finite time it takes to do the serial communication would cause underruns. 

OR

2)      Will the serial block run immediately upon the exhaustion of its output buffer, i.e., when its turn is complete in the stream mux block, then stop once it has the right number of samples for the next turn?  This would be a nearly maximum latency condition, but acceptable, since it would be deterministic.

 

If it is 2), if I put in an artificial delay inside of the serial block’s work function, I could lower the latency by pushing the start of the serial communication later within the time window before the serial block’s turn in the stream mux block.  This would have to be done carefully, because I could accidently push things into an underrun condition if that added delay is too long.

 

Comments? 

Thank you,

DL

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]