Re: [Discuss-gnuradio] Time
On 01/10/2014 06:19 PM, Paul B. Huter wrote: I am looking for a block that will give me a time while I am playing back my data in GNURadio Companion. By this, I mean something that will pop up when I start my flow and show me the time since the flow was started. I do not care if it does not stop, I just want to be able to have a reference point for how long my FFT Sink has been playing. Is there such a thing? I have looked through all of the blocks in GRC, and I am probably just missing it or not recognizing it. Thank you. Paul B. Huter ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio That doesn't really belong as a signal-processing block. Consider probes/function-probes in GRC, and the ability to call imported Python code. -- 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] PSK Real Time Voice Tx/Rx
On 01/13/2014 04:38 PM, Marqo Torres wrote:
Hi, thanks for replying. I'm using 16kHz in Audio sample-rate and
256kHz in USRP sink/source blocks.
Also I've noticed that when I change the config.d values in the files
from the gnuradio folder there's a variation in the breaking up voice
in the receiver's side.
In the transmitter's side I get U constantly and in the
receiver's side i get UaUaUaUa I know that it means Underrun and
Audio Underrun, but I still don't have any idea of what I'm doing wrong.
I've attached the flowgraphs of the Tx and Rx models.
Regards
Marqo.
Those U mean that your graph isn't able to to keep up with the
notional sample-rate, either because of computational sluggishness, or
because you aren't resampling appropriately within your flow-graph so
that the hardware is receiving samples at the correct rate.
2014/1/13 Marcus Leech mle...@ripnet.com mailto:mle...@ripnet.com
Indeed, don't use a throttle block for anything other than a
simulation not involving hardware.
What sample-rate are you using, and are you getting overrun or
underrun indications ('O' or 'U' printed).
on Jan 13, 2014, *Marqo Torres* marqotor...@gmail.com
mailto:marqotor...@gmail.com wrote:
Hello, I am working on a real time voice Tx/Rx using GNU Radio
as software and a USRP E110. I'm trying to do a QPSK
Modulation and I have consulted several models and forums and
it seems everything is okay, however at the moment of
receiving signal, the audio on the receiver is breaking up,
and I want the audio sounds good. I thought it might be
because of some errors in synchronism and carrier recovery, so
I added the block MPSK Reciever, without any changes in the
audio output. Is anything I am missing? or Is any calculation
or number wrong?
Could it be because of lack in processing? because I've tried
the same model with GMSK mod/demod blocks and the voice sounds
good. I've attached the flowgraphs of the Tx and Rx side for a
better understanding.
I really appreciate your help and I look forward your reply.
Regards.
Marqo
P.S. I've also read that at the moment of involving blocks
that work with hardware (USRP Sink/Source) I have to skip the
Throttle blocks, is that true?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
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] [USRP-users] B200 gain control and RF input power
On 01/18/2014 12:31 AM, Luke Hough wrote: Get your tomatoes ready, I have attached a proposed block diagram and possible component specs. I have not actually purchased the limiter or the circulator, but I do have the power amp and antenna. The power amp is a ZVE-8G http://www.minicircuits.com/pdfs/ZVE-8G+.pdf. I was looking at the VLM-63-2W http://www.minicircuits.com/pdfs/VLM-63-2W+.pdf limiter and possibly a JCC3300T3800S10 circulator ( hoping for a sample ). The numbers on the block diagram don't exactly match the specs shown. The numbers are closer to the table values. I have also not taken insertion losses into account. Looking at the the B200 schematic http://files.ettus.com/schematics/b200/b200.pdf, I was wondering if during transmit I might set switch U807 to OUT2 while U805 is OUT1. Then on receive switch U807 back to OUT1. Basically, during transmit both RX1 and TX1 are set to use the TXRX1 antenna, but during receive, RX1 is switched back to antenna RX1. Can the switch be made in less than 1µs ? I don't think the switch can be made in under 1us from the host. With suitable mucking-about on the FPGA you might be able to come up with a suitable scheme that amounts to half-duplex switching. In the ordinary scheme of things the ATR state machine will switch the RX chain to the RX2 port during transmit. If this could be done fast enough, that would work fine, and you'd just put a terminator on the RX2 port in half-duplex mode. You could consider a scheme where some external machinery is helping with switching and scheduling things. Such machinery would perhaps arrange for a high-isolation path for RX during your TX cycle. This kind of problem is pretty standard in radar designs, so there are probably good solutions out there that could be hybridized to interface to an SDR approach. But radar isn't my particular expertise. On Fri, Jan 17, 2014 at 8:45 AM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 01/17/2014 09:37 AM, Luke Hough wrote: As a hobby project, I am developing an active radar. I am primarily familiar with simulation and signal processing, but not so much with RF hardware. So this is a learning opportunity. I do need to Tx/Rx on the same frequency either through a shared antenna or independent. I have constructed an antenna and measured the S11 parameter to be -11dB over a 300MHz band around the resonnant frequency. I was hoping to avoid a GPIO controlled switch. I don't think the B200 has any GPIO capability, so another controller device would be required. Would it be possible to control one of the skyworks switches on the frontend of the B200 in combination with a circulator and a limiter? Basically open the RX1 channel and keep the TXRX1 channel switched to the TX chain. -Luke Well, if this is a half-duplex application, the USRP already does switching. Whenever the unit is transmitting, the RX is connected to the the RX port on the box. Why don't you draw a diagram of what your intended setup is, and we can through metaphoric tomatoes at it, as it were. On Fri, Jan 17, 2014 at 1:34 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx mailto:ra...@schmid.xxx wrote: Hi, +7dBm is *very* risky. Hmmm...3µs are not very long...but it is a risk, agreed. If you're feeding a common antenna, the usual approach is to use a diplexer/duplexer arrangement to isolate the TX frequency from the RX frequency (assuming different-frequency full-duplex). I guess he uses the same frequency for TX and RX - usage of an isolator/circulator makes me think so :) But this only works for a certain degree and requires no reflected power at all (that means, perfect impedance match) at the antenna port. Depending on the needed timing it may be an option constructing a PIN diode RX/TX switch, operated from some GPIO. In fixed-purpose applications, like WiFi, where a common antenna is used, there's a duplexor, usually implemented in some kind of ceramic resonator technology that has bandpass and band-stop components to it, to keep the RX isolated very deeply. This will not work for WiFi, as this transmits and receives on the same frequency, they usually apply the above mentioned diode method to rapidly switch between RX and TX path. Those ceramic diplexers are common for cellphones and some digital LMR systems, as they have the need for full duplex on different frequencies. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Ralph. -- Ralph A. Schmid
Re: [Discuss-gnuradio] Finding a particular version
On 01/18/2014 01:49 AM, Nikos Balkanas wrote: Sorry, can't do. As i mentioned before, it is not my code to port :-(. Subversion is still around and good. I have downloaded the first revision from 2006. However, I can't tell which version is and it has a bug, so it cannot build. Thanx for all your help, i still hope that someone will remember smt to help me find it. It is really unfortunate that you don't keep versions in your sources, like most opensource does. In the future a new versioning system will come out, and you will have the same exact problem with git. :-( So, just to clarify. The code in question is closed-source, and you can't get the source code to modify it? If it's directly linked with Gnu Radio libraries, that's a bit of a legal problem... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Finding a particular version
On 01/18/2014 11:42 AM, Nikos Balkanas wrote: The revisions that I was interested, don't use cmake. :-( I think the point that Tom is making is that the project *HAS* been using adequate version number practice *for several years*, so criticism of versioning practice that is at this point 8 years old is kinda pointless. -- 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] wxWidgets
On 01/18/2014 10:09 PM, Activecat wrote: Dear Sir, I am learning wxWidgets in order to use it with gnuradio. I find that WX GUI FFT Sink and WX GUI Scope Sink are programmed in python, not C++. Is this true? If yes, then I may just learn wxPython first. Please advise, thanks. Regards, activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Part of those sinks are in C++ land, and part (too much) are in Python. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sched is requesting more input data than we can provide
On 01/23/2014 04:00 PM, Miklos Maroti wrote: Hi! I am getting this error: sched:xxx is requesting more input data than we can provide. ninput_items_required = 16000 max_possible_items_available = 8191 and I have no idea how to fix it. Is it possible to request more buffer space? Setting the minimum output buffer size seems to have no effect for me. Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio If this isn't a block you wrote yourself, it's very likely that you've misconfigured your flow-graph in a way that causes this to happen. Make sure that there's agreement about sample-rates, decimations, etc, throughout the graph. -- 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] how to use FFT without grc block
On 01/24/2014 09:55 AM, Nasi wrote: Coder is a good coder if his code is readable first. Anyone one can design a confusing language. A programmers job in documentation isn't to teach you the language the code is written in. It is assumed that the reader knows the language already. Imagine that in spoken languages, we all had to include massive amounts of clarifying sub-texts every time we spoke, because the other party may not be familiar *at all* with our spoken languages. The www.gnuradio.org website has lots of overall architectural information, I'd suggest you spend some time at it. The Doxygen docs aren't intended to be tutorials. They are more like a quick reference document that can help you with calling parameters, etc. But from your questions, I'm getting that you have only the vaguest notion of how Gnu Radio is architected, and are confused as a result. -- 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] how to use FFT without grc block
On 01/24/2014 11:32 AM, Nasi wrote: instead of helping, you like to embarrass me... in my first email, I asked for a tutorial not a short reference. Well, how about here: http://gnuradio.org/doc/doxygen/ And here: http://gnuradio.org/redmine/projects/gnuradio/wiki/HowToUse And here: http://gnuradio.org/redmine/projects/gnuradio/wiki/WhatIsGR And here: http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsWritePythonApplications And here: http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ And here: http://www.youtube.com/playlist?list=PL618122BD66C8B3C4 Пятница, 24 января 2014, 10:33 -05:00 от Marcus D. Leech mle...@ripnet.com: On 01/24/2014 09:55 AM, Nasi wrote: Coder is a good coder if his code is readable first. Anyone one can design a confusing language. A programmers job in documentation isn't to teach you the language the code is written in. It is assumed that the reader knows the language already. Imagine that in spoken languages, we all had to include massive amounts of clarifying sub-texts every time we spoke, because the other party may not be familiar *at all* with our spoken languages. The www.gnuradio.org http://www.gnuradio.org website has lots of overall architectural information, I'd suggest you spend some time at it. The Doxygen docs aren't intended to be tutorials. They are more like a quick reference document that can help you with calling parameters, etc. But from your questions, I'm getting that you have only the vaguest notion of how Gnu Radio is architected, and are confused as a result. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org sentmsg?composeTo=discuss%2dgnura...@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- NE -- 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] GNU Radio Questions
On 01/25/2014 04:59 PM, Andrew Rich wrote: Hi, got some questions 1. Can GNURadio run on OpenSUSE Linux Yes. 2. Can GNURadio work with RTL SDR dongles ? Yes. 3. What can you do with the output of GNU Radio For instance, other than listening , can you decode AX25 decode PSK31 visualise the audio like on a scope do a spectral display decode ADS-B decode AIS decode pagers Andrew VK4TEC Gnu Radio is primarily a *development framework* for host-based DSP, mostly from SDR radio hardware. It isn't a plug and play application for casual airwave surfing, although such applications have been *written* using the Gnu Radio DSP framework, such as GQRX. If you can manipulate a signal using a formal mathematical model, you can use Gnu Radio to process that signal. I'd suggest starting at:www.gnuradio.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need an indicator on the GUI display
On 01/26/2014 05:34 PM, Marcus Müller wrote: Hi Jim, you can easily code your own GUI ;). Actually, I find that streaming values via UDP or TCP to a remote python application works rather nicely. And I find that gygtk and pycairo are rather powerful toolsets. Also I fiddled around with different python web frameworks, taking data from a socket, and rendering it by updating a browser page using ajax, but I kind of lost interest on the way... But maybe this might be of interest to your application case. Greetings, Marcus O YOu can stick a PROBE in the path, and have a static-text box take the output of a variable that tells you whether threshold exceeded or not. It's not a lamp, but it does the job. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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] Problem with receiving signal from satellite Thuraya-3
On 01/28/2014 09:14 PM, Cheng Chi wrote: Hi, I am trying to collect signal from Thuraya-3. Here is the setup I used: - USRP N210 + WBX - LNA with 30dB gain (ZHL-1217MLN) - Iridium Antenna (I don't have specific antenna for Thuraya right now. Since Iridium and Thuraya frequency bands are quite close, I suppose it would work more or less) Center frequency: 1530MHz Sampling rate: 10MHz From the spectrum (attached), I can see the Inmarsat signal, but no sign of Thuraya signal. Anyone has suggestion about how to receive the thuraya signal? Best regards, Cheng Chi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Is the Thuruya signal spread spectrum? -- 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] Problem with receiving signal from satellite Thuraya-3
On 01/28/2014 09:14 PM, Cheng Chi wrote: Hi, I am trying to collect signal from Thuraya-3. Here is the setup I used: - USRP N210 + WBX - LNA with 30dB gain (ZHL-1217MLN) - Iridium Antenna (I don't have specific antenna for Thuraya right now. Since Iridium and Thuraya frequency bands are quite close, I suppose it would work more or less) Center frequency: 1530MHz Sampling rate: 10MHz From the spectrum (attached), I can see the Inmarsat signal, but no sign of Thuraya signal. Anyone has suggestion about how to receive the thuraya signal? Best regards, Cheng Chi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Interesting. That amplifier is basically a *power amp*, rather than a receiver amp, and the noise figure isn't stunning, and 1.5dB. -- 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] Problem with receiving signal from satellite Thuraya-3
On 01/28/2014 09:24 PM, Cheng Chi wrote: Hi, I think it's TDMA/FDMA, not spread spectrum. Each channel is about 30KHz. Best regards, Cheng Chi Make sure that you're tuned to the correct frequency, and that your link margins are adequate. It could be that your antenna has insufficient gain for the signals coming from Thuruya. The Iridium birds are *strong*, and also in fairly low orbits. You might need a *real* LNA at those frequencies--a GPS LNA would work, except that you'd likely have to remove the 1575MHz filter. On Wed, Jan 29, 2014 at 10:17 AM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 01/28/2014 09:14 PM, Cheng Chi wrote: Hi, I am trying to collect signal from Thuraya-3. Here is the setup I used: - USRP N210 + WBX - LNA with 30dB gain (ZHL-1217MLN) - Iridium Antenna (I don't have specific antenna for Thuraya right now. Since Iridium and Thuraya frequency bands are quite close, I suppose it would work more or less) Center frequency: 1530MHz Sampling rate: 10MHz From the spectrum (attached), I can see the Inmarsat signal, but no sign of Thuraya signal. Anyone has suggestion about how to receive the thuraya signal? Best regards, Cheng Chi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Is the Thuruya signal spread spectrum? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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] Float version of the Frequency Xiating FIR Filter?
On 01/29/2014 07:24 PM, Jordan Johnson wrote: I am attempting to translate a 20khz DRM signal from its default spot of 10khz, to 120khz. The Frequency Xiating FIR does this just fine but it also decimates the signal--which I do not want. I want to pass the float input as a float until the final stage at the BlaeRF as my FM transmitter is an all-float operation as well. Altering the signal at all results in ruining reception of said signal. (I also like keeping constant sample-rates throughout the graph). Is there another way to translate frequency in GRC outside of the all-in-one filter? Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio YOu don't *need* to decimate on that filter at all. And, I think that you're confused about what decimation means. It has nothing to do with data formats. It has to do with sample-rates. -- 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] UHD stream tagging
On 02/08/2014 02:37 PM, Price, Nathan D. (ST-Student) wrote: Hello, I'm working on project in gnuradio, in which I'm trying to toggle on and off the transmission from the USRP. After much research, I learned this was done by tagging the first sample of a transmission with tx_sob and the last sample with tx_eob (there was also a tx_time tag, but I found the former option more convenient). I wrote a custom block that periodically tags segments out of continuous stream of data as a proof of concept; however, the transmission remains continuous as if there were no tag. I've checked with the tag debugging block to ensure my block acutally generates tags. My flow graph is simply: file source(repeat)-custom tagging block-psk mod-multiply const-uhd sink. Reading in the archive, I haven't found reference to success much success with the streaming API. I would love the community's input on this problem. Thanks, Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The basic issue is that TX_EOB doesn't mean what you think it means -- it's mostly just a way to let the hardware know not to expect any more samples. In particular, it doesn't cause the TX synthesizer to shut-down because many folks what phase-continuity across multiple bursts, so the synthesizer is left running, and if you have non-zero samples still flowing after TX_EOB, there'll still be stuff coming out the TX port. The main disconnect is that GNu Radio is a streaming architecture, and UHD supports that, but also supports a much-richer interaction model that doesn't really fit perfectly with Gnu Radio, so gr-uhd does the best job it can. Many folks who want to do stuff with UHD that doesn't fit the Gnu Radio model use UHD directly (a significant fraction of Ettus customers do things this way). While UHD has grown up alongside Gnu Radio, its architecture and interaction model aren't necessarily a fits like a glove thing. I'd suggest looking at the tx_bursts.cpp example in the UHD examples to see how bursts are managed. In particular, the hardware itself can't really know what your channel access model is, so it's up to you to crank the TX gain down to zero, and stop sending samples after a TX_EOB, if that's what you want to happen. Something that I recall getting discussed (and perhaps Martin can chime in here, since I think gr-uhd is you baby now :) ) was to have gr-uhd start dropping incoming samples on the floor when it receives a TX_EOB tag, and go into a waiting for further instructions mode, in particular perhaps waiting for a TX_SOB. But in concert with that the app really needs to crank down the TX gain, and insert zeros if it isn't going to stop sending samples. This can be hard to orchestrate within the confines of GRC, but in the full-fledged expressiveness of the Python or C++ APIs to Gnu Radio, it should be fairly easy. -- 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] Why does Airprobe no longer work with current GNU Radio?
On 02/09/2014 09:11 PM, zhenhua han wrote: Hi all, I'm new here to use GNU Radio. And I'm trying to decode GSM signal with airprobe. In GSoC page of GNU Radio, I found these words: It no longer works with current GNU Radio versions, and doesn't make use of any of the new GNU Radio features. What are the detailed reasons? Moreover, what are the new features? Best wishes, Zhenhua HAN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The Gnu Radio API changed between 3.6.5.1 and 3.7.0 http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7 Since very few of us here know exactly which features are used by gr-airprobe, it's hard to say which new features it might be avoiding using... -- 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] LPF in FM receiver
On 02/11/2014 11:22 AM, Pablo Fernández Alonso wrote: In the FM receiver: Why a LPF is used instead of a BPF in order to select the Radio channel that we want to hear? That is the only part I don't understand. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio A complex LPF is the same as a symmetric bandpass, when signals are at baseband. -- 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] IQ changing with restart
On 02/11/2014 11:57 AM, Martin Braun wrote: On 11.02.2014 06:19, Sylvain Munaut wrote: Hi, I've done my homework on this one, crawled through the web talked to colleagues. If I am missing something obvious please point it out - it's not for lack of effort on my part! I'm not really sure what you're expecting. Of course the phase alignement between the Tx and Rx is going to be random depending on restart. Using the same clock will prevent it from drifting, but the initial phase alignement is random. This is usually resolved by using training sequence, headers, differential encoding, ... I had the same thought -- it looks like a phase change. This is a PSK signal, right? Have you looked at the constellation diagram? MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Neither synthesizer will start with any particular phase offset, either. -- 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] Idea of a USRP UHD block that fills gaps in transmission from USRP
On 02/13/2014 11:19 AM, Matt Ettus wrote: Piotr, One problem is that if you cannot keep up, adding in all-zeros data will just make it harder to keep up. In general, modern PCs should be able to keep up with 25 MS/s without problem unless you are doing a lot of processing. We are actually able to keep up with 300 MS/s on the X300. So the question is more about why the app can't keep up. An alternative might be to stream to a file. That should keep up without dropping as long as you have a fast drive. Then you can process samples from that file at the pace your app can keep up with. Matt And on a tangentially-related note, SSDs aren't necessarily fast writers. Particularly if they aren't using an AHCI interface and/or, they're early-generation. I found this out the hard way... On Sun, Feb 9, 2014 at 1:19 AM, Perper per...@o2.pl mailto:per...@o2.pl wrote: Hi all, Interruptions transmission over Gigabit Ethernet when receiving samples from USRP can happen at highest data rates no matter how many tricks you use with your network card (I have experience with N200/N210). The loss of part of the signal results with synchronization loss in data transmission systems. There is possibility to handle this problem by catching rx_time stream tags. But there might be a solution to keep synchronization that might work quite well with gr-blocks that don't handle stream tags. What if USRP UHD Source gave user an option to fill all of the gaps in signal with exact number of lost samples (for example with zeros). Additionally it could produce stream tags with position and length of each gap so it would be easy to store a file with continuous signal stream paired with a file containing metadata describing where and for how long the signal samples were lost. Is it possible to do exactly what I'm describing with current gnuradio blocks? In my case it would often make many things I do easier. -- Best Regards, Piotr Krysik ___ 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 -- 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] Different sensing results with same hypothesis
On 02/19/2014 12:34 PM, Dan CaJacob wrote: Oh, you were talking about the daughterboard itself. No guarantees there, but the schematics are all available. I think there was a recent discussion about this on the list. What I was saying specifically, was that there is no AGC in the USRP motherboards/FPGA. Daughterboards are separate, but in general, I don;t think they have AGC. The WBX and some others, for instance, use fixed gain amplifiers with a variable attenuator to control power. Very Respectfully, Dan CaJacob The only card with AGC is TVRX2, and it cannot be disabled. On Wed, Feb 19, 2014 at 11:19 AM, Aditya Dhananjay adi...@cs.nyu.edu mailto:adi...@cs.nyu.edu wrote: I don't think there is any AGC on USRP hardware... Hi Dan, You are correct; I stand corrected. The XVCR2450 does not have an AGC. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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] Clarification regarding Sample width in USRP.
On 03/01/2014 11:00 PM, Manu T S wrote: Hello Everyone, From little bit of googling I understood that there are different sample width possible in USRP. If my understanding is correct, we can use 16/8 bit sample width. But my usrp block in GNU Radio lists complex float32 and complex int16, and VITA word 32 as the types. How can we relate this with the 16/8 bit sample width? From my understanding the complex data type in GNU Radio uses interleaved float32. So does the driver on the host machine convert the incoming data from its sample width to the one we want to the upstream blocks? -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You're looking for the wire format parameter in the UHD source/sink. UHD converts the wire-format into the floating-point format used within Gnu Radio. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Support e-mails to supp...@ettus.com
Folks: I've been on the road for the last 8 days, and I just got back this evening. Any of you who are waiting for a reply from supp...@ettus.com, I'll be working my way through the back-log tomorrow. Not ignoring you, just was on the road. -- 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] Failure of sending square wave over USRPs (back-to-back)
On 03/14/2014 01:05 PM, Johnathan Corgan wrote: The hardware PLL in the receive section of the daughterboard serves an entirely different purpose; it is there to create the local oscillator signal at the frequency requested when tuning. However, that frequency is ultimately derived from a hardware oscillator that is subject to manufacturing tolerances, drift, thermal effects, phase noise, etc. So even when both transmitter and receiver are physically tuned to what you set as the same frequency, in reality there is an offset between them, and even the amount of that offset changes on a moment-by-moment basis. It is an unavoidable reality of designing radio receivers that one must compensate for this offset in transmitter and receiver local oscillator frequencies. In software radio systems, this is most often done by estimating the frequency/phase error and performing de-rotation on the resulting waveform. I would emphasize that this requirement isn't a quirk of SDR hardware--every digital radio system ever has needed some kind of offset error estimator to track differences between TX and RX phase/frequency. In analog systems (like NBFM voice, or FM radio, or AM audio), it's generally not as necessary, because it's hard for humans to hear minor frequency offsets. But for data systems, an error estimator is vital.Even in WBFM, I've implemented an AFC block to compensate for the crappy (RTLSDR) master clock on the receiver. But each modulation type and coding system will have its own way of estimating phase/frequency error which you'll have to implement, or just live with bad BER. -- 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] Failure of sending square wave over USRPs (back-to-back)
On 03/14/2014 10:51 PM, Activecat wrote: Dear Martin, On Fri, Mar 14, 2014 at 5:13 PM, Martin Braun martin.br...@ettus.com wrote: Here's a very brief explanation: The PLL for the synthesizer makes sure the locally generated frequency is stable (per-device). It's physically impossible to make perfectly aligned oscillators. By throwing money at the problem, you can reduce the potential offset. But since you can never get rid of it entirely, you also need a mechanism (e.g. a PLL) to lock on the incoming signal. At the receiver side, the received signal is first processed by SBX daughtercard before being sent it to the host (which is the PC). The IQ demodulation is performed at the receiving SBX, not at the host. In this case the clocking of SBX must be synchronized to the received IQ-modulated signal. Hence the PLL must be done precisely in the SBX, not in the host, correct? If the PLL is done at the gnuradio flow graph, then this flow graph must be able to adjust the local oscillator of the SBX daughtercard, via softare. Does gnuradio flow graph have this capability? Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The SBX does analog downconversion, nothing more. It knows nothing about the incoming signal, and doesn't demodulate it in any way. That is what SDR is all about--the signals are represented as complex-baseband (i/Q) format for processing by computer algorithms. The SBX (or any other daughtercard) is simply doing downconversion (or, upconversion for TX). Frequency offset in a digital demodulator implemented in software generally drives a local correction--not the hardware. You achieve this by bringing in a bit more bandwidth than you actually need, and then applying frequency corrections in software. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 03/15/2014 12:10 AM, Activecat wrote: Dear Marcus, On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech mle...@ripnet.com wrote: The SBX does analog downconversion, nothing more. It knows nothing about the incoming signal, and doesn't demodulate it in any way. Please be clarified what do you mean by analog downconversion. At the transmitter side, complex-based (I/Q) signal is fed into USRP. Says, the signal is x(t) = I(t) + j.Q(t) I think this is performed at transmitter SBX: y(t) = I(t).cos(wt) - Q(t).sin(wt) where w = central frequency, t = time here the y(t) is the output of SBX to the antenna. Is this what you meant by analog upconversion ? Whereas at the receiver side, the received signal from antenna is real signal, says, z(t) = c.y(t) = c.I(t).cos(wt) - c.Q(t).sin(wt)where c = channel attenuation The receiver SBX performs this: Retrieved I(t) = LPS( z(t).cos(wt) )where LPS = low pass filter Retrieved Q(t) = LPS( z(t). sin(wt) ) With this process the receiver SBX is able to produce complex-based (I/Q) signal from the real signal from antenna. Is this what you meant by analog downconversion? If not, please describe what you mean by analog upconversion and analog downconversion, because I have no idea of what you are trying to explain. It is impossible that SBX only mix the incoming complex-based signal with a central frequency and then send directly to antenna for transmission, because the simple mixing (analog upconversion) produces another complex-based signal which cannot be transmitted through antenna. A physical antenna can only transmit real signal, not complex-based signal. Please clarify, thanks. Regards, Activecat The term upconversion and downconversion are common terms used in the radio engineering industry, but may not be common among other technical folks. The complex upconverter simply sums the two components after mixing, to produce a valid real-valued analog signal. But, again, none of the daughtercards that Ettus produces are designed to extract *information* from the signal--they merely manipulate it so that it is represented in a complex baseband form that can easily be digitized by the ADCs. One impresses *information* on an RF carrier by modulating it--doing stuff to that carrier so that the information can be recognized by a suitable receiver. There are hundreds of different ways of doing this, depending on the required attributes of the resulting signal, etc. You square-wave example is roughly similar to so-called OOK--on/off keying. Such techniques are generally only used for very-low-speed data transmission, owing to the unpleasant spectral properties of signals with sharp edges. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 03/15/2014 02:57 AM, Activecat wrote: Dear Marcus, Please avoid adding more confusions rather than clarities. The term upconversion and downconversion are common terms used in the radio engineering industry, but may not be common among other technical folks. In radio engineering industry, there are more than 1 type of upconversion or downconversion. The common types include: a). analog up-conversion: The baseband real signal x(t) will be mixed with a carrier frequency, that its output is a real signal of y(t) = x(t).cos(wt) where w = central frequency b). complex up-conversion: The baseband complex-based signal x(t) = I(t) + j.Q(t) will be quadrature upconverted so that its output is a real signal of y(t) = I(t).cos(wt) - Q(t).sin(wt) For clarity sometimes we need to clarify which one you were referring to. These two (analog vs complex upconverter) are significantly very different from each other. I was using the term analog to distinguish from digital. The FPGA *also* has up/downconverters for doing offsetting and mop up operations on the signal stream, and those operations are, necessarily, performed on a digital sample stream, rather than on an analog electron stream. A quadrature up (or down) converter is structurally very similar to a real-valued converter, and most folks in the industry refer to both as upconversion and downconversion. While the mathematical expressions that describe them are, as you note, different, they're performing a very similar function, and use nearly-identical hardware, except that in the complex (quadrature) case, you have two mixers, and a phase-split local oscillator. You can see the schematics of SBX (and other cards) here: http://www.ettus.com/files/schematics ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
This thread is starting to get a little too confrontational, so we all need to take a bit of a break. Please take a look at the PLL blocks in GNU Radio; you can find them under the Synchronizers category in the block tree of GRC. Spend some time understanding these blocks and how to use them. If you still have questions, please open another email thread. Thanks, Tom ___ Sorry, Tom. I posted another in the thread before looking at you drop this thread message. My bad. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] For Sale: bladeRF x115 with GPIO expansion
On 03/15/2014 09:57 PM, Louis Brown wrote: Quite so. I have a GPSDO though, so it's nice to be able to lock to that. Last week I recorded WWVB (60 kHz) amplitude and phase for 1 week to monitor propagation. Interesting results to see the fades over 6 days Phase was futile though as their new BPSK mod messes things up. Thanks, Lou KD4HSO I'll point out that for VLF monitoring, a 96kHz (DC-48kHz) or 192kHz (DC-96kHz) sound card works quite well. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I built a prototype WWVB receiver in GR a couple of years ago, but I don't locally get WWVB :(Neither did my LaCrosse clock though, so it wasn't my fault :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft missing
On 03/16/2014 03:20 PM, Chris Stankevitz wrote: Hello, Using gentoo linux I installed uhd and gnuradio with the commands emerge uhd and emerge gnuradio. According to http://gnuradio.org/redmine/projects/gnuradio/wiki/HowToUse: GNU Radio comes with a large variety of tools and programs... The most commonly used tools include uhd_fft Unfortunately I do not have uhd_fft on my system. I do have uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance , uhd_images_downloader, uhd_cal_tx_dc_offset, uhd_find_devices, and uhd_usrp_probe. According to http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource: If you want to be able to use USRP devices, you need to install UHD before installing GNU Radio. Questions: Q1: Why do I not have uhd_fft on my system? I can't answer that one Q2: What is the technically going on that leads to the warning about installing UHD before gnuradio? What are the consequences of installing UHD after GNU Radio? If you're building from source, the source-build needs to know where UHD is installed on your system before it can build gr-uhd, since gr-uhd links again UHD libraries. It can't very well do that until UHD has already been installed Q3: Which package provides the file uhd_fft: GNU Radio, UHD, or something else? It's part of gr-uhd/apps Thank you, Chris ___ 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] uhd_fft missing
On 03/16/2014 05:06 PM, Chris Stankevitz wrote: Marcus, Thank you. In gentoo speak, what you said typically translates to The gnuradio ebuild has a uhd USE flag. Make sure the uhd USE flag is enabled. Well, I checked and sure enough it was disabled. I'm rebuilding now but I'm sure it will work correctly. Thanks again, Chris The nice thing about distribution-specific idioms isthere's too damned many from which to choose. :( People often criticize build-gnuradio because it doesn't cover *my* particular distribution, as if adding support for a new distrib is as easy as dumping Nigerian spam in your junk folder One of Linux' most serious weaknesses has emerged from its most profound strength--there are now dozens of distribs extant, each with their own peculiar packaging tools, idioms, and filesystem layouts, and with that, troubleshooting strategies. If I were in charge of the world, there would only be one Linux distribution :) :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD blocks
On 03/20/2014 03:56 PM, Sara Chérif wrote: My friend has installed GNU Radio from this link http://blogs.bu.edu/mhirsch/2012/07/installing-gnu-radio-in-ubuntu-12-04-x64/comment-page-1/ Then when running GNURadio , she found UHD blocks in it . 1- Does this mean that this link has installed GNURadio UHD on Ubuntu , and that there is no need to install UHD ? 2- Is there any command that she can run in terminal to check if UHD is installed? Thanks ! :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Try uhd_usrp_probe -- 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] gqrx segfaults: rtlsdr_read_async returned with -5
On 03/21/2014 12:41 PM, M Dammer wrote: I updated from a gnuradio 3.7.3 git version (before 3.7.3 was officially released). I updated the pybombs recipes via git before the update. Pybombs update removed all updateable gnuradio stuff and installed it new as expected. I can actually confirm the problem now on two machines. Both running XUbuntu 12.04 64bit. One with an Intel core 2 due and the other with an AMD APU processor. I usually had no problems running gnuradio, gqrx and other related applications on both machines. Can you explain what that rtlsdr_read_async... message means ? Mark That message is coming from the rtl-sdr driver code, which is seeing an error return from a libusb read transaction. Which means there's something wrong in the USB communications path between your PC and the dongle. -- 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] UHD build apparently failed
On 03/21/2014 09:40 PM, Sara Chérif wrote: As I am installing GNU Radio from this link: http://blogs.bu.edu/mhirsch/2012/07/installing-gnu-radio-in-ubuntu-12-04-x64/comment-page-1/ (which installs GNU Radio UHD ) I got the following error , what can i do ? Thanks :) [ 26%] Building CXX object lib/CMakeFiles/uhd.dir/transport/nirio/rpc/rpc_client.cpp.o /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp: In constructor 'uhd::usrprio_rpc::rpc_client::rpc_client(const string, const string, uint32_t, uint32_t)': /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp:51:9: error: 'connect' is not a member of 'boost::asio' /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp:51:9: note: suggested alternatives: /usr/include/x86_64-linux-gnu/sys/socket.h:129:12: note: 'connect' /usr/include/boost/asio/detail/impl/socket_ops.ipp:383:5: note: 'boost::asio::detail::socket_ops::connect' make[2]: *** [lib/CMakeFiles/uhd.dir/transport/nirio/rpc/rpc_client.cpp.o] Error 1 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2 make: *** [all] Error 2 UHD build apparently failed Exiting UHD build Send success/fail info to sbrac.org http://sbrac.org? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I see the same problem on Fedora 14, and even when I specify: -DENABLE_X300=OFF In the cmake, I still see this build failure due to nirio requiring a newer boost. Ben/Michael have you a comment? -- 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] UHD build apparently failed
On 03/23/2014 10:23 AM, Moritz Fischer wrote: Hi Marcus, Sara I think I fixed this somewhen back in december, when RHEL6 support broke. Which branch (tag) are you building off? UHD 3.7.0 (master) should have those changes. Cheers, Moritz Here's a bit of git log of what I'm building: commit a8caec5f93976c081d488118f53a72dca49efdf6 Author: Ashish Chaudhari ash...@ettus.com Date: Wed Feb 19 19:22:52 2014 -0800 b200: Fixed bug in rx_dsp_core_3000 that would assume 3 halfbands and X300 s commit 7fef199d194c9a63b3312845979fa353f90f4d23 Author: Nicholas Corgan nick.cor...@ettus.com Date: Fri Feb 14 06:49:10 2014 -0800 Updated images URL to UHD 3.7.0 images commit ebf1f1780d692c25e445b4df1c19d01ba43d6a94 Author: Ben Hilburn ben.hilb...@ettus.com Date: Thu Feb 13 17:30:24 2014 -0800 Putting the ICMP destination unreachable fix in X300 firmware. commit ff1546f8137f7f92bb250f685561b0c34cc0e053 Author: Ben Hilburn ben.hilb...@ettus.com Date: Fri Feb 14 12:05:07 2014 -0800 Pushing the bulk of UHD-3.7.0 code. On Sat, Mar 22, 2014 at 2:55 AM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 03/21/2014 09:40 PM, Sara Chérif wrote: As I am installing GNU Radio from this link: http://blogs.bu.edu/mhirsch/2012/07/installing-gnu-radio-in-ubuntu-12-04-x64/comment-page-1/ (which installs GNU Radio UHD ) I got the following error , what can i do ? Thanks :) [ 26%] Building CXX object lib/CMakeFiles/uhd.dir/transport/nirio/rpc/rpc_client.cpp.o /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp: In constructor 'uhd::usrprio_rpc::rpc_client::rpc_client(const string, const string, uint32_t, uint32_t)': /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp:51:9: error: 'connect' is not a member of 'boost::asio' /home/dell/GNUradio/uhd/host/lib/transport/nirio/rpc/rpc_client.cpp:51:9: note: suggested alternatives: /usr/include/x86_64-linux-gnu/sys/socket.h:129:12: note: 'connect' /usr/include/boost/asio/detail/impl/socket_ops.ipp:383:5: note: 'boost::asio::detail::socket_ops::connect' make[2]: *** [lib/CMakeFiles/uhd.dir/transport/nirio/rpc/rpc_client.cpp.o] Error 1 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2 make: *** [all] Error 2 UHD build apparently failed Exiting UHD build Send success/fail info to sbrac.org http://sbrac.org? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I see the same problem on Fedora 14, and even when I specify: -DENABLE_X300=OFF In the cmake, I still see this build failure due to nirio requiring a newer boost. Ben/Michael have you a comment? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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] UHD build apparently failed
On 03/23/2014 12:08 PM, Moritz Fischer wrote: Hi Marcus, On Sun, Mar 23, 2014 at 3:24 PM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: Here's a bit of git log of what I'm building: commit a8caec5f93976c081d488118f53a72dca49efdf6 Author: Ashish Chaudhari ash...@ettus.com mailto:ash...@ettus.com Date: Wed Feb 19 19:22:52 2014 -0800 b200: Fixed bug in rx_dsp_core_3000 that would assume 3 halfbands and X300 s Crap, that's 7 commits down from the fix in our internal master. I'll see if I can get stuff pushed tomorrow. In the meantime you can try the attached patch. Happy hacking, Moritz It got further, the nirio stuff made it past, but, then: /home/mleech/uhd/host/include/uhd/transport/nirio/nirio_fifo.ipp:377:24: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic' [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_base.cpp.o [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_eeprom.cpp.o [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_id.cpp.o [ 45%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_iface.cpp.o [ 45%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_manager.cpp.o [ 46%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/gps_ctrl.cpp.o /home/mleech/uhd/host/lib/usrp/gps_ctrl.cpp:33:38: fatal error: boost/container/vector.hpp: No such file or directory compilation terminated. make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/gps_ctrl.cpp.o] Error 1 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2 make: *** [all] Error 2 -- 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] UHD build apparently failed
On 03/23/2014 02:42 PM, Marcus Müller wrote: boost::container is quite new (introduced in 1.48 afaik); I'm pulling master right now, but boost::container::vector should be STL-compatible. replace the incluse by #include vector and try ;) That got me past gps_ctrl.cpp, but now: /home/mleech/uhd/host/lib/usrp/common/adf435x_common.cpp: In function 'adf435x_tuning_settings tune_adf435x_synth(double, double, const adf435x_tuning_constraints, double)': /home/mleech/uhd/host/lib/usrp/common/adf435x_common.cpp:81:29: error: 'floor' is not a member of 'std' /home/mleech/uhd/host/lib/usrp/common/adf435x_common.cpp:128:66: error: 'ceil' is not a member of 'std' make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/common/adf435x_common.cpp.o] Error 1 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2 make: *** [all] Error 2 That stuff used to work just fine with my older (F14) system here. Frustrating. On 03/23/2014 06:10 PM, Marcus D. Leech wrote: On 03/23/2014 12:08 PM, Moritz Fischer wrote: Hi Marcus, On Sun, Mar 23, 2014 at 3:24 PM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: Here's a bit of git log of what I'm building: commit a8caec5f93976c081d488118f53a72dca49efdf6 Author: Ashish Chaudhari ash...@ettus.com mailto:ash...@ettus.com Date: Wed Feb 19 19:22:52 2014 -0800 b200: Fixed bug in rx_dsp_core_3000 that would assume 3 halfbands and X300 s Crap, that's 7 commits down from the fix in our internal master. I'll see if I can get stuff pushed tomorrow. In the meantime you can try the attached patch. Happy hacking, Moritz It got further, the nirio stuff made it past, but, then: /home/mleech/uhd/host/include/uhd/transport/nirio/nirio_fifo.ipp:377:24: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic' [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_base.cpp.o [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_eeprom.cpp.o [ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_id.cpp.o [ 45%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_iface.cpp.o [ 45%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard_manager.cpp.o [ 46%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/gps_ctrl.cpp.o /home/mleech/uhd/host/lib/usrp/gps_ctrl.cpp:33:38: fatal error: boost/container/vector.hpp: No such file or directory compilation terminated. make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/gps_ctrl.cpp.o] Error 1 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2 make: *** [all] Error 2 -- 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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] UHD build apparently failed
On 03/23/2014 07:08 PM, Marcus Müller wrote: This calls for #include cmath; I wonder how that is working on my f19 Yup, that took care of it. Then there's the b200_iface.cpp problem with libusb on my system not having libusb_error_name, so I had to copy the macro from transport/zero_copy that's conditional on HAVE_LIBUSB_ERROR_NAME, and it all compiled just fine. -- 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] AM Stereo TX? (Motorola C-QUAM)
On 03/24/2014 07:59 PM, Jordan Johnson wrote: I have been Googling a good deal and have not come up with much. I have done numerous projects with GNURadio, but while I can throw together a wideband AM transmitter, I cannot figure out the stereo portion. Based on what I know; it is some kind of phase-modulated information. Anyone know how to get started on a flowgraph, or maybe some code examples? Thanks. :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I don't think I've ever heard of anyone making this query before. You should probably start with whatever public documents describe the Motorola system, and go from there. -- 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] Received power measurement
On 03/26/2014 07:04 AM, Medhat Hamdy wrote: Hi all, I need to know if there is any method to measure the received signal power using USRP N210. I am using gr_probe_avg_mag_sqrd_x_0 to measure the signal strength, however, the results are not accurate. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio To get accurate readings, you have to calibrate with an external, known, source. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mixing two signals for Radar application.
Hi Marcus, here is the flow graph and the output signals with movement across the antennae and without. http://tinypic.com/r/a5et5k/8 (GRC flow) http://tinypic.com/r/nbeq0k/8 (without movement) http://tinypic.com/r/2s7dnye/8 (with movement) Thank you. Dimitris. OK, so I looked at the flow-graph you posted. There's a lot of confusion in there, it has a lot of confusion per unit area of flow-graph, so there's a list: o You're mixing sample-rates without doing any interpolation or decimation. For example, slamming your 100ksps signal source into a USRP hardware source that will try to suck samples out at 20Msps. o You're trying to mix this 100ksps source with a USRP source running at 25ksps (which isn't a valid rate for any USRP that I'm aware of). o You're using a throttle block in a chain that includes hardware -- I'm *guessing* that you thought maybe it would do sample-rate conversion or something, but it isn't clear what your intention is here. o You're trying to generate a 1MHz signal source with a sample-rate of only 100ksps. This violates Nyquist rather badly. I think you need to understand what your bandwidth requirements are, and let that guide your sample-rate decisions. If this is a CW radar, you don't need a lot of bandwidth, and thus, sample-rate. You don't mention what USRP hardware you have, but in general, the sample-rate must be a proper integer fraction of the master-clock rate, and generally, the resulting decimation can be no higher than 512. Some USRPs (B100, E1xx, B2xx) have variable master-clocks, so you can achieve a variety of different rates. Further, my suspicion from all the above is that your current grasp of DSP techniques isn't all that solid--I could be wrong, but it *seems* that way from the flow-graph. My suggestion would be to step back, trying to really understand what you want to do, and maybe curl up with a book on DSP *first*. While stumbling around when you're just building RX flow-graphs with real hardware doesn't do any harm, doing the same with TX flow-graphs can get unwanted visits from the Federal Authorities in some countries -- 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] GIT checkout of Gnu Radio failed!
Yes , I tried it again it works :)
Thanks Tom , Volker Nathan .
I ran gnuradio in terminal after installing I see there is no
problem in it
sara@ubuntu:~/gnuradio$ gnuradio-companion
Warning: Block key blocks_ctrlport_monitor_performance not found
when loading category tree.
Warning: Block key blocks_ctrlport_monitor_performance not found
when loading category tree.
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.000-53-g6962543f
Welcome to GNU Radio Companion 3.7.3
Showing:
BUT when installing it , after 3 hours of installation , I got an
output which shows that GNURADIO_CORE GRUEL LIBRARIES are not found
! is there a problem , or these libraries are not important ? Do I
have to uninstall install again?!
also it is saying : You will not be able to access your USRP1 device
until you do this .. I will use B100 B200 , is there any
problem ? Any problem will occur when using my usrps?!
also it is saying : You should probably set your PYTHONPATH to:
/usr/local/lib/python2.7/dist-packages Using:
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages in your
.bashrc or equivalent file prior to attempting to run
any Gnu Radio applications or Gnu Radio Companion.
what is the importance to do that ,as I ran gnuradio now ? I found a
.bashrc file in home directory , is this the meant file? I will copy
paste export PYTHONPATH=/usr/local/lib/python2.7/dist-packages to
the end of file , tell me if this is not right.
Thanks
Here is the output in terminal during installation:
Starting function extras at: Fri Mar 28 18:20:28 EET 2014
mv: cannot stat `gr-baz': No such file or directory
Doing GIT checkout for extra module gr-baz
Cloning into 'gr-baz'...
remote: Reusing existing pack: 1101, done.
remote: Total 1101 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1101/1101), 798.65 KiB | 51 KiB/s, done.
Resolving deltas: 100% (579/579), done.
Building extra module gr-baz
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.48.0
-- Found the following Boost libraries:
-- system
-- thread
-- checking for module 'gruel'
-- package 'gruel' not found
-- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
-- package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:135 (message):
Gruel required to compile baz
-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
mv: cannot stat `grextras': No such file or directory
Doing GIT checkout for extra module grextras
Cloning into 'grextras'...
remote: Reusing existing pack: 4066, done.
remote: Total 4066 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (4066/4066), 4.50 MiB | 55 KiB/s, done.
Resolving deltas: 100% (1996/1996), done.
Building extra module grextras
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.48.0
-- checking for module 'volk'
-- found volk, version 0.1
-- Found VOLK: /usr/local/lib/libvolk.so
-- checking for module 'gruel'
-- package 'gruel' not found
-- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
-- package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:112 (message):
Gruel required to compile extras
-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
Done function extras at: Fri Mar 28 18:22:31 EET 2014
Starting function mod_groups at: Fri Mar 28 18:22:31 EET 2014
This script has just modified /etc/group to place your userid
'('$USER')' into group 'usrp'
In order for this change to take effect, you will need to log-out and
log back
in again. You will not be able to access your
[Discuss-gnuradio] GR 3.7 build failure
I haven't tried building Gnu Radio in a while, and on my F14 system today: 15%] Building CXX object gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o In file included from /home/mleech/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc:27:0: /home/mleech/gnuradio/gr-blocks/lib/message_strobe_random_impl.h:48:7: error: ‘mt19937’ in namespace ‘boost::random’ does not name a type /home/mleech/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc: In constructor ‘gr::blocks::message_strobe_random_impl::message_strobe_random_impl(pmt::pmt_t, gr::blocks::message_strobe_random_distribution_t, float, float)’: /home/mleech/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc:57:9: error: class ‘gr::blocks::message_strobe_random_impl’ does not have any field named ‘d_rng’ /home/mleech/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc: In member function ‘void gr::blocks::message_strobe_random_impl::update_dist()’: /home/mleech/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc:89:95: error: ‘d_rng’ was not declared in this scope make[2]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o] Error 1 make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2 make: *** [all] Error 2 I've seen this mentioned elsewhere, but I don't see a hint of a fix. -- 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] Playing with 3.7
So, I have this flow-graph that mostly works under 3.7 now, except for something that's horrible. In my flow-graph, I have two layers of selectors, to select the input for a WX GUI FFT sink. The layers select either the raw or filtered chunk of bandwidth (coming off the 4 hardware sources), and the other layer selects which source. This worked like a champ in 3.6.5.1--never a problem. Under 3.7.4 (basically, today's master), when I go to select which input, there's a significant *pause*, and then the change is applied after up to about 2 seconds of hang. If I go to select the raw vs filtered, the whole application freezes solid--the GUI freezes up, no displays are updated, and the hardware sources start getting massive overruns. Now, when this thing is running, it consumes about 8% of my system, and when it freezes it consumes apparently much, much less. Now, I know that selectors are actually kind of a hack that stop the flow-graph, reconfigure it, and start it up again. So, maybe there's some kind of deadly-embrace going on. I can reimplement using adders and multipliers if I have to, but gosh, I'd rather not have to. I'm going to try to reproduce with the smallest flowgraph that shows the problem, but a simple quick test tonight worked flawlessly. Sigh. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FFT filter bug in GR3.7.4
Tag: v3.7.4git-50-ga8f73d85 This demonstrates a horrible bug I found in FFT filters--change the size from little to quite large, and the scheduler goes running home to momma: thread[thread-per-block[1]: block fft_filter_ccc (12)]: Buffer too small for min_noutput_items I've attached a minimal GRC to show this. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org fft_filter_bug.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] simple_ra/gr-ra_blocks updated for GR3.7
I've updated simple_ra and gr-ra_blocks for GR3.7. NOT extensively tested And when building gr-ra_blocks, your PKG_CONFIG_PATH had better include /usr/local/lib:/usr/local/lib64 prior to doing the cmake. -- 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] FFT filter bug in GR3.7.4
That's actually not surprising. The buffer is established when the top_block is started and will be based on the size of the FFT you need to run. Increasing the size of the filter will not increase the size of the buffer. We'll have to figure out how we want the solution to this to look. Might be we just refuse to increase the filter size during runtime so you'll have to lock/unlock the flowgraph. Will think more on this... Tom It's counter to the experience with the regular dot-product FIR filters in that you can re-size them at runtime and it's just fine. It certainly fails the least astonishment test when you have a filter that's configured for pass-through (1+0j single tap) and then later ask it to do some real filtering. But this bug has been around for a long time, as I was reminded. My other code has hacks to get around this, and when I was re-structuring for migration to GR3.7, it reared its unpleasant little head again. Granted, my use case, in this case, is a bit weird--the filter can go from passthrough to farking massive in one swell foop, when the user turns on coherent dedispersion and suddenly that's a rather-large de-dispersion filter in the path. -- 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] Fwd: Problem with getting clear FM signals using the usrp e110
On 04/10/2014 06:27 AM, Abouda Yassine wrote:
Thank you all for your responses.I tried to follow your instructions
and I did a lot of experiments to make the fm_receiver work.I have
come to some conclusions,the USRP E110 is really not that powerful,I
frankly say that I am disappointed.According to my personal
experiments the maximum sample rate for the fm_receiver was 1M and I
matched between the different blocks to get a clear sound at the
end.But,when I move the mouse the sound gets interrupted until I stop
moving and when I add an FFT sink it makes it worse.So, I believe that
I reached here the limits of the RAM ressources I think,and this
proves that the USRP E110 is not powerful or maybe not dedicated for
these applications(I am using the BASIC RX and TX daughterboards).Plz
do not hesitate to correct me if I was misjudging the device because I
am a newbie here !!
Yassine
The E1xx series are NOT a PC in a wierd box.
They're embedded platforms for embedded applications involving SDR.
The on-board CPU isn't in the same league as most desktop multi-core
processors, and even though it runs an embedded Linux, it's not just
a tiny desktop machine. The intended use for these platforms has always
been that heavy-lifting signal processing would happen on the FPGA,
so most users of this platform are adept at implementing algorithms on
the FPGA, with the CPU largely acting in a supervisory role.
Now, it turns out that there are some applications where most of the
signal processing will fit on the embedded CPU. There are ports,
for example, of OpenBTS to the E1xx series.
But asking it to do signal processing *and* GUI user-interface work at
the same time is asking a *lot* of that single-core ARM CPU.
2014-04-09 14:55 GMT+02:00 Robert McGwier rwmcgw...@gmail.com
mailto:rwmcgw...@gmail.com:
First 100k is insufficient sample rate from the E110. An FM
station has 150 kHz total swing (+/- 75 kHz) so the frequency
range of your E110 complex output is 100 kHz and is therefore
insufficient for the entire modulation. You then feed the 100k
sample per second signal into the FM block where you have informed
it you will be sending 500 kHz (quadrature rate) and then with no
decimation at all, you send the 500 kHz sample rate detected
audio to a sound block where you've told it to expect 96 kHz audio.
\left [ 0.9 \left [ \frac{A+B}{2} + \frac{A-B}{2}\sin4\pi f_pt
\right ] + 0.1\sin2\pi f_pt \right ] \times 75~\mathrm{kHz}
is the instantaneous frequency of an FM stereo broadcast signal
where A is the left channel, B is the right channel and fp is the
pilot tone frequency (19 kHz).
Consider matching sample rates between these blocks as the
software defined radio equivalent of impedance matching between
analog circuits in one view of it.
Bob
On Wed, Apr 9, 2014 at 7:40 AM, Mike Jameson m...@scanoo.com
mailto:m...@scanoo.com wrote:
Here are some pointers for you:
- Firstly, your screenshot shows the error message saying that
the RX frequency is not valid. I'd recommend using a WBX
daughterboard, however the BasicRX should still work with
strong FM signals with aliasing if that is what you are using.
- The samp_rate is set to 100e3. It should be the master
clock rate of the e110 divided by an even number such as
64e6/256 (250e3).
- The quadrature rate in the WBFM receive block should be set
to samp_rate (250e3) and the Audio decimation should be set to 5.
- The audio sink sample rate should be set to
samp_rate/audio_decim (250e3/5=50e3). 50e3 is as close to the
wanted audio sample rate of 48e3 that you are going to get
without using one of the resampler blocks.
Mike
--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com mailto:m...@scanoo.com
Web: http://scanoo.com
-- Forwarded message --
From: *Abouda Yassine* abouda21yass...@gmail.com
mailto:abouda21yass...@gmail.com
Date: Wed, Apr 9, 2014 at 12:09 PM
Subject: Re: [Discuss-gnuradio] Problem with getting clear FM
signals using the usrp e110
To: Mike Jameson m...@scanoo.com mailto:m...@scanoo.com
hi Mike,
thx for offering help.I enclosed both a picture of the fm
receiver and the grc file(because i'm using the embedded
gnuradio version on the usrpe 110),so it might not open
correctly to you.I will be waiting for your answer.
2014-04-09 11:47 GMT+02:00 Mike Jameson m...@scanoo.com
mailto:m...@scanoo.com:
Abouda,
If you attach your GRC file to your reply I'll take a look
at it for you. It sounds like a sample rate mis-match
going on somewhere.
Mike
--
Mike Jameson M0MIK BSc
Re: [Discuss-gnuradio] New GRC behavior request for comment
On 04/10/2014 04:13 PM, Ed Criscuolo wrote: How hard would it be to pop up a bother box if you attempt to enter with outstanding parameter error(s). Give you a chance to confirm or cancel the enter, because you may want to deliberately enter something that's wrong now but will be fixed later (for instance a variable name that you haven't created yet). I certainly like the evaluate when you leave the box paradigm, but I'm also the kind of developer who will enter a variable name, etc, that hasn't actually been created yet. -- 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] Cannot find an item size
On 04/14/2014 05:50 PM, madengr wrote: Try taking out the throttle. That's only needed to limit the CPU when there is no hardware dictating the sample rate. Lou KD4HSO That's good advice in general. But in this case, it seems the very-latest UHD doesn't quite mesh properly with Gnu Radio, and if you set the wire format in a UHD source/sink to Automatic you get this error. Unfortunately, Automatic is the default, but as a workaround, you can set the wire format to Complex int16. embob wrote Ive got an USRP B100 which Im trying to get transmitting as a first step. Ive built the latest GNU Radio from source (using the buildgnuradio script from sbrac.org). Ive setup a flow diagram (see image) which modulates a cosine and outputs it to the USRP Sink. Without the USRP block, the script works fine and I see the FFT Sink moving. With the USRP Sink, I get the error: Ive had this error before in the day when I was first getting started but it told me the size of the type mismatch. This time theres less to go on. Can anyone point me in the right direction of finding out why its happening? -- View this message in context: http://gnuradio.4.n7.nabble.com/Cannot-find-an-item-size-tp47571p47574.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 -- 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] Reference Clock power level for Ettus N210
On 04/23/2014 09:07 AM, Antonio Petrolino wrote: Hi, I'm using a USRP N210 and I need a 10 MHz reference clock. From ettus.com I got: Ref Clock - 10 MHz Using an external 10 MHz reference clock, a square wave will offer the best phase noise performance, but a sinusoid is acceptable. The reference clock requires the following power level: USRP2 5 to 15 dBm N2XX 0 to 15 dBm So in my case (N210) I should have a minimum 0 dBm signal. Can someone confirm this information (N2XX 0 to 15 dBm) for N210? The bad news for me is I have a -15dBm 10 MHz available... Thank you, Antonio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Yup, the minimum is 0dBm. -- 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] Reference Clock power level for Ettus N210
On 04/23/2014 09:31 AM, Marcus Müller wrote: Hi, looking at the N200 schematics from files.ettus.com, I'd say: stick to the 0dBm, your clock signal has to pass a transformer and some safety/matching circuitry and still ought to be more accurate than the on-board VCTCXO; the clock multiplexer (http://www.micrel.com/index.php/en/products/clock-timing/clock-data-distribution/multiplexers/article/29-sy89545l.html) datasheet says it needs at least a voltage swing of 0.1V after that. I'm not very much of a circuits person, but I think you won't deteriorate much of your clock accuracy by using a clock buffer, which are quite inexpensive (if you need but one and are not afraid to solder... TI gives away samples for free). Then again, you're trying to achieve a better clock performance than the on-board 10MHz ref clock, so I guess you shouldn't start introducing cheap hardware in the clock signal path... Greetings, Marcus PS: maybe the usrp-us...@lists.ettus.com mailing list is better suited for this... I've added that to CC: I think the main thing to watch out for with clock buffers is their linearity, since low-level non-linearity effects can increase phase-noise. Perhaps not a lot, but a little. I'd use a clock buffer, and see. -- 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] X300 PCIe issues
On 04/27/2014 02:45 PM, Robert McGwier wrote: Backing off to Ubuntu 12.04.4 LTS was successful in getting the PCIe Express interface to build, dkms the kernel module, start and uhd_find_device sees the USRP x300. Now for the fun part using it. Finally: To all those entertaining PCIe interfacing, do not install a later version of kernel or distro than is KNOWN to support the interface. PCIe is most decidely NOT USB or GigE. Ettus would not be using a proprietary interface from NI with known working support for various kernels if it were not necessary. Having done multiple projects at work with PCIe, you use it when it is necessary and NEVER when it isn't. My application for the x3x0 series requires it. I find all the pieces of the needed documentation to make it all work NOT in one place. I will give a short summary today after I get my first app going using the device. Thanks, Bob I'll chime in as an occasional kernel and driver developer. Developing code, like drivers or kernel extensions, that runs inside the kernel is a *royal pain in the posterior* in Linux. While the top side API is very stable so that applications hardly *ever* experience API changes that require on-going tedious maintenance, the same cannot be said of code that runs in the kernel. Quite the contrary. Linus and friends *routinely and regularly* change critical APIs within the kernel, sometimes even across minor version revs of the same codebase. This makes maintaining drivers and other kernel code a complete and utter nightmare, and which is why often drivers are only guaranteed to work for specific kernel versions or kernel version series. It's serious challenge, and it's not a road that should be gone down lightly -- 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] X300 PCIe issues
On 04/27/2014 05:32 PM, Sylvain Munaut wrote: While the top side API is very stable so that applications hardly *ever* experience API changes that require on-going tedious maintenance, the same cannot be said of code that runs in the kernel. Quite the contrary. Linus and friends *routinely and regularly* change critical APIs within the kernel, sometimes even across minor version revs of the same codebase. Come on, it's not _that_ bad ... Kernel API are stable inside the maintenance release, so they can only change like every 2 month at most. And when they change, finding the relevant commit is pretty easy with git and it will show exactly what need to be changed in your driver (because that commit fixed every other driver in-tree for the same change). And searching LKML will also give all the gory details. It's like half a day or one day of work at the most. So 1 day of code maintenance every 2 month to keep your codebase current is not what I'd call a nightmare. And if you want to avoid even that, just get your module merged upstream, it will be adapted for you free of charge when APIs change. And wrt to maintaining the same code building for several kernel, that's just the wrong approach. Just maintain different version in different branches. When the code is well written, the driver specific part will be decoupled enough from the kernel api part that there will hardly be any conflicts. And when your driver core function doesn't change (and for the NI driver, it seems it hasn't changed it's functionality for a while AFAICT, just added new kernel support, but I could be wrong on that), then it's even easier to just release a new code for each new kernel. For only a few revisions appart, you might be ok with #ifdef, but if you're trying to go back to ancient times, like the NI module which seems to support 2.6.0 (that's 11 years ago ), yeah there is going to be some serious changes ... Cheers, Sylvain PS: and yeah, for 2 years or so, I maintained an in-house PCIe driver for a FPGA board, so I did experience that. So, would we accept an applications-layer API that changed roughly every two months? I would argue, no, we wouldn't. But people developing in kernel land seem to accept it as some kind of necessary gospel. I reject that notion. Just because kernel-land is where all the kewl kids play is not a good reason to break things on a regular basis. Anyway, this thread is now going fairly far afield -- 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] GR330 configure doesn't find usb.h
On 04/27/2014 06:56 PM, Michael Carter wrote: Hello all, I'm hoping someone can provide some insight to a build problem I'm seeing. I'm building 3.3.0 to use with an Ettus Research USRP1. I'm given to understand that I need to build 3.3.0 as that was the last release which is compatible with the usrp1. I've gone through the dependencies and have installed them. The priority for me is getting the usrp functionality and grc built. When I do a ./configure I get these results: Unless you have a pre-UHD application that cannot be updated, there's no reason to use this. The USRP1 is perfectly functional with modern Gnu Radios that use UHD as the interface. - The following GNU Radio components have been successfully configured: config gruel gnuradio-core gr-msdd6000 gr-audio-jack gr-audio-osx gr-audio-portaudio gr-atsc gr-cvsd-vocoder gr-gsm-fr-vocoder gr-noaa gr-pager gr-radio-astronomy gr-trellis gr-video-sdl gnuradio-examples docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell usrp usrp2 gr-usrp gr-usrp2 gr-gcell gr-audio-alsa gr-audio-oss gr-audio-windows gr-comedi gr-gpio gr-radar-mono gr-wxgui gr-qtgui gr-sounder gr-utils grc These components will not be built. - In the build log, I see that usb.h is not found/usable (line 337 in the pastebin listed later): checking for usb.h... no USRP requires libusb header 'usb.h' which was not found or was not usable. See http://www.libusb.org Unable to find dependency libusb. Libusb was installed when I installed uhd-devel @3.7.1 via port. I've also built and installed from libusb.org's 1.0 source. port installed | grep usb libusb @1.0.18_0 (active) uhd-devel @3.7.0_20140325_0+docs+examples+libusb+manual+orc+python27+test uhd-devel @3.7.1_20140421_0+docs+examples+libusb+manual+orc+python27+test (active) mikec-macbook-pro:gnuradio-3.3.0 mikec$ cd /usr/local/include/ mikec-macbook-pro:include mikec$ ls -l usb* -rw-rw-r--+ 1 root wheel 8360 Sep 10 2009 usb.h -rw-rw-r--+ 1 root wheel 24428 Sep 10 2009 usbpp.h mikec-macbook-pro:include mikec$ cd ../lib mikec-macbook-pro:lib mikec$ ls -l libusb* -rwxrwxr-x+ 1 root wheel 140248 Sep 10 2009 libusb-0.1.4.dylib -rwxr-xr-x 1 root wheel 103760 Apr 27 14:59 libusb-1.0.0.dylib -rw-r--r-- 1 root wheel 366200 Apr 27 14:59 libusb-1.0.a lrwxr-xr-x 1 root wheel 18 Apr 27 14:59 libusb-1.0.dylib - libusb-1.0.0.dylib -rwxr-xr-x 1 root wheel 935 Apr 27 14:59 libusb-1.0.la -rw-rw-r--+ 1 root wheel 167156 Sep 10 2009 libusb.a -rwxrwxr-x+ 1 root wheel 914 Sep 10 2009 libusb.la -rwxrwxr-x+ 1 root wheel 270248 Sep 10 2009 libusbpp-0.1.4.dylib -rw-rw-r--+ 1 root wheel 340380 Sep 10 2009 libusbpp.a -rwxrwxr-x+ 1 root wheel 951 Sep 10 2009 libusbpp.la Generally, /usr/local/include and /usr/local/lib are default locations, but i've even set LDFLAGS=-L/usr/local/lib and CPPFLAGS=-I/usr/local/include just in case. I still get the same results. Any input would be appreciated. The entire build log is on pastebin at: http://pastebin.com/FubyMRAt Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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] GR330 configure doesn't find usb.h
On 04/27/2014 10:14 PM, Michael Carter wrote: Thanks Marcus. This is for OpenBTS 2.8, which based on the myriad lists I've been researching, is a pre-UHD application. Anyone have any insight the issue? Thanks, #mikec OpenBTS doesn't actually use Gnu Radio, just some of the driver code for USRP1 that came along for the ride with early Gnu Radio releases. Getting that code to build on a newer Linux distrib may be a challenge. On Apr 27, 2014, at 4:00 PM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 04/27/2014 06:56 PM, Michael Carter wrote: Hello all, I'm hoping someone can provide some insight to a build problem I'm seeing. I'm building 3.3.0 to use with an Ettus Research USRP1. I'm given to understand that I need to build 3.3.0 as that was the last release which is compatible with the usrp1. I've gone through the dependencies and have installed them. The priority for me is getting the usrp functionality and grc built. When I do a ./configure I get these results: Unless you have a pre-UHD application that cannot be updated, there's no reason to use this. The USRP1 is perfectly functional with modern Gnu Radios that use UHD as the interface. - The following GNU Radio components have been successfully configured: config gruel gnuradio-core gr-msdd6000 gr-audio-jack gr-audio-osx gr-audio-portaudio gr-atsc gr-cvsd-vocoder gr-gsm-fr-vocoder gr-noaa gr-pager gr-radio-astronomy gr-trellis gr-video-sdl gnuradio-examples docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell usrp usrp2 gr-usrp gr-usrp2 gr-gcell gr-audio-alsa gr-audio-oss gr-audio-windows gr-comedi gr-gpio gr-radar-mono gr-wxgui gr-qtgui gr-sounder gr-utils grc These components will not be built. - In the build log, I see that usb.h is not found/usable (line 337 in the pastebin listed later): checking for usb.h... no USRP requires libusb header 'usb.h' which was not found or was not usable. Seehttp://www.libusb.org Unable to find dependency libusb. Libusb was installed when I installed uhd-devel @3.7.1 via port. I've also built and installed fromlibusb.org http://libusb.org's 1.0 source. port installed | grep usb libusb @1.0.18_0 (active) uhd-devel @3.7.0_20140325_0+docs+examples+libusb+manual+orc+python27+test uhd-devel @3.7.1_20140421_0+docs+examples+libusb+manual+orc+python27+test (active) mikec-macbook-pro:gnuradio-3.3.0 mikec$ cd /usr/local/include/ mikec-macbook-pro:include mikec$ ls -l usb* -rw-rw-r--+ 1 root wheel 8360 Sep 10 2009 usb.h -rw-rw-r--+ 1 root wheel 24428 Sep 10 2009 usbpp.h mikec-macbook-pro:include mikec$ cd ../lib mikec-macbook-pro:lib mikec$ ls -l libusb* -rwxrwxr-x+ 1 root wheel 140248 Sep 10 2009 libusb-0.1.4.dylib -rwxr-xr-x 1 root wheel 103760 Apr 27 14:59 libusb-1.0.0.dylib -rw-r--r-- 1 root wheel 366200 Apr 27 14:59 libusb-1.0.a lrwxr-xr-x 1 root wheel 18 Apr 27 14:59 libusb-1.0.dylib - libusb-1.0.0.dylib -rwxr-xr-x 1 root wheel 935 Apr 27 14:59 libusb-1.0.la -rw-rw-r--+ 1 root wheel 167156 Sep 10 2009 libusb.a -rwxrwxr-x+ 1 root wheel 914 Sep 10 2009 libusb.la -rwxrwxr-x+ 1 root wheel 270248 Sep 10 2009 libusbpp-0.1.4.dylib -rw-rw-r--+ 1 root wheel 340380 Sep 10 2009 libusbpp.a -rwxrwxr-x+ 1 root wheel 951 Sep 10 2009 libusbpp.la Generally, /usr/local/include and /usr/local/lib are default locations, but i've even set LDFLAGS=-L/usr/local/lib and CPPFLAGS=-I/usr/local/include just in case. I still get the same results. Any input would be appreciated. The entire build log is on pastebin at:http://pastebin.com/FubyMRAt Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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
Re: [Discuss-gnuradio] GR330 configure doesn't find usb.h
On 04/27/2014 10:31 PM, Michael Carter wrote: Hi Marcus. Thanks, yes that seems to be bearing itself out so far. I'm fairly certain that if I can get the code that came along for the ride installed, then I'll be set. So the issue is still why the makefiles don't detect usb.h and libusb even though they're installed. Is there a trick I need to use to let the configure script know that it's there? thanks. On a modern distro, libusb is likely to be libusb-1 series, whereas this stuff was originally written for libusb-0.12 or something like that. Gnu Radio itself moved on to using CMake quite a long time ago, so there is decreasing community memory about how those autotool configure scripts worked ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] configuration incomplete , errors occur !
On 05/03/2014 12:21 AM, Sara Chérif wrote: I am installing GNU radio using this command wget http://www.sbrac.org/files/build-gnuradio chmod a+x ./build-gnuradio ./build-gnuradio --verbose But I found at the end of the installation an error (after 2 hours from beginning of installation during building of extra modules ) Building extra module grextras -- The CXX compiler identification is GNU -- The C compiler identification is GNU -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Build type not specified: defaulting to release. -- Boost version: 1.48.0 -- checking for module 'volk' -- found volk, version 0.1 -- Found VOLK: /usr/local/lib/libvolk.so -- checking for module 'gruel' -- package 'gruel' not found -- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS) -- checking for module 'gnuradio-core' -- package 'gnuradio-core' not found -- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES GNURADIO_CORE_INCLUDE_DIRS) CMake Error at CMakeLists.txt:112 (message): Gruel required to compile extras -- Configuring incomplete, errors occurred! make: *** No targets specified and no makefile found. Stop. make: *** No rule to make target `install'. Stop. Done function extras at: Sat May 3 06:02:03 EET 2014 Starting function mod_groups at: Sat May 3 06:02:03 EET 2014 make: *** No targets specified and no makefile found. Stop. make: *** No rule to make target `install'. Stop. Done function extras at: Sat May 3 06:02:03 EET 2014 Also when I run then GNURADIO in terminal , I got this line: XML parser: Found 1 erroneous XML file while loading the block tree (see Help/Parser errors for details) sara@sara-Inspiron-N5010:~$ gnuradio-companion Warning: Block key blocks_ctrlport_monitor_performance not found when loading category tree. Warning: Block key blocks_ctrlport_monitor_performance not found when loading category tree. linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.001-14-g1d2e8d39 Welcome to GNU Radio Companion 3.7.3 XML parser: Found 1 erroneous XML file while loading the block tree (see Help/Parser errors for details) Showing: --- Is there a big problem in installation , Do I have to reinstall?! I don't know why these errors occur!! Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The gr-extras code hasn't been updated for GR3.7, and so, won't build under 3.7. But it's not a critical subsystem, so its failure to build won't cause the rest of the build to fail. The errors about blocks_ctrlport_monitor are normal, in that they are showing up because the XML for them is included even when the underlying subsystem code doesn't get built (which it won't unless you have all the pre-requisites required for ctrlport already installed). -- 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] uhd_find_devices cannot find my B210
On 05/05/2014 01:52 PM, Greg Hulands wrote:
Hi,
I received my B210 this morning and when I run uhd_find_devices, it say it
can't find any devices.
$ uhd_find_devices
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.003-0-unknown
No UHD Devices Found
lsusb shows the device, but the product id is different to what is in
/lib/udev/rules.d/40-uhd-host.rules
Bus 003 Device 006: ID 2500:0020
So I added a line to the rules file
SUBSYSTEMS==usb, ATTRS{idVendor}==2500, ATTRS{idProduct}==0020, GROUP:=usrp,
MODE:=0660
I reloaded udev, unplugged and replugged in the device, but still
uhd_find_devices can't locate it.
I have the B210 plugged into a Via VL800 USB 3.0 card. lspci identifies it as
Device 3483 (rev 01).
What step am i missing?
Thanks,
Greg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
You need to most recent version of UHD. Support for B210 was introduced
at 3.5.4 of UHD, and if you're going to upgrade, you should upgrade to
the latest.
--
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] uhd_find_devices cannot find my B210
On 05/05/2014 02:13 PM, Greg Hulands wrote: I added the Ettus repo and installed 003.007.001 and yet when I run the uhd_find_devices command it shows the 003.005.003 version. Do you recommend building from source? Thanks, Greg I recommend erasing your installed-from-standard-repos instances of uhd and gnuradio *before* installing the Ettus stuff. sudo apt-get purge uhd uhd-host sudo apt-get purge gnuradio And *then* re-do the install-from-Ettus-repos. -- 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] Getting this today from recent GR master build:
Traceback (most recent call last): File /home/mleech/top_block.py, line 74, in module tb = top_block() File /home/mleech/top_block.py, line 39, in __init__ channels=range(1), File /usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py, line 122, in constructor_interceptor return old_constructor(*args) File /usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py, line 1747, in make return _uhd_swig.usrp_source_make(*args) NotImplementedError: Wrong number or type of arguments for overloaded function 'usrp_source_make'. Possible C/C++ prototypes are: make(::uhd::device_addr_t const ,::uhd::io_type_t const ,size_t) gr::uhd::usrp_source::make(::uhd::device_addr_t const ,::uhd::stream_args_t const ) gnuradio-config-info returns: v3.7.4git-183-g967489ad linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_003.007.001-14-g1d2e8d39 -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... _ / | Device: USRP1 Device | _ |/ | | Mboard: USRP1 | | serial: SRL__269 | | name: old-usrp1 | | | | Time sources: none | | Clock sources: internal | | Sensors: | | _ | |/ | | | RX DSP: 0 | | | Freq range: -32.000 to 32.000 Mhz | | _ | |/ | | | RX DSP: 1 | | | Freq range: -32.000 to 32.000 Mhz | | _ | |/ | | | RX Dboard: A | | | ID: DBSRX (0x0002) | | | _ | | |/ | | | | RX Frontend: 0 | | | | Name: DBSRX | | | | Antennas: J3 | | | | Sensors: lo_locked | | | | Freq range: 800.000 to 2400.000 Mhz | | | | Gain range GC1: 0.0 to 56.0 step 0.5 dB | | | | Gain range GC2: 0.0 to 24.0 step 1.0 dB | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: A | | | | Name: ad9522 | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | RX Dboard: B | | | ID: DBSRX (0x0002) | | | _ | | |/ | | | | RX Frontend: 0 | | | | Name: DBSRX | | | | Antennas: J3 | | | | Sensors: lo_locked | | | | Freq range: 800.000 to 2400.000 Mhz | | | | Gain range GC1: 0.0 to 56.0 step 0.5 dB | | | | Gain range GC2: 0.0 to 24.0 step 1.0 dB | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: B | | | | Name: ad9522 | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | TX DSP: 0 | | | Freq range: -44.000 to 44.000 Mhz | | _ | |/ | | | TX DSP: 1 | | | Freq range: -44.000 to 44.000 Mhz | | _ | |/ | | | TX Dboard: A | | | _ | | |/ | | | | TX Frontend: 0 | | | | Name: Unknown (0x) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 Mhz | | | | Gain Elements: None | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Codec: A | | | | Name: ad9522 | | | | Gain range pga: -20.0 to 0.0 step 0.1 dB | | _ | |/ | | | TX Dboard: B | | | _ | | |/ | | | | TX Frontend: 0 | | | | Name: Unknown (0x) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 Mhz | | | | Gain Elements: None | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Codec: B | | | | Name: ad9522 | | | | Gain range pga: -20.0 to 0.0 step 0.1 dB And if I use an osmocom block (such as provided by osmocom-fft) it works just fine, so I suspect this is an issue in gr-uhd. -- Marcus Leech Principal Investigator Shirleys
Re: [Discuss-gnuradio] Signal drought
On 05/05/2014 07:52 PM, Greg Hulands wrote: Hi, I built all the code today using the build-gnuradio script and when I create a simple GRC flow graph going from the USRP source to the waterfall plot, I get no data coming in. I then built gqrx and ran it and it too doesn’t get any data in from the device to display on its waterfall. I ran the rx_samples_to_file example and captured some data, but when looking at it in a hex editor, it doesn’t look like it captured anything in particular (http://test.utr-software.com/sdr/rxdump.dat). I ran it with ./rx_samples_to_file —freq=10770 —rate=100 —file=~/rxdump.dat. I am new to gnu radio and sdr so I’m not yet sure how to dig in to debug these issues. Anything help is greatly appreciated. Thanks, Greg How about something really, really simple: uhd_fft -a type=b200 -f 107.7e6 -s 1.0e6 -g 40 --fft-rate 8 --averaging -- 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] Signal drought
It just looks like noise. Well, noise isn't the same as no signal at all. Do you *expect* there to a signal at 107.7MHz? Do you have an antenna plugged in to the correct port on the device? On May 5, 2014, at 4:59 PM, Marcus D. Leechmle...@ripnet.com wrote: On 05/05/2014 07:52 PM, Greg Hulands wrote: Hi, I built all the code today using the build-gnuradio script and when I create a simple GRC flow graph going from the USRP source to the waterfall plot, I get no data coming in. I then built gqrx and ran it and it too doesn’t get any data in from the device to display on its waterfall. I ran the rx_samples_to_file example and captured some data, but when looking at it in a hex editor, it doesn’t look like it captured anything in particular (http://test.utr-software.com/sdr/rxdump.dat). I ran it with ./rx_samples_to_file —freq=10770 —rate=100 —file=~/rxdump.dat. I am new to gnu radio and sdr so I’m not yet sure how to dig in to debug these issues. Anything help is greatly appreciated. Thanks, Greg How about something really, really simple: uhd_fft -a type=b200 -f 107.7e6 -s 1.0e6 -g 40 --fft-rate 8 --averaging -- 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 -- 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] Signal drought
I changed antenna’s and I see a signal now in uhd_fft. I just noticed that when in GRC and I run the flow graph, i don’t see the RX light come on the board like when running uhd_fft. I have put the grc file up here http://test.utr-software.com/sdr/test.grc Thanks, Greg The default antenna port if you don't specify one is always TX/RX -- because you might be wanting to do half-duplex. You can explicitly specify the RX2 antenna port in the GRC source block, or just remember that unspecified means, typically, TX/RX. On May 5, 2014, at 5:03 PM, Greg Hulandsghula...@me.com wrote: It just looks like noise. On May 5, 2014, at 4:59 PM, Marcus D. Leechmle...@ripnet.com wrote: On 05/05/2014 07:52 PM, Greg Hulands wrote: Hi, I built all the code today using the build-gnuradio script and when I create a simple GRC flow graph going from the USRP source to the waterfall plot, I get no data coming in. I then built gqrx and ran it and it too doesn’t get any data in from the device to display on its waterfall. I ran the rx_samples_to_file example and captured some data, but when looking at it in a hex editor, it doesn’t look like it captured anything in particular (http://test.utr-software.com/sdr/rxdump.dat). I ran it with ./rx_samples_to_file —freq=10770 —rate=100 —file=~/rxdump.dat. I am new to gnu radio and sdr so I’m not yet sure how to dig in to debug these issues. Anything help is greatly appreciated. Thanks, Greg How about something really, really simple: uhd_fft -a type=b200 -f 107.7e6 -s 1.0e6 -g 40 --fft-rate 8 --averaging -- 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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] Signal drought
I changed to RX2 and still not activating the receiver on the board. Try changing the Wire Format to complex-int16 On May 5, 2014, at 5:44 PM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: I changed antenna’s and I see a signal now in uhd_fft. I just noticed that when in GRC and I run the flow graph, i don’t see the RX light come on the board like when running uhd_fft. I have put the grc file up herehttp://test.utr-software.com/sdr/test.grc Thanks, Greg The default antenna port if you don't specify one is always TX/RX -- because you might be wanting to do half-duplex. You can explicitly specify the RX2 antenna port in the GRC source block, or just remember that unspecified means, typically, TX/RX. On May 5, 2014, at 5:03 PM, Greg Hulandsghula...@me.com mailto:ghula...@me.com wrote: It just looks like noise. On May 5, 2014, at 4:59 PM, Marcus D. Leechmle...@ripnet.com mailto:mle...@ripnet.com wrote: On 05/05/2014 07:52 PM, Greg Hulands wrote: Hi, I built all the code today using the build-gnuradio script and when I create a simple GRC flow graph going from the USRP source to the waterfall plot, I get no data coming in. I then built gqrx and ran it and it too doesn’t get any data in from the device to display on its waterfall. I ran the rx_samples_to_file example and captured some data, but when looking at it in a hex editor, it doesn’t look like it captured anything in particular (http://test.utr-software.com/sdr/rxdump.dat). I ran it with ./rx_samples_to_file —freq=10770 —rate=100 —file=~/rxdump.dat. I am new to gnu radio and sdr so I’m not yet sure how to dig in to debug these issues. Anything help is greatly appreciated. Thanks, Greg How about something really, really simple: uhd_fft -a type=b200 -f 107.7e6 -s 1.0e6 -g 40 --fft-rate 8 --averaging -- 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 mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org http://www.sbrac.org/ -- 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] Signal drought
On 05/05/2014 09:11 PM, Greg Hulands wrote: Still no go. :-( I have also added device adde = name,serial=F4,type=b200,uhd and Mb0: Subdev Spec = A:A A:B both still having no effect. Thanks, Greg Just use a subdev spec of A:A Are you getting any error messages when you run the graph? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-uhd GR3.7.X on Fedora 14
Anyone else out there successfully using gr-uhd blocks successfully on a Fedora 14 system? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] USRP B210 error
On 05/10/2014 05:22 AM, asad umer via USRP-users wrote: Hi all, I am using B21o and simply RXing a signal and observing it in FFT sink block...The parameters set for UHD USRP source block are as shown in the screenshot...When i execute the flow graph i get the following error: thread[thread-per-block[0]: block gr uhd usrp source (24)]: LookupError: KeyError: Cannot find an item size: Can anybody help me ou heret?? ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com This properly belongs in discuss-gnuradio, since this is a Gnu Radio issue. There was a bug in gr-uhd that caused this. The workaround in your version is to manually select the wire-format as sc16 -- 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] Time delaying a signal
On 05/12/2014 02:02 PM, asad umer wrote: I want to introduce a time delay in a signal received through USRP...I have used the 'Delay' block but it is not showing any delay...what is the appropriate block to use?? Can i delay the phase instead? Are time and phase delay equal? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The delay block is in samples. -- 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] Time delaying a signal
On 05/12/2014 02:14 PM, asad umer wrote: so there is no exclusive block for this purpose in GRC?? A delay in samples is a delay in time: 1 sample == 1/sample-rate seconds of delay -- 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] Time delaying a signal
On 05/12/2014 02:19 PM, Marcus Müller wrote: Well, not that I'm aware of. However, FFT, multiplication with a signal source, IFFT is not really hard to do, and it's what a time shift mathematically is. Greetings, Marcus Also, a phase-shift is just a complex multiply by: complex(cos(ang),sin(ang)) With angle in radians That's how I do manual phase correction in the interferometer support in simple_ra -- 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] Merge multiple complex streams
On 05/13/2014 03:02 PM, Imre wrote: (Something went wrong with my mails, hopefully doing it right now, sorry Mike, replied directly to you) Using Mike's example and some fiddling around: http://www.livep2000.nl/code/grc/multichannel_input.grc Tuning on a FM channel shows the mentioned mess, interconnect the hardware clock? Maybe like this: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg00387.html I'am give the polyphase synthesizer a look -- View this message in context: http://gnuradio.4.n7.nabble.com/Merge-multiple-complex-streams-tp48146p48191.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 All you channels will not only need to be phase-coherent, but also have zero phase offset. That's the only way you can reasonably simulate having much wider bandwidth by gluing together a bunch of smaller bandwidths. My own experiments with the RTLSDR gear is that achieving phase coherence across significant bandwidth appears to not be possible, even with a common, high-quality master clock. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] B200 clock calibration
On 05/14/2014 11:44 AM, Tom Tsou wrote: On Wed, May 14, 2014 at 6:16 AM, Martin Braunmartin.br...@ettus.com wrote: On 14.05.2014 12:12, Robert Light wrote: UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 0.270833 MSps Actual sample rate: 0.271186 MSps Robert, as long as you see this warning, you'll get offsets. I don't know where or how kal sets up the master clock, but you should put in a master_clock_rate=13e6 somewhere in there. In this particular case, it's actually not very important. Kal is basically performing a tone search and the sample rate used for internal calculations is the rate returned by UHD. The sample rate can be almost any value. 2 kHz offset is within tolerance for 1900 MHz. Locking to a stable 10 MHz reference, generally an OCXO or GPSDO, is the recommended approach. -TT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The on-board clock on the B200 is good to about 2PPM, so 2kHz in 1900Mhz is just about right. -- 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] B200 clock calibration
On 05/14/2014 01:12 PM, Robert Light wrote: 2 kHz offset is within tolerance for 1900 MHz. Locking to a stable 10 MHz reference, generally an OCXO or GPSDO, is the recommended approach. I applied external 10MHz reference, the best I had at hand. Now kalibrate says I have about 200Hz offset at 900MHz and 420Hz at 1800MHz, but phones still do not want to register to OpenBTS. A few phones that did not see the network before, are now seeing the network. They see the network, but they say no access when I try to register. I configured OpenBTS to allow everything to register with no restrictions. The same computer was working with B100 a few weeks ago without any problems. I now have a few B200 but none of them works. They all behave the same way. Is there a point in going for a more accurate clock ? I am already below 500Hz at 1900MHz. Did anyone get OpenBTS working on B200 ? In the log I see regular Sample buffer: Overrun. Can I do anything about it? There is no sign in OpenBTS log that a phone is trying to register. May 14 13:33:29 lenovo-Edge transceiver: ERR 139674597304064 13:33:29.0 UHDDevice.cpp:780:readSamples: Sample buffer: Overrun May 14 13:33:30 lenovo-Edge transceiver: ERR 139674597304064 13:33:30.9 UHDDevice.cpp:780:readSamples: Sample buffer: Overrun May 14 13:34:29 lenovo-Edge transceiver: ERR 139674597304064 13:34:29.0 UHDDevice.cpp:780:readSamples: Sample buffer: Overrun May 14 13:35:29 lenovo-Edge transceiver: ERR 139674597304064 13:35:29.0 UHDDevice.cpp:780:readSamples: Sample buffer: Overrun May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251016960 14:42:40.0 UHDDevice.cpp:737:readSamples: Requested timestamp = 792.358 May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251049728 14:42:40.0 Transceiver.cpp:774:driveTransmitFIFO: radio clock 5:1319506 May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251016960 14:42:40.0 Transceiver.cpp:358:pullRadioVector: looking for TSC at time: 1:1319505 May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251016960 14:42:40.0 Transceiver.cpp:358:pullRadioVector: looking for TSC at time: 2:1319505 May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251016960 14:42:40.0 Transceiver.cpp:358:pullRadioVector: looking for TSC at time: 3:1319505 May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251016960 14:42:40.0 UHDDevice.cpp:737:readSamples: Requested timestamp = 792.36 May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251049728 14:42:40.0 Transceiver.cpp:774:driveTransmitFIFO: radio clock 7:1319506 May 14 14:42:40 transceiver: last message repeated 2 times May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251016960 14:42:40.0 UHDDevice.cpp:772:readSamples: Received timestamp = 792.357 May 14 14:42:40 lenovo-Edge transceiver: DEBUG 140528251016960 14:42:40.0 Transceiver.cpp:358:pullRadioVector: looking for TSC at time: 4:1319505 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio At this point, this is very-likely a question for the OpenBTS forums, not here. -- 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] aUaU FM receiver
On 05/16/2014 10:59 AM, Pablo Fernández Alonso wrote: Hi, I built a FM receiver working with a LiveUSB and a USRPB100 device. It worked fine, but when I installed Ubuntu and GNURadio in a virtual machine, the audio is distorted. The console types 'aU' letters. But I generate a wav file and the quality is good, the problem is with the audio sink. Regards, Pablo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio USB and Audio performance in VMs is highly variable and unpredictable. Sometimes it's fine, sometimes it's really poor. -- 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] MSF/DCF/RBU Time Station Receiver Implementation
On 05/16/2014 01:29 PM, Iain Young, G7III wrote: I'm not actually sure what advantages if any the Goertzel has over a narrow-band FIR, although there is a post in the archive from Marcus suggesting 15% CPU. With the advances in VOLK, it would be useful to try the benchmarks again to see which approach is best. -- 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] receive sensitivity of B200
On 05/18/2014 05:49 PM, Robert Light wrote: Hi, I use B200 with OpenBTS at 900MHz. I get very low range (about 10m only) and I identified that this is due to receive channel in B200. Changing rxgain between 0 and 70dB makes vey little difference. Does anyone know how the receive sensitivity of B200 compare with, for example, WBX? What could be the reason for this low sensitivity? uhd_fft spectrum looks normal , in the sense that I do not suspect a broken LNA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Are you on the correct antenna port? The B2xx RF section is roughly the same noise figure and total gain as a WBX. -- 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] using uhd_fft with USRP N210
On 05/20/2014 12:07 AM, tides anugraha wrote: Hi, I,m trying to run uhd_fft with USRP N210, my machine run Ubuntu 12.04.4 LTS. I've already install UHD, gnuradio, OpenBTS in my machine works fine. But when i try to run uhd_fft which is in /var/opt/gnuradio-3.7.0/gr-uhd/apps directory, i've got the following message: root@OpenBTS:/var/opt/gnuradio-3.7.0/gr-uhd/apps# ./uhd_fft Traceback (most recent call last): File ./uhd_fft, line 23, in module from gnuradio import gr, gru ImportError: No module named gnuradio I've already try to run make make install command in /var/opt/gnuradio-3.7.0/build/gr-uhd directory, as suggested in previous discussion, but it still show the same result. Can anyone help to solve this issue. Thanks, Tides ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I'm going to guess that it's because your PYTHONPATH doesn't point at wherever your installer put the various Python modules that Gnu Radio needs. It's really weird to install permanent libraries and executables under /var/opt. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using uhd_fft with USRP N210
On 05/20/2014 12:42 AM, tides anugraha wrote: Any suggestions or reference maybe? where should i install the install permanent libraries and executables? Thanks Well, /usr/local is the most usual place for Ubuntu. Sometimes under /opt. On Tue, May 20, 2014 at 11:18 AM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 05/20/2014 12:07 AM, tides anugraha wrote: Hi, I,m trying to run uhd_fft with USRP N210, my machine run Ubuntu 12.04.4 LTS. I've already install UHD, gnuradio, OpenBTS in my machine works fine. But when i try to run uhd_fft which is in /var/opt/gnuradio-3.7.0/gr-uhd/apps directory, i've got the following message: root@OpenBTS:/var/opt/gnuradio-3.7.0/gr-uhd/apps# mailto:root@OpenBTS:/var/opt/gnuradio-3.7.0/gr-uhd/apps# ./uhd_fft Traceback (most recent call last): File ./uhd_fft, line 23, in module from gnuradio import gr, gru ImportError: No module named gnuradio I've already try to run make make install command in /var/opt/gnuradio-3.7.0/build/gr-uhd directory, as suggested in previous discussion, but it still show the same result. Can anyone help to solve this issue. Thanks, Tides ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I'm going to guess that it's because your PYTHONPATH doesn't point at wherever your installer put the various Python modules that Gnu Radio needs. It's really weird to install permanent libraries and executables under /var/opt. ___ 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
Re: [Discuss-gnuradio] How to set a master clock rate on USRP B200
On 05/23/2014 12:23 PM, raf raf wrote: Hello All Gnu Radio user, To use a 2 TX, I want to change a clock rate to an accepted one, under 30.72 MHz. I use the API with uhd_usrp_probe and it works only for this command. Can you give me the idea or python code to use this argument parameter with a python flowgraph? --args=master_clock_rate=28 Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio In GRC, where it has a device args parameter, that's wher this master_clock_rate=28e6 should go. I assume you meant 28e6, rather than 28. Everything is in Hz, and there's no way the B200 can go down to a clock rate of 28Hz. -- 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] Window-close not killing everything
I have a user of simple_ra that has an issue with pieces of it still running after they use the window close button. In particular, there's an XMLRPC server thread that gets left behind. On my own, Fedora 14, system here, it's not a problem. Window close kills everything. On his Ubuntu 12.04 system, it seems to kill off most of it, but there's this dangler that is holding the XMLRPC socket. If I bind a close button to a function that issue a signal-to-self, what signal should that be? SIGHUP? -- 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] Some guidance on working through Core concepts of GNU Radio
On 05/25/2014 09:39 PM, Shane MacPhillamy wrote: I’m working through http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsCoreConcepts I’ve created the flow graph: I’m unsure on how to address the problem reported on Complex to Mag^2 as below, could you offer some pointers please? Connection ( Block - blocks_complex_to_mag_squared_0 - Complex to Mag^2(blocks_complex_to_mag_squared) Source - out(0) Block - blocks_file_sink_0 - File Sink(blocks_file_sink) Sink - in(0) ): Source IO size 4096 does not match sink IO size 8192”. Thanks. Cheers, Shane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio complex-to-mag**2 produces a *real* float output, and you're configuring your sink (or left it defaulted) to float-complex. GRC will have turned the arrow *red* to emphasize that the output type of one block doesn't match the input type of another, further, under the errors dialog, it would have noted the same thing. -- 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] How to set a master clock rate on USRP B200
On 05/25/2014 11:39 PM, jason sam wrote: device args parameter is not in the UHD USRP source/sink block?There is only 'Device addr' Sorry, I meant Device Addr On Fri, May 23, 2014 at 9:39 PM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 05/23/2014 12:23 PM, raf raf wrote: Hello All Gnu Radio user, To use a 2 TX, I want to change a clock rate to an accepted one, under 30.72 MHz. I use the API with uhd_usrp_probe and it works only for this command. Can you give me the idea or python code to use this argument parameter with a python flowgraph? --args=master_clock_rate=28 Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio In GRC, where it has a device args parameter, that's wher this master_clock_rate=28e6 should go. I assume you meant 28e6, rather than 28. Everything is in Hz, and there's no way the B200 can go down to a clock rate of 28Hz. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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] Muthaspewka!
git clone --progress http://gnuradio.org/git/gnuradio.git Cloning into gnuradio... error: Unable to get pack file http://gnuradio.org/git/gnuradio.git/objects/pack/pack-f226f3ea8e0b1778c849c7ac2c27532d22f0fefd.pack transfer closed with 88647 bytes remaining to read error: Unable to find 404ce04347b132e963564099f18345c19e2685c6 under http://gnuradio.org/git/gnuradio.git Cannot obtain needed blob 404ce04347b132e963564099f18345c19e2685c6 while processing commit 69dcaa75b629af4ebc465a073f54af84b7c75a11. error: Fetch failed. -- 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] Git cloned, errors in Portaudio during cmake
On 05/26/2014 07:07 PM, Johnathan Corgan wrote: On 05/26/2014 03:57 PM, Marcus D. Leech wrote: transfer closed with 88647 bytes remaining to read error: Unable to find 404ce04347b132e963564099f18345c19e2685c6 under http://gnuradio.org/git/gnuradio.git Cannot obtain needed blob 404ce04347b132e963564099f18345c19e2685c6 while processing commit 69dcaa75b629af4ebc465a073f54af84b7c75a11. error: Fetch failed. I just tried this, it worked. It could be an intermittent CloudFlare problem, as that transfer closed would have been when your system was connected to them, not gnuradio.org. Yup, came back up. But then, cmake fails tonight on my system, in an area it has never failed before: -- checking for module 'portaudio-2.0' -- found portaudio-2.0, version 19 CMake Error at cmake/Modules/FindPortaudio.cmake:37 (include): include could not find load file: CMakePushCheckState Call Stack (most recent call first): gr-audio/lib/CMakeLists.txt:135 (find_package) CMake Error at cmake/Modules/FindPortaudio.cmake:38 (cmake_push_check_state): Unknown CMake command cmake_push_check_state. Call Stack (most recent call first): gr-audio/lib/CMakeLists.txt:135 (find_package) -- Configuring incomplete, errors occurred! -- 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] Git cloned, errors in Portaudio during cmake
On 05/26/2014 08:40 PM, Sid Boyce wrote: Check if portaudio19-dev installed. root@sdrbox:~# dpkg -l|grep portaudio ii libportaudio2:amd64 19+svn20140130-1 amd64Portable audio I/O - shared library ii libportaudiocpp0:amd64 19+svn20140130-1 amd64Portable audio I/O C++ bindings - shared library ii portaudio19-dev 19+svn20140130-1 amd64Portable audio I/O - development files 73 ... Sid. [mleech@marcus2 ~]$ rpm -qa |grep portaudio portaudio-19-11.fc14.x86_64 portaudio-devel-19-11.fc14.x86_64 -- 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] Git cloned, errors in Portaudio during cmake
On 05/26/2014 09:56 PM, Sid Boyce wrote: On 27/05/14 02:01, Marcus D. Leech wrote: On 05/26/2014 08:40 PM, Sid Boyce wrote: Check if portaudio19-dev installed. root@sdrbox:~# dpkg -l|grep portaudio ii libportaudio2:amd64 19+svn20140130-1 amd64Portable audio I/O - shared library ii libportaudiocpp0:amd64 19+svn20140130-1 amd64Portable audio I/O C++ bindings - shared library ii portaudio19-dev 19+svn20140130-1 amd64Portable audio I/O - development files 73 ... Sid. [mleech@marcus2 ~]$ rpm -qa |grep portaudio portaudio-19-11.fc14.x86_64 portaudio-devel-19-11.fc14.x86_64 OK, it's Fedora. slipstream:/usr/src/gnuradio # ls -l cmake/Modules/FindPortaudio.cmake -rw-r--r-- 1 lancelot users 786 May 3 2012 cmake/Modules/FindPortaudio.cmake In the gnuradio/build directory run ccmake .. t to toggle advanced mode. Scroll down to the lines PORTAUDIO_INCLUDE_DIRS PORTAUDIO_LIBRARIES Hit Enter and type /usr/include (Enter) Scroll down to the PORTAUDIO_LIBRARIES line and hit Enter Type where libportaudio.so lives, e.g /usr/lib64/libportaudio.so and hit Enter. Type c to configure. Then g to generate. Then cmake .. 73 ... Sid. That yields the same results. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Git cloned, errors in Portaudio during cmake
On 05/26/2014 10:24 PM, Sid Boyce wrote: On 27/05/14 02:01, Marcus D. Leech wrote: On 05/26/2014 08:40 PM, Sid Boyce wrote: Check if portaudio19-dev installed. root@sdrbox:~# dpkg -l|grep portaudio ii libportaudio2:amd64 19+svn20140130-1 amd64Portable audio I/O - shared library ii libportaudiocpp0:amd64 19+svn20140130-1 amd64Portable audio I/O C++ bindings - shared library ii portaudio19-dev 19+svn20140130-1 amd64Portable audio I/O - development files 73 ... Sid. [mleech@marcus2 ~]$ rpm -qa |grep portaudio portaudio-19-11.fc14.x86_64 portaudio-devel-19-11.fc14.x86_64 H... a very old version of Fedora. When a new version comes out I upgrade to the latest using yum - likewise with openSUSE, Ubuntu and Ubuntu ARM. I crawl from one version to the next and only do a fresh install if I upgrade HD's. Problem comes when new code requires something that is a level or several higher than you have installed - upgrade beyond one or 2 versions probably doesn't work and you are forced to do a fresh install then all the other packages required after that, plus fresh setups. You get changes like systemd replacing sysvinit which is seamless if you are one or 2 levels back. With a fresh install there are many new things you are presented with suddenly, more to deal with when you are trying to get up and working. 73 ... Sid. I removed portaudio from the system, which cured this particular problem, since i only had 1 package that depended on it, and I'm not using it. -- 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] importing blocks to GRC
On 05/28/2014 09:11 PM, Pengyu Zhang wrote: When I do echo $PYTHONPATH, nothing shows up. How is $PYTHONPATH set? I thought it should be configured automatically by cmake and make. Correct? On Wed, May 28, 2014 at 4:56 PM, Alfredo Muniz mun...@seas.upenn.edu mailto:mun...@seas.upenn.edu wrote: On Wed, May 28, 2014 at 1:43 PM, Pengyu Zhang zhange...@gmail.com mailto:zhange...@gmail.com wrote: I still cannot see the block on GRC I'm assuming you're using ubuntu then. Check your python path echo $PYTHONPATH and ensure that you see the howto folder located there in the dist-packages ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio No, it's an environment variable. A Linux shell thing. PYTHONPATH should be set to include the place where the installer installed the Python modules. Setting users environment variables is unrelated to building software. I usually set mine in my .bashrc: PYTHONPATH=.:$HOME/bin:/usr/local/lib/python2.7/site-packages:/usr/local/lib/python2.7/dist-packages PYTHONPATH=$PYTHONPATH:/usr/local/lib64/python2.7/site-packages:/usr/local/lib64/python2.7/dist-packages export PYTHONPATH -- 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] Getting overflows at 50 Msps (not sure why)
On 06/04/2014 05:16 PM, Orin Lincoln wrote: Hello, I am trying to get samples from a B200 at 50 Msps into GNU Radio. The UHD benchmark_rate tool receives at 50 Msps without any overflows detected. My GNU Radio flowgraph is simply a USRP source connected to a null sink, and I'm still getting overflows. I've tried expanding the min_output_buffer for the USRP source, but that doesn't seem to help. I really don't know what is causing the problem. Any suggestions about what I should try? Thank you, Orin Lincoln ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio What is causing the problem is that your computer/OS simply cannot keep up. Gnu Radio has noticeably more overhead than a hand-crafted program like benchmark_rate. Being able to maintain real-time streaming at these rates is *challenging*, and just because benchmark_rate doesn't fall over, is *zero* guarantee that some *other* program, trying to swallow data at a similar rate, will actually be able to. Desktop/Server operating systems (Windows, OSX, Linux, *BSD) aren't really optimized for dealing with high-bandwidth real-time flows. In any given system configuration, it's rather a crap-shoot as to whether your system will be able to keep up or not. What type of computer do you have? What OS? How much memory? Is it the fastest memory you can use on your motherboard? -- 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] Help with wx-gui, window size error
On 06/06/2014 11:33 AM, Tom Rondeau wrote: On Fri, Jun 6, 2014 at 4:32 AM, Thilina Mallawa Arachchi thilina.arach...@gmail.com mailto:thilina.arach...@gmail.com wrote: Hi, I am having problems running a WX GUI FFT Sink, I am getting the following runtime error: Traceback (most recent call last): File /home/thilina/noctar/fm_rx/top_block.py, line 109, in module tb = top_block() File /home/thilina/noctar/fm_rx/top_block.py, line 50, in __init__ size=(720, 480), File /usr/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_nongl.py, line 198, in __init__ self.win = fft_window(self, parent, size=size) File /usr/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_nongl.py, line 331, in __init__ self.control_panel = control_panel(self) File /usr/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_nongl.py, line 256, in __init__ wx.Panel.__init__(self, parent, -1, style=wx.SIMPLE_BORDER) File /usr/lib/python2.7/site-packages/wx-3.0-gtk2/wx/_windows.py, line 68, in __init__ _windows_.Panel_swiginit(self,_windows_.new_Panel(*args, **kwargs)) wx._core.PyAssertionError: C++ assertion m_window failed at ./src/gtk/dcclient.cpp(2041) in DoGetSize(): GetSize() doesn't work without window Is this a know bug? whats the best way to fix it? I am new to gnuradio. I'm running gnuradio 3.7.3-4 Kind Regards, Thil It's telling you that you haven't defined a window for the FFT. You can specify no window (iirc) by passing it '[]' or you can look at the fft.window module, which provides a set of windows you can define. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Tom, you should look again. This is a guts of wxPython thing. Either there's no Xwindow server running, or they forgot to specify WX GUI in the generate options. -- 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] GPSDO detection in B200
On 06/06/2014 02:19 PM, Robert Light wrote: Hi, How is the detection of GPSDO done in B200 ? I see that UHD tries to detect GPSDO every time I use B200 but what is it looking for? How to force switching between internal, external and GPSDO clock ? I have GPSDO installed but sometimes I want to force another clock source. Also is there some more detailed description of what the LED's LED802/LED803 mean (especially LED802)? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I believe it just looks for messages from the NMEA serial port on the GPSDO. Also, you can select different clock sources when you instantiate a UHD source/sink block in GRC. There's a drop-down menu. If you aren't programming using GRC, you can use what it *does* generate in the Python as a template for your own code. -- 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] GPSDO detection in B200
On 06/06/2014 02:51 PM, Robert Light wrote: Is 1PPS used if I have GPSDO installed or does the B200 assume that 10MHz is already good enough? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio In all the USRPs that have 10MHz and 1PPS, the 1PPS is used only for TOD synchronization, for operations like: set_time_next_pps(). There is no internal PLL that is phase-locking to 1PPS--the assumption is that the 1PPS is locked to 10MHz already, and it's just used as a trigger for TOD (time-of-day) setting operations. -- 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] getting noise for FM receiver with usrp e110 ?
On 06/12/2014 06:14 AM, Wafa Elhajhmida wrote: Hi everybody, I'm trying to implement FM receiver on usrp e110. The daugtherboard used is SBX Board Rev 5.1. As a result, I got only noise, I wasn't able to hear the local station at 103.5 Mhz. And I got this error: *UHD Warning:* *The hardware does not support the requested RX frequency:* * Target frequency: 103.50 MHz* *Actual frequency: 423.50 MHz* * gr_fir_ccf: using armv7_a* * gr_fir_fff: using armv7_a* *aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUOaUaUaUOaUaUaUaUaUaUaUaUaUaUaUaUaUaU* * * I attached a screenshot of FM receiver 's GRC. Can you help me to detect if there are some parameters which are wrong ? Best regards, Wafa HAJ HMIDA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Two issues: The SBX doesn't support that frequency. The audio subsystem on E110 doesn't support a sample rate of 96k ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] wxPython 3.0 breaks wxGUI
On 06/12/2014 10:43 PM, Tom Rondeau wrote: In one sense, this is a low priority because we are moving away from using the wx sinks in favor of the qt sinks. Still, for now, most of our examples are base on wx, so we will need this to work for a little bit longer. Tom Tom, it's not just the examples. It's a significant base of 3rd party applications. If you make WX go away without having some kind of uber-smooth transition plan, then the bad taste left by the 3.6 to 3.7 transition will be remembered, and it won't be pretty. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues with syncing two USRPs!
On 06/14/2014 05:48 PM, eldarymli wrote: Hi Martin, This is a follow up on my earlier email. I am still having issues with getting two N200's to work together. First, please find a short answer to your questions. Do you know what kind of Ethernet controller is on your ports? Are they 82579LM by any chance? You *have* to make certain that Network Manager isn't trying to automatically assigned addresses on those cards, since it will try, and then take them out of service if it doesn't get a DHCP address assignment. Out of curiousity, do you have a MIMO cable and are willing to test that? No, I do not have a MIMO cable. You're saying you get 2 channels per LFRX, correct? Also, are you attenuating the signal? Yes, I tried both 2 (i.e., A:A, A:B) and 1 (i.e, A:AB). The signal is attenuated by a factor of four 'cuz I'm using two T's each with two outputs. Just to confirm: You're setting *both* clock and time sources to external? Yes. I initially thought the issue has to do with syncing, but it seems that it is not due to syncing per se (?!) A quick recap. One N200 acts as a single-channel Tx (i.e., A:AB) and a two-channel Rx (i.e., A:A and A:B). The other N200 only acts as a two-channel Rx (i.e., A:A and A:B). I am using two T's to split my Tx signal into four signals and I am feeding those to the Rx's. [i.e., my Rx signal is attenuated by a factor of 4]. In GRC, I always use an USRP sink that is properly configured for the Tx AB channel. At the Rx side, for the sake of testing, I tried multiple configurations as follows. First, I only considered one N200 (i.e., a single motherboard) at a time, and I used a source as above. When I do so, *either I apply external sync and clock or not*, I am able to perfectly receive my signal. This test was successful when I fed-in the source with either the two Rx channels from the first or the second N200, separately. Second, I used one single source with two motherboards and four Rx channels. I tested this* with and without sync/clocking signals*. In both cases, I get this error message: Using Volk machine: sse4_a_64_orc *thread[thread-per-block[4]: block gr uhd usrp source (1)]: *RuntimeError: fifo ctrl timed out looking for acks** Please note that, despite this message, the GRC program looks as if it is running, and the GUI shows me the output from the scope (i.e., scope is just placed before the USRP Tx sink). However, the output from the scopes after the Rx USRP is null for the four channels. [For Rx's with a single source, I also tried a single-channel from the two motherboards (i.e., A:AB) without any success]. Checking the system monitor on my computer confirms that one USRP is transmitting all the time while no receive/incoming traffic whatsoever. Besides this, I tried various diagnostics. I thought that the issue may has to do with the Ethernet controller/card on my computer, and that it may be dropping/delaying some packets. Hence, I 'unmanaged' the Ethernet connections, and I applied static configuration. I also tried to disable some options in the network driver such as autoneg, adaptive, coalesce, etc., without any success. Please find below some diagnoses that may give some clues on the FIFO ACK error, T-UD2H:~$ sudo ethtool --show-coalesce eth4 Coalesce parameters for eth4: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 20 rx-frames: 5 rx-usecs-irq: 0 rx-frames-irq: 5 tx-usecs: 72 tx-frames: 53 tx-usecs-irq: 0 tx-frames-irq: 5 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 T-UD2H:/etc/network$ sudo ethtool --show-coalesce eth3 Coalesce parameters for eth3: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 20 rx-frames: 5 rx-usecs-irq: 0 rx-frames-irq: 5 tx-usecs: 72 tx-frames: 53 tx-usecs-irq: 0 tx-frames-irq: 5 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 T-UD2H:/etc/network$ ifconfig -a eth4 eth4 Link encap:Ethernet HWaddr REMOVED inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: REMOVED_by_KE Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:118227 errors:0 dropped:0 overruns:0 frame:0 TX packets:733915 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8366882 (8.3 MB) TX bytes:930252111 (930.2 MB) Interrupt:19 GA-MA785GMT-UD2H:/etc/network$ ifconfig -a eth3 eth3 Link encap:Ethernet HWaddr REMOVED inet addr:192.168.20.1 Bcast:192.168.20.255 Mask:255.255.255.0 inet6 addr: REMOVED_by_KE Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:40807 errors:0 dropped:0
Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)
On 06/16/2014 04:23 PM, madengr wrote: Orin, Just curious what USB 3.0 chipset and OS you are using, and if you can go over 50 Msps? I am able to get 45 Msps UHD Benchmark with the VLI VL80x, but not over that. Thanks, Lou KD4HSO Also, I should point out that getting some high sample-rate in the *benchmark* application is only a very-vague indicator of how well things will do when you're actually *doing things* with the samples. It's very much cheaper to read samples and throw them away than it is to actually do things, including recording, with said samples. -- 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] GNU Radio / Software Radio conceptual question
On 06/16/2014 10:24 PM, Michael Rahaim wrote: Hi all, I have a relatively high level question regarding gnuradio and software radio in general. Is it a fair generalization to say that gnuradio is operating at the application layer and is essentially emulating a physical layer implementation (or the implementation of other lower layer protocols)? For example, if I have a link between two USRPs (more specifically, N series USRPs), the digitally sampled received data comes in on the ethernet NIC and moves up the stack to the software radio application. The signal processing that would typically be done in lower layers is then handled by the application. The second part of my question is, given a flow graph in gnuradio, what sort of steps would be necessary to push it back down the stack or implement in a chipset such that it can be used as an interface in a typical network stack? Is this something that anyone using gnuradio has considered or should I assume the next step would involve re-implementation? NOTE: This is by no means for a commercial product, but rather for demonstration. My research has led me to use gnuradio for some proof of concept implementations and I'm curious how much additional effort would be required to port the work to a practical device - for example, implementation on a smart phone. (you can read this as will it cause me to postpone graduation a few weeks? months? years?) Thanks in advance - any input is greatly appreciated. Regards, Michael Rahaim PhD Candidate Boston University, Boston, MA This presentation is several years old at this point, but I give it to ham-radio clubs from time to time: http://www.sbrac.org/files/sdr_introduction.ppt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sample time alignment in GRC
On 06/17/2014 09:58 AM, Lapointe, Benjamin - 1008 - MITLL wrote: Hi All, I am still having trouble time aligning sample streams from two USRP X310 devices. In GRC I noticed a random time offset from run to run in the two data streams using a WX GUI Scope Sink. Looking at recorded data in MATLAB I also see a random time offset from run to run in the two data streams (8, 18, and 24 sample offset). I verified that the two data streams that I am inputting into the X310 devices are time aligned using a physical scope. My GRC setup: USRP Source 1 (with internal GPSDO-MINI) -Sync = unknown PPS -Mb0: Clock Source = Default -Mb0: Time Source = Default USRP Source 2 -Sync = unknown PPS -Mb0: Clock Source = External -Mb0: Time Source = External For looking at the data streams I have USRP Source - Complex to Mag - WX GUI Scope Sink. For recording the data streams I have USRP Source - Head (5K) - File Sink (Unbuffered: OFF) Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” SMA cable. PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6” SMA cable. RF input to USRP devices is a pulsed RF signal, to make it easier to look at time offset. GPS on USRP 1 is locked; however, I work with tall buildings completely surrounding me and so I don’t know the strength of the GPS lock. I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but until then.. Does anyone have any other ideas for getting time-aligned samples from run to run in GRC, or what I am doing wrong? I would expect at most a minimal constant time offset between data streams if the 10 MHz Ref and 1 PPS signals are locked. Thanks! -ben *From:*Marcus Leech [mailto:mle...@ripnet.com] *Sent:* Friday, June 13, 2014 2:04 PM *To:* Lapointe, Benjamin - 1008 - MITLL *Cc:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] sample time alignment in GRC Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and all of them should use time synch of unknown PPS. Also, there has been a bug in the scope sink (dunno if fixed) where samples are *not* time-aligned in the scope sink. The except is that a complex-pair will be time-aligned internally, but not necessarily to other streams being displayed. on Jun 13, 2014, *Lapointe, Benjamin - 1008 - MITLL* blapoi...@ll.mit.edu mailto:blapoi...@ll.mit.edu wrote: Hi, I have two USRP X310 devices that I am trying to time align in GNU Radio Companion. One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS signals to the other one. The GPS is locked. Ideally I would have matched length cables for 10 MHz reference and 1 PPS, but I think my setup is close enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with matched length cables, USRP output sampling rate = 5M, USRP center frequency = 10M.) I am using WX GUI Scope Sink to look at the magnitudes of each stream from the USRP devices. I expect to see no/minimal delay between the two signal streams, but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from run to run between the two signal streams. The period of the signal is 50 samples, so the maximum delay difference is 25 samples. Am I missing something in my configuration? Since I am using a 10 MHz reference and 1 PPS signals, I expect time alignment between the two sample streams. Is there a GRC block for forcing time alignment? Thanks! -Ben ___ 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 What daughtercards are you using again? There *will* be a random phase offset between the two sides here, because GRC flow-graphs can't take advantage of timed-commands to phase-align the LOs on WBX and SBX cards. -- 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] Phase measurement with Ettus Research N210
On 06/17/2014 04:56 PM, Daniele Nicolodi wrote: I'll try to see if this makes a difference. The minimum sampling rate I can program is ~193 kHz (it is a strange fraction that I cannot check right now). Minimum sample rate = 100e6/512 The USRP devices do strictly-integer decimation in the FPGA. Given your explanation I believe that the issue may come from finite accuracy in the generation of the 100 MHz sampling rate: how is the 100 MHz clock generated exactly? If the 100 MHz clock is divided with a DDS to be compared to the 10 MHz clock to derive the error signal for the PLL, the finite precision of the DDS control register may explain the small frequency error (a 32 bit DDS would introduce the right order of magnitude effect, but I haven't check the exact number). Cheers, Daniele The master clock on the N2xx series is derived from a 10MHz source (on-board 10MHz VCTCXO, or external, or internal GPSDO), feeding an AD9510 PLL clock generator, which in turn controls a 100MHz VFO, implemented with a 100MHz VCTCXO--both clocks are in the 2.5PPM category. http://files.ettus.com/schematics/n200/n2xx.pdf -- 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
