rns.recipes

Any radio hams interested in a project
using HF and vara/ardop as a gateway to send
messages using winlink?

The HF portion of the link would be unencrypted of course and the sender would have to acknowledge this.

So a message would come in over reticulum and be stored (and forwarded when HF allows) via winlink to a similar station.
73
G6PHF

You may be interested in modem73, which is my open source, cross-platform HF/VHF/UHF software modem project designed to work with Reticulum natively https://modem73.app/

All you have to do is run modem73, and drag and drop the modem73interface https://github.com/RFnexus/modem73interface

VARA simply doesn't work with Reticulum due to the messy ARQ and fragmentation built in the modem layer, which is not suited to handle Reticulum traffic. On top of this, it's closed source and paid software that is long past its shelf life. VARA has no CSMA or collision avoidance, and does not handle a channel where there are multiple concurrent users. Which kills the idea of having a Reticulum "net" right out of the gate.

modem73's PHY is fine-tuned for working with Reticulum, with modes that support weak HF propagation conditions to high speed FM line of sight links at 13 kilobits per second all in the same 2400 Hz channel.

Thanks. Sounds interesting I will take a look.
Forgetting about the reticulum side of things for a moment, how does it compare to vara hf for weak signal transmission?

G6PHF wrote:

Thanks. Sounds interesting I will take a look.
Forgetting about the reticulum side of things for a moment, how does it compare to vara hf for weak signal transmission?

While the automatic gear ladder is still a work in progress, the modes start with the non-coherent MFSK family. MFSK-32 (35 byte payload at 63 bits per second) and MFSK-32R (55 byte payload and 99 bits per second) are decodable down to -8 dB and -7 dB respectively. There is also a work in progress MFSK-64 mode. These modes are intended for extremely poor propagation conditions

Moving up the ladder there are the ROBUST modes. These are designed specifically for higher throughput on the HF bands. ROBUST-1200 can survive 1 second fades and is decodable down to +3 dB providing 1150 bits per second of throughput. RDM-800 (781 bps) and RDM-600 ( 585 bps) can both survive 2 seconds of deep fading and are decodable down to +3 dB and +2 dB respectively.

Moving up from there, for more stable channels such as HF links over NVIS, you can use the OFDM modes from BPSK 1/2 normal to QAM16, which provides up to 3200 bits per second and a 1024 byte payload.

When CSMA (collision avoidance) is enabled, there is some slight overhead due to the channel contention window, but this is highly configurable and optional depending on your needs or applications you use modem73 wit,h.

The results have been validated both on-air and in a ITU-R F.1487 Watterson model

Attached below is some data during a test on the 20 meter HF band @ 10 watts of power over a 1780 km link:

It sounds a very interesting project.
But my plan wasn’t to send reticulum over amateur HF bands, as that’s encrypted and not allowed by our licenses. (Daft but true.)
Thanks

Out of interest do you know if anyone’s already built a plaintext/signed application-layer bridge over modem73?

G6PHF wrote:

Out of interest do you know if anyone’s already built a plaintext/signed application-layer bridge over modem73?

Yes, this is possible. modem73 is already compatible with any application that uses KISS framing such as Winlink. You could create a bridge using LXMF bots or a simple link handler in Reticulum. I will see what I can do.

Zenith wrote:

G6PHF wrote:
> Out of interest do you know if anyone’s already built a plaintext/signed application-layer bridge over modem73?

Yes, this is possible. modem73 is already compatible with any application that uses KISS framing such as Winlink. You could create a bridge using LXMF bots or a simple link handler in Reticulum. I will see what I can do.

That would be superb — happy to be a test station if you get something working; I'm in the north of England (IO83) with HF and a small Reticulum mesh already running (LoRa RNodes plus a standalone RTNode).
My use case, for context: an LXMF bot that terminates Reticulum at the gateway and re-originates messages as plaintext, callsign-identified traffic on HF — so encrypted content never touches the amateur bands (a hard constraint under a UK licence). Winlink message format over modem73 P2P seems attractive as the HF leg since the mail tooling already handles queuing and store-and-forward, but I'd equally take a simple signed-plaintext link handler if that's the cleaner path.
One thing I'm curious about from your testing: how does KISS/AX.25-style traffic hold up over a fading NVIS path without ARQ in the modem — is Reticulum's (or pat's) retry logic above the modem enough in practice, or would a bridge want its own light ARQ?
Cheers, and thanks for modem73 — great to see a modem actually designed for shared channels.

is Reticulum's (or pat's) retry logic above the modem enough in practice, or would a bridge want its own light ARQ?

I'm unfamiliar with the exact mechanisms of Winlink, but Reticulum implements retry requests at the API level. Resources handles large transfers which the receiver tracks which parts arrived explicitly and asks for any missing pieces. Channel uses windowed delivery with link layer receipts. Both of these are ARQ in practice and better than handling it in the modem layer as they are integrated directly with the Reticulum API. This works much better in practice.

LXMF the messaging layer also implements retry mechanisms for opportunistic messages and paths, (messages not sent over a lin,k) but the timing is a bit off for slower interfaces, so I recommend sending messages over a direct link instead in clients that have that option.

Thanks — that matches my experience on the LoRa side, and good tip re opportunistic timing on slow interfaces; I'll route via direct links/propagation to the bot.
One clarification on my case though, as it's a slightly unusual one: under a UK licence I can't put Reticulum's encrypted traffic on the amateur bands at all — so on the HF hop itself I can't use Links, Resources or Channel, since those are encrypted by design. My bridge has to terminate Reticulum at each end and send signed plaintext over modem73 between stations. Hence the ARQ question: with Reticulum's mechanisms unavailable on that hop, it's down to AX.25-style retries, Winlink's B2F recovery via pat, or a small ARQ in the bridge itself. If your bridge experiments could keep that constraint in mind (plaintext + Ed25519 signature on air, Reticulum only either side), it'd be directly usable by UK and most EU amateurs — happy to test over an inter-G NVIS path.