August 2012 - osmocom-sdr - lists.osmocom.org

Mis-detected E4000 instead of FC0013 tuner when using NOXON DAB Stick on Raspberry Pi

by Christoph Gommel

Hello Guys, First of all: I am amazed by your project - many ideas come up in my head what can be done with this tiny cheap SDR. I have tested rtl_sdr with a linux-vm on my Mac successfully but wanted to run it on my raspberry pi. Unfortunately and thithout an explainable reason to me the tools detect an E4000 instead of the soldered FC0013 on my stick - but only on the PI. To fix this issue I have changed the detection order in librtlsdr.c: diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 3a67b53..cb34f1d 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1073,13 +1073,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) /* Probe tuners */ rtlsdr_set_i2c_repeater(dev, 1); - reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR); - if (reg == E4K_CHECK_VAL) { - fprintf(stderr, "Found Elonics E4000 tuner\n"); - dev->tuner_type = RTLSDR_TUNER_E4000; - goto found; - } - reg = rtlsdr_i2c_read_reg(dev, FC0013_I2C_ADDR, FC0013_CHECK_ADDR); if (reg == FC0013_CHECK_VAL) { fprintf(stderr, "Found Fitipower FC0013 tuner\n"); @@ -1088,6 +1081,13 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) goto found; } + reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR); + if (reg == E4K_CHECK_VAL) { + fprintf(stderr, "Found Elonics E4000 tuner\n"); + dev->tuner_type = RTLSDR_TUNER_E4000; + goto found; + } + /* initialise GPIOs */ rtlsdr_set_gpio_output(dev, 5); After compiling the lib the FC0013 is detected and the sticks works great on my Pi. Of course this is not a perfect solution and I will figure out later in depth WHY the E4K_CHECK_VAL comes out of the FC0013. Anybody else who has or had the same problems? the Hardware used is: Bus 001 Device 004: ID 0ccd:00b3 TerraTec Electronic GmbH NOXON DAB/DAB+ Stick regards Christoph

11 years, 6 months

5
4
0 0

Fixed a division by zero bug in rtl_fm that appears on OS X

by Christoph Gommel

Hallo guys, I tried to isolate the Floating point exception that prevents rtl_fm from running on my OS X Machine. XCode's code analysis mechanism showed pointed out a location of some code that not only might bring up a division by zero but brought this on my machine. After adding some basic handling rtl_fm runs now on my Mac but does not deliver appropiate sound. It's chopped and not understandable. Despite the fact that gnuradio performs great on the same machine there seem to be more bugs present I do not understand at the moment. But first of all this small patch should be added to the main code base. Sorry for not knowing more about git than executing "git diff" ;( I am a daily svn user who does not understand the non-linear anarchistic version management behind git by now... diff --git a/src/rtl_fm.c b/src/rtl_fm.c index 0350d8b..d00ef2d 100644 --- a/src/rtl_fm.c +++ b/src/rtl_fm.c @@ -313,13 +313,17 @@ int mad(int *samples, int len, int step) int i=0, sum=0, ave=0; for (i=0; i<len; i+=step) { sum += samples[i]; - } - ave = sum / (len * step); + } + if (len * step) //Avoid Division by zero errors + ave = sum / (len * step); sum = 0; for (i=0; i<len; i+=step) { sum += abs(samples[i] - ave); - } - return sum / (len * step); + } + if (len * step) //Avoid Division by zero errors + return sum / (len * step); + else + return (0); } int post_squelch(struct fm_state *fm)

11 years, 7 months

1
0
0 0

Re: LTE Cell Scanner

by James Peroulas

> Date: Mon, 27 Aug 2012 12:27:21 +0200 > From: Christian Buchner <christian.buchner(a)gmail.com> > > For some reason, your CellSearch software worked the second time I ran > it. Here's the result for a scan in Munich. The two frequencies found > correspond to the operators O2 and Vodafone. Deutsche Telekom is > either not using the 800 MHz band here, or I happen to be out of the > reception range for this dongle. > > Detected the following cells: > C: CP type ; P: PHICH duration ; PR: PHICH resource type > CID fc foff RXPWR C nRB P PR CrystalCorrectionFactor > 449 796M -13.2k -47.7 N 50 N one 0.99998344473785039099 > 372 806M -13.2k -43.7 N 50 N one 0.99998362964129883235 I see that the received signal power is very low at -44dB, so it kind of makes sense that these cells would not be detected every time you run the program. I suspect that if you moved outdoors or used a tuned LTE antenna, these cells would be detectable more reliably. > This software project is way cool! I am surprised how precise my crystal is. > > Now who's willing to extend the code to combine several dongles to > scan the full 10 MHz band and to analyze the allocated resources > signalled on the PDCCH so we can generate statistics on cell load and > number of UEs served? Wow, I think that would be a major undertaking for these dongles! I think that's a task best suited for the USRP and the OpenLTE project :) JP

11 years, 7 months

1
0
0 0

LTE Cell Scanner

by James Peroulas

I just released an LTE cell scanner based on the rtlsdr library. If you're interested, the code is available on github: https://github.com/Evrytania/LTE-Cell-Scanner This code will search for all the LTE cells in your area and will also report the frequency error of your dongle. BR, James P.S. Many thanks for the rtlsdr library! -- Integrity is a binary state - either you have it or you don’t. - John Doerr

11 years, 8 months

5
9
0 0

Re: osmocom-sdr Digest, Vol 9, Issue 16

by James Peroulas

> Message: 1 > Date: Fri, 24 Aug 2012 18:11:59 +0200 > From: Christian Buchner <christian.buchner(a)gmail.com> > To: osmocom-sdr(a)lists.osmocom.org > Subject: Re: LTE Cell Scanner > Message-ID: > <CALm6U+pZd8Ufmu1UCOQ_+0ebMc_joDOh9_dFW0g=1QW=M2p02A(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I was able to build it on Ubuntu 9.04 (Jaunty Jackalope) with a little > upgrading of some dependencies. > > CellSearch is now crashing in the static initializer for the > ROM_TABLES object. *sigh* > > Would anyone have an idea what may be is causing it? > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb773b910 (LWP 21087)] > 0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from > /usr/local/lib/libitpp.so.7 > Current language: auto; currently asm > (gdb) where > #0 0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from > /usr/local/lib/libitpp.so.7 > #1 0x00f74ada in itpp::Vec<std::complex<double> >::operator= () from > /usr/local/lib/libitpp.so.7 > #2 0x0808b0cd in PSS_fd::PSS_fd () > #3 0x08094444 in global constructors keyed to ROM_TABLES () > > Christian Are you still having problems with this? Can you try upgrading to the latest github code? I changed the initialization sequence for the ROM_TABLES and it might fix your problem too. BR, James

11 years, 8 months

1
0
0 0

RTL_FM fails on OS X

by Christoph Gommel

Hello, I was completely happy that rtl-sdr builds without any problems in my iMac (with OSX 10.8.1 and latest Macports). Using a RLT2832-Dongle that is plugged into my mac on other machines via rtl_tcp works well, also recording data is working. What fails is running rtl_fm: iGommel:build chg$ rtl_fm -f 97300000 -s 44100 test.raw Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000291 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Elonics E4000 tuner Oversampling input by: 23x. Oversampling output by: 1x. Buffer size: 8.08ms Tuned to 97553575 Hz. Sampling at 1014300 Hz. Exact sample rate is: 1014300.020041 Hz Tuner gain set to -1.00 dB. Floating point exception: 8 Unfortunately i don't have the debugging skills to find the position of the Floating point exception without a high-level GUI ;) Any idea what can be done by me to help chasing the bug? Christoph

11 years, 8 months

1
0
0 0

BONANZA - The e4000 *complete* reference document :)

by Ben Ryan

Hey all, Got some gold for ya's. Registers, the works. Even a reference design schematic. Grab it while it's hot, before the lawyers catch on.. and thanks guys for all your hard work with RTLSDR! https://skydrive.live.com/redir?resid=E55F3F5F75B5A7BB!1160

11 years, 8 months

1
0
0 0

[benzandstra@caiway.nl: Small comment about the rtl-sdr wiki]

by Harald Welte

FYI, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

11 years, 8 months

1
0
0 0

[jarribas@cttc.es: GNSS-SDR now supports the RTLSDR signal source]

by Harald Welte

Hi all! I'm forwarding this announcement from the GNSS-SDR developers. I will also put it on the sdr.osmocom.org site. Congratulations to steve-m, horizon, hoernchen and the team! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

11 years, 8 months

1
0
0 0

Say Enter "RTL readlen=524288" in the 'ExtIO : Device hint' edit field, when that is what you mean

by Jay Salsburg

OK I get it. I wish those who write this stuff were not so Cryptic and Acronymous. On this page ... http://wiki.spench.net/wiki/USRP_Interfaces the author has an entry that looks like this "RTL readlen=524288" yet nowhere in the immediate text is there any language stating to enter this text in the 'ExtIO : Device hint' edit field, you have to sort of guess the author thoughts. No one is ever thinking like the one who is doing the original thinking so to reproduce original thinking adequate references to what the author is thinking is required to reproduce the original thoughts in the reader's mind. Literate illustration makes everything so much easier (and a liberal sprinkling screen shots). Thanks Jay Salsburg

11 years, 8 months

4
6
0 0

The real problem with this thing

by Jay Salsburg

I have been hacking into one of those $20 DVB-T TV Tuner Dongles. To get it to tune to the Freq I want I use the usual method with the ExtIO Drivers. The real problem with this thing, as far as making good use of the valuable E4000, is the RTL2832, even though controlling the Tuner through the USB requires the RTL2832. This clumsy Analog to Digital Converter / USB interface Chip, does not have the Audio dynamic range needed for my purposes. The infuriating predilection it has to crash every time you want to shift frequency is another disadvantage. Since the Owners of the E4000 have gone into Bankruptcy, I am taking the initiative to hack the Tuner. First, I attached a high gain audio amplifier's input directly to the Tuner's output then to a 96K Sample per Second, 24 Bit Audio card to observe a high quality spectral image from the tuner. Next is to hack into and record the I2C sent to the Tuner, so it may be controlled independent of that infuriating RTL2832. If anyone has done this, please share your code and understanding. Thanks Jay Salsburg

11 years, 8 months

3
6
0 0

Re: [Discuss-gnuradio] FCD/Alsa bug (Re: Bug hunting)

by don.lewis＠dses.org

Sent via the HTC V..b.livid™, anbURL: http://maps.google.com/maps?q=40.031769,-105.2;Kn)na?bks3213, 3128 Bell Dr, Boulder, CO 80301, USA AT&T 4G -3$/-)44+$LTE( (::,2mk: ----- Reply message ----- From: "Christian Gagneraud" <chris(a)techworks.ie> To: "Dimitri Stolnikov" <horiz0n(a)gmx.net> Cc: <discuss-gnuradio(a)gnu.org>, <osmocom-sdr(a)lists.osmocom.org> Subject: [Discuss-gnuradio] FCD/Alsa bug (Re: Bug hunting) Date: Wed, Aug 8, 2012 9:02 am Cross posting to discuss-gnuradio. The bug in question is that if you instanciate an alsa source on a busy device (opened by another app), then the program crashed. On 08/08/12 00:23, Dimitri Stolnikov wrote: > Hi Christian, [...] > > The other problem (segfault on trow in ctor) still has to be addressed. Yes, I started to investigate, and it seems to me that this is not a gr-osmosdr bug, but it's a gnuradio one, caused by gr-fcd. This simple test program have the same problem, yet it only uses gr-fcd. #include <iostream> #include <fcd_source_c.h> int main(int argc, char **argv) { fcd_source_c_sptr fsrc; try { fsrc = fcd_make_source_c("hw:2"); // KO, from gr-fcd } catch (std::runtime_error &e) { std::cerr << "Error!\n"; } exit(0); } g++ test.cc -o test -I/usr/local/include/gnuradio -lgnuradio-fcd Here is the log: audio_alsa_source[hw:2]: Device or resource busy Error! *** glibc detected *** /home/cgagneraud/sdr/gr-osmosdr/test: free(): invalid pointer: 0x08052e3c *** [...] And here is a cleaned up backtrace: operator delete gruel::msg_accepter::~msg_accepter checked_delete<gr_hier_block2> boost::detail::sp_counted_impl_p<gr_hier_block2>::dispose [...] const, boost::shared_ptr<gr_basic_block> > > >::~map __cxa_finalize __do_global_dtors_aux [...] main The problem is related to gnuradio-core/src/lib/runtime/gr_sptr_magic.{h,cc} and the static std::map in there. gr_hier_block2 ctor insert "this" in this map, but then in fcd_source ctor, audio_alsa_source ctor throws an exception, so "this" (gr_hier_block2/fcd_source) is not a valid pointer anymore. When the program exits, the map get cleanup up and free is called on this pointer. It's not possible to cleanup the map in fcd_source, because the dtor is not called when exception occurs in the ctor (which, btw, leads to some memory leaks in alsa_source: namely d_hw_params and d_sw_params). It's a bad idea to call fetch_initial_sptr(this) before throwing in the ctor, because it seems the object get deleted.

11 years, 8 months

1
0
0 0

just learning to fly with sdr ... and hit a 64-bit snag

by Gary Lawrence Murphy

First off, this is my first post to the group and I want to thank everyone who has worked to get this kit as far as it is; I was deathly worried that I might be stuck with unusable hardware, and it is still unusuable, but there seems to be light at the end of the SDR tunnel and I'm hoping this is the right forum for asking newbie questions :) Here's where I am so far: I have the Hama Nano DVB-T+DAB+FM with the Elonics E4000 tuner and my goal is really very modest (I hope) in that I only want to tune in one ordinary analog FM station, the FM transmitter in the next room that supplies our house with music from our MP3 collection. Rather than pay $40 at walmart for a radio for my lab, I thought I'd spend $20 on the USB device and have some fun in the process. And it's been fun: I found the recipe for the rtl_fm using the alsa aplay, and I assume the examples were concerned with some other sort of radio (shortwave?) because the recommended 48k sampling sounded like a taxi radio! Not really Easy Listening sort of audio. with some experimenting I found a formula that is still heavily distorted, but recognizable as music: rtl_fm -f 96.3e6 -s 192000 -l 5 -| aplay -t raw -f s16_le -r 192k -c 1 the trouble was that it wouldn't play continuously on my 3300-bogomips netbook, so I moved the code over to my 64-bit dual-core laptop and that's where a strange thing happened: when run as a regular user, the code aborts giving strange (unicode?) gibberish as the device name, but when run as root, the name is correctly reported although the program aborts. ~/Work/dev$ rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f s16_le Found 1 device(s): 0: , mX��, SN: ��z� Using device 0: Generic RTL2832U (e.g. hama nano) usb_open error -3 Failed to open rtlsdr device #0. ~/Work/dev$ sudo rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f s16_le Found 1 device(s): 0: Generic, RTL2832U, SN: 77771111153705700 Using device 0: Generic RTL2832U (e.g. hama nano) usb_claim_interface error -6 Failed to open rtlsdr device #0. on the 32-bit platform, the *Using device* line is followed by Found Elonics E4000 tuner Oversampling input by: 6x Oversampling output by: 1x is there perhaps some simple config setting that I've overlooked in the 64-bit box? Both are running Ubuntu 12.04 here are the kernel messages on loading the device on 64bit Aug 9 13:47:58 strata kernel: [200306.632008] usb 3-1: new high-speed USB device number 3 using xhci_hcd Aug 9 13:47:58 strata kernel: [200306.663830] usb 3-1: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 microframes Aug 9 13:47:58 strata kernel: [200306.669822] dvb-usb: found a 'RTL2832U DVB-T USB DEVICE' in warm state. Aug 9 13:47:58 strata kernel: [200306.669840] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Aug 9 13:47:58 strata kernel: [200306.671500] DVB: registering new adapter (RTL2832U DVB-T USB DEVICE) Aug 9 13:47:58 strata kernel: [200306.689815] RTL2832U usb_init_bulk_setting : USB2.0 HIGH SPEED (480Mb/s) Aug 9 13:47:58 strata mtp-probe: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1" Aug 9 13:47:59 strata kernel: [200306.972506] RTL2832U check_tuner_type : E4000 tuner on board... Aug 9 13:47:59 strata mtp-probe: bus: 3, device: 3 was not an MTP device Aug 9 13:47:59 strata kernel: [200307.552737] DVB: registering adapter 0 frontend 0 (Realtek DVB-T RTL2832)... Aug 9 13:47:59 strata kernel: [200307.553116] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1/input/input15 Aug 9 13:47:59 strata kernel: [200307.553243] dvb-usb: schedule remote query interval to 287 msecs. Aug 9 13:47:59 strata kernel: [200307.553251] dvb-usb: RTL2832U DVB-T USB DEVICE successfully initialized and connected. I notice that it DOESN'T say "*will pass the complete MPEG2 transport stream to the software demuxer"* as it does on the 32bit side. Also, what is the syntax for the -g switch? I have tried integers, decimals and the string -3dB and in all cases I get the message *Warning: Failed to set tuner gain* -- could the gain control simply be unsupported by my device? Lastly, I'd like to ask the hard question: are my goals here feasible? Is this an appropriate device for listening to FM broadcasts at the computer or is this more a hobbyist's SDR playground and, like a dancing bear, the bear doesn't dance amazingling, it is only amazing that the bear dances at all ;) -- *Have Blog, Will Travel: blog.teledyn.com* *A Serviceable Substitute: post.teledyn.com*

11 years, 8 months

2
2
0 0

Bug hunting

by Christian Gagneraud

Hi, Is there any bug tracker for the gr-osmosdr somewhere? It would be nice if the "audio_alsa_source[hw:X]: Device or resource busy" could be fixed. The problem with that bug is you can't even interogate the device driver for supported gain, etc... If the device is used by another application. For example, I have permanently 2 devices plugged in, I use an FCD to send AIS data to aishub.com, and a RTL to experiment with. The problem with this bug is that if you use python you can't even catch the exception, it simply crash the script. I think that the behaviour is different when using C++. Another "bug" I discovered is that if you just do a device scan to print available device and exit the python script, it will generate plenty of error messages like "libusb:warning [cancel_bulk_transfer] unrecognised discard errno 9", the workaround is to simply wait a bit before exiting. It seems that some USB packets are still pending after calling osmosdr.source_c(). Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

11 years, 8 months

4
11
0 0

[PATCH] [rtl-sdr] Relaxed async state machine

by chris＠techworks.ie

From: Christian Gagneraud <chris(a)techworks.ie> gr-osmosdr uses the driver in a multi-thread context, as a side effect the cancel_async() can be called before read_async(), in such a case the cancel is "forgotten". This patch fixed that by being a bit more relaxed with state machine transitions. This patch doesn't fix any race conditions, it just make an anoying one less likely to happen. This patch goes along this one [1] [1] http://lists.osmocom.org/pipermail/osmocom-sdr/2012-August/000201.html Signed-off-by: Christian Gagneraud <chris(a)techworks.ie> --- src/librtlsdr.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 4e54d8e..d83010d 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1256,6 +1256,12 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, if (!dev) return -1; + /* It can happen if cancel_async is called before read_async */ + if (dev->async_status != RTLSDR_INACTIVE) + return -1; + + dev->async_status = RTLSDR_RUNNING; + dev->cb = cb; dev->cb_ctx = ctx; @@ -1284,8 +1290,6 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, libusb_submit_transfer(dev->xfer[i]); } - dev->async_status = RTLSDR_RUNNING; - while (RTLSDR_INACTIVE != dev->async_status) { r = libusb_handle_events_timeout(dev->ctx, &tv); if (r < 0) { @@ -1326,7 +1330,7 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev) if (!dev) return -1; - if (RTLSDR_RUNNING == dev->async_status) { + if (RTLSDR_CANCELING != dev->async_status) { dev->async_status = RTLSDR_CANCELING; return 0; } -- 1.7.7

11 years, 8 months

1
0
0 0

[PATCH] Wait in the destructor for all I/O to finish without a timeout

by Peter Stuge

Signed-off-by: Peter Stuge <peter(a)stuge.se> --- lib/rtl/rtl_source_c.cc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc index 8839a2f..c8cc772 100644 --- a/lib/rtl/rtl_source_c.cc +++ b/lib/rtl/rtl_source_c.cc @@ -180,7 +180,7 @@ rtl_source_c::~rtl_source_c () if (_dev) { _running = false; rtlsdr_cancel_async( _dev ); - _thread.timed_join( boost::posix_time::milliseconds(200) ); + _thread.join(); rtlsdr_close( _dev ); _dev = NULL; } -- 1.7.4.1.343.ga91df.dirty --YZ5djTAD1cGYuMQK--

11 years, 8 months

1
0
0 0

gr-ais with osmosdr

by Christian Gagneraud

Hi there, I saw a message in the July archive (I wasn't subscribed yet at that date) about updating gr-ais with osmosdr support. I was working on the same thing recently, so i decided to publish my fixes on top of Antoine's one. The result can be found here: https://github.com/chgans/gr-ais I got it working with both an FCD and an RTL: ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0 ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0 Strangely passing freq_err=XX parameter to the source (using -D), doesn't work, the use of --error is thus needed (which will do a set_freq_corr()). Antoine, if you want sample file, just let me know. Nick, are you willing to integrate these changing back in gr-ais, Apart from the added automatic decimation filter, the changes are not intrusive at all. The default settings for UHD are 256Khz sampling with decimation filter 4, with this change, the decimation is one when using FCD (96KHz fixed frequency) and 16 for RTL when used at 1.024MHz (this was the minimum working frequency for me). Or maybe would you prefer to allow the user to set it manually, and use this technique as a fall back only. Please let me know what you guys think. Thx, Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

11 years, 8 months

4
10
0 0

Wiki page

by Christian Gagneraud

Hi, I started do add documentation to the wiki page of gr-osmosdr [1]. For now i've just added documentation about the "constructor" parameters. Any feedback welcome. [1] http://sdr.osmocom.org/trac/wiki/GrOsmoSDR PS: Could anyone tell me what the mcr is? (used for osmosdr source) -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

11 years, 8 months

2
2
0 0

[PATCH] Add swig hint for devices_t objects

by chris＠techworks.ie

From: Christian Gagneraud <chris(a)techworks.ie> Signed-off-by: Christian Gagneraud <chris(a)techworks.ie> --- swig/osmosdr_swig.i | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/swig/osmosdr_swig.i b/swig/osmosdr_swig.i index afdbb0e..4205fd6 100644 --- a/swig/osmosdr_swig.i +++ b/swig/osmosdr_swig.i @@ -25,6 +25,7 @@ %ignore osmosdr::device_t::operator[]; //ignore warnings about %extend %template(string_string_dict_t) std::map<std::string, std::string>; //define before device +%template(devices_t)std::vector<osmosdr::device_t>; %include <osmosdr_device.h> %template(range_vector_t) std::vector<osmosdr::range_t>; //define before range -- 1.7.7

11 years, 8 months

1
0
0 0

Iterating over gain ranges with python

by Christian Gagneraud

Hi there, In a python script, I would like to iterate over things like get_gain_names, get_gain_ranges, ... The problem is that these functions return a std::vector<std::string> *. The error i get is: TypeError: 'SwigPyObject' object is not iterable It would be very nice to be able to do something like: for src.get_sample_rates(): # do something for name in get_gain_names(): # do smth I found this: http://reference-man.com/files/generators.i But i haven't been able to use it so far. :( Any help or comments appreciated. Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

11 years, 8 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr August 2012