Friday, 31 May 2013

My last post was about the joys of SDR, this one is about the bane of not only SDR but radio in general namely the amount of electromagnetic rubbish that is thrown into the ether by shoddy equipment, with SDR you just see just how much s**t there is.

These are some waterfalls captured today, first exhibit showing lovely evenly space spikes, and a mass of hash and splatter.

A little further up the spectrum, another splatter, this I am convinced is some form of Power Line Network Adapter. You know the ones someone thought was a clever and expensive solution to that problem "How do you get network data from one room to another without the hassle of running a cheap proper shielded network cable or using wifi?" Their answer was to use unshielded mains wiring to transmit data at radio frequencies turning them into efficient antennas!

Mind you even using shielded network cabling isn't always the answer especially if you have cheap probably Chinese made network equipment which some one is using nearby. It generates this pretty pattern right across the VHF 2 meter band, especially bad on 144MHz.

Hold on VHF is immune to PLA interference you say? Yeah right!

I have posted before about problems I have had before including some videos including the one below. Thanks to my direction finding skills I know which direction this annoying interference was coming from, but I haven't seen it for a while, someone got themselves a new Plasma/LCD TV?

I am aware some of my equipment generates some noise, but even powering down the entire house and running on laptop batteries I see just as much rubbish, rubbish that disappears as soon as you remove the antenna.

Wednesday, 29 May 2013

I have owned and used radio scanners for many years, and loved them as my posts before December 2011 will testify.

In that month I became the proud possessor of a FUNCube Dongle Plus and discovered the joys of software defined radio, since then I purchased a FUNCube Dongle Pro+ and extended my SDR adventures in to the realms of HF and I have several of the insanely cheap RTL2832 based dongles.

As much as loved my scanners there was a major flaw with them, which has been brought into sharp focus now that I have used SDR.

No matter how fast or as sensitive as the scanner is are you are still playing a game of chance. You are limited by the frequency steps, demodulation modes and scanning rate of the receiver and you could zip through the band all day and still miss those elusive signals.

SDR and the waterfall display is a revolution, you can view a portion of the spectrum in real time and actually see the signals, they may be short lived bursts of data and voice, or continuous data transmissions.

The RTL-SDR dongles excel in this respect with their wide sampling rate you can view up to 2MHz of the spectrum at once, the following images show typical waterfalls captured this morning using one of my RTL-SDR dongles.

The first one, shows the cluster of data channels (was the old Vodaphone Paknet system) around 164.2 - 164.4 MHz, a trunking control channel and various data bursts, which are mostly Taxi Mobile Data Terminal (MDT) transmissions.

A little lower down the spectrum and another trunking control channel, a speech conversation, more data bursts and a faint digital channel.

Further up the spectrum into the UHF, a cluster of data transmissions.

Simply moving the cursor on the display and you can hear the transmission, if necessary change the demodulation type, widen or narrow the filter bandwidth, save the frequency. If you capture the IQ file you can then replay it endlessly tweaking and refining until you extract the information you want.

During the weekend I was experimenting and noticed there was lots of data bursts in the 163-168MHz range, I confess that I already knew what most of them were as I have experimented before with a scanner (with a discriminator tap) and Ian Wraith's Java based Taxi MDT decoder. I decided to reinvestigate them using the RTL-SDR as the receiver.

While many taxi companies still use voice transmissions, many have adopted automated data terminal systems, where the dispatcher sends information about jobs to terminals in the cars, the drivers then can accept jobs, get information and send information back to the dispatcher.

Ian's decoder which requires the Java runtime environment decodes systems that use the same physical layer as MPT1327 i.e 1200 Hz and 1800 Hz tones transmitted at 1200 bps. The two main systems used in the UK, are the Autocab and Auriga. The Taxi MDT Decoder currenly decodes the Autocab, but the coding for the Auriga system is still an unknown, so just outputs the raw data.

More information about Taxi MDT Decoder can be found here I confess to having one slight niggle with it, often I couldn't get it to accept sound from the selected input. A work around I found was to first open the Audacity sound editor which I had installed and select the input and start a recording, then opening the decoder seems to make it work!

Ian has also written the excellent DMRDecoder which allows analysis of the DMR digital mode which is becoming more widespread. I intend to post some details soon about decoding digital modes, keep watching.

I created a video showing the Taxi MDT Decoder in action, the quality is pretty dire but you can get the idea, I identify the Auriga as being encrypted, it might be but as nobody on the team knows the protocol yet!

Sunday, 26 May 2013

I have been tracking some more of the High Altitude Balloons (HAB) that have been released over the last few weekends.

Last weekend (18th May 2013) saw the release of STRATODEAN2 from the Stratodean team, which I received quite well as can be seen from the telemetry stats.

Mark and Cassie have posted an update of the flight on their blog including an entertaining video

This weekend, there have been three more flights which I have managed to decode, track and update telemetry to the habitat website,

MONDO-12 which flew on Saturday 25th May 2013

BABSHAB which flew early this morning

and finally this afternoon Dave Akerman's PIE6, which used a Raspberry PI to preform the radio tracking. Details of the payload can be found here. In addition to the GPS the payload also contained a camera and the captured images were also transmitted using the SSDV protocol.

Each image is broken into smaller packets, while a receiver may receive all packets for an image it is unlikely it would receive all so by using the distributed network of multiple receivers the images are reconstructed on the habitat server. http://ssdv.habhub.org/

The screen shot below shows my PC as it receives the packets and attempts to reconstruct the image, hopefully you can see some portions of the image are missing.

Dave used a very fast 600Baud RTTY so he could transmit the high quality images, so was impressed to receive anything as the combination of SDR# and DL-Fldigi can be hard work for my ageing PC.

However these are all the images I contributed to (from the habitat site)

One thing I didn't receive much of were the interlaced telemetry packets.

Friday, 24 May 2013

I have posted before about receiving weather and shipping facsimile transmissions on HF, for a couple of days I have been using the FCDP+ and WXSat to do some decoding, also been investigating some of the mysterious RTTY transmissions you also find.

Interestingly my previous experiment was using an Alinco Scanner with SSB capability, produced better results than using the FCDP+ and SDR#. not really sure why. It appears the some processing of the audio upsets WXSat, I have tried many settings and adjustments but the decodes haven't been brilliant clear despite the signal being very strong and clear, many of the faxs have come in with odd 'stepping' where portions of the image go out of sync which I have corrected in PaintShop Pro.

Any way, here is a small selection of the images I've decoded from the Deutscher Wetterdienst, broadcast on 7880 kHz (DDK3) from Pinneberg in Germany,

Tuesday, 21 May 2013

Checking my Yahoo Groups this morning and spotted this announcement in the RTL1090 Group

All -
RTL1090 series 2 is about to launch with a new GUI and improved decoders. It
will take some time until all functionality is there, but here is the first BETA
release for those who want to try.
Please read the release notes below for what's done and what's not, and run the
BETA parallel to your existing and working installation for now.
The GUI should be easier to use with the various OS versions, because it has no
window and no borders.
If you encounter a fatal error (Access violation) please note down the text of
the AV window and post it here, as any other comments, too.
The beta download is AVAILABLE from
>>> http://rtl1090.jetvision.de <<<
ONLY
Place the exe (rtl1090.beta2.exe) file to your RTL1090 folder and start from
there. All previous RTL1090 settings will be kept.
-- Andy
-- jetvision.de
============================================================================
This is a beta version of RTL1090.
Functionality is experimental and partially incomplete yet.
Please use at your own risk.
Retain the release that is working for you as a copy.
============================================================================
Build 101 - 20/05/2013
- GUI completely refurbished. Program window height can be altered and switches
are hidden by default. This makes the GUI more space efficient (and it looks
better). The window is borderless but can be dragged when placing the cursor to
the top bar or the frequency indicator.
- In status line: USB packet indicator (packets/s) changed to queue cycle time
(ms). The queue cycle time must stay below 300 ms for
lossless processing. This is important for MLAT operations. If you see a red
number here, be prepared for packet losses and inability to run MLAT from this
computer.
- Packet rate LEDs show all red when it appears that a USB data frame
was lost. This is in preparation for work on better MLAT accuracy. If all red
is shown no MLAT functionality is available. You should shutdown other programs
and demanding computer acitivity. Your computer may be even too slow at all to
cope with the USB data rate (32 MBit/s).
- Avg. Signal Strength (SG) and Message count (MSGS) added to flight table.
Avg. Signal Strength is normalized to 100% (max 99%).
Color codes are yellow (you can hear it), orange (you can see it),
red (you can touch it).
- Default display order in flight table changed. Newest flights are at top for
compatibility with DUMP1090 (not completely working yet)
- CONFIG dialog: some commmand line options can be selected from the dialog,
however command line entries are still valid and do override any selections.
If overriding occurs checkbox entries are printed in bold, but boxes will not be
checked, so the override conditions will not be saved to the configuration file.
- Update alert: when a new version is available an update sign appears in the
caption bar - no further functions yet - if you see the sign go back tohttp://rtl1090.jetvision.de and download the next release.
============================================================================
Outstanding commits:
- Start with Windows and Resume from hibernate/standby
- Stop without exit
- DO260 A/B and signal strength processing for HTTP server
- Improve Mode-S and Mode A/C decoder
- Complete autoupdate
- Log file selection from config dialog
- MLAT counter accuracy
- Renovate SISEX design

Well I downloaded it and fired it up and can report a much improved performance, with the promise of even more to come from the sound of it, just not sure my ageing PC is going to keep up!

My video detailing the construction of my collinear has also been featured on rtl-sdr.com and has now received quite a few views and I can report it is still performing magnificently.