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] 2 Next   Go Down
  Print  
Author Topic: DuoTone3 FSK (a digital mode I made myself)  (Read 5710 times)
KE7IZL
Member

Posts: 47




Ignore
« on: August 01, 2011, 08:41:23 PM »

I made designed a digital mode of my own. I wrote the program in Visual Basic 6 to write a WAV file as output. To actually send the signal, you have to load it into an audio player such as Windows Media Player. Unfortunately the techniques for decoding digital modes (FFT, and other advanced algorithms) are well beyond my ability to write a program for. So I leave the creation of RX software to someone with more knowledge than myself. All the specs you'll need to write a program using my mode can be found by examining the source code of my program. The complete source files for VB6 as well as a compiled EXE, can be found in the zip package here http://www.mediafire.com/?v0qd6lt96mdv47h
Logged
W5DQ
Member

Posts: 1209


WWW

Ignore
« Reply #1 on: August 02, 2011, 01:42:53 PM »

I made designed a digital mode of my own. I wrote the program in Visual Basic 6 to write a WAV file as output. To actually send the signal, you have to load it into an audio player such as Windows Media Player. Unfortunately the techniques for decoding digital modes (FFT, and other advanced algorithms) are well beyond my ability to write a program for. So I leave the creation of RX software to someone with more knowledge than myself. All the specs you'll need to write a program using my mode can be found by examining the source code of my program. The complete source files for VB6 as well as a compiled EXE, can be found in the zip package here http://www.mediafire.com/?v0qd6lt96mdv47h

Sounds much akin to WRITE ONLY MEMORY (WOM)  Grin
Logged

Gene W5DQ
Ridgecrest, CA - DM15dp
www.radioroom.org
KE7IZL
Member

Posts: 47




Ignore
« Reply #2 on: August 02, 2011, 04:58:43 PM »

I made designed a digital mode of my own. I wrote the program in Visual Basic 6 to write a WAV file as output. To actually send the signal, you have to load it into an audio player such as Windows Media Player. Unfortunately the techniques for decoding digital modes (FFT, and other advanced algorithms) are well beyond my ability to write a program for. So I leave the creation of RX software to someone with more knowledge than myself. All the specs you'll need to write a program using my mode can be found by examining the source code of my program. The complete source files for VB6 as well as a compiled EXE, can be found in the zip package here http://www.mediafire.com/?v0qd6lt96mdv47h

Sounds much akin to WRITE ONLY MEMORY (WOM)  Grin

Which is why I said "So I leave the creation of RX software to someone with more knowledge than myself". I indeed someone takes up the cause and writes me a receiving software for this mode.

Here's a zip archive containing a WAV file of "CQ CQ CQ DE KE7IZL KE7IZL KE7IZL" (not including the quote marks) being sent in DuoTone3 FSK, but rather the WAV file that my program itself generates. It also has a spectrogram of the signal created by using Spectrogram16, and then playing the sound from WMPlayer, while the soundcard input was set (using Windows Mixer control) to monitor the soundcard output. http://www.mediafire.com/?pd88bzvu8m29jq6
« Last Edit: August 02, 2011, 05:20:18 PM by KE7IZL » Logged
AA4HA
Member

Posts: 1503




Ignore
« Reply #3 on: August 05, 2011, 08:57:48 AM »

What are the benefits, advantages of this new mode? You cannot quantify it in any way unless you can encode and decode the data stream and do at least some basic analysis of how the mode is going to behave across a radio link. We have no way of knowing what the data rate will be, how well it deals with fading, SNR, phase distortions, etc.

Designing the decoder is usually the most challenging part. Having worked in radio and telephone modem design and CODEC's in the past you try to come up with a specification and then attack the problems systematically.
Logged

Ms. Tisha Hayes, AA4HA
Lookout Mountain, Alabama
KE7IZL
Member

Posts: 47




Ignore
« Reply #4 on: August 05, 2011, 07:24:10 PM »

What are the benefits, advantages of this new mode? You cannot quantify it in any way unless you can encode and decode the data stream and do at least some basic analysis of how the mode is going to behave across a radio link. We have no way of knowing what the data rate will be, how well it deals with fading, SNR, phase distortions, etc.

Designing the decoder is usually the most challenging part. Having worked in radio and telephone modem design and CODEC's in the past you try to come up with a specification and then attack the problems systematically.

I already know the data rate. This, and all other specs should be in the source code as "remark" lines. You can download the source package (complete with a compiled EXE file as well) from this link:
http://www.mediafire.com/?v0qd6lt96mdv47h

Also the only way I can check its effectiveness in different radio propagation conditions is to actually have a decoder and try it out for real.
Logged
K9IUQ
Member

Posts: 1983




Ignore
« Reply #5 on: August 07, 2011, 02:17:03 PM »

What are the benefits, advantages of this new mode?

My question would be why do we need yet another digital mode that no one uses? There are presently many many different digital modes to choose from. Last time I counted FLdigi had around a dozen different modes and most modes had many different variations.

Use one of the little used modes, call CQ and no one will answer because no one can figure out what mode you are using.  Grin Grin

Stan K9IUQ
Logged
W3HF
Member

Posts: 696


WWW

Ignore
« Reply #6 on: August 07, 2011, 06:08:15 PM »

Also the only way I can check its effectiveness in different radio propagation conditions is to actually have a decoder and try it out for real.

If you can specify the modulation's waveform mathematically, a communications system engineer/analyst can predict performance under various types of channels (AWGN, Rayleigh fading, shot noise, etc). But usually those concepts are factored into the creation of the waveform, so that the waveform addresses some deficiency in other systems. For example, trying to minimize bandwidth (e.g. PSK31), or inserting enough coding and interleaving to counter rotation of a spacecraft (the new BPSK1000 mode that is on ARISSAT), or using extremely slow data rates (and specific data protocols) for extremely weak signals (JT65), etc.

Simply "inventing" a new mode without understanding the interrelationships between requirements and features seems akin to building a house without understanding either local building codes or the needs of the prospective occupants. Maybe it will work, but maybe you'll end up with a Winchester Mystery House.

I wish you luck with this, but frankly I doubt you will find much help unless you do more than beg for assistance, and then ask everyone who might help to read the remarks in your source code.
« Last Edit: August 12, 2011, 05:00:39 AM by W3HF » Logged
KE7IZL
Member

Posts: 47




Ignore
« Reply #7 on: August 08, 2011, 11:04:21 PM »

Let me spell out the signal description the best I can. Each character is composed of 6 bits. It is based on ASCII. Instead of starting with starting with 0 = null, it starts with 0 = space. That means it's the ASCII code shifted down by 32 (usually space is ASCII code 32). In order for someone to force a next line with the enter key must work. Normally that's ASCII 13 then 10 (Carriage Return then Line Feed). With this new mode I've changed those codes to the top 2 numbers for 6 bits. Carriage Return is now code 62 and Line Feed is now code 63.  It has no "null" or other control characters. It doesn't need null, as it is not designed to keep typing while transmitting (as with BPSK31) but rather is meant to type then send (like Packet Radio).

The tones encode the bits as follows. There are 3 symbols for each character with each symbol containing 2 bits. The actual modulation uses a combination of Time Division Multiplexing, Frequency Division Multiplexing, and Frequency Shift Keying.

For the Time Division Multiplexing aspect of it, it works like this.
The first symbol contains bits 0 and 1, the second symbol contains bits 2 and 3, and the third symbol contains bits 4 and 5. Each symbol is transmitted consecutively, not concurrently.

For the Frequency Division Multiplexing aspect of it, it works like this.
Bit 1 is 50Hz above bit 0, bit 2 is 50Hz Above bit 1, etc; all the way up to bit 5 which is 50Hz above bit 4.

For the Frequency Shift Keying aspect of it, it works like this.
A given bit's binary "on" position is represented by a tone with a frequency exactly 300Hz above the binary "off" position for that bit.

The lowest frequency used is 500Hz




The 12 frequencies this digital mode uses (sorted by symbol, then by bit number) are as follows:

Symbol 1
500Hz = Bit 0 Off
800Hz = Bit 0 On
550Hz = Bit 1 Off
850Hz = Bit 1 On

Symbol 2
600Hz = Bit 2 Off
900Hz = Bit 2 On
650Hz = Bit 3 Off
950Hz = Bit 3 On

Symbol 3
700Hz = Bit 4 Off
1000Hz = Bit 4 On
750Hz = Bit 5 Off
1050Hz = Bit 5 On

So only 2 tones are transmitted at any given time.



The data rate is 20baud (20 symbols per second). With 3 symbols per character, that means 6.66666667 characters per second, or 400 characters per minute.

That's it for the data portion of the signal, but before the data signal comes the sync signal. It is a tone FSK modulated by a square wave. It lasts 20 data periods (one full second at 20baud) and alternates between 500Hz (same frequency used by Bit 0 Off in the data signal) and 800Hz (same frequency used by Bit 0 On in the data signal). So there are 10 periods of 500Hz interleaved with 10 periods of 800Hz (as controlled by the square wave modulation of the sync signal). I do this to synchronize any possible receiving software that someone may eventually write to allow my signal to be decoded. As such, this would have to be programmed to be recognized by that receiving software. It also allows for extensions to my mode to be developed (different baud rates and different frequency spacings) in possible future versions of my TX software without someone needing to rewrite the RX software to accommodate it or require manual control of the RX specs. If the RX program does (and it should) detect this sync signal, it will be able to automatically set its data receiving parameters to those it discovers by that decoding of the sync signal (automatic baud rate, and frequency spacing detection, as well as autostart decoding data at end of sync). This though means that it will have to hear the beginning of that transmission (the sync signal) before it can correctly decode the transmitted data.

How will decoding stop? Simple, if the signal stops for at least 3 data periods (3/20th of a second at 20baud), which is one character long it will assume the data is done being sent. Also if it receives a burst of noise or fade that obscures the signal for less than 3 data periods, or receives 1 or 2 nonsynced data symbols (a nonsynced data symbol is something that contains 1 or 2 bit errors, such as a valid frequency for bit 5, but during the time slot for symbol 1 which only contains bits 0 and 1), then it should assume that there was some error in the transmission and display the character ÿ (which is ASCII code 255) which is not within the 6 bit ASCII range of transmittable characters, in place of whatever character contained these 1 or 2 symbol errors. Also if there are at least 3 consecutive such "nonsynced data symbol" errors (enough to represent an entire character's data being corrupted, though it may not line up with a character's data boundries) it should be considered that the data transmission got somehow out of sync and therefore void the rest of the transmission (it should stop decoding the signal at this point, just as if the signal faded or got "lost in the noise" for that same 3 symbol period) until the next transmission starts (that is, until it "hears" the next sync signal, which occurs at the beginning of the data transmission). It is sort of like Packet, only slower and not containing error correction "hash" data.
I've specified here how I believe the decoding and error handling should be done. However as I've not written a decoder yet, there are no "official" decoder specs. It's entirely possible that my mode could be made even better without changing the transmission but rather by using better decoding and error handling techniques than I've outlined here. It will be up to the person who writes the decoder to decide what to use. At which point if he publishes his RX software specs, they will then become the official decoder specs for this mode.


So what are the advantages/disadvantages of this mode (assuming my above specified decoder specs are used)?

Advantages:
  • * It only has 6 bits so the transmission is faster than 7 or 8 bit ASCII.
  • * It sends 2 bits at any given time, so it's faster than most FSK modes which are strictly serial data modes (Baudot, Ascii, Amtor, etc).
  • * It can detect errors and determine if the errors are likely to continue (3 or more shuts off decoding of the signal until next sync, 1 or 2 errors within a character displays error character ÿ).
  • * If it detects 1 or 2 errors only within a character it can remain in sync because the bits are sent at unique times and frequencies for each of the 3 symbols within a character, so it can tell EXACTLY which symbol it's on just by which frequency tones are being used at a given time (normal FSK modes can't tell what bit is being received unless it started at the beginning of the transmission and stayed synced for the whole transmission without any disruptions at all).
  • * It uses only about 1050Hz bandwidth (frequency tones cover 500 to 1050 Hz, a 550Hz span, and taking into account modulation sidebands, add about 500Hz to the span of used frequencies for total bandwidth 550+500=1050). Thus it won't hog the limited frequency space in the ham bands as easily as some other modes (like ALE) do.

Disadvantages:
  • * Given my above suggested decoder specs, only one full character (3 symbols) messed up will force a decoder to stop decoding (I'm guessing someone else can come up with a better idea of number of ruined symbols to force a stop than only 3, that was just my first idea, but one should make sure that not too many characters get turned into ÿ or it's just wasted processor power on the RX end after it hits a string of errors without shutting off the decoding). This means relatively short bursts of noise can kill a transmission under my current suggested error handling.
  • * Relatively wide frequency range (not 170Hz like RTTY) means it's more susceptible to "selective fading".
    Doesn't use true error correction like Reed Solomon, so errors in the data can't actually be removed, only indicated as errors with ÿ on receiving end.


And one last thing.
Here's a zip archive containing a WAV file of "CQ CQ CQ DE KE7IZL KE7IZL KE7IZL" (not including the quote marks) being sent in DuoTone3 FSK (or more acurately the WAV file that my program itself generates using my DuoTone3 FSK mode). It also has a spectrogram of the signal created (used Spectrogram16 for that), and then playing the sound from Windows Media Player, while the soundcard input was set (using Windows Mixer control) to monitor the soundcard output so Spectrogram16 could "hear" the wave file being played from Windows Media Player.
The zip file containing the WAV file and the spectrogram can be download from the link below.
http://www.mediafire.com/?pd88bzvu8m29jq6



Ok, sorry that was SOOOOOOOOOOOOO LOOOOOOOOOOOONG of a post. It's just that it's complicated to describe a digital mode in technical terms.
Logged
KX5JT
Member

Posts: 217




Ignore
« Reply #8 on: August 09, 2011, 08:31:09 PM »

What are the benefits, advantages of this new mode?

My question would be why do we need yet another digital mode that no one uses? There are presently many many different digital modes to choose from. Last time I counted FLdigi had around a dozen different modes and most modes had many different variations.

Use one of the little used modes, call CQ and no one will answer because no one can figure out what mode you are using.  Grin Grin

Stan K9IUQ


Stan, I have been having a lot of great qso's in the more obscure modes thanks to RSID.  

Also Stan, be careful not QRM my OLIVIA cq on 10.1413 in the early mornings.  You threw out a CW CQ right on top of my ongoing CQ.  Maybe you didn't hear my signal?

John, KX5JT
« Last Edit: August 09, 2011, 08:43:41 PM by KX5JT » Logged
KE7IZL
Member

Posts: 47




Ignore
« Reply #9 on: August 09, 2011, 10:24:04 PM »

That Thor mode in Digifldr (or whatever it's called) seems a lot like Domino EX.
Logged
WB6RQN
Member

Posts: 484




Ignore
« Reply #10 on: August 10, 2011, 04:11:09 PM »

Thor is a reimplementation of the FEC on DominoEX. The FEC in DominoEX was lifted pretty much intact from MFSK-16 and is not really optimized for DominoEX. Thor was an attempt by W1HKJ (author of fldigi) to improve that.

73 de Brian, WB6RQN/J79BPL
Logged
K9IUQ
Member

Posts: 1983




Ignore
« Reply #11 on: August 10, 2011, 06:28:35 PM »

Also Stan, be careful not QRM my OLIVIA cq on 10.1413 in the early mornings.  You threw out a CW CQ right on top of my ongoing CQ.  Maybe you didn't hear my signal?

John, KX5JT


John, we seem to have a problem. I never call CQ on 30 mtrs. NEVER. The last time I was on 30 mtrs was 3-22-11 and I worked 6V7D. I use 30 mtrs for DX only. I never call CQ and I can count on 2 or 3 fingers the ragchews I have had on that band. It is not a band I frequent.

In fact I have not called CQ on CW in several years on ANY band. I work CW frequently but do not call CQ. On CW I work DX and DXexpedtions. I am not interested in working CW Domestic stations on 30 mtrs..

So either:

1. Your CW skills need work
2. You are lying.
3. A Pirate, which is highly unlikely even tho there are many who hate me because of my Flexradio views.

So, which do you pick John?

Please apologize or explain....

Stan K9IUQ


« Last Edit: August 10, 2011, 06:46:13 PM by K9IUQ » Logged
KX5JT
Member

Posts: 217




Ignore
« Reply #12 on: August 10, 2011, 08:34:10 PM »

Stan.  I hate liers and thieves.  I am neither one.  

I could possibly be mistaken on the callsign.  Actually my CW skills do need much improvement.   In fact I HOPE I am because then that would mean someone is pirating your call with the intent of upsetting the applecart.  If someone did use your call, I feel it would likely be someone who reads these forums, seeing how you and I have been posting a bit.

Forgive me for accusing you.  I probably should have formed a question instead of jumping on it as a statement.  Here is an olive branch.

If we can now get passed this, I see you are a boatanchor enthusiast and an A.M. operator.  I would love to work you sometimes from my modified Johnson Viking II and National NC-300.

(sorry to hijack the thread guys, we can get back to the topic at hand now)

BTW, Ben, KE7IZI, I would like to see your "new mode" in action.  It sounds a lot like THOR or DominoEX from listening to the audio files.
Logged
K9IUQ
Member

Posts: 1983




Ignore
« Reply #13 on: August 11, 2011, 05:27:06 AM »

Stan.  I hate liers and thieves.  I am neither one.  

Forgive me for accusing you.  I probably should have formed a question instead of jumping on it as a statement.  Here is an olive branch.

John, Apology accepted. You were a little accusatory with your original post and perhaps I was a little defensive. IMO the proper way to handle something like this is a private email instead of trying to embarrass someone on a public forum.

I knew it was not me without even looking at my logbook because I simply do not call CQ on CW.

73
Stan K9IUQ


« Last Edit: August 11, 2011, 05:31:54 AM by K9IUQ » Logged
KX5JT
Member

Posts: 217




Ignore
« Reply #14 on: August 11, 2011, 06:24:20 AM »

Stan.  I hate liers and thieves.  I am neither one.  

Forgive me for accusing you.  I probably should have formed a question instead of jumping on it as a statement.  Here is an olive branch.

John, Apology accepted. You were a little accusatory with your original post and perhaps I was a little defensive. IMO the proper way to handle something like this is a private email instead of trying to embarrass someone on a public forum.

I knew it was not me without even looking at my logbook because I simply do not call CQ on CW.

73
Stan K9IUQ




Indeed, you are correct.  It is I who are embarrassed.  I am still trying to put into practice some lessons about not reacting to anger right away, because it really discolors reality.  Smiley

Logged
Pages: [1] 2 Next   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!