[Discuss-gnuradio] GnuRadio, VLF, Metal Detecting...
Hi there, Im gls and I just registered. Sorry for my english. Im thinking about a sort of linux laptop converted in a vlf metal detector using GnuRadio and is internal soundcard connected to a coil/sensor and if necessary a preamp... Do you know of someone that have tried this experiment? Can you help me with suggestion, link, code or whatever? Thanks in advance, excuse me for the strange question. I hope to receive help :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 802.11 BBN in SuSE
Hi guys, has anyone tried to capture live 802.11b - 1mbit packets using the 802.11BBN source code in SuSE ? I'm trying to do so, but I'm encountering problems. First of all, when I run usrp_fft or usrp_oscope I can definitely see something. At least, I see power fluctuations due to my laptop's WLAN (old 802.11b) card. However, if I try to run ./bbn_80211b_tx.py I get the following error: Using TX d'board A: Flex 2400 Tx MIMO B gr_fir_ccf: using SSE spb:8 interp: 32 Failed to set Tx frequency to 2.4G I also tried to capture packets, using ./bbn_80211b_rx.py -d 8 -f 2412e6 -p , however I can't see any packets. Anyone an Idea ? -- View this message in context: http://www.nabble.com/802.11-BBN-in-SuSE-tf3977436.html#a11290356 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] reporting control/status responses for inband signaling?
This is a perfect question for Eric, but unfortunately he is on vacation. So I'm hoping that maybe Brian or someone can answer who was involved in the initial design of the inband USB packets :) The way we have the low-level control/status packets designed, I'm not sure how the application can ever get a response back correctly. Heres how we have them defined: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb#L116 They use the same packet header as data packets, except the channel is fixed to 0x1f so they can be deciphered as CS packets easily in the FPGA. If we do this, how are we ever supposed to properly determine what application to send the response back to? The current chain to get a CS packet to the USRP is like this: Application - usrp_server - USRP It's very straight forward, but sending responses back is a problem: USRP - usrp_server - ? How does usrp_server, which parses the USB packets, know which application to send the CS response to? The packets used to be demuxed by channel since channels are owned by specific applications, and therefore the channel is read to determine the application. In this case, the channel says absolutely nothing about the application that sent it. So for example, the way the ports are setup: http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/lib/inband/usrp_server.mbh usrp-tx includes usrp-low-level-cs so that I can send a PING over a TX channel that I own, and usrp-rx includes usrp-low-level-cs so that I can receive the PING response over an RX channel I own. So, sending the PING works just great, but again how will usrp_server know what RX channel to place the response on? The packets don't seem setup for this. It would make more sense if we had a single bit that specified it was a CS packet, and then the channel specifies which RX channel to send the response on. Maybe I'm missing something? - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: reporting control/status responses for inband signaling?
On 6/25/07, George Nychis [EMAIL PROTECTED] wrote: This is a perfect question for Eric, but unfortunately he is on vacation. So I'm hoping that maybe Brian or someone can answer who was involved in the initial design of the inband USB packets :) I'll do my best to figure it out. The way we have the low-level control/status packets designed, I'm not sure how the application can ever get a response back correctly. Heres how we have them defined: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb#L116 They use the same packet header as data packets, except the channel is fixed to 0x1f so they can be deciphered as CS packets easily in the FPGA. If we do this, how are we ever supposed to properly determine what application to send the response back to? I should note here that the USRP doesn't care which application on the host requests the different actions, which is probably why we have the fixed channel of 0x1f. The USRP is simply the endpoint. The current chain to get a CS packet to the USRP is like this: Application - usrp_server - USRP It's very straight forward, but sending responses back is a problem: USRP - usrp_server - ? How does usrp_server, which parses the USB packets, know which application to send the CS response to? The packets used to be demuxed by channel since channels are owned by specific applications, and therefore the channel is read to determine the application. In this case, the channel says absolutely nothing about the application that sent it. Looking at the payload of the control channel, any of the op codes that write something and then have the USRP reply back seem to have an RID within them to determine where to send things back. This is probably what should be inserted/stripped by the usrp_server to figure out which application receives the reply. I can see this working where the Application requests something (ping perhaps?) and sends the ping request to the usrp_server. The usrp_server constructs the packet with the next available RID (probably just some incremental counter mod 64, or if you don't expect one application to have multiple outstanding commands, just a unique number for each application which is reused - just ideas and you know this more than I would). After the USRP then processes the command and sends the reply back, the usrp_server will read the RID field of the received packet and forward the packet (minus the RID) back to the Application. I could be missing it just as much as you did, but what do you think about that? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question regarding output file format of usrp_rx_cfile.py
Hi, I was trying to change the script usrp_rx_cfile.py to generate a .dat file capturing the I and Q floats/interleaved shorts but I end up only getting a binary output file. Can anyone pls help me understand why the output file is in binary format? Other scripts which use gr.file_sink generate .dat output file Thanks for any and all help Meenaktchi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: reporting control/status responses for inband signaling?
Brian Padalino wrote: I should note here that the USRP doesn't care which application on the host requests the different actions, which is probably why we have the fixed channel of 0x1f. The USRP is simply the endpoint. Definitely, I agree with this. Looking at the payload of the control channel, any of the op codes that write something and then have the USRP reply back seem to have an RID within them to determine where to send things back. This is probably what should be inserted/stripped by the usrp_server to figure out which application receives the reply. I can see this working where the Application requests something (ping perhaps?) and sends the ping request to the usrp_server. The usrp_server constructs the packet with the next available RID (probably just some incremental counter mod 64, or if you don't expect one application to have multiple outstanding commands, just a unique number for each application which is reused - just ideas and you know this more than I would). After the USRP then processes the command and sends the reply back, the usrp_server will read the RID field of the received packet and forward the packet (minus the RID) back to the Application. I could be missing it just as much as you did, but what do you think about that? I think you're right on this, all of the commands which have a response have an RID. I'm going to go with the incremental counter mod X because I can imagine instances where one app could have multiple outstanding commands. It's unlikely, but for safety sake. Thanks for the response and insight, I was just going to 'broadcast' all responses to all applications for now... but now I can actually code it correctly ;) - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio, VLF, Metal Detecting...
Hi, Check : http://www.nuggethunting.com/detector_technology.htm I Think most of these technologies can be exploited with USRP + [LFTX DC-30 MHz Transmitter LFRX DC-30 MHz Receiver] daughterborads. Firas Giuseppe Luca Scrofani wrote: Hi there, Im gls and I just registered. Sorry for my english. Im thinking about a sort of linux laptop converted in a vlf metal detector using GnuRadio and is internal soundcard connected to a coil/sensor and if necessary a preamp... Do you know of someone that have tried this experiment? Can you help me with suggestion, link, code or whatever? Thanks in advance, excuse me for the strange question. I hope to receive help :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/GnuRadio%2C-VLF%2C-Metal-Detecting...-tf3977166.html#a11295012 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] error using rx_voice.py
I am working on tx_voice.py and rx_voice.py and I am trying to embed a fixed sequence in the payload part of my packet. However, when i try to receive the data using rx_voice, i get an error saying terminate called after throwing an instance of 'std::runtime_error' what(): msg length is not a multiple of d_itemsize Aborted (core dumped) I have added only one line in make_packet in packet_utils.py and it looks like this:(just the important lines as i thought) def make_packet(payload, samples_per_symbol, bits_per_symbol, access_code=default_access_code, pad_for_usrp=True): (packed_access_code, padded) = conv_1_0_string_to_packed_binary_string(access_code) (packed_preamble, ignore) = conv_1_0_string_to_packed_binary_string(preamble) payload = packed_preamble + payload payload_with_crc = gru.gen_and_append_crc32(payload) pkt = ''.join((packed_access_code, make_header(L), whiten(payload_with_crc), '\x55')) if pad_for_usrp: pkt = pkt + (_npadding_bytes(len(pkt), samples_per_symbol, bits_per_symbol) * '\x55') return pkt Can anyone please explain how to remove this error. I want to add fixed sequence so that it helps in calculation of BER. Thanks, Pratik Hetamsaria - Heres a new way to find what you're looking for - Yahoo! Answers ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bug in wfm_rcv_pll and fix, who has stereo FM specs/info and noise and gain issues
Matt Ettus wrote: Martin Dvh wrote: Hi, I found a nasty bug in the wfm_rcv_pll.py code. The pilot tone pll should return the recovered carrier, For this you should use gr.pll_refout_cc, not gr.pll_carriertracking_cc. pll_carriertracking returns the input transformed to baseband using the recovered carrier. pll_refout returns the recovered carrier. Great catch, Martin. With the fixed code I now actually get stereo. (Before you would get a kind of attenuated, distorted, spectrum inverted stereo) Can you check it in? Done I tested it with a stereo-coder I wrote in gnuradio, and now I seem to actually get stereo seperation. (stereo modulater is attached) But now I do get a lot of noise when decoding stereo. I also don't quite understand why double side band suppressed carrier Left-Right audio is attenuated and needs a factor 20 for gain. (It seems to be correct or at least close) I would try this with the regular (non-PLL) FM demod. I think the rolloff of the PLL tracking loop is what is giving you the lower gain. The code comments say 10 dB The actual code uses a factor 20 which corresponds to 20 *log10(20)= 26 dB. This 26 dB seems to be quite accurate, but where is this number based on? can you give me a link to more info or the stereo FM specs on this. # Pick off the double side band suppressed carrier Left-Right audio. It is attenuated 10 dB so apply 10 dB gain stereo_dsbsc_filter_coeffs = gr.firdes.complex_band_pass(20.0, Greetings, Martin fix for wrong pll is below: --- gnuradio-core/src/python/gnuradio/blksimpl/wfm_rcv_pll.py 2007-06-11 18:12:55.0 +0200 +++ gnuradio-core/src/python/gnuradio/blksimpl/wfm_rcv_pll_fixed.py 2007-06-17 08:07:43.0 +0200 @@ -131,8 +131,8 @@ max_freq = -2.0*math.pi*18990/audio_rate; min_freq = -2.0*math.pi*19010/audio_rate; -self.stereo_carrier_pll_recovery = gr.pll_carriertracking_cc(alpha,beta,max_freq,min_freq); -self.stereo_carrier_pll_recovery.squelch_enable(False); +self.stereo_carrier_pll_recovery = gr.pll_refout_cc(alpha,beta,max_freq,min_freq); +#self.stereo_carrier_pll_recovery.squelch_enable(False) #pll_refout does not have squelch yet, so disabled for now # set up mixer (multiplier) to get the L-R signal at baseband ___ 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] about how to test RFX900 with USRP
Hi, I am a beginner in USRP for GNU Radio. I just buy two sets of USRP with RFX900 for our project. There is no any documents together with the package. That is fine for play USRP monther board. I have test the USRP and it is fine. But when I want to test a transmitter and receiver between two sets of USRP+RFX900, there is no any documents address this. I have to find which file may be used to test RFX900, and furthermore go through all the codes in that file to decide how to build up a link between two RFX900. Since there are almost no comments, it is very difficult for many beginners like me to understand. Does anyone have suggestions for: 1. which files should I use to test link between two RFX900? 2. which file may I use to set the power gain for trasmitter? since my experience before is LNA in receiver has maximum input power limit. 3. which file may I use to set different waveforms? 4. Is there such documents addressing these for beginner? Thank you very much! Best Regards, James ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about how to test RFX900 with USRP
2007/6/24, CHEN,ZHIFENG [EMAIL PROTECTED]: Hi, I am a beginner in USRP for GNU Radio. I just buy two sets of USRP with RFX900 for our project. There is no any documents together with the package. That is fine for play USRP monther board. I have test the USRP and it is fine. But when I want to test a transmitter and receiver between two sets of USRP+RFX900, there is no any documents address this. I have to find which file may be used to test RFX900, and furthermore go through all the codes in that file to decide how to build up a link between two RFX900. Since there are almost no comments, it is very difficult for many beginners like me to understand. Does anyone have suggestions for: 1. which files should I use to test link between two RFX900? Just change the carrier frequency, you may use a lot of files for test. For example, usrp_fft.py, usrp_nbfm_ptt.py, usrp_nbfm_rcv.py etc. http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-examples/python/digital is a good example for full duplex transmission. 2. which file may I use to set the power gain for trasmitter? since my experience before is LNA in receiver has maximum input power limit. Only the software gain. I mean the data you give to DA. 3. which file may I use to set different waveforms? 4. Is there such documents addressing these for beginner? Thank you very much! http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html how to write a block is a document for beginner. And http://www.nd.edu/~jnl/sdr/docs/tutorials/ is a good tutorial, but maybe not updated for a long time. Hope they are helpful for you. BR HUANG Lin Best Regards, James ___ 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
