[Discuss-gnuradio] USRP2 BLOCK ERROR IN GNURADIO 3.6.2
hello All,
dose any one have idea about this error?
i install USRP block in gnuradio 3.6.2 for this file but still have an error.
root@Junaid-VPCF13UFX:/home/muhammadjunaid/airprobe/gsm-receiver/src/python#
./gsm_receive_usrp2.py
Traceback (most recent call last):
File "./gsm_receive_usrp2.py", line 6, in
from gnuradio import gr, gru, blks2
File "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2/__init__.py",
line 37, in
exec "from gnuradio.blks2impl.%s import *" % (f,)
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2impl/cvsd.py",
line 24, in
from gnuradio.vocoder import cvsd_vocoder
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/vocoder/cvsd_vocoder.py", line
26, in
_cvsd_vocoder = swig_import_helper()
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/vocoder/cvsd_vocoder.py", line
22, in swig_import_helper
_mod = imp.load_module('_cvsd_vocoder', fp, pathname, description)
ImportError: libgnuradio-cvsd-vocoder-3.4.2.so.0: cannot open shared object
file: No such file or directory
Thanks
Regards
Muhammad Junaid
m_junaid0...@yahoo.com
http://junaidmuhammad.webs.com/___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] request to add openSUSE 12.1 support to the build-gnuradio script
I've just corresponded with Marcus Leech about adding support for openSUSE 12.1 in the build-gnuradio script, and he's said "The cmake hackery might be better placed in the Cmake rules in Gnu Radio itself--using yet-another special recognizer for OpenSuse. I suggest you post to discuss-gnuradio to indicate that OpenSuse requires this rule, and perhaps someone (maybe Josh) will patch the Cmake rules appropriately." the place to check for openSUSE 12.1 is /etc/os-release and it contains: NAME=opensuse VERSION = 12.1 (Asparagus) VERSION_ID="12.1" PRETTY_NAME="openSUSE 12.1 (Asparagus) (i586)" ID=opensuse i used the existing build-gnuradio script as an outline for building it manually. the individual steps were quite successful. here's the key info: sudo zypper install cmake cppunit-devel doxygen fftw3-devel git gsl-devel libjack-devel libqt4-devel libqwtplot3d-devel libSDL-devel libusb-1_0-devel orc portaudio portaudio-devel python-cheetah python-devel python-lxml python-wxGTK python-wxWidgets-devel qwt-devel wxWidgets-devel xmlto (add texlive-latex to the list above if you want all the gnuradio docs to build - latex install alone needs about 300MB of disk) To enable building *gr-qtgui *in addition to all the rest, you have to point cmake to the location of the qwt header files: cmake -DQWT_INCLUDE_DIRS=/usr/include/qwt5 ../ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA time
Hello, Sorry for the lack of response, I was on vacation. We actually managed to fix most of our problems, mostly due to hardware setup issues. Thank you for your help! On Wed, Aug 29, 2012 at 3:18 PM, wrote: > ** > > On 29 Aug 2012 15:13, Josh Blum wrote: > > On 08/28/2012 03:24 PM, Anisha Gorur wrote: > > Sorry for the confusion. We are trying to synchronize 3 usrps for collect. > The devices seem to be time aligned in that the samples are timestamped > with the same metadata, so we believed that synchronization had been > achieved. However, when the data collected from the usrps was correlated, > samples that should have had 0 time difference of arrival were off by as > many as 5 samples, at a sample rate of 6.25MS/S. So even though the > timestamps are time aligned, the data does not seem to be. The devices have > been synchronized PPS times, not uspr.get_time_now(). Thank you, Anisha > > Can you tell me more about the correlation? Are you sending a impulse > split to all 3 devices and determining the pulse arrival. Is the error > in time of arrival consistent between runs or does it seem to be random? > > If you ask all N USRPs to stream at time X, the time reported in the > metadata will still be X, even if the internal tick count in each device > is not marching in lock step. > > I have a few suggestions: > > 1) I think you have 1 GPSDO per USRP providing each a different > reference. I would first try the experiment with a shared 10 MHz > reference and PPS to all devices to confirm the algorithm. You will need > to move the 10 MHz reference jumper back so you can provide an external > ref via SMA. > > > I've observed, in a previous life, phase-hits between two GPSDOs > connected to the same antenna, watching the same cluster of satellites. > Never figured out why, which is why for phase-sensitive work, it makes > sense to use a common reference, (like an external GPSDO), rather than a > GPSDO-per-unit. > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] contactless transaction using gnuradio?
On Sat, Sep 1, 2012 at 5:40 PM, Norman Khine wrote: > hello, > i am interested in learning if it is possible to use gnuradio to implement a > similar application to how tagpay works, here are some details > http://www.tagattitude.fr/en/products/technology > > any advise much appreciated. > > norman Norman, >From a signal processing standpoint, sure, GNU Radio should work with the basic idea. The issue you face is how to get the information into and out of GNU Radio to the external world. You might be able to use the audio I/O, but my guess is that you'll need some more specialized equipment. Of course, I say this after a 1 minute look at that website, so I'm sure there are subtleties that I'm missing. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] seg fault in volk_32f_s32f_multiply_32f_a_sse gnuradio v 3.6.1
On Mon, Sep 3, 2012 at 10:36 PM, ikjtel wrote: > >> The reason this doesn't cause a problem for you in 3.3 is because >> that's pre-Volk. This looks like you're running SSE operations on a >> system that doesn't support it. > > Hi Tom > I shall put together the full list of stuff you mentioned, but 3 quick things > > 1) the system apparently does support SSE (see below) Yes, looks like it. But it's an Atom, which might change things. I know we had some issues on Atom's before, but I thought that we worked them out. I'll be interested to see how cmake reports the architecture checks for VOLK here. > 2) we have a few custom C++ blocks in the app, perhaps there's some rule > we're breaking and so running afoul of the SSE instruction operand alignment > restrictions (is this possible?) > 3) the problem is happening in a relatively complex GR app > [http://op25.osmocom.org/wiki/wiki/SignalScopePage , using audio-IF mode]. > > Both 2 and 3 point toward the need to try to reproduce the problem here with > a simplified test app, finding the absolute minimum number of GR blocks > needed to do so, and ruling out the possibility that's it's something we're > doing wrong... > > Thanks > > Max Thanks. Not sure what to make of that, yet. What happens if you just have a sig_source_f->multiply_ff->null_sink? Tom ~~processor : 0 > vendor_id: GenuineIntel > cpu family: 6 > model: 28 > model name: Intel(R) Atom(TM) CPU N450 @ 1.66GHz > stepping: 10 > cpu MHz: 1000.000 > cache size: 512 KB > physical id: 0 > siblings: 2 > core id: 0 > cpu cores: 1 > apicid: 0 > initial apicid: 0 > fdiv_bug: no > hlt_bug: no > f00f_bug: no > coma_bug: no > fpu: yes > fpu_exception: yes > cpuid level: 10 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat > clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc > arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 > xtpr pdcm movbe lahf_lm dts > bogomips: .52 > clflush size: 64 > cache_alignment: 64 > address sizes: 32 bits physical, 48 bits virtual > power management: > > processor: 1 > vendor_id: GenuineIntel > cpu family: 6 > model: 28 > model name: Intel(R) Atom(TM) CPU N450 @ 1.66GHz > stepping: 10 > cpu MHz: 1000.000 > cache size: 512 KB > physical id: 0 > siblings: 2 > core id: 0 > cpu cores: 1 > apicid: 1 > initial apicid: 1 > fdiv_bug: no > hlt_bug: no > f00f_bug: no > coma_bug: no > fpu: yes > fpu_exception: yes > cpuid level: 10 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat > clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc > arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 > xtpr pdcm movbe lahf_lm dts > bogomips: 3332.92 > clflush size: 64 > cache_alignment: 64 > address sizes: 32 bits physical, 48 bits virtual > power management: ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] request to add openSUSE 12.1 support to the build-gnuradio script
On 04 Sep 2012 09:13, KB3CS - Chris wrote: > I've just corresponded with Marcus Leech about adding support for openSUSE 12.1 in the build-gnuradio script, and he's said > > "The cmake hackery might be better placed in the Cmake rules in Gnu Radio itself--using yet-another special recognizer for OpenSuse. I suggest you post to discuss-gnuradio to indicate that OpenSuse requires this rule, and perhaps someone (maybe Josh) will patch the Cmake rules appropriately." > > the place to check for openSUSE 12.1 is /etc/os-release and it contains: > NAME=opensuse > VERSION = 12.1 (Asparagus) > VERSION_ID="12.1" > PRETTY_NAME="openSUSE 12.1 (Asparagus) (i586)" > ID=opensuse > > i used the existing build-gnuradio script as an outline for building it manually. the individual steps were quite successful. > > here's the key info: > > sudo zypper install cmake cppunit-devel doxygen fftw3-devel git gsl-devel libjack-devel libqt4-devel libqwtplot3d-devel libSDL-devel libusb-1_0-devel orc portaudio portaudio-devel python-cheetah python-devel python-lxml python-wxGTK python-wxWidgets-devel qwt-devel wxWidgets-devel xmlto > > (add texlive-latex to the list above if you want all the gnuradio docs to build - latex install alone needs about 300MB of disk) > > To enable building GR-QTGUI in addition to all the rest, you have to point cmake to the location of the qwt header files: cmake -DQWT_INCLUDE_DIRS=/usr/include/qwt5 ../ To be clear, it's only the cmake stuff that I'd prefer be handled in the Gnu Radio build process itself, rather than build-gnuradio special-casing it. We've done distribution-specific "spooge" in the Cmake files a few times, and it seems like this might be another instance of that. The pre-requisite support using zypper is no problem, and I already put that in that last. But I'm waiting on opinions about the cmake flags -- whether that should be something in the gnuradio cmake files, or whether I need to special-case it in build-gnuradio. Doing it in Gnu Radio itself means that people doing manual builds will have a seamless experience. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] request to add openSUSE 12.1 support to the build-gnuradio script
On Tue, Sep 4, 2012 at 9:13 AM, KB3CS - Chris wrote: > I've just corresponded with Marcus Leech about adding support for openSUSE > 12.1 in the build-gnuradio script, and he's said > >"The cmake hackery might be better placed in the Cmake rules in Gnu Radio > itself--using yet-another special recognizer for OpenSuse. I suggest you > post to discuss-gnuradio to indicate that OpenSuse requires this rule, and > perhaps someone (maybe Josh) will patch the Cmake rules appropriately." Hi Chris, I'm not sure I understand what rule has to be added/changed for you? Is it just the location of the QWT header files? That's going to be a continuous problem since they don't produce a package config file for us to work off of. We're basically left to chase down all possible include directories where we know it exists. Also, now that QWT 6 is out, a lot of platforms are switching to that, so if we hard code /usr/include/qwt5, that'll just break when OpenSUSE moves to Qwt6 and we'll have to write another rule. Any advice for how to best handle this situation is appreciated. (But getting rid of Qwt isn't an option; it's way too useful.) Tom > the place to check for openSUSE 12.1 is /etc/os-release and it contains: > NAME=opensuse > VERSION = 12.1 (Asparagus) > VERSION_ID="12.1" > PRETTY_NAME="openSUSE 12.1 (Asparagus) (i586)" > ID=opensuse > > i used the existing build-gnuradio script as an outline for building it > manually. the individual steps were quite successful. > > here's the key info: > > sudo zypper install cmake cppunit-devel doxygen fftw3-devel git gsl-devel > libjack-devel libqt4-devel libqwtplot3d-devel libSDL-devel libusb-1_0-devel > orc portaudio portaudio-devel python-cheetah python-devel python-lxml > python-wxGTK python-wxWidgets-devel qwt-devel wxWidgets-devel xmlto > > (add texlive-latex to the list above if you want all the gnuradio docs to > build - latex install alone needs about 300MB of disk) > > To enable building gr-qtgui in addition to all the rest, you have to point > cmake to the location of the qwt header files: > > cmake -DQWT_INCLUDE_DIRS=/usr/include/qwt5 ../ > > > ___ > 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] USRP2 BLOCK ERROR IN GNURADIO 3.6.2
On Tue, Sep 4, 2012 at 3:17 AM, Muhammad JUNAID wrote:
> hello All,
> dose any one have idea about this error?
> i install USRP block in gnuradio 3.6.2 for this file but still have an
> error.
> root@Junaid-VPCF13UFX:/home/muhammadjunaid/airprobe/gsm-receiver/src/python#
> ./gsm_receive_usrp2.py
> Traceback (most recent call last):
> File "./gsm_receive_usrp2.py", line 6, in
> from gnuradio import gr, gru, blks2
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2/__init__.py",
> line 37, in
> exec "from gnuradio.blks2impl.%s import *" % (f,)
> File "", line 1, in
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2impl/cvsd.py",
> line 24, in
> from gnuradio.vocoder import cvsd_vocoder
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/vocoder/cvsd_vocoder.py",
> line 26, in
> _cvsd_vocoder = swig_import_helper()
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/vocoder/cvsd_vocoder.py",
> line 22, in swig_import_helper
> _mod = imp.load_module('_cvsd_vocoder', fp, pathname, description)
> ImportError: libgnuradio-cvsd-vocoder-3.4.2.so.0: cannot open shared object
> file: No such file or directory
>
> Thanks
> Regards
> Muhammad Junaid
> m_junaid0...@yahoo.com
> http://junaidmuhammad.webs.com/
Muhammad,
It looks like there's a version issue with your installation. You're
trying to install and run 3.6.2 (from git, I assume), but something is
looking for libgnuradio-cvsd-vocoder, which a) is from 3.4.2 here and
b) doesn't exist any longer. All vocoders are now in
libgnuradio-vocoder.
I suggest uninstalling and removing any old GNU Radio install files
from your system (there is information on the webpage and in the
mailing list about how to do this) and reinstall 3.6.2.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Queue Source not being processed by DPSK Demod Block
On Mon, Sep 3, 2012 at 5:44 PM, Travis Collins wrote: > By "not processing data" I mean I look at the size of the source > queue, which is attached to the dpsk_demod block and it just grows > without data being removed. I just use the queue.count() method to > observe this. I can even stop adding data to the message source block > and the queue count remains the same. > > Yes I'm using the dpsk_demod supplied with GNU-Radio. When you > mention the modulator, that doesnt apply here correct? Since Im using > only a demod and that should take complex data and then output packet > bits. > > When I convert the numpy array to a large string I get segmentation > faults now even at very low sample rates. Here is a link to the > flow-graph if you wanna take a look: http://pastebin.com/M2CrVPwP > > -Travis Ah, I see my confusion. You're talking about adding to the demodulators queue. Inserting into the message queue made me think you were working on the modulator side. In this case, the demodulator itself is what inserts the messages. It's your task (or, more precisely, the application's task) to remove the messages from the queue; in other words, the queue holds the frames created by the demodulator/receiver chain. Look in gr-digital/python/pkt.py in the _queue_watcher_thread function. That's where the messages are being popped off the queue. The demodulator expects a stream of complex values as inputs (from, say, a USRP source). Tom > On Sat, Sep 1, 2012 at 11:32 AM, Tom Rondeau wrote: >> On Fri, Aug 31, 2012 at 3:13 PM, Travis Collins >> wrote: >>> Ive change the connected block from a dbpsk_demod to a null_sink and a >>> file_sink and the queue is processed, but I'm still having an issue >>> with the demod block. >>> >>> I believe the problem has to be with the data type conversion >>> "processed.tostring()". Should I convert each individual value of the >>> numpy array to a string and append them together or is there a better >>> way? The numpy array itself is made up of complex data. >>> >>> -Travis >> >> Hi Travis, >> >> Can you provide more details when you say that it's not processing the >> data? What does that actually mean? Is it not doing anything or just >> not doing what you expect? >> >> The numpy array shouldn't be a problem since you are converting it to >> a string directly. Although make sure that what tostring() returns is >> what you think it should return. >> >> As for the dpsk modulator: is that the modulator from GNU Radio? Are >> you basically trying to do what we do in >> examples/narrowband/benchmark_tx.py? If so, that modulator expects >> (packed) bits, not complex samples. It will convert the bits to >> complex samples internally. >> >> Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO HW Interface
On Fri, Aug 31, 2012 at 2:57 PM, My Radio wrote: > While many HW solutions interfacing with GNURADIO has evolved but we dont > see any of them listed under GNURADIO HW interface page. For example here is > the link http://gnuradio.org/redmine/projects/gnuradio/wiki#VI-Hardware > > Is GNURADIO limited to a particular h/w?. Although we do not think so but > still there seems to be a Gap. > > Can anyone take us to a platform where any new HW can be plugged and played > independent of UHD with a standard source and sink of IQ data. We do not > oppose UHD but we see it is more related to USRP. > > However, if anyone can create a template to throw in there API' there and > compile with GNURADIO. That would be great start many h/w with GNURADIO. > Like GNURADIO, SDRSHARP is a simple example out there but provides a great > flexibility in terms of interfacing new hardware's. I wanted to address this in hopefully the least controversial way possible... In short, no, GNU Radio is not limited to any particular hardware, but it's a bit up to the hardware vendors to work with us to interface to GNU Radio. Similarly, the wiki is a place where anyone can get access to update it, so if someone wants to offer their hardware solution on the page, it's not very difficult. But this issue has a long history. It seems various platforms come and go and don't necessarily have a strong connection to our community. On the other hand, Ettus Research, both Matt in the early days of GNU Radio and now his team of engineers, has been a major contributor to GNU Radio and has had a sustained business of shipping and supporting SDR hardware for, what is it now, almost 10 years? So sure, it seems like there is a bias on GNU Radio's part to Ettus products, but that's because of a strong and sustained effort from them to work with and contribute to the community. But that does not prevent others from doing the same. As I said, there's a pretty long history here of different hardware products and a lot of emotions that surround it. I expect that answering this question publicly will draw a lot of comments and criticisms, but there you have it. There's another issue on the table here about a hardware abstraction layer or a general/global API for SDR front ends. That, too, is an incredibly complicated problem that I haven't seen any real solutions for. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hafl duplex for N210 + XCVR2450
Hi, I had question about using N210 and XCVR2450 in a half-duplex scenario. I have used tx_sob and tx_eob stream tags hoping for a switch from default RX to TX whenever there is a packet to transmit. What happens is both sides initiate with LED C constantly ON ( default to receiving, I guess ) but as the packet comes with the two stream tags attached, I do see the transmitting led A ON but the receiving LED C is also ON at the same time. Should not there be a switch from RX to TX and LED C be OFF. I am not being able to receive anything is this scenario though transmitting side does transmit but there is no activity in the receiving end. I will be thankful for any comments. Anjan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO HW Interface
On 04 Sep 2012 10:29, Tom Rondeau wrote: > There's another issue on the table here about a hardware abstraction > layer or a general/global API for SDR front ends. That, too, is an > incredibly complicated problem that I haven't seen any real solutions > for. > > Tom > > ___ The gr-osmosdr block does some abstraction for the RX side, supporting: o FunCube Dongle o OSMOSDR o UHD devices (all the Ettus gear) o RTLSDR So, there is an example of an attempt at an abstraction layer that works passably well. It'll get better over time as people use it, and can serve as an example for any other attempts out there. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO HW Interface
On Tue, Sep 4, 2012 at 10:41 AM, wrote: > On 04 Sep 2012 10:29, Tom Rondeau wrote: > > > > There's another issue on the table here about a hardware abstraction > layer or a general/global API for SDR front ends. That, too, is an > incredibly complicated problem that I haven't seen any real solutions > for. > > Tom > > ___ > > > The gr-osmosdr block does some abstraction for the RX side, supporting: > > o FunCube Dongle > > o OSMOSDR > > o UHD devices (all the Ettus gear) > > o RTLSDR > > > > So, there is an example of an attempt at an abstraction layer that works > passably well. It'll get better over time as people use it, and can serve > as an example for any other attempts out there. I'm not sure that I consider what they do an abstraction layer. They just switch between a handful of devices. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO HW Interface
On 04 Sep 2012 10:48, Tom Rondeau wrote: > On Tue, Sep 4, 2012 at 10:41 AM, wrote: > >> On 04 Sep 2012 10:29, Tom Rondeau wrote: There's another issue on the table here about a hardware abstraction layer or a general/global API for SDR front ends. That, too, is an incredibly complicated problem that I haven't seen any real solutions for. Tom ___ The gr-osmosdr block does some abstraction for the RX side, supporting: o FunCube Dongle o OSMOSDR o UHD devices (all the Ettus gear) o RTLSDR So, there is an example of an attempt at an abstraction layer that works passably well. It'll get better over time as people use it, and can serve as an example for any other attempts out there. > > I'm not sure that I consider what they do an abstraction layer. They > just switch between a handful of devices. > > Tom Anything that reduces/eliminates the need for multiple flow-graphs to support different devices with a similar "high level" interface is a good thing. For that, gr-osmosdr works quite well. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] contactless transaction using gnuradio?
hi, i can get the information into and out of GNU radio using tropo
https://www.tropo.com/how-it-works/ type application i guess!
but was interested to see working examples of how to work with the data
once it has been received, for example, if i have a python script which
creates a dictionary or a key:value object this then generates a unique
signal then to be able to process this signal and read the key:value
object.
is my understanding correct of the process and are there any security
issues with this?
thanks
On Tue, Sep 4, 2012 at 2:59 PM, Tom Rondeau wrote:
> On Sat, Sep 1, 2012 at 5:40 PM, Norman Khine wrote:
> > hello,
> > i am interested in learning if it is possible to use gnuradio to
> implement a
> > similar application to how tagpay works, here are some details
> > http://www.tagattitude.fr/en/products/technology
> >
> > any advise much appreciated.
> >
> > norman
>
> Norman,
>
> From a signal processing standpoint, sure, GNU Radio should work with
> the basic idea. The issue you face is how to get the information into
> and out of GNU Radio to the external world. You might be able to use
> the audio I/O, but my guess is that you'll need some more specialized
> equipment. Of course, I say this after a 1 minute look at that
> website, so I'm sure there are subtleties that I'm missing.
>
> Tom
>
--
%>>> "".join( [ {'*':'@','^':'.'}.get(c,None) or chr(97+(ord(c)-83)%26) for
c in ",adym,*)&uzq^zqf" ] )
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] request to add openSUSE 12.1 support to the build-gnuradio script
there are two qwt packages involved: libqwt5 and qwt-devel maybe one rule for /usr/include/qwt and then a symlink from /usr/include/qwt[0-9] -> /usr/include/qwt ? or maybe someone can also attempt to persuade the Qwt folks to adopt the package config infrastructure? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] contactless transaction using gnuradio?
On Tue, Sep 4, 2012 at 10:51 AM, Norman Khine wrote:
> hi, i can get the information into and out of GNU radio using tropo
> https://www.tropo.com/how-it-works/ type application i guess!
>
> but was interested to see working examples of how to work with the data once
> it has been received, for example, if i have a python script which creates a
> dictionary or a key:value object this then generates a unique signal then to
> be able to process this signal and read the key:value object.
Well, we're really just interested in getting data in and out of a
communication application. Once you have the data, it's a bit outside
of our box. You might find some useful applications over at cgran.org
that use GNU Radio with other data sources/sinks for inspiration.
> is my understanding correct of the process and are there any security issues
> with this?
>
> thanks
And yes, I'm sure there are security issues. Aren't there always :)
Tom
> On Tue, Sep 4, 2012 at 2:59 PM, Tom Rondeau wrote:
>>
>> On Sat, Sep 1, 2012 at 5:40 PM, Norman Khine wrote:
>> > hello,
>> > i am interested in learning if it is possible to use gnuradio to
>> > implement a
>> > similar application to how tagpay works, here are some details
>> > http://www.tagattitude.fr/en/products/technology
>> >
>> > any advise much appreciated.
>> >
>> > norman
>>
>> Norman,
>>
>> From a signal processing standpoint, sure, GNU Radio should work with
>> the basic idea. The issue you face is how to get the information into
>> and out of GNU Radio to the external world. You might be able to use
>> the audio I/O, but my guess is that you'll need some more specialized
>> equipment. Of course, I say this after a 1 minute look at that
>> website, so I'm sure there are subtleties that I'm missing.
>>
>> Tom
>
>
>
>
> --
> %>>> "".join( [ {'*':'@','^':'.'}.get(c,None) or chr(97+(ord(c)-83)%26) for
> c in ",adym,*)&uzq^zqf" ] )
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] request to add openSUSE 12.1 support to the build-gnuradio script
On Tue, Sep 4, 2012 at 11:02 AM, KB3CS - Chris wrote: > there are two qwt packages involved: libqwt5 and qwt-devel That's pretty standard. > maybe one rule for /usr/include/qwt and then a symlink from > /usr/include/qwt[0-9] -> /usr/include/qwt ? We already look in /usr/include/qwt, so if you symlinked there, yes that should work. > or maybe someone can also attempt to persuade the Qwt folks to adopt the > package config infrastructure? I've not had any contact with the developers and so I don't know why they don't use it. QT projects tend to have a different configuration and setup than what we're used to, so perhaps they expect, and most of their users use, a different setup. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO HW Interface
On Tue, Sep 4, 2012 at 7:51 AM, wrote: > ** > > On 04 Sep 2012 10:48, Tom Rondeau wrote: > > I'm not sure that I consider what they do an abstraction layer. They just > switch between a handful of devices. Tom > > Anything that reduces/eliminates the need for multiple flow-graphs to > support different devices with a similar "high level" interface is a good > thing. For that, gr-osmosdr works quite well. > A useful abstraction layer would provide an 'upper API' that user code would rely on for providing a stable, common interface to program to, while also providing a 'lower API' to device manufacturers to register with (at runtime library initialization or as loadable modules) to inform GNU Radio of device capabilities and to perform actual API calls. The challenge is in coming up with an upper API abstraction that adequately covers the common functions of device discovery, configuration, naming, streaming vs. burst data transfers, metadata, multiple device support, synchronization, etc., for a variety of devices, but that also allows users to get at any vendor specific features that don't fit into the abstraction. I could certainly see developing a 'gr-sdr' component that provides the upper API source and sink blocks and allows other blocks or libraries to hook in underneath. That part, though, is fairly mechanical in nature (pluggable APIs go back decades). I'd want to see a well-thought out upper and lower abstraction that people are happy with before writing any code. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 BLOCK ERROR IN GNURADIO 3.6.2
On 09/04/2012 12:17 AM, Muhammad JUNAID wrote:
> hello All,
> dose any one have idea about this error?
> i install USRP block in gnuradio 3.6.2 for this file but still have an error.
> root@Junaid-VPCF13UFX:/home/muhammadjunaid/airprobe/gsm-receiver/src/python#
> ./gsm_receive_usrp2.py
> Traceback (most recent call last):
> File "./gsm_receive_usrp2.py", line 6, in
> from gnuradio import gr, gru, blks2
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2/__init__.py",
> line 37, in
> exec "from gnuradio.blks2impl.%s import *" % (f,)
> File "", line 1, in
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2impl/cvsd.py",
> line 24, in
> from gnuradio.vocoder import cvsd_vocoder
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/vocoder/cvsd_vocoder.py",
> line 26, in
> _cvsd_vocoder = swig_import_helper()
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/vocoder/cvsd_vocoder.py",
> line 22, in swig_import_helper
> _mod = imp.load_module('_cvsd_vocoder', fp, pathname, description)
> ImportError: libgnuradio-cvsd-vocoder-3.4.2.so.0: cannot open shared object
> file: No such file or directory
>
If this is a debian based machine, its often necessary to run sudo
ldconfig to fix these kind of issues.
-josh
> Thanks
> Regards
> Muhammad Junaid
> m_junaid0...@yahoo.com
> http://junaidmuhammad.webs.com/
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multiply Const block
Hi, I'm using the Mutliply Const block in my flow graph. IO type: complex and Constant: x+yj. I used 2 sliders to adjust x and y values. But only the slider for x values works. The slider for y values does not work and get the system to crash. Can anyone help me understand this? Regards. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hafl duplex for N210 + XCVR2450
On 09/04/2012 07:33 AM, Anjan Rayamajhi wrote: > Hi, > > I had question about using N210 and XCVR2450 in a half-duplex scenario. I > have used tx_sob and tx_eob stream tags hoping for a switch from default RX > to TX whenever there is a packet to transmit. What happens is both sides > initiate with LED C constantly ON ( default to receiving, I guess ) but as > the packet comes with the two stream tags attached, I do see the > transmitting led A ON but the receiving LED C is also ON at the same time. > Should not there be a switch from RX to TX and LED C be OFF. I am not being > able to receive anything is this scenario though transmitting side does > transmit but there is no activity in the receiving end. > > I will be thankful for any comments. > When transmitting, the mixer should go into TX mode regardless of RXing or not. In other words, the TX state overrides the RX state. So it should be ok to continuously receive samples, that wont disrupt transmit. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiply Const block
On 09/04/2012 10:21 AM, guelord ingala wrote: > Hi, I'm using the Mutliply Const block in my flow graph. IO type: > complex and Constant: x+yj. I used 2 sliders to adjust x and y > values. But only the slider for x values works. The slider for y > values does not work and get the system to crash. Can anyone help me > understand this? Regards. > > This should work, I think I have even done it before... hmmm Can you attach the test code that demonstrates the problem? GRC flowgraph or python file? -josh > > ___ 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] Queue Source not being processed by DPSK Demod Block
I'm trying to get a channel estimate, therefore I need to access the data before the demodulator, since the demodulator will quantize the data. My flow-graph isnt using USRP's for the meantime, just a channel model. So my system receiver goes like this: CHANNEL_MODEL -> MESSAGE_SINK -> DO SOME PYTHON PROCESSING -> MESSAGE_SOURCE -> DEMODULATOR -> FILE_SINK I was trying to do this in C++ originally but ran into a lot of problem with external Linear Algebra libraries with SWIG. -Travis On Tue, Sep 4, 2012 at 10:26 AM, Tom Rondeau wrote: > On Mon, Sep 3, 2012 at 5:44 PM, Travis Collins > wrote: >> By "not processing data" I mean I look at the size of the source >> queue, which is attached to the dpsk_demod block and it just grows >> without data being removed. I just use the queue.count() method to >> observe this. I can even stop adding data to the message source block >> and the queue count remains the same. >> >> Yes I'm using the dpsk_demod supplied with GNU-Radio. When you >> mention the modulator, that doesnt apply here correct? Since Im using >> only a demod and that should take complex data and then output packet >> bits. >> >> When I convert the numpy array to a large string I get segmentation >> faults now even at very low sample rates. Here is a link to the >> flow-graph if you wanna take a look: http://pastebin.com/M2CrVPwP >> >> -Travis > > Ah, I see my confusion. You're talking about adding to the > demodulators queue. Inserting into the message queue made me think you > were working on the modulator side. In this case, the demodulator > itself is what inserts the messages. It's your task (or, more > precisely, the application's task) to remove the messages from the > queue; in other words, the queue holds the frames created by the > demodulator/receiver chain. Look in gr-digital/python/pkt.py in the > _queue_watcher_thread function. That's where the messages are being > popped off the queue. > > The demodulator expects a stream of complex values as inputs (from, > say, a USRP source). > > Tom > > > >> On Sat, Sep 1, 2012 at 11:32 AM, Tom Rondeau wrote: >>> On Fri, Aug 31, 2012 at 3:13 PM, Travis Collins >>> wrote: Ive change the connected block from a dbpsk_demod to a null_sink and a file_sink and the queue is processed, but I'm still having an issue with the demod block. I believe the problem has to be with the data type conversion "processed.tostring()". Should I convert each individual value of the numpy array to a string and append them together or is there a better way? The numpy array itself is made up of complex data. -Travis >>> >>> Hi Travis, >>> >>> Can you provide more details when you say that it's not processing the >>> data? What does that actually mean? Is it not doing anything or just >>> not doing what you expect? >>> >>> The numpy array shouldn't be a problem since you are converting it to >>> a string directly. Although make sure that what tostring() returns is >>> what you think it should return. >>> >>> As for the dpsk modulator: is that the modulator from GNU Radio? Are >>> you basically trying to do what we do in >>> examples/narrowband/benchmark_tx.py? If so, that modulator expects >>> (packed) bits, not complex samples. It will convert the bits to >>> complex samples internally. >>> >>> Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] seg fault in volk_32f_s32f_multiply_32f_a_sse gnuradio v 3.6.1
> I'll be interested to see how cmake reports the architecture checks for VOLK > here. pasted below. Hopefully the mailers won't mangle, if so i'll post it to a web page and send a link. > What happens if you just have a sig_source_f->multiply_ff->null_sink? :-( It works perfectly, without any crashes whatsoever. Will have to try harder to isolate it ... Max ~~~ Script started on Tue 04 Sep 2012 03:49:30 PM EDT ~/tmp/gnuradio-3.6.1/build$ cmake ../ -- 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. -- Found Git: /usr/bin/git -- Performing Test HAVE_VISIBILITY_HIDDEN -- Performing Test HAVE_VISIBILITY_HIDDEN - Success -- Performing Test HAVE_WARN_SIGN_COMPARE -- Performing Test HAVE_WARN_SIGN_COMPARE - Success -- Performing Test HAVE_WARN_ALL -- Performing Test HAVE_WARN_ALL - Success -- Performing Test HAVE_WARN_NO_UNINITIALIZED -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success -- Found PythonLibs: /usr/lib/libpython2.7.so -- Found SWIG: /usr/bin/swig (found version "1.3.40") -- Minimum SWIG version required is 1.3.31 -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring python-support support... -- Dependency PYTHONLIBS_FOUND = TRUE -- Dependency SWIG_FOUND = TRUE -- Dependency SWIG_VERSION_CHECK = TRUE -- Enabling python-support support. -- Override with -DENABLE_PYTHON=ON/OFF -- checking for module 'cppunit' -- found cppunit, version 1.12.1 -- Found CPPUNIT: /usr/lib/libcppunit.so;dl -- -- Configuring testing-support support... -- Dependency CPPUNIT_FOUND = TRUE -- Enabling testing-support support. -- Override with -DENABLE_TESTING=ON/OFF -- -- Configuring volk support... -- Enabling volk support. -- Override with -DENABLE_VOLK=ON/OFF -- Found PythonInterp: /usr/bin/python2.7 -- -- Python checking for python >= 2.5 -- Python checking for python >= 2.5 - found -- -- Python checking for Cheetah >= 2.0.0 -- Python checking for Cheetah >= 2.0.0 - found -- Boost version: 1.42.0 -- Found the following Boost libraries: -- unit_test_framework -- checking for module 'orc-0.4 > 0.4.11' -- package 'orc-0.4 > 0.4.11' not found -- orc files (missing: ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE) -- Looking for cpuid.h -- Looking for cpuid.h - found -- Looking for intrin.h -- Looking for intrin.h - not found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for dlfcn.h -- Looking for dlfcn.h - found -- Compiler name: GNU -- x86* CPU detected -- Performing Test have_maltivec -- Performing Test have_maltivec - Failed -- Performing Test have_mfpu_neon -- Performing Test have_mfpu_neon - Failed -- Performing Test have_mfloat_abi_softfp -- Performing Test have_mfloat_abi_softfp - Failed -- Performing Test have_funsafe_math_optimizations -- Performing Test have_funsafe_math_optimizations - Success -- Performing Test have_m32 -- Performing Test have_m32 - Success -- Performing Test have_m64 -- Performing Test have_m64 - Failed -- Performing Test have_m3dnow -- Performing Test have_m3dnow - Success -- Performing Test have_msse4_2 -- Performing Test have_msse4_2 - Success -- Performing Test have_mpopcnt -- Performing Test have_mpopcnt - Success -- Performing Test have_mmmx -- Performing Test have_mmmx - Success -- Performing Test have_msse -- Performing Test have_msse - Success -- Performing Test have_msse2 -- Performing Test have_msse2 - Success -- Performing Test have_msse3 -- Performing Test have_msse3 - Success -- Performing Test have_mssse3 -- Performing Test have_mssse3 - Success -- Performing Test have_msse4a -- Performing Test have_msse4a - Success -- Performing Test have_msse4_1 -- Performing Test have_msse4_1 - Success -- Performing Test have_mavx -- Performing Test have_mavx - Success -- ORC support not found, Overruled arch orc -- Check size of void*[8] -- Check size of void*[8] - done -- CPU width is 32 bits, Overruled arch 64 -- Available architectures: generic;32;3dnow;abm;popcount;mmx;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx -- Available machines: generic;sse2_32;sse3_32;ssse3_32;sse4_a_32;sse4_1_32;sse4_2_32;avx_32 -- Did not find liborc and orcc, disabling orc support... -- Using install prefix: /usr/local -- TRY_SHM_VMCIRCBUF set to ON. -- Found Doxygen: /usr/bin/doxygen -- Could NOT find Sphinx (missing: SPHINX_EXE
Re: [Discuss-gnuradio] GNURADIO HW Interface
On Tue, Sep 04, 2012 at 10:29:38AM -0400, Tom Rondeau wrote: > Similarly, the wiki is a place where anyone can get access to > update it, so if someone wants to offer their hardware solution on the > page, it's not very difficult. I'll put in my usual preaching here: As Tom said, gnuradio.org is a wiki. If *anyone* has stuff to offer here, please add it! Apart from the hardware page, there's other pages which will only work and stay up-to-date if people contribute. Here's a couple of pages anyone can help to maintain: - Tutorials (both on-site and external; if you've written something about GNU Radio, don't hesitate, either paste it here or post a link) - Downloadable examples - Downloadable sample streams (baseband files) - Academical papers on GNU Radio - The "who's using GR" page - The FAQ And there's more. Don't just consume, participate! M -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgp8fRD9dO6T4.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] seg fault in volk_32f_s32f_multiply_32f_a_sse gnuradio v 3.6.1
> Yes, looks like it. But it's an Atom, which might change things. I > know we had some issues on Atom's before, but I thought that we worked > them out. I'll be interested to see how cmake reports the architecture > checks for VOLK here. Hi Tom I've made some further progress, and this may be premature, but I'll go so far as to say we can rule this out entirely. Here's a strawman theory - criticism of the theory is invited, shooting it down would be welcomed ; ) Our app uses lots of disconnect() and connect() calls because our appetite for widgets is bigger than the CPU available. Also, since the widgets are tab-selectable there is only one widget visible at a time. So when the user hits a tab we call disconnect and connect (surrounded by lock() / unlock() of course) in order to dynamically create a flow graph that connects up all the elements needed by that tab (and disconnects the elements, filters, demods, FFT's and other blocks that aren't needed by this tab, to conserve CPU. The theory is that this is "messing up" the boundary alignments of the operands to the SSE instructions, making them no longer properly aligned, resulting in a GPF. Here's the minimal python app , it seg faults in volk 100% reliably for me. If the call to shuffle() is removed, the script does not crash. Max p.s. kindly let me know if this code isn't properly machine-readable ~~~ #!/usr/bin/env python import math import time from gnuradio import gr, gru, audio, eng_notation, blks2, optfir class app_top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self, "mhp") self.source = gr.sig_source_f(48000, gr.GR_TRI_WAVE, 1.0, 1.0, 0) self.amp = gr.multiply_const_ff(65.0) self.sink = gr.null_sink(gr.sizeof_float) self.connect(self.source, self.amp, self.sink) self.amp_connected = True def shuffle(self): self.lock() if self.amp_connected: self.disconnect(self.source, self.amp, self.sink) self.connect(self.source, self.sink) else: self.disconnect(self.source, self.sink) self.connect(self.source, self.amp, self.sink) self.amp_connected = not self.amp_connected self.unlock() if __name__ == "__main__": tb = app_top_block() tb.start() while True: time.sleep(0.1) tb.shuffle() ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio release 3.6.2 available for download
GNU Radio release 3.6.2 is now available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.6.2.tar.gz This release contains the new gr-filter top-level component, some new signal processing blocks, and numerous bug fixes. The detailed changelog is here: http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_6_2 Contributors this release: Ben Reynwar Chí-Thanh Christopher Nguyễn Hendrik van Wyk Jaroslav Skarvada Johnathan Corgan Josh Blum Martin Braun Nicholas Corgan Nick Foster Tim O'Shea Tom Rondeau Wayne Roberts Enjoy! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
