[Discuss-gnuradio] KNOPPIX
Hello all I believe that some time ago there was a KNOPPIX live CD with GNURADIO. I have been unable to locate any ISO though. Does an ISO exist (if so please point to the URL of the latest ISO) or do I need to remaster KNOPPIX with GNURADIO? Cheers and many thanks in advance. Gerard Borg ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] KNOPPIX
[EMAIL PROTECTED] wrote: or do I need to remaster KNOPPIX with GNURADIO? If it turns out you need to remaster, we (almost) have Debian packages available for GNU Radio 3.1.0. The ones in our repository are made for Ubuntu = 7.04; there are slight differences with Debian etch that I'm looking for assistance with. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] KNOPPIX
[EMAIL PROTECTED] wrote: Hello all I believe that some time ago there was a KNOPPIX live CD with GNURADIO. I have been unable to locate any ISO though. Does an ISO exist (if so please point to the URL of the latest ISO) or do I need to remaster KNOPPIX with GNURADIO? It was a very old version. It is not as hard to install gnuradio now, so we have not made a new bootable CD for a while. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Encoder Integration
Hi, I have implemented a convolutional encoder and a viterbi decoder in Verilog and am trying to integrate it with the existing GNU Radio software and make it available to everyone, once I integrate it. My encoder takes in the input binary bits and generates encoded binary bits, based on defined parameters. I am first focusing on integrating the encoder with the GNU Radio software. My understanding from the code is that the following steps are performed while transmitting ( i.e. benchmark_tx.py, transmit_path.py, pkt_py, modulation_utils.py ) : 1)Generate random bits. 2)Map bits to symbols (gmsk or any other modulation ) 3)Convolve the symbols with a wave and taking discrete samples (Sampling) 4)Combine the step (3) samples with header information and make a packet. 5)Pass it on to the FPGA. Generating bits and sending it to FPGA for encoding using my encoder module and sending the encoded bits back to follow the above chain will possibly not make sense as I am overusing the bus resources, which would defeat the purpose of encoding in Verilog/FPGA . (bus usage should decrease by transmitting raw bits across the bus). So, should I pass all the above (steps 1 to 5) functionalities into the FPGA i.e. generate, encode, map, convolve inside the FPGA and then pass it on to the existing functionalities in the FPGA ? Or is there a more optimum way to do this ? Any inputs on the above would help me. I am stuck with this problem for quite some time now. Please correct me if I am going wrong somewhere. Thanks. Best Regards, S. Mande. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] patch to extended oscope to enable dualchan and complex mode on basicRX and basicTX
Eric Blossom wrote: On Fri, Oct 26, 2007 at 07:14:48PM +0200, Martin Dvh wrote: Hi all, inspired by the question of George Nychis I extended the usrp_oscope.py script to enable dualchannel and complex mode for basicRX and LFRX. You can find a patch and the complete modified script at: http://www.olifantasia.com/projects/gnuradio/mdvh/oscope_basicrx_dualchan/ You can copy the new script or apply the patch to your current gr-utils/src/usrp_oscope.py. The patch should apply cleanly if you have version 3.1 of gnuradio. There are two new commandline options: -C, --basic-complex Use both inputs of a basicRX or LFRX as a single Complex input channel -D, --basic-dualchan Use both inputs of a basicRX or LFRX as seperate Real input channels With --basic-complex both inputs of a basicRX or LFRX are enabled to form a single complex channel (I=input A, Q=input B) With --basic-dualchan both inputs are treated seperately and so you get two input real channels. (I1=input A, Q1=0, I2=input B, Q2=0) The difference between the two options becomes clear when you set a nonzero frequency. With the dualchannel option you can set the frequence for each channel seperately. With the complex option you can set only one frequency. If you set this to nonzero, this is only usefull if you actually have an I and Q signal connected to both inputs. Greetings, Martin Thanks Martin! Can you please go ahead and commit your patch? Done, I think this is an improvement but maybe it can still be improved further. The disadvantage of my current patch is that knowledge about daughterboards and muxvalues is in the oscope script. It is always better to have this info/knowledge in one place, and one place only. This would mean we would have to extend the code in gr-usrp. What do you think about the following possble setup: for basicRX and LFRX the subdev code could be extended the following way. subdevspec A:0 use input A of daughteboard A as a real input iscomplex() should return False subdevspec A:1 use input B of daughteboard A as a real input iscomplex() should return False subdevspec A use input A and B of daughteboard A as a complex input iscomplex() should return True (Note however this would change the API. At the moment you actually get A:0 when you specify A. We could also do something like A:real (which would be an alias for A:0) and A:complex which would give a complex input using both inputs. It gets more complicated when you want to use multiple inputs as multiple channels. You would want to be able to call usrp.determine_rx_mux_value() with multiple subdev specs for example: usrp.determine_rx_mux_value(self.u, (options.rx_subdev_spec0,options.rx_subdev_spec1)) What do you think? Martin Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Encoder Integration
S Mande wrote: Hi, I have implemented a convolutional encoder and a viterbi decoder in Verilog and am trying to integrate it with the existing GNU Radio software and make it available to everyone, once I integrate it. My encoder takes in the input binary bits and generates encoded binary bits, based on defined parameters. I am first focusing on integrating the encoder with the GNU Radio software. My understanding from the code is that the following steps are performed while transmitting ( i.e. benchmark_tx.py, transmit_path.py, pkt_py, modulation_utils.py ) : 1)Generate random bits. 2)Map bits to symbols (gmsk or any other modulation ) 3)Convolve the symbols with a wave and taking discrete samples (Sampling) 4)Combine the step (3) samples with header information and make a packet. 5)Pass it on to the FPGA. Generating bits and sending it to FPGA for encoding using my encoder module and sending the encoded bits back to follow the above chain will possibly not make sense as I am overusing the bus resources, which would defeat the purpose of encoding in Verilog/FPGA . (bus usage should decrease by transmitting raw bits across the bus). So, should I pass all the above (steps 1 to 5) functionalities into the FPGA i.e. generate, encode, map, convolve inside the FPGA and then pass it on to the existing functionalities in the FPGA ? Or is there a more optimum way to do this ? Well you could still generate the random bits on the host. You should however implement the other steps on the FPGA. There are ways to implement optimized root-raised cosine filters and (fractional) resampler filters in the FPGA if you do BPSK or QPSK. (because you only have +1.0 and -1.0 values) (I have some code for that if you need it) You said you already had implemented a convolutional encoder and a viterbi decoder in Verilog. So it seems like combining all the parts is what has to be done. Where exactly are you stuck. Any inputs on the above would help me. I am stuck with this problem for quite some time now. Maybe it would help if you published what you got now somewhere, so people can help by looking at your code. Please correct me if I am going wrong somewhere. Thanks. Best Regards, S. Mande. ___ 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] Failing test_mblock
Hi. I installed the gnuradio from the trunk. I ran make check with no errors. But when I run test_mblock it gives the following: .. mb_runtime_thread_per_block: dtor (# workers = 4) . mb_runtime_thread_per_block: dtor (# workers = 6) ...Segmentation fault What could be the cause of this error and how can it be fixed. Thanks. Owais ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failing test_mblock
[EMAIL PROTECTED] wrote: Hi. I installed the gnuradio from the trunk. I ran make check with no errors. But when I run test_mblock it gives the following: .. mb_runtime_thread_per_block: dtor (# workers = 4) . mb_runtime_thread_per_block: dtor (# workers = 6) ...Segmentation fault What could be the cause of this error and how can it be fixed. Hi Owais, Can you provide us with more information about your install? Like machine specs, the Linux distribution you are running, if you're running under cygwin. Else, we have to guess :) - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Encoder Integration
Thank you Martin for your reply. I wasent sure if rest of the 4 steps needed to be pushed to the FPGA ? And if the current USRP implementation on the FPGA leaves that much room for expansion? This is where I was stuck, thinking if there was any other alternate flow / solution ? So, i guess the flow should be: 1) Generate the bits on the host. (Then, Pass on those raw bits to the FPGA) Everything after this on the FPGA. 2) Mapping of the bits to symbols (This should'nt be difficult as this can be implemented using look up tables in Verilog) -- Needs to be implemented in Verilog 3) Convolving the symbols with root raised cosine filter (or any other wave) -- Needs to be implemented in Verilog 4) Sampling the resultant signal. -- Needs to be implemented in Verilog After this, it should be normal flow of the existing GNU Radio FPGA implementation. Please correct me if I am going wrong or please reply if I am right (It is easy to confuse no response with being right !) Also, I would be more than happy to use your (Martin) code, as it will save my time reimplementing the same logic again. I think that my code would be more meaningful to others, once I have atleast integrated the 'transmitter' portion. Best Regards, S. Mande. P.S. Martin: I would be happy to use your code if you could send the same to [EMAIL PROTECTED] (with appropriate rights / notices if you wish) ! It was kind of you to suggest the same to me. On 10/28/07, Martin Dvh [EMAIL PROTECTED] wrote: S Mande wrote: Hi, I have implemented a convolutional encoder and a viterbi decoder in Verilog and am trying to integrate it with the existing GNU Radio software and make it available to everyone, once I integrate it. My encoder takes in the input binary bits and generates encoded binary bits, based on defined parameters. I am first focusing on integrating the encoder with the GNU Radio software. My understanding from the code is that the following steps are performed while transmitting ( i.e. benchmark_tx.py, transmit_path.py, pkt_py, modulation_utils.py ) : 1)Generate random bits. 2)Map bits to symbols (gmsk or any other modulation ) 3)Convolve the symbols with a wave and taking discrete samples (Sampling) 4)Combine the step (3) samples with header information and make a packet. 5)Pass it on to the FPGA. Generating bits and sending it to FPGA for encoding using my encoder module and sending the encoded bits back to follow the above chain will possibly not make sense as I am overusing the bus resources, which would defeat the purpose of encoding in Verilog/FPGA . (bus usage should decrease by transmitting raw bits across the bus). So, should I pass all the above (steps 1 to 5) functionalities into the FPGA i.e. generate, encode, map, convolve inside the FPGA and then pass it on to the existing functionalities in the FPGA ? Or is there a more optimum way to do this ? Well you could still generate the random bits on the host. You should however implement the other steps on the FPGA. There are ways to implement optimized root-raised cosine filters and (fractional) resampler filters in the FPGA if you do BPSK or QPSK. (because you only have +1.0 and -1.0 values) (I have some code for that if you need it) You said you already had implemented a convolutional encoder and a viterbi decoder in Verilog. So it seems like combining all the parts is what has to be done. Where exactly are you stuck. Any inputs on the above would help me. I am stuck with this problem for quite some time now. Maybe it would help if you published what you got now somewhere, so people can help by looking at your code. Please correct me if I am going wrong somewhere. Thanks. Best Regards, S. Mande. ___ 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] Failing test_mblock
[EMAIL PROTECTED] wrote: Hi. I installed the gnuradio from the trunk. I ran make check with no errors. But when I run test_mblock it gives the following: .. mb_runtime_thread_per_block: dtor (# workers = 4) . mb_runtime_thread_per_block: dtor (# workers = 6) ...Segmentation fault What could be the cause of this error and how can it be fixed. Hi Owais, Can you provide us with more information about your install? Like machine specs, the Linux distribution you are running, if you're running under cygwin. Else, we have to guess :) - George Machine: Intel P-4 OS: Ubuntu Dapper 6.06 Gnuradio: Trunk Is there something specific you are looking for? Thanks. Owais ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failing test_mblock
On Sun, Oct 28, 2007 at 06:22:01PM -0500, [EMAIL PROTECTED] wrote: Hi. I installed the gnuradio from the trunk. I ran make check with no errors. But when I run test_mblock it gives the following: .. mb_runtime_thread_per_block: dtor (# workers = 4) . mb_runtime_thread_per_block: dtor (# workers = 6) ...Segmentation fault What could be the cause of this error and how can it be fixed. You can ignore it for now. There's a race during shutdown that hasn't been fully sorted out. It's loggged as ticket:180. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] patch to extended oscope to enable dualchan and complex mode on basicRX and basicTX
On Mon, Oct 29, 2007 at 12:34:12AM +0100, Martin Dvh wrote: Eric Blossom wrote: Can you please go ahead and commit your patch? Done, I think this is an improvement but maybe it can still be improved further. The disadvantage of my current patch is that knowledge about daughterboards and muxvalues is in the oscope script. It is always better to have this info/knowledge in one place, and one place only. This would mean we would have to extend the code in gr-usrp. What do you think about the following possble setup: for basicRX and LFRX the subdev code could be extended the following way. subdevspec A:0 use input A of daughteboard A as a real input iscomplex() should return False subdevspec A:1 use input B of daughteboard A as a real input iscomplex() should return False subdevspec A use input A and B of daughteboard A as a complex input iscomplex() should return True (Note however this would change the API. At the moment you actually get A:0 when you specify A. We could also do something like A:real (which would be an alias for A:0) and A:complex which would give a complex input using both inputs. The Basic Rx and LF Rx are only boards that this matters with. As you said A and A:0 and equivalent. Perhaps we should extend the syntax to support A:* or some such. It gets more complicated when you want to use multiple inputs as multiple channels. You would want to be able to call usrp.determine_rx_mux_value() with multiple subdev specs for example: usrp.determine_rx_mux_value(self.u, (options.rx_subdev_spec0,options.rx_subdev_spec1)) Unless it's really transparent, and makes sense for most cases, I think I'd want to leave it alone. Part of problem is that for the multichannel case, you start to get additional constraints when it comses to frequency setting etc. E.g., extracting two channels from a single daughterboard vs extracting two channels from two daughterboards. If you can think of way to handle the entire mess in a way that makes sense, and doesn't complicate the typical single channel case, I'm all ears. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Encoder Integration
Here are some of the thoughts running through my head in no particular order. You don't have to have the RRC filter for transmit if you don't want to. The CIC and the reconstruction filter of the DAC should take care of filtering out a good portion of the extra spectrum. To achieve the best performance with the convolutional code, some interleaving should also be used to utilize time diversity on the burst transmission. The modulator LUT should really be an M-QAM LUT that can be configured to restrict itself to QPSK or BPSK as well. Another option would be to try to figure out a CPM style mapper that can be used and/or updated in-band to utilize a different number of CPM waveforms that require no extra filtering and have the filtering built into the LUTS. The Viterbi decoder will probably not be of use while there is no receiver functionality built into the FPGA as well. As such, the testbench for the Viterbi decoder should probably be extremely extensive and more effort should go into making the decoder extremely generic (eg: How many ACS units to use in parallel, should traceback be done in a burst or windowed, programmable constraint length and generator polynomial, etc). How hard would it be to change the algorithm to be a soft output Viterbi algorithm (SOVA) for use with Turbo Codes? Here is a little stub: http://en.wikipedia.org/wiki/Soft_output_Viterbi_algorithm Robustness is key to utilizing this code in the fullest extent. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
