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:stephan.ludw...@de.bosch.com] Sent: 17 November 2015 08:38 To: Will Thompson <will.thomp...@toshiba-trel.com>; discuss-gnuradio@gnu.org Subject: AW: USRP Latency. 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 Stephan Ludwig Robert Bosch GmbH Communication Technology (CR/AEH4) Renningen 70465 Stuttgart GERMANY www.bosch.com<http://www.bosch.com> Tel. +49(711)811-8809 Fax +49(711)811-5187845 Mobile +49(172)5630639 stephan.ludw...@de.bosch.com<mailto:stephan.ludw...@de.bosch.com> 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 Von: discuss-gnuradio-bounces+stephan.ludwig2=de.bosch....@gnu.org<mailto:discuss-gnuradio-bounces+stephan.ludwig2=de.bosch....@gnu.org> [mailto:discuss-gnuradio-bounces+stephan.ludwig2=de.bosch....@gnu.org] Im Auftrag von Will Thompson Gesendet: Freitag, 13. November 2015 17:18 An: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Betreff: [Discuss-gnuradio] USRP Latency. 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 ________________________________ 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<http://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 ________________________________ ________________________________ 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 ---------------------------------------------------------------------------------------
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
