I try to get gunradio3.3.0 launched on ubuntu 10.04, but the module
gr-comedi can not pass building. when type ./configure, the result as
follows:
checking for COMEDI… no
gr-comedi requires comedilib, not found.
Not building component gr-comedi.
I think I’m running into some scheduler issues in GNU Radio that I don’t
really understand. I’ve been working on running GNU Radio blocks on the
Beagleboard’s DSP by writing new DSP specific custom signal processing
blocks When I run simple QA python test scripts everything works fine.
If I start incorporating the block into more complex GNU Radio
flowgraphs, the work method is occassionally not called. When I run my
code in debug mode I can see the DSP being initialized and parameters
being passed to it but once the flowgraph starts everthing hangs when I
comment the DSP block out of the graph everything works fine.
Just because I’m not sure what else to do, I added
gr_enable_realtime_scheduling(). With this the “Work” method would
occassionally get called. I’m using an interpolator class template and
from what I see, the “work” method calls “general_work” and the
consume_each() method so I guess I don’t have to dabble with that.
The other thing, my code blocks during each function call to the DSP,
would this somehow affect the scheduler? I’m guessing not since not
even the debug printf statements appear at the beginning are printed to
the screen.
I’m not quite sure how to debug the schdeuler calls and such related
topics, any help would be greatly appreciated.
al
On Thu, Jul 22, 2010 at 10:18:41PM -0400, [email protected] wrote:
I think I’m running into some scheduler issues in GNU Radio that I
don’t really understand. I’ve been working on running GNU Radio
blocks on the Beagleboard’s DSP by writing new DSP specific custom
signal processing blocks When I run simple QA python test scripts
everything works fine.
What version of GNU Radio?
If I start incorporating the block into more
complex GNU Radio flowgraphs, the work method is occassionally not
called.
Are you running out of CPU cycles?
When I run my code in debug mode I can see the DSP being
initialized and parameters being passed to it but once the flowgraph
starts everthing hangs when I comment the DSP block out of the graph
everything works fine.
Sounds like something’s wrong with your block 
Just because I’m not sure what else to do, I added
gr_enable_realtime_scheduling(). With this the “Work” method would
occassionally get called. I’m using an interpolator class template
and from what I see, the “work” method calls “general_work” and the
consume_each() method so I guess I don’t have to dabble with that.
The other thing, my code blocks during each function call to the
DSP, would this somehow affect the scheduler?
If you’re using the single-threaded-scheduler, you MAY NOT block in
your work function. It should work OK when using the thread-per-block
scheduler, assuming that your code isn’t stepping on memory that it
doesn’t own, or other types of problems.
Is the DSP code that you’re calling thread-safe? Or does it have some
assumptions built in such as it’s only ever called by the same thread,
it’s not reentrant, etc?
I’m guessing not since not even the debug printf statements appear
at the beginning are printed to the screen.
I’m not quite sure how to debug the schdeuler calls and such related
topics, any help would be greatly appreciated.
Try writing more comprehensive test cases for your block.
What is its io_signature? How many samples do your test cases run
through it? Try running at least 32K samples through your block.
My first guess would be that your block is trashing memory that
doesn’t belong to it. Perhaps it’s writing beyond the end of some
buffer? If you’ve derived from gr_sync_interpolator, be sure that
the main loop in work is executed noutput_items/N times, where N is your
interpolation factor. Each iteration of the loop should produce N
output items. What value are you returning from work? Is it less
than or equal to noutput_items? If not, fix this.
Does the compiler produce ANY WARNINGS when compiling your block?
If so, MAKE THEM ALL GO AWAY.
If you are passing pointers to the block’s input or output buffers to
your DSP code, know that they are ONLY VALID for the duration of the
call to work. If the DSP thinks it can read or write from them
outside of that temporal window, that would definitely cause a problem.
Eric
Is anyone using a Gigabit Ethernet USB dongle to communicate with a
USRP2? If so, which one?
Thank you,
Harley Myler
CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.
As far as I know that module is no longer supported and it’s not
needed for running GNU Radio
Alex
2010/7/23 ÁõȨ [email protected]:
1- GNU Radio 3.2.1
2- I’m not running out of CPU cycles
3- I’ve been dissecting the filtering blocks in GNU Radio in hopes of
doing the same on the DSP. It’s my understanding that the filter can
process (noutput_items + ntaps) for each iteration. For DSP filtering,
I’ve tried just copying “noutput_items” to the DSP, zero pad in the end
by “ntaps” and write back “noutput” items to GNU Radio and I also tried
passing (noutput_items + ntaps) to the DSP and filter noutput_items
long. My results match with the GNU Radio GPP implementation when I
pass (nouput_items + ntaps) inputs so I’m assuming that this is correct.
4- I’m not specifying the scheduler type so I’m assuming that the
thread-per-block scheduler is used. Even when I specify the scheduler
“GR_SCHEDULER = STS ./mygraph.ph” and “GR_SCHEDULER = TPB ./mygraph.ph”
the behavior seems unaffected so I decided to leave the standard
scheduler. It’s possible that environmental variable was not being
passed porperly I just couldn’t figure out how to change the scheduler
directly from my flowgraph even if that is possible.
5- Regarding if the code is thread safe, with my code there can only be
one call to the DSP at a time so two threads cannot call the DSP at the
same time but all the DSP handlers are static variables so they don’t
have to be called by the same exact thread everytime. Though I have all
my DSP code in a static library outside of GNU Radio.
On Jul 23, 2010, at 9:48 AM, Charles H. wrote:
Harley
USRP2 uses Gigabit Ethernet because USB did not have enough bandwidth.
If you use a usb dongle, you are killing its purpose.
If you would like to use it through USB, I guess using a USRP 1 is a better idea.
If you do get it to work on a dongle, which I doubt will be possible, you will not be able to use the USRP full capacity, and still be limited to higher decimation values.Charles
Yes, I know.
Harley
CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.
Apparently the issue was some USB block sizing that was happening in the
flowgraph, a flowgraph that someone in my research lab provided, when I
enabled scheduler logging as per Eric’s suggestion I found that the
scheduler wasn’t calling the work function at all. When I enabled
logging from the “gr_flat_flowgraph.cc” file I found that the flowgraph
was dying as the buffer were being allocated. Anyways, the code works
now but for the future I will do more testing with the USB block sizes
with the DSP in the loop to be understand this issue.
thanks again for your help Eric.
al fayez
On Thu, Jul 22, 2010 at 07:40:29PM -0700, Eric B. wrote:
On Thu, Jul 22, 2010 at 10:18:41PM -0400, [email protected] wrote:
I think I’m running into some scheduler issues in GNU Radio that I
don’t really understand. I’ve been working on running GNU Radio
blocks on the Beagleboard’s DSP by writing new DSP specific custom
signal processing blocks When I run simple QA python test scripts
everything works fine.
Sorry, I should have mentioned this earlier.
Try enabling the scheduler logging by
#define ENABLE_LOGGING 1
In gr_block_executor.cc, line 38.
This will create a separate ascii log file for each block.
They’ll be created in the current directory and have names
“sst-%3d.log”, where the numbers are unique. The log files contain
the name of the block as the first line.
Good luck, and let us know what you find out!
Eric
On Thu, Jul 29, 2010 at 12:06:19PM -0400, [email protected] wrote:
thanks again for your help Eric.
You’re welcome! Thanks for letting us know what you found.
Eric