Re: [Discuss-gnuradio] WBX and frequencies around 433 MHz?
Nick,
I tuned the center frequency to 400 MHz, 430 MHz and 433 MHz and the LO is
locked for all of them.
The spectrum for 430 MHz looks like the spectrum for 433 MHz (white line) in my
previous post. I've tried the same thing on another USRP2 with another WBX and
I get similar spectrums. So it doesn't happen on just one device.
BTW, I like the probe block, didn't know it before. It can be useful for other
purpose aswell.
Br,
Patrik
> Patrik,
>
> Can you please check to see that the WBX LO is locked? If you
> have a GRC flowgraph, you can use a function probe block with
> the following
> settings:
>
> ID: lo_locked
> Block ID: uhd_usrp_source_0 (or whatever your UHD source
> block is named) Function name: get_dboard_sensor Function
> args: '"lo_locked", 0'
> Poll rate: 1
>
> Then use a WXGUI checkbox with a default value set to bool(lo_locked).
> When you run your flowgraph, the checkbox will indicate
> whether the LO is locked.
>
> In your own non-GRC application you can use name>.get_dboard_sensor("lo_locked", 0) to check the status of the
> daughterboard LO lock.
>
> --n
>
> On Tue, Dec 6, 2011 at 4:40 AM, Patrik Eliardsson
> wrote:
> >> > > Hi,
> >> > >
> >> > > While I was testing the DQPSK-(de)modulation blocks in GRC.
> >> > I found a frequency region where the reception failed. I
> >> started with
> >> > the ISM-band (433 MHz) as the center frequency, and the
> reception
> >> > didn't work. After checking my code several times I decided
> >> to change
> >> > the center frequency to 2 GHz and everything started to
> work. So I
> >> > tried several other center frequencies with successful
> outcome, for
> >> > example 2 GHz, 1.5GHz, 800MHz, 500MHz, 420MHz. If I tuned the
> >> > frequency to the 430-440 MHz region the reception fails.
> >> > >
> >> > > I've used 2 USRP2s with the WBX and connected them with a
> >> > cable and 20 dB attenuator.
> >> > >
> >> > > I have 4 different WBX cards and the result is the same for
> >> > each of them.
> >> > >
> >> > > Have someone encountered the same problem with frequencies
> >> > around 433 MHz?
> >> > >
> >> > > Br,
> >> > > Patrik
> >> > >
> >> > >
> >> > Well, there's a lot of amateur radio traffic in that
> >> frequency range,
> >> > which may be interfering.
> >>
> >> I will keep that in mind. But I used a cable between the
> USRP2s, so I
> >> wouldn't expect any interference from other systems.
> >>
> >> > Also, there's a special frequency at 433.920MHz used for
> >> garage door
> >> > openers. Are you running
> >> > your USRP2 with the covers on or off?
> >>
> >> The covers are on.
> >>
> >> I will have a look at the received spectrum again, as Nick
> suggested.
> >
> >
> > Please have a look at the attached spectrum.
> >
> > Cable.png shows the spectrum when the transmitter is
> connected to the spectrum analyzer with a cable and 20 dB
> attenuator. The white line is the spectrum at the center
> frequency 433 MHz and the yellow line is at 400 MHz. The
> spectrum for 433 MHz looks like crap.
> >
> > Figure 400.png and 433.png shows the received constellation
> points and the received spectrum after a LPF for 400 MHz and 433 MHz.
> >
> > -Patrik
> > ___
> > 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] problems with python blocks [attn: jblum]
On Tue, Dec 06, 2011 at 09:54:43PM -0800, Josh Blum wrote: > So it looks like everything else passed which included gr_feval (another > thing in gnuradio-core that uses swig directors). Yes, indeed sir, that happened. Start 22: qa_feval 22/92 Test #22: qa_feval . Passed 0.70 sec > It looks like the last recognizable thing the thread calls (from your > traceback) is the swig director used in gr_block_gateway: > #7 0x746ca774 in > SwigDirector_gr_block_gw_handler_safe::call_handle (this=0x1b5ef90) I don't understand swig, but that is how I read it too. I went source diving in there and decided it was too arcane for my tired mind at that time. Maybe now that I have more sleep, who knows… > So perhaps, if the problem is the director, and if we remove the things > that are different from gr_feval, this might work for you? Can you try > this patch: http://pastebin.com/nThT5RBj Patched! Compiled! That didn't seem to work either … Start 22: qa_feval 22/92 Test #22: qa_feval . Passed0.69 sec … Start 27: qa_block_gateway 27/92 Test #27: qa_block_gateway .***Failed0.67 sec … 99% tests passed, 1 tests failed out of 92 Double checked to make sure I applied the patch: bash$ curl http://pastebin.com/raw.php?i=nThT5RBj | patch -p1 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 9680 9680 0 10759 0 --:--:-- --:--:-- --:--:-- 16406 (Stripping trailing CRs from patch.) patching file gnuradio-core/src/lib/general/gr_block_gateway.i Reversed (or previously applied) patch detected! Assume -R? [n] ^C Definitely applied. my gr_norm.aq result is familiar… #7 0x74706d03 in SwigDirector_gr_block_gw_handler_safe::call_handle (this=0x1af5550) at /home/jettero/code/arch/gnuradio/src/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6829 > I wonder if anyone else on arch has the same issue? Hard to say since there's no official package for gnuradio. The community build (AUR) is (or was) a little out of date, so I tweaked it to do things I wanted and to use the most recent git (his did a clone too, but I wanted to control that process a little, most recently to use your repo and branch). However, I have a hunch that it would not be unique to me since my build isn't so much different from the AUR build, just uses newer gits and … ahh … builds completely on the current repos. I definitely wonder if it's my swig. Can you try under Swig 2.0.4 on your end? -Paul -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange behaviour of example 'variable-config.grc'
On Tue, Dec 6, 2011 at 4:00 PM, Tom Rondeau wrote: > What OS are you running? > > (I'm asking these questions because I'm stumped and am buying time.) > > I did the same thing in #gnuradio ;) I believe it was slackware. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio locking up
Has anyone had time to look into the unlock() lockup that Rachel reproduced
below further? I seem to be running into it left and right for some reason
and sadly my C++ isnt anywhere near good enough to go seeking the cause
myself.
On Tue, Nov 22, 2011 at 9:02 AM, Rachel Kroll wrote:
>
> On Nov 22, 2011, at 7:56 AM, Marcus D. Leech wrote:
>
> > On 22/11/11 10:48 AM, Rachel Kroll wrote:
> >> It's pretty easy to get wedged forever if you call lock and unlock a
> lot in conjunction with connect and disconnect. Sooner or later, you'll
> hit a race and things will get stuck.
> >>
> >> I have a simple reproduction case if anyone is interested. It'll hang
> reliably after a few dozen iterations.
> >>
> >>
> > That's the type of information that shouldn't be withheld from this
> > list, and by implication, the
> > developers. Don't assume that because you've found a
> > bug/unexpected-behaviour, that the developers
> > know about it, and are working on a fix.
>
> It's come up a few times in the mailing list archives. The usual solution
> seems to be "add more sleeps", which of course is not a fix.
>
> Anyway, here's the reproduction case:
>
> #include
> #include
> #include
> #include
> #include
>
> static void connect(gr_top_block_sptr block, gr_sig_source_f_sptr source,
>gr_hier_block2_sptr block2) {
> fprintf(stderr, "connect: calling lock, connect, unlock\n");
> block->lock();
> block->connect(source, 0, block2, 0);
> block->unlock();
> fprintf(stderr, "connect: done\n");
> }
>
> static void disconnect(gr_top_block_sptr block, gr_sig_source_f_sptr
> source,
> gr_hier_block2_sptr block2) {
> fprintf(stderr, "disconnect: calling block->lock\n");
> block->lock();
>
> fprintf(stderr, "disconnect: calling block->disconnect\n");
> block->disconnect(source, 0, block2, 0);
>
> fprintf(stderr, "disconnect: calling block->unlock\n");
> block->unlock(); // It usually hangs here.
>
> fprintf(stderr, "disconnect: done\n");
> }
>
> int main(int argc, char** argv) {
> // Inner block: block to sink.
> gr_hier_block2_sptr inner;
> inner = gr_make_hier_block2("inner",
> gr_make_io_signature(1, 1, sizeof(float)),
> gr_make_io_signature(0, 0, 0));
>
> gr_file_sink_sptr sink;
> sink = gr_make_file_sink(sizeof(float), "/dev/null");
> inner->connect(inner, 0, sink, 0);
>
> // Outer block: signal source to inner block.
> gr_top_block_sptr outer = gr_make_top_block("outer");
> gr_sig_source_f_sptr src = gr_make_sig_source_f(11025, GR_COS_WAVE,
> 400, .1, 0);
>
> // Hook it up and get it going.
> connect(outer, src, inner);
> outer->start();
>
> // Frob it until we die.
> while (true) {
>disconnect(outer, src, inner);
>fprintf(stderr, "\n\n\n\n");
>
>connect(outer, src, inner);
> }
>
> return 0;
> }
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio locking up
Matt Mills wrote:
Has anyone had time to look into the unlock() lockup that Rachel
reproduced
below further? I seem to be running into it left and right for some reason
and sadly my C++ isnt anywhere near good enough to go seeking the cause
myself.
This looks like an old boost problem
(https://svn.boost.org/trac/boost/ticket/2330). Is there any chance you are
using a version of boost older than 1.45?
-- Don W.
On Tue, Nov 22, 2011 at 9:02 AM, Rachel Kroll
wrote:
On Nov 22, 2011, at 7:56 AM, Marcus D. Leech wrote:
> On 22/11/11 10:48 AM, Rachel Kroll wrote:
>> It's pretty easy to get wedged forever if you call lock and unlock a
lot in conjunction with connect and disconnect. Sooner or later, you'll
hit a race and things will get stuck.
>>
>> I have a simple reproduction case if anyone is interested. It'll hang
reliably after a few dozen iterations.
>>
>>
> That's the type of information that shouldn't be withheld from this
> list, and by implication, the
> developers. Don't assume that because you've found a
> bug/unexpected-behaviour, that the developers
> know about it, and are working on a fix.
It's come up a few times in the mailing list archives. The usual
solution
seems to be "add more sleeps", which of course is not a fix.
Anyway, here's the reproduction case:
#include
#include
#include
#include
#include
static void connect(gr_top_block_sptr block, gr_sig_source_f_sptr source,
gr_hier_block2_sptr block2) {
fprintf(stderr, "connect: calling lock, connect, unlock\n");
block->lock();
block->connect(source, 0, block2, 0);
block->unlock();
fprintf(stderr, "connect: done\n");
}
static void disconnect(gr_top_block_sptr block, gr_sig_source_f_sptr
source,
gr_hier_block2_sptr block2) {
fprintf(stderr, "disconnect: calling block->lock\n");
block->lock();
fprintf(stderr, "disconnect: calling block->disconnect\n");
block->disconnect(source, 0, block2, 0);
fprintf(stderr, "disconnect: calling block->unlock\n");
block->unlock(); // It usually hangs here.
fprintf(stderr, "disconnect: done\n");
}
int main(int argc, char** argv) {
// Inner block: block to sink.
gr_hier_block2_sptr inner;
inner = gr_make_hier_block2("inner",
gr_make_io_signature(1, 1, sizeof(float)),
gr_make_io_signature(0, 0, 0));
gr_file_sink_sptr sink;
sink = gr_make_file_sink(sizeof(float), "/dev/null");
inner->connect(inner, 0, sink, 0);
// Outer block: signal source to inner block.
gr_top_block_sptr outer = gr_make_top_block("outer");
gr_sig_source_f_sptr src = gr_make_sig_source_f(11025, GR_COS_WAVE,
400, .1, 0);
// Hook it up and get it going.
connect(outer, src, inner);
outer->start();
// Frob it until we die.
while (true) {
disconnect(outer, src, inner);
fprintf(stderr, "\n\n\n\n");
connect(outer, src, inner);
}
return 0;
}
___
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] Problem with new swig docs stuff
On Tue, Dec 6, 2011 at 3:51 PM, Josh Blum wrote: > >> >> [ 47%] Generating general_swig_doc.i >> Error in xml in file >> /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml >> Traceback (most recent call last): >> File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 253, in >> >> make_swig_interface_file(di, swigdocfilename, >> custom_output=custom_output) >> File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 196, in >> make_swig_interface_file >> blocks = di.in_category(Block) >> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 140, in in_category >> self.confirm_no_error() >> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 206, in confirm_no_error >> self.check_parsed() >> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 203, in check_parsed >> self._parse() >> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", >> line 51, in _parse >> self._members += converted.members() >> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 174, in members >> self.confirm_no_error() >> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 206, in confirm_no_error >> self.check_parsed() >> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 203, in check_parsed >> self._parse() >> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", >> line 163, in _parse >> self.set_descriptions(self._retrieved_data.compounddef) >> AttributeError: 'NoneType' object has no attribute 'compounddef' >> make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1 >> make[1]: *** >> [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2 >> make: *** [all] Error 2 >> > > Tom/Ben, > > I think doxyindex.py may be relying on an xml field that older doxygen's > do not define. > > Perhaps we could put a big try/catch around this in case it fails and > print to stderr. That way the build keeps going, and its just a warning > printed out in the terminal. > > -josh You're right, it clearly needs to be more robust. I'll have a look tonight. Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Manipulating Waterfall Display
Hey Everyone, I am new to GNURadio, and am at the beginning stages of learning Python/C++, just to give you a frame of reference. I am currently working on developing a RTI plot from data collected by the USRP2/USRP N210. After working with the GNURadio Companion, I figured easiest approach to this task would be to alter the code generating the Waterfall Plot. The only difference would be to replace each fft slice with the power of each sample (acquired by the I and Q values). The number of samples in each slice will represent the number of samples in one IPP (Inter-Pulse Period) for the particular radar application. Each sample can also be represented as a range gate for distance from the antenna. I have been looking through the code generated by GRC, and have made very little progress, so I have a few questions. 1.) Is there any documentation on how the Waterfall Plot is generated? I searched through doxygen, but couldn't find anything. 2.) What would be the best way to alter the waterfall code for plotting the power of each sample instead of the fft? 3.) Can an input be implemented to the python code that can adjust to different IPP settings? Any advice on these issues will be greatly appreciated. Thank you very much, Rob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with python blocks [attn: jblum]
> I definitely wonder if it's my swig. Can you try under Swig > 2.0.4 on your end? > swig 2.01 from ubuntu 11.10 repo was ok swig 2.04 from source had the same failure I cant say yet as to why, but at least its reproducible. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about benchmark_tx and benchmark_rx
Hi, I am using: OS: Ubuntu 11.10 (which I read in blog said that it has some problem with gnuradio) Gnuradio: 3.5.0 rc 0 (which I git from master branch) I quite puzzled it's not working with my current setup. It seems doable by many people but not me. Regards, Muhammad b Rosli Student Bachelor of Electrical and Electronic University of Canterbury On Wed, Dec 7, 2011 at 12:14 PM, Tom Rondeau wrote: > On Thu, Dec 1, 2011 at 10:15 PM, Muhammad Rosli wrote: > >> Hi, >> >> Thanks for your reply. I am using the narrowband example. >> >> If I attempt using >> >> ./benchmark_tx.py -f 400M -r 250k -S 4 >> >> and >> >> ./benchmark_rx.py -f 400M -r 250k -S 4 >> >> which I worked out from reading the README file, the receiver still >> output overrun (many '0'). I verified that the transmitter working since my >> spectrum analyser can pickup the signal from the transmitter. >> >> >> -- >> Regards, >> Muhammad b Rosli >> Student >> Bachelor of Electrical and Electronic >> University of Canterbury >> > > > What is your OS, version of GNU Radio, hardware? > > By default, the digital benchmarks run GMSK, so that with 250 kbps rate > should be easily doable without overruns on most modern machines. > > Tom > > > >> >> On Fri, Dec 2, 2011 at 3:56 PM, Marcus D. Leech wrote: >> >>> ** >>> On 12/01/2011 09:36 PM, Muhammad Rosli wrote: >>> >>> Hi, >>> >>> Thanks for reading my mail. I would like to ask is there any additional >>> setup or configuration required to execute benchmark_tx.py and >>> benchmark_rx.py? >>> >>> My problem is I tried to initiate simple communication between two USRP1 >>> using benchmark_rx.py and benchmark_tx.py . I had browse through the >>> mailing list looking on how to use the file appropriately. Running >>> benchmark_tx.py also execute help which I follow closely but failed to >>> receive any packets. If I tried to execute at transmitter: >>> >>> benchmark_tx.py -f 400M -S 10 >>> >>> and at receiver >>> >>> benchmark_rx.py -f 400M -S 10 >>> >>> I did not received packet status. I only received '0' in the terminal. >>> Is it correspond to error? >>> >>> I also read mailing list sent by other members but none mentioned about >>> not able to execute benchmark_tx.py . If I missed any post, could anyone >>> please provide me the link. >>> >>> For additional information: >>> Gnuradio version used: v3.5.0rc0 >>> USRP1 : revision 4 >>> Ubuntu: 11.10 >>> Daugtherboard: SBX >>> >>> Please let me know if I had to provide any additional information. >>> >>> -- >>> Regards, >>> Muhammad b Rosli >>> Student >>> Bachelor of Electrical and Electronic >>> University of Canterbury >>> >>> You're asking for 10 samples per symbol, which may exceed the rate at >>> which your receiver computer can keep up, depending on >>> the modulation used, and the complexity of the modulation techniques. >>> Are you using the narrowband or ofdm examples? >>> >>> The 'O' means overrun. The hardware (USRP1) is sending samples faster >>> than your computer can keep up. >>> >>> >>> >>> >>> -- >>> Marcus Leech >>> Principal Investigator >>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org >>> >>> >>> ___ >>> 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 >> >> > -- Regards, Muhammad b Rosli Student Bachelor of Electrical and Electronic University of Canterbury ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio locking up
On Wed, Dec 7, 2011 at 10:00 AM, Don Ward wrote: > This looks like an old boost problem ( > https://svn.boost.org/trac/boost/ticket/2330). Is there any chance you > are using a version of boost older than 1.45? > *frowns at ubuntu* ii libboost1.40-dev 1.40.0-4ubuntu4 Boost C++ Libraries development files ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Please tell me about recommend GPS antena and High Frequency Amplifier
Hi,all. I want to receive GPS L1 signal.and want to analyze location data in PC Now I use following GPS antena USRPN200 and DBSRX2. however, GPS signal's amplitude is very small. Ican't see gps signal in FFT http://www.amazon.co.jp/%E3%83%91%E3%82%A4%E3%82%AA%E3%83%8B%E3%82%A2-GPS%E3%82%A2%E3%83%B3%E3%83%86%E3%83%8A-5m-AN-G031/dp/B003V70RGG This time I want to change GPS antena. Please tell me about enough to amplitude of GPS antena. Thanks Kouki ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange behaviour of example 'variable-config.grc'
On Tue, 6 Dec 2011 18:00:51 -0500 Tom Rondeau wrote: > What OS are you running? OS is Linux 2.6.37.3 running on an AMD64 - the distribution is Slackware64-current with the Gnome SlackBuild additions and XFCE as window manager. I have no idea how to debug a mixture of Python and C++, so I can't be of much help with suggestions - sorry... Cheers, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Something about xcvr2450 daughterboard
Dear everyone: Recently I am studying the codes about daughterboard xcvr2450(mainly usrp\host\lib\db_xcvr2450.c) and there are some problems confuse me. 1. You see there are two steps in setting the frequency. First daughter board tunes as close as the target fequency and return the actual frequency . Second AD9862 perform the DUC procedure according to target fequency and actual frequency . But in function xcvr2450::set_freq() the so called actual_freq is set equal to target_freq and the computing of actual_freq is not used(there are // at the begining of the line). Why?? 2.Accoring to the table12 in the datasheet of MAX2829, we derive the divider ratio either using or .We should divide 20M.But it seems in function xcvr2450::set_freq() 64M/3 is used to be divided instead of 20M.Why?? Any of your answers will be very appreciated.Thank you.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Something about xcvr2450 daughterboard
On 12/07/2011 11:05 PM, signalswdm wrote: Dear everyone: Recently I am studying the codes about daughterboard xcvr2450(mainly usrp\host\lib\db_xcvr2450.c) and there are some problems confuse me. 1. You see there are two steps in setting the frequency. First daughter board tunes as close as the target fequency and return the actual frequency . Second AD9862 perform the DUC procedure according to target fequency and actual frequency . But in function xcvr2450::set_freq() the so called actual_freq is set equal to target_freq and the computing of actual_freq is not used(there are // at the begining of the line). Why?? 2.Accoring to the table12 in the datasheet of MAX2829, we derive the divider ratio either using or .We should divide 20M.But it seems in function xcvr2450::set_freq() 64M/3 is used to be divided instead of 20M.Why?? Any of your answers will be very appreciated.Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You should probably be looking at the UHD version of the XCVR code, since the "classic" stuff hasn't been touched in over two years. The XCVR board has a reference divider on board, and it looks like it is (in UHD), always set to divide the incoming master clock by either 2 or 3, depending on the master clock. The reference clock going into the MAX2829 can be up to 40Mhz, according to the data sheet. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How does benchmark_rx.py know the packet size?
When I run benchmark_tx.py, the packet size has to be specified (default is 1500) However, I could see nothing defining the packet size on benchmark_rx.py In benchmark_rx.py, messages from benchmark_tx.py are queued after passing demodulator, correlator, and framer sink. But, I'm wondering that how can the receiver queue a message which has the exact size defined by the transmitter without defining the packet size on the receiver. Are there any steps or procedures inside the demodulator, correlator, or framer sink that recognize the start and the end of the packet? -- Seokseong Jeon, PhD Candidate Communication & Networks Lab IT Convergence Engineering (ITCE), POSTECH, Korea +82 10 8338 1229, gee.songsong at gmail . com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
