Re: [Discuss-gnuradio] e100 OpenBTS Linux Kernel missing
On 11/15/2011 06:54 PM, Jacob Gilbert wrote: I was attempting to download the uImage linux kernel from the following website and got a dropbox 404 page. http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSE100 Is there a mirror or am I using an outdated e-100 OpenBTS page? usrp-users is a better place to ask this ... That said, Tom Tsou and I are looking at doing an update ASAP. Philip Thanks, Jacob ___ 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] dynamically changing delay in gr_delay (or history in any gr_block)
Marcus, The grc file that i sent does not support your theory: I have 2 filters: one with taps: (0,)*delay+(1,) and the other with taps (1,)+(0,)*delay then I can change the delay dynamically, which also means that the history is also changed dynamically (NOT ONLY AT INIT) and there is no problem whatsoever. Clearly the second filter is not needed but if i get rid of it then the whole thing does not work... I am really confused... Achilleas On Tue, Nov 15, 2011 at 6:21 PM, Marcus D. Leech mle...@ripnet.com wrote: On 11/15/2011 06:16 PM, Achilleas Anastasopoulos wrote: Take a look at the attached grc file: As implemented, it does not work (changing the delay does not have an effect). If I introduce the fictitious filter (1,0,0,0,0,..) it works as expected. AM I doing something wrong in the first case? Achilleas It seems that the runtime machinery pays attention to d_history *only* on block init, and at no other time, which leads to unexpected results. But, surely, this must have worked at some point? I mean, I regularly use filters whose parameters I change dynamically, and they apparently do what I want, although, perhaps at the moment of changing parameters, the phasing isn't right, but they seem to work. Someone with more exposure to the gr-runtime stuff should comment here. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org -- ___ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGAN Fax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: anas...@umich.edu URL: http://www.eecs.umich.edu/~anastas/ ___ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
On 11/15/2011 07:24 PM, Achilleas Anastasopoulos wrote: Marcus, The grc file that i sent does not support your theory: I have 2 filters: one with taps: (0,)*delay+(1,) and the other with taps (1,)+(0,)*delay then I can change the delay dynamically, which also means that the history is also changed dynamically (NOT ONLY AT INIT) and there is no problem whatsoever. Clearly the second filter is not needed but if i get rid of it then the whole thing does not work... I am really confused... Achilleas Yes, there's some deep weirdness. The only time the runtime pays attention to history, in my second pass through there, is in forecast() computations, via a little inlined function called history(), which just returns d_history. Not sure what this means. But clearly, there's some brokenness there, and it's not clear to *me* how to fix it, although I desperately want dynamically-settable gr_delay() blocks to work as well, for some interferometry work. -- 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
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
On Tue, Nov 15, 2011 at 16:44, Marcus D. Leech mle...@ripnet.com wrote: But clearly, there's some brokenness there, and it's not clear to *me* how to fix it, although I desperately want dynamically-settable gr_delay() blocks to work as well, for some interferometry work. Sorry, I've been buried in some commercial projects that haven't left me with much time to look at the issue more in depth. I can confirm that dynamically changing the delay in gr_delay does not (and never has) worked. The fix for this is not that complex but it would be a change in the runtime that would need a lot of regression testing. In the FIR-based delay scenario, it would be useful to know if there is a difference between changing the taps from, say [0, 0, 0, 0, 1] to [0, 0, 1], so the taps end up changing length, or changing the position of the 1 but leaving trailing 0's so the tap length would remain the same. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
On 11/15/2011 11:19 PM, Johnathan Corgan wrote: On Tue, Nov 15, 2011 at 16:44, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: But clearly, there's some brokenness there, and it's not clear to *me* how to fix it, although I desperately want dynamically-settable gr_delay() blocks to work as well, for some interferometry work. Sorry, I've been buried in some commercial projects that haven't left me with much time to look at the issue more in depth. What, you want to feed your kids in preference to helping a buncha feeloaders like us? :-) :-) -- 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] rx_callback with UHD
Hi, I want to modify benchmark_tx/rx.py for UHD In benchmark_tx.py, usrp_receive_path invokes rx_callback when receiving a signal I'm curious that it is also possible with uhd.usrp_source or not -- 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
Re: [Discuss-gnuradio] rx_callback with UHD
I want to modify benchmark_tx/rx.py for UHD http://gnuradio.org/cgit/gnuradio.git/tree/gr-digital/examples/narrowband ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_callback with UHD
Oh, thank you very much It seems its directory hierarchy is different from that of mine. I'm currently using 3.4.0 Is it new one for 3.5.0 ? 2011/11/16 Josh Blum j...@joshknows.com: I want to modify benchmark_tx/rx.py for UHD http://gnuradio.org/cgit/gnuradio.git/tree/gr-digital/examples/narrowband ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
On 11/15/2011 12:00 PM, Achilleas Anastasopoulos wrote: I made a simple example with a cosine and a delayed version of that going through a multiplier, and observing the output together with a slider that changes the delay dynamically. However i do not see any change (eg, elimination of the dc component when delay ~ pi/2). Looking at the code of the block gr_delay it shows that the delay can dynamically change and this results essentially in a call to set_history() in gr_block. Looking further into the set_history() method, it sets the private variable d_history. The question is: does the dynamic change of history have any effect in gr_block? What happens in the guts of the block when d_history changes? and why don't i see any effect in the example above? I dont think that set history works quite that way. I made a new delay block in gr-basic. Demo in GRC attached. Here is the implementation: http://gnuradio.org/cgit/jblum.git/tree/gr-basic/lib/gr_basic_delay.cc?h=gr_basic -Josh delaydemo.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 108, Issue 13
On Mon, Nov 14, 2011 at 06:32:01AM -0800, Ben Hilburn wrote: Bill, Automatic Modulation Classification (AMC) is still a heavily researched area, and you should be able to find hundreds of papers on the topic by searching IEEE for 'automatic modulation classification'. There are algorithms that use energy analysis, imaging techniques, cyclostationarity analysis, and many, many more. Yep, it's a massive and fun topic. If you want cyclostationary stuff, that was just added to the Spectral Estimation toolbox (on https://www.cgran.org/wiki/SpecEst) 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-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpk0IehK9Rhc.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP 1 and 2 Fuse replacement
Hi guys, we need to replace a Fuse in two USRP 1 and one USRP2 box. Can anybody tell me exactly which fuses we have to order? Regards Johannes Schmitz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP 1 and 2 Fuse replacement
We are located in Germany. Here in Farnell I can only find PANASONIC ERBRE4R00V would it be ok as well? For USRP2 I can find COOPER BUSSMANN - TR/3216FF4-R - FUSE, SMD, 4A, 1206, FAST ACTING so this should be fine. They broke over a longer period of time, mostly due to broken power supplies. But weren't replaced because we didn't need all of our USRP's for quite some time. For the USRP1, the fuse is: ERB-SE4R00U Available at digikey And for USRP2: TR/3216FF4-R Both available at DigiKey But I have to ask--how did you blow fuses on 3 of your devices? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP 1 and 2 Fuse replacement
Ok we just decided to order from DigiKey and take the parts that you have mentioned. For the USRP1, the fuse is: ERB-SE4R00U Available at digikey And for USRP2: TR/3216FF4-R Both available at DigiKey ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CYGWIN/X gnuradio
I have Linux hosts running gnuradio. Just wondering if CYGWIN/X environment was ever considered as a platform to run Gnuradio inside of the MS Windows environment. Does anyone have a working CYGWIN/X environment (as a X-Window server) connected through XDCMP to a Linux gnuradio host (X-Window client)? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CYGWIN/X gnuradio
On Tue, Nov 15, 2011 at 9:32 AM, Samudra Haque (SpaceQuest) samu...@spacequest.com wrote: I have Linux hosts running gnuradio. Just wondering if CYGWIN/X environment was ever considered as a platform to run Gnuradio inside of the MS Windows environment. Does anyone have a working CYGWIN/X environment (as a X-Window server) connected through XDCMP to a Linux gnuradio host (X-Window client)? Yes, with a bit of difficulty, GNU Radio will run in Cygwin and MinGW. On the other hand, the latest work in the 3.5 series natively builds with cmake in Windows with Visual Studio. I've not yet done this myself, but I've seen it working. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CYGWIN/X gnuradio
On 11/15/2011 07:15 AM, Tom Rondeau wrote: On Tue, Nov 15, 2011 at 9:32 AM, Samudra Haque (SpaceQuest) samu...@spacequest.com wrote: I have Linux hosts running gnuradio. Just wondering if CYGWIN/X environment was ever considered as a platform to run Gnuradio inside of the MS Windows environment. Does anyone have a working CYGWIN/X environment (as a X-Window server) connected through XDCMP to a Linux gnuradio host (X-Window client)? Yes, with a bit of difficulty, GNU Radio will run in Cygwin and MinGW. On the other hand, the latest work in the 3.5 series natively builds with cmake in Windows with Visual Studio. I've not yet done this myself, but I've seen it working. Build instructions http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork Here is an installer with instructions (a little stale) http://www.joshknows.com/gnuradio_port -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Install gnuradio on E100
On 11/14/2011 11:21 PM, Daniel Dekst wrote: Hi, All, I try to reinstall gnuradio (3.5.0rc0) on E100 with $ cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake ../ $ make I got errors when build gruel. How can I fix it? It looks like a problem with boost. If you grab the latest sd card image you should have much better luck. The gnuradio install was also build native on that very image so it should definitely work for you. http://comments.gmane.org/gmane.comp.hardware.usrp.e100/2021 Cheers, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to change SPI clock rate on USRP2?
Hi all, Is there a way to change the SPI clock rate on USRP2? (I am using uhd) I found a similar question for E100 here - http://comments.gmane.org/gmane.comp.hardware.usrp.e100/1257 . Is this solution applicable to USRP2 also? Also, I found some variable in - /firmware/zpu/lib/spi.c spi_regs-div = 1; // 0 = Div by 2 (25 MHz); 1 = Div-by-4 (12.5 MHz) Can I increase the value to 2? Will that make the clock speed 6.25 MHz? Thanks, Sriharsha Puranik. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
I made a simple example with a cosine and a delayed version of that going through a multiplier, and observing the output together with a slider that changes the delay dynamically. However i do not see any change (eg, elimination of the dc component when delay ~ pi/2). Looking at the code of the block gr_delay it shows that the delay can dynamically change and this results essentially in a call to set_history() in gr_block. Looking further into the set_history() method, it sets the private variable d_history. The question is: does the dynamic change of history have any effect in gr_block? What happens in the guts of the block when d_history changes? and why don't i see any effect in the example above? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
On 15/11/2011 3:00 PM, Achilleas Anastasopoulos wrote: I made a simple example with a cosine and a delayed version of that going through a multiplier, and observing the output together with a slider that changes the delay dynamically. However i do not see any change (eg, elimination of the dc component when delay ~ pi/2). Looking at the code of the block gr_delay it shows that the delay can dynamically change and this results essentially in a call to set_history() in gr_block. Looking further into the set_history() method, it sets the private variable d_history. The question is: does the dynamic change of history have any effect in gr_block? What happens in the guts of the block when d_history changes? and why don't i see any effect in the example above? thanks Achilleas I ran into the exact same thing a couple of weeks ago. It has to do with the deep-structure of the schedule, and Jonathan Corgan had indicated he was going to look into it. The weird thing is that FIR filters do the same thing when you change the number of tapes (muck with d_history), but they actually *work* dynamically after you change them. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
I actually tried using filters to implement the delay and they do NOT work as expected: I used Interpolating FIR filter with taps equal to (0,)*delay+(1,) and i didn't see any difference as i was changing the delay parameter dynamically Achilleas On Tue, Nov 15, 2011 at 3:05 PM, Marcus D. Leech mle...@ripnet.com wrote: On 15/11/2011 3:00 PM, Achilleas Anastasopoulos wrote: I made a simple example with a cosine and a delayed version of that going through a multiplier, and observing the output together with a slider that changes the delay dynamically. However i do not see any change (eg, elimination of the dc component when delay ~ pi/2). Looking at the code of the block gr_delay it shows that the delay can dynamically change and this results essentially in a call to set_history() in gr_block. Looking further into the set_history() method, it sets the private variable d_history. The question is: does the dynamic change of history have any effect in gr_block? What happens in the guts of the block when d_history changes? and why don't i see any effect in the example above? thanks Achilleas I ran into the exact same thing a couple of weeks ago. It has to do with the deep-structure of the schedule, and Jonathan Corgan had indicated he was going to look into it. The weird thing is that FIR filters do the same thing when you change the number of tapes (muck with d_history), but they actually *work* dynamically after you change them. -- ___ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGAN Fax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: anas...@umich.edu URL: http://www.eecs.umich.edu/~anastas/ ___ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
On 11/15/2011 05:01 PM, Achilleas Anastasopoulos wrote: I actually tried using filters to implement the delay and they do NOT work as expected: I used Interpolating FIR filter with taps equal to (0,)*delay+(1,) and i didn't see any difference as i was changing the delay parameter dynamically Achilleas The filtering still seems to work, but the delay (based on d_history) appears not to. -- 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
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
Take a look at the attached grc file: As implemented, it does not work (changing the delay does not have an effect). If I introduce the fictitious filter (1,0,0,0,0,..) it works as expected. AM I doing something wrong in the first case? Achilleas On Tue, Nov 15, 2011 at 5:26 PM, Marcus D. Leech mle...@ripnet.com wrote: On 11/15/2011 05:01 PM, Achilleas Anastasopoulos wrote: I actually tried using filters to implement the delay and they do NOT work as expected: I used Interpolating FIR filter with taps equal to (0,)*delay+(1,) and i didn't see any difference as i was changing the delay parameter dynamically Achilleas The filtering still seems to work, but the delay (based on d_history) appears not to. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org -- ___ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGAN Fax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: anas...@umich.edu URL: http://www.eecs.umich.edu/~anastas/ ___ test_delay.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)
On 11/15/2011 06:16 PM, Achilleas Anastasopoulos wrote: Take a look at the attached grc file: As implemented, it does not work (changing the delay does not have an effect). If I introduce the fictitious filter (1,0,0,0,0,..) it works as expected. AM I doing something wrong in the first case? Achilleas It seems that the runtime machinery pays attention to d_history *only* on block init, and at no other time, which leads to unexpected results. But, surely, this must have worked at some point? I mean, I regularly use filters whose parameters I change dynamically, and they apparently do what I want, although, perhaps at the moment of changing parameters, the phasing isn't right, but they seem to work. Someone with more exposure to the gr-runtime stuff should comment here. -- 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] e100 OpenBTS Linux Kernel missing
I was attempting to download the uImage linux kernel from the following website and got a dropbox 404 page. http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSE100 Is there a mirror or am I using an outdated e-100 OpenBTS page? Thanks, Jacob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
