[Discuss-gnuradio] ofdm channel estimation
Hi Martin: Greeting from xd.Thank you so much for your example tx_ofdm.grc and rx_ofdm.grc.I want to ask a question about channel estimation.And I know that the channel estimate is on a tag.But I want to make some changes on your example.So I just want to ask whether my understanding is right or not. I know the rx_ofdm include header stream and payload stream.In the payload stream,if i denote the data come from FFT block rx_data. channel=rx_data/tx_data Is it right?Is my understanding right?Thank you. Best regards, xd ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Slow control external hardware
On 29/07/2014 19:29, mle...@ripnet.com wrote: There are rather a lot of ways to choke this particular cat, writing a block is just one of them. I do control external device things from within GRC without custom blocks, using helper code and a polling function at a low rate that drives a simple state machine. I use this for controlling a serial device that turns calibration sources on/off. It can get data out of the flow-graph if it needs to, with low-rate probe blocks. Some might call this inelegant, I call it saving the headache of writing/maintaining custom blocks when the functionality doesn't really require real-time access to the sample stream Hello, well, writing a block that listens to messages or that emits messages takes less than 20 lines of python all included. I would hardly call this an headache to maintain :) Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Messages and flow-graph termination
Hello, as soon as I introduce a pair of block publishing and consuming messages, the GNURadio scheduler (version 3.7.2) does not terminate the execution of the flow-graph when the stream sources signal the end of the stream. This is also reflected in how the test case qa_python_message_passing checks for the termination of the execution. Is this by design, is it a known limitation, or is it a bug? Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What do Packet Encoder and Packet Decoder do?
On Wed, Jul 30, 2014 at 4:44 AM, Nguyễn Văn Lý lynguyenvan@gmail.com wrote: Hi all, Can anyone tell me what do *Packet Encoder* and *Packet Decoder* blocks do? and it would be great if you can give me some example :-) Thanks in advance Van-Ly These are very simple example blocks to show you how to packetize data. Packet bytes go in, they get wrapped into a packet of a given payload length with a header, access code, and preamble. The header is just a 2x repetition of the payload length (16 bits for each field). Leaving the preamble and access code blank just chooses the defaults. The decoder just looks for the access code with the number of available bits wrong. When it's found, it reads the header to get the payload length, extracts the payload, and outputs the payload. Hope this helps. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Messages and flow-graph termination
On Wed, Jul 30, 2014 at 7:50 AM, Daniele Nicolodi dani...@grinta.net wrote: Hello, as soon as I introduce a pair of block publishing and consuming messages, the GNURadio scheduler (version 3.7.2) does not terminate the execution of the flow-graph when the stream sources signal the end of the stream. This is also reflected in how the test case qa_python_message_passing checks for the termination of the execution. Is this by design, is it a known limitation, or is it a bug? Cheers, Daniele Yes, this is a know bug fixed in 3.7.4. See the release notes under Important Bug Fixes and Improvements: http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_7_4 Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Port flowgraph from Python to C++
On Tue, Jul 29, 2014 at 5:53 PM, Stefan Oltmanns stefan-oltma...@gmx.net wrote: Hello, I was able to create a flowgraph in GRC to demodulate a signal (low-frequency battery telegram of wireless microphones). Now I started to port the generated code from Python to C++. I had to realize that some blocks are Python-only, like the FM Demodulator. I was able to rebuild the FM Demodulator in C++, for one exception: The FM demodulator uses optfir, which is implemented in Python, so it cannot be used in C++. So I replaced it with firdes (I noticed the parameter difference in transition band end and transition band width). Another thing is that the Frequency-Xlating-Filter uses a complex lowpass, but in C++ I could only find a complex band-pass, so I used a band-pass with lower frequency 0, is that the same? Also it works, the signal is a lot noisier and the result cannot be decoded in many cases. I think the reason are the different filters. Could that be the reason? As I understood, both optfir and firdes create just a bunch of numbers and that´s it. As my program is not going change the filter parameters they could be hardcoded in my program, right? Best regards Stefan You can use gr_filter_design (or in GRC call it with Tools-Filter Design Tool) to show you the filter you designed. But I think your problem is the bandpass filter you created is probably only half of the bandwidth you want, so you're cutting out a large amount of information in your signal. The frequency xlating filter takes in the filter you define and moves it to the center frequency of the incoming signal by a complex multiply. You want this to then be a low-pass filter defined to be symmetric around 0. You can then use the freq_xlating_fir_filter_ccf version of the filter to take in the real taps defined by the lowpass filter. Alternatively, keep with the complex bandpass but define the lower passband edge as -B and the upper edge as +B. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Messages and flow-graph termination
On 30/07/2014 15:27, Tom Rondeau wrote: On Wed, Jul 30, 2014 at 7:50 AM, Daniele Nicolodi dani...@grinta.net mailto:dani...@grinta.net wrote: Hello, as soon as I introduce a pair of block publishing and consuming messages, the GNURadio scheduler (version 3.7.2) does not terminate the execution of the flow-graph when the stream sources signal the end of the stream. This is also reflected in how the test case qa_python_message_passing checks for the termination of the execution. Is this by design, is it a known limitation, or is it a bug? Cheers, Daniele Yes, this is a know bug fixed in 3.7.4. See the release notes under Important Bug Fixes and Improvements: http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_7_4 Hello Tom, thanks, I missed it from the release notes. There is a known workaround to stop execution of the flow-graph? Thanks. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Slow control external hardware
On 07/30/2014 07:40 AM, Daniele Nicolodi wrote: On 29/07/2014 19:29, mle...@ripnet.com wrote: There are rather a lot of ways to choke this particular cat, writing a block is just one of them. I do control external device things from within GRC without custom blocks, using helper code and a polling function at a low rate that drives a simple state machine. I use this for controlling a serial device that turns calibration sources on/off. It can get data out of the flow-graph if it needs to, with low-rate probe blocks. Some might call this inelegant, I call it saving the headache of writing/maintaining custom blocks when the functionality doesn't really require real-time access to the sample stream Hello, well, writing a block that listens to messages or that emits messages takes less than 20 lines of python all included. I would hardly call this an headache to maintain :) Cheers, Daniele It's a big universe, there's room for different design choices -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Spectrum sensing Simulation Only
On Tue, Jul 29, 2014 at 3:34 PM, Bogale, Tadilo Endeshaw tadilo.bog...@emt.inrs.ca wrote: Hello Everyone I am a new to gnuradio. I would like to do simulation of spectrum sensing (Simple energy detector with single band only). Normally I have seen usrp_spectrum_sense.py. However, that is written for USRP (and not easy to understand and modify it). Actually I have a difficulty in computing average and display it continuously in a graphical user interface. See also my grc and corresponding python code (The vector sinc block is not correct). Any help is appreciated. Thanks, --- Tadilo Endeshaw, PhD The easiest way to average is to use the single_pole_iir_filter to smooth out the data stream. But note that you're coming out of the FFT block as a vector. You can set the vector length of the single pole IIR, but I'd have to review exactly what that means mathematically. It probably smooths the entire vector as one as opposed to smoothing over index i in each vector. You might have to play around with that. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Spectrum sensing Simulation Only
On 07/30/2014 03:37 PM, Tom Rondeau wrote: The easiest way to average is to use the single_pole_iir_filter to smooth out the data stream. But note that you're coming out of the FFT block as a vector. You can set the vector length of the single pole IIR, but I'd have to review exactly what that means mathematically. It probably smooths the entire vector as one as opposed to smoothing over index i in each vector. You might have to play around with that. gr-specest might help you with that (pybombs install gr-specest, or https://github.com/kit-cel/gr-specest). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm channel estimation
On 07/30/2014 10:57 AM, xianda wrote: Hi Martin: Greeting from xd.Thank you so much for your example tx_ofdm.grc and rx_ofdm.grc.I want to ask a question about channel estimation.And I know that the channel estimate is on a tag.But I want to make some changes on your example.So I just want to ask whether my understanding is right or not. I know the rx_ofdm include header stream and payload stream.In the payload stream,if i denote the data come from FFT block rx_data. channel=rx_data/tx_data Is it right?Is my understanding right?Thank you. Yep. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Port flowgraph from Python to C++
On 07/29/2014 11:53 PM, Stefan Oltmanns wrote: Hello, I was able to create a flowgraph in GRC to demodulate a signal (low-frequency battery telegram of wireless microphones). Now I started Awesome! Are you planning to publish the code somewhere? M to port the generated code from Python to C++. I had to realize that some blocks are Python-only, like the FM Demodulator. I was able to rebuild the FM Demodulator in C++, for one exception: The FM demodulator uses optfir, which is implemented in Python, so it cannot be used in C++. So I replaced it with firdes (I noticed the parameter difference in transition band end and transition band width). Another thing is that the Frequency-Xlating-Filter uses a complex lowpass, but in C++ I could only find a complex band-pass, so I used a band-pass with lower frequency 0, is that the same? Also it works, the signal is a lot noisier and the result cannot be decoded in many cases. I think the reason are the different filters. Could that be the reason? As I understood, both optfir and firdes create just a bunch of numbers and that´s it. As my program is not going change the filter parameters they could be hardcoded in my program, right? Best regards Stefan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_ofdm.grc start_of_burst end_of_burst
On 07/30/2014 03:59 AM, xianda wrote: Hi all: I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.Recently I have used the UHD API to send packet.And I want to know whether the tx_ofdm.grc add start_of_burst and end_of_burst automatically.Namely,need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? usrp_sink understands tagged streams. So, the OFDM code does *not* add EOB, but that doesn't matter if you have an up-to-date gr-uhd. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What do Packet Encoder and Packet Decoder do?
Thank you Tom, I found a note in documentation of the *Packet Encoder *block where it declares that the *Packet Encoder* is for use with the gnuradio modulator blocks: GMSK, DPSK, QAM. I don't know why only these modulator blocks are supported, but not some popular things like BPSK or QPSK. Another thing is that my task requires the use of OFDM. Suppose now I have a simple flow graph as below: File Source --- Packet Encoder --- Packet Decoder - File Sink I wonder what types of file can be loaded and processed properly in the *File Source* block (text, image, or video ...), and the same question for the *File Sink* block :-) Thank you so much Van-Ly Van-Ly Nguyen, Signals and Systems of Laboratory - SSL Faculty of Electronics and Telecommunications - FET University of Engineering and Technology - UET Vietnam National University, Hanoi - VNU Tel: (+84) 978 819 406 On Wed, Jul 30, 2014 at 8:24 PM, Tom Rondeau t...@trondeau.com wrote: On Wed, Jul 30, 2014 at 4:44 AM, Nguyễn Văn Lý lynguyenvan@gmail.com wrote: Hi all, Can anyone tell me what do *Packet Encoder* and *Packet Decoder* blocks do? and it would be great if you can give me some example :-) Thanks in advance Van-Ly These are very simple example blocks to show you how to packetize data. Packet bytes go in, they get wrapped into a packet of a given payload length with a header, access code, and preamble. The header is just a 2x repetition of the payload length (16 bits for each field). Leaving the preamble and access code blank just chooses the defaults. The decoder just looks for the access code with the number of available bits wrong. When it's found, it reads the header to get the payload length, extracts the payload, and outputs the payload. Hope this helps. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What do Packet Encoder and Packet Decoder do?
On 07/30/2014 04:14 PM, Nguyễn Văn Lý wrote: Thank you Tom, I found a note in documentation of the *Packet Encoder *block** where it declares that the *Packet Encoder* is for use with the gnuradio modulator blocks: GMSK, DPSK, QAM. I don't know why only these modulator blocks are supported, but not some popular things like BPSK or QPSK. Another thing is that my task requires the use of OFDM. These should also work (they are basically subsets of QAM), but *you* have to make sure the absolute phase is correct *before* going into the packet decoder. Suppose now I have a simple flow graph as below: File Source --- Packet Encoder --- Packet Decoder - File Sink I wonder what types of file can be loaded and processed properly in the *File Source* block (text, image, or video ...), and the same question for the *File Sink* block :-) Any file. The packet blocks really don't care about the contents. M Thank you so much Van-Ly Van-Ly Nguyen, Signals and Systems of Laboratory - SSL Faculty of Electronics and Telecommunications - FET University of Engineering and Technology - UET Vietnam National University, Hanoi - VNU Tel: (+84) 978 819 406 On Wed, Jul 30, 2014 at 8:24 PM, Tom Rondeau t...@trondeau.com mailto:t...@trondeau.com wrote: On Wed, Jul 30, 2014 at 4:44 AM, Nguyễn Văn Lý lynguyenvan@gmail.com mailto:lynguyenvan@gmail.com wrote: Hi all, Can anyone tell me what do *Packet Encoder* and *Packet Decoder* blocks do? and it would be great if you can give me some example :-) Thanks in advance Van-Ly These are very simple example blocks to show you how to packetize data. Packet bytes go in, they get wrapped into a packet of a given payload length with a header, access code, and preamble. The header is just a 2x repetition of the payload length (16 bits for each field). Leaving the preamble and access code blank just chooses the defaults. The decoder just looks for the access code with the number of available bits wrong. When it's found, it reads the header to get the payload length, extracts the payload, and outputs the payload. Hope this helps. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Messages and flow-graph termination
On Wed, Jul 30, 2014 at 9:36 AM, Daniele Nicolodi dani...@grinta.net wrote: On 30/07/2014 15:27, Tom Rondeau wrote: On Wed, Jul 30, 2014 at 7:50 AM, Daniele Nicolodi dani...@grinta.net mailto:dani...@grinta.net wrote: Hello, as soon as I introduce a pair of block publishing and consuming messages, the GNURadio scheduler (version 3.7.2) does not terminate the execution of the flow-graph when the stream sources signal the end of the stream. This is also reflected in how the test case qa_python_message_passing checks for the termination of the execution. Is this by design, is it a known limitation, or is it a bug? Cheers, Daniele Yes, this is a know bug fixed in 3.7.4. See the release notes under Important Bug Fixes and Improvements: http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_7_4 Hello Tom, thanks, I missed it from the release notes. There is a known workaround to stop execution of the flow-graph? Thanks. Cheers, Daniele Sure, the patch is in current version :) It was actually somewhat complicated to fix, though, but you could potentially cherry-pick it onto your local source. Otherwise, I don't think there is a good workaround. You'd have to have some streaming components. You could try to add a streaming port into a null sink or something stupid like that... Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_ofdm.grc start_of_burst end_of_burst
Hi: Thank you so much for your kindly reply.I write c++ code use the uhd not gnuradio.So need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Thank you. Best regards, xd At 2014-07-30 10:05:47, Martin Braun martin.br...@ettus.com wrote: On 07/30/2014 03:59 AM, xianda wrote: Hi all: I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.Recently I have used the UHD API to send packet.And I want to know whether the tx_ofdm.grc add start_of_burst and end_of_burst automatically.Namely,need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? usrp_sink understands tagged streams. So, the OFDM code does *not* add EOB, but that doesn't matter if you have an up-to-date gr-uhd. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_ofdm.grc start_of_burst end_of_burst
Hi Xianda, if you don't use gnuradio, this might not be the right list for you... Anyway, I think it's possible you're confusing something. start_of_burst / end_of burst are stream tags that are GNU Radio concepts. There is not something like this without GNU Radio. UHD supports timed commands, which might be close to what you need, but I really don't understand what your question aims at. Greetings, Marcus On 30.07.2014 16:50, xianda wrote: Hi: Thank you so much for your kindly reply.I write c++ code use the uhd not gnuradio.So need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Thank you. Best regards, xd At 2014-07-30 10:05:47, Martin Braun martin.br...@ettus.com wrote: On 07/30/2014 03:59 AM, xianda wrote: Hi all: I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.Recently I have used the UHD API to send packet.And I want to know whether the tx_ofdm.grc add start_of_burst and end_of_burst automatically.Namely,need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? usrp_sink understands tagged streams. So, the OFDM code does *not* add EOB, but that doesn't matter if you have an up-to-date gr-uhd. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_ofdm.grc start_of_burst end_of_burst
Hi Marcus: Thank you so much.I just want to make some changes on the example of tx_ofdm.grc.And I use the UHD not the gnuradio.But the example is about the gnuradio.I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.And I want to know whether need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Am I right? Best regards, xd At 2014-07-30 11:39:02, Marcus Müller marcus.muel...@ettus.com wrote: Hi Xianda, if you don't use gnuradio, this might not be the right list for you... Anyway, I think it's possible you're confusing something. start_of_burst / end_of burst are stream tags that are GNU Radio concepts. There is not something like this without GNU Radio. UHD supports timed commands, which might be close to what you need, but I really don't understand what your question aims at. Greetings, Marcus On 30.07.2014 16:50, xianda wrote: Hi: Thank you so much for your kindly reply.I write c++ code use the uhd not gnuradio.So need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Thank you. Best regards, xd At 2014-07-30 10:05:47, Martin Braun martin.br...@ettus.com wrote: On 07/30/2014 03:59 AM, xianda wrote: Hi all: I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.Recently I have used the UHD API to send packet.And I want to know whether the tx_ofdm.grc add start_of_burst and end_of_burst automatically.Namely,need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? usrp_sink understands tagged streams. So, the OFDM code does *not* add EOB, but that doesn't matter if you have an up-to-date gr-uhd. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_ofdm.grc start_of_burst end_of_burst
Sorry Xianda, I'm still not understanding completely. Is this question about a) tx_ofdm.grc, or b) not about GNU Radio? Best regards, Marcus On 30.07.2014 17:51, xianda wrote: Hi Marcus: Thank you so much.I just want to make some changes on the example of tx_ofdm.grc.And I use the UHD not the gnuradio.But the example is about the gnuradio.I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.And I want to know whether need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Am I right? Best regards, xd At 2014-07-30 11:39:02, Marcus Müller marcus.muel...@ettus.com wrote: Hi Xianda, if you don't use gnuradio, this might not be the right list for you... Anyway, I think it's possible you're confusing something. start_of_burst / end_of burst are stream tags that are GNU Radio concepts. There is not something like this without GNU Radio. UHD supports timed commands, which might be close to what you need, but I really don't understand what your question aims at. Greetings, Marcus On 30.07.2014 16:50, xianda wrote: Hi: Thank you so much for your kindly reply.I write c++ code use the uhd not gnuradio.So need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Thank you. Best regards, xd At 2014-07-30 10:05:47, Martin Braun martin.br...@ettus.com wrote: On 07/30/2014 03:59 AM, xianda wrote: Hi all: I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.Recently I have used the UHD API to send packet.And I want to know whether the tx_ofdm.grc add start_of_burst and end_of_burst automatically.Namely,need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? usrp_sink understands tagged streams. So, the OFDM code does *not* add EOB, but that doesn't matter if you have an up-to-date gr-uhd. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_ofdm.grc start_of_burst end_of_burst
Hi Marcus: Thank you.I just want to know whether the example tx_ofdm.grc add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? Best regards, xd At 2014-07-31 00:03:33, Marcus Müller marcus.muel...@ettus.com wrote: Sorry Xianda, I'm still not understanding completely. Is this question about a) tx_ofdm.grc, or b) not about GNU Radio? Best regards, Marcus On 30.07.2014 17:51, xianda wrote: Hi Marcus: Thank you so much.I just want to make some changes on the example of tx_ofdm.grc.And I use the UHD not the gnuradio.But the example is about the gnuradio.I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.And I want to know whether need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Am I right? Best regards, xd At 2014-07-30 11:39:02, Marcus Müller marcus.muel...@ettus.com wrote: Hi Xianda, if you don't use gnuradio, this might not be the right list for you... Anyway, I think it's possible you're confusing something. start_of_burst / end_of burst are stream tags that are GNU Radio concepts. There is not something like this without GNU Radio. UHD supports timed commands, which might be close to what you need, but I really don't understand what your question aims at. Greetings, Marcus On 30.07.2014 16:50, xianda wrote: Hi: Thank you so much for your kindly reply.I write c++ code use the uhd not gnuradio.So need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Thank you. Best regards, xd At 2014-07-30 10:05:47, Martin Braun martin.br...@ettus.com wrote: On 07/30/2014 03:59 AM, xianda wrote: Hi all: I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.Recently I have used the UHD API to send packet.And I want to know whether the tx_ofdm.grc add start_of_burst and end_of_burst automatically.Namely,need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? usrp_sink understands tagged streams. So, the OFDM code does *not* add EOB, but that doesn't matter if you have an up-to-date gr-uhd. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_ofdm.grc start_of_burst end_of_burst
Hi Xianda, as Martin said: So, the OFDM code does *not* add EOB Greetings, Marcus On 30.07.2014 18:06, xianda wrote: Hi Marcus: Thank you.I just want to know whether the example tx_ofdm.grc add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? Best regards, xd At 2014-07-31 00:03:33, Marcus Müller marcus.muel...@ettus.com wrote: Sorry Xianda, I'm still not understanding completely. Is this question about a) tx_ofdm.grc, or b) not about GNU Radio? Best regards, Marcus On 30.07.2014 17:51, xianda wrote: Hi Marcus: Thank you so much.I just want to make some changes on the example of tx_ofdm.grc.And I use the UHD not the gnuradio.But the example is about the gnuradio.I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.And I want to know whether need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Am I right? Best regards, xd At 2014-07-30 11:39:02, Marcus Müller marcus.muel...@ettus.com wrote: Hi Xianda, if you don't use gnuradio, this might not be the right list for you... Anyway, I think it's possible you're confusing something. start_of_burst / end_of burst are stream tags that are GNU Radio concepts. There is not something like this without GNU Radio. UHD supports timed commands, which might be close to what you need, but I really don't understand what your question aims at. Greetings, Marcus On 30.07.2014 16:50, xianda wrote: Hi: Thank you so much for your kindly reply.I write c++ code use the uhd not gnuradio.So need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Thank you. Best regards, xd At 2014-07-30 10:05:47, Martin Braun martin.br...@ettus.com wrote: On 07/30/2014 03:59 AM, xianda wrote: Hi all: I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.Recently I have used the UHD API to send packet.And I want to know whether the tx_ofdm.grc add start_of_burst and end_of_burst automatically.Namely,need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? usrp_sink understands tagged streams. So, the OFDM code does *not* add EOB, but that doesn't matter if you have an up-to-date gr-uhd. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_ofdm.grc start_of_burst end_of_burst
But you don't *need* it, either. So, don't add EOB if you're using a current GNU Radio. M On 07/30/2014 06:24 PM, Marcus Müller wrote: Hi Xianda, as Martin said: So, the OFDM code does *not* add EOB Greetings, Marcus On 30.07.2014 18:06, xianda wrote: Hi Marcus: Thank you.I just want to know whether the example tx_ofdm.grc add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? Best regards, xd At 2014-07-31 00:03:33, Marcus Müller marcus.muel...@ettus.com wrote: Sorry Xianda, I'm still not understanding completely. Is this question about a) tx_ofdm.grc, or b) not about GNU Radio? Best regards, Marcus On 30.07.2014 17:51, xianda wrote: Hi Marcus: Thank you so much.I just want to make some changes on the example of tx_ofdm.grc.And I use the UHD not the gnuradio.But the example is about the gnuradio.I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.And I want to know whether need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Am I right? Best regards, xd At 2014-07-30 11:39:02, Marcus Müller marcus.muel...@ettus.com wrote: Hi Xianda, if you don't use gnuradio, this might not be the right list for you... Anyway, I think it's possible you're confusing something. start_of_burst / end_of burst are stream tags that are GNU Radio concepts. There is not something like this without GNU Radio. UHD supports timed commands, which might be close to what you need, but I really don't understand what your question aims at. Greetings, Marcus On 30.07.2014 16:50, xianda wrote: Hi: Thank you so much for your kindly reply.I write c++ code use the uhd not gnuradio.So need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet?Thank you. Best regards, xd At 2014-07-30 10:05:47, Martin Braun martin.br...@ettus.com wrote: On 07/30/2014 03:59 AM, xianda wrote: Hi all: I know a packet in the example tx_ofdm.grc include a preamble,a header,the payload and crc value.Recently I have used the UHD API to send packet.And I want to know whether the tx_ofdm.grc add start_of_burst and end_of_burst automatically.Namely,need I add start_of_burst at the beginning of every packet and add end_of_burst at the end of every packet? usrp_sink understands tagged streams. So, the OFDM code does *not* add EOB, but that doesn't matter if you have an up-to-date gr-uhd. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Filter in rational resampler
Hello, I was studying the code of the rational resampler block in gnuradio/gr-filter/pythoin/rational_resampler.py and I have a doubt about the low pass filter generated by the design_filter() function. It seems that the generated filter does not take into account the decimation factor. Is that correct? I don't see how this may result in the correct anti-aliasing filter when it is applied by rational_resampler_base_xxx. Can someone point me to a relevant explanation? Thanks a lot. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Filter in rational resampler
On 07/30/2014 12:42 PM, Daniele Nicolodi wrote: Hello, I was studying the code of the rational resampler block in gnuradio/gr-filter/pythoin/rational_resampler.py and I have a doubt about the low pass filter generated by the design_filter() function. It seems that the generated filter does not take into account the decimation factor. Is that correct? I don't see how this may result in the correct anti-aliasing filter when it is applied by rational_resampler_base_xxx. Can someone point me to a relevant explanation? Thanks a lot. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The filtering happens *before* resampling. It has to, or you end up with aliases. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re Spectrum sensing Simulation Only
Hello Martin Thank you for the help. I try to run specest_noisy_sinusoid_mtm.py (Python script is also okey for me). However it does not run it says no module specest. By the way I am using windows 8 OS. My goal is is to write a simple python or gnuradio code to perform the following task I have the following variables NFFT=1024 Nav=512 ampl=1 seed=1 Sampling_rate= 10k 1. Generate any real time signal (This could be done by using gr.noise_source_f (gr.GR_GAUSSIAN, ampl, seed1)). 2. Insert throttle to control the sampling rate (i.e., gr.throttle(1, Sampling_rate)) 3. Compute the FFT (even without windowing) (i.e., NFFT samples at a time) Let me assume that after I compute FFT and I got an x vector of size NFFT 4. Compute the square magnitude of x (This could be done by using gr.complex_to_mag_squared(NFFT)) i.e., in matlab y=abs(x).^2 4. sum the first and second Nav samples i.e., av1=sum(y(1:512))/Nav and av2=sum(y(513:1024))/Nav 5. Then display av1 and av2 in a text box continuously. Note that in matlab (without GUI it is very easy task) And I feel that there should be some simple approach to do it in GNUradio Thank you again for your help --- Tadilo Endeshaw Postdoctoral Researcher Institut National de recherche Scientifique Centre Energie Matriaux Telecommunications Place Bonaventure, 800 de la Gauchetiere Ouest, Suite 6900 H5A 1K6 Montreal, QC Canada E-mail : tadilo.bog...@emt.inrs.ca tadilo...@yahoo.com (private) Personal home page: https://sites.google.com/site/tadilomypage/ From: discuss-gnuradio-bounces+tadilo.bogale=emt.inrs...@gnu.org [discuss-gnuradio-bounces+tadilo.bogale=emt.inrs...@gnu.org] On Behalf Of Martin Braun [martin.br...@ettus.com] Sent: July 30, 2014 10:01 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Spectrum sensing Simulation Only On 07/30/2014 03:37 PM, Tom Rondeau wrote: The easiest way to average is to use the single_pole_iir_filter to smooth out the data stream. But note that you're coming out of the FFT block as a vector. You can set the vector length of the single pole IIR, but I'd have to review exactly what that means mathematically. It probably smooths the entire vector as one as opposed to smoothing over index i in each vector. You might have to play around with that. gr-specest might help you with that (pybombs install gr-specest, or https://github.com/kit-cel/gr-specest). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] increasing output power from lftx with resistor mod gives saturated output
Hello- I have attempted to increase the output power from my Rev 2.2 LFTX as per instructions from Matt Ettus on this list dated Aug 3 2013 in which he suggests reducing the values of resistors R3 and R5, but I am seeing a clipped output at peak values much less than expected. Using the ettus.com LFTX schematic as a guide, I left the resistors on the board untouched, but soldered wires to either side of R3 and R5 to add additional resistors in parallel. My first attempt was with resistors of value 220 ohms; I figured this would about halve the value at R3 and R5 which are originally 225 ohms. I do see some increase in output power, but very minimal. Specifically, whereas before I was observing 1 V P-P, or about 2.5 milli-watts on an oscilloscope that is 50-ohm DC coupled, I am now seeing 1.34 V P-P, or about 4.6 milli-watts with a 1 kHz sine-wave. To obtain this without clipping I had to reduce the amplitude on the USRP sink block from 1 to about .77, othwerwise the tops of the sinusoids flatten anywhere above the 1.34 V P-P level. So I appear to be saturated. I am using a USRP1 Rev. 3. I verified that the LFTX output op-amp in question is supplied with +/- 3.3 volts, so I don't see why it is clipping at half of this. I am hoping to use the LFTX in an HF Ham radio application. I have mini-circuits ZHL-1A TX pre-amplifier for this purpose, but was hoping to obtain a little more output from the LFTX than I am currently getting to drive the ZHL-1A. Any thoughts? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re Spectrum sensing Simulation Only
Hi Tadilo, have you made sure that specest was correctly installed? (make make install) Greetings, Marcus On 30.07.2014 20:48, Bogale, Tadilo Endeshaw wrote: Hello Martin Thank you for the help. I try to run specest_noisy_sinusoid_mtm.py (Python script is also okey for me). However it does not run it says no module specest. By the way I am using windows 8 OS. My goal is is to write a simple python or gnuradio code to perform the following task I have the following variables NFFT=1024 Nav=512 ampl=1 seed=1 Sampling_rate= 10k 1. Generate any real time signal (This could be done by using gr.noise_source_f (gr.GR_GAUSSIAN, ampl, seed1)). 2. Insert throttle to control the sampling rate (i.e., gr.throttle(1, Sampling_rate)) 3. Compute the FFT (even without windowing) (i.e., NFFT samples at a time) Let me assume that after I compute FFT and I got an x vector of size NFFT 4. Compute the square magnitude of x (This could be done by using gr.complex_to_mag_squared(NFFT)) i.e., in matlab y=abs(x).^2 4. sum the first and second Nav samples i.e., av1=sum(y(1:512))/Nav and av2=sum(y(513:1024))/Nav 5. Then display av1 and av2 in a text box continuously. Note that in matlab (without GUI it is very easy task) And I feel that there should be some simple approach to do it in GNUradio Thank you again for your help --- Tadilo Endeshaw Postdoctoral Researcher Institut National de recherche Scientifique Centre Energie Matriaux Telecommunications Place Bonaventure, 800 de la Gauchetiere Ouest, Suite 6900 H5A 1K6 Montreal, QC Canada E-mail : tadilo.bog...@emt.inrs.ca tadilo...@yahoo.com (private) Personal home page: https://sites.google.com/site/tadilomypage/ From: discuss-gnuradio-bounces+tadilo.bogale=emt.inrs...@gnu.org [discuss-gnuradio-bounces+tadilo.bogale=emt.inrs...@gnu.org] On Behalf Of Martin Braun [martin.br...@ettus.com] Sent: July 30, 2014 10:01 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Spectrum sensing Simulation Only On 07/30/2014 03:37 PM, Tom Rondeau wrote: The easiest way to average is to use the single_pole_iir_filter to smooth out the data stream. But note that you're coming out of the FFT block as a vector. You can set the vector length of the single pole IIR, but I'd have to review exactly what that means mathematically. It probably smooths the entire vector as one as opposed to smoothing over index i in each vector. You might have to play around with that. gr-specest might help you with that (pybombs install gr-specest, or https://github.com/kit-cel/gr-specest). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Spectrum sensing Simulation Only
Tadilo, please stick to the mailing list. On 07/30/2014 08:23 PM, Bogale, Tadilo Endeshaw wrote: Hello Martin Thank you for the help. I try to run specest_noisy_sinusoid_mtm.py (Python script is also okey for me). However it does not run it says no module specest. Did you install gr-specest? My goal is is to write a simple python or gnuradio code to perform the following task That's really simple. In gr-specest, the Welch blocks pretty much do that. Even without, you can easily click that together in GRC. M I have the following variables NFFT=1024 Nav=512 ampl=1 seed=1 Sampling_rate= 10k 1. Generate any real time signal (This could be done by using gr.noise_source_f (gr.GR_GAUSSIAN, ampl, seed1)). 2. Insert throttle to control the sampling rate (i.e., gr.throttle(1, Sampling_rate)) 3. Compute the FFT (even without windowing) (i.e., NFFT samples at a time) Let me assume that after I compute FFT I got x vector of size NFFT 4. Compute the square magnitude (This could be done by using gr.complex_to_mag_squared(NFFT)) i.e., in matlab y=abs(x).^2 4. sum the first and second Nav samples i.e., av1=sum(y(1:512)) and av2=sum(y(513:1024)) 5. Then display av1 and av2 in some GNUradio GUI continuosly. Note that in matlab (without GUI it is very easy task) And I feel that there should be some simple approach to do it in GNUradio Thank you again for your help --- Tadilo Endeshaw Postdoctoral Researcher Institut National de recherche Scientifique Centre Energie Matriaux Telecommunications Place Bonaventure, 800 de la Gauchetiere Ouest, Suite 6900 H5A 1K6 Montreal, QC Canada E-mail : tadilo.bog...@emt.inrs.ca tadilo...@yahoo.com (private) Personal home page: https://sites.google.com/site/tadilomypage/ From: discuss-gnuradio-bounces+tadilo.bogale=emt.inrs...@gnu.org [discuss-gnuradio-bounces+tadilo.bogale=emt.inrs...@gnu.org] On Behalf Of Martin Braun [martin.br...@ettus.com] Sent: July 30, 2014 10:01 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Spectrum sensing Simulation Only On 07/30/2014 03:37 PM, Tom Rondeau wrote: The easiest way to average is to use the single_pole_iir_filter to smooth out the data stream. But note that you're coming out of the FFT block as a vector. You can set the vector length of the single pole IIR, but I'd have to review exactly what that means mathematically. It probably smooths the entire vector as one as opposed to smoothing over index i in each vector. You might have to play around with that. gr-specest might help you with that (pybombs install gr-specest, or https://github.com/kit-cel/gr-specest). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] increasing output power from lftx with resistor mod gives saturated output
Hello- I have attempted to increase the output power from my Rev 2.2 LFTX as per instructions from Matt Ettus on this list dated Aug 3 2013 in which he suggests reducing the values of resistors R3 and R5, but I am seeing a clipped output at peak values much less than expected. Using the ettus.com LFTX schematic as a guide, I left the resistors on the board untouched, but soldered wires to either side of R3 and R5 to add additional resistors in parallel. My first attempt was with resistors of value 220 ohms; I figured this would about halve the value at R3 and R5 which are originally 225 ohms. I do see some increase in output power, but very minimal. Specifically, whereas before I was observing 1 V P-P, or about 2.5 milli-watts on an oscilloscope that is 50-ohm DC coupled, I am now seeing 1.34 V P-P, or about 4.6 milli-watts with a 1 kHz sine-wave. To obtain this without clipping I had to reduce the amplitude on the USRP sink block from 1 to about .77, othwerwise the tops of the sinusoids flatten anywhere above the 1.34 V P-P level. So I appear to be saturated. I am using a USRP1 Rev. 3. I verified that the LFTX output op-amp in question is supplied with +/- 3.3 volts, so I don't see why it is clipping at half of this. I am hoping to use the LFTX in an HF Ham radio application. I have mini-circuits ZHL-1A TX pre-amplifier for this purpose, but was hoping to obtain a little more output from the LFTX than I am currently getting to drive the ZHL-1A. Any thoughts? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] increasing output power from lftx with resistor mod gives saturated output
On 07/30/2014 04:14 PM, emat...@yahoo.com wrote: Hello- I have attempted to increase the output power from my Rev 2.2 LFTX as per instructions from Matt Ettus on this list dated Aug 3 2013 in which he suggests reducing the values of resistors R3 and R5, but I am seeing a clipped output at peak values much less than expected. Using the ettus.com LFTX schematic as a guide, I left the resistors on the board untouched, but soldered wires to either side of R3 and R5 to add additional resistors in parallel. My first attempt was with resistors of value 220 ohms; I figured this would about halve the value at R3 and R5 which are originally 225 ohms. I do see some increase in output power, but very minimal. Specifically, whereas before I was observing 1 V P-P, or about 2.5 milli-watts on an oscilloscope that is 50-ohm DC coupled, I am now seeing 1.34 V P-P, or about 4.6 milli-watts with a 1 kHz sine-wave. To obtain this without clipping I had to reduce the amplitude on the USRP sink block from 1 to about .77, othwerwise the tops of the sinusoids flatten anywhere above the 1.34 V P-P level. So I appear to be saturated. I am using a USRP1 Rev. 3. I verified that the LFTX output op-amp in question is supplied with +/- 3.3 volts, so I don't see why it is clipping at half of this. I am hoping to use the LFTX in an HF Ham radio application. I have mini-circuits ZHL-1A TX pre-amplifier for this purpose, but was hoping to obtain a little more output from the LFTX than I am currently getting to drive the ZHL-1A. Any thoughts? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I would look at the datasheet for the driver amp. But +6dBm is pretty-close to the max output of the DAC as I recall, so you might be better to just put an interstitial amplifier in place. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] increasing output power from lftx with resistor mod gives saturated output
According to the AD8047 datasheet, the output voltage range is +/- 3 volts into a 150 ohm load. That works out I believe to 30 milli-watts of output. So it should be able to sink sufficient current to do better than what I'm observing... On Wednesday, July 30, 2014 4:22 PM, Marcus D. Leech mle...@ripnet.com wrote: On 07/30/2014 04:14 PM, emat...@yahoo.com wrote: Hello- I have attempted to increase the output power from my Rev 2.2 LFTX as per instructions from Matt Ettus on this list dated Aug 3 2013 in which he suggests reducing the values of resistors R3 and R5, but I am seeing a clipped output at peak values much less than expected. Using the ettus.com LFTX schematic as a guide, I left the resistors on the board untouched, but soldered wires to either side of R3 and R5 to add additional resistors in parallel. My first attempt was with resistors of value 220 ohms; I figured this would about halve the value at R3 and R5 which are originally 225 ohms. I do see some increase in output power, but very minimal. Specifically, whereas before I was observing 1 V P-P, or about 2.5 milli-watts on an oscilloscope that is 50-ohm DC coupled, I am now seeing 1.34 V P-P, or about 4.6 milli-watts with a 1 kHz sine-wave. To obtain this without clipping I had to reduce the amplitude on the USRP sink block from 1 to about .77, othwerwise the tops of the sinusoids flatten anywhere above the 1.34 V P-P level. So I appear to be saturated. I am using a USRP1 Rev. 3. I verified that the LFTX output op-amp in question is supplied with +/- 3.3 volts, so I don't see why it is clipping at half of this. I am hoping to use the LFTX in an HF Ham radio application. I have mini-circuits ZHL-1A TX pre-amplifier for this purpose, but was hoping to obtain a little more output from the LFTX than I am currently getting to drive the ZHL-1A. Any thoughts? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I would look at the datasheet for the driver amp. But +6dBm is pretty-close to the max output of the DAC as I recall, so you might be better to just put an interstitial amplifier in place. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What do Packet Encoder and Packet Decoder do?
Hi Martin, Consider the following flow graph. File Source ---Throttle Packet Encoder --- Packet Decoder -File Sink 2 \ \--- File Sink 1 If the File Source loads a small-size image (around 50 kB), then the Packet Decoder works properly and File Sink 2 can open the image. However if the File Source load a bigger image or video (9 MB, for example), then the File Sink 2 achieve only more than 1 MB, and it can only display a part of the image/video. This surprised me. Then I added a File Sink right after the Packet Encoder (it's called File Sink 1) to see what happened after the Packet Encoder. If I let the Sample Rate = 32k, then the File Sink 1 receives more than 9 MB, but the File Sink 2 still receive more than 1 MB. If I let the Sample Rate be faster, 1M or 4M, then both the File Sink 1 and File Sink 2 only get more than 1MB. I wonder if something related to CPU got out of ability with high Sample Rate or Packet Encoder - Packet Decoder Best Regards, V-L Van-Ly Nguyen, Signals and Systems of Laboratory - SSL Faculty of Electronics and Telecommunications - FET University of Engineering and Technology - UET Vietnam National University, Hanoi - VNU Tel: (+84) 978 819 406 On Wed, Jul 30, 2014 at 9:19 PM, Martin Braun martin.br...@ettus.com wrote: On 07/30/2014 04:14 PM, Nguyễn Văn Lý wrote: Thank you Tom, I found a note in documentation of the *Packet Encoder *block** where it declares that the *Packet Encoder* is for use with the gnuradio modulator blocks: GMSK, DPSK, QAM. I don't know why only these modulator blocks are supported, but not some popular things like BPSK or QPSK. Another thing is that my task requires the use of OFDM. These should also work (they are basically subsets of QAM), but *you* have to make sure the absolute phase is correct *before* going into the packet decoder. Suppose now I have a simple flow graph as below: File Source --- Packet Encoder --- Packet Decoder - File Sink I wonder what types of file can be loaded and processed properly in the *File Source* block (text, image, or video ...), and the same question for the *File Sink* block :-) Any file. The packet blocks really don't care about the contents. M Thank you so much Van-Ly Van-Ly Nguyen, Signals and Systems of Laboratory - SSL Faculty of Electronics and Telecommunications - FET University of Engineering and Technology - UET Vietnam National University, Hanoi - VNU Tel: (+84) 978 819 406 On Wed, Jul 30, 2014 at 8:24 PM, Tom Rondeau t...@trondeau.com mailto:t...@trondeau.com wrote: On Wed, Jul 30, 2014 at 4:44 AM, Nguyễn Văn Lý lynguyenvan@gmail.com mailto:lynguyenvan@gmail.com wrote: Hi all, Can anyone tell me what do *Packet Encoder* and *Packet Decoder* blocks do? and it would be great if you can give me some example :-) Thanks in advance Van-Ly These are very simple example blocks to show you how to packetize data. Packet bytes go in, they get wrapped into a packet of a given payload length with a header, access code, and preamble. The header is just a 2x repetition of the payload length (16 bits for each field). Leaving the preamble and access code blank just chooses the defaults. The decoder just looks for the access code with the number of available bits wrong. When it's found, it reads the header to get the payload length, extracts the payload, and outputs the payload. Hope this helps. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
