Please see my SA818 page for information about the radio module itself.

Heres a schematic for one variation of this device.

The board contains a CM108 for audio input/output.

CM108 input signals:

• The SA818 SQ signal is connected to the CM108 VOLDN pin. This is consistent with the usual convention: COS -> VOLDN.

CM108 output signals:

• The SA818 PTT signal is connected to the CM108 GPIO3. This pin is mapped to HID_OR1 in the 0b00000100 bit position. This can only be written when HID_OR0 0b11000000 is set to 0. For reasons that aren’t clear to me (and not consistent with the datasheet), turning on GPI03 requires a 5-byte write { 0, 0, 0x4, 0x4, 0 } and turning it off requires a 5-bute write { 0, 0, 0x04, 0x00, 0 }. The first 0x04 is tbe mask that sets GPI03 as output and the second 0x4 is the “high” signal or the “low” signal.

• An important reference from KC2IRV that talks about synchronization requirements.
• A good intro video on simulcast.
• A video about simulcast systems
• An article that gives some parameters.
• An interesting article that talks about the risks to public safety communications.
• Several case-studies and background

The conventional wisdom states that the baseband signal needs to be synchronized to within 30 degrees of phase across different transmitters. For a 1kHz tone that equates to about 80uS of accuracy.

In my experience, the best way to really understand a technology is to try to implement it yourself. You can read the books, take the classes, and watch the YouTube videos, but there is no substitute for sitting in front of a blank screen and trying to copy something with your own hands. There are 100’s of subtle details lurking below the surface of a system of modest complexity, none of which can be appreciated (let alone understood) by simply watching the highlight reel. Not to mention the AI summary …

A time-honored training method used by artists is called the “Master Copy” in which the aspiring student attempts to reproduce a great masterwork. “Art begets art,” says Daniel Graves, a well-known painter and founder of the Florence Academy of Art, “and nothing is more useful for an art student than to copy a great master painting.” Supposedly Chopin began his piano practice every day with some preludes and fugues from Bach’s 48. I spent two weeks in Maine last summer at the The Wooden Boat School where a bunch of us spent hours a day in a shop trying to accurately reproduce a wooden dory designed by George L. Chaisson, the legendary builder from the North Shore of Massachusetts.

I once had the chance to work with Dragomir Krgin, a famous expert in the field of bond market conventions from Merrill Lynch, or at least as famous as you can get working in such an esoteric field. I would approach Dr. Krgin with a question about some obtuse nuance in the “true yield” calculation used for Italian government bonds and he would refuse to answer my question directly. Instead, he would pull out his yellow pad and derive every answer from first principles (present value is the sum of the discounted future cash-flows). This could take hours, but I came to appreciate how the ease with which he could reinvent the “wheels” in his space allowed him to navigate complicated problem with confidence and authority.

There is something about the process of replicating the work of the great masters that prepares your hands to do great work of your own.

Unified Extensible Firmware Interface (UEFI) is a specification for the firmware architecture of a computing platform. The standard is open but the implementations are generally proprietary.

The actual boot order, which tells the UEFI where to look (e.g., which disk, which partition, which bootloader file), is stored in the motherboard’s Non-Volatile RAM (NVRAM).

ESP

The UEFI ESP (EFI System Partition) is a small, mandatory FAT32 partition on storage drives that holds boot loaders, drivers, and utilities for computers using the Unified Extensible Firmware Interface (UEFI) to start the operating system.

The ESP is a dedicated OS-independent partition, allowing multiple operating systems (like Windows and Linux) to coexist on the same drive, each with its own boot files in the ESP or related locations.

It provides files for UEFI utilities and firmware updates, often mounted at /boot/efi in Linux.

The ESP contains the .efi files that the UEFI firmware executes to start an operating system.

For Debian 12 (Bookworm) UEFI installs, the EFI System Partition (ESP) needs to be FAT32 formatted with a mount point of /boot/efi. While a minimum of 100-300 MB works, 500-1000 MB (1GB) is strongly recommended to comfortably handle multiple kernels, operating systems (dual-boot), and firmware updates without running out of space later, as resizing it can be difficult.

BOOTX64.EFI

Every device that can be booted, has an EFI System Partition (ESP) formatted with the FAT32 filesystem. The UEFI firmware is supposed to, at a minimum look for the file “\EFI\BOOT\BOOTX64.EFI” in every ESP and add that to the boot menu. The UEFI firmware can also maintain other boot menu entries that refer to files in the EFI System Partitions, such as the familiar “\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI”.

The UEFI firmware scans all EFI System Partitions for this specific path if no other boot options are set.

Parition Setup

For new users, personal Debian boxes, home systems, and other single-user setups, a single / partition (plus swap) is probably the easiest, simplest way to go. The recommended partition type is ext4.

With respect to the issue of swap partition size, there are many views. One rule of thumb which works well is to use as much swap as you have system memory. It also shouldn’t be smaller than 512MB, in most cases. Of course, there are exceptions to these rules. For hibernation to work you must have a swap space (partition or file) at least as large as your RAM to save your system’s state.

WYSE 3040 Notes

An article related to the Wyse 3040.

The Wyse 3040 only uses UEFI and doesn’t support a legacy BIOS mode.

This machine has a bug that involves its firmware’s strict requirement to find bootloaders at the standard EFI/BOOT/BOOTX64.EFI fallback path, often failing with non-standard installations like Debian’s default, causing boot failures or blank screens.

Used the LxQt version of the Debian Live distro.

Added “nomodeset” from Grub menu in live install to address a blank screen issue.

Debian Setup of 3040

An 8Gb drive shows up as /dev/mmcblk0 df

• Partition 1: 500MB, ESP
• Partition 2: 7GB, ext4, /
• Partition 3: ~500MB, swap

Selected: “ Force extra installation to the EFI removable media path?”

I’ve been working on putting the Wellesley Amateur Radio Society (W1TKZ) repeater system on AllStarLink using a 4G/LTE cellular hotspot. I’ve never worked much with the mobile carriers so a lot of this is new to me. In particular, the hotspot that I am using (Verizon + Netgear LM1200) provides generally good service, but it has the known limitations of CGNAT on the IPv4 side. Bottom line: it’s not easy to accept inbound connections since (a) you don’t have a static IP address and (b) the port numbers are NATed and (c) there’s a rigid firewall with no concept of “port forwarding rules” like you might have from a commercial or home ISP.

That said, the story on the IPv6 side is much better. I think robust support for IPv6 in AllStarLink is the best way to get away from the limitations of the CGNAT world. With IPv6 there is no translation of addresses or ports - you get “real” internet addresses/ports all the way down to the AllStarLink end-point. My implementation of IAX2 now supports IPv6 and it works well, with some important limitations. I’ll provide a different write-up on that later.

However, the problem isn’t solved. The inflexible firewall still exists and the Verizon 4G/LTE service doesn’t allow ports to be opened from the outside world. For obvious reasons, the carriers designed the mobile network to support clients, not servers. So even now with everything running on IPv6, making a call into the node at our repeater site is still blocked.

All of this reminded me of something from my EchoLink experience. I know people might quarrel with this, but from my perspective the AllStarLink and EchoLink systems are very similar from a technology standpoint. Both essentially borrow concepts/protocols from the VOIP/PBX world and adapt them for ham radio use. Each system has its pros and cons. One of the big pros of EchoLink it its smooth(er) traversal of firewalls. I think the AllStarLink system can borrow a proven technique from EchoLink.

Adapting the EchoLink OPEN/OVER Protocol

If you want to know how the EchoLink system works, my reverse-engineering document may be the most detailed source of information. EchoLink doesn’t enjoy an nice RFC like IAX2, so everything needed to be figured out using Wireshark.

EchoLink has a central server called the “Addressing Server” that plays a similar role to the AllStarLink registration server. One simple feature in the EchoLink Addressing Server makes firewall traversal simpler. I call this feature the “OPEN/OVER protocol”.

Understanding this mechanism requires an understanding of dynamic firewall capabilities known as Stateful Packet Inspection and/or UDP Hole Punching. A full explanation is beyond the scope of this document, but the key thing to understand is: on most “normal” home/cellular internet routers sending a UDP packet to a remote address will automatically grant temporary permission for the return path. This temporary permission is sometimes called a “UDP hole” because it enables a traffic pattern that would not normally be possible. The hole being described here includes (a) a firewall opening to allow return traffic on the same port and (b) the routing entries needed to get the return traffic back to the right place on your LAN. Without this hole, two-way communication would not be possible.

The UDP hole is transient and will only persist as long as the network path is actively being used. Once a path becomes inactive the UDP hole is closed. The lifetime of the hole depends on the carriers and the traffic situation, but it’s safe to assume that the holes will last through 15 seconds of inactivity.

If node 44444 (from port 4569) wants to connect to node 55555 (to port 4569) it will be blocked by the firewall. However, if node 55555 just happens to send a UDP message to node 44444 on the same ports, a temporary opening will be created on node 55555’s firewall for a short time. If node 44444 wants to connect to node 55555 via IAX2 during that window, the packets go through just fine.

So, the “trick” is to ask node 55555 to send a content-free message to node 44444 in advance of receiving a real IAX2 call from node 44444. EchoLink performs this trick by leveraging their addressing server. AllStarLink could do the same thing, something like this:

1. Node 55555 sends an PING to the Registration Server on a regular basis. This has the effect of keeping a UDP hole open on 55555’s firewall to accept packets FROM the Registration Server. The specific port-numbers here don’t matter much, although it would make sense to use a single well-known port on the server side.
2. When node 44444 wants to call node 55555, it first sends an OPEN_REQUEST message to the Registration Server with the IP address/port that it wants to connect to (i.e. 55555’s address/port). Again, the specific ports used don’t matter much.
3. After authentication (likely PKI), the Registration Server uses its open path to 55555 to send an OPEN_REQUEST frame telling it of node 44444’s interest. It should use the same address/port that was used by node 55555 in step 1 to ensure successful delivery.
4. Node 55555 sends a POKE frame directly to node 44444, thus establishing the needed UDP hole. This is an IAX message on the normal IAX port.
5. Finally, node 44444 places the call the usual way, leveraging the open path that was just created by the previous step.
6. The ongoing call keeps the firewalls open in both directions.

To be clear: the Registration Server does not stay in the middle of the call - this is not a proxy mechanism. The Registration Server is just acting as a notification service to help nodes stuck behind restrictive firewalls.

Also, I don’t think the Registration Server would need to perform any real-time database access to support this feature. A public-key encryption mechanism could be used to perform the necessary validations. The Registration Server would need to periodically refresh its cache of the private keys for all nodes on the network. It would also need to keep track of the address and port most recently used for the regular PING (step 1) for each active node on the network.

I’m specifically mentioning the IAX POKE frame type because that message is already in the IAX2 protocol and is designed for this kind of situation. From the RFC:

A POKE message is sent to test connectivity of a remote IAX peer. It is similar to a PING message, except that it MUST be sent when there is no existing call to the remote endpoint. It MAY also be used to “qualify” a user to a remote peer, so that the remote peer can maintain awareness of the state of the user. A POKE MUST have 0 as its destination call number.

Upon receiving a POKE message, the peer MUST respond with a PONG message.

One nice thing about the POKE is that it is processed by Asterisk (a) without needing any authentication and (b) without needing an active call. I’ve tested this on several nodes on the existing network and they all respond with the PONG, as required by the RFC.

This scheme will actually be simpler than that used on EchoLink because AllStarLink only needs one port. EchoLink needs two ports, both of which need to be opened using this handshake.

With this mechanism in place, there should be no reason for special inbound firewall rules. This lowers the friction to adding new nodes on the network.

HID Experiments With an AllScan UCI90

Many thanks to David Gleason for sending me one of these excellent devices. See AllScan.info. This device uses the CM108B chip.

• Schematic for the UCI90
• Datasheet for the CM108B
• See this page for information on Linux USB controls.

My testing was done on a Raspberry Pi 5 using the stock OS. No special drivers we required to use the UCI90.

The CM108B chip allows GPIO pins to be read via USB HID registers. Here’s the code that can read 4 bytes of data out of the box via the HID interface. From the Linux docs “typically, this is used to request the initial states of an input report of a device, before an application listens for normal reports via the regular device read() interface. The format of the buffer issued with this report is identical to that of …“

  char buf[64];
  // Set the report ID
  buf[0] = 0;
  int ret = ioctl(fd, HIDIOCGINPUT(5), buf);
  // The first byte is the report ID, ignore it
  for (unsigned i = 1; i < ret; i++)
      printf("%d %02X\n", i, (unsigned int)buf[i]);

The PTT button on the microphone (connector K1 3.5mm) acts like a COS signal. This is connected to the VOLDN pin (pin 48) on the CM108B. This maps to HID_IR0 bit 1. So if the microphone button is pressed we’ll get this from the ioctl() call:

            0x02,0x00,0x00,0x00

Whenever the GPIO state changes a USB HID interrupt is generated. This can be accessed using a normal read() system call - no ioctl() required. The format of the data is the same - 4 bytes.

The CM108B is a stereo CODEC so the audio data needs to be stereo. That said, we usually only care about one channel. The audio output on the speaker connection of the UCI90 (J2) and the microphone connection (K2 2.5mm) comes from the left channel of the CODEC (pin 30).

The audio input from the microphone connection appears on both channels at the same time.

HID Experiments With USB Audio Box Containing a CM6206

This device is reported as “CM106 like” by the Linux kernel.

• See CM106-F/L datasheet (page 18)
• Or CM6206 datasheet

We are reading/writing /dev/hidraw0 in all cases, using normal Linux open/read/write calls. There is no ioctl necessary with this chip.

Per USB specification, numbers are represented in little-endian format.

Test 1: Press/release mute button on control box. Output:

0x14, 0x00, 0x30 -> 0001 0100, 0000 0000, 0011 0000 0x10, 0x00, 0x30 -> 0001 0000, 0000 0000, 0011 0000

This shows the “mute” bit turning on/off (WORKING!).

Test 2: Press/release volume down button. Output:

0x12, 0x00, 0x30 0x10, 0x00, 0x30

This shows the “VDN” bit turning on/off (WORKING!).

Test 3: Generate a Set Output Report asking for the contents of

register 1.

Send 48, 00, 00, 01. Received 0x30, 0x00, 0x30 -> 0011 0000, 0000 0000, 0011 0000

From datasheet (page 19), this means PLLBINen=1 and SOFTMUTEen=1.

Test 4: Read register 3.

Send 48, 0, 0, 3 Received: 0x30, 0x7F, 0x14

Full register 3 contents: 0001 0100 0111 1111

Notes on Audio Flow Through chan_simpleusb.b

Channel function simpleusb_write() is called when a data frame is received from the network. This function does nothing more than put the frame onto o->txq for later handling.

Channel function simple_read() appears to be called periodically (at the frame rate?) and does a few things:

• (A few steps)
• Takes frames off the transmit queue (o->txq):
  • Applies preemphasis, converts to 48k audio,
  • Sends them to the sound card.
• Reads from the sound card to get as much as possible
  • If there is no audio available then return immediately with a null frame.
• Based on COS/CTCSS status (and transitions) sends control messages AST_CONTROL_RADIO_KEY or AST_CONTROL_RADIO_UNKEY.
• Converts the 48k sound to 8k, makes a frame, deals with HPF, deemphasis, etc.
• DTMF detection: ast_dsp_process(c, o->dsp, f) that appears to return a frame handle if there is any DTMF content in the audio frame.

Linux Audio Interface (USB)

res_usbradio.c looks into this directory:

    /proc/asound/cards

Setting/Getting HID Register:

void ast_radio_hid_set_outputs(struct usb_dev_handle *handle, unsigned char *outputs)
{
	usleep(1500);
	usb_control_msg(handle, 
        // Request Type 
        USB_ENDPOINT_OUT + USB_TYPE_CLASS + USB_RECIP_INTERFACE,
        // Request
        HID_REPORT_SET,
        // Value
        0 + (HID_RT_OUTPUT << 8), 
        // Index
        C108_HID_INTERFACE, 
        // Data
        (char *) outputs, 
        // Length
        4, 
        // Timeout
        5000);
}

void ast_radio_hid_get_inputs(struct usb_dev_handle *handle, unsigned char *inputs)
{
	usleep(1500);
	usb_control_msg(handle, 
        // Request Type 
        USB_ENDPOINT_IN + USB_TYPE_CLASS + USB_RECIP_INTERFACE,
        // Request
        HID_REPORT_GET,
        // Value
        0 + (HID_RT_INPUT << 8), 
        // Index
        C108_HID_INTERFACE, 
        // Data
        (char *) inputs, 
        // Size
        4, 
        5000);
}

int usb_control_msg(struct usb_device * dev, 
    __u8 request, 
    __u8 requesttype, 
    __u16 value, 
    __u16 index, 
    void * data, 
    __u16 size, 
    int timeout);

Get Request Type: 0b1010_0001 (0xA1), request: 0x01, value: 0x0100, index: 0x0003, length: 0x0004 Set Request Type: 0b0010_0001 (0x21), request: 0x09, value: 0x0200 #define C108_HID_INTERFACE 3

Understanding request parameter:

USB_ENDPOINT_OUT + USB_TYPE_CLASS + USB_RECIP_INTERFACE

From libusb docs:

• Bit 7: Data Transfer Direction (0 = Host to Device, 1 = Device to Host)
• Bit 6-5: Type (00 = Standard, 01 = Class, 10 = Vendor, 11 = Reserved)

• Bit 4-0: Recipient (00000 = Device, 00001 = Interface, 00010 = Endpoint, 00011 = Other)

• USB_ENDPOINT_OUT (0x00): A transfer from the host to the device.
• USB_ENDPOINT_IN (0x80): A transfer from the device to the host.
• USB_TYPE_CLASS: corresponds to the value 0x01 « 5 (which is 0x20), meaning the bits 6 and 5 are set to 01. This signifies that the request is a class-specific request.
• USB_RECIP_INTERFACE (0x01): The request is directed at one of the device’s interfaces.

Understanding request parameter:

    HID_REPORT_SET - 0x09 0b0000_1001
    HID_REPORT_GET - 0x01 0b0000_0001

Understanding “value” parameter:

    0 + (HID_RT_OUTPUT << 8), 
    0 + (HID_RT_INPUT << 8), 

Possibly: HID_RT_INPUT = 0x01; HID_RT_OUTPUT = 0x02. So HID_RT_OUTPUT « 8 = 0x0100 and HID_RT_INPUT « 8 = 0x0200?

USB Audio Experiments

Looking in /dev/snd. The naming convention pcmCxDy or controlCxDy indicates the card number (x) and device number (y) for a specific sound card. ”p” for playback, “c” for capture.

References

• CM108 datasheet
• HID specification
• USB Protocol Stuff
• An ALSA HOWTO from >25 years ago
• Another that is more PCM related
• Part 1 of an article about how to build an Asterisk Channel Driver (highly relevant)
• Part 2
• Part 3

Example SIP Message

Here’s an extract of a real SIP message. Note that HTTP format is used. There is a request line, followed by a set of header lines, followed by a blank line, followed by the “body” of the request.

    INVITE sip:61057@192.168.8.102:5060;user=phone SIP/2.0
    Via: SIP/2.0/UDP 192.168.8.225;branch=z9hG4bKa236ad2d25EAA60
    From: "Bruce AllStarLink" <sip:1001@192.168.8.102>;tag=C33436A7-230A9A
    To: <sip:61057@192.168.8.102;user=phone>
    CSeq: 1 INVITE
    Call-ID: 5ad49fee49257106bfba2eceaea5130b
    Contact: <sip:1001@192.168.8.225>
    Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
    User-Agent: PolycomVVX-VVX_410-UA/5.9.5.0614
    Accept-Language: en
    Supported: replaces,100rel
    Allow-Events: conference,talk,hold
    Max-Forwards: 70
    Content-Type: application/sdp
    Content-Length: 352

    v=0
    o=- 1761157361 1761157361 IN IP4 192.168.8.225
    s=Polycom IP Phone
    c=IN IP4 192.168.8.225
    t=0 0
    a=sendrecv
    m=audio 2260 RTP/AVP 9 102 0 8 18 127
    a=rtpmap:9 G722/8000
    a=rtpmap:102 G7221/16000
    a=fmtp:102 bitrate=32000
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=rtpmap:127 telephone-event/8000

SIP Handshake Notes

In this testing I used a properly configured SIP phone (.225) and an Asterisk server (.102). Here’s the sequence, filtered for the SIP traffic.

RTP Port Traversal Examination

In this testing I used a properly configured SIP phone (.225) and an Asterisk server (.102).

Commands used to check firewall:

    sudo firewall-cmd --get-active-zones
    sudo firewall-cmd --zone=public --list-all
    sudo firewall-cmd --zone=allstarlink --list-all

The last command shows that a custom–sip rule had been added, which likely opens port 5060 for inbound connections from the phone.

The AllStarLink documentation has some helpful firewall notes here.

The SIP negotiation happens on UDP port 5060 without any problems.

The final message in the SIP negotiation (OK (INVITE)) assigns UDP port 16314 to the RTP/media. That is a random server-assigned port inside of the expected range of 10,000 to 20,000.

However, that port is normally not open to inbound connections. Notice the ICMP messages being generated in response to the phones RTP messages that tell the phone that its messages are being rejected.

But after a few seconds the server finally sends an RTP packet of its own to the phone on port 16314. This triggers the firewall hole-punch and no more ICMP errors are seen from the firewall.

Authentication Notes

An initial INVITE message from the phone was rejected by the server with a status 401 (Unauthorized). However, this rejection contains this header:

WWW-Authenticate: Digest realm="asterisk",nonce="1761157360/8582866c17ef9e4cfd024254e37cf1e8",opaque="50d273e02ab5c6c3",algorithm=MD5,qop="auth"

The format of this header is dictated by RFC 2617 in section 3.2.1.

Digest authentication is requested using the MD5 algorithm.

The subsequent INVITE message from the phone contained this new header:

Authorization: Digest username="1001", realm="asterisk", nonce="1761157360/8582866c17ef9e4cfd024254e37cf1e8", qop=auth, cnonce="/68T/KlfvEd3p7T", nc=00000001, opaque="50d273e02ab5c6c3", uri="sip:61057@192.168.8.102:5060;user=phone", response="30ffb4415b99d73da5ef3badee2781d1", algorithm=MD5

This particular endpoint was configured (/etc/asterisk/pjsip.conf) with a type=auth, auth_type=userpass, username=1001, password=1001.

The critical part of this header is the response attribute which contains a hash value that allows the client to prove that it knows the password. The definition of how this hash is computed is provided in RFC 2617 in section 3.2.2.

Here’s a short Python script that demonstrates the steps to validate the secret. The request/response match those provided above.

import hashlib
import base64

def MD5(a):
    md5_hash = hashlib.md5()
    md5_hash.update(a.encode("utf-8"))
    return md5_hash.hexdigest()

# Here is the secret that the client has:
password="1001"

# All of this is contained in the client's request (no 
# secrets here):
realm="asterisk"
username="1001"
uri="sip:61057@192.168.8.102:5060;user=phone"
nonce="1761157360/8582866c17ef9e4cfd024254e37cf1e8"
nc="00000001"
cnonce="/68T/KlfvEd3p7T"
qop="auth"
response="30ffb4415b99d73da5ef3badee2781d1"

# Here we are following the steps outline in RFC 2616 section 3.2.2.1.
# Please see https://datatracker.ietf.org/doc/html/rfc2617#section-3.2.2.1

a1 = username + ":" + realm + ":" + password
a2 = "INVITE" + ":" + uri
secret = MD5(a1) + ":" + nonce + ":" + nc + ":" + cnonce + ":" + qop + ":" + MD5(a2)

# Do we match?
assert(MD5(secret) == response)

Python does this automatically. Java uses BigInteger. There are other libraries.

This comes up (among other places) in RSA cryptography where we need to compute things like:

c = (m^e) mod n

With very large (ex: 128-bit) numbers.

Representation Using Multiple Digits

A two-digit representation using base B:

x = x₁B^m + x₀

Addition

The addition to two N-digit numbers will result in (at most) an N+1 digit number.

Multiplication

The multiplication of two N-digit number will result in (at most) a 2N digit number.

Karatsuba is a common efficiency improvement: https://en.wikipedia.org/wiki/Karatsuba_algorithm.

Division

If the goal is to divide Q = N / D, a starting estimate for Q can be made by shifting N and D to the right by S bits. Because Q = (N / s) / (D / s).

But this only works if there is significance in the first S bits of both N and D. So a different algorithm would look at the S most significant bits of N and D, keeping in mind that the amount of the shift might be different for the two numbers.

Modulo

Discussion of multi-precision modulo: https://stackoverflow.com/questions/27057920/large-integer-arithmetic-how-to-implement-modulo

Summary: when computing D mod M you can remove any integer multiple of M from D withing impacting the answer. So keep doing that until D - QM <= M, and then modulo = D - QM. This requires (1) a fast multiply (b) an iterative algorithm and (c) and a way of improving Q.

Another option: Figure out what 1/M is and then multiply it by D to find Q. This might use the Newton-Raphson algorithm.

References

• A GNU Library: https://gmplib.org/
• A good paper: https://www.hvks.com/Numerical/Downloads/HVE%20The%20Math%20behind%20arbitrary%20precision.pdf
• https://people.ece.cornell.edu/land/courses/ece4760/RP2350/arithmetic/index_arithmetic.html

Per the IAX2 RFC 5456 in section 8.6.16, the RSA material exchanged in the authentication process follows the official RSA standard used documented in PKCS#1 V2.0 for RSA (RFC 2437). Note that there are later versions of RSA described (now up to V2.2).

IAX2-Specific Notes

During the AUTHREQ process the server sends a random integer (9-digit string) to the client. The client “RSA signs” the SHA1 hash of this integer using its private key and sends back the resulting signature in the AUTHREP message.

The authentication process in the server involves these steps:

• Hash the random integer using SHA1.
• Decrypt the signature received in the AUTHREP message to get the SHA1 hash that the client received.
• Compare the two to ensure a match.

This is an RSVP1 operation as defined in the PKCS#1 terminology.

Notes on PKCS#1 V2.0 (RFC 2437)

An overview of the PKCS#1 standard is here: https://en.wikipedia.org/wiki/PKCS_1. Basically, this standard defines the terminology and data formats that allow the RSA math to be used in a practical application.

Representation of the Public Key

The public key found in a .PEM file is a base-64 encoding of a complicated structure defined in the standard (specified using ASN.1). Part of the structure has two important fields:

• The RSA modulus n.
• The RSA public exponent e.

The size of the modulus determines the size of the message that will be encrypted.

Encoding the Message: EME-PKCS1-v1_5

“Encoding” here doesn’t mean “encrypting.” The encoding process converts the message bytes (M) into something that can represented as an integer. The most important part is the padding since the encryption wants to work on a fixed block of data.

• M is the original message.
• k is the length of the modulus (n) in octets.
• Message length can be up to k-11 octets. Padding is used to make up for any shortfall.
• The encoded message EM ends up being k-1 octets long.
• The padding process must add at least 8 octets of padding consisting of pseudorandomly generated nonzero octets. The pad is called PS.

• The encoded message will look like this:

    EM = 02 || PS || 00 || M
  

Converting an Encoded Message to an Integer: OS2IP (RFC 2437 section 4.2)

The OS2IP operation interprets a byte string as a big-endian representation of an integer. Each byte in the message is treated as a digit in a base-256 numbering system. The first byte in the message becomes the most significant part of the integer.

Encryption Scheme (RSAES-PKCS1-v1_5)

https://crypto.stackexchange.com/questions/3617/how-do-ciphers-change-plaintext-into-numeric-digits-for-computing

Verification (RSAVP1)

A verification primitive recovers the message representative from the signature representative under the control of the corresponding public key. This is exactly the same as decryption.

This requires Modular Exponentiation: https://en.wikipedia.org/wiki/Modular_exponentiation

References

https://www.practicalnetworking.net/series/cryptography/rsa-example/

https://crypto.stackexchange.com/questions/9896/how-does-rsa-signature-verification-work

I’ve been experimenting with this module. The datasheets are lacking a bit. Here are my notes.

The module has a power range of 3.3 to 5.5V (Vdd). When powered from a +5V supply the logic I/Os including TXD, RXD, PTT, and AFSQ all operate using 3.3V logic. So there is no level-shifting required to communicate with the module from a 3.3V controller.

Audio Input

A 10mVpp signal generator (HiZ) at 1 kHz gives a good tone on a receiver.

FM Deviation Measurement

Here we use the Bessel null method to evaluate the deviation of the module.

Module is keyed with no audio input and the carrier is centered.

Tone magnitude is set to 30mVpp and frequency to 1.5kHz. We see the expected sidebands appear:

Tone frequency is reduced to 1.0kHz. We see the carrier start to diminish relative to the sidebands.

Frequency is adjusted until the carrier is at the noise floor, about 850 Hz:

Since the carrier’s first null will happen with a modulation index of 2.4, we can compute the deviation:

    Δf = deviation_index • modulation_frequency

So the deviation is about 2,040 Hz.

Programming/Commands

Programming Guide

IMPORTANT: The characters that make up a command (including the trailing CR/LF) need to be sent in one batch. There is obviously some kind of internal timeout that generates an error state if there is any delay between characters. So connecting a terminal emulator and typing commands interactively into the module (at human speed) won’t work.

The examples in the programming guide notwithstanding, the frequencies must be specified with 4 digits to the right of the decimal point.

AT+VERSION AT+DMOCONNECT

NOAA receiver

AT+DMOSETGROUP=0,162.4750,162.4750,0000,1,0000 AT+DMOSETGROUP=0,146.5800,146.5800,0000,1,0000

CTCSS tone=88.5 on transmit and receive

AT+DMOSETGROUP=0,146.5800,146.5800,0008,1,0008 AT+DMOSETVOLUME=4

Query for RSSI

RSSI?

A Python CLI For Configuring The Module

https://0x9900.com/programming-the-radio-module-sa818/

Other Notes

There is an annoying lag between the activation of the PTT signal and the beginning of the transmission.