This has less to do with GNU Radio and more to do with real-time programming.
A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed.[5] Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline
Things that affect order of execution include:
- The operating system scheduler
- "Real-time" extensions are present in most Linux distros, but require explicit enabling; more common scheduling strategies include "round robin"; for precise scheduling, you would need a pre-emptive strategy.
- You may need to pin your process to a particular CPU (core)
- Note that (depending on your hardware) a "sleep" function, regardless of the requested delay, will not return in less that 50us or so (this one surprised us recently).
- "Real-time" extensions are present in most Linux distros, but require explicit enabling; more common scheduling strategies include "round robin"; for precise scheduling, you would need a pre-emptive strategy.
- Your hardware
- in order for things to execute in parallel, there must be parallel execution paths. Most modern CPUs have multiple cores and threads within cores, so unless you are taxing your CPU (possible) there should be compute paths available
- Control of the radios is via some hardware port. If the two devices use the same hardware (e.g., USB hub), there will be some serialization
- in order for things to execute in parallel, there must be parallel execution paths. Most modern CPUs have multiple cores and threads within cores, so unless you are taxing your CPU (possible) there should be compute paths available
Simply put, real-time execution constraints are difficult to satisfy, and I would be surprised if a python GNU Radio application could achieve them. Maybe my brain is frozen in the past and it is very doable now, but that hasn't been my experience.
---
Jim Melton
Hello Marcus,
The boards I have are b200 and b210.
I want to change the frequency of 2 SDRs at the same time. Even if I write the codes in parallel, the frequency of one of the SDRs changes first, and then the frequency of the other one changes. I want 2 of them to run in parallel.
I looked at the resources you shared and the examples on GitHub. Based on these, I wrote the following code. But I can't say it worked. I guess I couldn't get it to work.
tune_rx = pmt.make_dict()
tune_rx = pmt.dict_add(tune_rx, pmt.intern("freq"), pmt.from_double(center_freq))
self.blocks_message_strobe_0 = blocks.message_strobe(tune_rx, 20)
self.msg_connect((self.blocks_message_strobe_0, "strobe"), (self.uhd_usrp_source_0, "command"))
self.msg_connect((self.blocks_message_strobe_0, "strobe"), (self.uhd_usrp_sink_0, "command"))
The hopped frequencies vary, usually in 100MHz steps, and are higher than my master clock rate.
Sent from Mail for Windows
No comments:
Post a Comment