Discussion:
SDR software for various formats/devices - Linux ONLY, please.
Adam Nielsen
2014-09-15 22:27:10 UTC
Permalink
I am looking to find software to use with the various re-purposed
DVB-T sticks as SDR's.
I am aware of the "The BIG List of RTL-SDR Supported Software - rtl-
sdr.com"
But this list is polluted with software for non Linux, and I refuse
to wade through that stuff.
A while back I started on my own list of SDR software on a wiki I found,
sadly I haven't had the time to expand it so there are only a half-dozen
programs there and only two for Linux, but if you (or anyone else)
finds any in your travels it would be nice to expand it:

http://www.amateur-radio-wiki.net/index.php?title=List_of_SDR_programs

You can sort by heading, so if you sort by the Linux heading then all
the software that works on Linux will be grouped together.

Personally I have found gqrx to be one of the best general purpose SDR
programs for Linux. It's roughly equivalent to SDR# in layout and
purpose, but native Linux. Unfortunately it does use Pulseaudio for
sound, but nobody's perfect ;-)

Cheers,
Adam.
Leif Asbrink
2014-09-15 23:38:28 UTC
Permalink
Hello Dean,
1) **LINUX ONLY!**. Native, NO WINE!
2) Console based, preferred, unless an image would need to be displayed.
3) Pipe'ble to Python, BASH, PhP scripts for processing.
It is unclear to me what you really look for.

There is Linrad which you can run in console mode with fbdev.
The output can be sent to other software in several ways,
ALSA sndaloop, Jack or network.

Linrad is multi-OS, it runs under Windows, MAC OSX and PC-BSD also,
but there is no need for you to bother about that. Linux is the
OS where development is done.
http://www.sm5bsz.com/linuxdsp/linrad.htm

Regards

Leif
The goal is to pipe rtl_fm to these, or they are standalone receiver
systems using the USB SDR (dvb-t) sticks.
I am especially geared to TEXT/CONSOLE based software v. GUI based ones,
unless of course the format would need to display graphics. I take
multimon-ng and pipe it to my own python stuff to do alerts on various
data from the pages.
I've done searches and find various software, or the results are too
polluted with non Linux software, or the circular links to various
projects on Github which you can't tell if they support something or not,
ie: a couple of projects in re OS WX sensor support, as a for instance.
So hopefully something more sane can be compiled by finding actual users
of such software...
So with out further editorial delay...
*Radio Trunking*
/P25 Phase I and II*/
/EDACS Wide and Narrow with/without CC XOR Encoding/
/Motorola Smartnet|Zone/
* Including Motorolas X2 pre-standard not sanctioned take on P25pII
If it can at a MINIMUM decode the control channel and output DECODED
FORMATED stream of data, not just some hex or other dump of the stream
that needs to be fed to something else.
Yes I am aware of the Wireshark sniffer.
If it can control an SDR dongle and "trunk track" P25 Phase I, and even
better the Phase II TDMA for unencrypted systems, bring it on! Same for
EDACS (Standard (or WIDE 9600cc) or Narrow ) and the older Motorola
SmartNet/Zone systems. As well as interface to DSD/libmbe to do ProVoice
(EDACS - unencrypted) digital even better. Even if it uses one dongle for
CC decode, and another to follow/track the audio. EDACS Analog & P25
would be a boon right now.
Especially if this could be fed via rtl_tcp..
I am aware of another program(s), but they are NOT LINUX.
*Paging - Especially /Flex/ *
Flex - all formats
Or a combined FLEX & POCSAG ala multimon-ng, which I use now, but it
lacks Flex.
(Radio lawyers need not reply. I am aware of the laws in my area, and
since it is MY transmissions, I can decode them. Thanks.)
*ACARS*
I've seen the rtl_acars...but what is the current, stable, and supported
by coders ACARS decoder.
*VDLM2|3 aka ACARS NG/2.0*
*Weather Stations*
Specifically */Oregon Scientific/ V2 *and* V3 protocols on 433.920Mhz
LaCrosse and Accurite would be of interest as well.
*Power Utility Meters*
Specifically Sensus Meters in the 901-941Mhz MS & CN band
These are "smart meters" and report back power usage, and in certain
cases contain remote disconnect systems to disconnect..
There has been huge issues with the local city power company using these,
and several cases of the remote connects causing catastrophic fires.
These are being replaced.
Along with distrust in their accuracy.. hence why I have, another
monitor, see below.
*Power Monitor Meters*
The ancient old Black and Decker power monitor meter on 433.920Mhz.
*EMWIN*
1200, 2400, and 9600 EMWIN transmissions. While I've lost my local VHF
source.. An area a little further away has one on the "NTIA/NOAA-NWR
Sanction" frequencies for this...
*Multi channel NBFM similar to RTL-SDR-Airband*
Something like RTLSDR-Airband *but for NBFM*.
In my area a couple of these centered on a few UHF channels could feed an
entire county of PS quite easily.... (oooohhh ooohhh getting
faint.....ooohh!)
Leif Asbrink
2014-09-17 19:38:04 UTC
Permalink
Hello Dean,
The posts on Linrad were not very positive.... mostly about huge amounts
of crashing at random.
Please tell me where you found those posts.
There is a Linrad mailing list on which I expect feedback.
There are few reports on "crashing at random" - and all bugs that
have been reported so far have been fixed.

Linrad supports a huge number of hardware platforms and I am
sure there are bugs - but I can not fix them unless someone
would point me to the problem.
Linrad is multi-OS, it runs under [junkdows], MAC OSX and PC-BSD also,
but there is no need for you to bother about that. Linux is the OS where
development is done.
Well as above I've not read positive things... and supporting non Linux
is a huge strike against it..things tend to eventually start to creep to
support only junkdows....
The Linux vs Windows discussion often takes ugly forms. Surely the
philosophy of open vs proprietary is VERY different, but when it comes
to system performance differences are actually very small. For sound
systems one would have to compare Linux ALSA to Windows WDM-KS, WASAPI
or ASIO. Things like MME or direct sound are much worse than Pulseaudio.

I have recently found a case where operating systems really differ.
Late Linux kernels like Debian Sid (unstable) perform significantly
better than Windows or earlier Linux like Debian wheezy (stable) in certain
situations of high CPU load. I think it is about different strategies
for CPU speed and scheduling. Problems occur if several threads need nearly
100% of a CPU while a couple of threads need less than 50%.

All replies should be Linux centric. As I don't use anything but a real
OS.
This is a mailing list. Replies are not only for you and to the
extent that information about other operating systems is relevant
to the subjects you bring up I think replies should also include
non-Linux information.

Regards

Leif
Peter Stuge
2014-09-26 21:43:05 UTC
Permalink
My thread,
It's not anyone's thread. We are a community of people working together.
I want only Linux responses..
It must suck to be you.
I am not interested in anything else
What you seem to be missing (completely and repeatedly) is that when
you ask someone to volunteer advice then it is not your place - and
certainly not your right - to tell them how they should respond.

If you do not like the response you get from people who spend their
precious lifetime on helping you then I think you owe it to them to
leave them alone, and I think you should be embarrassed to come back
until you are capable to demonstrate that you yourself are solving
your own problems the way you want them to be solved.

It may be that you are only capable of having people work *for* you,
as opposed to having people work *with* you. The difference is huge,
and my experience is that nobody likes to waste time on the former
within open source. You might simply be asking in the wrong place.


//Peter
Leif Asbrink
2014-09-26 23:40:26 UTC
Permalink
Hello Dean,
Post by Leif Asbrink
Please tell me where you found those posts.
.
.
That may be, but what I ran across was not favorable.
Additionally I an */not/* after a GUI program.
Linrad is open source and you can fairly easily skip the GUI
if you wish.
http://epic.geek.nz/page/2012/12/29/sdr-software-good-bad-and-ugly/
This is the critizism: "The spectrum display could desperately use some
gradient or even solid fill to improve visibility. I have rather
poor eyesight which made the small fonts and single pixel lines
too hard to see at high resolution. While it did function for me,
I found it too awkward to use and difficult for a beginner."
It is from a beginner who did not care to select bigger fonts although
it seems important to him. It is true however that Linrad is pixel
oriented and people with poor eyesight need to set a smaller screen
to get fewer pixels.

You mentioned Linrad was said to be unstable and crasching. I am
interested to know where such information has been published.

Surely there is a lot of false information on the Internet. This is
an ugly example:
http://www.uninstallapp.com/article/How-to-uninstall-Linrad-0.1.html
It is for Windows, but it is a fraud. Linrad does not write
anything in the registry as they claim. I guess they want money or
want to install some malware.
I am not interested in the source code. Your software, here is my bug
report, feature request... your the author you can handle that. Source
code is really of no value to me, except in the stuff I program, and that
is not going anywhere outside my systems, ever.
Well, to me your attitude seems atypical for a Linux user. Linrad
comes as a tarball. You may add users_extra.c or users_hwaredriver.c
to get functions of your own. You do of course not have to share
what you do. Friendly users have supplied their files in the past
and those contributions are now included in the Linrad tarball.

73

Leif

Ralph A. Schmid, dk5ras
2014-09-18 07:34:58 UTC
Permalink
Hi,
I am not really after all those waterfall things.. maybe if your the NSA etc... or
you want to impress some one, or you are bored that may be of use.. not for
me, at least right now. I have dedicated tasks I need to resolve with known
frequencies and formats.
Sure, then it is not necessary - but when hunting for short burst of signals or wideband noise, then the waterfall thing is just great, also for monitoring a band to quickly find a signal, or to find a gap in a crowded radio band for your own transmission.
Jack
Ralph.
Ed Beroset
2014-09-16 00:07:24 UTC
Permalink
*Power Utility Meters*
Specifically Sensus Meters in the 901-941Mhz MS & CN band
These are "smart meters" and report back power usage, and in certain
cases contain remote disconnect systems to disconnect..
There has been huge issues with the local city power company using these,
and several cases of the remote connects causing catastrophic fires.
These are being replaced.
Along with distrust in their accuracy.. hence why I have, another
monitor, see below.
I've been monitoring my own power usage this way for a little while. I
have been using this:
http://www.rtl-sdr.com/rtlamr-rtl-sdr-receiver-900mhz-ism-smart-meters/

In my particular case, I was interested in seeing the demand over time,
so I wrote some software (all Linux) to go with it. Specifically, the
chain goes like this on my machine:

1. rtl_tcp: this streams the raw I+Q signals out via TCP. You can start
from there and do anything that's possible with an SDR receiver.
2. rtlamr: reads stream from rtl_tcp and decodes to text.
3. energymon: my own C++ application which reads the text from rtlamr,
throws away all data other than for my own meter, parses the data and
slings it into a local SQL database.
4. energy.php: an extremely simple PHP page whose sole function is to
pull data from the SQL database and reformat it as JSON.
5. energy.html: a d3.js based web page that does a little additional
computation (specifically, it calculates demand from the raw energy
values and timestamps) and renders it as a 2D autoscaled plot.

Note that all but the last step is without any GUI, and in fact, the GUI
is essentially remote via a web browser rather than on the machine itself.

As a disclaimer, I am an engineer involved in the design of metering
devices, but not with the specific manufacturer you mention. These
devices are generally highly accurate, but you can easily test this for
yourself, and I encourage you to do just that. One simple way to do
this doesn't even require a radio. Plug in and turn on a single 100W
incandescent light into an outlet for which you know the controlling
breaker and assure nothing else is using power on that breaker. Go
outside to the meter and turn off all breakers. Write down kWh (energy)
reading. Turn on only the single breaker controlling the single 100W
light and leave the house in that condition for precisely one hour. At
exactly that time, turn off the breaker again and note the kWh reading.
The reading should be exactly 0.1 kWh greater than the previous reading.
At that point the experiment is done and you can turn on all the
breakers again.

Generally speaking, one can use gnuradio-companion to graphically design
the actual radio portion. Once it's designed, it compiles to Python and
if one hasn't included graphical I/O into the design, the resulting
Python application does not use or need any GUI.

Alternatively, there are many available gnuradio blocks from others that
can be used as-is or modified for your own particular purposes. Here
again, once you have a block, or a whole subsystem, you can easily
compile it into a CLI-based Python program, that that opens up a whole
other world of exploration for those of us who prefer CLI.

Ed
Peter Stuge
2014-09-18 22:53:09 UTC
Permalink
some one else will need to provide
The way you express yourself makes you seem like an entitled asshole. :\

I think you really have to write the programs you need on your own.


//Peter
Ed Beroset
2014-09-19 03:20:15 UTC
Permalink
Post by Ed Beroset
http://www.rtl-sdr.com/rtlamr-rtl-sdr-receiver-900mhz-ism-smart-meters/
The Sensus devices are on 900Mhz licensed PCS frequencies. 1W meters, and
30W bases... the local mafitilty has recently stuck some up on a their
poles as they obviously had some coverage issues.
But outside of that they are not going to release, to the general public
at least, any data.
All the FCC OET exhibits with this are "Permanent Confidential."
http://fccid.net/number.php?fcc=SDBIDTB002&id=640613
http://fccid.net/document.php?id=1338971
That's not correct. They don't make schematics available to the public
(probably because they fear revealing them to competitors) but the test
report is certainly available and tells you most of what you would want
to know about the frequency bands, channel spacing and modulation:
https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1338973
Based on the heavily PR puff and sanitized info on their site this uses
an IP network, with most likely an IPv6 (blech!) addressing system for
meters etc... and controlled via DNP3 protocol. Which with the IP nature
maybe encrypted via VPN (IEEE1179).. They don't mention anything about
the security other than their monitoring of tampering, moving a meter
etc..
Typing the name of the company and the words "meter" and "security" into
a search engine yields rather a lot of information, so I'm not sure why
you were unable to locate it.
Based on one of those RF is killing me whackos [1], did turn up some info
that the meters may be transmitting on 940.1125MHz, and monitoring this
I do get digital bursts on this channel.
The FCC report states that it operates in any of 9 different bands at 2
different power settings and 5 distinct modulation modes. It also gives
numbers & specs for all of those.
And based on the emissions
designator for the grant its some sort of 4-9Khz wide FM signal with
possible a subcarrier on some models and possibly TD as well.
Base station specs (again, easily found with a search engine) for their
equipment pretty clearly state that the TX side uses 2-FSK at 5-10 kbps
and RX is 7-FSK at 4-8 kbps.
I will try to capture some audio to post some place if I can...
Post by Ed Beroset
Alternatively, there are many available gnuradio blocks from others that
can be used as-is or modified for your own particular purposes.
I don't use that software, nor am I going to. May be the bees knees and
all that.. just doesn't connect with me. Bloated, PITA to install, setup,
use, and huge amounts of issues in re stuff that doesn't work with newer
versions and vice versa...
It's actually pretty easy to install in my experience. Just run this
script: http://www.sbrac.org/files/build-gnuradio

Naturally, if anything goes wrong, you'll need to know what you're doing
with Linux to troubleshoot, but I haven't really had any significant
difficulty with it. Not sure how you could claim it's "bloated" unless
you could point me to something significantly smaller that does what it
does. If you know of such software, please name it and provide a
pointer to its source code. I'm sure there are many here who would be
interested.
Post by Ed Beroset
again, once you have a block, or a whole subsystem, you can easily
compile it into a CLI-based Python program, that that opens up a whole
other world of exploration for those of us who prefer CLI.
Thats great, but some one else will need to provide that "compiled"
program. I am a willing tester.
If, by that, you mean you don't yet have the skill or knowledge required
to be able to design the radio based on working blocks, then you might
consider using gnuradio to learn something new. I don't yet consider
myself an expert with gnuradio, but find that's it's quite useful as a
platform for trying out digital radio techniques and find it quite fun
and interesting to explore that way. You might, too, if you can get
beyond your many apparent prejudices.

Ed
f***@free.fr
2014-09-17 20:02:00 UTC
Permalink
Bob Snyder
2014-09-17 20:35:19 UTC
Permalink
Post by Adam Nielsen
Personally I have found gqrx to be one of the best general purpose SDR
programs for Linux. It's roughly equivalent to [censored word - such
lanquage! :) ;) as you can tell I have a disdain for that thief of
software)] in layout and
purpose, but native Linux.
I am really after something that is not trying to be the Linux version of
somethig, and especially GUI based... I really have no need, nor interest
in them for my tasks.
Post by Adam Nielsen
Unfortunately it does use Pulseaudio for
sound, but nobody's perfect ;-)
And thus unusable for me, I refuse to touch that.
You may not be interested in Gqrx, but for the record it works fine
without Pulseaudio, which is listed as optional in the Gqrx README.md file.

Bob W6CP
Adam Nielsen
2014-09-18 00:31:47 UTC
Permalink
Post by Bob Snyder
You may not be interested in Gqrx, but for the record it works fine
without Pulseaudio, which is listed as optional in the Gqrx README.md file.
Oh wow you're right! Sadly I had so much trouble trying to get it to
install from source (dependency issues) I gave up until it appeared in
my distribution's repositories. I only now discover they install a
"gqrx-alsa" binary as well which works so much better!

Thanks for the tip :-)

Cheers,
Adam.
Peter Stuge
2014-09-18 02:31:39 UTC
Permalink
hopefully something more sane can be compiled by finding actual users
I think you have to write all that software that you need on your own.

It would be honorable to make it open source and publish it to the world.

If you lack neccessary skills you can always try to pay someone to do it.


//Peter
Loading...