|
From: | Ludwig Stephan (CR/AEH4) |
Subject: | Re: [Discuss-gnuradio] USRP Latency. |
Date: | Tue, 17 Nov 2015 08:37:39 +0000 |
Hi Will, we have a similar problem with our set-up, and hence I can somehow confirm your findings, although we do not have a solution/explanation (yet), either. We have a 2x2 MIMO N210 system (with MIMO cable and w/o GPSDO) in burst-mode (PDU messages from message strobe are issued every 500ms, converted into tagged stream
and transmitted identically on both Tx antennae) and experience an offset of some 12µs between signals of each antenna. Internally, we take the current time from the USRPs directly before we transmit, then add some buffer time and use this as a tx_time tag’s
value. Since we do not rely on the original rx_time tag, we (and maybe you as well) can - at least - rule out this as a source. In our case the offset changes between the antennae, i.e. one time ant1 is 12µs ahead, the other time ant2 is 12µs ahead. So it seems to be not constant :-( But
the 12µs are pretty constant and independent from the chosen sampling frequency. For the file: Up to now, we have not been able to synchronize samples for MIMO burst transmission with message strobes, while it synchronizes out of the box for
continuous streams. Unfortunately, we haven’t got an explanation, either. But I am about to contact Ettus support for that. Mit freundlichen Grüßen / Best regards
Von: discuss-gnuradio-bounces+address@hidden [mailto:discuss-gnuradio-bounces+address@hidden
Im Auftrag von Will Thompson Hi I have question about the latency of transmissions in the N210 USPR.
A bit of back ground in my system: I have three nodes. One (Node1) that periodically transmits a signal.
The one of the other nodes (Node2) tries to synchronise its transmission with that of Node 1.
Node3 is simply used to record the transmissions and check that they align.
When Node2 starts up, it saves the rx_time of the initial stream item Tag from the USRP source.
It then listens for the periodic transmission from Node1. Node2 then estimates the timing offset of Node1’s transmission and starts to transmits its signal that should be synchronised with Node1’s.
It adds a tx_time tag to its burst which is based on the rx_time tag of its first arriving sample and a multiple of the sample time and then number of sample bins needed to align with Node1’s transmissions. (the system is working with a sample rate of 1Ms, centre frequency of 2.48GHz, and using N210 with XCVR2450) The issue I’m having is that the actual transmission of Node2 is about 26us behind that of Node1, and I’m wondering why this might be… is this a predictable delay, or might it change with other systems? Possible issues might be that it is the delay between the Tx burst being released from the buffers and actually being transmitted, but I feel that 26us is quite a long time really.
Or it might be from the original rx_time tag somehow.
Any advice or insight into this would be greatly appreciated.
Thanks. Will -- William Thompson Ph.D. Research Engineer Toshiba Research Europe Limited 32 Queen Square, Bristol, BS1 4ND, UK Tel: +44 (0) 117 906 0734
This email has been scanned for email related threats and delivered safely by Mimecast. |
[Prev in Thread] | Current Thread | [Next in Thread] |