Hi Doug,
> What about adding an lo_locked metadata tag to the stream of samples?
>
> You could send lo_locked value=False on the last sample before LO unlocks,
> and lo_locked value=True for first sample after LO locks. That should be (?)
> simple to implement and would be equally as useful.
The problem is that the architecture doesn't really allow this. You have
to imagine it like this:
There's two (ok, more than that, but basically) two things going through
the RX-side Motherboard/daughterboard connector:
1. Analog complex baseband, which gets converted to digital samples at
the physical sampling rate by the motherboard's ADC (typically 100+
MS/s), and
2. serial control lines.
Both the sample bit lines from the ADC as well as the serial control
lines end up in the FPGA. Now, UHD has a fast track on which it pushes
all the samples around, through the various DSP stages, and through your
Gigabit interface (on N2x0, for example). That's possible because
samples are just that - samples. No back and forth communication, just
FIFOs in one direction and an on-FPGA bus that configures the whole
thing and makes sure things such as timed commands are executed on time.
The daughterboards do all the analog magic -- using programmable gain
amplifiers, programmable LO synthesizers, attenuators etc.
To control these, the control lines are there. These basically are just
"extended" serial ports of your PC. UHD knows how, for example, to
configure a specific LO synthesizer to give you the desired frequency,
and it just instructs the USRP to do so ("Write this over your serial
control port #0", "Read the thing you get when asking for register 0x0F
on port #1", these kind of things). These transfers are a lot slower,
though they can be initiated at a given time (thanks to timed commands,
again), than the sample clock.
Now, when you ask UHD "what is the lo_locked sensor value?", UHD
translates that to an read instruction to the LO synthesizer, and
translates the answer it gets from the USRP back to something like
true/false. Typically, these requests take quite some time. Also, your
chip has no way of guessing early whether the LO is locked or not -- it
observes stability, and the speed it can detect whether the LO is locked
must be inverse to the quality of that observation.
Thus, getting the answer from the synthesizer chip would typically
longer than justifiable here -- you'd end up throwing away less samples
if you did not poll the chip for that info and just threw away a fixed
amount of samples after every rx_freq tag. Also, polling the sensor
might get in the way of "normal" operation, because it'd occupy the
serial line.
Greetings,
Marcus
On 04/01/2015 07:49 PM, Anderson, Douglas J. wrote:
> Martin,
>
> I think we could have the same effect with a much simpler solution:
>
> What about adding an lo_locked metadata tag to the stream of samples?
>
> You could send lo_locked value=False on the last sample before LO unlocks,
> and lo_locked value=True for first sample after LO locks. That should be (?)
> simple to implement and would be equally as useful.
>
> Otherwise, determining the first usable sample, as you said, "depends on
> pretty much everything", and that's a lot to push down on the end user.
>
> -Doug
>
> ________________________________________
> From: discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org
> [discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org] on behalf of
> Martin Braun [martin.br...@ettus.com]
> Sent: Wednesday, April 01, 2015 11:30 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked
>
> On 31.03.2015 14:25, Anderson, Douglas J. wrote:
>> Marcus,
>>
>> That makes sense, I hadn't thought of the DSP tuning issue, though I
>> think it would be infinitely more useful to make the stream tagging
>> logic aware of LO/DSP tuning and tag the first usable block in either
>> case. Slightly more involved than I assumed though.
> That is correct. It depends on pretty much everything, at the very least
> which exact device + d'board combo you're using.
>
> Cheers,
> M
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
