Re: [Discuss-gnuradio] N210 MIMO packet TX time alignment when using message strobe

[Ludwig Stephan (CR/AEH4)]

Hi Martin,

thank you for your quick reply. I will try your suggestions.

As I wrote, we do not have a GPSDO for the PPS. Just to be clear: Do you want 
me to connect an external PPS to both USRPs and then change the python code of 
the model to set_time_unknown_pps() before the flow graph is executed?

Can I use the PPS only without the 10MHz reference or do I need both? 

Doesn't the USRP block do this by setting the sync parameter to "unknown 
PPS/sync" (cp. uhd_usrp_sink.xml)?

Ad 1) That would be perfect ;-)
Ad 2) No, we do not see any 'L's. There are two 'U's when starting, but that's 
OK.

I will also test the tx_time injection. But remember: All works fine with plain 
tagged streams, but not if the tagged stream is "triggered" by a message strobe 
block (see attached model or image). Do you have an idea what could interfere 
there at all?

Mit freundlichen Grüßen / Best regards

 Stephan Ludwig

Communication Technology (CR/AEH4) 
Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com
Tel. +49(711)811-8809 | Mobile +49(172)5630639 | Fax +49(711)811-5187845 | 
address@hidden

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000; 
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. 
Volkmar Denner, 
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus 
Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Dr. Werner Struth, Peter Tyroller


-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Martin Braun
Gesendet: Dienstag, 17. November 2015 18:29
An: address@hidden
Betreff: Re: [Discuss-gnuradio] N210 MIMO packet TX time alignment when using 
message strobe

Hi Stephan,

some prelims first: Can you manually sync the devices using
set_time_unknown_pps() before running the flow graph? I would like to rule out 
VITA time issues.

Also, your way of setting the time should work; it's the same code as if you 
were using tx_time tags. Although, that's something worth testing:
Can you inject tx_time tags onto the tagged streams with increasing time 
stamps? I.e., generate a tagged stream every 1 second, and increase the time 
stamp in 1s increments between bursts, instead of using your modification. This 
should rule out any simple bugs.

Some background: Assuming the VITA clocks in the two USRPs are in sync, and any 
time is written into the metadata, one of two things happens:

1) The packet arrives on time, i.e. before the VITA clock on the device reaches 
the time in the timestamp, and then the packets are transmitted at the same 
time, or
2) The packet arrives late -- in that case, UHD will eventually print an 'L', 
which I assume it doesn't in your case.

Cheers,
Martin

On 17.11.2015 07:56, Ludwig Stephan (CR/AEH4) wrote:
> Hello list,
> 
> I have a really tricky question that we have been working on during the last 
> few weeks. I am asking for any advice how to handle this issue:
> 
> In short: Samples input into the USRP sink do not appear at both hardware 
> outputs at the same time, but are set off by several sampling periods. 
> Meanwhile, we got the system synchronized when using tagged streams, but if 
> we use a message strobe as a periodic trigger, sync is lost again.
> 
> The long story:
> We are trying to synchronize samples (not carrier phase) in time at a 
> transmitter, which consists of 2 N210 (SBX daughter board, w/o GPSDO) 
> connected by a MIMO cable. We managed to synchronize the samples for 
> the transmission of a "packet_len"-tagged stream, which does not work 
> out-of-the-box, by adapting the source code of
> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_sink_
> impl.cc#L476 We changed the USRP_sink_impl.cpp file in such a way that 
> is reads the current URSP time right before transferring the data to UHD/USRP 
> and attach this time plus a buffer time as a tx_time tag.
> 
> We inserted the following lines after line 476 _metadata.time_spec = 
> get_time_now() + ::uhd::time_spec_t(0.15); _metadata.has_time_spec = 
> true; , where 0.15 [ms] is the time buffer which shall care for the 
> transmission latency, in order to have the hardware clock have a time smaller 
> the tag's value.
> 
> Question #1: Do you see any negative effects by this change?
> 
> This works for a simple transmission with tagged streams.
> 
> But: As soon as we switch to a transmission, which is triggered by a periodic 
> message strobe, the time alignment is lost. The setup is:
> message strobe (with PDU content) -> PDU to tagged stream (packet_len) 
> -> unpack K Bits (convert 1 Byte to 8 Bits) -> tagged stream multiply 
> length tag (by 8) -> UChart to Float -> Float to Complex (as real 
> part) -> both data inputs of USRP sink
> 
> By measuring both antenna RF output signals (modulated at 500 MHz carrier 
> frequency) with an oscilloscope, we determine a timing offset of some 12µs 
> for long (<500) packet lengthes, which is pretty much constant; but which 
> signal is ahead of the other seems to be random: one time antenna 1 is 12µs 
> ahead of antenna 2, the other time it is vice versa.
> 
> The timing offset depends on the the packet_len,if it is chosen small 
> (1..500); the 12µs seem to be an asymptote.
> Even more strange is that this delay is constant during a run of the model, 
> but changes (randomly?) from execution of the model to execution.
> 
> The timing offset is independent from the chosen sampling frequency (at least 
> for large packets).
> Since we intend to use 10 MHz of sampling frequency, 12µs offset 
> results in a shift of several samples
> 
> Today, there has been raised a similar but different issue by Will. 
> Basically, I am asking the same questions but from a different background. 
> Since I am not sure whether our topics have the same cause, I ask in a 
> separate thread.
> 
> We have an open ticket with NI/Ettus support, but they asked me to also post 
> this issue here, since there exists some overlap.
> 
> Question #2: Do you have any hint to help us solve this issue?
> 
> I noticed similar questions, which did not help us so far:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-June/
> 009842.html 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-April/009274.html,
>  which might be a hint to a work-around.
> 
> Any help is appreciated
> 
> Best regards,
> 
>  Stephan Ludwig
> 
> Robert Bosch GmbH
> Communication Technology (CR/AEH4)
> Renningen
> 70465 Stuttgart
> GERMANY
> www.bosch.com
> 
> Tel. +49(711)811-8809
> Fax +49(711)811-5187845
> Mobile +49(172)5630639
> address@hidden
> 
> Registered Office: Stuttgart, Registration Court: Amtsgericht 
> Stuttgart, HRB 14000; Chairman of the Supervisory Board: Franz 
> Fehrenbach; Managing Directors: Dr. Volkmar Denner, Dr. Stefan 
> Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus 
> Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Dr. Werner 
> Struth, Peter Tyroller
> 
> 
> 
> _______________________________________________
> 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

bursttx_tag.grc
Description: bursttx_tag.grc

bursttx_tag.grc.png
Description: bursttx_tag.grc.png