Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

   Home   Help Search  
Pages: [1]   Go Down
  Print  
Author Topic: What we need is auto-mode-detection!  (Read 7341 times)
NE1R
Member

Posts: 1




Ignore
« on: February 04, 2012, 06:10:41 AM »

I have recently been playing with a mode called M110A on MARS frequencies and I discovered what is missing from Ham Radio digital modes -- automation.

The thing that frustrates me about digital modes and keeps me from enjoying them, is the hassle of trying to figure out which mode a signal is using, what speed, what parameters, etc... By the time I try a few combinations by trial and error, the signal is gone and the opportunity is missed.

With M110A, the software detects a signal, determines it's baud rate and interleave length and even its amount of error in RF frequency.  It displays those to you as it begins decoding the message and then tells you when the message is done.

Now, how cool would it be if that concept were applied to HRD or MixW, or whatever?  You could see a signal on the waterfall, click on it, the SOFTWARE would determine what mode, speed, parameters it was and tell you and automatically set your signal to reply in kind.  THAT would be cool and well worth paying for!

If anyone has a connection to the computer wiz kids known as @Anonymous, why don't you tell them this would be a worthy challenge for their talents instead of hacking into trivial conference calls and stealing credit card numbers.

73,
DE NE1R
Logged
W8JX
Member

Posts: 6468




Ignore
« Reply #1 on: February 04, 2012, 07:25:40 AM »

Actually the trick here is mode ID transmitted at start of transmission. I am not just talking ID in waterfall. Some software supports this and some does not. Until they all do it will never work as intended though. HRD or Mix W is that the best there is for this game though.
Logged

--------------------------------------
All posted wireless using Win 8.1 RT, a Android tablet using 4G/LTE/WiFi or Sprint Note 3.
G0GQK
Member

Posts: 634




Ignore
« Reply #2 on: February 04, 2012, 11:45:09 AM »

I find the same irritation when I've seen an unusual trace. The callers always give short blasts and then vanish when they don't get a response. Users of PSK 31 have much longer CQ calls because its slower, but even some people using 31 seem to think a couple of quick blasts of their call sign will get them a response.

Mel G0GQK
Logged
KX5JT
Member

Posts: 217




Ignore
« Reply #3 on: February 04, 2012, 01:31:08 PM »

RSID
Logged
AA4PB
Member

Posts: 12986




Ignore
« Reply #4 on: February 04, 2012, 06:04:27 PM »

Its not complicated but the key is that the mode ID has to be transmitted in a universally common mode so that the receiver can decode it to find out what mode the actual data transmission is using. The issue there is that you have to be listening at the time the mode ID is transmitted (beginning and/or end of transmission). For example, a real simple solution would be to end the transmission with a CW ID that contained the mode. RSID is similar except that it uses a PSK ID transmission that can be decoded via software.

It would be very complex to have the receive software actually analyze the transmission to determine the mode. At the very least you would have to ensure that the radio is set so that the entire signal is contained within the passband before there would be any hope of success. Then there is the question of how long it takes the computer to analyze the signal and pick a mode from all the many different possibilities.
Logged
STAYVERTICAL
Member

Posts: 875




Ignore
« Reply #5 on: February 04, 2012, 08:31:07 PM »

What you want is already there and used in DM780, FLdigi and Multipsk.
Some of them throw up a hyperlink and if you click on it will change the program settings to the correct mode, and if you have radio control, even change the frequency or mode on your radio accordingly.

This will only work however if you have RSID receive enabled, and the station on the other end has RSID transmission enabled.
RSID just sends a sequence of tones at the beginning and sometimes end, of the transmission which allow mode identification.
Unfortunately, not everyone uses digital programs which support RSID, and many just don't bother to turn it on.
Not every mode has RSID defined but the majority do, and the most used ones certainly have.

There is also a feature called "video ID" on those same (and many other) programs.
They will send an abbreviated mode ID in a way that simply displays as a small picture on the waterfall, thus not needing any special software to receive, except for a waterfall display.
If I am using an exotic mode, I typically use both RSID and VIDEO-ID so that anyone receiving will know the mode I am using, whether they have an RSID capable program or not.
So there are plenty of options out there, but many hams either don't know about them, or choose not to use them.

Having a generalised program to identify modes is certainly possible, but probably the need is not perceived to be great enough to warrant the effort.

For example, one method I could see of solving the problem without actually having to try each mode and decode some text, is to use a neural network and train it with examples of the preambles in each mode and sub-mode.

This is similar to methods used to read zip codes or differentiate mines from rocks on the sea floor, and has the advantage that it is extensible easily.
Neural networks however, need careful management, since if you add new data it may disrupt already existing data, but these issues are well known and there are many different topologies which could be utilised, and the most appropriate selected.

Sorry, I am not in the market for this enterprise since I am still trying to figure out a foolproof betting system for Vegas (hi).

73s

« Last Edit: February 04, 2012, 08:37:43 PM by STAYVERTICAL » Logged
W0BTU
Member

Posts: 1800


WWW

Ignore
« Reply #6 on: February 05, 2012, 04:39:31 AM »

I discovered what is missing from Ham Radio digital modes -- automation. The thing that frustrates me about digital modes and keeps me from enjoying them, is the hassle of trying to figure out which mode a signal is using, what speed, what parameters, etc... By the time I try a few combinations by trial and error, the signal is gone and the opportunity is missed.

I've been saying this for some time. But every time I do, somebody either says to use RSID or go to http://www.w1hkj.com/FldigiHelp-3.20/Modes/index.htm. Okay. Thank you.

The problem with RSID is that it's off by default (at least in Fldigi), and I seldom see a signal with it enabled (READ: almost nobody uses it)!
And even when RSID is enabled, it's only sent occasionally.
This means that RSID is effectively almost worthless! There's GOT to be a better way.

Can't an algorithm be written to determine what mode and sub-mode is being received? I'm convinced that the right software algorithm can determine at least some digital modes. Once that happens, the software could automatically switch to the correct mode.

Each mode has multiple tones of a fixed duration of a spaced by a fixed amount. I've written enough software to know that an algorithm can be written to determine:

How many frequencies (tones) there are in the passband
What the duration of the tones is
What the spacing of the tones is

... and figure out the mode from that.

Of course, this wouldn't work well with very weak signals, or on a crowded band (unless we narrow down our passband). But anything is better than the status quo!

Somebody either has software that does this now, or will have in the future.
« Last Edit: February 05, 2012, 05:01:41 AM by W0BTU » Logged

AB2KT
Member

Posts: 62




Ignore
« Reply #7 on: February 05, 2012, 08:48:10 AM »

Somebody either has software that does this now, or will have in the future.
"Automatic Signal Classification for Software Defined Radios," QEX Dec 2003.
"Robust Signal Classification Using the Wavelet Transform for Feature Extraction," http://groups.winnforum.org/p/cm/ld/fid=56.
Logged
AA4PB
Member

Posts: 12986




Ignore
« Reply #8 on: February 05, 2012, 11:12:07 AM »

"How many frequencies (tones) there are in the passband
What the duration of the tones is
What the spacing of the tones is"

The question becomes how do you know that all the tones in the passband belong to the desired signal (not QRM) and that all of the desired signal's tones are present in the passband? Different modes occupy different bandwidths. For PSK31 the signal is pretty much contained within a 50Hz bandwidth. Many other modes require 500Hz or greater bandwidths. Once the bandwidth issue has been solved, using a computer to identify the signal mode is not terribly complex.

I find some of the wider bandwidth, multiple tone modes to be quite difficult to tune in correctly and get copy even when I know what the mode is unless the signal is pretty strong and stable and there is no QRM.
Logged
W0BTU
Member

Posts: 1800


WWW

Ignore
« Reply #9 on: February 05, 2012, 11:44:50 AM »

... how do you know that all the tones in the passband belong to the desired signal (not QRM) and that all of the desired signal's tones are present in the passband?

Good question. In the simplest implementation, the user could manually select the desired signal. Perhaps by click-dragging the mouse across the signal in the waterfall to select it.
Logged

AG6WT
Member

Posts: 475




Ignore
« Reply #10 on: February 06, 2012, 07:43:53 AM »

If I understand the M110A spec., it has a preamble for the purpose of identifying the signal and synchronizing the receiving modem. So in a sense, RSID is included in every M110A transmission.

Automatic mode detection would be nice but considering the number of available modes, the problems of QRN, QRM, and QSB, it isn't likely to happen, at least not globally. You might find a middle ground if you can narrow the problem space. For example, you might have to tell the automatic mode detection algorithm your best guess, like "I think this transmission is Olivia or Contestia between 7.036 - 7.037 MHz".

But if we are insisting that someone should create and perfect a new piece of software, it might be easier if we instead lobby for the adoption of RSID, much in the same way as you are required to id your transmission with your callsign, or lobby the digital mode software authors to include RSID as a uncheckable setting with their CQ macros.
Logged
KX5JT
Member

Posts: 217




Ignore
« Reply #11 on: February 06, 2012, 05:11:37 PM »

I think that's a great idea.  If the software had RSID turned on by default, that would be a great solution!
Logged
AK7V
Member

Posts: 251




Ignore
« Reply #12 on: February 08, 2012, 01:22:16 PM »

I agree, someone should do it.  RSID works, but hardly anyone uses it.  Determining what modes are in use on a given waterfall is not an intractable problem -- the decoding scheme only needs to look for signals that it is itself capable of decoding.  If a signal is truncated at the edge of a waterfall, it's ignored or flagged as unknown.  I don't think comparing a waterfall to maybe 30 or 40 digital modes (including differences in bitrate/bandwidth/etc) would take too much computation time.  The user could speed it up by "bracketing" the signal within a passband, so the program would only have to try and match that particular signal.  If there are ambiguities in polarity or sideband, the program could look for the solution that results in decoded ascii character values as opposed to other, uncommon ascii values.

Not sure why this isn't a feature in existing software.  I'd do it if I had the time, but I don't.  Could even be a simple "brute force" script -- decode the selected signal using all decoders and display all results in a window.  Click on the one that looks like intelligible text (or have the software decide) and there you go.  That's essentially what I do, except I have to make several clicks to change modes, wait a second for the decoder to catch up, and look at the results.  By the time I get through 4 or 5 iterations, the signal is likely gone.
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!