[Discuss-gnuradio] Re: gr-trellis: convenc and viterbi with own mapper/de-mapper
On Mon, 16 Aug 2010, Jonas M. Börner wrote: Hi all, I am trying to use the convolutional encoder and Viterbi provided by the gr-trellis class within another environment. I have my own mapper and de-mapper blocks which I want to use. So I tried to use the feed the viterbi_combined with this arguments: va_combined = trellis.viterbi_combined_fb(fo,nsymbols,0,-1,1,[-1,1],trellis.TRELLIS_EUCLIDEAN) My de-mapper outputs soft bits between -1 and +1. Here is an example output of my test script: data: [0, 1, 1, 0, 0] encoded:(0, 3, 2, 2, 0) unpacked: (0, 0, 1, 1, 1, 0, 1, 0, 0, 0) modulated: ((1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j)) demodulated:(-1.0, -1.0, 1.0, 1.0, 1.0, -1.0, 1.0, -1.0, -1.0, -1.0) decoded:(0, 0, 1, 0, 0, 1, 0, 1, 0, 1) Another thing I don't understand is why the decoder outputs 10 values instead of 5. I would be glad if someone told me what I am doing wrong. Regards, Jonas If I remember correctly, when you start pushing symbols through the trellis, it has some zero values before the input and some zero values after your last symbol pushed into the trellis. I think this is typically the length of your trellis. So at some point you will have to truncate the trellis output. Any one else care to comment? --Colby Boyer___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr-trellis: convenc and viterbi with own mapper/de-mapper
Hi Colby, thanks for your reply. My trellis is created like this: t=trellis.fsm(1,2,[91,121]) The constraint length is 7 so it doesn't look like it was connected to a trellis-specific thing. As I remember from the gr-trellis examples they didn't do any truncating there before comparing the source with the destination for error calculation... Regards, Jonas Am 17.08.2010 um 08:10 schrieb colby.bo...@gmail.com: On Mon, 16 Aug 2010, Jonas M. Börner wrote: Hi all, I am trying to use the convolutional encoder and Viterbi provided by the gr-trellis class within another environment. I have my own mapper and de-mapper blocks which I want to use. So I tried to use the feed the viterbi_combined with this arguments: va_combined = trellis.viterbi_combined_fb(fo,nsymbols,0,-1,1,[-1,1],trellis.TRELLIS_EUCLIDEAN) My de-mapper outputs soft bits between -1 and +1. Here is an example output of my test script: data:[0, 1, 1, 0, 0] encoded: (0, 3, 2, 2, 0) unpacked:(0, 0, 1, 1, 1, 0, 1, 0, 0, 0) modulated: ((1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j)) demodulated: (-1.0, -1.0, 1.0, 1.0, 1.0, -1.0, 1.0, -1.0, -1.0, -1.0) decoded: (0, 0, 1, 0, 0, 1, 0, 1, 0, 1) Another thing I don't understand is why the decoder outputs 10 values instead of 5. I would be glad if someone told me what I am doing wrong. Regards, Jonas If I remember correctly, when you start pushing symbols through the trellis, it has some zero values before the input and some zero values after your last symbol pushed into the trellis. I think this is typically the length of your trellis. So at some point you will have to truncate the trellis output. Any one else care to comment? --Colby Boyer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr-trellis: convenc and viterbi with own mapper/de-mapper
On Tue, 17 Aug 2010, Jonas M. Börner wrote: Hi Colby, thanks for your reply. My trellis is created like this: t=trellis.fsm(1,2,[91,121]) The constraint length is 7 so it doesn't look like it was connected to a trellis-specific thing. As I remember from the gr-trellis examples they didn't do any truncating there before comparing the source with the destination for error calculation... Regards, Jonas Am 17.08.2010 um 08:10 schrieb colby.bo...@gmail.com: On Mon, 16 Aug 2010, Jonas M. Börner wrote: Hi all, I am trying to use the convolutional encoder and Viterbi provided by the gr-trellis class within another environment. I have my own mapper and de-mapper blocks which I want to use. So I tried to use the feed the viterbi_combined with this arguments: va_combined = trellis.viterbi_combined_fb(fo,nsymbols,0,-1,1,[-1,1],trellis.TRELLIS_EUCLIDEAN) My de-mapper outputs soft bits between -1 and +1. Here is an example output of my test script: data: [0, 1, 1, 0, 0] encoded:(0, 3, 2, 2, 0) unpacked: (0, 0, 1, 1, 1, 0, 1, 0, 0, 0) modulated: ((1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j)) demodulated:(-1.0, -1.0, 1.0, 1.0, 1.0, -1.0, 1.0, -1.0, -1.0, -1.0) decoded:(0, 0, 1, 0, 0, 1, 0, 1, 0, 1) Another thing I don't understand is why the decoder outputs 10 values instead of 5. I would be glad if someone told me what I am doing wrong. Regards, Jonas If I remember correctly, when you start pushing symbols through the trellis, it has some zero values before the input and some zero values after your last symbol pushed into the trellis. I think this is typically the length of your trellis. So at some point you will have to truncate the trellis output. Any one else care to comment? --Colby Boyer I have not used the GNU Radio trellis before. In the past, I have only used the the matlab trellis and I remember I had to deal with truncating. --Colby___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA ZigBee PHY 64 chip-sequences
Thanks for the reply! Any other suggestions? I'm trying to change the UCLA ZigBee PHY to do spreading and despreading using a table of 16 64-chip-sequences instead of the 16 32-chip sequences. The files I have edited are listed below. Now, as it is still not working, I'm looking for hints, suggestions or anything at all, whether there might be more code to edit in order to achieve this goal... best regards and thanks a lot for the help Quoting Jason Uher jasonu...@gmail.com: [Hide Quoted Text] I have experience with the code, but you might try grep to find references to old number of bits or variables. Jason On Mon, Aug 16, 2010 at 11:34 AM, bjoe...@ee.ethz.ch wrote: Hi everyone, I use the UCLA ZigBee PHYsical Layer with gnuradio and USRP. And now I try to increase the number of chips per symbol within the Symbol-to-chips-table from 32 chips per 4 bit symbol to 64 chips. I adopted the three files - ucla_ieee802_15_4_packet_sink.cc - ucla_ieee802_15_4_packet_sink.h and - ucla_symbols_to_chips_bi.cc . I also generated a 64 bit Symbol_Table, CHIP_MAPPING respectively using the OQPSK - MSK encoding as described in the papaer: GNU Radio 802.15.4 En- and Decoding But still it is not working. I assume that there might be some other parts of the code, which depend on whether the chip-sequences are 32 chips or 64 chips and I was wondering if you might be able to give me a hint where to look!? Even after going through the files from UCLA, i couldn't figure out where this might be!? Help would be highly appreciated! Thanks a lot for your help, Best regards, Björn ___ 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] Build failing, any ideas?
On Mon, Aug 16, 2010 at 01:18:25PM -0700, Eric Blossom wrote: The bug is fixed in the master, maint and next git branches. Also, there shouldn't be a need to specify the --with-boost-thread and --with-boost-program-options options. Thanks a lot, for me it still needs the configure line, though. I managed to put a gnuradio stable PKGBUILD into Arch's AUR repos. Cheers pgpMKATyHPSxx.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to bypass the ISM band filter on the RFX900?
Hello, My current application needs to work on ISM band, and there is an ISM band filter on RFX900, how to remove or bypass the ISM band filter on the RFX900? Thanks Zhen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to bypass the ISM band filter on the RFX900?
http://www.google.com/search?q=inurl%3Adiscuss-gnuradio+disable+ism+filter The filter affects both TX and RX, but not the auxiliary RX path (RX2). If you just want to receive, use the 2nd SMA port and make sure to set that in the software. If you want to bypass the filter for transmit, you will need to put a cap of about 50 to 200 pF in the path, and cut the traces to the filter. You have to de-solder it. Optionally (in case you don't want to remove the part, since it will be difficult to reinstall it), you could install a jumper (zero-ohm resistor) or (better) a small 10pF capacitor in parallel (there is a pad), but this may cause some weird side-effects if you use the USRP in the ISM band after installation. You need to put a cap of between 25 and 500 pF in that location, AND you need to cut the traces which go to the filter. If you don't you will get weird resonances. Jason On Tue, Aug 17, 2010 at 9:24 AM, Zhen zkon...@yahoo.com.cn wrote: Hello, My current application needs to work on ISM band, and there is an ISM band filter on RFX900, how to remove or bypass the ISM band filter on the RFX900? Thanks Zhen ___ 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] Changing external reference frequency with USRP2...
On 08/16/2010 09:22 PM, Ian Holland wrote: Please disregard my last. I must have got something wrong in my testing. It now compiles, but it seems I need to use txrx_xcvr.bin instead of txrx.bin with the latest git trunk. Please correct me if this is wrong (note I have XCVR2450 as my daughterboard). This is correct. Due to the size of the code, the xcvr was split out to its own file. Also, you are right about the prescaler. Nonetheless, I still seem to get a time varying frequency offset between a transmitted and received BPSK waveform, when using the same local oscillator of 36 MHz at each end. In fact, about every million samples, this frequency offset disappears, then comes back getting larger, then smaller and disappears again about 1 million samples later. Is this expected when using a reference different to 10 MHz? When I have used two USRP2s both locked to a 10 MHz reference, I never saw this problem. No, you should not see that. It sounds like it is not locked, and I think the reason is loop bandwidth. The original setup is for a 10 MHz compare frequency, and you are using a 1 MHz compare frequency. This will mess up the loop dynamics by dividing the loop bandwidth by 10. The greatest common divisor of 100 MHz and 36 MHz is 4 MHz, so I would use that for the compare frequency. Then also increase the charge pump current to the maximum. That should bring you closer to the original loop bandwidth. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] External clock source Info?
Hi All; It seems that 52MHz /64MHz precision clock references are like hen's teeth, so I'm working on a design. What I need to know is what sort of level is the USRP1 looking for ? Is it 3.3V CMOS ? Once I get the design working, I'll make them available at a reasonable price J Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Helper script to automatically add blocks
thanks for the contribution Martin :) I have some tools I could add to it myself. I think devtools was the right thing to do. Hopefully several people will contribute other tools to it. I will move it to the top of the Projects page. On Mon, Aug 16, 2010 at 5:44 AM, Martin Braun martin.br...@kit.edu wrote: Hi list, since pretty much all of my GNU Radio'ing consists of dealing with out-of-tree modules I started a script to modify those. In the current state, it can add blocks to an existing out-of-tree module. It will attempt to guess a lot of stuff and then add skeleton code for the blocks and the QA code and edit the makefiles accordingly. I will still have to add some blocks to my modules before it actually saves *me* some time, but I just got pretty annoyed at editing all the makefiles by hand, and always forgetting one line somewhere. Following George's request, I made it available on CGRAN. I couldn't resist calling it 'devtools' and making it a project for all kinds of tools, scripts etc. which help developing. Being an optimist, I'm assuming there might be others who've made scripts, vim/emacs/Eclipse-plugins etc. and are just waiting for a platform to publish these. Grab infos and the code at https://www.cgran.org/wiki/devtools Disclaimer: This script actually edits your files. It might cause damage, and take no responsibility. Use at your own risk. I only want to know about it if it's in form of a bug report. Cheers, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ 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] External clock source Info?
On Aug 17, 2010, at 2:24 PM, William Pretty Security Inc wrote: It seems that 52MHz /64MHz precision clock references are like hen’s teeth, so I’m working on a design. What I need to know is what sort of level is the USRP1 looking for ? Is it 3.3V CMOS ? Once I get the design working, I’ll make them available at a reasonable price J I think you will get bonus points if your design can accept an external 10MHz reference provided by a GPS-disciplined oscillator. If there was some convenient way to adjust out the crystal aging for use when the external reference isn't available, that would be even better. I've been thinking of designing something along these lines, but I won't complain if you do the hard work and I can just buy one from you. ;) -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp2 master clock modifications
Hi,
I tought I'd share some experiences with running the usrp2 system
clock with something else than 100 MHz (so I can google it when I
forget).
Matt suggested that I could remove the 100 MHz oscillator and input my
own external clock instead. The VCTCXO was easy to remove, and I put a
1 Vpp sample clock in the place of pin 3. Another option would have
been to buy a VCTCXO with another frequency, but I just thought this
would be more straightforward.
I also modified the following places:
firmware/microblaze/lib/memory_map.h:#define MASTER_CLK_RATE 1
firmware/microblaze/divisors.py:master_clk = 100e6
lib/usrp/usrp2/usrp2_iface.cpp:double get_master_clock_freq(void){
and flashed the firmware after compiling.
I initially tried with a 60 MHz clock. The, but I couldn't get the
sampling to start. I then tried 80 MHz with better success. The seems
to work ok, but I'm still in the process of verifying it.
juha
On Mon, Aug 16, 2010 at 16:35, Matt Ettus m...@ettus.com wrote:
The USRP2 can ran at other clock frequencies, but only by removing the clock
on the board. The oscillator on there is a CVHD-950 and it is available in
a bunch of other frequencies in the range you are looking for, including:
67.5 MHz
70
74.1758
74.25
76.8
80 MHz
You can also use the 122.88 MHz version and set the clock gen chip to divide
by 2, to give you 61.44.
See here for ordering:
http://www.mouser.com/Search/Refine.aspx?Keyword=cvhd-950
You can't make the reference clock appear on the output except by board
mods. If you are in a hurry and can't get a new oscillator chip, you can
remove the oscillator and input an external signal.
Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Helper script to automatically add blocks
On Tue, Aug 17, 2010 at 11:56:20AM -0700, George Nychis wrote:
I have some tools I could add to it myself. I think devtools was the
right thing to do. Hopefully several people will contribute other tools to
it. I will move it to the top of the Projects page.
Another interesting thing in this context could be what toolset/ setup
people are using for their 'daily' GNU Radio development.
Although I know there's a lot of people out there (like me) quite happy with
their setup of vim + gdb + {insertyourtoolhere} grown over the years it might
be interesting to have a plugin for eclipse or something of this kind. (read:
less scary for beginners). Some time back I experimented around with writing a
plugin for eclipse, since at our institute a lot of people getting into
contact with GNU Radio for the first time are quite intimidated by the rather
let's say ... not overly comfortable autotools.
Please don't start throwing rocks already ;-)
Beeing not a real java programmer and running out of time for exams I haven't
achieved a lot yet but nevertheless to me it seemed like a good place to try
since eclipse's wizard structure does conform quite well with the usual
everyday programming tasks for out of tree modules / applications.
Maybe a frontend to Martin's script might be another approach worth trying.
So maybe if we add information on work in progress / unfinished projects and
ideas for future devtools to the wikipage we might find people with common
interests.
So far,
Moritz
pgpx7fKRbMPs5.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP spike
On 08/17/2010 02:01 AM, Vincent W wrote: As evidence for the other kind of spikes, the ones that follow you around, please see the attached pictures, centered around frequencies of 1134 and 1135MHz. These are the spikes that follow the centre frequency around. The problem around 100MHz is very similar to what has been previously reported here: http://lists.gnu.org/archive/html/discuss-gnuradio/2010-03/msg00412.html, but I'm not sure exactly what the correct resolution is. To follow up, in the case of those spikes that seem to follow the center frequency, the solution appears to be increasing the gain until they go away, or else avoiding them entirely by setting it to the maximum value. However, I still have problems with the spikes around multiples of 100MHz. As an example, if I tune the WBX to 100MHz, everything appears fine, but if I tune to 100.25MHz, as shown in the attached picture, I see all sorts of spurious spikes that do not go away - regardless of the gain setting. Regards, Vincent attachment: usrp2_100M25k_spike.jpeg___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OCXO ' s
More Info on the parts I plan to use: At this point I have two possible fixed frequency parts: Silicon Labs Si590 series: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail http://search.digikey.com/scripts/DkSearch/dksus.dll?Detailname=590PC-BDG- ND name=590PC-BDG-ND Pletronics OHM4 Series: http://www.pletronics.com/products/select/ocxo1.php I'm still talking to distributers and reps, so we'll see . I'd could still use some input on what levels the USRP1/2 are expecting . Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] External clock source Info?
On Tue, Aug 17, 2010 at 3:10 PM, Mark J. Blair n...@nf6x.net wrote: On Aug 17, 2010, at 2:24 PM, William Pretty Security Inc wrote: It seems that 52MHz /64MHz precision clock references are like hen’s teeth, so I’m working on a design. What I need to know is what sort of level is the USRP1 looking for ? Is it 3.3V CMOS ? Once I get the design working, I’ll make them available at a reasonable price J I think you will get bonus points if your design can accept an external 10MHz reference provided by a GPS-disciplined oscillator. If there was some convenient way to adjust out the crystal aging for use when the external reference isn't available, that would be even better. I've been thinking of designing something along these lines, but I won't complain if you do the hard work and I can just buy one from you. ;) A while back I decided I wanted a better clock in my USRP1s and went hunting. I didn't have a lot of luck, and the few places I sent inquiries to didn't get back to me. My attention was eventually pulled off onto other projects... but you can count me in as someone who would like to partake in the results of this work. I'd also like to echo the 10MHz comment. GPSDOs Clocks with excellent long term stability show up at fairly low prices on ebay all the time (excess from cell site deployments, I assume). I have a couple of them. What they don't usually have is the very low phase noise that I'd want for a clock which is eventually going to multiplied up to GHz levels. So a USRP1 clock board which was primarily a 10-64MHz up-converter with very low phase noise would be exactly what I would want. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] External clock source Info?
On Aug 17, 2010, at 2:24 PM, Gregory Maxwell wrote: I'd also like to echo the 10MHz comment. GPSDOs Clocks with excellent long term stability show up at fairly low prices on ebay all the time (excess from cell site deployments, I assume). I have a couple of them. What they don't usually have is the very low phase noise that I'd want for a clock which is eventually going to multiplied up to GHz levels. So a USRP1 clock board which was primarily a 10-64MHz up-converter with very low phase noise would be exactly what I would want. For my bench frequency reference, I selected a surplus Trimble Thunderbolt with the newer version of OCXO that's supposed to be nearly as good as the HP double-oven OCXOs. I'll power it from an HP bench supply, since the switchers that are often supplied with the surplus Thunderbolts are said to add a lot of phase noise to the oscillator output. If the statistics from the monitoring program that I used during my first test run of the oscillator are to be trusted, then it should be able to provide a reference accurate to within tens of parts per trillion. I haven't finished installation of my GPSDO yet; I still need to finish repairing the (cheap, broken) HP bench supply that I got from eBay and assemble a power cable. I may get this done tonight, as the parts I needed just arrived today. The outdoor antenna (a surplus Lucent +26dB antenna as used at cell sites) is already installed and cabled into my house. My own idea for a USRP clocking replacement was to use a common and fairly inexpensive VCTCXO rated for temperature stability of around +/-2.5ppm (available at Digi-Key in frequencies commonly used in cell phones, GPS receivers, etc.), drive a PLL+VCO with that to generate 64 MHz (or 52 MHz, or any other frequency that the TCXO+PLL+VCO can generate), with an additional PLL to lock the VCTCXO to an external 10 MHz input. I'd also include a microcontroller which could measure the VCTCXO control voltage while locked to an external reference, and then drive that same voltage with a DAC when the external reference isn't present. Thus, while attached to the GPSDO the internal reference would be slaved to a very good reference, and then when that reference isn't available (such as when operating in the field) the on-board VCTCXO would at least be trimmed to compensate for aging. The memorization of the nominal VCTCXO tuning voltage might be triggered automatically, or by a push button, or by a GPIO controlled by the USRP hardware. The VCTCXO might be replaced with a voltage-controllable OCXO if desired for better holdover stability, but I figured that VCTCXO should be adequate for my needs. Does that architecture sound reasonable? If so, would anybody like to save me the trouble of designing and building it myself? ;) -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OCXO ' s
On Aug 17, 2010, at 5:07 PM, William Pretty Security Inc wrote: More Info on the parts I plan to use: At this point I have two possible fixed frequency parts: Silicon Labs Si590 series: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detailname=590PC-BDG-ND Pletronics OHM4 Series: http://www.pletronics.com/products/select/ocxo1.php I think that the Pletronics part looks like a much better option. If I'm not mistaken, the SiLabs part is a computer-grade oscillator with much lower stability and accuracy than is typically required in radio communications applications. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Hi Matt Thanks so much for your help. I tried your latest suggestion, and this gets my frequency offset between Tx and Rx down to a mere 1 Hz. This is much better and should make my testing considerably simpler. Cheers Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Wednesday, 18 August 2010 1:09 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... On 08/16/2010 09:22 PM, Ian Holland wrote: Please disregard my last. I must have got something wrong in my testing. It now compiles, but it seems I need to use txrx_xcvr.bin instead of txrx.bin with the latest git trunk. Please correct me if this is wrong (note I have XCVR2450 as my daughterboard). This is correct. Due to the size of the code, the xcvr was split out to its own file. Also, you are right about the prescaler. Nonetheless, I still seem to get a time varying frequency offset between a transmitted and received BPSK waveform, when using the same local oscillator of 36 MHz at each end. In fact, about every million samples, this frequency offset disappears, then comes back getting larger, then smaller and disappears again about 1 million samples later. Is this expected when using a reference different to 10 MHz? When I have used two USRP2s both locked to a 10 MHz reference, I never saw this problem. No, you should not see that. It sounds like it is not locked, and I think the reason is loop bandwidth. The original setup is for a 10 MHz compare frequency, and you are using a 1 MHz compare frequency. This will mess up the loop dynamics by dividing the loop bandwidth by 10. The greatest common divisor of 100 MHz and 36 MHz is 4 MHz, so I would use that for the compare frequency. Then also increase the charge pump current to the maximum. That should bring you closer to the original loop bandwidth. Matt This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] External clock source Info?
Gregory Maxwell wrote: On Tue, Aug 17, 2010 at 3:10 PM, Mark J. Blair n...@nf6x.net wrote: On Aug 17, 2010, at 2:24 PM, William Pretty Security Inc wrote: It seems that 52MHz /64MHz precision clock references are like hen’s teeth, so I’m working on a design. What I need to know is what sort of level is the USRP1 looking for ? Is it 3.3V CMOS ? Once I get the design working, I’ll make them available at a reasonable price J I think you will get bonus points if your design can accept an external 10MHz reference provided by a GPS-disciplined oscillator. If there was some convenient way to adjust out the crystal aging for use when the external reference isn't available, that would be even better. I've been thinking of designing something along these lines, but I won't complain if you do the hard work and I can just buy one from you. ;) A while back I decided I wanted a better clock in my USRP1s and went hunting. I didn't have a lot of luck, and the few places I sent inquiries to didn't get back to me. My attention was eventually pulled off onto other projects... but you can count me in as someone who would like to partake in the results of this work. I'd also like to echo the 10MHz comment. GPSDOs Clocks with excellent long term stability show up at fairly low prices on ebay all the time (excess from cell site deployments, I assume). I have a couple of them. What they don't usually have is the very low phase noise that I'd want for a clock which is eventually going to multiplied up to GHz levels. So a USRP1 clock board which was primarily a 10-64MHz up-converter with very low phase noise would be exactly what I would want. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I enjoy hearing the discussion on clocks as I have also wanted very low phase-noise. For the USRP2 I hope that a good 10MHz reference will do the trick. A while ago I did some tests which show good results when the transmitter and receiver are locked to the same 10MHz (see below). From this I assume that the same good results would occur with excellent 10MHz references. I have ordered T1220-T17-3.3-SM-10.0MHz from http://www.greenrayindustries.com/tcxo.html. I haven't tested with that one yet. == My experiments: I have been experimenting with transmitting a tone between two USRP2s equipped with basic daughterboards. The daughterboards are tuned to 20MHz, and the transmitted signal is generated in base-band as a cisoid with 5MHz frequency. The decimation and interpolation rate is 25MHz in both TX and RX. In the figure http://www.s3.kth.se/~perz/usrp/phase_noise1.jpg http://www.s3.kth.se/%7Eperz/usrp/phase_noise1.jpg non of the USRP2s are locked to external reference. In the figure http://www.s3.kth.se/~perz/usrp/phase_noise2.jpg http://www.s3.kth.se/%7Eperz/usrp/phase_noise2.jpg the two USRPs are locked to the 10MHz ref output of a marconi2024 generator. In the figure http://www.s3.kth.se/~perz/usrp/phase_noise3.jpg http://www.s3.kth.se/%7Eperz/usrp/phase_noise3.jpg the two USRP2 are locked to the 10MHz ref of two _different_ marconi2024. What I gather from this is that the reference of my marconi2024 is better than that built in the usrp2 (first and third figure). Though, it can be much better (second figure). However, then I would need an extremely clean reference. My marconi2024 is specified to have phase-noise better than -124dB/Hz at 20kHz. The results seem to suggest that's not true. However, the generator is 15 years old. Is it likely that it has aged ? BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
