Re: [Discuss-gnuradio] Creating a FFT plot like the one in this youtube variable
Hi Ashraf, If you've configured the USRP source correctly, you're very likely actually displaying the spectrum your digital receiver sees -- depending on the signal, you could a) actually be rising the power level in that whole band, or b) maybe you're observing something like saturation and hence intermodulation of additional signals. You migth want to share what exactly you are observing, and what exactly the signal is you're generating. Screenshots are easy to make and to upload [1], so please illustrate a little better! Best regards, Marcus [1] www.imgur.com On 22.07.2015 17:56, Ashraf Younis wrote: Hello, the issue I am having is I cannot display a graph that shows a wide range of frequencies and their power. When I attempt it with the QT GUI Frequency in GRC, I get something similar to the one in this video (FFT plot https://youtu.be/cygDXeZaiOM?t=3m49s) but then I transmit a signal in the range I am currently looking at and the whole line moves up. This leads me to believe that I am no displaying the whole range I desire, but in fact I am displaying the center frequency and a small bandwidth around it. I want to, for example, scan the 2.4 GHz range and see all of the channels and their power. And when I transmit at a certain frequency, I see a spike at the spot in the graph. How do I create that graph? ___ 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] Creating a FFT plot like the one in this youtube variable
Hello, the issue I am having is I cannot display a graph that shows a wide range of frequencies and their power. When I attempt it with the QT GUI Frequency in GRC, I get something similar to the one in this video (FFT plot https://youtu.be/cygDXeZaiOM?t=3m49s) but then I transmit a signal in the range I am currently looking at and the whole line moves up. This leads me to believe that I am no displaying the whole range I desire, but in fact I am displaying the center frequency and a small bandwidth around it. I want to, for example, scan the 2.4 GHz range and see all of the channels and their power. And when I transmit at a certain frequency, I see a spike at the spot in the graph. How do I create that graph? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Creating a FFT plot like the one in this youtube variable
Hi Ashraf, I don't want to complain much, but this feels like you're only giving us fractions of the information that is easily available to you, but expect us to guess what you're seeing; try to understand the situation of someone who's trying to understand your problems: now you've just sent us two uncommented screenshots, and we don't know what situation you're actually showing -- is it what you see when there's no signal? Is it what you see when there is signal? How do these spectra look in comparison? Also, you haven't explained anything about what you're transmitting, with which bandwidth, using which devices, antennas, gains/powers etc. The only thing that I can say for sure is that you're misunderstanding the bandwidth parameter of the graphical sink: Of course, the sink always displays the bandwidth of the sampled signal you send into it -- which, for complex signals, is the sampling rate, and the bandwidth parameter just puts the numbers on the axis. The actual bandwidth you're observing is 100kHz, not 2MHz! you need to modify the sampling rate if you want to change that. I remember we had a discussion on whether any GNU Radio sink actually displays powers (in dBm) or just relative values (dB); this is exactly the same! Frequency is displayed relative to the bandwidth you set in the sink parameters -- it's not a quality inherent to the sequence of numbers that is your digital signal. Best regards, Marcus On 22.07.2015 19:32, Ashraf Younis wrote: On Wed, Jul 22, 2015 at 12:01 PM, Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote: Hi Ashraf, If you've configured the USRP source correctly, you're very likely actually displaying the spectrum your digital receiver sees -- depending on the signal, you could a) actually be rising the power level in that whole band, or b) maybe you're observing something like saturation and hence intermodulation of additional signals. You migth want to share what exactly you are observing, and what exactly the signal is you're generating. Screenshots are easy to make and to upload [1], so please illustrate a little better! Best regards, Marcus [1] www.imgur.com http://www.imgur.com On 22.07.2015 17:56, Ashraf Younis wrote: Hello, the issue I am having is I cannot display a graph that shows a wide range of frequencies and their power. When I attempt it with the QT GUI Frequency in GRC, I get something similar to the one in this video (FFT plot https://youtu.be/cygDXeZaiOM?t=3m49s) but then I transmit a signal in the range I am currently looking at and the whole line moves up. This leads me to believe that I am no displaying the whole range I desire, but in fact I am displaying the center frequency and a small bandwidth around it. I want to, for example, scan the 2.4 GHz range and see all of the channels and their power. And when I transmit at a certain frequency, I see a spike at the spot in the graph. How do I create that graph? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] QT Blocks causing BER errors?
I've come across a really unexpected correlation this morning that I'm hoping someone has an explanation for. I have a large flow graph with many QT GUI blocks because I'm debugging a design. Mostly Time Sinks and Constellations plots with a couple of Frequency Sinks thrown in. The number of points in some of the time sinks is rather large, on the order of 30k, which allows me to see several packets of data at once. What I noticed this morning, while debugging a BPSK loopback BER tester, is by disabling a number of Constellation plots which were fed by RRC filters to make the plot pretty, errors went away. The system works as you would expect a simulation with no noise or channel effects to work, perfectly. When I enable those GUI blocks, the system looses packet synchronization within the first minute consistently. Nothing is changed in the data stream between these tests. So the question is, is there a known cap on GUI plots? Like I said, I have a lot of them and some of them are plotting a large number of points. Could this be causing buffers overruns into data spaces or something scary like that? Another thought I had, could there be an identity problem in which GNU Radio at some point can't uniquely identify blocks with the same name apart from each other and thus chooses one in some default manner? I'm imagining a plotting stream getting crossed with a data stream in some way. The bottom line is all I need to do to make this system work is disable some plotting only related blocks. Is there a known plotting cap issue that I should be aware of? Thanks, Rich ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Firs byte always missing on TCP BPSK encoder
It seems your per-packet payload is but 1; and it's quite probable the first packet gets lost in trying to synchronize, which would explain your loss. Best regards, Marcus On 22.07.2015 19:20, Jason Matusiak wrote: I have a BPSK modulator/demodulator simulator script (attached) that has me a little perplexed. I have a TCP source on the input and a TCP sink on the output. The Encoder is setup for a payload length of 1. Everything works except that I seems to always lose the first byte. What I do is run the script and then run: nc localhost 6 in one terminal and nc localhost 60001 in another If I type, this is a test in the first terminal (minus the quotes) and hit enter, I see his is a test in the second terminal. So it looks like things are working, but why would I be losing that first byte? It seems to happen every time I start the script fresh. ___ 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] Simple BPSK modulation with alternating 1's and 0's
FYI - copying the GNU Radio mailing list, which would be a more appropriate place to post a question such as this one. Some comments on your GNU Radio setup: * You're using a PSK Mod block, which applies a root-raised cosine pulse-shaping filter to the +1/-1 stream, so you wouldn't exactly see +1/-1 at the output, but instead the sum of symbol-period delayed filter responses. * If you look at the documentation for the PSK Mod block in GRC, it will tell you that the input expects unsigned chars, which equates to values in the range [0,256). Instead of using a vector source, use a Random Source with Minimum=0 and Maximum=256 to feed the PSK Mod block. * Your throttle block is what's setting the sample rate in this example, and the modulator is using 4 sps (samples-per-symbol), so your symbol rate is 32k/4 = 8 ksym/s. Since this is BPSK, the data rate is also 8 kbps. * If you were to use a USRP to transmit, you would set its sample rate and then change the SPS to achieve the desired symbol rate: sym_rate = usrp_samp_rate / SPS. * If you're using the QT GUI Constellation Sink, it will display all the complex points, including those interpolated by the filter in the PSK Mod block. Therefore you won't see symbol-clock sampled constellation points - you will also see intermediate points as the signal transitions between constellation points. From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of Moon, Seung - Exelis via USRP-users Sent: Wednesday, July 22, 2015 2:55 PM To: usrp-us...@lists.ettus.com Subject: [USRP-users] Simple BPSK modulation with alternating 1's and 0's Hello, I'm currently working an intern, and my teammate and I are trying to generate a simple BPSK modulated signal. We both lack knowledge on GNURadio and communications for our project, so we are hoping to get some help online. Currently, I have a repeating vector source of alternating 1 and 0 which feeds into PSK modulator block (constellation point: 2, gray code: Y, differential encoding: Y, sps: 4, excess BW: .35) which feeds into a throttle block (sample rate: 32k) which then feeds into a GUI sink. On the GUI constellation diagram, we see some points that are not situated at +1 and -1. We are not sure on how to interpret what we are seeing on the constellation diagram. From my understanding, BPSK modulation modulates our data to +1 and -1. Ultimately, we will be using USRP B200 to transmit our signal to lock on to a receiver which expects a BPSK modulated signal at certain data rate (let's say 1kbps). We are also unsure on how to transmit our data at the desired data rate. Any guidance will be greatly appreciated. Thank you for your interest. Have a wonderful day. This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Creating a FFT plot like the one in this youtube variable
Thank you for replying. I included some screenshots of the program. One is of the block diagram and the other is of the graph itself. I am generating a signal using a different device and program. having only one B200 has prompted me to use this method. I am using a NI USRP-2920 with lab view to generate a signal On Wed, Jul 22, 2015 at 12:01 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Ashraf, If you've configured the USRP source correctly, you're very likely actually displaying the spectrum your digital receiver sees -- depending on the signal, you could a) actually be rising the power level in that whole band, or b) maybe you're observing something like saturation and hence intermodulation of additional signals. You migth want to share what exactly you are observing, and what exactly the signal is you're generating. Screenshots are easy to make and to upload [1], so please illustrate a little better! Best regards, Marcus [1] www.imgur.com On 22.07.2015 17:56, Ashraf Younis wrote: Hello, the issue I am having is I cannot display a graph that shows a wide range of frequencies and their power. When I attempt it with the QT GUI Frequency in GRC, I get something similar to the one in this video (FFT plot https://youtu.be/cygDXeZaiOM?t=3m49s) but then I transmit a signal in the range I am currently looking at and the whole line moves up. This leads me to believe that I am no displaying the whole range I desire, but in fact I am displaying the center frequency and a small bandwidth around it. I want to, for example, scan the 2.4 GHz range and see all of the channels and their power. And when I transmit at a certain frequency, I see a spike at the spot in the graph. How do I create that graph? ___ Discuss-gnuradio mailing listDiscuss-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
Re: [Discuss-gnuradio] Firs byte always missing on TCP BPSK encoder
It's been my experience that the packet decoder block always loses 1 payload length. Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) On Wed, Jul 22, 2015 at 12:23 PM, Marcus Müller marcus.muel...@ettus.com wrote: It seems your per-packet payload is but 1; and it's quite probable the first packet gets lost in trying to synchronize, which would explain your loss. Best regards, Marcus On 22.07.2015 19:20, Jason Matusiak wrote: I have a BPSK modulator/demodulator simulator script (attached) that has me a little perplexed. I have a TCP source on the input and a TCP sink on the output. The Encoder is setup for a payload length of 1. Everything works except that I seems to always lose the first byte. What I do is run the script and then run: nc localhost 6 in one terminal and nc localhost 60001 in another If I type, this is a test in the first terminal (minus the quotes) and hit enter, I see his is a test in the second terminal. So it looks like things are working, but why would I be losing that first byte? It seems to happen every time I start the script fresh. ___ Discuss-gnuradio mailing listDiscuss-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
Re: [Discuss-gnuradio] Firs byte always missing on TCP BPSK encoder
OK, I think I figured it out. If I change the mod/demod type from DQPSK to DBPSK I get all of the packet. All seems to be roses now. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multiple sources synchronization ?
Hi Jean-Michel! There's nothing in your system that would make both RTL dongles and the soundcard start sampling at the same time, so naturally there's a large time offset between these. You will need to time align these signals first, before you can use the sound card signal to determine in which state (reference or unknown signal) your switch is; this is at least as hard as the problem of aligning the RTL dongles themselves. To be honest, I'd rather write an estimator that tells me, only from the signal, whether each RTL dongle is observing the reference or the signal. How do you frequency-synchronize both dongles? Have you modified them to use a common oscillator, or do you also plan to do that based on the observation of the 50MHz tone? Best regards, Marcus On 22.07.2015 09:51, jean-michel.fri...@femto-st.fr wrote: Possibly a stupid question, but might help me better understand how the gnuradio scheduler works: my objective is to make a low cost phase-referenced radiofrequency interferometer using two DVB-T dongles. Since I have observed that the PLL inside each dongle induces slow phase drift, I want to use an external RF switch to monitor a known (50 MHz) reference oscillator feeding both dongles, and then monitor the unknown signal. Current switching rate is about 50 Hz triggered by an external generator (which also synchronizes other events of the experiment, not relevant to this post). My idea for synchronizing the post-processing of phase extraction was to record on the one hand the two DVB-T dongle data flow (this I know works), and on the other hand the sound card microphone connected to the switch trigger signal. This process is summarized in the grc flowchart at http://jmfriedt.sequanux.org/damien_grc.png However, the sound card output shows a result completely out of sync with the phase measurements. I understand that the sound card and DVB-T dongles do not share the same clock sources, but considering the huge decimation factor (48*32 kHz for the DVB-T, 48 kHz for the sound card, and a phase output recorded at about 0.5 to 5 kHz, not shown on this grc chart), I would have expected the trigger signal to be more or less synchronized with the DVB-T outputs, which is not at all the case. Is the gnuradio scheduler unable to interleave two data sources as different as a sound card and the USB data flow from the two DVB-T dongles ? Is there a way I might tune my flowchart to achieve the expected result ? Thanks, JM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] isolate channels from wideband
On 21/07/15 21:39, Tom Rondeau wrote: Here's my presentation from last GRCon: http://gnuradio.squarespace.com/grcon14-presentations#tut-rondeau Hello Tom, browsing through your presentation I see that on page 58 and 59 you recommend to use firdes filter design tool and not optfir to build re reconstruction filter. However, I don't quite understand why the filter generated by one tool is better than the other is this case. Can you please comment on it? Thanks! Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multiple sources synchronization ?
There's nothing in your system that would make both RTL dongles and the soundcard start sampling at the same time, so naturally there's a large time offset between these. You will need to time align these signals first, before you can use the sound card signal to determine in which state (reference or unknown signal) your switch is; this is at least as hard as the problem of aligning the RTL dongles themselves. To be honest, I'd rather write an estimator that tells me, only from the signal, whether each RTL dongle is observing the reference or the signal. right, this is what I ended up doing yesterday: since the reference and measured signals exhibit different power, I am recording the phase difference as well as the magnitude from the dongle connected to the switch, and use the magnitude information to differentiate the two states of the switch. How do you frequency-synchronize both dongles? Have you modified them to use a common oscillator, or do you also plan to do that based on the observation of the 50MHz tone? Yes I removed the quartz from one dongle and am using the 28 MHz output from the other dongle to clock the former. I believe that the slow phase slip is not important for passive radar applications since the cross-correlation reinitializes the phase, but for my interferometric measurement I need the long term phase drift information. Thanks for the answer, JM Best regards, Marcus On 22.07.2015 09:51, jean-michel.fri...@femto-st.fr wrote: Possibly a stupid question, but might help me better understand how the gnuradio scheduler works: my objective is to make a low cost phase-referenced radiofrequency interferometer using two DVB-T dongles. Since I have observed that the PLL inside each dongle induces slow phase drift, I want to use an external RF switch to monitor a known (50 MHz) reference oscillator feeding both dongles, and then monitor the unknown signal. Current switching rate is about 50 Hz triggered by an external generator (which also synchronizes other events of the experiment, not relevant to this post). My idea for synchronizing the post-processing of phase extraction was to record on the one hand the two DVB-T dongle data flow (this I know works), and on the other hand the sound card microphone connected to the switch trigger signal. This process is summarized in the grc flowchart at http://jmfriedt.sequanux.org/damien_grc.png However, the sound card output shows a result completely out of sync with the phase measurements. I understand that the sound card and DVB-T dongles do not share the same clock sources, but considering the huge decimation factor (48*32 kHz for the DVB-T, 48 kHz for the sound card, and a phase output recorded at about 0.5 to 5 kHz, not shown on this grc chart), I would have expected the trigger signal to be more or less synchronized with the DVB-T outputs, which is not at all the case. Is the gnuradio scheduler unable to interleave two data sources as different as a sound card and the USB data flow from the two DVB-T dongles ? Is there a way I might tune my flowchart to achieve the expected result ? Thanks, JM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- JM Friedt, FEMTO-ST Time Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multiple sources synchronization ?
Possibly a stupid question, but might help me better understand how the gnuradio scheduler works: my objective is to make a low cost phase-referenced radiofrequency interferometer using two DVB-T dongles. Since I have observed that the PLL inside each dongle induces slow phase drift, I want to use an external RF switch to monitor a known (50 MHz) reference oscillator feeding both dongles, and then monitor the unknown signal. Current switching rate is about 50 Hz triggered by an external generator (which also synchronizes other events of the experiment, not relevant to this post). My idea for synchronizing the post-processing of phase extraction was to record on the one hand the two DVB-T dongle data flow (this I know works), and on the other hand the sound card microphone connected to the switch trigger signal. This process is summarized in the grc flowchart at http://jmfriedt.sequanux.org/damien_grc.png However, the sound card output shows a result completely out of sync with the phase measurements. I understand that the sound card and DVB-T dongles do not share the same clock sources, but considering the huge decimation factor (48*32 kHz for the DVB-T, 48 kHz for the sound card, and a phase output recorded at about 0.5 to 5 kHz, not shown on this grc chart), I would have expected the trigger signal to be more or less synchronized with the DVB-T outputs, which is not at all the case. Is the gnuradio scheduler unable to interleave two data sources as different as a sound card and the USB data flow from the two DVB-T dongles ? Is there a way I might tune my flowchart to achieve the expected result ? Thanks, JM -- JM Friedt, FEMTO-ST Time Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Synchronous MIMO TX on X310
Hello, I am trying to implement a MIMO burstytransmission on USRP X310 with 2 CBX daughterboards using GNU Radio.In order to make both antennas to start transmission synchronously Iset up the time spec in the USRP Sink code usrp_sink_impl.cc: _metadata.time_spec = get_time_now() +::uhd::time_spec_t(epsilon); where epsilon is 1ms fixed delay. Thisfixed delay is a problem, because of the GNU Radio time jitter, i.e.in one case epsilon is too small and the burst is late (), inanother case epsilon is too large and the USRP just wastes time forwaiting. I want to minimize the waiting time,and make the USRP to start transmission simultaneously as soon as the TX chains ofboth antennas have some data to transmit. One option is makingchanges in the X310 FPGA image. My question however is, can Iminimize the waiting time just by changing the GNU Radio code orsettings? Thank you in advance, Dmitry.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] isolate channels from wideband
On Wed, Jul 22, 2015 at 4:57 AM, Daniele Nicolodi dani...@grinta.net wrote: On 21/07/15 21:39, Tom Rondeau wrote: Here's my presentation from last GRCon: http://gnuradio.squarespace.com/grcon14-presentations#tut-rondeau Hello Tom, browsing through your presentation I see that on page 58 and 59 you recommend to use firdes filter design tool and not optfir to build re reconstruction filter. However, I don't quite understand why the filter generated by one tool is better than the other is this case. Can you please comment on it? Thanks! Cheers, Daniele The shape of this filter matters greatly. The inband, transition, and stop band behavior all determine if the filter can be used for the reconstruction purposes. The image on slide 59 shows the specific transition between the pass band and stop bands. To match that with the PM (i.e., Remez) algorithm, you can't get the same stop band performance for that given transition. Plus the equal response in the stop band is bad when channelizing because all channels will alias at equal powers, whereas the roll off in frequency with the windowed (firdes) filter continues to decrease with f. Remez also produces a pass band ripple, which will also affect things. The ripple with the firdes is not equiripple like Remez promises, but it's much, much smaller. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] isolate channels from wideband
Based on the plot of resulting figures the firdes designed filter has more out of band rejection. It's a trade-off between number of taps and rejection. We're good enough (computationally) at doing fir filters that 20 extra taps 25dB of attenuation is worth it. -Nathan On Wed, Jul 22, 2015 at 4:57 AM, Daniele Nicolodi dani...@grinta.net wrote: On 21/07/15 21:39, Tom Rondeau wrote: Here's my presentation from last GRCon: http://gnuradio.squarespace.com/grcon14-presentations#tut-rondeau Hello Tom, browsing through your presentation I see that on page 58 and 59 you recommend to use firdes filter design tool and not optfir to build re reconstruction filter. However, I don't quite understand why the filter generated by one tool is better than the other is this case. Can you please comment on it? Thanks! Cheers, Daniele ___ 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] ham2mon GR based scanner
Throught I'd share my GR based scanner with curses GUI. Locks on and demodulates N number of NBFM channels and logs audio to disk. Uses gr-osmosdr source so should work with a variety of devices. https://github.com/madengr/ham2mon https://www.youtube.com/watch?v=BXptQFSV8E4 -- View this message in context: http://gnuradio.4.n7.nabble.com/ham2mon-GR-based-scanner-tp54975.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unique-connection check inappropriately griping when using bus connections
I'm getting gripes from GRC when using bus connections:
ookupError: This connection between source and sink is not unique.
Error: Connection between pfb_channelizer_ccf_0_0(8) and
blocks_streams_to_vector_0_0(8) could not be made.
This connection between source and sink is not unique.
Traceback (most recent call last):
File
/usr/local/lib64/python2.7/site-packages/gnuradio/grc/base/FlowGraph.py,
line 377, in import_data
self.connect(source, sink)
File
/usr/local/lib64/python2.7/site-packages/gnuradio/grc/base/FlowGraph.py,
line 241, in connect
connection = self.get_parent().Connection(flow_graph=self,
porta=porta, portb=portb)
File
/usr/local/lib64/python2.7/site-packages/gnuradio/grc/python/Connection.py,
line 27, in __init__
_Connection.__init__(self, **kwargs)
File
/usr/local/lib64/python2.7/site-packages/gnuradio/grc/base/Connection.py,
line 54, in __init__
raise LookupError('This connection between source and sink is not
unique.')
LookupError: This connection between source and sink is not unique.
Error: Connection between pfb_channelizer_ccf_0_0(9) and
blocks_streams_to_vector_0_0(9) could not be made.
This connection between source and sink is not unique.
Traceback (most recent call last):
File
/usr/local/lib64/python2.7/site-packages/gnuradio/grc/base/FlowGraph.py,
line 377, in import_data
self.connect(source, sink)
File
/usr/local/lib64/python2.7/site-packages/gnuradio/grc/base/FlowGraph.py,
line 241, in connect
connection = self.get_parent().Connection(flow_graph=self,
porta=porta, portb=portb)
File
/usr/local/lib64/python2.7/site-packages/gnuradio/grc/python/Connection.py,
line 27, in __init__
_Connection.__init__(self, **kwargs)
File
/usr/local/lib64/python2.7/site-packages/gnuradio/grc/base/Connection.py,
line 54, in __init__
raise LookupError('This connection between source and sink is not
unique.')
LookupError: This connection between source and sink is not unique.
For flow-graphs with bus connections that previously worked just fine.
This is with v3.7.7.1-204-g55d8f482
It seems to proceed OK, and even generate reasonable-looking code.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Creating a FFT plot like the one in this youtube variable
Hi Ashraf, I don't know what frequency f_squarewave your square wave has, but rectangular signals have sinc-shaped envelope, with peaks every f_squarewave. Having a sinc envelope especially means it exists over the whole nyquist band -- so that explains why you see your complete spectrum rise! I think what you should do is have a look at the spectrum of your /transmit/ signal. This will make it easier to understand what you see at the receiver. Try this: http://i.imgur.com/EARpJLx.png flowgraph with squarewave of f_sample/32 http://imgur.com/EARpJLx so, a squarewave with frequency of f_sample/32 (remember, there's no real frequencies in DSP -- this really just tells GNU Radio that a period is 32 samples long). Important: the QT sink is set to have an FFT length of 1024 points. You should see this: http://i.imgur.com/33xrCl6.png Now, if you have a look at this spectrum, you'll notice deep wells between the peaks, which aren't there in the receive PSD, right? There's a simple reason for that: In the simulation / the TX spectrum, your f_squarewave is probably an integer factor of f_sample. This means that the period is a whole number of samples, and that whole number of samples also happens to be an integer factor of your FFT length! Therefore, your signal is perfectly periodic (as far as the observer can tell), and hence, has line spectrum characteristics. Now, we'll play around with the frequency of the square wave: http://imgur.com/Kduv5fL set it to f_sample/32/2**0.5 ; the root of 2 is not a rational number, so no FFT window in this world could transform this without leakage. So you get this: http://imgur.com/1Fkl8f8 Looking familiar? Now, these are extremes. But the problem here is that frequency synchronization between your N210 and B200 will not be perfect -- hence, on the receiver side, the signal period might not be as exactly the integer factor that you have on the TX side, and you see the inter-peak leakage. I hope that has explained the most of this phenomenom. Best regards, Marcus On 22.07.2015 20:40, Ashraf Younis wrote: -- Forwarded message -- From: *Ashraf Younis* shraff...@gmail.com mailto:shraff...@gmail.com Date: Wed, Jul 22, 2015 at 2:39 PM Subject: Re: [Discuss-gnuradio] Creating a FFT plot like the one in this youtube variable To: Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com I apologize for the way it seems I'm relaying information. I will attempt to give you all new information with your perspective in mind. I have two screenshots now, they have a fixed y-axis from 0 to -100 dB. The first is the graph that is displayed when there is no signal transmitted and the second is when there is one being transmitted. From the screenshots it is evident that the signal raises all of the graph's values, instead of where the signal is being transmitted. The receiving gain is set to 1. I deleted the bandwidth QT GUI Entry since my I did not know what it was doing. The receiver is is a USRP B200 The signal I am transmitting on the USRP 2921 is a simply square wave. the IQ rate is 100k, the antenna is a vert 2450 dual-band, it is set to 10 gain. It was transmitting in the same channel the B200 is receiving. I just want to make sure we're headed in the right direction. I want to use a wide band spectrum sense graph On Wed, Jul 22, 2015 at 1:55 PM, Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote: sure :) On 22.07.2015 19:45, Ashraf Younis wrote: Excuse me, it was my mistake. I sent it as an attachment, is that okay? On Wed, Jul 22, 2015 at 1:29 PM, Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote: Hi Ashraf, your mail is only 8.5kB large -- did you possibly forgot to include links to the images? Best regards, Marcus On 22.07.2015 19:28, Ashraf Younis wrote: Thank you for replying. I included some screenshots of the program. One is of the block diagram and the other is of the graph itself. I am generating a signal using a different device and program. having only one B200 has prompted me to use this method. I am using a NI USRP-2920 with lab view to generate a signal On Wed, Jul 22, 2015 at 12:01 PM, Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote: Hi Ashraf, If you've configured the USRP source correctly, you're very likely actually displaying the spectrum your digital receiver sees -- depending on the signal, you could a) actually be rising the power level in that whole band, or b) maybe you're observing something like saturation and hence intermodulation of additional signals. You migth want to share what exactly you are observing, and what
[Discuss-gnuradio] gnuradio and android
Hi! I watched the development of gnuradio for android. But I'm not very familiar with java, so I searched for a way to run gnuradio python scripts without or with little modifications on android. I detected the python_for_android project and wrote some recipes to run gnuradio on android. For those who are interested , see: https://github.com/dl1ksv/python-for-android At the moment I'm able to run things like dial_tone or an fm receiver using the rtl dongle. But there are a lot of things missing, in particular a gui, support of fcd(pro+), etc. So my question: Where to go from here: Introducing kivy to gnuradio for building gui's , or migrating qt5 ( a way I'd prefer ) Or is this only a nice finger exercise and of no special interest ? Comments are welcome -- Volker ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio and android
I complied the latest code on a Raspberry Pi 2 and the standalone applications seem to work but I ran into strange behavior when I ran gnuradio-companion. I could not get common data types to work between processes. That is, I could not resolve type conflicts between ins and outs. Any hints on what might be wrong and how to fix it? Thanks, Alan Hill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio and android
For which blocks did that happen? Also, you say raspberry Pi2, are you running android on that? Greetings, Marcus On 22.07.2015 23:37, Silverfox wrote: I complied the latest code on a Raspberry Pi 2 and the standalone applications seem to work but I ran into strange behavior when I ran gnuradio-companion. I could not get common data types to work between processes. That is, I could not resolve type conflicts between ins and outs. Any hints on what might be wrong and how to fix it? Thanks, Alan Hill ___ 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] OFDM example from gr-digital with UHD
Thanks again Marcus. Now I am using the Head block... I don't know which number I have to put in Num Items to get out my file with no repeated information. I can understand this number to a Sin/Cosine function or a random source that I can limit how many samples I want ... but for a file I don't know and how calculate this number. Can you help me with this? My size's file: 120 bytes ; packet length: 96 Thanks so much Cheers, José On 16.07.2015 18:52, Marcus Müller-3 wrote: As I mentioned, use the head block. BR, Marcus -- View this message in context: http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54974.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about phase sync MIMO X310
Hi Sanjoy, On 22.07.2015 16:09, Sanjoy Basak wrote: I exchanged set_command_time with set_start_time to check you need both -- set_start_time to align the sampling start, ie. the point in time the ADC takes the first measurement, and set_command_time() followed by set_center_freq() to make both daughterboards tune exactly at the same time, allowing for static phase offset. Note that I write static phase offset: This means that after tuning each oscillator will have the same phase like the last time that exact oscillator was tuned, but due to manufacturing tolerances as well as your RF set up, the phase with which your radio signal will be transmitted or received will still have an offset -- but it's going to be the same. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multiple sources synchronization ?
The use the signal itself method is something that I've used in the past for Dicke-switched type systems. The idea was originally described by Ken Tapping of the DRAO observatory. The gr-ra_blocks OOT module that I designed includes an Oblivious Slicer block that will produce a difference value based on a block of samples, using oblivious slicing. https://github.com/patchvonbraun/gr-ra_blocks The technique works well for well-differentiated signals (large difference between reference and sky), but not otherwise. On 2015-07-22 04:01, Marcus Müller wrote: Hi Jean-Michel! There's nothing in your system that would make both RTL dongles and the soundcard start sampling at the same time, so naturally there's a large time offset between these. You will need to time align these signals first, before you can use the sound card signal to determine in which state (reference or unknown signal) your switch is; this is at least as hard as the problem of aligning the RTL dongles themselves. To be honest, I'd rather write an estimator that tells me, only from the signal, whether each RTL dongle is observing the reference or the signal. How do you frequency-synchronize both dongles? Have you modified them to use a common oscillator, or do you also plan to do that based on the observation of the 50MHz tone? Best regards, Marcus On 22.07.2015 09:51, jean-michel.fri...@femto-st.fr wrote: Possibly a stupid question, but might help me better understand how the gnuradio scheduler works: my objective is to make a low cost phase-referenced radiofrequency interferometer using two DVB-T dongles. Since I have observed that the PLL inside each dongle induces slow phase drift, I want to use an external RF switch to monitor a known (50 MHz) reference oscillator feeding both dongles, and then monitor the unknown signal. Current switching rate is about 50 Hz triggered by an external generator (which also synchronizes other events of the experiment, not relevant to this post). My idea for synchronizing the post-processing of phase extraction was to record on the one hand the two DVB-T dongle data flow (this I know works), and on the other hand the sound card microphone connected to the switch trigger signal. This process is summarized in the grc flowchart at http://jmfriedt.sequanux.org/damien_grc.png [1] However, the sound card output shows a result completely out of sync with the phase measurements. I understand that the sound card and DVB-T dongles do not share the same clock sources, but considering the huge decimation factor (48*32 kHz for the DVB-T, 48 kHz for the sound card, and a phase output recorded at about 0.5 to 5 kHz, not shown on this grc chart), I would have expected the trigger signal to be more or less synchronized with the DVB-T outputs, which is not at all the case. Is the gnuradio scheduler unable to interleave two data sources as different as a sound card and the USB data flow from the two DVB-T dongles ? Is there a way I might tune my flowchart to achieve the expected result ? Thanks, JM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2] Links: -- [1] http://jmfriedt.sequanux.org/damien_grc.png [2] 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] about phase sync MIMO X310
Hi Marcus, Thank you very much for pointing out the errors. I removed the set_time_next_pps from my code. I can do time sync without this. So I am fine with it. However, I am not getting time sync with set_command_time(). I am not really sure why but this is not giving me time sync. When I check the receive file in Matlab, I see around 35000 zeros at the beginning of my first OFDM symbol for 2MSPS and this number varies with every initiation. The reason could be my set_command_time is controlling the transmitter to send signal at the specified time. But the receiver is not waiting, its getting started at the beginning. This is my code. time.sleep(1) cmd_time =self.usrp_source0.get_time_last_pps() cmd_time0 = self.usrp_sink0.get_time_last_pps() real_seconds = uhd.time_spec_t.get_real_secs(cmd_time) real_seconds0 = uhd.time_spec_t.get_real_secs(cmd_time0) print real_seconds print real_seconds0 future_real_seconds = real_seconds + 1 future_real_seconds0 = real_seconds0 + 1 print future_real_seconds print future_real_seconds0 future_cmd_time = uhd.time_spec_t(future_real_seconds) future_cmd_time0 = uhd.time_spec_t(future_real_seconds0) self.usrp_source0.set_command_time(future_cmd_time) self.usrp_source0.set_center_freq(uhd.tune_request(f,0), 0) self.usrp_source0.set_center_freq(uhd.tune_request(f,0), 1) self.usrp_sink0.set_command_time(future_cmd_time0) self.usrp_sink0.set_center_freq(uhd.tune_request(f,0), 0) self.usrp_sink0.set_center_freq(uhd.tune_request(f,0), 1) self.usrp_source0.clear_command_time() self.usrp_sink0.clear_command_time() I exchanged set_command_time with set_start_time to check, set_start_time is giving time sync as before, a constant sample shift for every initiation, but no phase sync. For one X310, I tried this now = usrp_source0.get_time_now() starttime = now + uhd.time_spec(0.1) usrp_source0.set_command_time(starttime) usrp_sink0.set_command_time(starttime) self.usrp_source0.set_center_freq(uhd.tune_request(f,0), 0) self.usrp_source0.set_center_freq(uhd.tune_request(f,0), 1) self.usrp_sink0.set_center_freq(uhd.tune_request(f,0), 0) self.usrp_sink0.set_center_freq(uhd.tune_request(f,0), 1) self.usrp_source0.clear_command_time() self.usrp_sink0.clear_command_time() result: no time sync. Am I making any mistake again or what exactly is going wrong? Please let me know. Phase sync about SBX is not written specifically in the Device synchronization site, whereas about UBX, it is written that the phase sync works perfectly *X300/X310, phase sync with UBX fully works*. Can I expect similar behavior with *SBX-120*? *The phase offset drifts+periodic calibration necessary? * If I just need to take a measurement for 5 minutes (say for example), Do I need calibration in between 5 minutes? All I need is to have a zero phase difference between 2 (or more) RX OFDM symbols over the receive frames. Please let me know. Best regards Sanjoy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
