Re: [Discuss-gnuradio] Confirming uhd.set_command_time is working
Hi Doug,
I'm not 100%, but: Getting the center frequency might be a command which
will also end up in the timed command queue.
What happens if you:
u.set_command_time(u.get_time_now() + uhd.time_spec(2))
print("about to issue tune command...")
result = u.set_center_freq(800e6)
u.clear_command_time()
print("immediate tune result: {:f}MHz RF, {:f} Hz
DSP".format(result.rf_freq/1e6, result.dsp_freq))
print("get_center_freq before sleep: {:f}
MHz".format(u.get_center_freq()/1e6))
time.sleep(2)
print("get_center_freq after sleep: {:f}
MHz".format(u.get_center_freq()/1e6))
Greetings,
Marcus
On 04/28/2015 12:03 AM, Anderson, Douglas J. wrote:
> Hi all,
>
> I'm playing around with timed commands on the USRP, but I'm not sure I
> understand them correctly.
>
> I've got a usrp connected as "u" and set to center freq 700e6.
>
> >>> u.set_command_time(u.get_time_now() + uhd.time_spec(2));
> u.set_center_freq(800e6); u.clear_command_time();
> print(u.get_center_freq()); time.sleep(2); print(u.get_center_freq())
> -- Successfully tuned to 800.00 MHz
> --
> '::uhd::tune_result_t *' at 0x7f1b75a3b930> >
> 8.0
> [... 2 second pause is here ...]
> 8.0
>
> It looks like it's changing the freq immediately... but I'm assuming
> as usual there's more than meets the eye to this command. Any hints?
>
> -Doug
>
>
> ___
> 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
[Discuss-gnuradio] GNU Radio / Software Radio Trainings in Germany
Dear GNU Radio community, we are happy to announce that Fennec Research in cooperation with Munich Innovation Labs is offering GNU Radio User & Developer Trainings in Germany! Date: August 6, Thursday to August 7, Friday, 2015 Venue: Bremen, Germany Goal: Independent development and application of GNU Radio communication systems To sign up or request further information, please visit http://www.munich-innovation-labs.com/training/ . Best regards, Jens ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No scope with gr?
Hi, > Hi Ralph, > I see... Hm. The point is that most of us is not really deep into the WX code > base, and GNU Radio is planning to move away from WX to QT, and since I > can't reproduce the problem locally, it's going to be very hard to get you > running. It really *is* an odd failure if only the scope is failing. So I will have a look at the qt stuff and simply forget about wx. To by honest, I never bothered what kind of GUI I am using, but when qt GUI offers the same functionality, so why stay with wx?! > Generally, if your application is "simple enough" to just switch Generate > Options from "WX" to "Qt" and replace a few GUI elements, then I'd > recommend using Qt; it's more modern, and it will stick around longer. Most > features can be configured even at runtime using "middle-click" on the > visualization. Yep, it is all quite simple stuff, nothing special. The scope I even do not really need most of the time, just the waterfall is nice to have. > Greetings, > Marcus Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on control-loop block design
Hello, I've been looking into the design details of the control-loop block. I stumbled upon the blog post of Tom (http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html with the derivation https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d0863397/543aee1fe4b09162d08633ac/1313345573084/control_loop_derivation.pdf) and also this article from TI: http://www.ti.com/lit/an/slyt169/slyt169.pdf. Now looking at the schematics of the control loop in Tom's post and the TI article (figure 5), you notice a slight difference after the loop filter. In the TI article, there is delay (z^-1) followed by an accumulator. In the schematics of Tom's post, the delay block is directly integrated in the loop. Can somebody comment on these differences? Thanks Ruben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Many thanks
Hello. Thanks for your great help for me about two rtl2832 dongles in a GRC project. The idea of Kevin Reid of using osmosdr source block is usefull. My two rtl2832 dongles are working together now. Sincerely Igor Popov. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Announcing NEWSDR on Thr/Fri May 21/22 at WPI
* * NEWSDR 2015 * * * * New England Workshop on Software-Defined Radio * * * * Fifth-Annual* * * *Main Event * * Friday May 22, 7:30 AM - 4:00 PM * * * * GNU Radio Hacking Workshop* *Thursday May 21, 5:00 PM - 9:30 PM * * * * Worcester Polytechnic Institute (WPI) * *Worcester, MA, USA * * * * http://www.sdr-boston.org/* * * * Free Registration* * * * INVITATION TO PARTICIPATE You are cordially invited to the 2015 New England Workshop on Software Defined Radio (NEWSDR 2015), which is the fifth installment of an annual series of workshops organized by the Boston SDR User Group (SDR-Boston). This year, NEWSDR will be held at the Rubin Campus Center of Worcester Polytechnic Institute (WPI), and consists of a day-long Main Event on Friday, and a GNU Radio Hacking Workshop (GRHW) on the evening before. People are welcome to attend either or both. * MAIN EVENT Friday May 22, 7:30 AM - 4 PM KEYNOTE SPEAKER: * Professor frederic harris, San Diego State University INVITED SPEAKERS: * Professor Miriam Leeser, Northeastern University * Professor Mieczyslaw Kokar, Northeastern University TECHNICAL POSTER PRESENTATIONS: * Covering the recent work in SDR and cognitive radio technology * Poster presentations are now being solicited * See link at the bottom of this email to submit your abstract SPONSORS: * The MathWorks Inc. * National Instruments / Ettus Research * MediaTek Wireless Inc. * Wireless Innovation Laboratory (WI Lab) at WPI DEMOS & TECHNICAL SEMINARS FROM: * The MathWorks Inc. * National Instruments / Ettus Research COMPLIMENTARY: * Free parking * Free breakfast, lunch, coffee provided The Main Event features invited speakers, technical poster presentation sessions, hardware and software demonstrations from the event sponsors, and two technical seminars, all focusing on recent work in SDR and cognitive radio technology. The event provides an excellent networking opportunity and a terrific venue to exchange thoughts and ideas with other people working in the SDR space. * GNU Radio Hacking Workshop (GRHW) Thursday May 21, 5 PM - 9:30 PM HOST: * Dr. Tom Rondeau, Rondeau Research LLC COMPLIMENTARY: * Free parking * Free pizza, drinks, and dessert provided The GRHW is a great opportunity for people to learn about how to productively use GNU Radio and USRP devices. The workshop is aimed at both novice users as well as at those with some previous basic experience. The GRHW will be run by Dr. Tom Rondeau, who will briefly speak about the current state and future directions of the GNU Radio project. Afterwards, a brief GNU Radio tutorial will follow. Then attendees will work individually or in groups to implement a communications system from scratch, with guidance from on-hand staff to answer questions and help with problems. A working system will be presented at the end. Attendees are required to bring their own laptops, but USRP radios as well as bootable live USB flash drives will be provided. Nothing will need to be installed on attendees' laptops. * REGISTRATION * Registration is completely free * Registration takes less than 5 minutes * Registration includes free parking and free food * You must register online in order to receive a voucher for free parking and free food * Attendance, food, parking are all limited, so please register online as soon as possible to secure your spot * Registration deadline is Friday May 15 * See link at the bottom of this announcement to register onlin
Re: [Discuss-gnuradio] Correlation Estimation Block Oddity
Hey Andy, When you mentioned I should remove leading or trailing zeros from the Correlation Estimator symbols field, how would you go about doing this if you used the modulate vector block as done in the example? I'm stuck on this. v/r, Rich On Mon, Apr 27, 2015 at 4:52 PM, Richard Bell wrote: > I somehow attached the wrong correlation screenshot in my previous post. > Here is the correct one. > > Rich > > On Mon, Apr 27, 2015 at 4:35 PM, Richard Bell > wrote: > >> Andy and all, >> >> Sorry for the delay in reply, I've been working hard to figure things out >> on my end. >> >> I use the polyphase clock recovery block for timing recovery. >> >> I have essentially copied the test_corr_est.grc example that was included >> with the block in the examples directory. It seems that this might not be >> the appropriate way to use this block. Here is why I say this. If you look >> at the attached screenshot, you will see the correlation output has two >> peaks, somewhat close in amplitude to each other. The synchronization >> sequence that was used to generate those peaks was 64 bits long and >> composed of two 32 bit long PN sequences repeated. Therefore, one would >> expect the output of the correlation to generate 3 peaks, a center peak >> that is ~64 units high, and two side peaks spaced 32 samples apart that are >> ~32 units high. >> >> Now, I believe the cause of this to be the use of the modulate vector >> block to generate the input mask for the correlation estimation block. I >> have attached a second screenshot of the output of the modulation vector >> block. You will see in this screen shot a large transient portion that is >> fed into the correlation estimation block. So, if we agree we should not >> use the modulate vector block to feed the correlation estimation block with >> its mask, then the question is how should I? An example what be most >> helpful. >> >> This is difficult to discuss because things get wordy very quickly. Let >> me know if I can make anything more clear. >> >> v/r, >> Rich >> >> On Fri, Apr 24, 2015 at 9:11 AM, Andy Walls >> wrote: >> >>> Hi Richard, >>> >>> > From: >>> > Richard Bell >>> > Subject: >>> > Re: [Discuss-gnuradio] Correlation >>> > Estimation Block Oddity >>> > Date: >>> > Thu, 23 Apr 2015 15:38:38 -0700 >>> > >>> > __ >>> > I have another question on tag placement for the correlation >>> > estimation block. In the screenshot I've attached, you'll see that the >>> > corr_start tag is placed well before the preamble actually starts. >>> >>> OK. That's the first thing you should try to fix. You are crossing the >>> correlation threshold too early. >>> >>> Either >>> >>> a. Get rid of leading 0's in the correlation sequence that you are >>> using, >>> b. Set the threshold on the corr_est block to something higher than the >>> default 0.9 (90%), or >>> c. make the correlation sequence "more unique" somehow, e.g. make it >>> longer. >>> >>> As I mentioned in my previous email, the "corr_start" tags is placed at >>> the length of your matched filter samples before where the correlation >>> peak was detected. >>> >>> You can eyeball how the correlation is going by plotting the Magnitude^2 >>> of the "corr" output on top of the output signal (use a tag_gate block >>> to block the tags coming out of the "corr" output). The output signal >>> is delayed by the length of the matched filter, so you can see the >>> correlation peak and the "corr_start" tag line up. >>> >>> See the attached screen shot of an AIS preamble and the scaled magnitude >>> squared of the correlator output. >>> >>> >>> > If I use the 'delay tag' field to move it to the end of the preamble >>> > where I need it, it stops delaying, no matter how big I make the >>> > delay, >>> >>> Yup, the code forces a maximum delay. You can delay it to the end of >>> your matched filter and no further: >>> >>> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/corr_est_cc_impl.cc#L65 >>> >>> The code does this because GnuRadio will not let us tag samples outside >>> of the window of samples passed to the current call to work. By setting >>> the bound of the marking delay to the start and end of the matched >>> filter, with other mechanisms in the block, we are guaranteed to be able >>> to mark the sample. >>> >>> > before it reaches the end of the preamble. >>> >>> Well as far as the block is concerned, you are able to mark to the end >>> of the matched filter where the correlation peak occurred (but no >>> further), which should be the end of your preamble. Your problem is >>> that the block declared a correlation too early. >>> >>> >>> > This is shown in the picture. I need this tag to denote the start of >>> > the header for the Header Payload Demux block. >>> >>> Out of curiosity, what's doing timing recovery, i.e. finding the optimal >>> b
Re: [Discuss-gnuradio] Correlation Estimation Block Oddity
On Tue, Apr 28, 2015 at 12:48 PM, Richard Bell wrote: > When you mentioned I should remove leading or trailing zeros from the > Correlation Estimator symbols field, how would you go about doing this if > you used the modulate vector block as done in the example? I'm stuck on > this. > The group delay in the pulse shaping filter (in this case, RRC) causes these leading zeros. This is something I'd like to figure out a "proper" solution for, but my quick hack that works pretty well is to duplicate the PN sequence as it goes into modulate_vector, then take only the second half of the samples of the output for the correlation block. This then "pre-fills" the filter with data that is arguably the right spectral shape, and the resulting second-half vector works much better than the original way. Again, this is a quick hack, but it works well. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
