[Discuss-gnuradio] OFDM spectrum with power rolloff?
Hi all, I am generating my own OFDM waveform which actually does not modulate anything. Step by step. I am simulating 1024 subcarriers but first generating 1024 zeros, and then I want to only enable the center 100 subcarriers. To do this, I map the center frequency at the first index in the array, then the positive frequency subcarriers, then the negative frequency subcarriers. To enable the center 100 subcarriers, I multiply the first 50 positive frequency subcarriers by: (1.472) * complex(1,1), and do the same with the first 50 negative frequency subcarriers. Finally, I take the IFFT of the data, with a size of 1024. I multiply this by sqrt(1024). If I then take the FFT, to double check what I've done, and plot against the subcarrier index, I get what I expect: http://www.ece.cmu.edu/~gnychis/subc.png Now, I want to transmit this out of the USRP2 so I write the typical GNU Radio python script to read an 8-byte complex file source and pump it to the USRP2... repeating the complex samples in the file on finish for continuous transmission. I start up the spectrum analyzer and get a clean noise floor: http://www.ece.cmu.edu/~gnychis/noise_floor.jpg Now, when I transmit from the USRP2 using an interpolation rate of 32: http://www.ece.cmu.edu/~gnychis/transmit_spectrum.jpg Well, I can certainly see the waveform. But I have two questions... 1) My calculation of the bandwidth of the 100 active bins, and the actual bandwidth, is off by a factor of two: (((100 MHz) / 32) / 1024) * 100 = 305.175781 kilohertz, where 32 is the interpolation rate, 1024 was the size of the IFFT, and 100 is the number of active bins. I see 610KHz, however. 2) I'm not seeing a clean power falloff outside of the active bins. I am seeing a lot of power rolloff. Do I need to be applying a low pass and/or high pass filter for this? Or is this the result of weirdness created by the interp CIC filter and the dual half-band filters? I'm not too familiar at this level of communications.. I'd greatly appreciate any feedback. I can provide any code, but my guess is that I have a more fundamental misunderstanding than a coding error. Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM spectrum with power rolloff?
On 07/22/2010 11:51 PM, George Nychis wrote: Hi all, I am generating my own OFDM waveform which actually does not modulate anything. Step by step. I am simulating 1024 subcarriers but first generating 1024 zeros, and then I want to only enable the center 100 subcarriers. To do this, I map the center frequency at the first index in the array, then the positive frequency subcarriers, then the negative frequency subcarriers. To enable the center 100 subcarriers, I multiply the first 50 positive frequency subcarriers by: (1.472) * complex(1,1), and do the same with the first 50 negative frequency subcarriers. I don't know what you mean by the above. The peaking on either end of the spectrum might be caused by this. Finally, I take the IFFT of the data, with a size of 1024. I multiply this by sqrt(1024). If I then take the FFT, to double check what I've done, and plot against the subcarrier index, I get what I expect: http://www.ece.cmu.edu/~gnychis/subc.png Now, I want to transmit this out of the USRP2 so I write the typical GNU Radio python script to read an 8-byte complex file source and pump it to the USRP2... repeating the complex samples in the file on finish for continuous transmission. I start up the spectrum analyzer and get a clean noise floor: http://www.ece.cmu.edu/~gnychis/noise_floor.jpg Now, when I transmit from the USRP2 using an interpolation rate of 32: http://www.ece.cmu.edu/~gnychis/transmit_spectrum.jpg Well, I can certainly see the waveform. But I have two questions... 1) My calculation of the bandwidth of the 100 active bins, and the actual bandwidth, is off by a factor of two: (((100 MHz) / 32) / 1024) * 100 = 305.175781 kilohertz, where 32 is the interpolation rate, 1024 was the size of the IFFT, and 100 is the number of active bins. I see 610KHz, however. 2) I'm not seeing a clean power falloff outside of the active bins. I am seeing a lot of power rolloff. Do I need to be applying a low pass and/or high pass filter for this? Or is this the result of weirdness created by the interp CIC filter and the dual half-band filters? I'm not too familiar at this level of communications.. Since you are using an interpolation is a multiple of 4, you won't see CIC rolloff, you get a nice flat passband. There are likely a couple of issues causing the spectrum to look bad. First, successive symbols coming out of the FFT will have amplitude discontinuities. This causes out of band emissions unless you smoothly transition between the symbols. This is normally done with windowing. The 802.11g spec is a good example. Second, you may be clipping. OFDM has a very high peak to average ratio, so you need to make sure the peaks are below clipping. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding USRP2 flow control
Hi Eric, it took me some time to assemble the RS 232 level shifter. First to explicitly answer your question about realtime scheduling. Yes I did put in the explicit enabling you have told me, and yes, I get no error, i.e. realtime scheduling should be set succesfully. 2010-07-20 20:18, Blossom: If your machine has any kind of power control and/or frequency scaling, be sure that it's configured in its Performance mode. That is, run at full speed all the time, do not try to save energy, throttle the CPU, etc. I tried to tune my BIOS settings, but this did not change the behaviour substantly. Be sure that flow control is properly configured. It should look like this with a USRP2 plugged in and powered up: $ ethtool -a eth1 Pause parameters for eth1: Autonegotiate: on RX: on TX: off Yes, this is how it looks on my machine. I also experimentally set it to Autonegotiate: off RX: off TX: off to see, if it would change something, but as you guessed, it did not improve the situation. On transmit, it'll be a buffer underrun. The host isn't keeping up. I can now confirm that I am seeing bursts of 'UUU...' on the debug port of the USRP2. Some more observations: 1) The 6.31 rt kernel from the ubuntu 10.04 LTS is worse than the default stock 6.32 kernel. 2) Altough the USRP2 is signaling underuns ( I guess this is what U stands for) at the same time I can see in wireshark that I am receiving PAUSE frames. This looks like there might be some buffer size problems. How large are the transmit buffers of the USRP2? 3) I wrote a small test app that blasts out UDP frames on the same interface as fast as it can, and I can see a sustained rate of approx 900Mbits/ses. So I guess it is not a limitation of my hardware. Do you have any other ideas what else I could try? Turning to receive side: I invoked usrp2_fft.py -e eth2 -d 4 and I can see not see 'S' on the terminal. Am I correct in the assumption this means I have no missed packets on receive? Thank you for your help! Roland -- _ _ _ | Roland Schwarz OE1RSA |_)(_ | sip:speedsn...@ekiga.net | \__) | mailto:oe1...@oevsv.at | http://www.blackspace.at ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't find firmware: std.ihx
This USRP has been here since before my time but the other guys in the lab seem to think that it was bought directly from Ettus. It has the Ettus Research LLC sticker on it with the Ser number and test date. As for the lsusb. It reports: Bus 001 Device 007: ID fffe:0002 similar to lsusb for the working USRP. Craig Tong Radar Remote Sensing Group University of Cape Town On 22/07/2010 20:15, Thomas Tsou wrote: On Thu, Jul 22, 2010 at 4:35 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, Thanks for the help, I tracked through the functions that are used to load up the firmware and it turns out that this USRP is reporting its revision number as 0. As such the path to the firmware is always invalid. I managed to get my hands on another USRP just now and it returns revision 4 so my code seems to work correctly. Is this likely to be an EPROM corruption ? That is likely. At usrp power-up, the USB controller reads the eeprom data, which is reported to the host as various identifiers. Either the data is somehow corrupt or not being read. What appears when you run lsusb on the command line? Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 21/07/2010 19:15, Thomas Tsou wrote: On Wed, Jul 21, 2010 at 1:36 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to use gcell gang-scheduling in qa_fft.py (Python) on Cell BE?
Hi, when i run benchmark_nop on Cell BE (PS3), i can see the speedup pretty well. When i take qa_fft.py as testcase i can't see the speedup. All SPEs run the same code for same time. So when i use 6 SPEs, computing takes the same time as 1 SPE but it computes six times more. I think i have to set gang_schedule() to true in gc_job_manager.h. But how can i use this option in qa_fft.py? def setUp(self): ph = gcell.program_handle_from_filename(../../gcell/lib/spu/gcell_all) opts = gcell.jm_options(ph, 1) self.mgr = gcell.job_manager(opts) gcell.set_singleton(self.mgr) gcell.jm_options() has only two parameters, in gc_job_manager.h there are 7 options. Maybe, somebody can help me! I want to achieve, to see the speedup as well with qa_fft.py as testcase. Best Regards Matty ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Software mobile phone
Dear All, Do we think it is possible to create a software mobile phone using the USRP, with the OpenBTS code or something else? I mean everything would be in software, plus the USRP? Abdalaleem ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] some configure and building problems on ubuntu 10.04
As far as I know that module is no longer supported and it's not needed for running GNU Radio Alex 2010/7/23 刘权 mars-n...@163.com: I try to get gunradio3.3.0 launched on ubuntu 10.04, but the module gr-comedi can not pass building. when type ./configure, the result as follows: checking for COMEDI... no gr-comedi requires comedilib, not found. Not building component gr-comedi. 网易邮箱，没有垃圾邮件的邮箱。 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The building problem of gnuradio 3.2.2 on ubuntu 10.04
you need to go into gnuradio-3.2.2/gr-qtgui/src/lib and delete all the files ending in moc.cc and then run ./configure make make check make install Let me know if that fixes it for you Alex 2010/7/23 刘权 mars-n...@163.com: my gnuradio 3.2.2 passes through configure on ubuntu 10.04, while there is a building problem at make. The error information is as follows: ../../../../gr-qtgui/src/lib/spectrumdisplayform_moc.cc:14:2: error: #error This file was generated using the moc from 4.5.0. It ../../../../gr-qtgui/src/lib/spectrumdisplayform_moc.cc:15:2: error: #error cannot be used with the include files from this version of Qt. ../../../../gr-qtgui/src/lib/spectrumdisplayform_moc.cc:16:2: error: #error (The moc has changed too much.) 您想拥有和网易免费邮箱一样强大的软件吗？ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USB Gigabit Ethernet Dongle + USRP2
Is anyone using a Gigabit Ethernet USB dongle to communicate with a USRP2? If so, which one? Thank you, Harley Myler CONFIDENTIALITY: Any information contained in this e-mail (including attachments) is the property of The State of Texas and unauthorized disclosure or use is prohibited. Sending, receiving or forwarding of confidential, proprietary and privileged information is prohibited under Lamar Policy. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DDC design
Hi Brian thanks for reply, right now we are stuck with DDC On Thu, Jul 22, 2010 at 7:41 PM, Brian Padalino bpadal...@gmail.com wrote: On Thu, Jul 22, 2010 at 7:28 PM, zero cool smzeroc...@gmail.com wrote: hi all, I am trying to design my own DDC for the purpose of better reception of gsm signals, but stuck with its design, currently I am using vertex 5 FPGA from Xilinx, so please if there is any link or design guide from where we can start, Any help is very much appreciated. Are you getting stuck with the FPGA/Verilog portion, or the signal processing what do I do? portion? For the FPGA/Verilog stuff, it isn't too bad - just ask the right question and there should be an answer somewhat quickly. For the signal processing what do I do? stuff, you should try that book Bob McGwier posted about earlier: http://www.lulu.com/product/paperback/signal-processing-techniques-for-software-radios/11905533 Looked like it has some good SDR material in it. I am sure they go over mixers and DUC/DDC and plenty of filtering. Good luck! Brian -- Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't find firmware: std.ihx
On 07/23/2010 04:51 AM, Craig Tong wrote: This USRP has been here since before my time but the other guys in the lab seem to think that it was bought directly from Ettus. It has the Ettus Research LLC sticker on it with the Ser number and test date. What is the serial number? Philip As for the lsusb. It reports: Bus 001 Device 007: ID fffe:0002 similar to lsusb for the working USRP. Craig Tong Radar Remote Sensing Group University of Cape Town On 22/07/2010 20:15, Thomas Tsou wrote: On Thu, Jul 22, 2010 at 4:35 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, Thanks for the help, I tracked through the functions that are used to load up the firmware and it turns out that this USRP is reporting its revision number as 0. As such the path to the firmware is always invalid. I managed to get my hands on another USRP just now and it returns revision 4 so my code seems to work correctly. Is this likely to be an EPROM corruption ? That is likely. At usrp power-up, the USB controller reads the eeprom data, which is reported to the host as various identifiers. Either the data is somehow corrupt or not being read. What appears when you run lsusb on the command line? Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 21/07/2010 19:15, Thomas Tsou wrote: On Wed, Jul 21, 2010 at 1:36 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't find firmware: std.ihx
Hi Philip its 712 Craig Tong Radar Remote Sensing Group University of Cape Town On 23/07/2010 15:36, Philip Balister wrote: On 07/23/2010 04:51 AM, Craig Tong wrote: This USRP has been here since before my time but the other guys in the lab seem to think that it was bought directly from Ettus. It has the Ettus Research LLC sticker on it with the Ser number and test date. What is the serial number? Philip As for the lsusb. It reports: Bus 001 Device 007: ID fffe:0002 similar to lsusb for the working USRP. Craig Tong Radar Remote Sensing Group University of Cape Town On 22/07/2010 20:15, Thomas Tsou wrote: On Thu, Jul 22, 2010 at 4:35 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, Thanks for the help, I tracked through the functions that are used to load up the firmware and it turns out that this USRP is reporting its revision number as 0. As such the path to the firmware is always invalid. I managed to get my hands on another USRP just now and it returns revision 4 so my code seems to work correctly. Is this likely to be an EPROM corruption ? That is likely. At usrp power-up, the USB controller reads the eeprom data, which is reported to the host as various identifiers. Either the data is somehow corrupt or not being read. What appears when you run lsusb on the command line? Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 21/07/2010 19:15, Thomas Tsou wrote: On Wed, Jul 21, 2010 at 1:36 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_spectrum_sense and gr_bin_statistics_f
Hello,
I've been looking into how usrp_spectrum_sense works and I have a
question about my understanding of how it works.
The basic idea is that is that you tune, take FFT(s?), then retune,
etc. This is done with the fft block and the stats block. My
questions are:
1) What is input_items conceptually? I think it is a vector of
pointers to different fft sweeps, but I could be wrong.
2) So, is this code taking several FFTs then the for loop and
accrue_stats finds the maximum magnitude of each of the FFT bins. Is
that right?
3) Could I change dwell_time to change the number of FFTs that are taken?
4) If I wanted to do some averaging (instead of find the max
magnitude) could I would have to edit accrue_stats
Here's all the relevant code from
gnuradio-core/src/lib/general/gr_bin_statistics_f.cc
const float *input = (const float *) input_items[0];
size_t vlen = d_max.size();
int n = 0;
int t;
while (n noutput_items){
switch (d_state)
...
case ST_DWELL_DELAY:
t = std::min(noutput_items - n, int(d_delay));
for (int i = 0; i t; i++){
accrue_stats(input[n * vlen]);
n++;
}
d_delay -= t;
assert(d_delay = 0);
if (d_delay == 0){
leave_dwell_delay();
enter_tune_delay();
}
break;
...
void
gr_bin_statistics_f::accrue_stats(const float *input)
{
for (size_t i = 0; i vlen(); i++){
d_max[i] = std::max(d_max[i], input[i]);// compute per bin maxima
}
}
Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio scheduler behavior
1- GNU Radio 3.2.1 2- I'm not running out of CPU cycles 3- I've been dissecting the filtering blocks in GNU Radio in hopes of doing the same on the DSP. It's my understanding that the filter can process (noutput_items + ntaps) for each iteration. For DSP filtering, I've tried just copying noutput_items to the DSP, zero pad in the end by ntaps and write back noutput items to GNU Radio and I also tried passing (noutput_items + ntaps) to the DSP and filter noutput_items long. My results match with the GNU Radio GPP implementation when I pass (nouput_items + ntaps) inputs so I'm assuming that this is correct. 4- I'm not specifying the scheduler type so I'm assuming that the thread-per-block scheduler is used. Even when I specify the scheduler GR_SCHEDULER = STS ./mygraph.ph and GR_SCHEDULER = TPB ./mygraph.ph the behavior seems unaffected so I decided to leave the standard scheduler. It's possible that environmental variable was not being passed porperly I just couldn't figure out how to change the scheduler directly from my flowgraph even if that is possible. 5- Regarding if the code is thread safe, with my code there can only be one call to the DSP at a time so two threads cannot call the DSP at the same time but all the DSP handlers are static variables so they don't have to be called by the same exact thread everytime. Though I have all my DSP code in a static library outside of GNU Radio. -Original Message- From: Eric Blossom e...@comsec.com To: alfa...@aol.com Cc: discuss-gnuradio@gnu.org Sent: Thu, Jul 22, 2010 10:40 pm Subject: Re: [Discuss-gnuradio] GNU Radio scheduler behavior On Thu, Jul 22, 2010 at 10:18:41PM -0400, alfa...@aol.com wrote: I think I'm running into some scheduler issues in GNU Radio that I don't really understand. I've been working on running GNU Radio blocks on the Beagleboard's DSP by writing new DSP specific custom signal processing blocks When I run simple QA python test scripts everything works fine. What version of GNU Radio? 1- GNU Radio 3.2.1 If I start incorporating the block into more complex GNU Radio flowgraphs, the work method is occassionally not called. Are you running out of CPU cycles? 2- I'm not running out of CPU cycles ... at least it doesn't seem like it When I run my code in debug mode I can see the DSP being initialized and parameters being passed to it but once the flowgraph starts everthing hangs when I comment the DSP block out of the graph everything works fine. Sounds like something's wrong with your block :-) 3- I've been dissecting the filtering blocks in GNU Radio in hopes of doing the same on the DSP. It's my understanding that the filter can process (noutput_items + ntaps) for each iteration. For DSP filtering, I've tried just copying noutput_items to the DSP, zero pad in the end by ntaps and write back noutput items to GNU Radio and I also tried passing (noutput_items + ntaps) to the DSP and filter noutput_items long. My results match with the GNU Radio GPP implementation when I pass (nouput_items + ntaps) inputs so I'm assuming that this is correct. Just because I'm not sure what else to do, I added gr_enable_realtime_scheduling(). With this the Work method would occassionally get called. I'm using an interpolator class template and from what I see, the work method calls general_work and the consume_each() method so I guess I don't have to dabble with that. The other thing, my code blocks during each function call to the DSP, would this somehow affect the scheduler? If you're using the single-threaded-scheduler, you MAY NOT block in your work function. It should work OK when using the thread-per-block scheduler, assuming that your code isn't stepping on memory that it doesn't own, or other types of problems. Is the DSP code that you're calling thread-safe? Or does it have some assumptions built in such as it's only ever called by the same thread, it's not reentrant, etc? 4- I'm not specifying the scheduler type so I'm assuming that the thread-per-block scheduler is used. Even when I specify the scheduler GR_SCHEDULER = STS ./mygraph.ph and GR_SCHEDULER = TPB ./mygraph.ph the behavior seems unaffected so I decided to leave the standard scheduler. It's possible that environmental variable was not being passed porperly I just couldn't figure out how to change the scheduler directly from my flowgraph even if that is possible. 5- Regarding if the code is thread safe, with my code there can only be one call to the DSP at a time so two threads cannot call the DSP at the same time but all the DSP handlers are static variables so they don't have to be called by the same exact thread everytime. Though I have all my DSP code in a static library outside of GNU Radio I'm guessing not since not even the debug printf statements appear at the beginning are printed to the screen. I'm not quite sure how to debug the schdeuler calls and such related
Re: [Discuss-gnuradio] USB Gigabit Ethernet Dongle + USRP2
On Jul 23, 2010, at 9:48 AM, Charles Herdt wrote: Harley USRP2 uses Gigabit Ethernet because USB did not have enough bandwidth. If you use a usb dongle, you are killing its purpose. If you would like to use it through USB, I guess using a USRP 1 is a better idea. If you do get it to work on a dongle, which I doubt will be possible, you will not be able to use the USRP full capacity, and still be limited to higher decimation values. Charles Yes, I know. Harley CONFIDENTIALITY: Any information contained in this e-mail (including attachments) is the property of The State of Texas and unauthorized disclosure or use is prohibited. Sending, receiving or forwarding of confidential, proprietary and privileged information is prohibited under Lamar Policy. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DBPSK rework (SDPSK implementation)
My goal is to rework DBPSK module, so that it is possible to easily implement
SDPSK module.
DBPSK goes like this: differential_encoding ordinary BPSK, so there is no
actual constellation rotation. All rotation part is done by diff.encoder.
But this can be done only when shifting between 2 states. SDPSK shifts
between 4 states (1 = +90', 0 = -90').
So my intention was to make a class which would do something like the
following:
state = 1+0j #initial phase
if (chunk0x01==1)
state = state * p_change;
else
state = state * n_change;
for DBPSK p_change=1+0j (no change in phase if bit = 1)
n_change=-1+0j (reverse phase if bit = 0)
for SDPSK p_change =0+1j (+90' turn if bit = 1)
n_change =0-1j (-90' turn if bit = 0)
It can't be implemented as a function because it has to store current state
somewhere. So I should probably write a class, where state would be
initialized at constructor.
So I have read this How to write a signal processing block guide.
Also have written howto_diffconst.h file:
#ifndef INCLUDED_HOWTO_DIFFCONST_BC_H
#define INCLUDED_HOWTO_DIFFCONST_BC_H
#include gr_block.h
class howto_diffconst_bc;
typedef boost::shared_ptrhowto_diffconst_bc howto_diffconst_bc_sptr;
howto_diffconst_bc_sptr howto_make_diffconst_bc ();
class howto_diffconst_bc : public gr_block
{
private:
friend howto_diffconst_bc_sptr howto_make_diffconst_bc ();
howto_diffconst_bc ();
public:
~howto_diffconst_bc ();
int general_work (int noutput_items, gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items);
};
#endif
and stopped at howto_diffconst.cc file:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include howto_diffconst_bc.h
#include gr_io_signature.h
howto_diffconst_bc_sptr howto_make_diffconst_bc () {return
howto_diffconst_bc_sptr
(new howto_diffconst_bc ());}
howto_diffconst_bc::howto_diffconst_bc (): gr_block (diffconst_bc,
gr_make_io_signature (1, 1, 1),
gr_make_io_signature (1, 1, 8)) {}
howto_diffconst_bc::~howto_diffconst_bc () {}
int howto_diffconst_bc::general_work (int noutput_items, gr_vector_int
ninput_items,
gr_vector_const_void_star
input_items,
gr_vector_void_star output_items)
{
//const float *in = (const float *) input_items[0];
//float *out = (float *) output_items[0];
//out[0] = in[0] * in[0];
consume_each (noutput_items);
return noutput_items;
}
Now, finally about what bothers me.
First - signatures. Input should be a single chunk, output - signle complex.
So I wrote input signature: gr_make_io_signature(1,1,1), output signature:
gr_make_io_signature(1,1,8)
Would that be correct?
Next - variables. Thing is I have no idea what type of variables to use for
chunk and complex.
My guess - int for chunk, and complex class (complexfloat) from standart
c++ library ( http://cplusplus.com/reference/std/complex/complex/
std/complex ) for complex. But would that be compatible with gnu-radio
complex?
Third - initialization. Do I set initial phase
howto_diffconst_bc::howto_diffconst_bc (): gr_block (diffconst_bc,
gr_make_io_signature (1, 1, 1),
gr_make_io_signature (1, 1, 8)) {here?}
Please help! Any suggestions accepted.
--
View this message in context:
http://old.nabble.com/DBPSK-rework-%28SDPSK-implementation%29-tp29249098p29249098.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM spectrum with power rolloff?
Thanks a bunch for your response, Matt! Since you are using an interpolation is a multiple of 4, you won't see CIC rolloff, you get a nice flat passband. Got ya! There are likely a couple of issues causing the spectrum to look bad. First, successive symbols coming out of the FFT will have amplitude discontinuities. This causes out of band emissions unless you smoothly transition between the symbols. This is normally done with windowing. The 802.11g spec is a good example. I will check the spec for this, thanks for the pointer there. I will see how they do the windowing. Second, you may be clipping. OFDM has a very high peak to average ratio, so you need to make sure the peaks are below clipping. Clipping nailed it. I get a very clean spectrum now :) Super awesome! One last question still, do you know where I am missing a factor of two here: 1) My calculation of the bandwidth of the 100 active bins, and the actual bandwidth, is off by a factor of two: (((100 MHz) / 32) / 1024) * 100 = 305.175781 kilohertz, where 32 is the interpolation rate, 1024 was the size of the IFFT, and 100 is the number of active bins. I see 610KHz, however. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Synchronizing 2 Usrp2's via MIMO cable?
We need to synch up multiple U2's. I've seen reference to using the MIMO cable to sync 2 U2s. Is this currently supported by the existing software? If so, what do I need to do in my own code in order to affect a sync? Would the same code work with a GPSDO (e.g., Jackson Labs FireFly (which I've also seen referenced here by Matt others))? Thanks, --Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't find firmware: std.ihx
On Fri, Jul 23, 2010 at 1:51 AM, Craig Tong tngcra...@rrsg.ee.uct.ac.za wrote: This USRP has been here since before my time but the other guys in the lab seem to think that it was bought directly from Ettus. It has the Ettus Research LLC sticker on it with the Ser number and test date. As for the lsusb. It reports: Bus 001 Device 007: ID fffe:0002 similar to lsusb for the working USRP. That means the EEPROM is being read correctly. Try running lsusb -v and look for the line bcdDevice under the fffe:0002 section. You should be seeing 0.04, which means unconfigured (high byte) and rev4 (low byte). Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 22/07/2010 20:15, Thomas Tsou wrote: On Thu, Jul 22, 2010 at 4:35 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, Thanks for the help, I tracked through the functions that are used to load up the firmware and it turns out that this USRP is reporting its revision number as 0. As such the path to the firmware is always invalid. I managed to get my hands on another USRP just now and it returns revision 4 so my code seems to work correctly. Is this likely to be an EPROM corruption ? That is likely. At usrp power-up, the USB controller reads the eeprom data, which is reported to the host as various identifiers. Either the data is somehow corrupt or not being read. What appears when you run lsusb on the command line? Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 21/07/2010 19:15, Thomas Tsou wrote: On Wed, Jul 21, 2010 at 1:36 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding USRP2 flow control
On Fri, Jul 23, 2010 at 10:35:12AM +0200, OE1RSA wrote: Hi Eric, it took me some time to assemble the RS 232 level shifter. First to explicitly answer your question about realtime scheduling. Yes I did put in the explicit enabling you have told me, and yes, I get no error, i.e. realtime scheduling should be set succesfully. Roland, all of the stuff below looks good. On transmit, it'll be a buffer underrun. The host isn't keeping up. I can now confirm that I am seeing bursts of 'UUU...' on the debug port of the USRP2. Some more observations: 1) The 6.31 rt kernel from the ubuntu 10.04 LTS is worse than the default stock 6.32 kernel. 2) Altough the USRP2 is signaling underuns ( I guess this is what U stands for) at the same time I can see in wireshark that I am receiving PAUSE frames. This looks like there might be some buffer size problems. How large are the transmit buffers of the USRP2? 3) I wrote a small test app that blasts out UDP frames on the same interface as fast as it can, and I can see a sustained rate of approx 900Mbits/ses. So I guess it is not a limitation of my hardware. Do you have any other ideas what else I could try? Sorry, this may have been in an earlier message, but what ethernet chip/card are you using? (lspci will show the details.) We've had lots of problems with RealTek. What kind of CPU are you running on? In my exerience, it takes at least a Core 2 Duo running at 3+ GHz to transmit at full speed. The challenge is that there's not much buffer in the USRP2, and thus the average Tx rate over a very small window needs to be rock solid. If the cpu gets side-tracked doing something else, you'll see underruns. Also, on some machines with multiple CPU sockets, such as my dual quad core Xeon, on some versions of the OS, it really matters as to whether or not all of the computation is running on a single physical chip. If you've got a machine like that, try using numactl to force all the threads to live on a single physical chip (not core). If you look at the output of cat /proc/cpuinfo, physical id indicates which cores are in which sockets. (How the processors are assigned numbers seems to have a random component (at least under some versions of the OS)) Turning to receive side: I invoked usrp2_fft.py -e eth2 -d 4 and I can see not see 'S' on the terminal. Am I correct in the assumption this means I have no missed packets on receive? Yes. Thank you for your help! You're welcome. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Understanding Data Flow in the USRP2 Firmware
Hi, I am trying to understand the data flow in the FPGA. I am trying to understand the Architecture and aemb firmware program control flow. Which one is the top level firmware C file. How it gets data from ADC. How it interacts with the UART etc.Please let me know some details on it. Thanks JS ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio Companion - AUX DAC
Hello, I notice that in GNU Radio Companion there does not seem to be a way to set the value of the auxiliary DACs. Is there a way to do this that I have not noticed, or will I have to do so in the generated Python code manually? Thanks, ~Jeff -- ~Jeffrey Lambert, K1VZX ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding Data Flow in the USRP2 Firmware
On Fri, Jul 23, 2010 at 12:31:19PM -0700, Ashish Bansal wrote:
Hi,
I am trying to understand the data flow in the FPGA. I am trying to
understand the Architecture and aemb firmware program control flow.
Which one is the top level firmware C file. How it gets data from ADC. How
it interacts with the UART etc.Please let me know some details on it.
Thanks
JS
txrx.c is the top-level C file.
memory_map.h describes the various peripherals that the firmware sees.
Most of the magic occurs in the buffer pool which can simultaneously
accept input from 4 sources, send output to 4 destinations, and
includes a full cross bar and 8 buffers. AFAIK, there's no overview
documentation on it, but between memory_map.h, buffer_pool.{h,c}, and
dbsm.{h,c} you may be able to sort it out.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software mobile phone
Dear All, Do we think it is possible to create a software mobile phone using the USRP, with the OpenBTS code or something else? I mean everything would be in software, plus the USRP? It is absolutely possible. So far I don't know anyone who has tried to do it. The OpenBTS code would give you a big head start. I also think it would be interesting to port the resulting code into a mobile phone. Generally the GSM protocols in a phone are run in a baseband processor separate from the user interface processor. Every phone I know of uses secret, proprietary code running in the baseband processor, even when the user interface is largely free software. Once you had working code running in GNU Radio on a Linux machine, the challenge would be finding a well-documented baseband chip (in which the manufacturer tells you where to find the radio I/O gear on the chip, and how it works, etc). Porting clean GSM code to run in that chip in realtime would require some adaptation to exploit unusual on-chip DSP hardware, mastering an embedded debugging environment, and perhaps shrinking the memory consumption of the GNU Radio-based code. I think it's not only doable, but well worth doing. It should be worth a couple of PhDs at least. You would certainly know the GSM protocols inside and out by the time you were done! John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software mobile phone
Hi, The OpenBTS code would give you a big head start. The tranceiver part sure. But you'd still need pretty big modification to have it act as a TDMA clock slave and not TDMA clock master (that's quite different). Once you have done the L1 inside the USRP somehow, you can re-use the osmocom-bb code (which is an opensource baseband implementation project) for the upper layers. Sylvain Munaut ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: 2nd Edition (Corrected link)
On Thu, Jul 22, 2010 at 09:29:17AM -0400, Bob McGwier wrote: The 2nd edition of the REALLY expensive ($29.95) SDR book by friend and colleague, Behrouz Farhang-Beroujeny, has been released from lulu. It contains important additions (OFDM, more filtering, all known errata fixed) and I recommend it highly. http://bit.ly/cTU2cm Correction: the 2nd Edition has a different link. Use this one: http://www.lulu.com/product/hardcover/signal-processing-techniques-for-software-radios-2nd-edition/11905547 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Openbts-discuss] [Discuss-gnuradio] Software mobile phone
Fantastic stuff! On 23 Jul 2010, at 22:26, Joshua Lackey wrote: And leveraging the work from the osmocombb project (http://bb.osmocom.org/trac/) will get you a far ways towards the goal. Quoting John Gilmore (g...@toad.com): Dear All, Do we think it is possible to create a software mobile phone using the USRP, with the OpenBTS code or something else? I mean everything would be in software, plus the USRP? It is absolutely possible. So far I don't know anyone who has tried to do it. The OpenBTS code would give you a big head start. I also think it would be interesting to port the resulting code into a mobile phone. Generally the GSM protocols in a phone are run in a baseband processor separate from the user interface processor. Every phone I know of uses secret, proprietary code running in the baseband processor, even when the user interface is largely free software. Once you had working code running in GNU Radio on a Linux machine, the challenge would be finding a well-documented baseband chip (in which the manufacturer tells you where to find the radio I/O gear on the chip, and how it works, etc). Porting clean GSM code to run in that chip in realtime would require some adaptation to exploit unusual on-chip DSP hardware, mastering an embedded debugging environment, and perhaps shrinking the memory consumption of the GNU Radio-based code. I think it's not only doable, but well worth doing. It should be worth a couple of PhDs at least. You would certainly know the GSM protocols inside and out by the time you were done! John -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Openbts-discuss mailing list openbts-disc...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbts-discuss ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] question about xcvr2450
Hi all, I want to use tunnel.py with usrp1+xcvr2450 to create a network interface, and I set the frequent to 5.0G. The tx is ok, but it can't receive anything. I google the reason about it, someone say that the gnuradio_r10853 can fix the question. However, I can't get the trunk version of 10853. I use some trunks of gnuradio( gnuradio-3.1.1 gnuradio-3.2.2 gnuradio-3.3.0) to test it, it still can't receiving. What should I do to use xcvr2450. Thank you very much! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Strange constellation appears on pi/4 dqpsk and dqpsk thru scope_sink
Hi, I also have the similar problem at the receiver side, why trying to obtain the constellation of DQPSK. From constellation sink block, I can obtain much better constellation. But, using scope sink, it shows a mess. As far as I went through the code of constellation sink, it seems like conducting additional synchronization before plotting the results. Anyone can explain more about the detail of constellation sink in GRC block? And how can we output the data in constellation sink? Many thanks -- Regards, Guanbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Strange constellation appears on pi/4 dqpsk and dqpsk thru scope_sink
Hi, I also have the similar problem at the receiver side, when trying to obtain the constellation of DQPSK. From constellation sink block, I can obtain much better constellation. But, using scope sink, it shows a mess. As far as I went through the code of constellation sink, it seems like conducting additional synchronization before plotting the results. Anyone can explain more about the detail of constellation sink in GRC block? And how can we output the data in constellation sink? Many thanks -- Regards, Guanbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
