Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
This has never been clear to me! What about the phase ambiguity due to the fractional-N VCO's, as Marcus has mentioned? This has to be calibrated out, yes/no?, but how?, unless after a retune you then TX a calibration sequence that you can correlate against and correct. But after this, then, do you really need to accurately wait for a PPS? It's just stuff in the buffer, with the computational overhead of alignment. Basically, how do you compensate for the ambiguity? (maybe it doesn't matter and I'm probably talking rubbish :-/ ) Cheers - Original Message From: Josh Blum To: Khalid Jamil Cc: discuss-gnuradio@gnu.org Sent: Tue, 26 April, 2011 21:12:08 Subject: Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs On 04/26/2011 11:22 AM, Khalid Jamil wrote: > Please correct me if I am wrong. I think that this random channel-channel > phase offset at each acquisition depends on when each usrp 100MHz LO locks > to 10MHz external frequency reference by PLL. How PPS will help in that > case? Unless PPS is locked somehow to 10MHz clock? > Yes, but I strongly recommend that you get time-aligned samples working before trying to calibrate for the LO phase offsets. In your GRC flowgraph, each USRP source block will provide samples that start at a different random time that could be offset by many milliseconds. I don't think you want that? In order to get time-aligned samples from N devices, you must 1) synchronize the the time registers (seconds/ticks) across all USRP devices. You should use the PPS to do this 2) tell the devices to stream at the same time. > Is there a good example to follow, may to start with 2 or 4 channels? > There is an example that comes w/ uhd called rx_multi_samples. if you want to do this in GRC, follow the instructions in the previous email. -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
Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
This has never been clear to me! What about the phase ambiguity due to the fractional-N VCO's, as Marcus has mentioned? This has to be calibrated out, yes/no?, but how?, unless after a retune you then TX a calibration sequence that you can correlate against and correct. But after this, then, do you really need to accurately wait for a PPS? It's just stuff in the buffer, with the computational overhead of alignment. Basically, how do you compensate for the ambiguity? (maybe it doesn't matter and I'm probably talking rubbish :-/ ) Cheers, David - Original Message From: Josh Blum To: Khalid Jamil Cc: discuss-gnuradio@gnu.org Sent: Tue, 26 April, 2011 21:12:08 Subject: Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs On 04/26/2011 11:22 AM, Khalid Jamil wrote: > Please correct me if I am wrong. I think that this random channel-channel > phase offset at each acquisition depends on when each usrp 100MHz LO locks > to 10MHz external frequency reference by PLL. How PPS will help in that > case? Unless PPS is locked somehow to 10MHz clock? > Yes, but I strongly recommend that you get time-aligned samples working before trying to calibrate for the LO phase offsets. In your GRC flowgraph, each USRP source block will provide samples that start at a different random time that could be offset by many milliseconds. I don't think you want that? In order to get time-aligned samples from N devices, you must 1) synchronize the the time registers (seconds/ticks) across all USRP devices. You should use the PPS to do this 2) tell the devices to stream at the same time. > Is there a good example to follow, may to start with 2 or 4 channels? > There is an example that comes w/ uhd called rx_multi_samples. if you want to do this in GRC, follow the instructions in the previous email. -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
Re: [Discuss-gnuradio] Does anybody have sucessfully installed GNURadio on Windows
How about USRP2 and UHD? Cheers, Dave - Original Message From: Don Ward To: Matt Dunstan ; discuss gnuradio Sent: Mon, 1 November, 2010 1:28:26 Subject: Re: [Discuss-gnuradio] Does anybody have sucessfully installed GNURadio on Windows Matt Dunstan wrote: > OK, I really don't know what to do with that GNU Radio. I tried to install > it many times with CygWin and MinGW but no success, this is why I have this > question: does anybody have sucessfully installed GNU Radio on Windows OS Yes, I have installed it on Windows many times using both Cygwin and MinGW, and run it on Windows routinely. > (on > the site of Ettus Research it's written: it works under Win 7, XP ...)? or >maybe > everybody is working under Linux and I shouldn't try to install GNU Radio on > Windows because I waste my time as I did in the last 3 month. Have you followed the instructions at http://gnuradio.org/redmine/wiki/gnuradio/CygwinInstallMain or http://gnuradio.org/redmine/wiki/gnuradio/MingwInstallMain? Have you asked for help? It is true that both Cygwin and MinGW and the required third-party libraries can change over time and cause things to stop working, but if you report problems to this list someone will try to help. Best regards, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] differences between USRP2 rev 3 and rev 4 boards
What's the push button for? Dave - Original Message From: Matt Ettus To: Steve Mcmahon Cc: GNR Sent: Tue, 12 October, 2010 23:16:23 Subject: Re: [Discuss-gnuradio] differences between USRP2 rev 3 and rev 4 boards On 10/12/2010 02:22 PM, Steve Mcmahon wrote: > I am wondering what are the differences between the USRP2 rev 3 board > and the rev 4 board? > > I have one of each (one I ordered maybe a year ago and one I ordered > this past summer), and I don't see any differences on the board > itself. I understand that the versions of the FPGA image and the > firmware that shipped on the SD card from the factory would be > different, since over a year of time elapsed between my purchasing > the two boards. But what else is different? I can't find a changelog > for the USRP2 boards anywhere. Some clocks were reorganized for layout reasons and the PPS input circuit was modified to have a more consistent delay. The same FPGA image works for both. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom Processor
This may also be helpful. -Zotac ION Dual Core 1.6GHz Atom N330 Mini-ITX Board -2x USRP2 Rev 3, 10MHz bandwidth each -Netgear GigE Switch, the MB has only one port -Seagate 1TB baracuda (5900 rpm I think) -ext2 filesystem, Ubuntu 9.04 Using VRT branch code to just dump raw 16bit I&Q I was able to dump 15 minute cuts without problems (i didn't test for longer). I found though once the disk got to 30% capacity, dropouts occur, probably due to the write speed slowing down as the head nears the centre of the disk. Splitting the data from each USRP2 to seperate disks solved this problem. I was also able to test a few different boards, and concluded that the disk chipset/driver was a notable bottleneck between boards. eg, a Dell i7 based PC could not achieve this! I also used "bonnie++" to test disk throughput, the results of which tallied with the streaming results. From what I remember, if the bonnie++ write result was around 100MB/s, then you could sustain the 80MB/s (Going by disk test results on the web, this seemed in line with most max rates for sata drives). Also, I believe I also got 12.5MHz BW per channel (I'll check if I get a chance), but then, this is two channels, not one full 25MHz capture. Dave. - Original Message From: Sharif Shaher To: Marcus D. Leech Cc: discuss-gnuradio@gnu.org Sent: Sat, 9 October, 2010 2:47:53 Subject: Re: [Discuss-gnuradio] Intel Atom Processor Hi Marcus, Thank you so much for doing this and for informing all of us of your results. Helpful to us, and probably to others. On 10/8/2010 6:21 PM, Marcus D. Leech wrote: > On 10/08/2010 04:44 PM, Sharif Shaher wrote: >> Hi Marcus, >> >> That would be great, and greatly appreciated, we are just not sure >> is if there is a fighting chance or not...thus the question to the forum. >> >> Thanks so much, >> Sharif > On my dual-core Atom D-510 at 1.67GHz, with 4GB of memory, and an Intel > 80GB SSD, I can run at 12.5Msps without a problem. >Once I step it up to 16.67Msps, it starts getting long sequences of > overruns "O". > > This is with the UHD "Single USRP" source, using complex-short output, > into a "file sink" with a short input, vector-length 2. From >a USRP2. > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] find_usrps only succeed when an sniffer is ON
You may have done this already, but check that the network port is eth0, which find_usrp's uses by default. I had similar problem after inserting another network card, check /etc/udev/rules.d/70-persistent-net.rules... D. - Original Message From: Marcus D. Leech To: discuss-gnuradio@gnu.org Sent: Tue, 7 September, 2010 20:35:58 Subject: Re: [Discuss-gnuradio] find_usrps only succeed when an sniffer is ON On 09/07/2010 03:12 PM, Jorge Miguel wrote: > Thanks for your quick answer. A problem with a firewall was an idea > that also came to my mind but I disabled the Ubuntu firewall with the > command "sudo ufw disable" so that no firewall is running into my > machine and the USRP2-Host computer connection is made directly with a > 1 Gb ethernet wire. > > Furthermore there were no errors during the installation of the > software (via package manager).I run out of ideasany suggestion? > > Jorge. > > On 09/07/2010 04:43 AM, Jorge Miguel wrote: > >> I installed GNU Radio on a ThinkPad Lenovo T4410 under Ubuntu 10.04. >> After connecting the USRP2 with the original Ettus code on the SD card >> D and F LEDs are ok and when executed: >> >> ~$ sudo find_usrps >> No USRP2 found. >> >> I run wireshark or tcpdump to see what happens in my network and I got: >> >> ~$ sudo find_usrps >> 00:50:c2:85:35:a2 hw_rev = 0x0400 >> >> If I stop the sniffer, I get again: >> >> ~$ sudo find_usrps >> No USRP2 found. >> >> My problem is that 'find_usrps' only works when a sniffer is running. >> How can it be explained? >> >> Jorge, >> >> > What are the permissions on: /usr/local/bin/usrp2_socket_opener They need to be 4755 in order for non-privileged apps to work correctly with the raw ethernet interface. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BURX 26MHz clock
Thanks John, This is how I understood it, but I suppose my real question is (not being a dsp expert), why would you want to do this? I assumed that being a 26MHz clock, this would be ideal for GSM rate signals? Cheers, Dave - Original Message From: John Orlando To: David Evans Cc: GNURadio Sent: Thu, 19 August, 2010 18:39:30 Subject: Re: [Discuss-gnuradio] BURX 26MHz clock On Thu, Aug 19, 2010 at 12:17 PM, David Evans wrote: > Hi, > > Probably a stupid question... > By connecting the BURX's 26MHz clock to the USRP2's 100MHz ref. input, as > described in the source, does this pull the mainboard clock to 26MHz, or does >it > just phase lock to it? i.e. if I collect samples with usrp2_rx_cfile, these >will > all be samples at 26MHz? On the USRP2, there isn't any way to provide an external clock source (at least not a straight-forward way...you can always unsolder the 100 MHz oscillator etc). So if you're interested in using the BURX's on-board 26 MHz TCVCXO, this would clock the BURX board only, leaving the A/D converters still running at 100 Msamples/sec. The USRP2 can phase lock to an external 10 MHz reference, and it is also possible (with firmware modifications to the aeMB code) to phase lock to a reference clock frequency other than 10 MHz (this has been a topic of discussion on the mailing list over the last week or so). So you can access the 26 MHz TCVCXO output of the BURX board through the U.FL connector, and route it to the SMA input on the USRP2 where the 10 MHz reference typically goes, which will phase lock the two clocks. But you will need to tweak the aeMB firware to make this happen. -- John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BURX 26MHz clock
Hi, Probably a stupid question... By connecting the BURX's 26MHz clock to the USRP2's 100MHz ref. input, as described in the source, does this pull the mainboard clock to 26MHz, or does it just phase lock to it? i.e. if I collect samples with usrp2_rx_cfile, these will all be samples at 26MHz? Thanks Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC+USRPx file sink problem
Thanks, so it is. Unfortunately though, I have discovered that the gain for an RFX card cannot be adjusted (min=0, max=0, step=0), requiring a massive multiply value in gnuradio-companion, so its all very distorted. :-( Cheers, Dave - Original Message From: Marcus D. Leech To: discuss-gnuradio@gnu.org Sent: Wed, 18 August, 2010 20:26:38 Subject: Re: [Discuss-gnuradio] GRC+USRPx file sink problem On 08/18/2010 01:41 PM, David Evans wrote: > Hi, > > GRC Setup (used with RFX and WBX cards)... > > USRP1 ---to---> FFT Graphical sink (shows signal spectrum as expected) > and ---to---> Complex to IShort -to> File Sink (signals are >dumped > > to disk as expected) > > USRP2 ---to---> FFT Graphical sink (shows signal spectrum as expected) > and ---to---> Complex to IShort to> File Sink (**file is > all > zeros**) > > Tried with 3.3.0 and git 3.3.1, and on three different installations/USRPs. > Basically zero output with USRP2. > USRP2 works fine with python scripts eg, usrp2_fft.py with --output-shorts. > > Any ideas please? > > Dave > > My guess is that with USRP2, samples are scaled -1.0 to 1.0. Which means that a straight conversion to a short integer is going to yield zero most of the time. Try putting a multiplier block in front of your file sink--maybe scale those -1.0 to +1.0 to +/- 32767. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC+USRPx file sink problem
Hi, GRC Setup (used with RFX and WBX cards)... USRP1 ---to---> FFT Graphical sink (shows signal spectrum as expected) and ---to---> Complex to IShort -to> File Sink (signals are dumped to disk as expected) USRP2 ---to---> FFT Graphical sink (shows signal spectrum as expected) and ---to---> Complex to IShort to> File Sink (**file is all zeros**) Tried with 3.3.0 and git 3.3.1, and on three different installations/USRPs. Basically zero output with USRP2. USRP2 works fine with python scripts eg, usrp2_fft.py with --output-shorts. Any ideas please? Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD + BURX
Hello, Will BitShark be supported in UHD? Would it be easy to merge from GIT 3.3? Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tune time
Hi, Just a few general querys... How long does it take for an RFX card to tune and lock to a frequency, once a set_freq command is issued? Does it matter if the steps are small or large, ie a greater swing on the VCO? Is there a way to tell if/when the VCO is locked, ie its tuned (could I monitor it via the fpga gpio)? Is there a way to tell if the frequency reference is locked to an external reference (could I monitor it via the fpga gpio)? Regards, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multiple USRP2 sync
if I have two (or more) usrp2s, and I do a set_time_next_pps(), there is (or is there?) a chance that the pps could occur after the first call, so the second call will set the second usrp a second later. I would need to know when there is a pps or seconds transition prior to setup, then have one or two seconds to call set_time_next_pps(). Ok, I could read the system time, but I would need a gps with pps/ref out, and sync'd using ntpd or gpsd, and this may not be guaranteed. Or I could just monitor the pps level via the serial port (DCD, like ntpd does with nmea stream) to guarantee when the seconds tick over. If the pps state could be read back from the usrp (approx 80ns rtt) however, this would simplify the system and hardware requied (USB dongle, TTL to RS232 convertor, extra wires, etc...). So... while (get_pps_level() == 0); // wait for edge while (get_pps_level() == 1); u1->set_time_next_pps(...); // We are guaranteed at least one second to issue this to both usrp at once u2->set_time_next_pps(...); Thanks David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD query PPS
Maybe I misunderstand how to synchronise... if I have two usrp2s, and I do a set_time_next_pps(), there is a chance that the pps could occur after the first call, so the second call will set the second usrp a second later. I would need to know when there is a pps or seconds transition prior to setup, then have one or two seconds to call set_time_next_pps(). Ok, I could read the system time, but I would need a gps with pps/ref out, and sync'd using ntpd or gpsd, and this may not be guaranteed. Or I could just monitor the pps level via the serial port (DCD, like ntpd does with nmea stream) to guarantee when the seconds tick over. If the pps state could be read back from the usrp (approx 80ns rtt) however, this would simplify the system and hardware requied (USB dongle, TTL to RS232 convertor, extra wires, etc...). So... while (get_pps_level() == 0); // wait for rising edge while (get_pps_level() == 1); u1->set_time_next_pps(...); // We are guaranteed at least one second to issue this to both usrp at once u2->set_time_next_pps(...); Cheers, David - Original Message From: Josh Blum To: David Evans Sent: Sat, 22 May, 2010 17:37:32 Subject: Re: [Discuss-gnuradio] UHD query PPS Not sure what you mean. Perhaps readback the current time on the device? -Josh On 05/22/2010 07:23 AM, David Evans wrote: > Is it, or could it be possible to add a query method to get the PPS state > (something like u2->get_pps())? > > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD query PPS
Is it, or could it be possible to add a query method to get the PPS state (something like u2->get_pps())? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 dropping data
After much ado... The VRT branch I have always returns zero for rx_missing() and rx_overruns(), with a FIXME comment. I notice this is now fixed in the latest git. I also found no problems of lost data using Ubuntu 9.10 on an older Zotac motherboard, it wasn't until I moved to the H55-itx, and had to get the latest e1000 ethernet driver, that the missing data issue appeared. I then had the problem using the later driver on the older motherboard, which confused me. I wil try the later git code... Checking the fractional timestamps of the received packets I found that the receive samples handler always reports the same nitems (365 in my case with a 10MHz sample rate = 3650), but the fractional count itself sometimes updates (with the new intel ethernet driver) by a multiple of this value (eg 3x), but because I'm using nitems to fwrite the data to disk, data was being skipped. I've not had a chance to check the latest git, but hopefully this is fixed. Yes, config_mimo isn't there, I was trying to go by memory, which isn't what it used to be, or ever was...:-o Yes UHD looks the way to go, but loks to be another learning curve and rewrite of code I've done already. Cheers - Original Message ---- From: Per Zetterberg To: David Evans Sent: Mon, 17 May, 2010 20:30:12 Subject: Re: [Discuss-gnuradio] USRP2 dropping data David Evans wrote: > Hi, > > setup... > -2x USRP2s + GPS 10MHz reference + 1PPS > -Single GigE port, with USRPs on GigE switch > -Zotac H55-itx MB + i3 processor, so quite high end. > -VRT branch code. I also use PPS via DCD line to trigger when to load time on > next PPS, enable real time scheduling, ref to SMA, pps to SMA, > config_mimo(MC_WE_LOCK_TO_SMA) and use similar code to rx_streaming_samples > (but 2x USRPs). > -decimation set to 10 > -feeding in same off tune carrier into RFX400s to get a sine wave, just to > observe sync. > And yet, after sampling 30 seconds of data to file from both USRPs and the > code reports 0 underruns, 0 lost packets, no S's, I often get > dropouts/missed packets. > As I am receiving only, I gather from various posts that a single eth port + > switch should be Ok. The data captured always starts off in sync, it just > goes wrong sometime during the capture. The number of bytes captured is > normally the same for both channels too. > > Hope you can help please, > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > I have used VRT and everything has worked so far. However, I didn't do "config_mimo(MC_WE_LOCK_TO_SMA)" I did "c.ref_source=usrp2::clock_config_t::REF_SMA;" and "u2->config_clock(c);". Is "config_mimo" really part of the host VRT code ? In any case, you and me should start to use UHD instead . ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 dropping data
Hi, setup... -2x USRP2s + GPS 10MHz reference + 1PPS -Single GigE port, with USRPs on GigE switch -Zotac H55-itx MB + i3 processor, so quite high end. -VRT branch code. I also use PPS via DCD line to trigger when to load time on next PPS, enable real time scheduling, ref to SMA, pps to SMA, config_mimo(MC_WE_LOCK_TO_SMA) and use similar code to rx_streaming_samples (but 2x USRPs). -decimation set to 10 -feeding in same off tune carrier into RFX400s to get a sine wave, just to observe sync. And yet, after sampling 30 seconds of data to file from both USRPs and the code reports 0 underruns, 0 lost packets, no S's, I often get dropouts/missed packets. As I am receiving only, I gather from various posts that a single eth port + switch should be Ok. The data captured always starts off in sync, it just goes wrong sometime during the capture. The number of bytes captured is normally the same for both channels too. Hope you can help please, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sync 2x USRP2s
Hi, I want to sync two USRP2s, and currently trying to modify the VRT rx_timed_samples... usrp2::clock_config_t cc; cc.ref_source = usrp2::clock_config_t::REF_INT; cc.pps_polarity = usrp2::clock_config_t::PPS_NEG; cc.pps_source = usrp2::clock_config_t::PPS_SMA; cc.provide_ref_to_mimo = false; u2->config_clock(cc); // u2->set_time(); // replaced with... u2->set_time_at_next_pps(...); However, the code hangs at the start sampling, and manually applying a pulse to the PPS SMA does nothing. What is the correct voltage level and pulse shape required? Manually toggling anything between 0-1.5v and 0-5v does nothing. I hope 5V isn't too much!!! Ultimately, I want to capture coherent samples with both USRPs, maybe with the MIMO cable, and a GPS reference + PPS. Would this be just a case of... For USRP A (with ref + PPS attached)... cc.ref_source = usrp2::clock_config_t::REF_EXT; cc.pps_polarity = usrp2::clock_config_t::PPS_NEG; cc.pps_source = usrp2::clock_config_t::PPS_SMA; cc.provide_ref_to_mimo = true; For USRP B... cc.ref_source = usrp2::clock_config_t::REF_EXT; ***MIMO???*** cc.pps_polarity = usrp2::clock_config_t::PPS_NEG; cc.pps_source = usrp2::clock_config_t::PPS_SMA; ***MIMO???*** cc.provide_ref_to_mimo = false; Kind Regards, David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SBCs with GiGE
Not sure about cheap-ish, but have a look at the Toradex Robin NanoCOM SBC & Daisy daughterboard. I have one, very compact, cheapish at under 300 Euros?, and a quick test today with my USRP2, running the usrp rx samples program (the one in host/apps!), I was able to capture complex samples with a decimation of 7 with no overruns (captured into RAM, as I don't have a hard disk and boot from flash). I tried an EeeBox (Z270) initially, and when it did work (very unreliable detection of the USRP2), could only manage the occasional reliable capture with a decimation of 128. Just some thoughts, but I am also very interested in others experiences with USRP2 and compact SBCs. Cheers, Dave Marcus D. Leech wrote: Are there any SBCs (Single Board 'Pooters) out there that are: o compact o cheap-ish o Have 1 GiGE on them "for real"? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX900 Failure
Hi, Thanks for the fast response. Yes the SAW filter is broken and putting a capacitor in as you suggested has brought the output power back up to normal. :-) So, a couple of questions please, * Can the SAW be damaged by too much power from the PA? (I could find no info on the maximum power limits for this device, just the bandwidth and attenuation). * Can the SAW be damaged by a mismatched load (i.e no load!). I've asked around about this and get differing opinions o Yes, because the reflected power will be additively doubled, and enhanced due to the high Q of the filter o No, because the filter is a passive device, and the power will just pass through. * Also, apparently, SAW filters can easily be damaged due to physical shock, damaging the piezo electric material, so maybe this was just a one-off. I'll have to replace the chip anyway Thanks again guys, David Matt Ettus wrote: On 02/24/2010 09:42 AM, David Evans wrote: Hi all, Power output has significantly dropped, initially by 8dB, now much more. My first thoughts are that the PA has failed, so is it possible to break the transmitter... - by prolonged transmitting at high power (i.e. setting it to/near maximum)? - using a mismatched antenna? - mismatching resulting in VSWR effects? (err, without a load)? I'm obviously going to have to test now, where to start, any suggestions, like what voltage swing before and after the 3315 should I expect? I have seen this once before with someone who was transmitting at max power continuously. The problem may be in the SAW filter, which would make it easy to fix. You can just put a cap of anywhere between 50 and 1000 pF, size 0603 in the empty capacitor location which is in parallel with the filter. In order to tell if that really is the problem, you would probably need to probe with an RF probe for your spectrum analyzer or vary fast oscilloscope. You could probe at the antenna port and immediately before the SAW filter, and if there is a big loss in the filter you know that is bad. If you don't have the equipment to test this, it may be easier to just put the cap in there and try it. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFX900 Failure
Hi all, Power output has significantly dropped, initially by 8dB, now much more. My first thoughts are that the PA has failed, so is it possible to break the transmitter... - by prolonged transmitting at high power (i.e. setting it to/near maximum)? - using a mismatched antenna? - mismatching resulting in VSWR effects? (err, without a load)? I'm obviously going to have to test now, where to start, any suggestions, like what voltage swing before and after the 3315 should I expect? Many Thanks David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP1 + RFX900) + ATR
Hi, I am using 2 x (USRP1 + RFX900) for simple transceiver test (USRP1 to USRP2 back to USRP1), and can successfully transmit OOK packet (preamble + payload) and receive response. However, if I enable ATR on the sender, the received response by the sender is corrupted (I successfully correlate preamble, but following payload is corrupted). It's as if the received signal level becomes reduced after the ATR switches, or the sampling becomes off cut. Basically, the simple transceiver works, until Automatic Transmit Receive switch is enabled. I would like the transmitter to switch on only when transmitting, thus removing the LO breakthrough when in a quiescent state. Is there timing constraints I should adhere to, is there any further info on use of ATR I could be pointed to, Thank you, David. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
