[USRP-users] feedback from a USRP message

Derek Kozel derek.kozel at ettus.com
Mon Oct 30 13:27:24 EDT 2017


The error checking of the parameter range will happen inside of UHD rather
than in the GNU Radio wrapper. The existing check is only for the type of
the parameter, in the gain case a numerical value is supplied so it passes
the check.

The first command will result in a tune to 2.4 GHz.
The second command will result in maximum gain as UHD will coerce the value
by limiting it to the valid range. The value actually set can be read using
the API, but isn't readily available in GRC, you'd have to use a function
probe or custom python block to call it.

The third case should be caught and logged as an error, it looks like a
check is missing from this `if` statement. There might be a good reason,
but that's something I'll check on. In the meantime you can try adding a
GR_LOG_ALERT or ERROR statement to this block.
https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a23978774d3b/gr-uhd/lib/usrp_block_impl.cc#L558

Derek

On Mon, Oct 30, 2017 at 4:18 PM, Jason Matusiak <
jason at gardettoengineering.com> wrote:

> Thanks Derek, that last link helped get me in the right direction.  I set
> both to debug level (to try to get as much output as I can.  What bothers
> me is that I get this message for sending what I feel like is a valid
> command:
> gr::debug :DEBUG: gr uhd usrp source0 - Processing command message ((chan
> . 0) (freq . 2400000000))
>
> but I get the same message for what should be a bad command (and i feel
> like should probably print that out):
> gr::debug :DEBUG: gr uhd usrp source0 - Processing command message ((chan
> . 0) (gain . 2400000000))
>
> or even a total made up key:
> gr::debug :DEBUG: gr uhd usrp source0 - Processing command message ((chan
> . 0) (badData . 2400000000))
>
> Am I giving too much credit to how the USRP error checks messages?
>
>
>
>
> On 10/30/2017 11:30 AM, Derek Kozel wrote:
>
> Hi Jason,
>
> The command message handling in the USRP source in GNU Radio is a bit
> interesting. The command may contain many pairs of key->value, most of
> which end up in a call to their own handler. There is a debug message
> printed for each of these handlers if you have GNU Radio debug messages
> enabled.
>
> List of supported keys
> https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a2
> 3978774d3b/gr-uhd/lib/usrp_block_impl.cc#L30
>
> There is also error reporting if the command type isn't correct.
> https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a2
> 3978774d3b/gr-uhd/lib/usrp_block_impl.cc#L538
>
> If you aren't seeing the debug messages then try changing your GNU Radio
> logging settings.
> https://gnuradio.org/doc/doxygen/page_logger.html
>
> Regards,
> Derek
>
> On Mon, Oct 30, 2017 at 2:54 PM, Jason Matusiak via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> Is there anyway to get feedback from a sent message command to a USRP
>> source in GR?  I was sending some commands and was *pretty* sure I was
>> doing it right, but to know for sure I sent a bogus command, and it didn't
>> complain (I expected to see something on the terminal).  Is there anyway to
>> turn on some sort of print-out to see that it accepted the commands I am
>> sending (like changing freqs)?  Or at the very least see when a bad command
>> was sent?
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171030/4b4ba8f0/attachment-0002.html>


More information about the USRP-users mailing list