Audio data FSK encode / decode

"An ascii version of an RTTY message, sent as a packeted data message".

Much is said regarding "AFSK" or audio frequency shift keying, so I thought to have a go at the subject. To provide a data test signal, I used an Arduino Nano.

First hand I constructed an FSK modulator, there are many designs around, but I thought I would use a 555 timer circuit, shown below:

I thought that using a audio frequency shift from 1200Hz to 2200Hz, would occupy the voice spectrum space for the data signal, thus so hopefully in doing so swamp out any interference signals, upon the received data signal. The frequency shift should hopefully allow data rates up to 1200 bits/s baud rate, going by the manufacturers data sheets of chip spec's. For starters, I chose the XR2211 modem chip, and had a go at finding some results, but however these are my results but the not the intended manufacturers intended end results, I had some difficulty in balancing the chip circuit, but here goes with my attempts.

Now at a data rate of 50 bits/s, that's 50 baud, the following image on my scope was discovered. The test data sequence was one high bit and two low bits, done so to see how although the data sheet s illustrates calculations for the bit rate filter circuit, this would be for one single bit, but two low bits in succession after one high bit, would be a different effective bit rate of the two low bits in sequence, so would perhaps be of a frequency spectrum and time domain than just one bit high the next bit low and so on.

There is an error within the above diagram, as the tuning capacitor between pins 13 and 14, should be a 10nF capacitor, and not as shown.

Shown next below is an image of the 50 baud rate data signal.

At 110bits/s baud rate, the digital scope image is shown below:

Then attempting a 300 Baud rate, the image below:

Then I gave a 600 baud rate ago to see how my circuit set-up would re-act.

My home radio shack lab results are as shown above. I am sure that there is a way of tuning the chip to 1200 baud data signa, but I have not yet worked out how, maybe some one else may perhaps do so.

It transpires that the audio frequency shift from 1200Hz logic low, then up to 2200Hz logic high, it is correct to say the normally a logic high signal is the lower of the two tones, but this is just a test, so perhaps not so quite critical just yet. The audio shift tones cope quite well up to about 300 bits/s, or 300 Baud rate, but after this point, there is not enough audio tone waveform cycles to allow the modem chip to follow the frequency shift from the data signal, and so the chip gives up. As the above image of the 600 baud rate shows, the chip is trying its best.

The reason also why I did the test in this manner, was to find out if the chip would handle data rates from 50 bit/s to 600bits/s without re-balancing the chips circuits. To a point the chip does quite well, but perhaps to a point 300 baud is perhaps the top end, but with some more signal circuits, the 600 baud rate may perhaps just work.

However with the 1200Hz to 2200Hz frequency shift, this amounts to a 1000Hz frequency deviation of the AFSK modulator signal. The thought that comes to mind here, is the modulation index of a frequency modulated signal, irrespective it is an audio frequency shift of the AFSK modulator. For the 50 bits/s rate, the modulation index for this data rate is some "baud rate / AFSK deviation" equates to thus as "1000/50", hence in value of 20, while the 110 bits/s equates to 9, the 300 bits/s then calculates to 3·3, hence finally the 600bits/s equates to then as 1·66. The attempt in choosing this principle, was to try and adopt the wideband FM transmission principle, although would be band two broadcast FM transmission, I though there was no harm in trying this at audio level, to put through the AFSK data signal not only on shortwave, and in the face of all these days interference, but also for VHF/UHF or even for some on the microwave bands. Now shortwave and VHF/UHF I can do but microwave bands are at this moment out of my abilities.

I tried out a modified version of the circuit, increasing the load resistance upon the error voltage from the output low pass filter, the baud rate filter, and also decreased the line resistor to the phase error voltage line. I then re-ran the 600 baud rate test once more.

There is an error within the above diagram, as the tuning capacitor between pins 13 and 14, should be a 10nF capacitor, and not as shown.

It would seem that this modem arrangement has a more stable approach to the 600 baud rate test.

The chips data sheet provides mathematical calculations, so I have written a BBC Basic program to determine the values in an attempt to predict the circuit design. I am not sure how relevant the results are actually, as some degree of trial design tinkering is always needed.

XR2211 Cad code "BBC Basic"

10 REM xr2211 calculation routine

20 F_one = 1200

30 F_two = 2200

40 R_one = 47000

50 R_x = 2500

60 bit_rate = 600

70 delta_f = 1500

80

90

100 F_vco = ((F_two - F_one)/2) + F_one

110 REM F_vco = SQR(F_two * F_one)

120 R_o = R_one*(delta_f/F_vco)

130 R_t = R_o + (R_x/2)

140 cap_oh = 1/(R_t * F_vco)

150

160 R_f = 5 * R_one

170 R_b = R_f * 5

180 cap_one = (1250*cap_oh)/( R_one * 0.5^2)

190 R_sum = ((R_f + R_one)*R_b)/(R_f + R_one + R_b)

200 cap_f = 0.25/(R_sum * bit_rate)

210 REM recheck delta for tracking bandwidth

220 F_delta = (R_o * F_vco)/R_one

230 PRINT TAB(5);"F_one = ";F_one;" Hz"

240 PRINT TAB(5);"F_two = ";F_two;" Hz"

250 PRINT TAB(5);"F delta +/- = ";INT(F_delta);" Hz"

260 PRINT TAB(5);"bit_rate = ";bit_rate;" baud"

270 PRINT TAB(5);"F_vco = ";INT(F_vco);" Hz"

280 PRINT

290 PRINT TAB(5);"cap_tune = ";INT(cap_oh*1E9*10)/10;" nF"

300 PRINT TAB(5);"R_t = ";INT(R_t);" K ohms"

310 PRINT TAB(5);"R_one = ";INT(R_one);" ohms"

320 PRINT TAB(5);"R_o = ";INT(R_o);" ohms"

330 PRINT TAB(5);"R_x = ";INT(R_x);" ohms"

340 PRINT TAB(5);"R_f = ";INT((R_f/1E3));" K ohms"

350 PRINT TAB(5);"R_b = ";INT((R_b/1E3)*10)/10;" K ohms"

360 PRINT TAB(5);"cap_one = ";INT(cap_one*1E9*10)/10" nF"

370 PRINT TAB(5);"R_sum = ";INT(R_sum/1E3);" K ohms"

380 PRINT TAB(5);"cap_f = ";INT(cap_f*1E12);" pF"

390

400

410 END

A sample of calculations results are as shown below, in this case for the 600 baud data rate setting.

To test the AFSK encoder, I have used an Arduino Nano, as the visual basic 2019 terminal interface code that I have managed to write, uses an Arduino Mega. The PC communicates with the Arduino mega at 57600 baud on serial port "0", while serial port "3" is used to interface with the modem, illustrated here in the 300 baud oscilloscope plot image. The vb code is for a poor mans Packet Radio principle, while it does only a message up to 1024 characters, it is serial port "3" that is set to the analog modem baud rate. From the studies shown here, perhaps the maximum of 300 baud would be perhaps possible.

The tx and rx buffer on the Arduino mega is set to 1024 characters. While the base setting for the serial port is 64 characters, I found a way from web references, to reset the tx and rx buffer for the mega in the Arduino ide base file. The vb code works on both a windows 7 and windows 10 machines. The vb code is set that each time one sends out a message, your callsign heads the message data send out via the modem. At present, I am using two Arduino mega boards, connected serial port 3 to serial port 3, the tx and rx wires cross connected.

As an update ( 8th april 2020 ), the arduino mega tx and rx buffers need to be the same size, and also there is a need to flush the serial port "0" and "3", between the tx and rx subroutines. The buffers I have now set to 1500 bytes each, and to do this I have altered the arduino ide base file for "hardwareserial.h" file, by adding an "if conditional test" to determine should an arduino mega is being programmed. Use "notepad++" to modify the arduino ide base file.

I have found that the serial port coding in the Arduino ide does not require a handshake return signal, so then the tx output to the AFSK encoder works as if straight into an microphone socket of ones radio. The rx wire connection likewise also works without the handshake return signalling, so can be connected the radio audio output back into the tone decoder circuit. In each case, the Arduino mega talks to the pc via the usb port, and subsequently to the other ham via the radio, be it on shortwave or vhf / uhf or the microwave bands. The vb coding does not act as a message repeater station, but otherwise between the test win7 and win 10 pc, works as far as I know and can determine, just works well enough. However, there are just one or two niggly things that need sorted out, to finish off the vb coding. In time I hope to post the vb coding via my website, in a exe file. The Arduino mega coding via a text file listing here when also ready. At present I have a working model system between to pc's.

However, the Arduino Nano was used to key the AFSK encoder ( AFSK generator ) to simulate the Arduino mega attache, the AFSK output thus feed into the AFSK decoder using the XR2211 chip..

Arduino Nano test code for FSK modem project

void setup()

{

pinMode(12, OUTPUT);

digitalWrite(12, LOW);

}

void loop()

{

digitalWrite(12, HIGH);

// delay(2);

//delayMicroseconds(833);

delayMicroseconds(833);

digitalWrite(12,LOW);

delayMicroseconds(833);

delayMicroseconds(833);

// delay(2);

//delay(2);

}

Date : 19th April 202

I have found that the varying the baud rate while using a PLL to detect the FSK shift, has a problem that if the PLL loop filter is not changed should the baud rate change, as the voltage bias point to tune the PLL oscillator changes. This causes a miss tuning of the centre frequency of the oscillator, to such a point that the PLL phase error voltage cannot retune the oscillator.

I tried reducing the overall FSK shift frequency, reducing down to 2100Hz high tone and a 1500Hz low tone, thus a +/- 300Hz fsk shift, overall 600Hz. I decided to follow the RTTY tone principle, that being however Logic One a high tone, in this case the 2100Hz tone. The baud rate of 300bits/sec, the FSK shift would be twice the baud rate, but as the AM bandwidth of a baud rate signal is equal to the baud rate, in this case for 300bits.sec, the AM bandwidth is thus 300Hz. The overall FSK shift is 600Hz which would then equate the FM modulation index to a value of 2.

I have also attempted a different approach to detect the FSK tones, which was to un-connect the phase error feedback, thus tuning the oscillator to 1800Hz, and then using the frequency and phase detector of the cmos 4046 to act as a frequency discriminator. Thus to a point worked, but I was also finding a mains hum signal of the power ground line, so therefore created a mains ripple effect of the discriminator output.

The frequency and phase detector thus current or voltage dumping the phase error signal into a low pass filter circuit to reveal the data signal. This revealed itself as a chittery rising side pulse movement, although the falling edge of the data pulse finished without error, always in the same place as the original data signal, comparing the original data signal with the recovered FSK data signal on a dual trace oscilloscope.

There are a couple of ideas to devise a FSK receiver decode circuit, a bandpass filter then into an envelope detector, or to recover the high or low tone for each tone to generate a BFO signal to synchronously recover the data signal. Alternatively, use a frequency to voltage convertor chip, such as LM331 device, available from Amazon.

The synchronous demodulation technique is one used for the recovery of Bi-phase carrier modulated signals, but it would do to recover one of the data tones to generate a audio carrier signal as the tone is detected, hence using an audio BFO technique to resolve the data tone to recover the data signal. If both tones are resolved in this manner to recover the data signal, then two each individual channel lines would need to be built.

By using bandpass filter method, the data baud rate may be changed without any real overall problems. Regarding the use of bandpass filters, the filter "Q" is naturally important in this regard to separate the twin tones, logic high and logic low signalling data tones. Hunting around for good BPF, I came across a gyrator bandpass filter, and old principle that their happens to be little data around these days. However I happened to come across an Australian listing website, the listing used as a study article on this blog, url listed below: https://sites.google.com/site/radiohamtechnology/la3600-5-band-af-equaliser

However for the meantime, to use your packet radio in its basic form, the below code for the Arduino mega part, meaning the micro-controller used for the modem, is listed below. At present I have just got the FSK unit part made, now waiting for the parts delivery from both Ebay and Amazon, postal and cross boarder delivery travel from elsewhere in the world depended, but patients is a virtue, so i'll just bide my time until it arrives.

It is worth noting, that the arduino mega in this case does not us a serial link handshake synchronising principle, thus so, the Serial Tx line may perhaps work independently from the Serial Rx line. Even so, the Rx line can thus receive a packet data sequence, as the Serial Rx line would synch to the data sequence from the received RF signal "Serial Tx line", of the originating radio or cabled transmission.

Arduino Mega code for Packet Radio modem

/*This Arduino Mega code is the data rate translator bewteen the ]

* PC and the audio modem

* Writen by : Alastair GW0AJU

* Date : 26th Mrach 2020

*/

#include <EEPROM.h>

char ch_read;

char radio_read;

int ptt_flag = 1;

int t = 0;

int ledTx = 11;

int audio_enable = 10;

void setup()

{

Serial.begin(57600); // pc link data rate

// Serial3.begin(300, SERIAL_8E2); // modem data rate, SERIAL_8E2 = 300bits/sec, 8 bit data, even parity, 2 stop bits

Serial3.begin(300);

pinMode(ledTx, OUTPUT); // tx / rx indicator

digitalWrite(ledTx, HIGH); // led on

pinMode(audio_enable, OUTPUT); // ptt in Tx mode

digitalWrite(audio_enable, LOW); // ptt in Tx mode

pinMode(8,OUTPUT);

}

void loop()

{

//fsk_test();

send_receive_data();

}

void fsk_test()

{

digitalWrite(audio_enable, HIGH); // activate the Modem audio fsk generaTOR OUTPUT

digitalWrite(8, HIGH);

delay(5000);

digitalWrite(8, LOW);

delay(5000);

}

void send_receive_data()

{

do

{

Serial.flush();

if (Serial3.available())

{

radio_read = Serial3.read(); // read modem

Serial.print(radio_read); // send to PC

}

} while (Serial.available() == 0);

do // tx mode

{

if ((ptt_flag == 1 ) && (Serial.available() != 0))

{

digitalWrite(ledTx, LOW); // ptt in Tx mode

delay(250);

digitalWrite(audio_enable, HIGH); // ptt in Tx mode

delay(250);

ptt_flag = 0;

}

/*

* Place here the modem dtmf signalling

*/

Serial3.flush();

if (Serial.available())

{

ch_read = Serial.read();

Serial3.write(ch_read); // send to modem

Serial.print(ch_read); // send modem copy to PC

}

if ((ptt_flag == 0 ) && (Serial.available() == 0))

{

delay(250);

digitalWrite(audio_enable, LOW); // ptt in Tx mode

delay(250);

digitalWrite(ledTx, HIGH); // ptt in Rx mode

ptt_flag = 1;

}

} while (Serial.available() != 0);

}

However, the Arduino file "HardwareSerial.h" needs modified to allow greater than 64 characters. If you look at the code lines within the text box below, and the image below that, the image uses "notepad++", the file address shown at the top of the image, is where on my computer the Arduino file that needs modified lives.

"hardwareSerial.h" additional code lines

//to discover if an arduino mega is being programmed

#if ((RAMEND == 8703 ) && ( RAMSTART == 512))

#define SERIAL_TX_BUFFER_SIZE 1500 // approx 280 words; modified variable 8th April 2020

#define SERIAL_RX_BUFFER_SIZE 1500 // approx 280 words; modified variable 8th April 2020

#endif

Now when you have found the Arduino file, by adding the new text lines, as shown between code lines 59 to 63, shown below, this will allow the arduino mega modem code to accept upto 1500 characters for the Tx/Rx buffer. The RAMEND and RAMSTART variables allow the mega to be programmed to accept 1500 character, but only the mega, as so if you where to then program an Uno or Nano, then the either 16 or 64 characters is what you will find available, but for the mega, it will be 1500 characters. Once the file option "save" is used, the notepad++ will ask to go into "administrator mode", allow this be clicking the option "ok" or "yes", and the file update will be saved within the Arduino ide program.

Test scripting a text, using also paragraphs, I managed to get 257 words into 1494 characters. Mind you, I did use the word and character count of a word processor, it was a bit easier to do so, than manually counting.

It is quiet simple to pre-prepare a text in either a word processor, or even using notepad, then just "copy and paste" the text into the arduino monitor app that comes with the arduino ide. Alternatively, as I have done, written my own "packet radio" systems "text editor / data terminal" code.

The hard coded buffer size is stored in a file called HardwareSerial.cpp (or USBAPI.h in more recent versions)

https://www.hobbytronics.co.uk/arduino-serial-buffer-size

https://forum.arduino.cc/index.php?topic=395595.0

https://forum.arduino.cc/index.php?topic=399751.0

In its basic form to start using the packet radio Arduino modem, you can use the Arduino monitor program to start using you packet radio, shown below:

Please do note, that the baud rate to the Arduino mega is set to "57600 baud".

Should the Arduino mega modem code be used as such, then as you click the send button on the Arduino monitor app, the modem code will automatically key down the ptt line using a relay, with the radio in Tx mode, the text then sent out as the packet data signal. Once the text has been sent, the modem code will again automatically key the ptt line up, with the radio back into Rx mode.

Have fun.

Oh, I too have been working on a visual basic terminal code to use for the packet radio application here, replacing the Arduino monitor app use. One more thing though, for the fsk generator, I have replaced the two 4700 ohms resistor with a 100K ohm ( an item too hand at the time ) variable pot, to adjust the tones for 2100Hz high, and 1500Hz low. I have though it may be best to use the RTTY method, using the high tone for the logic one data signal, such that logic one is 2100Hz and logic zero is 1500Hz. On reflection, the 100K ohm pot could reduce to a smaller value, as long as the audio frequency shift is obtained, as required.

Now usually in the past, packet radio has been used on FM, but I have tested my fsk unit on my bitx40, which is LSB mode, then picking the 40m signal up on my ft450d. As radios these days are computer controlled, using packet radio on the HF bands should not be a problem, perhaps also be used on 136KHz or 475KHz as well. Now relating to the Arduino mega code, if "serial3.begin" is change to another bit rate, say 9600 Baud, or even 57600 baud, this would be useful for meteor scatter use, or even down to 10bits /sec, for slow speed data use.

Now this version of the Arduino mega modem code, those meteor scatter propagation chaps, the next version, if you send at the end of your message the code "#qsl", you will get an automatic qsl response from the radio ham the other end also using packet radio.

auto qsl message response return message

/*This Arduino Mega code is the data rate translator between the ]

* PC and the audio modem

* Written by : Alastair GW0AJU

* Date : 3rd May 2020

*/

#include <EEPROM.h>

char ch_read;

char radio_read;

String mess;

int ptt_flag = 1;

int t = 0;

int ledTx = 11;

int audio_enable = 10;

void setup()

{

Serial.begin(57600); // pc link data rate

// Serial3.begin(300, SERIAL_8E2); // modem data rate, SERIAL_8E2 = 300bits/sec, 8 bit data, even parity, 2 stop bits

Serial3.begin(300);

pinMode(ledTx, OUTPUT); // tx / rx indicator

digitalWrite(ledTx, HIGH); // led on

pinMode(audio_enable, OUTPUT); // ptt in Tx mode

digitalWrite(audio_enable, LOW); // ptt in Tx mode

pinMode(8,OUTPUT);

}

void loop()

{

//fsk_test();

send_receive_data();

}

void fsk_test()

{

digitalWrite(audio_enable, HIGH); // activate the Modem audio fsk generaTOR OUTPUT

digitalWrite(8, HIGH);

delay(5000);

digitalWrite(8, LOW);

delay(5000);

}

void send_receive_data()

{

do

{

Serial.flush();

if (Serial3.available())

{

radio_read = Serial3.read(); // read modem

mess += (char)radio_read;

if (mess.endsWith("#qsl"))

{

digitalWrite(ledTx, LOW); // ptt in Tx mode

delay(250);

digitalWrite(audio_enable, HIGH); // ptt in Tx mode

delay(250);

Serial3.write("gw0aju, roger qsl direct, irq io??vu, good dx, 73"); // send to modem Serial.print("gw0aju, roger qsl direct, irq io??vu, good dx, 73");

delay(250);

digitalWrite(audio_enable, LOW); // ptt in Tx mode

delay(250);

digitalWrite(ledTx, HIGH); // ptt in Rx mode

}

Serial.print(radio_read); // send to PC

}

} while (Serial.available() == 0);

do // tx mode

{

if ((ptt_flag == 1 ) && (Serial.available() != 0))

{

digitalWrite(ledTx, LOW); // ptt in Tx mode

delay(250);

digitalWrite(audio_enable, HIGH); // ptt in Tx mode

delay(250);

ptt_flag = 0;

}

/*

* Place here the modem dtmf signalling

*/

Serial3.flush();

if (Serial.available())

{

ch_read = Serial.read();

Serial3.write(ch_read); // send to modem

Serial.print(ch_read); // send modem copy to PC

}

if ((ptt_flag == 0 ) && (Serial.available() == 0))

{

delay(250);

digitalWrite(audio_enable, LOW); // ptt in Tx mode

delay(250);

digitalWrite(ledTx, HIGH); // ptt in Rx mode

ptt_flag = 1;

}

} while (Serial.available() != 0);

}

The above image is the Arduino monitor on a win7 laptop, as I have put two Arduino mega back to back, that is cross connected "tx for rx" and "rx for tx" on "serial port 3", the other end on my win10 desktop, and the above image is the auto qsl response return. My win7 laptop sent out the "hi bro how are you #qsl", and the line below ( the auto qsl response message ) was the return response from my win10 pc to the win7 laptop. Now if you are meteor scattering, this modem code maybe perhaps very useful.

Just by sending a hopeful message on meteor scatter, and if it bounces off a meteor, then if you have added #qsl to your message out going, as shown above, then you will get an instance auto qsl contact verification message as the auto response reply, and hopefully just before the meteor scatter contact path fades away.

On my visual basic terminal program, I added a "#Tx" at the beginning of the transmission, then the "#qsl" at the end.

Now, thinking of things now, if the message was as below, perhaps used for an automated meteor scatter qso,

#Tx gw0aju #call cq cq dx qth canada #qsl

The "#call" can be used to indicate the senders callsign, and between the "#call" and the "#qsl" is the packet message, and between "#Tx" and "#qsl", the complete overall packet transmission overall. By using string commands in visual basic, I have managed to add the return callsign, but however here using arduino "C" coding.

My class "b" call was gw6orb, so if I add this in for example, the return packet message my perhaps be thus:

#Tx gw0aju #call gw6orb #reply irq = io??vu, 73 good dx #verify

The reply then to verify contact to the replier,

#Tx gw0aju #call gw6orb #reply many thanks from canada, 73 good dx #end

The use of the "#qsl" for a cq cq dx meteor scatter shout, then responded with the "#verify" and then to complete the overall contact details for contest points or awards for good efforts, the "#end" is used to end the overall contact turn about.

To add to the packet radio text editor, I have been writing a visual basic terminal emulator program, info how to do this is a bit on the short side on internet, but I found one or two references, thus so have been able to make a data terminal with a inline text editing, just as notepad does in any case. The visual basic "Packet Radio Data Terminal ( text editor )", does not use the "vb notepad app plug in", so I have written my own overall packet radio text editor. With the new version of the Arduino Mega code, not yet published, I have been able to via the Visual basic "Packet Radio Data Terminal" coding, to change the "radio / P.C." modem's baud rate, by selecting from a pull down menu.

By using the remote operation control program for your radio, if say it was a "Icom 7300" or "Icom 7600" or even the Yaesu FT991A, Packet Radio operation can be achieved on all of the bands, HF SSB say 300 or 600 Baud, and VHF or UHF or even 23cm or above, then a higher data rate, all the way up 57600 baud from the slowest of 300 Baud. I myself have used both my Packet Radio Data Terminal and the FT450d remote control program together, that is both program in use on the P.C. monitor screen. This allowed both "radio control" and "packet radio control", both from just the computer.

As both units, the radio and the packet radio modem are fed from the usb port, even through a usb hub, it is just a matter of using the correct "com port" for each unit. In my case, "com port 8" for the packet modem, and "com port 18" for the FT450d, hence thus both units networked together using the each usb port, or usb hub should one be short on usb ports on ones computer.

Where to place in the radio shack the packet radio modem, well I found that a keyboard PS2 patch lead works well for the data audio port on my FT450d. I purchased a 3m length 6 pin mini din cable, and also sourced from amazon chassis mounting 6 pin mini din sockets, so it was a mere trouble to plug in the radio, the packet modem usb connection to the P.C. itself. By the way, I found a data terminal app for also my chromebook, I downloaded and it worked with the packet modem.

Now the packet modem uses the usb 5 volt rail on the usb connection, hence the need for a -5volt generator for the op-amp circuits, to make life easier for the op-amp circuits to function. Point is though, for SOTA working, or field day events, your solid state memory ( ssd ) laptop, would also power the packet modem, and as the modem is best audio transformer isolated, it would be thus a simple connection to the radio, microphone socket or the audio data port at the radio rear panel.

However, do not forget to use an arduino relay module to key the radio transmitter. The combination of audio isolation transformer and the PTT relay, means that the radio and P.C., in the middle the packet modem, are all essentially signal and ground isolated.

Additions to the packet radio text editor, are, just simply first an ascii version of RTTY by using a packeted data message, a beacon mode, a repeater station mode, and also "packet post" posting club messages on packet radio, and "packet mail" to address messages, via packet radio, all using a "peer to peer" connection. The modem put together so far I have been testing TX on HF using SSB, at 300 Baud, on both my FT450d and also a bitx40.

The second listed Arduino mega could also shows an "auto reply" reply idea ( principle ), by using a "#qsl" label at the end of the sent message. The idea is to provide that intended recipient can send an OK message to say that they have received and resolved the message, by replying with a OK message back to where the original message was originated from.

A packet mail address could be ( following the style of the movie "The battle of the river plate " ), packet mail from "Admiralty London", to "Rear Admiral Graham, Royal Navy, South Atlantic".

Not bad.