[Top][All Lists]

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

[Discuss-gnuradio] Could This Be A Speed Problem? How Can I Make It Fast

From: P C
Subject: [Discuss-gnuradio] Could This Be A Speed Problem? How Can I Make It Faster
Date: Thu, 16 May 2019 14:13:43 -0500
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

I have what I think is a problem with processing speed.
I want to run the attached flow graph on my Raspberry Pi 3B.
It captures a serial bit stream.

The lower File Sink is a FIFO type file that is read and processed in real time (I hope) by the Python script decoder.py (attached). Actually decoder.py is a dummed down script I am using to isolate the problem.  The script I hope to use is ~100 lines long.

The upper File Sink just writes a file that is processed off line by a different script.

Note that in decoder.py there is a variable delay.  If I make delay small, like 0 or 1, I believe the flow graph runs successfully.  But if I make delay larger things start to fall apart.  By that I mean bits are dropped.  Also the Time Sink falls behind. I test that by manually changing the bit stream.  What I see is, if delay is small, the Time Sink displays the changed bit stream immediately.   If delay is 2 or 3 the change to the bit stream is delayed 5 or 6 seconds.

Also, in the larger  delay case, the file Capture.sec is also missing bits.  It seems that if decoder isn't taking bytes out of the FIFO fast enough, the "backup" reflects back to the output of the Multiply Constant.   I separated the paths to the File Sinks hoping that I could avoid this effect but no luck.

So, I guess my questions are:
(1) Is my analysis correct?
(2) Is it reasonable that just one or two times through that "while" loop could be such a problem? (3) Would it be useful to rewrite the processing script as a C program?  Keeping in mind that the program I really want to use is 10 or 20 times longer. (4) Am I doing things in a way that slows things down and could be fixed by some manipulation?
(5) Shouldn't a FIFO be able to "absorb" the data flow?
(6) Would using something like ZMQ get around this problem?



Attachment: First.grc
Description: Text Data

Attachment: decoder.py
Description: Text document

reply via email to

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