|
| From: | Will Thompson |
| Subject: | Re: [Discuss-gnuradio] USRP Latency. |
| Date: | Fri, 20 Nov 2015 10:17:33 +0000 |
|
Hi Stephan That interesting with your answer, and we will use get time at last pps in some of our work as well now.
Actually, Martin Leech gave an answer that seems good,
“You're probably just seeing the group delay of the interpolation filters on the N210, which for a given configuration, should
be of a fixed and predictable duration.” So it sounds like my problem was very much down to processing delays in the usrp interpolation registers. I was surprised it was so long really, but as it seems a reliable 26us,
I just take it into account when setting tx_time tag. Hopefully it will be ok, but I guess it will change when I use different sampling frequencies as well (hopefully it will just equate to 26 sample bins).
Cheers Will -- William Thompson Ph.D. Research Engineer Toshiba Research Europe Limited 32 Queen Square, Bristol, BS1 4ND, UK Tel: +44 (0) 117 906 0734 From: Ludwig Stephan (CR/AEH4) [mailto:address@hidden
Hi Will, as you might have seen, my issue was pretty simple to solve. Let’s attack yours, which seems to be more tricky. Considering your questions: We request the current time from just one (the master) USRP. But I meanwhile checked both times and up to a fraction they are equal,
as you also noted. As far as I understood, this is OK, because it takes some time to poll the second USRP for the time. Both USRPs are not polled at identical times, and this is the time difference you see. You should get identical results if you poll for
get_time_last_pps(size_t mboard=0), which reads the time from the USRP at the last PPS pulse.
Since both share the same PPS, this value should be identical (Certainly, Martin will correct me if I am wrong ;-) ). Considering your problem: are you sure that there is not a delay, which you do not compensate, due to the time it takes to transfer IP packets through the cable
(USRP -> PC) or by the variation of the computation time of the GR model? Mit freundlichen Grüßen / Best regards
Von: Will Thompson [mailto:address@hidden]
Hi Stephan Thanks for your reply. It’s good to hear you’re having similar issues with tags.
Actually in part of our larger system we do actually synchronise transmissions as well, but at that point ours system is transmitting OFDM so is less sensitive to small delays. I was just wondering, as you are using the MIMO cable, do you request the current time from both usrps? Or just the one?
As we initially had an OOT block that polled both USRPs and found that the start up time was a fraction out, but as they both share a clock and time source (via-MIMO cable), we used the time from just one of
the nodes and it seemed to work. In our case I think there was just a bit of delay in reporting the time from each USRP (I think it was done sequentially in C++). – Our system then just tagged bursts with a tx_time tag, we haven’t used messages for synchronising
transmission bursts. If you get a response from Ettus please put it up on the forum, or if possible forward it to me, as I would be really interested in finding out where these delays are coming from.
All the best Will -- William Thompson Ph.D. Research Engineer Toshiba Research Europe Limited 32 Queen Square, Bristol, BS1 4ND, UK Tel: +44 (0) 117 906 0734 From: Ludwig Stephan (CR/AEH4) [mailto:address@hidden]
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.
This email has been scanned for email related threats and delivered safely by Mimecast. NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com |
| [Prev in Thread] | Current Thread | [Next in Thread] |