From thierry.leconte at laposte.net Sat Mar 1 17:17:17 2014 From: thierry.leconte at laposte.net (Thierry Leconte) Date: Sat, 01 Mar 2014 18:17:17 +0100 Subject: acarsdec 2.1 released In-Reply-To: <5309EAC7.9070909@laposte.net> References: <5309EAC7.9070909@laposte.net> Message-ID: <5312161D.1040204@laposte.net> This is a fix and small improvements release * Fix display of uplink messages * add -A option to display only downlink messages * add -g gain option to set rtl dongle preamp gain * add -p ppm to set ppm frequency correction for rtl dongle * improve -o 0 output (now print the beginning of message ) * use sse2 optimized vector math lib for AM demod (more than 40% CPU load improvement) * other small performance optimizations Download here : https://sourceforge.net/projects/acarsdec/files/latest/download?source=files PS :Acarsdec is a multi-channels acars decoder with built-in rtl_sdr front end. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hoofdeigenwijs at gmail.com Sat Mar 1 21:28:36 2014 From: hoofdeigenwijs at gmail.com (Ben Z en de rest) Date: Sat, 1 Mar 2014 22:28:36 +0100 Subject: sdrangelove, make gives error [Solved] Message-ID: Hi, the problem with the installation of sdrangelove is solved. I had mistaken the Qt5 version and I installed the 32 bits version but I am running 64 bits Ubuntu. So make succeeded without errors now. TnX, Ben (can anyone help me how to reply to my own message, so the problem and solution make a thread ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at scottcutler.net Sat Mar 1 23:28:31 2014 From: scott at scottcutler.net (Scott Cutler) Date: Sat, 1 Mar 2014 15:28:31 -0800 Subject: SDRIO: A hardware abstraction layer for SDR devices Message-ID: Some of you may have seen this already when I was asking licensing questions, but others may still be curious. In the course of other development efforts, I had a need for an abstraction layer that had more features than ExtIO. In particular, I wanted transmit support (for my bladeRF), as well as better control over gain and other settings. What I have come up with is SDRIO: a straightforward C interface for interacting with SDR devices. I currently support rtl-sdr, bladeRF, and the Funcube Dongle. Each driver lives in its own module: SDRIO_bladeRF.dll, etc. Applications can load these modules, query if devices are present, and then interact with them. All data transfer is asynchronous. Currently I only support Windows, though the API is OS-agnostic and the drivers (particularly rtl-sdr) should be able to be ported in a straightforward manner. SDRIO is licensed as LGPL. However, because it uses GPL code, it may not be distributed with non-GPL applications. It may still be used with non-GPL applications as long as the distributions are kept wholly separate (no bundling, auto-downloaders, etc.). Code is currently kept at: https://github.com/spcutler/SDRIO Right now it is in a very alpha state, and subject to change. Documentation is also currently minimal, although I hope the API is clear enough to be obvious. I hope to stabilize things once I get some outside feedback and suggestions. Thanks! -Scott PS: Mirics dongle support should be coming soon due to the generosity of a fellow member of this mailing list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bistromath at gmail.com Mon Mar 3 21:35:21 2014 From: bistromath at gmail.com (Nick Foster) Date: Mon, 3 Mar 2014 13:35:21 -0800 Subject: Retrieving device type Message-ID: Hi, gr-osmosdr is great at abstracting the device type, but now I find myself wishing to de-abstract. For instance: HackRF has large DC offset, so I'd like the option to switch in a DC blocking filter when using that source. RTL dongles can't support more than 2.4Msps reliably, so I'd like to be able to cope accordingly at initialization time. Is there a good way to retrieve, say, a string descriptor telling me which particular source I'm using? --n -------------- next part -------------- An HTML attachment was scrubbed... URL: From oz9aec at gmail.com Mon Mar 3 22:02:29 2014 From: oz9aec at gmail.com (Alexandru Csete) Date: Mon, 3 Mar 2014 23:02:29 +0100 Subject: Retrieving device type In-Reply-To: References: Message-ID: On Mon, Mar 3, 2014 at 10:35 PM, Nick Foster wrote: > Hi, > > gr-osmosdr is great at abstracting the device type, but now I find myself > wishing to de-abstract. For instance: HackRF has large DC offset, so I'd > like the option to switch in a DC blocking filter when using that source. > RTL dongles can't support more than 2.4Msps reliably, so I'd like to be able > to cope accordingly at initialization time. > > Is there a good way to retrieve, say, a string descriptor telling me which > particular source I'm using? None that I know of, but aren't you the one who decides what device is in use by passing e.g. "hackrf=0" as argument to the constructor? Alex From bistromath at gmail.com Mon Mar 3 22:04:06 2014 From: bistromath at gmail.com (Nick Foster) Date: Mon, 3 Mar 2014 14:04:06 -0800 Subject: Retrieving device type In-Reply-To: References: Message-ID: Sure. I could explicitly set this, but it means now I need a separate menu item or configuration switch for each Osmo source -- and there are a bunch. Not the end of the world, just hoping for something easier. --n On Mon, Mar 3, 2014 at 2:02 PM, Alexandru Csete wrote: > On Mon, Mar 3, 2014 at 10:35 PM, Nick Foster wrote: > > Hi, > > > > gr-osmosdr is great at abstracting the device type, but now I find myself > > wishing to de-abstract. For instance: HackRF has large DC offset, so I'd > > like the option to switch in a DC blocking filter when using that source. > > RTL dongles can't support more than 2.4Msps reliably, so I'd like to be > able > > to cope accordingly at initialization time. > > > > Is there a good way to retrieve, say, a string descriptor telling me > which > > particular source I'm using? > > None that I know of, but aren't you the one who decides what device is > in use by passing e.g. "hackrf=0" as argument to the constructor? > > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oz9aec at gmail.com Mon Mar 3 22:14:45 2014 From: oz9aec at gmail.com (Alexandru Csete) Date: Mon, 3 Mar 2014 23:14:45 +0100 Subject: Retrieving device type In-Reply-To: References: Message-ID: I must be completely missing something... When you create your source now, don't you already pass it a string with a device descriptor? On Mon, Mar 3, 2014 at 11:04 PM, Nick Foster wrote: > Sure. I could explicitly set this, but it means now I need a separate menu > item or configuration switch for each Osmo source -- and there are a bunch. > Not the end of the world, just hoping for something easier. > > --n > > > On Mon, Mar 3, 2014 at 2:02 PM, Alexandru Csete wrote: >> >> On Mon, Mar 3, 2014 at 10:35 PM, Nick Foster wrote: >> > Hi, >> > >> > gr-osmosdr is great at abstracting the device type, but now I find >> > myself >> > wishing to de-abstract. For instance: HackRF has large DC offset, so I'd >> > like the option to switch in a DC blocking filter when using that >> > source. >> > RTL dongles can't support more than 2.4Msps reliably, so I'd like to be >> > able >> > to cope accordingly at initialization time. >> > >> > Is there a good way to retrieve, say, a string descriptor telling me >> > which >> > particular source I'm using? >> >> None that I know of, but aren't you the one who decides what device is >> in use by passing e.g. "hackrf=0" as argument to the constructor? >> >> Alex > > From bistromath at gmail.com Mon Mar 3 22:17:59 2014 From: bistromath at gmail.com (Nick Foster) Date: Mon, 3 Mar 2014 14:17:59 -0800 Subject: Retrieving device type In-Reply-To: References: Message-ID: I've been letting it autodiscover. --n On Mon, Mar 3, 2014 at 2:14 PM, Alexandru Csete wrote: > I must be completely missing something... When you create your source > now, don't you already pass it a string with a device descriptor? > > On Mon, Mar 3, 2014 at 11:04 PM, Nick Foster wrote: > > Sure. I could explicitly set this, but it means now I need a separate > menu > > item or configuration switch for each Osmo source -- and there are a > bunch. > > Not the end of the world, just hoping for something easier. > > > > --n > > > > > > On Mon, Mar 3, 2014 at 2:02 PM, Alexandru Csete > wrote: > >> > >> On Mon, Mar 3, 2014 at 10:35 PM, Nick Foster > wrote: > >> > Hi, > >> > > >> > gr-osmosdr is great at abstracting the device type, but now I find > >> > myself > >> > wishing to de-abstract. For instance: HackRF has large DC offset, so > I'd > >> > like the option to switch in a DC blocking filter when using that > >> > source. > >> > RTL dongles can't support more than 2.4Msps reliably, so I'd like to > be > >> > able > >> > to cope accordingly at initialization time. > >> > > >> > Is there a good way to retrieve, say, a string descriptor telling me > >> > which > >> > particular source I'm using? > >> > >> None that I know of, but aren't you the one who decides what device is > >> in use by passing e.g. "hackrf=0" as argument to the constructor? > >> > >> Alex > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oz9aec at gmail.com Mon Mar 3 22:27:46 2014 From: oz9aec at gmail.com (Alexandru Csete) Date: Mon, 3 Mar 2014 23:27:46 +0100 Subject: Retrieving device type In-Reply-To: References: Message-ID: I am guessing that if you use the osmosdr::device::find() method, which gives you a list of available devices, the first device in the list will be the one gr-osmosdr chooses to use. Alex On Mon, Mar 3, 2014 at 11:17 PM, Nick Foster wrote: > I've been letting it autodiscover. > > --n > > > On Mon, Mar 3, 2014 at 2:14 PM, Alexandru Csete wrote: >> >> I must be completely missing something... When you create your source >> now, don't you already pass it a string with a device descriptor? >> >> On Mon, Mar 3, 2014 at 11:04 PM, Nick Foster wrote: >> > Sure. I could explicitly set this, but it means now I need a separate >> > menu >> > item or configuration switch for each Osmo source -- and there are a >> > bunch. >> > Not the end of the world, just hoping for something easier. >> > >> > --n >> > >> > >> > On Mon, Mar 3, 2014 at 2:02 PM, Alexandru Csete >> > wrote: >> >> >> >> On Mon, Mar 3, 2014 at 10:35 PM, Nick Foster >> >> wrote: >> >> > Hi, >> >> > >> >> > gr-osmosdr is great at abstracting the device type, but now I find >> >> > myself >> >> > wishing to de-abstract. For instance: HackRF has large DC offset, so >> >> > I'd >> >> > like the option to switch in a DC blocking filter when using that >> >> > source. >> >> > RTL dongles can't support more than 2.4Msps reliably, so I'd like to >> >> > be >> >> > able >> >> > to cope accordingly at initialization time. >> >> > >> >> > Is there a good way to retrieve, say, a string descriptor telling me >> >> > which >> >> > particular source I'm using? >> >> >> >> None that I know of, but aren't you the one who decides what device is >> >> in use by passing e.g. "hackrf=0" as argument to the constructor? >> >> >> >> Alex >> > >> > > > From kpreid at switchb.org Tue Mar 4 01:08:27 2014 From: kpreid at switchb.org (Kevin Reid) Date: Mon, 3 Mar 2014 17:08:27 -0800 Subject: Retrieving device type In-Reply-To: References: Message-ID: <7431FE2F-613C-40D5-9B74-D1B4D4E18848@switchb.org> On Mar 3, 2014, at 14:02, Alexandru Csete wrote: > On Mon, Mar 3, 2014 at 10:35 PM, Nick Foster wrote: >> Hi, >> >> gr-osmosdr is great at abstracting the device type, but now I find myself >> wishing to de-abstract. For instance: HackRF has large DC offset, so I'd >> like the option to switch in a DC blocking filter when using that source. >> RTL dongles can't support more than 2.4Msps reliably, so I'd like to be able >> to cope accordingly at initialization time. >> >> Is there a good way to retrieve, say, a string descriptor telling me which >> particular source I'm using? > > None that I know of, but aren't you the one who decides what device is > in use by passing e.g. "hackrf=0" as argument to the constructor? My own project is unrelated to the original poster's, but I'd also like to see this feature. I'm *not* deciding what device to use -- the user is giving a device string in my application's configuration. I could parse the config string, but then I'm reimplementing parts of gr-osmosdr (note that it can have "a=b" parameters which are not themselves device specifications, and might even come first, or at least that used to be a possibility). Being able to ask gr-osmosdr is good factoring. Even then, the config string is less specific than might be useful: for example, RTL devices all match "rtl=...", but have different RF characteristics (for example, those with the E4000 chip have a DC offset but R820Ts do not, and they also have different gain and filtering behavior). This information is available to the underlying driver, obviously as it prints messages like "Using device #0 Realtek RTL2838UHIDIR SN: 1E" and "Found Elonics E4000 tuner"; I'd just like to have that amount of detail exposed. (The first part but not the second is available if you are using osmosdr.device_find().) -- Kevin Reid From richard at g8jvm.com Tue Mar 4 13:15:31 2014 From: richard at g8jvm.com (Richard Bown) Date: Tue, 4 Mar 2014 13:15:31 +0000 Subject: getting started Message-ID: <20140304131531.45d4048c@richard-laptop> Hi, I've followed the steps in http://sdr.osmocom.org/trac/wiki/rtl-sdr All built OK, I opened up GRC clicked on RTLSDR in sources, but all I get is something flashing up on screen, looks like a block of text on a yellow background, but it seen to be flashing and scrolling and near impossible for me to read. rtl_test -t shows Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 Sampling at 2048000 S/s. No E4000 tuner found, aborting. What do I need to do now to get a working srd display, ie spectrum and waterfall display, or point me in the direction of the idiot guide please TIA -- -- Best wishes /73 Richard Bown Email : richard at g8jvm.com HTTP : http://www.g8jvm.com nil carborundum a illegitemis ################################################################################## Ham Call G8JVM . OS Linux Mint 16 x86_64 on a Dell Inspiron N5030 laptop Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W Microwave 23 cms 140W, 13 cms 100W, 6 cms 0W & 3cms 5W ##################################################################################