[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] GR-UHD features incoming
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] GR-UHD features incoming |
Date: |
Wed, 24 Jun 2015 09:14:03 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
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.
>>>
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>