10-13-2015 06:09 AM
Hello Community!
I am trying to synchronise multiple Ettus USRP N210 using Octoclock. I am sending a short beacon from one USRP at each whole second (using the onboard timestamp), the other USRP picks up the beacon and display the time. I have set the clock source of both USRP to PpsIn using niusrp properties node, however it looks that both USRP are still using their internal clock: I can see a relatively fixed fractional second at the RX once it picks up a beacon and this fractional second doesn't change whether I set the clock source to internal or ppsin. I am not sure whether it is the correct way of sync USRP to external reference beacuse I am quite new to Labview Comms, anyone has any ideas? Many thanks!
Solved! Go to Solution.
10-13-2015 11:00 AM
Hello Maxcy,
Welcome to the Community!
I highly recommend looking through the NI-USRP Help>Programming Reference>MIMO Synchronization document. This will help explain the synchronization.
Synchronization requires two components, a shared timebase and start trigger. In this case to share the timebase, you use the Clocking and Sync Properties of the USRP Reference to set the Frequency Reference to RefIn and the Timebase Source to be PPSIn. You will want to wire the system the same way as Figure 9 in the following Ettus Document:
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
In order to share the start trigger, we will want to use the Configure Start Time Trigger to be increments of 1 second. More importantly, you will want to reset the Onboard USRP Timers of all USRPs at the same time. This is done by using the Set Time VI and ensure that the change is applied at the next PPS Edge (set the apply timestamp input to 1). This will require the TX and RX to both be started and configured within the same second of each other. For testing purposes, I recommend configuring both the RX and TX within the same VI. This will take advantage of LabVIEW's innate parallelism and will ensure that both are started at the same time.
With all of the above synchronization there will be a random amount of constant phase offset between the channels, as documented in figure 6 of:
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
This could be responsible for your consistent fractional offset. These needs to be signal processed to ensure alignment.
I hope this helps.
Regards,
10-13-2015 11:52 AM - edited 10-13-2015 11:54 AM
Hi tcap,
This makes sense now thanks very much! I can see the next pps option in Labview's SetTime node but in Labview Comms's SetTime node I can only input a number to 'when to apply timestamp' varaible which I can't find any instruction on how to set it in the online manual.
At the moment I am using two host PCs for two USRP devices, and it seems that I can still get their timestamps sycnrhonised by some luck. The example you mentioned uses Ethernet switch to control multiple USRP on single host, will it affect the bandwidth and performance of the system and cause overflow/underflow?
To ensure the same timestamp on USRPs connected to different hosts I am thinking of use the hosts' timestamp(whole second only, each host sync to the Internet) as the initial time rather than 0, so that even if RX/TX sessions start at different time they can still have the same timestamp. Do you think it's possible? Many thanks!
10-13-2015 02:10 PM
Hello Maxcy,
If you set the Apply Timestamp to 1, it will use the next PPS edge to set the time. Sorry for the lack of documentation. I recommend looking at the LabVIEW Help Documentation, because all of the functions are the same.
If you connect the USRPs to a switch, it will negatively impact the throughput performance. If you have 8 1Gbit/s connections being streamed into a switch, which outputs 1Gbit/s, data will be lost and you will get flow errors. If you have multiple Network adapters on your computer, you can connect each one to a USRP. This will increase the Ethernet throughput, but will negatively impact the PCI or PCIe bus throughput. The Ethernet Switch does not affect the synchronization.
Finally, I think that your idea to synchronize to host computer's time is great. You might want to round it to the nearest 10 seconds or minute, in order to give you a little more time to run across the lab and hit run on another computer.
Regards,