[USRP-users] Filling gaps resulting from overruns, issue with (probably) power saving in USRP B210

Piotr Krysik perper at o2.pl
Tue Mar 29 09:02:05 EDT 2016


W dniu 26.03.2016 o 20:18, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I'm working on a GNU Radio block that uses UHD source meta-data (rx_rate
> and rx_time tags) in order to fill gaps in transmission from USRPS.
> It will be intended to be used in two steps:
> 1st - the data from USRP is stored to a file with meta-data (all
> transmission interrupts like buffer overruns are reflected in the
> meta-data),
> 2nd - file with meta-data is turned to a single file with zeros inserted
> in the gaps resulting from interrupted transmission (number of zeros
> computed based on the metadata).
>
> The resulting file should be like a file recorded without any interrupts
> but with zeroed some blocks of samples. This have great advantage when
> for example there are two recordings done in different locations with
> USRP synchronized with GPS. The from different locations is then
> processed coherently. But... currently a first transmission interruption
> means that all data after that moment is unusable as the synchronization
> between recordings is lost. Even with single recording recording it is
> much better to have continuous file instead of shredded one (you can
> easily read it with any software that reads binary files, you can easily
> compute time at which every sample is located).
>
> The feature that I want to implement is needed especially with USRPs
> B2x0 where there is a strange problem with overruns when data is
> streamed to a disk (even for low sample-rates like 5MS/s with single
> channel).
>
> Currently I've implemented a block computing number of zeros that need
> to be inserted for each rx_time tag that results from transmission
> interruption. I recorded test data with USRP B210. Recorded was GSM
> signal, the sample rate was fs=3250000/3 (each GSM timeslot has 625
> samples in this case) and master clock rate was 2*fs. I was stunned to
> find out that there are some gaps with length that is not integer
> multiply of sample period - some of them end in the middle between two
> samples.
>
> You can check this by downloading:
> git clone https://github.com/ptrkrysik/gr-tagtools.git
>
> and running the program (to run it you need GNU Radio):
> cd ./gr-tagtools/examples/
> python debug.py
>
> The result is shown below:
> Found a gap in the data at offset: 145577  with length: 176159.51111 
> [samps] (non-integer number of samples - the 0.0111 is probably there
> due to limited precision)
> Found a gap in the data at offset: 256406  with length: 117081.01177 
> [samps] (integer number of samples)
> Found a gap in the data at offset: 393807  with length: 102807.503405 
> [samps] (non-integer number of samples)
> Found a gap in the data at offset: 604792  with length: 106977.000579 
> [samps] (integer number of samples)
> Found a gap in the data at offset: 766721  with length: 110671.523902 
> [samps] (non-integer number of samples)
> Found a gap in the data at offset: 971574  with length: 100338.996294 
> [samps] (integer number of samples)
> Found a gap in the data at offset: 1147811  with length: 117452.046175 
> [samps] (integer number of samples)
> ...
>
>
> My hypothesis is following:
> There is some strange mechanism in the USRP B210 (I haven't checked
> other devices in this regard yet) that turns off the receiver chain on
> each buffer overrun. My test data was recorded for master clock rate
> that is 2 times the output sampling frequency. Then if DDC in the FPGA
> is fed by a random sample - for one transmission interruption odd and
> even for another one - it might be that after decimation of 2 times the
> signal at the output is sometimes shifted by some number of samples and
> half in relation to the first sample.
>
> Aside there are other negative effects of such action like: that it
> takes some time to turn on the RX amplifier again (you can see that in
> the attached picture) and if the rx oscillator is restarted each time
> then phase coherency is lost on each overrun (that would be a disaster -
> I haven't checked this yet if this is the case).
>
> The questions:
> 1. Is this possible to disable the mechanism that turnings the receiving
> chain on transmission interruptions? In most cases I can think of this
> mechanism is strongly undesirable (actually only advantage I can find is
> saving of some marginal power).
> 2. Where is this mechanism implemented in the UHD code?
> 3. Is this possible that this mechanism is behind what I observe with
> recording restarting in the middle between two samples after buffer overrun?
>
> Thanks for reading my quite long post to this point and thanks in
> advance for any help :).
>
> Best Regards,
> Piotr Krysik
>
Hi all,

Nobody is answering so maybe I'll ask a shorter question:

There is a mechanism in the B210 FPGA that is turning off receiving
chain when nothing is streamed to the PC. It is also turning off the
receiving chain on any buffer overrun in the USRP and this isn't a
feature but a bug.

Whenever someone wants to receive continuous stream of samples it will
cause problems by altering:
- amplitude - because of rx amplifier switching on that takes some time,
- phase - by causing delay that is not integer multiply of sample
period, I don't know yet if RX oscillator is also retuned - that would
randomly change phase on each buffer overrun.

How to disable that mechanism for the whole duration of the streaming?
Where it is implemented in the FPGA code?

Best Regards,
Piotr Krysik




More information about the USRP-users mailing list