Re: [Discuss-gnuradio] usrp_tv_rcv.py on Leopard
Casey - OK; you were right to not post that whole log the first time. Any one of the parts such as 2008-04-27 15:59:32.006 Python[11995:717] *** _NSAutoreleaseNoPool(): Object 0x29c0400 of class NSCFData autoreleased with no pool in place - just leaking would have sufficed nicely. Let's make this a lesson to others as well: Start out by including the minimum you reasonably can from a log, and working your way up if that wasn't enough info. Sending the whole log will probably just piss folks off. Anyway, here's addressing your log: usrp_tv_rcv uses video_sdl, which uses SDL, which is known to have issues running on OSX. I've never been able to make it work on either 10.4 or 10.5, though maybe I'm just unlucky - YMMV. When I (or you) try to use this, I get those _NSAutoreleaseNoPool errors also - so, again, I'd say this is normal for OSX ... unfortunately. From my reading, this might be a Objective- C issue w/r.t. Apple's additions to GCC. Wish I could say more; maybe others can? - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QPSK demodulation problem
hi, I am trying to implement a QPSK receiver with GNU radio using the board RFX2400 where I take the input from signal generator. The symbol rate of signal generator is 1Msym/sec sending a constant pattern of 0010 and i have set the decimation in USRP to 16 to have 4 samples per symbol. I suppose that I have done the calculation correct since the ADC rate is 64 Msa/sec. Since i am not very familiar with the parameters of frequency and timing synchronization blocks i have just used the default ones: costas_alpha=0.15 mu=0.05 omega_re_limit=0.5 When I look at the demodulated bit stream by reading the file rx_unpack.dat (which should supposedly be showing the demodulated bits) what I get is arbitrary 0's and 1's which has nothing to do with the pattern 0010 that I am sending. Does anybody have any idea where might be the problem? Secondly I am recording the data before and after the frequency/time synchronization block so that I can plot the constellation points before and after the synchronization. I suppose that the recorded data is in the format [I Q] so for example when I read [32 64 128 196] then 32 is the decimal equivalent of the first 8 bits of I and 64 is the decimal equivalent of last 8 bits. Sİmilarly 128 is the first 8bits of Q and 196 is the last 8. Can anyone validate this ? and how about the sign, how is it determined? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Retrieving file from packets received by benchmark_rx.py
Hello, I have been playing around with benchmark_tx.py and benchmark_rx.py I was able to transmit packets (generated from a Text File) over the air to another computer. My question is, is there a way to retrieve the original file from the actual packets? It would be greatly appreciated if someone would point me to the right direction. Thank you -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/messages/discuss-gnuradio@gnu.org/topic.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: polymorphic type documentation (PMT)
George, Thanks for coming up with the doc so fast. This helped a lot! A few comments: 1. In section Constructing / Assigning a PMT: isn't pmt_list part of this too? 2. In PMT Conversion Methods: what's the difference between using a construction method and a conversion method to generate a PMT type? For example, one can use either pmt_integer(long) or pmt_from_long() to get a pmt long type. - David On Sat, 2008-04-26 at 00:36 -0400, George Nychis wrote: Hi all, I've added documentation on the new polymorphic type in GNU Radio, PMT, to the GNU Radio wiki: http://gnuradio.org/trac/wiki/TypePMT It has full details of many of the methods, how to use a PMT, how to assign it values, how to do type conversions, etc... For more difficult PMT types (lists, dictionaries, etc...), I have added detailed sections. This is all part of my attempt to make a better wiki... http://gnuradio.org/trac/wiki/WikiStartNew ... I'm branching out from the m-block info, slowly but surely! - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: polymorphic type documentation (PMT)
1. I have to check, but I think so 2. Actually, this is a slight mis-conception from my documentation which I need to fix tonight. pmt_integer() is not a public member of the PMT class. You need to use pmt_from_long(X) which will return you a pmt_t which is an instance of a pmt_integer. I need to make this clear and update my documentation. If you look at any of the inband code or my MAC examples, you will always see pmt_from_long() and pmt_to_long() - George David Li wrote: George, Thanks for coming up with the doc so fast. This helped a lot! A few comments: 1. In section Constructing / Assigning a PMT: isn't pmt_list part of this too? 2. In PMT Conversion Methods: what's the difference between using a construction method and a conversion method to generate a PMT type? For example, one can use either pmt_integer(long) or pmt_from_long() to get a pmt long type. - David On Sat, 2008-04-26 at 00:36 -0400, George Nychis wrote: Hi all, I've added documentation on the new polymorphic type in GNU Radio, PMT, to the GNU Radio wiki: http://gnuradio.org/trac/wiki/TypePMT It has full details of many of the methods, how to use a PMT, how to assign it values, how to do type conversions, etc... For more difficult PMT types (lists, dictionaries, etc...), I have added detailed sections. This is all part of my attempt to make a better wiki... http://gnuradio.org/trac/wiki/WikiStartNew ... I'm branching out from the m-block info, slowly but surely! - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK demodulation problem
Ahmet Hasim Gokceoglu wrote: hi, I am trying to implement a QPSK receiver with GNU radio using the board RFX2400 where I take the input from signal generator. The symbol rate of signal generator is 1Msym/sec sending a constant pattern of 0010 and i have set the decimation in USRP to 16 to have 4 samples per symbol. I suppose that I have done the calculation correct since the ADC rate is 64 Msa/sec. Ahmet, I'm not sure I understand how you are generating your input signal. What signal generator? Is this an external sig gen, or are you somehow generating the signal with GNU Radio? Also, are you using the dqpsk.py for the DQPSK mod/demod functions? I wasn't sure if you were building your own QPSK receiver. Since i am not very familiar with the parameters of frequency and timing synchronization blocks i have just used the default ones: costas_alpha=0.15 mu=0.05 omega_re_limit=0.5 These defaults were set because they worked with the implementation or the receiver. They should be fine. When I look at the demodulated bit stream by reading the file rx_unpack.dat (which should supposedly be showing the demodulated bits) what I get is arbitrary 0's and 1's which has nothing to do with the pattern 0010 that I am sending. Does anybody have any idea where might be the problem? Again, it will depend on how you are generating the input symbols. If you are using the packet modulator code we have in /digital/benchmark_tx.py, the packets transmitted are first whitened. The file rx_unpack.dat is captured before the signal is dewhitened. You can turn whitening off by looking at gnuradio-core/src/python/gnuradio/packet_utils.py in the unmake_packet function for how. If you are not using the benchmark_tx to generator your symbols and are sending over the 0010 bit stream, what you are doing is sending over a very specific pattern (0 degree shift followed by a 90 degree shift) that will bias the recovery loops. Try sending a longer more random sequence. Secondly I am recording the data before and after the frequency/time synchronization block so that I can plot the constellation points before and after the synchronization. I suppose that the recorded data is in the format [I Q] so for example when I read [32 64 128 196] then 32 is the decimal equivalent of the first 8 bits of I and 64 is the decimal equivalent of last 8 bits. Sİmilarly 128 is the first 8bits of Q and 196 is the last 8. Can anyone validate this ? and how about the sign, how is it determined? If you're using file_sink(gr.sizeof_float, file.dat), the output is 32-bit float for the I and 32-bit float for the Q. It's standard IEEE 754 or whatever style. You can use the Python/Matplotlib tools we have in gr-utils/src/python for plotting these files. They are installed into your system now (/usr/local/bin unless you changed the prefix) and called gr_plot_*. You can look at the constellation with gr_plot_const.py filename Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Retrieving file from packets received by benchmark_rx.py
[EMAIL PROTECTED] wrote: Hello, I have been playing around with benchmark_tx.py and benchmark_rx.py I was able to transmit packets (generated from a Text File) over the air to another computer. My question is, is there a way to retrieve the original file from the actual packets? It would be greatly appreciated if someone would point me to the right direction. Thank you If you aren't getting the file out, how do you know you are able to transmit then to another computer? If I understand your question, you'd have to look at the rx_callback function in benchmark_rx.py to write the file to disk. Currently, it just spits out some stats and discards the payload. You need to make it do something interesting with the payload. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multirate DSP Articles
There are an interesting set of articles on multirate signal processing over at DSP Design Line. So far the two parts have covered basic upconversion and downconversion as well as non-integer sampling factors. Both articles can be found here: http://www.dspdesignline.com/howto/207400771?printableArticle=true - Multirate DSP, part 1: Upsampling and downsampling http://www.dspdesignline.com/howto/207402260?printableArticle=true - Multirate DSP, part 2: Noninteger sampling factors I like the use of examples and actual numbers/graphs to help illustrate the points. I am not trying to advertise the book or persuade anyone to try to buy it, I just thought I'd share the articles since they seemed pretty well put together and a good starting point. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK demodulation problem
Do we have a QPSK (not a DQPSK)Demodulator available and operational in gnuradio??? Ahmet Hasim Gokceoglu wrote: hi, I am trying to implement a QPSK receiver with GNU radio using the board RFX2400 where I take the input from signal generator. The symbol rate of signal generator is 1Msym/sec sending a constant pattern of 0010 and i have set the decimation in USRP to 16 to have 4 samples per symbol. I suppose that I have done the calculation correct since the ADC rate is 64 Msa/sec. Ahmet, I'm not sure I understand how you are generating your input signal. What signal generator? Is this an external sig gen, or are you somehow generating the signal with GNU Radio? Also, are you using the dqpsk.py for the DQPSK mod/demod functions? I wasn't sure if you were building your own QPSK receiver. Since i am not very familiar with the parameters of frequency and timing synchronization blocks i have just used the default ones: costas_alpha=0.15 mu=0.05 omega_re_limit=0.5 These defaults were set because they worked with the implementation or the receiver. They should be fine. When I look at the demodulated bit stream by reading the file rx_unpack.dat (which should supposedly be showing the demodulated bits) what I get is arbitrary 0's and 1's which has nothing to do with the pattern 0010 that I am sending. Does anybody have any idea where might be the problem? Again, it will depend on how you are generating the input symbols. If you are using the packet modulator code we have in /digital/benchmark_tx.py, the packets transmitted are first whitened. The file rx_unpack.dat is captured before the signal is dewhitened. You can turn whitening off by looking at gnuradio-core/src/python/gnuradio/packet_utils.py in the unmake_packet function for how. If you are not using the benchmark_tx to generator your symbols and are sending over the 0010 bit stream, what you are doing is sending over a very specific pattern (0 degree shift followed by a 90 degree shift) that will bias the recovery loops. Try sending a longer more random sequence. Secondly I am recording the data before and after the frequency/time synchronization block so that I can plot the constellation points before and after the synchronization. I suppose that the recorded data is in the format [I Q] so for example when I read [32 64 128 196] then 32 is the decimal equivalent of the first 8 bits of I and 64 is the decimal equivalent of last 8 bits. SÄ°milarly 128 is the first 8bits of Q and 196 is the last 8. Can anyone validate this ? and how about the sign, how is it determined? If you're using file_sink(gr.sizeof_float, file.dat), the output is 32-bit float for the I and 32-bit float for the Q. It's standard IEEE 754 or whatever style. You can use the Python/Matplotlib tools we have in gr-utils/src/python for plotting these files. They are installed into your system now (/usr/local/bin unless you changed the prefix) and called gr_plot_*. You can look at the constellation with gr_plot_const.py filename Tom ___ 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] help with tuning RFX2400 MIMO_b, weird RX results
Hi all, First, I'm sorry if my actions are shunned upon (C++ daughterboard code outside the mainstream repository), but I could sincerely use help with a deadline approaching next week. I am trying to use code that Per started for tuning a MIMO_b RFX card in C++. Using the base code he gave me, I was able to get the transmitter working bot not receiver. I am trying to receive a GMSK transmission. Here is a normal reception after tuning the card in python: http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/gmsk_regular.jpg http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/gmsk_regular_rvi.jpg ... we get a nice clean circular transmission. When I attempt to receive using the C++ RX code, that I modified to set the RX gain, I get the following square-like transmission: http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/gmsk_flex.jpg http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/gmsk_flex_rvi.jpg Based on these results, does anyone have any insight in to what I may be tuning incorrectly? I thought it might be the gain setting, but I mimiced the set_gain() method exactly with the python code and ensure the write_aux_dac() and set_pga() values are the same: https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/dboard_code/db_flexrf_mimo.cc#L193 To tune the cards, I am using: db_flexrf_mimo dboards(d_urx, d_utx, 0); dboards.configure(d_rf_freq, 45, 0); dboards.configure(d_rf_freq, 0, 1); dboards.select_tx(); I followed through almost every function call and I can't seem to find the different in tuning between my code and the python. I'd greatly appreciate any insight. Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
