On 06/11/2012 05:18 PM, Ryan Wolfarth wrote: > The clock signal has not been split yet: I'm only testing one N210 to > verify a reference lock. We will be using a SRS FS735 distribution > amplifier for clock splitting. It outputs 13+/-1 dBm to a 50 Ohm load from > each output. > > The current dboard is an RFX1800, but we will be using a combination of > 1200s and 1800s depending on the signal we're capturing. We changed the > sleep time in test_dboard_coercion to 5 seconds instead of 1. I'm going > perform some more thorough testing, but this looks like a good fix! >
Yea, sorry. It looks like there were a few things a little screwy with the lock detect checking. I will push something tomorrow to make it a little more consistent. Thanks! -Josh > Thank you, > Ryan > > On Mon, Jun 11, 2012 at 7:14 PM, Josh Blum <j...@ettus.com> wrote: > >> >> >> On 06/11/2012 04:04 PM, Ryan Wolfarth wrote: >>> Hi all, >>> >>> My research group is continuing our setup of two servers with multiple >>> N210s for a GNSS application. Each server will have 4 or 5 N210s >> recording >>> RF data at frequencies of interest. All are to be locked to the 10MHz >>> reference and 1 PPS output from a Septentrio PolaRxS. I have >> successfully >>> tested our PPS arrangement using test_pps_input. However, >>> test_dboard_coercion sometimes reports an unsuccessful lock to our >> external >>> oscillator. The number of unsuccessful locks varies with the inputs to >>> test_dboard_coercion: >>> >>> Set1: "--rx --ref external" reports an unsuccessful ref lock at 1500MHz >>> Set2: "--rx --ref external --no_rx_gain" reports an unsuccessful ref >> lock >>> at 1500, 1550, 1700, 1750, 1800, 1850, 1900, 1950, and 2000MHz. >>> >>> These unsuccessful locks are intermittent. The results for Set2 don't >>> worry me so much: we're always running at high gain when recording. What >>> is the cause and is there a good solution to this problem? Our plan is >> to >>> have all N210s writing constantly to a ring buffer, but only writing to >>> file when triggered by an external source. The reference lock is >> critical >>> since we're studying GNSS signals. Any help is appreciated. I know this >>> list usually hits it out of the park, so I'm looking forward to your >>> responses! >>> >>> Thank you, >>> Ryan >>> >>> Setup: Dell PowerEdge R510 running UHD 3.4.2 on Ubuntu 12.04 server. >>> >>> >>> >> >> Ryan, >> >> Can you tell me which dboard you are using? Its possible the sleep time >> before checking for lock might not be enough. >> >> -Josh >> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
