discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GR-UHD features incoming


From: Piotr Krysik
Subject: Re: [Discuss-gnuradio] GR-UHD features incoming
Date: Wed, 24 Jun 2015 19:50:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

Hi Martin,

When the command carried by message is executed immediately after
reception by USRP the situation seems to be similar to tune request
invoked by the user through gui. Or is there something that I overlooked?

Things get more complicated when command has "time" in the future at
which it should be executed. I don't see easy way to identify uhd
metadata that is result of execution of given command so it could be
turned into a stream tag.

Best Regards,
Piotr

W dniu 24.06.2015 o 18:14, Martin Braun pisze:
> Piotr,
>
> not intentional -- this was indeed an oversight. I'll add an issue.
> However, it's not trivial to change; when doing message-based retuning,
> there's no clear way of knowing which sample to tag.
>
> M
>
> On 24.06.2015 04:33, Piotr Krysik wrote:
>> Hi all,
>>
>> After reading the code of usrp_source_impl I've found out that there are
>> separate methods for tune requests invoked from gui and by message
>> interface.
>>
>> For gui:
>>     ::uhd::tune_result_t
>>     usrp_source_impl::set_center_freq(const ::uhd::tune_request_t
>> tune_request,
>>                                       size_t chan)
>>     {
>> ...
>>       _tag_now = true;
>> ...
>>     }
>>
>> For messages:
>>     SET_CENTER_FREQ_FROM_INTERNALS(usrp_source_impl, set_rx_freq);
>>
>> The second one doesn't set _tag_now - therefore no tags are added.
>> Everything suggests that this behaviour is intentional.
>> But what is the rationale? Without this tag I'll have to keep track of
>> frequency changes that are made and add tags myself as they are needed
>> to trigger events downstream.
>>
>> Would it be possible to leave for the user to decide if he wants to
>> receive tags or not?
>>
>> Best Regards,
>> Piotr Krysik
>>
>>
>> W dniu 24.06.2015 o 12:01, Piotr Krysik pisze:
>>> Hi Martin,
>>>
>>> I'm trying to make use of the new message interface. I'm able to set
>>> center frequency and other parameters with use of it which is great as
>>> now I'm able to make for example a application that scans spectrum
>>> without stopping the flowgraph.
>>>
>>> However I expected that after USRP switch frequency because it received
>>> a command a new stream tag would be added to the signal at the moment of
>>> switching (like it happens when for example central frequency is
>>> switched with use of gui widgets). No tag is added though. Is this
>>> intended behaviour?
>>>
>>> Best Regards,
>>> Piotr Krysik
>>>
>>> W dniu 06.05.2015 o 19:35, Martin Braun pisze:
>>>> The big change for the moment is the enhanced message interface. With
>>>> more blocks using messages for commands (not just data), we're trying to
>>>> standardize how blocks receive messages. If you build the manual
>>>> yourself, you'll see the changes added in
>>>> https://github.com/mbr0wn/gnuradio/commit/72e0c237e06e5214eb2706bd4ac732cef068161c
>>>> to document how we'd like these command interfaces to look like.
>>>>
>>>> UHD already had it's own, home-grown message command interface. With
>>>> this change, it has been adapted to comply with how command messages
>>>> should look like.
>>>> At the same time, a lot of new commands were added. You can now change
>>>> gain, antenna, DSP frequency, LO offset, command times, analog bandwidth
>>>> (where applicable) and sampling rate through messages.
>>>>
>>>> This offers tons of cool new options. Imagine you have a blind OFDM
>>>> receiver, which first estimates the OFDM parameters (center frequency,
>>>> bandwidth, sampling rate) before attempting to blind-demodulate. You can
>>>> have a downstream block change all of these parameters[1] in a kind of
>>>> control loop[2] until they match, then demodulate -- all from the same
>>>> flow graph, just using GNU Radio blocks.
>>>>
>>>>
>




reply via email to

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