Question about Amtor A mode

[Ben Hutchinson]

I noticed that MultiPSK has an Amtor A receive-only mode. However it has no TX for this mode, so I have no way to even test its reliability, nor do I have a hardware TNC for sending Amtor A either. So I decided to make an Amtor A test signal generator software. And I learned something interesting. Amtor A (a.k.a. Amtor ARQ) has 7 bits per character and always 3 mark (binary 1s) and 4 space (binary 0s) bits (where mark corresponds to high pitch tone of the FSK, and space corresponds to the low pitch tone). This means that all I need to know now is the correct encoding table, that is what combination of 3 marks and 4 spaces do I need for each character in the Amtor A character set. So here comes my question. Where can I get a full technical document on the Amtor A mode that will have the info I need?

[5B4AJB]

My Kantronics KAM manual has quite a bit of info on it, Wikipedia has some links, looks like you'll have to trawl Google to find the character table, shift register etc...

[Ben Hutchinson]

My Kantronics KAM manual has quite a bit of info on it, Wikipedia has some links, looks like you'll have to trawl Google to find the character table, shift register etc...

Do you suppose you could scan the pages of your manual that have to do with the Amtor A mode, and post a zip file containing PNGs of the scanned pages?

[5B4AJB]

http://www.quadibloc.com/crypto/jscrypt.htm

Surely on these pages (if you can find it)...

[edit]

Digging a bit deeper, I think this is what you're looking for:-
http://www.quadibloc.com/crypto/tele03.htm

[Ben Hutchinson]

Thanks for the info. This could prove useful. By the way I already finished making the software in question. I finally found a source (even before you replied) with info on the needed Amtor character set table. After debugging (involving both binary inversion of 1->0 and 0->1, and bit order reversing until I figured out what the correct code exactly was), I finally got my Amtor A tester working.

Download from here.
http://www.mediafire.com/?0hl6cdtc8cpmc9a

When used with MultiPSK, make sure you set MultiPSK to "professional modes" Sitor A if you are going to send an ! to MultiPSK, as MultiPSK uses the same code for ! in Sitor A as it does for % in "amateur modes" Amtor A. This means that if you send ! in this program it will incorrectly show up as % in MultiPSK's Amtor A mode, but will display correctly as ! in Sitor A mode. However if you intend to use every character but ! you can then use either Amtor A or Sitor A mode in MultiPSK. As I don't have an actual Amtor TNC I have no way of testing it with real hardware.


On another note, do you happen to have a scan of your Kamtronics manual you mentioned? That might prove useful just for its technical information.

[5B4AJB]

I'll have to dig it out of the shed, I looked on the Kantronics website, but the old KAM manual isn't there and didn't find anything very useful online, apart from that site I mentioned...

[Ben Hutchinson]

Here is my completed program again. But this time I corrected some errors and added a couple new features. This is now version 1.1 (original I posted was version 1.0). Also before I only posted the Amtor A test signal generator, but this time I'm posting a zip file containing both that one and the other one I wrote which is for 7bit ASCII FSK (in MultiPSK it's just called "ASCII" mode and with the 8bit sub-mode turned off). The two programs I wrote are called ASCII FSK.exe and Amtor ARQ.exe and the zip file containing them both can be downloaded from: http://www.mediafire.com/?ch790jxh2jhupmt


My project was originally to test my ability to write software using VB6 alone that could send an audio signal that could be decoded in MultiPSK. The obvious choice was ASCII mode, as it is the same encoding used by computers, and the ASCII value of a single text character in VB can be gotten with the simple command ASC(StringVariableContainingCharacter). After that, I realized the need for an Amtor/Sitor ARQ test signal generator. Because of the nature of a synchronized ARQ signal and the tight timing requirements of switching between RX and TX so rapidly, no digital-modes software writer has bothered to make a program that even attempted this feat. Of the few programs that even handle Amtor/Sitor ARQ, they only handle RX. This left me with NO WAY to test out their RX ability. So I decided to write a program that did TX only. It wouldn't attempt to switch back and forth repeatedly between RX and TX so that it could listen for an ACK so it could know to transmit the next packet instead of resend the old one. Instead it simply plays silence during that time (it is always TXing during the time it's actively playing the sound, even in the breaks between packets), and thus each next packet is always the next packet sent, never does it have to resend the previous packet (although in a future version I may add a checkbox button that makes it always send 2 of the same packet to test a software's Amtor A RX-only ability to reject the second pack in a pair of identical packets). By using TX always, there is no losing sync or such bad things. This allows me to test how well software actually does RX of Amtor A when using software that has an RX-only mode for Amtor A. This means I don't have to shell out big bucks for an actual Amtor ARQ capable TNC to just simply test a piece of software. So that's why I made the Amtor ARQ test signal generator software. So far as I know there is no other software available that does this.

[Ben Hutchinson]

Ok, I finally got the sending redundancy feature (activated with a check box) in my Amtor ARQ software. Also made a couple minor changes to both the Amtor ARQ and ASCII FSK software. These are available in version 1.2 of these pieces of software. Download version 1.2 of both pieces of software in a zip file here.
http://www.mediafire.com/?0c330q81z19o4co


There is one catch with using the Amtor ARQ redundancy feature, though this has to do MultiPSK's internal mechanism for handling redundant packets, and is not a glitch in my program.

Below is a description of the problem that arises in some situations.


What you want to send.
JACK AND JILL WENT UP THE HILL TO FETCH A PAIL OF WATER. JACK FELL DOWN AND BROKE HIS CROWN, AND JILL CAME TUMBLING AFTER.


How Amtor will divide it up.
12312312312312312312312312312312312312312312312312 3123123
JACK AND JILL WENT UP THE HILL TO FETCH A PAIL OF WATER:.

12312312312312312312312312312312312312312312312312 3123123
:JACK FELL DOWN AND BROKE HIS CROWN:, :AND JILL CAME TUM

123123123123123
BLING AFTER:.~~

: represents control characters UseFigures and UseLetters.
~ represents the Idle character


This is fine until you want to double send the packets (redundancy) given the way reception works when not truly using an ARQ system.
Here's what MultiPSK sees when you used forced redundancy on the above text

12312312312312312312312312312312312312312312312312 3123123
JACJACK AK AND ND JILJILL WL WENTENT UP UP TH THE HE HILL

12312312312312312312312312312312312312312312312312 3123123
ILL TO TO FE FETCHTCH A A PAIPAIL OL OF WF WATEATER:.R:.

12312312312312312312312312312312312312312312312312 3123123
:J :JACKACK FE FELL LL DOWDOWN AN AND ND BROBROKE KE HIS

12312312312312312312312312312312312312312312312312 3123123
HIS CR CROWNOWN:, :, :AN:AND JD JILLILL CA CAME ME TUMTUM

12312312312312312312312312312312312312312312312312 3123123
BLIBLING NG AFTAFTER:ER:.~~.~~


Lets look at what happens when just one of these areas involving switching Letters to Figures and back goes bad.

123123123123123123123123
ATEATER:.R:. :J :JACKACK

becomes this
ATEATER:.4:. :J :JACKACK
^ ^
UseFigs| |UseLetters

So UseFigs is canceled by UseLetters but not before sending the R again. Which makes the repeat of the packet containing the R look like it is actually sending a 4 (same code as R but in figs mode, so it looks like a different packet not a duplicate, and thus it is not removed by MultiPSK).
Thus you have a useless data packet containing just garbage.
And it ends up looking like this when displayed.

ATER.4. JACK



To fix this, it must be padded with Idle characters (equivelant to nulls in ASCII, meaning they do nothing but act as padding, while still keeping the signal alive). The UseFigures or UseLetters control character will only work in this scheme if it is the 1st of the 3 symbols in a packet. Therefore the preceeding packet must be padded to 3 characters with Idles so the packet containing the UseLetters or UseFigures will start with that control character. Here's an example of this.

123123123123123
ATER~~:. :JACK

when made redundant becomes this
123123123123123123123123123123
ATEATER~~R~~:. :. :JA:JACK CK

which becomes
ATEATER~~R~~:. :. :JA:JACK CK
^ ^
UseFigs| |UseLetters


And it ends up looking like this when displayed.

ATER. JACK




Here are 2 examples of the the Jack and Jill poem. The first one will work fine with most digital modes, except for my TX only Amtor ARQ when used with sending redundant packets.

JACK AND JILL WENT UP THE HILL, TO FETCH A PAIL OF WATER. JACK FELL DOWN AND BROKE HIS CROWN, AND JILL CAME TUMBLING AFTER.

This second one has been correctly padded with ~ symbols (which will be translated to Idle characters by my program) in order to make it compatible with my program's "Send Redundant Text Packets" mode.

JACK AND JILL WENT UP THE HILL~, TO FETCH A PAIL OF WATER~~. JACK FELL DOWN AND BROKE HIS CROWN, AND JILL CAME TUMBLING AFTER~~.

Now remember if you add any "enter key" line breaks you add 2 control characters CR and LF, which means that the above will no longer be in sync and you'll have to repad the text at the correct spots to make it display correctly once again when received in MultiPSK. And do use MultiPSK. TrueTTY when set for Amtor ARQ reception rarely gets any text right, even when receiving it without forced redundant packets.

[Ben Hutchinson]

I've now released version 1.3 of my ASCII FSK software. It adds the ability to use 8bit Extended ASCII.
Download at: http://www.mediafire.com/?ulnrg5v2kp35hrb

[5B4AJB]

Jack and Jill went up the hill to fetch a pail of water, Jill came down with half a crown, but not for carrying water...

It would be interesting to apply compression of some sort onto the redundant packets, a bit like Pactor.
Not downloaded your work yet, but wonder what tone pair you're using? maybe that could be modified (stretched) as well to further optimise most transceivers (~2kHz split)?

I always felt the standard RTTY split was a bit small - OK, it gets more users on the band, but if it was a bit wider, surely there'd be less errors?

[Ben Hutchinson]

Jack and Jill went up the hill to fetch a pail of water, Jill came down with half a crown, but not for carrying water...

It would be interesting to apply compression of some sort onto the redundant packets, a bit like Pactor.
Not downloaded your work yet, but wonder what tone pair you're using? maybe that could be modified (stretched) as well to further optimise most transceivers (~2kHz split)?

I always felt the standard RTTY split was a bit small - OK, it gets more users on the band, but if it was a bit wider, surely there'd be less errors?

Tone frequencies are fixed. I'm using upper tone of 1000Hz. Frequency shift of 170Hz (so lower tone = 830Hz). By keeping keeping the frequencies where they are they should be within the audio-passband of most SSB tranceiveres, with room to spare. The bandwidth used is about 500Hz (depending on how sensitive you set your spectrogram software, if you set its sensitivity's lower boundary set down to -120dB then the band will look wider than if you only have it set to only -60dB).

My programs don't use any compression for 2 reasons.
1: The official standard for both ASCII FSK and Amtor ARQ never calls for any compression.
2: Huffman compression would be maddeningly hard to code, but especially in VB. I even find it reasonably difficult to program RLE compression in VB. So yeah, I'm not going to be programing Huffman compressed Pactor any time soon. However I might try to make an uncompressed Pactor-1 ARQ test signal generator if such an uncompressed version of the Pactor-1 exists in the official specifications.