I am trying to syncronise data acquisition for 3 USRP2 boxes at 2.4GHz
to
aquire say 1M samples from each board and write to a text file. So far I
have managed to modify the firmware to output the USRP2 clock to the
debug
pins and to call config_mimo(WE_LOCK_TO_SMA) and sync_to_pps(). When I
connect a 10MHz 2v Pk-Pk sine wave to each board (No PPS signal) and
look at
the clock output pin for each there is no drift in waveforms with
respect to
one another and the external clock reference. However, there is a phase
offset between the clock edges on each board which changes every time
they
are reset (sometimes of half a clock period).
Please see the example which includes the external clock reference and 3
clock outputs.
Wont this mean that I have unsyncronised sampling since the ADC is
controlled by the position of the clock edge?
Is there a way to overcome this problem?
My current python script to read in parallel is derived from the example
/gr-utils/src/python/usrp2_rx_cfile.py using gr.hier_block2 to create
multiple flow graphs (usrp2 → text file replicated four times). Do I
need
any special syncronisation functions in here or should the problem be
fully
handled on the firmware/FPGA?
Best regards,
Marc.
View this message in context:
http://old.nabble.com/Syncronous-data-aquisition-using-multiple-USRP2-boards-tp27642862p27642862.html
Sent from the GnuRadio mailing list archive at Nabble.com.
MarcW wrote:
Please see the example which includes the external clock reference and 3
any special syncronisation functions in here or should the problem be fully
handled on the firmware/FPGA?
Best regards,
Marc.
http://old.nabble.com/file/p27642862/scope_plot.jpg
I am not sure about the answer to your question.
What I do know, is that I myself tried the jblum VRT branch code
(including bitstream and firmware). I modified rx_streaming_samples to
synchronize with 10MHz and PPS. Finally, I feeded the two USRP2 (with
basic RX dBs) with a splitted AM modulated signal. The two USRP2s
synchronized perfectly in all my tests (not many though). Initially I
had problems with my pps signal not being sharp enough. By the way, the
pps signal was not synchronized in any way with the 10MHz signal, and
wasn’t 1Hz either, it was just a manually triggered single-step
function.
BR/
Per
Hi,
What do we see in your example? Have you divided the clock by 10?
Is the output stable or are the edges jittering anything?
When I look at our clock outputs (in a very quick measurement) they are
all approximately in phase but the edges are jittering quite a bit, and
I would assume that to different usrp2s could in a worst case be as far
apart as half a clock cycle…
Regards,
Ulrika
I am still at a complete unknown as to the source of the phase shifts of
the
USRP2 clocks I obtain in my initial post. Looking at the input clock
reference signals to each board there is no phase offset and Matt said
in
his post on USRP2 syncronisation that clocks on multiple boards must
have no
phase offset. Does anybody know why I am getting these such large phase
shifts?
Best regards,
Marc.
MarcW wrote:
We get no jitter at the clock edges though. Are your probes good for the
Ulrika U. wrote:
Regards,
edges on each board which changes every time they are reset
My current python script to read in parallel is derived from
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
–
View this message in context:
http://old.nabble.com/Syncronous-data-aquisition-using-multiple-USRP2-boards-tp27642862p27704497.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Hi Ulrika,
In my example the top sine wave in the 10MHz clock reference and the
lower 3
plots are from the debug clock pins on different USRP2 boards all using
this
clock reference. All boards are started at approximately the same time
and
all 4 signals undergo no drift with respect to each other but have a
clear
fixed phase offset which can be up to half a clock cycle.
The only modification I made is config_mimo(MC_LOCK_TO_SMA) and
clocks_enable_test_clk(true,10) which is done in txrx.bin. The 10 refers
to
the divide by 10 of the clock.
We get no jitter at the clock edges though. Are your probes good for the
frequency?
What cables do you use to connect your reference clock? We are currently
using quite long BNC’s so I think my next step is to try to reduce this
by
using much shorter SMA’s.
Best regards,
Marc.
Ulrika U. wrote:
Regards,
edges on each board which changes every time they are reset
My current python script to read in parallel is derived from
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
–
View this message in context:
http://old.nabble.com/Syncronous-data-aquisition-using-multiple-USRP2-boards-tp27642862p27701371.html
Sent from the GnuRadio mailing list archive at Nabble.com.
We used a couple of “home-modified” sma cables but extended them with
bnc (totally around 0,5 m long) but we didn’t divide the clock
(clocks_enable_test_clk(true,1)). Maybe we should look over the cables
to see if that might be the cause of the jitter? We do however not get
any phase offset larger than a quarter of a 100 MHz clock cycle.
I will try to make another measurement later if I have time.
Regards,
/Ulrika
