Hello Steven,

The UHD blocks in GNU Radio do support time commands so the question is how
to expose the functionality to GNU Radio Companion.
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_block_impl.h#L62
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_block_impl.h#L78

I haven't yet had much need to look at the Control Port on the UHD blocks.
The code looks quite simple though so adding the plumbing for set and get
device time and to read the sensor should be simple.
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_block_impl.h#L112
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_block_impl.cc#L608

An option available right now is to add the commands needed to synchronize
the USRP time with GPS to a python block in GRC. I haven't done that
before, but often use them for frequency hopping and other non-streaming
behaviors.

Derek

On Mon, May 2, 2016 at 7:35 PM, Steven Knudsen via USRP-users <
usrp-users@lists.ettus.com> wrote:

Hello Steven, hello Derek,

I'd just wanted to add that the "usual" way to communicate the time when
something should be happening (i.e. what gets translated to
"set_command_time(timespec); set_{??_frequency, _bandwidth, …}(value);
clear_command_time()" in the USRP blocks) is to either use specific
stream tags, or (and that might be what you're looking for) commands
sent via message port [1]. Basically, you can build a PMT dictionary
containing commands and the time they will apply, and send that in
through a message port. You can build a sender for those with e.g. a
message strobe (or a minimal self-written python block – this might
really be a more elegant way of doing this, assuming you have a bit of
"business logic" needing to influence that).

The other problem is how to set the device time according to the proper
procedure outlined in [2]. You can do that by modifying the Python code
that GRC produces to include that algorithm, but: that's not going to be
a great solution, seeing as it will get overwritten by the next
modification of your flow graph.

So yeah, on one hand, we don't want to bloat neither the UHD nor the
gr-uhd API, but on the other, this is really not working for pure-GRC
workflows.

Best regards,
Marcus

[1] http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
[2] http://files.ettus.com/manual/page_gpsdo_x3x0.html#Setting
On 03.05.2016 07:26, Derek Kozel via USRP-users wrote:

Hello Marcus and Derek.

Thanks very much for your comments.

Derek provided links to the areas I had looked at and that got me to thinking along the lines I described, though perhaps not as clearly as I should have.

Marcus, I do understand the set_command_time + set_xxx pattern and for the set_xxx commands defined, that works great. What I mentioned was pretty easy to implement and verify was the kind of logic you referred to in [2], which is one the links I had found and upon which I based my command line UHD-based program.

BTW, the use of Python in a top block may be an okay way, but it feels wrong for the reasons we state and I am not sure about latency issues. Besides, being more of a C/C++ person and anticipating that I may want to move some of my logic into kernel modules, I can’t really use the top block approach...

My problem is that I am developing a TDMA system and would like to tie slot number and other attributes to the Unix Epoch Time, so using a common, absolute time based on GNSS time makes sense (actually, a project I worked on for the past 6 years is based on the same premise, so perhaps I’m biased).

Someone may eventually suggest that I just wait until a USRP source gives me time for a received sample and work backwards to align that with my GR runtime platform (GRRP) time (which is tied to GPS), but that feels and sounds like more work than should be necessary, and problematic in that I am not sure how to account for latencies, both existing and perhaps induced by future GR changes.

What I think I will try is to

1. add more support to the command message input for the “missing” set_xxx commands from the UHD
2. add a second output message port to provide results from set_xxx and get_xxx commands

The second point is the part that needs careful consideration in the context of adding bloat, complexity, etc. One point is that it seems to fix the need to add external python code to a top block to get sensor results and other things. Of course, it has to be done right to reflect the architectural and other intents of the UHD and GR APIs.

Marcus touches on a third path I have considered and that’s to just veer away from GRC. I have a mandate to use GR and GRC and am a bit reluctant to recommend against it. I think there are definite advantages in using GRC when handing a project over to other people, especially if they are not actual developers (e.g., researcher comfortable with MATLAB and not much else).

I think I’ll take a crack at 1) and 2) above. As I see it, the main issue is to devise a way to link an input message with a matching output message. Two thoughts come to mind; a) just form proper output messages and let any receiving block choose to consume them or not, or b) add something like response UUID to input command messages that is associated with any output messages. Hmmmm...

Anyway, thanks for your consideration of the question and, of course, any further thoughts.

steven

Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

All the wires are cut, my friends
Live beyond the severed ends.  Louis MacNeice

Hello Steven,

On 03.05.2016 16:53, Steven Knudsen wrote:

Ah, the only thing latency-critical here is that the sleep(0.2) doesn't
take longer than (1.0s - roundtrip). I'm absolutely confident this won't
be a problem in practice.

Sorry, I don't understand – UHD is userland software through and
through, and I don't think you'd want to call userland functionality
from kernel?

Totally agree! That's why we have those GPSDOs, and that's why we have
timed commands: so that the latency-critical stuff doesn't happen on
your CPU, but is executed just in time in the FPGA of the USRP. Timed
commands really work by telling the FPGA what you want to do when
before, and the FPGA then latching those settings exactly at the clock
edge where they should be happening.

Exactly. The USRP should be in charge of knowing the time – after all,
it's the only device with absolutely deterministic latency with respect
to the radio frontend.

What do you need, specifically? And: as message handler, or as methods
to the USRP blocks?

Yeah, that's something the GNU Radio project thinks about once in a
while: You'd be building an RPC framework. I can see how controlport
came into this discussion.
Now, a bit of a fair warning: the return values of these are most of the
time (haven't gone through all of them now, but I think it's all of
them) meaningless when you use timed commands, as the host can't know
which setting is valid the moment you ask. UHD, for most of these
settings, just has a host-side cache. So you're not really reading the
LO frequency from the USRP (that's not possible at all technically for
most tuner ICs), you're just asking for the last set value – whether
that might be already in effect is a question that the host PC can't
answer (because only the FPGA knows when exactly the timed command is
starting to apply).

Yes, giving someone a Python Application and an accompanying GRC flow
graph is probably a bad idea if just re-generating the python code from
GRC is going to break the application.

Yes, RPC :) ! As Derek suggested, control port might be the way to go.

You're absolutely welcome! Discussions like these are usually
enlightening for all sides :)

Best regards,
Marcus

Thanks for the quick reply. I’ll risk one more level of inline comments below… I’m probably at the point where it’s time to just get busy and try stuff, then report back.

Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend. Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für nichtig erklären, im Recht, denn es ist noch nichts geschehen. - Franz Kafka

Guess the onus is on me to test your confidence :-)

It would probably be the other way around, the userland code may rely on kernel modules.

The runtime platform in my case is used to control other RF hardware and functions and is very much the main entity. Thus, the USRP time must be synchronized, but is not the master. The runtime platform can have FPGA and other hardware resources that may be accessed via kernel modules (at least controlled by KMs), and I am anticipating using the API to those KMs in my GR application (possibly, but best to plan ahead). Anyway, I am not sure that it’s totally relevant here. Bottom line, GNSS time is known on the runtime platform and must be set on the USRP, preferably without resorting to “volatile python” in the top block for many reasons including the annoying loss of code on block re-gen.

That’s the part I like :-)

See above regarding runtime platform; the assertion about the USRP is not necessarily true in a non-USRP centric application. Imagine, for example, if a USRP-based radio without a GNSS reference could acquire time over-the-air (OTA). If the acquired time was set at the USRP time and it turned out to be incorrect (there are many reasons including a malicious attack on time), the downstream systems may be compromised. Without getting into details I can’t discuss, I guess I’m saying there are reasons to have a different time master in some scenarios.

Message handler, I believe. The support for time set/get (pps) commands is present in the usrp_block_impl.

Your warning is what I am afraid of, so I’m still digesting what the current implementation does and how one would deal with the uncertainty. It may well be that this is my own red herring (i.e., I don’t need it after the code integration/debug phase), so I need to think.