Re: [Discuss-gnuradio] Costas loop and MM algorithm on FPGA
Hello Phone Do you have a git repo that one might throw in ones two coppers? Best Paul 2011/12/15 Phone Naing MYINT phonenaing.my...@sg.panasonic.com Hi, Anyone here implemented freq/phase correction and symbol timing correction in USRP's FPGA? Recently I implemented Costas loop and Muller Mueller algorithm in RTL by referring the gnuradio code. Now I'm testing it on FPGA. I can get correct demodulated data(DQPSK) at initial few thousand symbols. After that I'm getting all rubbish data. I think the problem with my RTL implementation is not good enough bit-resolution (unlike implementation on PC). Currently I'm using 15-bits resolution for decimal part. Anyone has any suggestion ? PN ___ 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] Costas loop and MM algorithm on FPGA
Hi Phone No, but I am very interested :D From your original post it might seem that fresh eyes might hit the spot. I'm more of a VHDL guy, so I might not be too much of a help. I just thought that others might have a better chance of helping if they could see the code. Best Paul 2011/12/15 Phone Naing MYINT phonenaing.my...@sg.panasonic.com Hi Paul, I do not have one. Do you implemented them before? PN *From:* discuss-gnuradio-bounces+phonenaing.myint=sg.panasonic@gnu.org[mailto: discuss-gnuradio-bounces+phonenaing.myint=sg.panasonic@gnu.org] *On Behalf Of *Paul M. Bendixen *Sent:* Thursday, December 15, 2011 4:48 PM *To:* GNURadio Discussion List *Subject:* Re: [Discuss-gnuradio] Costas loop and MM algorithm on FPGA Hello Phone Do you have a git repo that one might throw in ones two coppers? Best Paul 2011/12/15 Phone Naing MYINT phonenaing.my...@sg.panasonic.com Hi, Anyone here implemented freq/phase correction and symbol timing correction in USRP's FPGA? Recently I implemented Costas loop and Muller Mueller algorithm in RTL by referring the gnuradio code. Now I'm testing it on FPGA. I can get correct demodulated data(DQPSK) at initial few thousand symbols. After that I'm getting all rubbish data. I think the problem with my RTL implementation is not good enough bit-resolution (unlike implementation on PC). Currently I'm using 15-bits resolution for decimal part. Anyone has any suggestion ? PN ___ 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] Default antenna with RFX2400
2011/12/13 Josh Blum j...@ettus.com On 12/12/2011 08:25 PM, Phone Naing MYINT wrote: Hi, TX is clear, defaulted to TX/RX. RX default to direct conversion, what does it mean? RFX2400 is a direct conversion receiver *and* a direct conversion transmitter. What the docs really should say: 1) When you tune the transmit chain, the default behaviour is to tune the LO away from the desired center frequency. 2) When you tune the receive chain, the default behavior is to tune the LO as close as possible to the desired center frequency. You can of course, override this behavior: http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes I would personally reccomend you to use this (and scrap GRC) as soon as possible. The RFX2400 board has some problems selecting a center frequency far enough off, and you might run into trouble if you are using a digital modulation (You can see some of my earlier posts on this) For receive, using TX/RX or RX2 provides same performance? TXRX vs RX2 is just a simple switch. You must pick what is most useful for your application (full vs half duplex). Obviously, for a receive-only application, either antenna option is good. If you use the TX/RX as a receiver, you will notice a small attenuation (~2dB) compared to using RX2. Also remark, that the attenuation between TX/RX when transmitting and RX2 is ~65 dB. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DPSK Block - Verifying Received Message
2011/12/9 John Malsbury john.malsb...@ettus.com Domenic, Whenever you are transferring data from a transmitter to a receiver it is reasonable to use some sort of framing. If you want a quick test, use a packet encoder and decoder on your transmitter and receiver, respectively. This will packetize the data and eliminate the continuous flow of garbage data to your file since the decoder will only output data from valid packets(w/ header + crc are removed). Bit errors will manifest themselves as a short file, since bad packets will be discarded. If you run the block in verbose mode there may also be reporting for when packets are discarded. Set the payload length number in the encoder so you have a known relationship between the number of bytes missing from the file and the number of packet errors. There are numerous ways to improve this simple test, but this is a start for you. Also, you may want to perform a more fundamental bit error test. See error rate block. Just a word of warning: If you use the package en/decoder and the BER block , it might just go haywire The BER block cannot regain from a missing frame (which would be the case if the framer threw it away) -J On 12/09/2011 07:29 AM, Domenic Magazu III wrote: All, I was playing around with the DPSK block provided with GNU Radio. I was able to get my two USRPs talking to each other. I placed a file sink on the random source generator (set to transmit 10 random binary digits) and I'm able to see what was actually sent from that file (command: od -d filename.bin). I was curious how I go about verifying that the message in my filename.bin is received as transmitted on the other end? I tried placing a file sink on the DPSK demod block however because the receiver is constantly pulling in information my file becomes extremely large and it's difficult to determine where the message would be amongst the other 'noise'. Does anyone have any ideas on how to verify my transmitted message is making it to my receiver? Thank you Domenic ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build-gnuradio needs updates
On my Gentoo system, I also get the Udev errors, I don't know where excacly this comes from (but it is annoying). It might be part of the build system of the UHD driver, since I haven't tried using the script. Best Paul 2011/12/2 Marcus D. Leech mle...@ripnet.com On 2-12-2011 10:06 AM, alick wrote: Hi all, I am a newcomer here. I previously use the build-gnuradio script to get a modern version of gnuradio and UHD. The script did a great job. But I guess some (small) updates are needed. One is related to udev conf. I saw the warning while booting my OS (Fedora 14): Starting udev: udevd[584]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/10-usrp.rules:3 I searched the web and this page[1] suggests that substitution will work. But I'm not sure. Another is with the latest Fedora 16. I plan to upgrade my OS in a few days(maybe just tomorrow), and the current script only supports up to Fedora 15... [1] http://sdrblog.wordpress.com/gnuradio-installation/ I don't have any plans to immediately support F16. If you, or someone else, wants to send patches, I'm happy to merge them in. I don't own any F16 systems myself, and don't have immediate plans to upgrade. ___ 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] UHD vs. USRP2 driver questions
2011/11/29 Kevin Tien kvn.t...@gmail.com
Hi,
We're using USRP2s with the RFX2400 daughterboards, and we've recently
switched from the old USRP drivers to the UHD drivers as per general
recommendation. However, we've run into a few problems that have us
stumped:
1) Previously, our receiver gains were set to 0 dB and we had no
problem receiving a signal with 30 or 40 dB SNR. However, now the UHD
receiver blocks need specified gain around 30 or 40 dB to achieve this
same performance; did baseline values change?
As far as I remember, there was something about the old driver sending out
signals that were ints
The new driver sends and receives +/- 1, so you will need some more gain
(38 dB I believe somone calculated)
2) As far as we can tell through searching the Internet, the sampling
rate in the Tx/Rx blocks has replaced the decimation and interpolation
fields from the legacy blocks. But what exactly are we specifying with
the sampling rate now? Is it the sampling rate the rate at which the
transmitter transmits samples, with interpolation assumed if the data
going into the block isn't throttled? In which case, would higher
sampling rate imply lower 'interpolation' rate? Bottom line, we have
no idea how to play around with the sample rate, or how important it
is.
The UHD driver sets up the interpolation rate for you.
It will select the interpolation rate most appropriatly close to 100MHz /
requestedSamplerate
With the caveat that it first checks if it is dividable by two(for the
first hb filter), if that result is dividable by two( for the second hb
filter) and if the final result is less than 128 (for the CIC) it will be
set.
If you select an unobtainable sampling rate, the output will tell you.
in pseudocode:
%% Mechanism for chosing HB filters and interprate %%%
%% root / host / lib / usrp / cores / tx_dsp_core_200.cpp
%
% if (interp_rate 128) interp_rate = ~0x1;//CIC up to 128, have to use 1
HB
% if (interp_rate 256) interp_rate = ~0x3;//CIC up to 128, have to use 2
HB
% size_t interp = interp_rate;
%
% //determine which half-band filters are activated
% int hb0 = 0, hb1 = 0;
% if (interp % 2 == 0)
% {
% hb0 = 1;
% interp /= 2;
% }
% if (interp % 2 == 0)
% {
% hb1 = 1;
% interp /= 2;
% }
%%
Thanks for your help,
Kevin Tien
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Best
Paul
--
* - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *-
*/- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRUG meeting tonight!
Damn it! Why couldn't you have put this up yestoday? Now it's too late to book the flight from Denmark ;) Have a good one Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP N210 Benchmarks.
Hi Nick Thank you for looking into this. 2011/11/26 Nick Foster n...@ettus.com On Thu, Nov 24, 2011 at 5:59 AM, Paul M. Bendixen paulbendi...@gmail.com wrote: Hi again Thank you very much, we expect our thesis will be available from some time next year, we will add it to the academic section. The work we have done so far have pointed us to the daughterboard mixer. All mixers have problems causing harmonics, and our research so far has shown us that this is the big problem. The work with gain adjusting the I Q channels in the drivers give us an idea we might be right ;) Can you give more details? If you can, please post your measurements which lead to this conclusion. We did a couple of measurements just around the 2,4 GHz mark. The reason we thought it might be the daughterboard mixer is that the problem arose whether we used a 2,4003 GHz carrier and a zero cosine or a 2,4GHz carrier and a 300kHz cosine. Since the mixer stage in the DAC is not activated (that we can see, is this a future possibility?) the (~only) next stage is the daughterboard mixer. The included picture is a 2,401GHz carrier, no cosine frequency into a N210_r3 using an RFX2400, 42dB attenuator on a cable to a RhodeSwartz Spectrum analyser. If you compare the peaks to the datasheet, you will see they are almost identical (bear in mind that the datasheet uses LSB and we use USB). This is in the very part where IQ imbalance is presented. Employing the auto calibration might help reduce the peaks. (when the RFX2400 gets support) We have spent a good while describing what frequencies the osclilator on the daughterboard can supply. When in auto mode, the UHD driver will try to select a frequency that is offset, so that an actual direct up/down conversion does not take place. This is what is normally known as the Superheterodyne radio. However, because of the division of labour between the mixer in the FPGA and the mixer on the daughterboard, the IF frequency selected is often too close to the daughterboard mixer frequency. This results in quite a bit of nasty spikes around the desired signal. There are two ways of testing this: 1: the scientific) Try sending out a single frequency, a flowgraph of [complex cosine] - [UHD Sink] was good enough for us. Check out what spurious frequencies are created. You will typically see the wanted signal (f_c +/- f_s), a bit of the _actual_ carrier (f_c) and mirrors of different description. (eg f_c +/- 2*f_s ; f_c -/+ f_s). Increasing the signal frequency(f_s) will reveal which is the oscilator(f_c) and which is the mirror. Page 19 of the AD8349 (mixer for the RFX2400) showed part of this explanation. 2: the mechanics version) Try other frequencies, maybe you will get lucky ;) One other method might be to write all or parts of the application in C++, that way you should be able to select a mixer frequency far away from the one you need (the N210 FPGA mixer can provide +/- 50MHz offset, i believe the USRP1 can supply +/- 32MHz). This way you should be able to reduce the spurious emissions. You can use the advanced tuning parameters in Python as well. No need for C++ if you don't want it. You can pick whatever LO offset frequency you like. http://files.ettus.com/uhd_docs/manual/html/general.html OK, thank you, if we have the time before deadline, we will check this out. We have been using the GRC exclusively. The problem using this approach is that you will send the spurious emissions into other parts of the band (the problem with having a narrow signal in a wide-band application). You will have this issue with essentially any direct-conversion transceiver which has an open (or reasonably open) front end. Exactly. As I mentioned in the second paragraph ;) Our best bet as I see it, is to use a quasi-superhetrodyne approach, where possible. Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// attachment: BT_2401MHz_500KHz_samprate.png___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP N210 Benchmarks.
Hi again Thank you very much, we expect our thesis will be available from some time next year, we will add it to the academic section. The work we have done so far have pointed us to the daughterboard mixer. All mixers have problems causing harmonics, and our research so far has shown us that this is the big problem. The work with gain adjusting the I Q channels in the drivers give us an idea we might be right ;) We have spent a good while describing what frequencies the osclilator on the daughterboard can supply. When in auto mode, the UHD driver will try to select a frequency that is offset, so that an actual direct up/down conversion does not take place. This is what is normally known as the Superheterodyne radio. However, because of the division of labour between the mixer in the FPGA and the mixer on the daughterboard, the IF frequency selected is often too close to the daughterboard mixer frequency. This results in quite a bit of nasty spikes around the desired signal. There are two ways of testing this: 1: the scientific) Try sending out a single frequency, a flowgraph of [complex cosine] - [UHD Sink] was good enough for us. Check out what spurious frequencies are created. You will typically see the wanted signal (f_c +/- f_s), a bit of the _actual_ carrier (f_c) and mirrors of different description. (eg f_c +/- 2*f_s ; f_c -/+ f_s). Increasing the signal frequency(f_s) will reveal which is the oscilator(f_c) and which is the mirror. Page 19 of the AD8349 (mixer for the RFX2400) showed part of this explanation. 2: the mechanics version) Try other frequencies, maybe you will get lucky ;) One other method might be to write all or parts of the application in C++, that way you should be able to select a mixer frequency far away from the one you need (the N210 FPGA mixer can provide +/- 50MHz offset, i believe the USRP1 can supply +/- 32MHz). This way you should be able to reduce the spurious emissions. The problem using this approach is that you will send the spurious emissions into other parts of the band (the problem with having a narrow signal in a wide-band application). Best Paul 2011/11/23 Justyn Bell jbell...@gmail.com On Tue, Nov 22, 2011 at 3:54 PM, Justyn Bell jbell...@gmail.com wrote: Hey guys, sorry for the extremely late response. Although identifying and solving USRP problems is great, our focus lies in the project at hand. That being said, the responses on here were great. We tried scaling the input signal magnitude and it actually worked very well. The perplexing thing, however, is that the more we scale the magnitude, the better the observable spectrum got. There was no point in which scaling the magnitude didn't show at least a little improvement on the spectrum. I have attached the spectrum of our actual P25 waveform with scaling. Also included in that figure (yellow) is a signal captured by the USRP that was transmitted using an EF Johnson handset with a P25 waveform installed. Clearly the EF Johnson's spectrum looks the best, and although we didn't try scaling our data further than by .0625, the signal decreases in strength. At some point the signal must be too weak to transmit without both compromising the SNR and the granularity or resolution of the original signal (if that's the appropriate word to use). The biggest thing I am considering is this: we are using a 12.5kHz channel on a daughterboard whose range is between 50MHz to 2.2GHz. Is such a narrowband signal on such a wide band board problematic? Although the spectrum looks great when scaled, when we actually test our waveform from USRP to USRP we still get bit errors. Again, it's hard to say how many because we are utilizing a waveform that is equipped with a software vocoder, encryption (small bit errors mean huge losses in packets we receive) and forward error correction (should eliminate small bit errors). You can see how it is difficult to track down bit errors, but my personal opinion is that with forward error correction and the boxes sitting no more than 4 feet away from each other, there are enough errors to ruin our encrypted messages, and that's just too much. We would very much like to use the very descriptive images you have provided in our work, if that's okay with you. This is completely fine with all of us here, and thanks again for great responses. With the availability of so many USRPs (did I mention we have 2 USRP1s with the RFX daughterboards in them?) we can at least narrow things down a bit. On Fri, Oct 28, 2011 at 5:08 AM, Marcus D. Leech mle...@ripnet.comwrote: 2011/10/27 Marcus D. Leech mle...@ripnet.com Well, that sounds like the lazy solution, intermodulation products are bad, so just throwing the transmitter power away is not what I'd prefer. But what it points to is an *analog* issue, entirely independant of the CORDIC (which, as I observe, isn't likely involved in the test cases at hand here). Analog
Re: [Discuss-gnuradio] N210, About Decimation Rate
Forgot the list :) The quick answer is: It's done for you the formula is: decimationrate = iround(tick_rate/sample_rate); where tick_rate = 100e6, and sample_rate is the sample rate you set. It will only allow accurate matches of the decimation rate, otherwise it will tell you what sample rate it wants to go at. Best Paul 2011/11/24 Sebastian Döring sdoer...@rhrk.uni-kl.de Hello List, I have a short question about the decimation rate of the USRP N210 : Since I know that the decimation rate of the N-Series is supposed to be programmable and that one was able to change it using the usrp_rx_cfile.py-script, why is this option missing in the UHD-Version of this script? Regards Sebastian ___ 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] Simulation of TX_path
Hello all In order to simulate the Tx path in the FPGA we need to get a few things clarified. How is the interpolation rate chosen with a known Sample rate and Transmission frequency. I am using an N210 and i know how the Interpolations rates are used in %root/host/lib/usrp/cores/tx_dsp_core_200.cpp Where the filters are enabled, but where does it get the interpolation value from, and what about the interpolation value of the DAC, this is set to 1 or 4 depending on (freq/tickrate) . When i select a sample rate and carrier frequency in GNU radio, what is the corresponding tick rate, Interpolation rate and DAC settings. What are the formulas for this, or where precisely can i get this information? Futhermore i want to know if the tickrate mentioned in the code is the CLK signal for the FPGA running at 100MHz. This is not clear to me because this is somehow connected to master clock rate. And this is only documented as avalible if Hardware changes have been made, see root/host/include/uhd/usrp/multi_usrp.hpp We are getting lost in the massive amount of undocumented and uncommented Verilog and C++ code. Best Paul M. B. -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP N210 Benchmarks.
2011/10/27 Marcus D. Leech mle...@ripnet.com Well, that sounds like the lazy solution, intermodulation products are bad, so just throwing the transmitter power away is not what I'd prefer. But what it points to is an *analog* issue, entirely independant of the CORDIC (which, as I observe, isn't likely involved in the test cases at hand here). Analog gain elements (including DACs) have operating regions over which they're linear, and operating regions over which they're not linear. If you drive any amplifier near its maximum operating point, it will start to become non-linear to one degree or another. I'll let Matt or one of the other engineering folks at Ettus comment further, but I personally am totally unsurprised when things start to become non-linear near the nominal maximum operating point. Is there any way of finding out what the resolution is? We haven't been able to track it down for the RFX2400 board, but this sounds like a nice way to test if it _is_ the CORDIC. Look at the tune_result_t from tuning: http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__result__t.html If the actual_dsp_freq is 0, then the CORDIC wasn't involved. I tuned to an even number of MHz, which on all of the synthesizers *should* yield 0 CORDIC frequency. But maybe Josh can add a feature to 'uhd_usrp_probe' to display the PLL resolution (although in some cases, it may change with target frequency range, I think). Thank yo very much for this, It is really usefull, and it furthermore confirms what we have observed. At 2.4GHz there is no problems, when we go 300 kHz up, we start seeing the problems. (see images attached) This is further collaborated, with the fact that we can find good frequencies up through the entire band. Only problem there is that there is a 55 dB loop back between the in and output of the RFX2400 board, so two different radios are needed. You're talking about the combined isolation of the two RF switches in the path between the TX and RX? That's adequate attenuation for the tests I'm suggesting. I think I prefer our measurement equipment at the University We have observed this as well, but as described before we do not find this to be the correct solution. I'm keen to hear what your correct solution is to the problem of non-linearity in off-the-shelf analog gain devices. I suspect the solution won't be in the digital domain, but I'm always willing to be surprised. I have implemented the cordic in vhdl now, this should reduce the phase error (which is also mentioned in the pdf you referenced) because of the ability to increase the CORDIC stages. I am now just waiting for a Xilinx license. Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP N210 Benchmarks.
Hello to you too At our university we have seen this behaviour as well. Our setup is a USRP N210 with a 2400 daughterboard into a Rhode Swartz spectrum analyzer. We also get these sidelobes, and if you trawl the archives, you will find others have as well. Currently we are working on a theory that it might be the CORDIC algorithm in the FPGA that causes the disturbance. I have managed to create Matlab and Python code showing some of the same characteristics, and am currently working on implementing this into a block, so that a channel model can be done. I believe the reason is the way the CORDIC algorithm is implemented. In the verilog code, there are two hints that it might be written better, but that it is difficult because of the verilog language. It is however almost trivial using VHDL, so I am currently considering rewriting the CORDIC in VHDL, although this will probably not be untill we have handed in our Masters Thesis (The main object of the thesis is not correcting possible errors, but documenting their impact). We would very much like to use the very descriptive images you have provided in our work, if that's okay with you. Best Regards Paul M. Bendixen Stud. Scient EE 2011/10/26 justynnuff jbell...@gmail.com Hello all: We have been working on an APCO P25 project at my university, and are fortunate enough to have 4 USRP N210's all equipped with the WBX boards. As the project has progressed we have accomplished many of our goals. However, one thing that has haunted us throughout the entire project is transmission from USRP to USRP results in very high bit errors. We also have 2 P25 handsets available and when Tx'ing from a handset and receiving from a USRP or Tx'ing from the USRP and receiving from a handset, everything is fine, we have no perceivable bit errors (we haven't really dug into the exact bit error measurements, however, we are working with a DVSI AMBE vocoder/FEC, which implies the bit errors are large enough to screw up the error correction, which, no matter how you cut it, shouldn't happen with two USRP's 2 feet from each other). So we ran some tests with the 4 USRP's We used a two-tone test at +1kHz and -2kHz. We used GNU Radio and GRC with a fairly simple set up that consisted of reading the MATLAB generated two-tone sample data using the file source block into the UHD USRP sink. On the Rx end, it was the same, but reversed. I have supplied figures of the received data, but guessed the GRC setup code isn't necessary. In the first figure, we saw that using the same USRP for Tx and switching USRP's on the Rx end resulted in very odd data. In the second, we used USRP 1 to Tx and 2 to Rx (what we believe to be the worst USRP's in the bundle) and attached them to an external clock. It can be seen that as far as the two tone test goes, the peaks were right on the money. Another thing we noted is that by changing the gain on the Tx end, the harmonics shown don't scale with the power. At low power, the harmonics are far too close to the main peaks, which is worrying (initially we had the gain of the USRPs marginally under the maximum gain because we initially thought the errors were caused by the RF front end going into some kind of saturation state. From this data we see this isn't the case). Also of note is that at the time the first figure was generated, the USRP's were approximately 2 feet from each other. In the latter figure, they were about 5 feet apart. It is obvious that the harmonics in the second figure are higher, relative to the main peaks, than the first. I don't really have a solid question to ask other than is this behavior normal? It is apparent that the poor results in the first figure are caused by clock drift, but the harmonics are also very worrying. Especially USRP 4 in the first figure, which shows a relatively high harmonic right next to the main peaks. Since the time we have sampled the supplied data, we have been progressing forward in the project, so we haven't been able to test the P25 waveform from USRP to USRP, and can't verify that the initial bit error problems are alleviated by getting rid of the clock drift, or if they are caused by the harmonics. Is there something we can do to remedy this problem, or, again, is this behavior normal? http://old.nabble.com/file/p32726685/Rx_DualTone_1.jpg http://old.nabble.com/file/p32726685/external_clock_dual_tone.jpg -- View this message in context: http://old.nabble.com/USRP-N210-Benchmarks.-tp32726685p32726685.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP N210 Benchmarks.
Hello 2011/10/27 Marcus D. Leech mle...@ripnet.com The attached two_tone flow-graph shows that close-in intermod products are sensitive to overall signal magnitude settings. Keep the digitla signal magnitudes lower, and the intermod products are quite well suppressed. The flow-graph is setup for a WBX for the antenna settings. Well, that sounds like the lazy solution, intermodulation products are bad, so just throwing the transmitter power away is not what I'd prefer. Keep in mind that the CORDIC is used only when the desired target frequency is not a multiple of the resolution of the PLL synthesizer on whatever daughtercard you're using, otherwise the CORDIC NCO doesn't do anything to the signal. Is there any way of finding out what the resolution is? We haven't been able to track it down for the RFX2400 board, but this sounds like a nice way to test if it _is_ the CORDIC. Connect the TX/RX port to the RX2 port through a 60dB attenuator, so you can use the RX side to monitor the spectrum of the TX side. The RX-side bandwidth is set to 50Khz total, which gives you a good close-in view of the spectrum around the +/- 1Khz tones. Vary the digital gain control, and observe intermod peaks around the fundamental tones, and observe that at digital gains below 0.250, the intermod peaks become well suppressed (about 45dB down from the fundamental tones). Only problem there is that there is a 55 dB loop back between the in and output of the RFX2400 board, so two different radios are needed. We have observed this as well, but as described before we do not find this to be the correct solution. About the disabling of the CORDIC, I do not currently have a Xilinx ISE licence, but have instigated measures to get one. When I (hopefully) do, I will try out both cutting it out and using an optimized one, written in VHDL. Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble with multiple installs or how i learned to love make uninstall
So I started today off by doing a make uninstall on the gentoo box. Then I went hunting. As it turns out, I had to manually remove 3.5.0git files from a lot of the locations mentioned in the post concerning the WX Gui problem ( http://lists.gnu.org/archive/html/discuss-gnuradio/2011-10/msg00355.html). After removing these (along with a set of old installation files) i tried rebuilding. (after git clean -dfx; git pull) Only error i got was: .../git/uhd/firmware/zpu/lwip/lwip-1.3.1/src/include/lwip/memp.h:45: Warning: include file lwip/memp_std.h not found, perhaps you forgot to add its directory to INCLUDE_PATH? with some warnings that: Warning: explicit link request to 'define' could not be resolved in the zpu firmware image. It all works fine now, however due to moving around (i guess) i get a lot of warnings like: Error: Connection between gr_interleave_0(0) and blks2_ofdm_mod_0(0) could not be made. sink block id blks2_ofdm_mod_0 not in block ids in gnuradio-companion When I use the modulation-gmsk it results in the error: self.blks2_gmsk_mod_0 = blks2.gmsk_mod( AttributeError: 'module' object has no attribute 'gmsk_mod' which is correct, it is now in digital. Should this be fixed or are the XML files that grc uses not fully updated? If so, should the git clean -dfx not have fixed this? The last example is the same on the xubuntu box (which was installed using the new build-gnuradio script). Maybe I should start splitting this out into different mails? Best Paul 2011/10/25 Tom Rondeau trondeau1...@gmail.com On Tue, Oct 25, 2011 at 12:19 PM, Paul M. Bendixen paulbendi...@gmail.com wrote: Hello It seems it might be a good idea if it were possible to uninstall gnuradio propper. I currently have two systems faling (hard) using the new build. My gentoo box (configured using cmake in another thread) gives me the error : ImportError: libgruel-3.4.2git.so.0: cannot open shared object file: No such file or directory Whenever i try from gnuradio import digital. funny part is: I never succeeded in installing 3.4.2, so I don't blame it for not finding it. I tried doing a manual ldconfig, but it didn't seem to do the trick. On an ubuntu machine (xubuntu to be specific) using the build-gnuradio script, most of the digital schemes fails due to the reallocation of packets to digital. This includes stuff that should be updated. Is it possible that the python stuff does not get properly updated and is there any way to fix this? Downgrading, by adding a git checkout v3.4.2 fixes makes the build run fine again. On both systems the building of the system is without problems. make uninstall does work and removes all of the GNU Radio files from the system. The twist that you need to remember is that you have to do it BEFORE upgrading to a new version. The 3.5 will try to uninstall it's stuff, which will be different from 3.4. So you have to have to run 'make uninstall' when you've configured for what's installed on your system. Then you can upgrade and shouldn't have any conflicts. When you say that you didn't have 3.4.2 installed, do you mean that you never installed from master before? For the past few weeks, the master branch reflected the 3.4.2, so any installs will have that in their name. You did help me find a bug in our cmake install, though. Some of our specially-built files are not being removed by uninstall. Tom -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Errors of missing modulators in gnuradio-companion
Did a little more digging cd [gitdir]/grc/ find . -name * | xargs grep digital Returns nothing, on the other hand grepping blks2.gmsk_mod returns: ./Makefile.am: blks2_gmsk_mod.xml \ ./block_tree.xml: blockblks2_gmsk_mod/block ./blks2_gmsk_mod.xml: keyblks2_gmsk_mod/key ./blks2_gmsk_mod.xml: makeblks2.gmsk_mod( In other words: the XML structure of the grc that has to do with anything moved to digital must be updated, before 3.5 can be compared to a stable environment. XML has never been my strong suit, so I won't start looking into it. Furthermore some of the blocks have changed input parameters (e.g. gmsk_demod). Perhaps merging next into master was a little premature? Best regards Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Errors of missing modulators in gnuradio-companion
Thanks, building now Just one thing, shouldn't the xml files go into /gr-digital/grc/ like the other blocks instead of /gr-digital all by them selves? Will get back to you on how it went. Best Paul 2011/10/26 Tom Rondeau trondeau1...@gmail.com The master branch has been updated with the fixes to the GRC blocks. Thanks again for the reports! Tom On Wed, Oct 26, 2011 at 7:55 AM, Tom Rondeau trondeau1...@gmail.comwrote: On Wed, Oct 26, 2011 at 7:49 AM, Paul M. Bendixen paulbendi...@gmail.com wrote: Did a little more digging cd [gitdir]/grc/ find . -name * | xargs grep digital Returns nothing, on the other hand grepping blks2.gmsk_mod returns: ./Makefile.am: blks2_gmsk_mod.xml \ ./block_tree.xml: blockblks2_gmsk_mod/block ./blks2_gmsk_mod.xml: keyblks2_gmsk_mod/key ./blks2_gmsk_mod.xml: makeblks2.gmsk_mod( Fixing these now. About to push the patch. In other words: the XML structure of the grc that has to do with anything moved to digital must be updated, before 3.5 can be compared to a stable environment. XML has never been my strong suit, so I won't start looking into it. Furthermore some of the blocks have changed input parameters (e.g. gmsk_demod). Perhaps merging next into master was a little premature? Best regards Paul I don't think so at all. The problem is there are no automated test for this kind of stuff, and there's a lot of code that's of concern here. The only way we could get these kinds of error reports was to get the real users of GNU Radio to test them. These problems have been around in the old 'next' branch for a while, but without being used, there was no way for us to get these kinds of bug reports that is allowing us to fix them. In other words, I really appreciate you checking these things out and reporting the errors. This is also why we have stable releases. For people who have environments where stability is a concern, they should stick with the releases. I went through and checked the GRC blocks against everything I moved into gr-digital, so hopefully there is nothing left that I missed. I wonder if we can make a piece of automatic test code that would try to load each of the GRC XML blocks and report an error if it can't be loaded properly? Thanks! Let me know if you find anything else. Tom -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Errors of missing modulators in gnuradio-companion
Compiling done. So a grep for blocks that are only in digital in the grc files showed that mpsk_sync_cc and cvsd_decode and encode are still missing. Oh, and a minor glitch: it seems that putting the blocks in gr-digital instead of gr-digital/grc made it disappear from grc's view (at least with the new build it's nowhere to be found). During startup, the following warnings pop up: Warning: Block key digital_gmskmod_bc not found when loading category tree. Warning: Block key digital_cpmmod_bc not found when loading category tree. Warning: Block key digital_gmsk_mod not found when loading category tree. Warning: Block key digital_gmsk_demod not found when loading category tree. cpmmod_bc however is in the right place, so I can't comment on that. Best Paul 2011/10/26 Paul M. Bendixen paulbendi...@gmail.com Thanks, building now Just one thing, shouldn't the xml files go into /gr-digital/grc/ like the other blocks instead of /gr-digital all by them selves? Will get back to you on how it went. Best Paul 2011/10/26 Tom Rondeau trondeau1...@gmail.com The master branch has been updated with the fixes to the GRC blocks. Thanks again for the reports! Tom On Wed, Oct 26, 2011 at 7:55 AM, Tom Rondeau trondeau1...@gmail.comwrote: On Wed, Oct 26, 2011 at 7:49 AM, Paul M. Bendixen paulbendi...@gmail.com wrote: Did a little more digging cd [gitdir]/grc/ find . -name * | xargs grep digital Returns nothing, on the other hand grepping blks2.gmsk_mod returns: ./Makefile.am: blks2_gmsk_mod.xml \ ./block_tree.xml: blockblks2_gmsk_mod/block ./blks2_gmsk_mod.xml: keyblks2_gmsk_mod/key ./blks2_gmsk_mod.xml: makeblks2.gmsk_mod( Fixing these now. About to push the patch. In other words: the XML structure of the grc that has to do with anything moved to digital must be updated, before 3.5 can be compared to a stable environment. XML has never been my strong suit, so I won't start looking into it. Furthermore some of the blocks have changed input parameters (e.g. gmsk_demod). Perhaps merging next into master was a little premature? Best regards Paul I don't think so at all. The problem is there are no automated test for this kind of stuff, and there's a lot of code that's of concern here. The only way we could get these kinds of error reports was to get the real users of GNU Radio to test them. These problems have been around in the old 'next' branch for a while, but without being used, there was no way for us to get these kinds of bug reports that is allowing us to fix them. In other words, I really appreciate you checking these things out and reporting the errors. This is also why we have stable releases. For people who have environments where stability is a concern, they should stick with the releases. I went through and checked the GRC blocks against everything I moved into gr-digital, so hopefully there is nothing left that I missed. I wonder if we can make a piece of automatic test code that would try to load each of the GRC XML blocks and report an error if it can't be loaded properly? Thanks! Let me know if you find anything else. Tom -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Errors of missing modulators in gnuradio-companion
2011/10/26 Tom Rondeau trondeau1...@gmail.com Yes, they are supposed to be in gr-digital/grc. That was just unbelievably stupid of me. This is why you should never commit before breakfast! I also didn't properly put these new ones into the Makefiles. This has been fixed. I was in a rush to get out the door this morning and wasn't thinking clearly. Was such a simple thing to do, too Tom Yes, it looks fine now, it even runs :) Only one little hitch left: During startup of gnuradio-companion it declares: Warning: Block key digital_gmsk_demod not found when loading category tree. The other warnings have disappeared, but this one remains. Worst part is that the file is there and is in the CMakeList.txt as well. I'm really stumped here. I made uninstall and deleted the appropriate folders, but to no avail. I really can't see why it is doing this to me. Oh well, off to bed, maybe the answer will be clear tomorrow. Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Another Building on Mac OS X
Hello Rickard You could try building using cmake? if you can do cmake-gui, you should see where to put the path to your swig at the bottom, perhaps configuring this explicitly helps? Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Editing Wiki
Hi So now the build works fine with cmake on my gentoo box. I want to give back all the good advice I have received here, so I go to make a gnuradio.org profile. However I can't see where to edit the wiki entry for build instructions on gentoo. Could somebody give me a hint? Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Editing Wiki
Hello Martin 2011/10/25 Martin Braun martin.br...@kit.edu On Tue, Oct 25, 2011 at 01:05:55PM +0200, Paul M. Bendixen wrote: Hi So now the build works fine with cmake on my gentoo box. I want to give back all the good advice I have received here, so I go to make a gnuradio.org profile. However I can't see where to edit the wiki entry for build instructions on gentoo. Could somebody give me a hint? Hi Paul, you launch the Start Page and Go 'Build Guide', and there, under 'Operating System Specific Instructions', is a link for Gentoo. Alternatively, enter 'Gentoo' in the search box and it's an immediate hit. I recently restructured the Wiki, hoping to make these things easier to find by creating fairly obvious paths to all relevant pages. Could you give me some feedback on what confused you in finding this page? I thought it's fairly obvious, but perhaps it can still be improved. MB As you can read from the original message, I found the page fine. However I want to edit it, in order for it to reflect the changes done in the newest release (using cmake). However, I can't find anywhere to edit the text once i found the page. Could you tell me how I can do this? Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Editing Wiki
Thank you and you're welcome 2011/10/25 Martin Braun martin.br...@kit.edu On Tue, Oct 25, 2011 at 02:16:24PM +0200, Paul M. Bendixen wrote: Hello Martin As you can read from the original message, I found the page fine. However I want to edit it, in order for it to reflect the changes done in the newest release (using cmake). However, I can't find anywhere to edit the text once i found the page. Could you tell me how I can do this? Hi Paul, there's a guest account (guest:gnuradio). Thanks for updating the wiki pages! 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Editing Wiki
Hello Tom I did register, and couldn't edit. Which is why i wrote the mail in the first place. After logging in as guest, It worked like a charm. I am however experiencing some new troubles, but more about that later. Best Paul 2011/10/25 Tom Rondeau trondeau1...@gmail.com On Tue, Oct 25, 2011 at 9:01 AM, Paul M. Bendixen paulbendi...@gmail.comwrote: Thank you and you're welcome Paul, you should be able to create an account by using the Register button at the top right. This will give you wiki editing privileges. Of course, if you don't mind using the guest account, that always works, too. Thanks for contributing! Tom 2011/10/25 Martin Braun martin.br...@kit.edu On Tue, Oct 25, 2011 at 02:16:24PM +0200, Paul M. Bendixen wrote: Hello Martin As you can read from the original message, I found the page fine. However I want to edit it, in order for it to reflect the changes done in the newest release (using cmake). However, I can't find anywhere to edit the text once i found the page. Could you tell me how I can do this? Hi Paul, there's a guest account (guest:gnuradio). Thanks for updating the wiki pages! 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ 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] Trouble with multiple installs or how i learned to love make uninstall
Hello It seems it might be a good idea if it were possible to uninstall gnuradio propper. I currently have two systems faling (hard) using the new build. My gentoo box (configured using cmake in another thread) gives me the error : ImportError: libgruel-3.4.2git.so.0: cannot open shared object file: No such file or directory Whenever i try from gnuradio import digital. funny part is: I never succeeded in installing 3.4.2, so I don't blame it for not finding it. I tried doing a manual ldconfig, but it didn't seem to do the trick. On an ubuntu machine (xubuntu to be specific) using the build-gnuradio script, most of the digital schemes fails due to the reallocation of packets to digital. This includes stuff that should be updated. Is it possible that the python stuff does not get properly updated and is there any way to fix this? Downgrading, by adding a git checkout v3.4.2 fixes makes the build run fine again. On both systems the building of the system is without problems. -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New build structure! (Warning #2)
Hi again 2011/10/20 Josh Blum j...@joshknows.com [snip] You need to clean your source directory. This file should not exist: /home/expert/skole/speciale/GnuRadio/git/volk/include/volk/volk.h:7:29: error: volk/volk_config.h: Ingen sådan fil eller filkatalog Can you git clean -dfx and try again? Done Seems like that helped, at least volk now compiles :) A lot of warnings about comparing signed and unsigned types though ;) I also tried pulling the latest version from git, however, it said something about 'next' not being a valid reference. (perhaps I should try a fetch seeing as I don't really change the code) Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New build structure! (Warning #2)
Hi happy to hear it, autotools were complaining about old syntax on my machine Using gentoo (not too heavily updated I'm afraid) and not succeding Configuring using cmake went well, but compiling didn't, already at first stop volk (that I'm not entirely sure i need) a _lot_ of errors occured. To be more specific, more than my shell history could take. 2011/10/20 Tom Rondeau trondeau1...@gmail.com [snip] $ cd gnuradio $ git checkout next $ git pull $ mkdir build $ cd build $ cmake ../ Up to here it went well $ make This fails already at volk $ make test $ sudo make install Is there any way to disable parts such as volk? (akin to --disable-volk that doesn't seem to work) The errors seems to be syntax errors in volk. Errors include: In file included from /home/expert/skole/speciale/GnuRadio/git/build/volk/lib/volk.c:6: /home/expert/skole/speciale/GnuRadio/git/build/volk/lib/volk_machines.h:20: fejl: expected ':', ',', ';', '}' or '__attribute__' before 'volk_16i_branch_4_state_8_a_archs' (the first one, fejl means error in danish) Any other outputs I can provide to help, just ask. Again, if that fails but you really need to use the current next branch, the same autotools build process will work. Please let us know if you find any issues. Thanks, I'll just checkout master again ;) Best Paul M. Bendixen * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I hate Unity
I have had no problems installing Gnu Radio under Kubuntu. If you already have a potent machine, try that. It gives the added bonus of being much prettier than Gnome ;) Best Regards Paul M. Bendixen 2011/10/17 Ben Hilburn b...@ettus.com N.B.: What follows is obviously all opinion: I can't stand Unity, and the default settings for Gnome 3 drove me nuts. If you are willing to put the effort in, you can install a bunch of extensions that will make it at least approach the usability of Gnome 2. I recommend: http://intgat.tigress.co.uk/rmy/extensions/gnome32.html http://www.webupd8.org/2011/10/official-gnome-shell-extensions.html After installing, restart Gnome, and then use the 'Advanced Settings' menu (which is actually a shortcut to the tool Bob mentioned, gnome-tweak-tool) to enable the extensions you want. I was able to almost achieve what I had in Gnome 2 by doing this - although there are still some annoyances. I really don't understand why Gnome3 took this giant step backwards, and Canonical took Ubuntu even further backwards with Unity. Cheers, Ben On Mon, Oct 17, 2011 at 11:10 AM, Vincenzo Pellegrini wwvi...@gmail.comwrote: Just a couple of lines to cast my ballot in favor of Bob's complaint. I had the same reaction in response to Fedora 15 reception of the Gnome3 thing. That stuff does move too far away from the power-user-desktop concept I've been enjoying for several years as a developer. Also I'm a bit frustrated to have to go after that load of tweaks in order to get a freshly installed system usable. my best regards to everybody there vince 2011/10/17 Alexandru Csete oz9...@gmail.com On Mon, Oct 17, 2011 at 7:28 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Oct 17, 2011 at 10:39 AM, Robert McGwier rwmcgw...@gmail.com wrote: Install gnome-tweak-tools to get advanced settings for gnome to be able to get your favorite settings after you install gnome-shell. On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier rwmcgw...@gmail.com wrote: http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ -- Bob McGwier Facebook: N4HYBob ARS: N4HY Or do what I did: apt-get install gnome-session-fallback and switch to Gnome Classic Mode at the login screen. Removes Unity. I haven't heard anyone say a good thing about Unity. It's an awful environment to develop under. The first thing I do in Ubuntu now is stop using it. I'm now shopping around for another Linux distro if they keep going this way. Tom On Ubuntu 11.04 I have installed Xfce desktop ( http://www.xfce.org/ ) - it is available via the package manager (or by installing xubuntu instead of regular ubuntu). It is similar to Gnome 2 and is very lightweight. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
