# TETRA Decoding on Windows with Telive

TETRA is a type of digital voice and trunked radio communications system that stands for “Terrestrial Trunked Radio”. It is used heavily in many parts of the world, except for the USA. Telive is a decoder for TETRA which is compatible with RTL-SDR dongles, and has been around and in use for almost 2 years now. If you have unencrypted TETRA signals available in your area it can be used to listen in on them.

Telive is dependent on GNU Radio, so it is normally installed and used on a Linux system. Previously we wrote a tutorial on it’s installation and use, and other users have also made bootable Linux images of telive available.

However, now a TETRA experimenter by the handle of “cURLy bOi” has released a new prototype of a telive modification that works on Windows systems. It makes use of the GNU Radio for Windows development. The telive Windows file can be downloaded from curly’s webserver. His reademe file shows how to install and use the software and it reads:

This has been put together as lowest-effort configuration
to run telive on Windows system. I have also optimized to process (for example adding the CQPSK block to GRC since the python code in the original telive package is IN FACT some unused part of GNU Radio)

Warning:
———
This package contains pre-compiled binaries that work on my 64-bit system. I have compiled them inside the M-SYS2 package. If you don’t trust me, you can follow the installation guide from telive docs, just be prepared you are going to need a lot of packages for the M-SYS2 (pacman -S gcc automake git wget, etc.)

Install:
———
and install
4) Copy contents of msys_root to your M-SYS2 installation directory
and extract everything from bin to usr\bin in your M-SYS2 installation directory
6) In M-SYS2 shell execute “pacman -S socat”
7) Get GNU Radio Companion (GRC) projects from original telive package at
(only udp or xmlrpc, pipes won’t work)
8) Open whatever GRC project you want to use and edit it:
– Delete the link between (all) Fractional Resampler and UDP Sink
– From the modules on the right (ctrl-f to search) drag CQPSK Demod to project
(If you don’t see CQPSK Demod then you have messed up #2)
– Connect Fractional Resampler -> CQPSK Demod -> UDP Sink
– Change UDP Sink Input Type to Float in its properties
– Save

Use:
——
1) Open GRC project of your choice (already with the CQPSK Demod box)
2) Use the Project/Execute to run the project from the GRC
– OR –
to generate top_block.py file in the GRC project directory.
Then open GNURadio Command Prompt from Start menu, the use this command
This will enhance performance.
3) Open new M-SYS2 shell for every channel in that project and execute
command “receiver1udp X” where X is the number of each channel in GRC project
4) Open new M-SYS2 shell, resize it to 203×60 and execute:
– cd /tetra/bin
– ./rxx OR ./rxx_xmlrpc (if you are using XMLRPC GRC project)
You can edit these files to match your preferences
5) That’s it, should work.

Note that we have not tested this out ourselves yet and can’t guarantee the file safety or that it works, but we have no reason to believe that it wouldn’t be safe or not work.

# Using Multiple RTL-SDR’s to Capture a Trunking System

An RTL-SDR dongle has a maximum usable bandwidth of about 2.4 MHz which most often isn’t enough to capture an entire trunking system that may be spread out over a larger bandwidth. In order to get around this limitation Luke Brendt has been using three RTL-SDR dongles together to capture a trunking system in his area which is spread over 6 MHz of bandwidth.

Luke uses his own Trunk Recorder software and writes that he has modified it to support multiple SDR’s. His software has the following description:

Trunk Recorder is able to record the calls on a trunked radio system. It uses 1 or more Software Defined Radios (SDRs) to do. The SDRs capture large swatches of RF and then use software to process what was recieved. GNURadio is used to do this processing and provides lots of convienent RF blocks that can be pieced together to do complex RF processing. Right now it can only record one Trunked System at a time.

• Trunk Recorder currently supports the following:
• P25 & SmartNet Trunking Systems
• SDRs that use the OsmoSDR source ( HackRF, RTL – TV Dongles, BladeRF, and more)
• Ettus USRP
• P25 Phase 1 & Analog voice

Luke also mentions that using three RTL-SDRs like this seems to be more efficient on the CPU than using a single SDR that has 8 MHz of bandwidth due to the amount of down sampling that needs to be done on larger bandwidth SDRs.

When I was using a single SDR, each Recorder had to take in the full 8MHz and pull out the small 12.5KHz that was interesting. The end results is that I could only record about 3 channels at once before the CPU got overloaded. Since that control channel was going at the same time, that was the equivalent of about 32MHz of bandwidth to process.

With the RTL-SDR, each Recorder only has to look at 2MHz, which puts a lot lighter load on the CPU. Roughly speaking, having 3 Recorders active, plus the control channel would mean that only a total of 8MHz was being processed. As you can see, this means that it scales much more efficiently.

# Trunking with the Latest DSD+ 1.08t Fast Lane Version

DSD+ stands for Digital Speech Decoder Plus and is a software program that can allow you to decode digital voice signals such as P25 and MotoTRBO/DMR. DSD+ is under continual development, and in their last public update they began offering early access to the latest DSD+ features in development through their fast lane subscription. The fast lane subscription costs $10 USD for one year and$25 for unlimited early access. Information about joining the fast lane service can be found in the readme file of the latest DSD+ 1.074 public release.

Over on YouTube user John Miller has been testing the latest early access version DSD+ 1.08t. This new version adds trunking support which allows you to follow conversations. Previously other software like Unitrunker was required to follow the trunking signal. On YouTube John has uploaded a video first showing trunking in action, and a second video showing how to set up DSD+ 1.08t for trunking.

# Listening to Trunked Radios with One RTL-SDR

Usually to listen to trunked radio systems, two RTL-SDR dongles are required. One for decoding the trunking control channel and another for listening to the audio channel. However if the audio channels are within the same chunk of received bandwidth as the control channel it is possible to use just one dongle to follow trunked conservations.

Recently Pawel of pewusoft wrote in to RTL-SDR.com to let us know about a tutorial he uploaded showing how to get trunking to work with just one RTL-SDR dongle. His method uses Unitrunker and SDR# together with the AuxVFO plugin and a new plugin that he wrote for interfacing with Unitrunker.

Although there is already a Unitrunker interface plugin for SDR#, Pawel wrote a new plugin based on serial port commands as he found that the original interface plugin did not work properly for him.

# RTL-SDR Tutorial: Listening to TETRA Radio Channels

TETRA is a trunked radio communications system that stands for “Terrestrial Trunked Radio”. It is used heavily in many parts of the world, except for the USA. Recently, a software program called Tetra Live Monitor (telive) was released on GitHub. This software can be used along with the (patched) Osmo-TETRA software to monitor and listen to unencrypted TETRA communications.

Below we show a tutorial on how to listen to TETRA communications using a RTL-SDR RTL2832U software defined radio. This tutorial is based heavily on the telive_doc.pdf file that is written by the author of telive and included in the telive git download. Please refer to that pdf file for further details on how the software works. We have modified their tutorial slightly to make it a little easier to understand. As this code is still under heavy development if you have trouble please check their PDF file for modifications to the procedures.

Again, we reiterate: This tutorial is not a substitute for a thorough reading of the documentation. If you have trouble setting this software up, please refer to the telive documentation first, before asking any questions. It contains a comprehensive FAQ section which solves most of the common problems. The documentation can be found directly at https://github.com/sq5bpf/telive/raw/master/telive_doc.pdf. There is also a discussion at http://forums.radioreference.com/digital-voice-decoding-software/302347-tetra-decoding.html.

## Decoding and Listening to TETRA Tutorial

Most of this tutorial is performed in Linux and we assume that you have some decent Linux experience. We also assume you have some experience with the RTL-SDR dongle and have a decent antenna capable of picking up TETRA signals in your area. If you don’t have a RTL-SDR dongle yet see our Buy RTL-SDR dongles page.

Note: As of October 2016 there is now a Windows port of the Telive decoding software available. This may be an option for you if you prefer to run in Windows. More information here.

First, we will need to find some TETRA signals. The easiest way to do this is to open SDR# or another program like GQRX and look for them. TETRA signals are continuously broadcasting with a bandwidth of around 25 kHz. In most European countries they can be found at 390 – 470 MHz. In some countries they may be found around 850 MHz or 915 – 933 MHz. There may be several TETRA signals grouped in close proximity to one another. See the example images below.

 A Zoomed in TETRA Signal A Grouping of TETRA Signals Zoomed Out

An example audio clip of a TETRA signal recorded in NFM mode is shown below.

Once you have found some TETRA signals, record their frequencies. Now close SDR#, or whatever software you were using and boot into Linux. In this tutorial we use a 32-bit Ubuntu 14.04 virtual machine running on VMWare Player as our Linux system. Some of the commands may vary if you are using a different system.

# RTL-SDR Tutorial: Following Trunked Radio with Unitrunker

The popular trunking decoding software Unitrunker now supports the RTL2832U R820T RTL-SDR directly in its new version. This means that extra SDR receiver software like SDR# is no longer required to use Unitrunker.

In a normal radio system, one company (or talkgroup) might use a single frequency for radio communications. However, this is very inefficient as the frequency may not be in use for the majority of the time. In a trunked radio system, a small set number of frequencies are shared between a large number of talkgroups. Each radio receives a special computer controlled control channel. The control channel determines a vacant frequency that a particular talkgroup should use. This helps to make radio frequency allocations more efficient.

Because a talkgroup might switch between various frequencies often, it can make listening to a conversation difficult for radio scanners. Unitrunker can be used to decode the control channel and follow a voice conversation as it hops across various frequencies. With two RTL-SDR dongles you can set up a trunking receiver station with just Unitrunker. What follows below is a tutorial on how to set this up.

# SDRSharp Trunking Plugin Updated

Reddit user rtlsdr_is_fun has updated the SDRSharp Unitrunker trunking plugin so that it works with the latest versions of SDRSharp. See the thread here for more information and a download link. Use this plugin to allow Unitrunker to control SDRSharp, so you can listen to trunked radio conversations. A new tutorial on doing this can be found here.

NOTE: Recent changes to WordPress seem to have broken the audio on this page. Please use the new Signal Identification Wiki which has many new signals. Anyone can edit and improve the information on the pages on the wiki.

A guide to help you identify some amateur and utility digital radio signals and sounds which you may find on the frequency spectrum. Most of these have been received with an RTL-SDR software defined radio. I will be slowly adding more to this list over time. If you enable stereo mix and pass the sample audio to an appropriate decoding program the sample audio should be decodable for most samples.

If you would like to suggest a modification or contribute a sample, please send a sample, waterfall image and information about the signal to [email protected], or post in the comments. (Note I am currently backlogged with contributed signals, if I haven’t replied or added your signal yet it will be done within a month or two).

More sites with sample audio can be found at this list on dxzone.com. A very nice overview video of the HF spectrum by balint can be found here. There are also two paperback books: Technical Handbook for Radio Monitoring VHF/UHF (PDF Excerpt) & Technical Handbook for Radio Monitoring HF (PDF Excerpt) which have a very comprehensive list, description and images of many signals.

# ACARS

Sample Audio:

Typical Frequency: 131.550 MHz

Mode: AM

Bandwidth: 5000-8000 Hz

Description: Aircraft Communications Addressing and Reporting System (ACARS). Short messages sent to and from aircraft.

Decoding Software: PlanePlotter, ACARSD

Video Examples: [1], [2]

# P25 Phase 1 (C4FM Modulation) (Encrypted)

Sample Audio:

Typical Frequency: ~860 MHz, ~500 MHz + others

Mode: NFM

Bandwidth: 10000 Hz

Description: P25 encrypted digital voice signal with C4FM modulation.

Decoding Software: Digital Speech Decoder (DSD). Note, only unencrypted can be decoded.

Video Examples:  [1], [2][3]

# DMR/MotoTRBO

Sample Audio:

Typical Frequency: ~860 MHz

Mode: NFM

Bandwidth: 10000 Hz

Description: Motorola digital voice signal known as MotoTRBO (pronouced Moto-Turbo).

Decoding Software: Digital Speech Decoder (DSD). Note, only unencrypted can be decoded.

Video Examples: [1], [2]

# POCSAG/FLEX-A

Sample Audio:

Typical Frequency: ~151 MHz, ~900-950 MHz

Mode: NFM

Bandwidth: 10000 Hz

Description: Pager digital signal known as POCSAG. An acronym of Post Office Code Standardization Advisory Group.

Decoding Software: PDW

Video Examples: [1], [2]

# Weather Balloon (Radiosonde) Vaisala RS92SGP

Sample Audio:

Typical Frequency: ~400 MHz

Mode: NFM

Bandwidth: ~5500 Hz

Description: Weather balloon (Radiosonde) telemetry data. Only transmits during a weather balloon launch.

Decoding Software: SondeMonitor

Video Examples: [1], [2]

Sample Audio:

Typical Frequency: 380 – 430 MHz

Mode: –

Bandwidth: 25000 Hz

Description: Terrestrial Trunked Radio (TETRA), also know as Trans-European Trunked Radio is a professional mobile radio and two-way transceiver (walkie-talkie) specification. Modulated with π/4 DQPSK. Audio sample recorded in NFM mode.

Thanks to Jenda for the submission.

Decoding Software: osmocomTETRA

Video Examples: [1], [2]

# Trunking Control MPT1327

Sample Audio:

Typical Frequency: ~420 MHz

Mode: NFM

Bandwidth: 10000 Hz

Decoding Software: Trunkview, UniTrunker

Video Examples: [1]

# Trunking Control Motorola Type II Smartnet

Sample Audio:

Typical Frequency: ~860 MHz

Mode: NFM

Bandwidth: 8000 Hz

Decoding Software: UniTrunker

Video Examples:

# Trunking Control EDACS96

Sample Audio:

Typical Frequency: ~860 MHz

Mode: NFM

Bandwidth: 10000 Hz

Decoding Software: UniTrunker

Video Examples:

# Trunking Control APCO P25

Sample Audio:

Typical Frequency: ~860MHz

Mode: NFM

Bandwidth: 12500 Hz

Decoding Software: UniTrunker

Video Examples:

# AFSK1200

Sample Audio:

Typical Frequency: ~144 MHz

Mode: NFM

Bandwidth: 10000 Hz

Description: Audio frequency-shift keying (AFSK). Used by amateur radio hams for packet radio, Automatic Packet Reporting System (APRS) and telemetry.

Decoding Software: QTMM

Video Examples: [1]

# AIS

Sample Audio:

Typical Frequency:

Marine Channel 87 – 161.975 MHz
Marine Channel 88 – 162.025 MHz

Mode: NFM

Bandwidth: 12500 Hz OR 25000 Hz

Description: Automatic Identification System (AIS). Used by ships to broadcast position and vessel information. Uses 9.6 kbit GMSK modulation.

Decoding Software: ShipPlotter, AISMon (In the Files Section of the Yahoo Group)

Video Examples: [1], [2]

# NOAA Weather Satellite (APT)

Sample Audio:

Typical Frequency:

NOAA 15 137.620
NOAA 18 137.9125
NOAA 19 137.100

Mode: WFM

Bandwidth: 30000 Hz

Description: NOAA Automatic Picture Transmission (APT) signal. Used to by the NOAA weather satellites to transmit satellite weather photos.

Only transmits at certain times throughout the day when the satellite passes overhead at your location.

Decoding Software: WXtoImg

Video Examples: [1], [2], [3]

# Stereo Wideband FM (WFM)

Sample Audio: –

Typical Frequency:

Common – 87.5 to 108.0 MHz
OIRT – 65 to 74 MHz
Japan – 76 to 90 MHz
Consumer Wireless Devices – ~860 MHz

Mode: WFM

Bandwidth: 30000 Hz

Description: Stereo Wideband FM signal. Used for typical broadcast radio, and in some wireless headsets and speakers. This particular signal is from an AKG headset.

Top signal is WFM transmitted with low amplification. Bottom signal is WFM transmitted with high amplification.

Thanks to Tobby for the submission.

Decoding Software: Unencoded

Video Examples: [1], [2]

# Amplitude Modulation (AM)

Sample Audio: –

Typical Frequency:

Long wave – 153 to 279 kHz
Medium wave – 531 to 1,611 kHz in ITU regions 1 and 3 and 540 to 1610 kHz in ITU region 2.
Short wave – 2.3 to 26.1 MHz

Aircraft – 108 to 137 MHz

Mode: AM

Bandwidth: 10000 Hz

Thanks to rtlsdr_is_fun for the submission.

Decoding Software: Unencoded

Video Examples: [1], [2]

# Weatherfax (HFFAX)

Sample Audio:

Typical Frequency: HF ~3 to 16 KHz. Location dependant.

Mode: Upper side band (USB)

Bandwidth: ~1900 KHz

Description: HF Weatherfax. Used by boats for weather reports. Also Kyodo News, a Japanese newspaper transmits entire pages via HFFAX.

Decoding Software: FLDIGI

Video Examples: [1], [2]

# Upper Side Band Voice (USB)

Sample Audio:

Typical Frequency: All HF band.

Mode: USB

Bandwidth: ~1900 Hz

Description: Single side band, specifically upper side band. Used in the HF band by amateur radio hams and aircraft weather reports. Single side band saves bandwidth.

Decoding Software: Unecoded

Video Examples: [1], [2]

# Over the Horizon (OTH) Radar

Sample Audio:

Typical Frequency: All over HF Band

Mode: –

Bandwidth:

Description: Over the horizon radar. Used by governments for very long range radar systems.

Decoding Software: Unencoded

# Analogue PAL TV

Sample Audio:

Typical Frequency: Multiple

Mode: PAL TV

Bandwidth: 5 MHz

Description: Analogue PAL TV. Color TV signal.

Decoding Software: TVSharp

Video Examples: [1]

Sample Audio: No Audible Sound Produced

Typical Frequency:

Multiple channels.
Block 13F – 239.200 MHz

Mode: DAB

Bandwidth: 1,537 KHz

Decoding Software: SDR-J

Video Examples: [1]

# Baby Monitor (NFM)

Sample Audio: –

Typical Frequency: ~40 MHz, 49.5 – 50 MHz

Mode: NFM

Bandwidth: < 15 KHz

Description: NFM signal from a baby monitor. Periodically bursts signal when no audio is detected. Thanks to Dean for some extra info.

Decoding Software: Unencoded

Video Examples: [1]

Sample Audio:

Typical Frequency: Below 30 MHz on HF, near other shortwave radio stations.

Mode: USB

Bandwidth: 10000 Hz

Thanks to Will P. for the contribution.

Decoding Software: DREAM, SODIRA

Video Examples: [1], [2]

# STANAG 4285

Sample Audio:

Typical Frequency: All over HF.

Mode: USB

Bandwidth: 2500 Hz

Description: Standardization Agreement (STANAG) 4285. NATO standard for HF communication.

Decoding Software: Sorcerer (Waring: Potential Virus Alert), Sigmira

Video Examples: [1]

Sample Audio:

Typical Frequency: 900 MHz and 1800 MHz Band OR 850 MHz and 1900 MHz Band

Mode: –

Bandwidth: 200 KHz

Description: GSM Cell Phone Downlink (Non Hopping Signal). Audio sample used NFM mode.

Decoding Software: Airprobe

Sample Audio: No Audible Sound Produced.

Typical Frequency: ~890 MHz

Mode: –

Bandwidth: 200 KHz

Description: Initial connection GSM signal sent from a cellphone.

Decoding Software:

Sample Audio: No Audible Sound Produced

Typical Frequency: 900 MHz and 1800 MHz Band OR 850 MHz and 1900 MHz Band

Mode: –

Bandwidth: Each channel 200 KHz

Description: GSM cell phone hopping.

Decoding Software:

# “Japanese Slot Machine” (XSL)

Sample Audio:

Typical Frequency: Between 4 MHz and 9 MHz

Mode: USB?

Bandwidth:

Description: Known as the Japanese Slot Machine. Thought to be data originating from the Japanese Navy.

Decoding Software: Sigmira (But Cannot Decrypt)

Video Examples: [1], [2]

Sample Audio: No Audible Sound Produced

Typical Frequency: 1090 MHz

Mode: –

Bandwidth: 2 MHz

Video Examples: [1], [2], [3]

# Cuban Numbers Station HM01

Sample Audio:

Typical Frequency: 11.530 MHz.

Mode: AM

Bandwidth:

Description: (Previously Unidentified Signal 5). Numbers stations are thought to transmit encoded information for various spy agencies around the world. They are recognized by a voice reading a sequence of numbers or words. This is a Cuban Numbers Station which has a data portion and a voice portion. Sound sample recorded in AM mode.

Thanks to Andrew from the comments section for the ID.

Decoding Software: Information Here

Video Examples: [1], [2], [3], [4], [5]

# High Frequency Data Link (HFDL)

Sample Audio:

Typical Frequency:  HF Band

Mode: USB (1440 Hz below center)

Bandwidth: ~2800 Hz

Description:  (Previously Unidentified Signal 2). An Aircraft Communications Addressing and Reporting System (ACARS) data link that aircraft use to communicate short messages over long distances using HF signals.

Thanks to Andrew from the comments section for the ID.

Decoding Software: PC-HFDL

Video Examples: [1], [2], [3]

# Binary Phase Shift Keying (BPSK31)

Sample Audio:

Typical Frequency:  HF Amateur Band

Mode: SSB

Bandwidth: ~31 Hz

Description:  A digital amateur radio mode based on Phase Shift Keying (PSK) modulation

Thanks to Patrick for the submission.

Decoding Software: Fldigi, MixW, HRD Digital Master 780, MultiPSK

Video Examples: [1], [2][3]

Sample Audio:

Typical Frequency: 72-76 MHz

Description: (Previously unidentified signal 10). Identified in the comments section by Ronen as an Asynchronous Frequency Shift Keying (AFSK) pager link. It is easier to transmit the FSK pager signal to the transmitter site as AFSK.

# Pulse Code Modulated (PCM) RC Toy Signal

Sample Audio:

Typical Frequency: 27.145 MHz, 72 MHz

Description: (Previously unidentified signal 9). Identified in the comments section by W1BMW as a Pulse-code modulated (PCM) signal used for remote control (RC) Toys. Link to IQ file http://i.nyx.cz/files/00/00/09/99/999880_c640d91142db39ee7d57.zip?name=SDRSharp_20130613_113322Z_27186kHz_IQ.zip. Sample audio recorded in USB mode.

# Overlapping RTTY Signals

Sample Audio:

Typical Frequency: HF band

Description: Previously unidentified signal (11). Identified in the comments by various contributors as multiple overlapping RTTY signals sent by ham radios.

# Voice Frequency Telegraph

Sample Audio:

Typical Frequency: 7453.50 KHz USB

Description: Previously unidentified signal (13). VFT or Voice Frequency Telegraph is one of several systems for sending multiple RTTY signals over one voice-bandwidth radio channel.

# Portable Traffic Lights

Sample Audio:

Found Frequency: 154.463 MHz

Description: Previously unidentified signal (17). Identified by Peter via email as being signals sent from portable traffic lights that are often used at roadworks.

# X2 on iDEN

Sample Audio:

Found Frequency: 154.463 MHz

Description: iDEN is an acronym for Integrated Digital Enhanced Network and is a technology developed by Motorola. It is a type of trunked radio with cellular phone benefits.

Thanks to Mike (VE3HER) for the submission.

# Funcube-1 Satellite

Sample Audio:

Found Frequency: 145.950 – 145.970 MHz

Mode: USB

Bandwidth: ~2 kHz

Description: The Funcube-1 is a Cubesat amateur radio satellite.

Decoding Software: Funcube Telemetry Dashboard

# Swedish Pocsag Minicall

Sample Audio:

Typical Frequency: ~161 MHz

Mode: NFM

Bandwidth: 20 kHz

Description: A short Pocsag 1200 signal used in electric plants and remote transformer and insulation stations.

Thanks to Joni for the submission.

Decoding Software: PDW

Video Examples: [1], [2]

# Unidentified Signals

If you know what any of these signals are please write in the comments. You can also submit any unidentified signals you would like to be added to [email protected]

# (1)

Sample Audio:

Found Frequency: 171.3 MHz

Description: Recognized by DSD as a NXDN96 signal, but is disputed in the comments section. (Possibly a bug in DSD).

# (3) – ALE?

Sample Audio:

Found Frequency:  HF Band

Description: Sound sample recorded in USB mode. Potentially some sort of 2G ALE signal. Similar signal shown in balints HF tour video. Possible a weather map transmitted from Tokyo as noted in the comments section by Syd, or 4xFSK from China as identified by K2RCN in the comments.

# (4)

Sample Audio:

Found Frequency: HF Band

Description: Periodic pulses. Sound sample recorded in USB mode. Possibly a GlobeWireless signal as identified in the comments section by K2RCN.

# (6)

Sample Audio:

Found Frequency: 152.652 MHz

Description: Continuous signal. Audio sample recorded in NFM.

# (7)

Sample Audio:

Found Frequency: 162.863 MHz

Description: Continuous bursts. Audio sample recorded in NFM.

# (8)

Sample Audio:

Found Frequency: 457.168 MHz

Description: Audio sample recorded in NFM.

# (10)

Sample Audio:

Found Frequency: 452.325 Mhz

Description: Sent in over email. Sounds like Motorola Type II smartnet, but Unitrunker does not recognize.

# (12)

Sample Audio:

Found Frequency: 154.646 MHz

Description: Sent in over email. Repeats every minute.

# (14)

Sample Audio:

Found Frequency: 433 MHz

Description: Sent in over email.

Hello! I was listening in the 433MHz band and saw this blip (about 1-2sec) on the waterfall on 433.873 (Millville, MA). It repeats about every 30-50 seconds, though doesn’t seem to be the same every time. Maybe a wireless instrument of some type (weather or something?). The only clear sound of it I could get was with AM, about a 4.2kHz wide filter (rtl-sdr, gqrx linux). Any ideas? Thanks!

# (15)

Sample Audio:

Found Frequency: 455 MHz

Description: Sent in over email.

# (16)

Sample Audio:

Found Frequency: 173.262 MHz

Description: Sent in over email.

# (18)

Sample Audio: None

Found Frequency: ~856 MHz

Description: Sent in over email.

The antenna has a Yagi pointed to West from 23.5° South latitude, 47.46° West longitude.
The signal can be local or from the sky. The signal is horizontal polarized.

# (19)

Sample Audio:

Found Frequency: ~409.6 MHz

Description: Sent in over email. Recorded in NFM mode.