Re: [Discuss-gnuradio] Compiler machine compatibility
On 04/08/2011 01:06 PM, Nick Foster wrote: Make sure you're compiling with optimization flags appropriate for the hardware you're planning to run on. For instance, if you spec -msse3 or newer on a pre-Prescott P4, you'll generate instructions the CPU can't execute. I'm pretty sure GCC won't generate these instructions unless you specify it using these flags so make sure your automake/cmake setup isn't doing so. Another issue is if you compile on a 32-bit compiler it'll barf on a 64-bit system, and this might generate an illegal instruction error. This is the reason package maintainers keep a 32-bit and 64-bit version of their packages. If you want to make code that runs on a 64-bit system from your 32-bit system, you'll have to use a 64-bit GCC installation (I think GCC is the same for either, but you need 64-bit libc) and use -m64 as a compile flag. --n OK, so it turns out that I lied, viciously and nastily. Brazenly, even :-) I had -msse3 turned on, which won't work on an early Pentium 4, but will work on late-model Pentium 4. So, I cranked-back the optimization flags to -msse2, which was available for Pentium 4. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Abstract deadline for SDR'11
The abstract deadline for SDR'11 has been extended to April 19. The updated Call for Abstracts is here: http://data.memberclicks.com/site/s1/SDR11AbstractReg.pdf I'd love to see a bunch of Open Source related submissions. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus2 and RFX2400 For Sale
Ok ok wrong audience for inaccurate branding. USRP2 is for sale. I guess Ettus1 named the product USRP not Ettus. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: WiMAX decoding: DL-PUSC question
Ok, we've found the problem ourselves: http://code.google.com/p/wimax-scanner/source/detail?r=a3f58c295ed975acd4f6cfac7687bac4c260dfe8 Now we can see DL-MAP in our test captures. On Fri, Apr 8, 2011 at 13:15, Alexander Chemeris wrote: > Hi all, > > This is a little bit offtopic for this mailing list, but I can't find > a better place to ask this question. > > We're doing an open-source project on WiMAX decoding > (http://code.google.com/p/wimax-scanner/) and at this point we have a > trouble with correct subchannelization of DL-PUSC, so we're looking > for some advise on what we're doing wrong. Or may someone could just > contribute some code for correct subchannelization? > > My implementation is available as Matlab code and as Excel spreadsheet here: > http://code.google.com/p/wimax-scanner/source/browse/matlab/get_slot_data.m > http://code.google.com/p/wimax-scanner/source/browse/matlab/PUSC-permutation.xls > It is able to correctly list sub-carriers for FCH of segment 0 (i.e. > for subchannels 0-3), but looks like it gives incorrect results for > all other subchannels. The result of this is that I can see only two > consecutive repetitions of slot data in DL-MAP part of the header, > where I should see 4 or 6 repetitions. The standard is very vague and > unclear on this topic and people who write textbooks certainly thinks > it's an obvious part and no one document it in an understandable way. > > If you have a working implementation of DL-PUSC subchannelization, > which you can't share with us, we would appreciate if you just share > mappings of subchannels to sub-carriers for a few sets of parameters. > That would be very helpful for us to debug our own code. > > PS If you're interested in contributing to an open-source WiMAX > implementation - you're very welcome to join the effort! We believe we > can make a real difference in the wireless world. > > -- > Regards, > Alexander Chemeris. > http://www.fairwaves.ru > -- Regards, Alexander Chemeris. http://www.fairwaves.ru ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus2 and RFX2400 For Sale
On 04/08/2011 01:08 PM, Josh Blum wrote: On 04/08/2011 02:44 PM, jeremy ward wrote: I have an Ettus 2 and an RFX2400 that I don't need anymore. I used them a couple times and they work great. If you're interested just drop me a line. So you have one of Matt's helper clones. Ettus 2 escaped a few months ago and we could really use him back. Is Ettus 2 the one that keeps the Chief Slow Loris under control? Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus2 and RFX2400 For Sale
Is that something like mini-matt? On Fri, Apr 8, 2011 at 3:08 PM, Josh Blum wrote: > > > On 04/08/2011 02:44 PM, jeremy ward wrote: > > I have an Ettus 2 and an RFX2400 that I don't need anymore. I used them > a > > couple times and they work great. If you're interested just drop me a > line. > > > > So you have one of Matt's helper clones. Ettus 2 escaped a few months > ago and we could really use him back. > > Thanks! > -Josh > > ___ > 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] Ettus2 and RFX2400 For Sale
On 04/08/2011 02:44 PM, jeremy ward wrote: > I have an Ettus 2 and an RFX2400 that I don't need anymore. I used them a > couple times and they work great. If you're interested just drop me a line. > So you have one of Matt's helper clones. Ettus 2 escaped a few months ago and we could really use him back. Thanks! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ettus2 and RFX2400 For Sale
I have an Ettus 2 and an RFX2400 that I don't need anymore. I used them a couple times and they work great. If you're interested just drop me a line. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Synthesizable Frequencies for WBX?
Hello Jason, Thank you for the instant reply. Here are the responses to your question: The transceiver set-up is really basic: TX Random src --> DQPSK MOD --> Pulse Shape --> UHD SINK RX UHD SOURCE --> FFT block so, Signal amplitude? 1 Gain setting? 0dB at TX and RX sides Antenna port? TX: TX/RX RX: RX2 I believe it is a mis-sampling mismatch. I am using 4 samples per symbol. I should add that this problem appears to be ONLY at the TX side. I am able to see a clean signal when the TX is at 900MHz and RX is 900.050MHz. But not the other way around. Also, as far as the parameters go: if I want to access 900.05MHz I pass to tune_request_t : target frequency = 900M LO freq = 50K However, the result is: bad signal (i can see the peak at the center frequency expected (900.05MHz) but the bandwidth is wide in the same manner as if I set the center frequency manually at 900.05 rather than using tune_request_t. I am pretty sure that the upsampling in FPGA is messed up or the upconversion setting in the transmitter has to be done in different way. Any advice please? Kind regards, Yahia Tachwali From: Jason Abele [ja...@ettus.com] Sent: Friday, April 08, 2011 12:45 PM To: Tachwali, Yahia Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Synthesizable Frequencies for WBX? On Fri, Apr 8, 2011 at 10:22 AM, Tachwali, Yahia wrote: > Hello Guys, > > I am experiencing some problems in transmitting/receiving at frequencies > around 900MHz for WBX board. While, I am able to do so cleanly at > 900MHz, other center frequencies are not. > > The signal bandwidth : 50 KHz > The sampling frequency: 200 KHz What signal amplitude? What gain setting? Which antenna port? > > I have tried 901MHz , 900.1MHz, 910MHz and many others but the received > signal appears to be wider than it should be. The signal level is higher than > -40dbm over the total 200 KHz range when these frequencies are used. This usually indicates a sample rate mismatch in your flowgraph, if you post an example to replicate your problem, it will be easier to help you. > > The only frequencies I was able to use with no problems are 900MHz, > 1.8 GHz , 890MHz, 880MHz. > > What could be the problem? I have tried to use "tune_request_t" in the target > frequency paramter but it gave similar bad results . Any pointers? What parameters did you give to the tune_request_t? Have you looked at the tune_result_t returned by set_center_freq? Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synthesizable Frequencies for WBX?
On Fri, Apr 8, 2011 at 10:22 AM, Tachwali, Yahia wrote: > Hello Guys, > > I am experiencing some problems in transmitting/receiving at frequencies > around 900MHz for WBX board. While, I am able to do so cleanly at > 900MHz, other center frequencies are not. > > The signal bandwidth : 50 KHz > The sampling frequency: 200 KHz What signal amplitude? What gain setting? Which antenna port? > > I have tried 901MHz , 900.1MHz, 910MHz and many others but the received > signal appears to be wider than it should be. The signal level is higher than > -40dbm over the total 200 KHz range when these frequencies are used. This usually indicates a sample rate mismatch in your flowgraph, if you post an example to replicate your problem, it will be easier to help you. > > The only frequencies I was able to use with no problems are 900MHz, > 1.8 GHz , 890MHz, 880MHz. > > What could be the problem? I have tried to use "tune_request_t" in the target > frequency paramter but it gave similar bad results . Any pointers? What parameters did you give to the tune_request_t? Have you looked at the tune_result_t returned by set_center_freq? Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiler machine compatibility
On Fri, 2011-04-08 at 13:23 -0400, Marcus D. Leech wrote: > On 08/04/2011 1:06 PM, Nick Foster wrote: > > > > Make sure you're compiling with optimization flags appropriate for the > > hardware you're planning to run on. For instance, if you spec -msse3 or > > newer on a pre-Prescott P4, you'll generate instructions the CPU can't > > execute. I'm pretty sure GCC won't generate these instructions unless > > you specify it using these flags so make sure your automake/cmake setup > > isn't doing so. > > > > Another issue is if you compile on a 32-bit compiler it'll barf on a > > 64-bit system, and this might generate an illegal instruction error. > > This is the reason package maintainers keep a 32-bit and 64-bit version > > of their packages. If you want to make code that runs on a 64-bit system > > from your 32-bit system, you'll have to use a 64-bit GCC installation (I > > think GCC is the same for either, but you need 64-bit libc) and use -m64 > > as a compile flag. > > > Hmm, my "make" use using the "naked" compiler without any extra flags. > The target system is >a Pentium-IV, and my build system is a 32-bit Intel Core (T2400). > Is the P4 running a 32-bit or 64-bit OS? > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiler machine compatibility
On 08/04/2011 1:06 PM, Nick Foster wrote: Make sure you're compiling with optimization flags appropriate for the hardware you're planning to run on. For instance, if you spec -msse3 or newer on a pre-Prescott P4, you'll generate instructions the CPU can't execute. I'm pretty sure GCC won't generate these instructions unless you specify it using these flags so make sure your automake/cmake setup isn't doing so. Another issue is if you compile on a 32-bit compiler it'll barf on a 64-bit system, and this might generate an illegal instruction error. This is the reason package maintainers keep a 32-bit and 64-bit version of their packages. If you want to make code that runs on a 64-bit system from your 32-bit system, you'll have to use a 64-bit GCC installation (I think GCC is the same for either, but you need 64-bit libc) and use -m64 as a compile flag. Hmm, my "make" use using the "naked" compiler without any extra flags. The target system is a Pentium-IV, and my build system is a 32-bit Intel Core (T2400). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Synthesizable Frequencies for WBX?
Hello Guys, I am experiencing some problems in transmitting/receiving at frequencies around 900MHz for WBX board. While, I am able to do so cleanly at 900MHz, other center frequencies are not. The signal bandwidth : 50 KHz The sampling frequency: 200 KHz I have tried 901MHz , 900.1MHz, 910MHz and many others but the received signal appears to be wider than it should be. The signal level is higher than -40dbm over the total 200 KHz range when these frequencies are used. The only frequencies I was able to use with no problems are 900MHz, 1.8 GHz , 890MHz, 880MHz. What could be the problem? I have tried to use "tune_request_t" in the target frequency paramter but it gave similar bad results . Any pointers? Kind regards, Yahia Tachwali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiler machine compatibility
On Fri, 2011-04-08 at 12:29 -0400, Marcus D. Leech wrote: > I have some code that lives on top of Gnu Radio, and I think I'm having > a code-generation issue with GCC. The binaries work on all >my machines, but on a customers machine, it raises an Illegal > Instruction exception. I generated the code on a 32-bit Intel Core >machine, on Fedora 12. The code is executing on a Pentium-IV class > machine, on a Fedora 12 installation. I gather than by default >GCC will generate code that's optimized for the machine on which the > compile is happening. How do distributors of binaries assure >that the code will execute correctly on older-generation hardware? Make sure you're compiling with optimization flags appropriate for the hardware you're planning to run on. For instance, if you spec -msse3 or newer on a pre-Prescott P4, you'll generate instructions the CPU can't execute. I'm pretty sure GCC won't generate these instructions unless you specify it using these flags so make sure your automake/cmake setup isn't doing so. Another issue is if you compile on a 32-bit compiler it'll barf on a 64-bit system, and this might generate an illegal instruction error. This is the reason package maintainers keep a 32-bit and 64-bit version of their packages. If you want to make code that runs on a 64-bit system from your 32-bit system, you'll have to use a 64-bit GCC installation (I think GCC is the same for either, but you need 64-bit libc) and use -m64 as a compile flag. --n > > > > > ___ > 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] problem on transmitting signal
On 08/04/2011 10:30 AM, Thomas H Kim wrote: Hi all, I'm transmitting a packet to 2.4G band using RFX2400 on USRP1 and observed this problem: Once in a while, the transmission stops in the middle of the packet being transmitted. Does anyone know if 1) there is any TX amp control line which is controlled by the FPGA and in what condition it toggles, Any transmit power control will be under control of the software--the FPGA doesn't make spontaneous decisions about that. 2) if it can happen when USRP underrun (uU) occurs When the host-side underruns the transmitter, it must necessarily transmit 0s, which effectively turns off the transmitter for the duration of the underrun. 3) if there is a schematic for RFX2400 and usrp1 available? Schematics available here: http://code.ettus.com/redmine/ettus/projects/public/documents I'm using gnuradio 3.2.2. Thanks, Thomas ___ 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] Compiler machine compatibility
I have some code that lives on top of Gnu Radio, and I think I'm having a code-generation issue with GCC. The binaries work on all my machines, but on a customers machine, it raises an Illegal Instruction exception. I generated the code on a 32-bit Intel Core machine, on Fedora 12. The code is executing on a Pentium-IV class machine, on a Fedora 12 installation. I gather than by default GCC will generate code that's optimized for the machine on which the compile is happening. How do distributors of binaries assure that the code will execute correctly on older-generation hardware? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem on transmitting signal
Hi all, I'm transmitting a packet to 2.4G band using RFX2400 on USRP1 and observed this problem: Once in a while, the transmission stops in the middle of the packet being transmitted. Does anyone know if 1) there is any TX amp control line which is controlled by the FPGA and in what condition it toggles, 2) if it can happen when USRP underrun (uU) occurs 3) if there is a schematic for RFX2400 and usrp1 available? I'm using gnuradio 3.2.2. Thanks, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help : Where is the demodulation blocks implemented in gnuradio [ GMSK,PSK etc].
the demodulation and modulation is done in GNU Radio. the raw digitized signal from USRP will be proccessed by gnu radio either we want to filtered, do FFT, demodulate and etc. all is done using GNU Radio. USRP is the hardware to interfare the digital world with the analog world.. anil ph wrote: > > Thanks Marcus for your valuable information . > Now as per you have said that the usrp/gnuradio doesnt do any default > demodulation , that means if i apply a demodulation technique to the > captured file from usrp_rx_cfile.py , i will get the required output.For > example if i apply GMSK demodulation to the captured file i ll get the > properly formatted output as per the GSM protocol ... right. > Thanks > > On Thu, Apr 7, 2011 at 10:02 PM, Marcus D. Leech > wrote: > >> On 07/04/2011 10:34 AM, ton ph wrote: >> >>> Hi guys , >>> I Just want to confirm a thing regarding the demodulation of the >>> digital >>> dat in the gnuradio as the signals are received from the usrp. The doubt >>> are, >>> 1. Where is the demodulation is implemented in the gnuradio . >>> 2. What demodulation is implemented by default in the urp_rx_cfile ... >>> please do help me someone in clearing my doubts . >>> >>> Thanks >>> >> Gnu Radio is a generic digital-signal-processing framework. Which >> includes >> *many* pre-built processing blocks, including demodulators >> and modulators, correlators, detectors, etc, etc. >> >> There is no *default* demodulation scheme anywhere in the basic >> architecture, and usrp_rx_cfile is used to simply copy samples as they >> come off the USRP hardware into a file. >> >> The USRP hardware doesn't do any demodulation--the signal you see >> delivered >> to the host PC is just filtered/decimated baseband >> samples as they come off the ADC, appropriately scaled for use inside >> Gnu >> Radio. The USRP hardware doesn't know anything >> about modulation or demodulation, per se. All of that is the >> responsibility of the host software. Correspondingly, the transmit >> side of the USRP hardware doesn't *know* anything about modulation, >> either. It is entirely up to the host software to provide >> appropriately-modulated samples for the hardware to dutifully turn into >> analog signals and then (usually) up-convert to the >> desired RF band of interest. Generally, the host interface operates in >> "baseband" mode--the (complex) samples are centered at DC. >> >> Cheers >> >> >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > -- > Phenomenon > # Life is the most precious phenomenon ever happen ... > > # Lets pray and give emotional strength to the innocent brave victims of > japan > # they are human and m also a human which implies we are one. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > - Mohd Adib Sarijari Universiti Teknologi Malaysia www.fke.utm.my www.utm.my -- View this message in context: http://old.nabble.com/Help-%3A-Where-is-the-demodulation-blocks-implemented-in-gnuradio---GMSK%2CPSK-etc-.-tp31343206p31351930.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
[Discuss-gnuradio] Try to get the hardware end point.
Hello every one... i am new in gnuradio... i start tracing usrp_rx_cfile... i want to find the hardware interaction point where data is received by gnuradio from usrp... or from where gnuradio code starts processing & take data from usrp... I found a function "read" in "file fusb_generic" which calls "usb_bulk_read"(libusb function) to read data from cyprex(usb)... is this the starting point of software(gnuradio)... or is there any other block(part) of gnuradio which put data from cyprex(from where read by "usb_bulk_read")... plz do tolerate if question is illogical or any grammatical mistake... thanks to all of you in advance... -- View this message in context: http://old.nabble.com/Try-to-get-the-hardware-end-point.-tp31351007p31351007.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] How to use the SNR block in the GRC
hi josh: Thank you for your last e-mail.I am sorry I did not mention the version of GRC I used,and it is 3.2.2(GNU Radio is 3.3.3). And I found the probe_function block as you said.I use a scope block to connect to the probe_function block to see the output of the blcok.I also put the bpsk modulated data input this block,and put the output of the block to a file_sink. I use the ID of the gr_probe_mpsk_snr block as the parameter Block ID of the probe_function block, then set the parameter Function name as the name of the functions in the gr_probe_mpsk_snr block such as signal_mean(), snr().But there is an error " 'gr_hier_block2_sptr' object has no attribute 'signal_mean' "in the flow graph .Why did it happen? Did I set some parameters wrong? Can you give me a example flow graph (not the one in the digital-bertfolder)about the gr_probe_mpsk_snr and probe_function? Thank you inter > Date: Thu, 7 Apr 2011 11:33:23 -0500 > From: j...@joshknows.com > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] How to use the SNR block in the GRC > > > > On 04/07/2011 05:18 AM, intermilan wrote: > > > > Hi all: > > I found these is a block gr_probe_mpsk_snr in the grc which is used to > > measure the snr of the bpsk or qpsk signals. But I > > do not know how to use this block.In my flow graph, I put the bpsk > > modulated data input this block,and put the output of the block to a > > file_sink. > > But there is nothing in that file.So I hope someone can tell me how to use > > this block. > > Thanks in advance. > > inter > > > > > I dont know what version your using. But I reworked how the probe blocks > work since the last release, so here is how it works in the current master: > > Attach a probe block to your signal. Notice in the probe block docs, > that the available functions are listed. Use the function probe block to > read that function periodically and to write the value into a variable. > > To display the result, just use the ID from the function probe in the > value parameter for the appropriate graphical widget. > > -Josh > > > > > > > > > ___ > > 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] WiMAX decoding: DL-PUSC question
Hi all, This is a little bit offtopic for this mailing list, but I can't find a better place to ask this question. We're doing an open-source project on WiMAX decoding (http://code.google.com/p/wimax-scanner/) and at this point we have a trouble with correct subchannelization of DL-PUSC, so we're looking for some advise on what we're doing wrong. Or may someone could just contribute some code for correct subchannelization? My implementation is available as Matlab code and as Excel spreadsheet here: http://code.google.com/p/wimax-scanner/source/browse/matlab/get_slot_data.m http://code.google.com/p/wimax-scanner/source/browse/matlab/PUSC-permutation.xls It is able to correctly list sub-carriers for FCH of segment 0 (i.e. for subchannels 0-3), but looks like it gives incorrect results for all other subchannels. The result of this is that I can see only two consecutive repetitions of slot data in DL-MAP part of the header, where I should see 4 or 6 repetitions. The standard is very vague and unclear on this topic and people who write textbooks certainly thinks it's an obvious part and no one document it in an understandable way. If you have a working implementation of DL-PUSC subchannelization, which you can't share with us, we would appreciate if you just share mappings of subchannels to sub-carriers for a few sets of parameters. That would be very helpful for us to debug our own code. PS If you're interested in contributing to an open-source WiMAX implementation - you're very welcome to join the effort! We believe we can make a real difference in the wireless world. -- Regards, Alexander Chemeris. http://www.fairwaves.ru ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help : Where is the demodulation blocks implemented in gnuradio [ GMSK,PSK etc].
Thanks nick for your immediate reply , if we have different demodulation modules and as i have learnt recently that usrp/gnuradio does not do any default demodulation , than what captured file from usrp_rx_cfile contains ... is that the captured file contains the complete baseband information present in a particular frequency .. and as per the demodulation block applied to the captured file , we get the required information. Thanks. On Thu, Apr 7, 2011 at 9:51 PM, Nick Foster wrote: > On Thu, 2011-04-07 at 20:04 +0530, ton ph wrote: > > Hi guys , > > I Just want to confirm a thing regarding the demodulation of the > > digital dat in the gnuradio as the signals are received from the usrp. > > The doubt are, > > 1. Where is the demodulation is implemented in the gnuradio . > > In any of the demodulation blocks. AM demod, FM demod, PSK demod, etc. > > > 2. What demodulation is implemented by default in the > > urp_rx_cfile ... > > None. > > > please do help me someone in clearing my doubts . > > > > Thanks > > > > > > -- > > Phenomenon > > # Life is the most precious phenomenon ever happen ... > > > > # Lets pray and give emotional strength to the innocent brave victims > > of japan > > # they are human and m also a human which implies we are one. > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -- Phenomenon # Life is the most precious phenomenon ever happen ... # Lets pray and give emotional strength to the innocent brave victims of japan # they are human and m also a human which implies we are one. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help : Where is the demodulation blocks implemented in gnuradio [ GMSK,PSK etc].
Thanks Marcus for your valuable information . Now as per you have said that the usrp/gnuradio doesnt do any default demodulation , that means if i apply a demodulation technique to the captured file from usrp_rx_cfile.py , i will get the required output.For example if i apply GMSK demodulation to the captured file i ll get the properly formatted output as per the GSM protocol ... right. Thanks On Thu, Apr 7, 2011 at 10:02 PM, Marcus D. Leech wrote: > On 07/04/2011 10:34 AM, ton ph wrote: > >> Hi guys , >> I Just want to confirm a thing regarding the demodulation of the digital >> dat in the gnuradio as the signals are received from the usrp. The doubt >> are, >> 1. Where is the demodulation is implemented in the gnuradio . >> 2. What demodulation is implemented by default in the urp_rx_cfile ... >> please do help me someone in clearing my doubts . >> >> Thanks >> > Gnu Radio is a generic digital-signal-processing framework. Which includes > *many* pre-built processing blocks, including demodulators > and modulators, correlators, detectors, etc, etc. > > There is no *default* demodulation scheme anywhere in the basic > architecture, and usrp_rx_cfile is used to simply copy samples as they > come off the USRP hardware into a file. > > The USRP hardware doesn't do any demodulation--the signal you see delivered > to the host PC is just filtered/decimated baseband > samples as they come off the ADC, appropriately scaled for use inside Gnu > Radio. The USRP hardware doesn't know anything > about modulation or demodulation, per se. All of that is the > responsibility of the host software. Correspondingly, the transmit > side of the USRP hardware doesn't *know* anything about modulation, > either. It is entirely up to the host software to provide > appropriately-modulated samples for the hardware to dutifully turn into > analog signals and then (usually) up-convert to the > desired RF band of interest. Generally, the host interface operates in > "baseband" mode--the (complex) samples are centered at DC. > > Cheers > > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Phenomenon # Life is the most precious phenomenon ever happen ... # Lets pray and give emotional strength to the innocent brave victims of japan # they are human and m also a human which implies we are one. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
