Where to start?

There are other ways to do this.  

Perhaps the cheapest approach would be to just build custom cables to tap the radio AF-in and PTT pins on the Mic port and AF-out from the SP2 port, wire those directly to my computer's aux-out and mic jacks, and use a software modem.  Gain/level control and PTT may require some circuitry in between.  It is also possible to control the radio (PTT, VFO selection, set frequency, etc) over a TTL serial connection provided on the center ring of the SP2 port.

Similarly, a 2-way Bluetooth audio device could be used to relay AF to and from a PC running sound modem software with the BT device selected as the audio input and output device.  This approach lets you eliminate electrical connections to your control computer.  One could design an analog circuit to pull in PTT when audio is streaming from the controlling PC, or devise some other way to toggle PTT wirelessly, potentially over a separate BT device running as a serial port.  

This is what got me thinking about the ESP32 which could serve as a 2-way BT audio device and either decide digitally when to trigger PTT, or provide a telnet terminal which the control software on the PC can use to command PTT.  Plus, there are tons of other things you can do with an ESP32 driving the radio.

This also got me thinking that the ESP32 is plenty powerful enough to handle onboard AF modulation and demodulation, eliminating the need for a software modem on the PC.  Instead, one could implement KISS protocol over Bluetooth serial profile or over 802.11 telnet to control the TNC and send and receive digital packets.  

This is hardly a new idea, it's just new to me.  Other projects use various forms of microcontrollers with a bluetooth serial interface over I2C or similar.  For instance, the  mobilinkd TNC3 and  MicroModem projects, both of which seem to be well supported and well worth the investment.  It turns out Mobilinkd is also actively looking at moving to the ESP32 but hesitated due to bugs in power management in BLE mode which have since been fixed.

I am very tempted to buy the mobilinkd TNC3 but figured I might as well try building something similar since I have some spare Esp32s and miscellaneous components, plus test equipment, and since various parts of the needed code base already exist in various forms for other platforms.  Also, it turns out @Evan has already started porting Mark Qvist's APRS work to the ESP32.  I'll try Evan's LibAPRS branch and go from there.  There are a few other Arduino KISS TNC projects that also look promising, but are targeted for older, slower boards.  Some look easier than others to port to the ESP32.

If all fails, I will likely break down and buy a mobilinkd TNC3 or wait for an ESP32-based version.

Some thoughts about interfaces:

• Strong desire to handle up to 9600 baud on VHF.
  • (9600 not possible without access to radio modulator)
    • perhaps I can add this later if people with compatible radios show interest
  • Priority:  AFSK 1200 bd
  • maybe BPSK 1200 Bd, BPSK 2400 Bd, QPSK 2400 bps, QPSK 3600 bps?
  • other modes via soundcard modem, with ESP32 as audio relay
• Ideally, the device should also support HF as well, at lower baud.
  • ...in case I get an HF or tri-band rig later, or for other users
  • Priority:  HF Packet, 1200 baud
  • other modes via soundcard modem, with ESP32 as audio relay
  • Support APRS (should be easy since open source libraries are available)
    • i.g. @Evan 's ESP32 TNC project which ports Mark Qvist's APRS libraries to ESP32
• 5 4 ways to transfer data between PC and modem:
  • AF relay mode:  audio to/from PC software modem, 
    • over Bluetooth (A2DP 2-way?) (deprioritized)
    • over 802.11 (UDP if TCP not practical)
  • KISS over bluetooth low energy (BLE) serial profile, or 
  • KISS over 802.11 TCP
  • KISS over USB serial port
• Wifi (802.11 b/g/n):
  • Initially will hardcode my home network SSID and password.  Later, will implement a generalized wifi config method similar to most IoT devices, so the modem will default as its own AP but will provide html interface to configure it for any network.
  • Will provide telnet port to allow terminal computer to configure the radio and send and receive digital data over wifi instead of USB or BT serial.
  • Will serve an HTML modem and radio configuration page
  • Will provide HTTP REST server for modem and radio config.
    • Maybe also use this to send and recieve text messages.  Interesting...
• Use the ID-5100 TTL serial port to control VFO selection, squelch, frequency, etc.
  • Will probably manually code this.  Hamlib looks too heavy.
  • Not easily adaptable to other radios.  The modem will still work but operator has to manually configure the radio.
• Support HTs
• Physical interfaces:
• Tx "arm" switch?  Breaks ESP32-radio PTT and tx AF links
• Use screw terminals for users to manually adapt any hacked-up cables
  • i.g. cut-up ethernet cable and 3.5mm stereo audio cable for Icom, and a cut-up Baofeng headset for Baofeng HTs (and many others with same interface).
• Need onboard regulator to allow variety of power sources (ideally sourced by the radio where possible)

----

AX.25/KISS:

AX.25:  http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf
Good overview:  http://www.ax25.net/kiss.aspx

The AX.25 protocol is removed entirely from the TNC, as are all command interpreters and the like. The TNC simply converts between synchronous HDLC, spoken on the full- or half-duplex radio channel, and a special asynchronous, full duplex frame format spoken on the host/TNC link. Every frame received on the HDLC link is passed intact to the host once it has been translated to the asynchronous format; likewise, asynchronous frames from the host are transmitted on the radio channel once they have been converted to HDLC format.

HDLC:  https://en.wikipedia.org/wiki/High-Level_Data_Link_Control

HDLC frame:
  • Flag (8 bits: b01111110, 0x7E)
  • Address (8+ bits)
  • Control (8 or 16 bits)
  • Information (variable, 8xn bits)
  • Frame Check Sequence (16-bit CRC-CCITT or a 32-bit CRC-32 computed over the Address, Control, and Information fields)
  • Flag (8 bits: b01111110, 0x7E)

If the receiver's calculation of the FCS does not match that of the sender's, indicating that the frame contains errors, the receiver can either send a negative acknowledge packet to the sender, or send nothing. After either receiving a negative acknowledge packet or timing out waiting for a positive acknowledge packet, the sender can retransmit the failed frame.

The FCS field of an AX.25 frame is sent most-significant bit first. All other fields are sent with each octet’s least-significant bit first. 

There are three general types of AX.25 frames:
  • Information frame (I frame)
  • Supervisory frame (S frame)
  • Unnumbered frame (U frame) 

Modulation:

Good summary about modulation techniques used with KISS/AX.25:  https://destevez.net/2016/06/kiss-hdlc-ax-25-and-friends/

[AFSK] is normally used for a rate of 300 baud on the HF bands. The NRZ-I bits are transmitted as an audio signal which frequency shifts between two tones spaced 200Hz apart. The radio is set to SSB mode, so the actual emission is really FSK. The particular tones that are used are not standard, so this has to be compensated by setting the radio dial frequency correctly. It is not important whether LSB or USB mode is used, because the signal is not sensitive to polarity inversion.

The second way to do it is using FM AFSK. This is normally used for a rate of 1200 baud on the VHF and UHF bands. The NZR-I bits are transmitted as an audio signal which frequency shifts between the tones 1200Hz and 2200Hz. This audio signal is FM modulated before transmission.

The third way to do it is using G3RUH FSK [requires direct access to radio modulator].

The fourth way to do it is using BPSK. This is used in a few amateur satellites, using a rate of 1000 or 1200 baud. The NRZ-I bits are transmitted as a BPSK signal (differential encoding is not used). This BPSK signal can be generated as an audio signal on a computer and then used to drive an SSB transmitter.

Finally, fldigi can act as a KISS TNC, allowing to send AX.25 frames in many of the modes supported by this program. However, these digital modes are normally used for text based chat and rarely used for AX.25.

gr-kiss includes example flowgraphs showing how the 1k2 FM AFSK, 9k6 FSK and 1k2 BPSK modulations work.

=>  1200 baud AFSK for VHF/UHF, with tones at 1200Hz and 220Hz.
=>  300 baud FSK on HF SSB (LSB or USB) with 200Hz tone separation.
=>  FLdigi with ESP32 as BT audio relay

Another good summary:  http://www.symek.com/g/pacmod.html

Other modulation methods:
ARDOP P2P HF (use ESP32 as BT audio relay)
FLdigi NBEMS (use ESP32 as BT audio relay)
WinMOR on HF (use ESP32 as BT audio relay)
PACTOR requies proprietary modem >:-(
PSK31 for HF?  No error correction, not recommended for EMCOMM

FLdigi/NBEMS intro:  http://www.arrl.org/files/file/On%20the%20Air/Tutorials/Introduction_to_NBEMS_ARRL.pdf

Fascinating:  https://github.com/daniestevez/gr-satellites

ESP32:
power management tips:  https://www.savjee.be/2019/12/esp32-tips-to-increase-battery-life/

VARA:
main page:  https://rosmodem.wordpress.com/
VARA quick guide:  https://mega.nz/download
=> implement as AF pass-through, driven by PC app

ID-5100a:
Icom ID-5100a service manual:  https://www.iu2frl.it/wp-content/uploads/2019/02/id5100e-service-manual.pdf 

8V regulator:  NJM2835DL1, 500mA max  https://www.njr.com/semicon/PDF/NJM2835_E.pdf
Full manual:  https://www.icomamerica.com/en/downloads/DownloadDocument.aspx?Document=671
SP2 pinout:  tip RXD, Ring: TXD, Sleeve: GND
Serial interface:  4800/9600/19200, Data: 8 bit, Parity: none, Stop: 1 bit, Flow control:Xon/Xoff
Get CI-V address and set baud rate via CI-V menu
Default address:  0x8C
Maybe can also configure Data port as serial?  Pg 12-10; "Data Device Set -> Serialport Function:  CI-V"
Data format on pg 13-16 and Cmd Table on pg 13-17