Ham Radio / Off-grid communication

[888Flux]

@Juan Números Hey check this out, someone made a Windows build of modem73

https://github.com/SP5LOT/modem73

It seems to be vibecoded, but if it works thats awesome. It looks like it uses Dear Imgui which is what I had thought about writing it with first but had zero experience working with.

 

[888Flux]

these LDMOS driven HF pallet amps are sick

 

[Juan Números]

GOOD MORNING I HATE VARA

@Juan Números Hey check this out, someone made a Windows build of modem73

https://github.com/SP5LOT/modem73

Absolutely based. Seems to work okay but I'll need some more time to do more than a dry run.

Tomasz SP5LOT was actually an early adopter of Ahmet's OFDM modem, using it for his team's stratospheric balloon images.

I'm really glad that more people are coming together to try this promising technology. It's the right combination of experimentation, possibility and pissing off the (VARA) boomers.

POTA bag is almost ready to go, I'll just need some non-shitty cables to run from my shortened (on 40 and 30 m) 1/4 wave antenna to my transceiver (as the shitty cable for the EFHW is too short).

 

[888Flux]

Tomasz SP5LOT was actually an early adopter of Ahmet's OFDM modem, using it for his team's stratospheric balloon images.

Siiiiick

I'm still working on the ARQ layer. There are just a few things I haven't figured out what I want to do with yet. Big update coming soon

---

Good news for my Reticulum niggs, the C++ port and LoRa firmware are now reaching maturity, and there is now a full micropython port for ESP32-S3 and Pi Pico boards.

https://github.com/varna9000/micropython-reticulum

https://github.com/attermann/microReticulum_Firmware

 

[NortelNutworks]

GOOD MORNING I HATE VARA

Same.
If we can get Modem73 to do channel sounding and automatic mode selection, we can give it a run for its' money.

How do I get started with this vibecoding nonsense?

 

[NortelNutworks]

these LDMOS driven HF pallet amps are sick

Have you seen the Mud Duck Sharky videos about these? He did a lot of experimentation and theory of how they work and how to build reliable high-power CB amps out of them, most of which also applies to ham HF.

 

[Juan Números]

Same.
If we can get Modem73 to do channel sounding and automatic mode selection, we can give it a run for its' money.

To be fair, I’m not entirely against VARA. It’s a clever mode and it works quite well. What I don’t like about VARA boils down to all the things that go against the ham radio goal of technical experimentation:

• Not open-source.
• Absolute Windows boomerware.
• Details are opaque at best.
• The creator and dev team really took a page off the lolcows’ book on how to handle criticism.

While I get why civil protection and EmComm community go ham for VARA, I can’t say the same for me. Fucking around and finding out is the real meat and potatoes of ham radio.

 

[888Flux]

channel sounding and automatic mode selection

There's a few things that need a lot of consideration and I just don't know how to do them yet. Maybe some feedback here would be helpful so I'll outline my thinking below. Consider this as an example:

K0BOB wants to send 3500 bytes (28000 bits) of arbitrary data to K1JOE. Both are running modem73 and and the ARQ client. This connection is taking place over the 40 meter band, skywave prop. So we're limited by the HF channel state.

The idea is to have two separate gear ladder tables for HF modes and VHF/UHF+. The upper limit for HF is 8PSK based on real world testing. The gear ladder table looks something like this:

Rung	Modulation	Rate	Payload	Bitrate
tbd	MFSK (4, 8 )	tbd	tbd	tbd
0	BPSK	1/2	256 B	788 bps
1	BPSK	3/4	384 B	1183 bps
2	QPSK	1/2	512 B	1577 bps
3	QPSK	3/4	768 B	2366 bps
4	8PSK	1/2	1024 B	2397 bps
5	8PSK	3/4	1536 B	3596 bps
6	8PSK	5/6	1704 B	3990 bps

Determining which rung to shift to is going to be either based on SNR feedback from ACKs. I'm thinking for every two packets sent, you get one ACK back which contains an SNR between both. That way ACK overhead is only half. If you are sending somethign that fits entirely within the payload you would only need one ACK so that's all gtg.

OR some type of "negotiation" which can be done at every X interval or manually. Basically for that destination (K1JOE) you log the received SNR from them and which rung to use.

The shortest on air time with the current modulation is 1 second, but an ACK is only 70 bytes max. So all ACKs use short framing and BPSK with 1/2 coding as the default.

 

[y a t s]

Determining which rung to shift to is going to be either based on SNR feedback from ACKs. I'm thinking for every two packets sent, you get one ACK back which contains an SNR between both. That way ACK overhead is only half. If you are sending somethign that fits entirely within the payload you would only need one ACK so that's all gtg.

OR some type of "negotiation" which can be done at every X interval or manually. Basically for that destination (K1JOE) you log the received SNR from them and which rung to use.

The negotiation approach sounds good. I wonder about something resembling a NAK that is sent whenever the measured SNR reaches some threshold where it's deemed unacceptable, and that is used as the trigger for a negotiation. That way, you only have to send some sort of SNR feedback when absolutely necessary.

 

[888Flux]

The negotiation approach sounds good. I wonder about something resembling a NAK that is sent whenever the measured SNR reaches some threshold where it's deemed unacceptable, and that is used as the trigger for a negotiation. That way, you only have to send some sort of SNR feedback when absolutely necessary.

It's all an issue of timing and what the best tradeoff is.

If we do NACK's the sender has to stop and wait. Otherwise we might send something the receiver can't decode and waste time on the air.

And another problem is we can't gearshift up /down because the sequence number of the packet is determined based on the phy payload. So in the example above, 3000 bytes fits in to 6 frames if we were on rung 2.

QPSK

1/2

512 B

but if we saw that the ACKs we got back had good SNR and we could go higher, our payload per frame migth become 1024 bytes and now instead of 6 sequences we have 1 or 2.

Some type of byte offset instead of sequence number might work.

I think the simplest solution will just be negotiating between destinations. As some type of user-triggered process or something done after hearing a beacon or at every X interval. Then just log that destination into a table with what rung to use, and when we're transferring data between them use that one.

 

[y a t s]

Some type of byte offset instead of sequence number might work.

I think you're on the right track here.

If we do NACK's the sender has to stop and wait. Otherwise we might send something the receiver can't decode and waste time on the air.

I think using a sliding window like good old ZMODEM does would handle this fine; I could be wrong. Its offset-based approach to packet ordering could help a lot with the sizing issues when shifting, like you mentioned above. With a carefully chosen window size, the overall efficiency gains could decrease your on-air time enough to justify the occasional junk transmission. Though, I say this knowing implementing all of this would be a huge undertaking.

 

[888Flux]

sliding window like good old ZMODEM does would handle this fine;

I like the concept but that requires full-duplex for handling that. We are only half-duplex as we can't listen while we transmit. But maybe the ratio of ACKs per packets can be driven by SNR too.

In the wire for the ACK and packet's instead of sequence it's gonna be byte offset.

HF is very tricky because prop conditions can change over the minute. I plan to implement some MFSK modes using https://github.com/limosky/mFSK which will be slower, but better suited for traditional modes of propagation. Both decoders will just get fed the same audio samples.

So maybe there will actually end up being 3 gear ladder tables, HF, HF skywave, and VHF/UHF (line of sight where channel is stable)

I have a few ideas now and will start wo,rk on it next week.

 

[HairyBadger]

I'm trying to learn the basics. Thanks for the basics on the front page.

What is negotiation?

 

[y a t s]

We are only half-duplex

Ah, there's the catch I figured I must be missing lol.

But maybe the ratio of ACKs per packets can be driven by SNR too.

I like this idea. Then it's just a matter of amortization, which shouldn't be tough to work out.

What is negotiation?

In this context, it's like a handshake:

In telecommunications, a handshake is an automated process of negotiation between two participants (example "Alice and Bob") through the exchange of information that establishes the protocols of a communication link at the start of the communication, before full communication begins. The handshaking process usually takes place in order to establish rules for communication when a computer attempts to communicate with another device. Signals are usually exchanged between two devices to establish a communication link. For example, when a computer communicates with another device such as a modem, the two devices will signal each other that they are switched on and ready to work, as well as to agree to which protocols are being used.

Though, "handshake" to most people implies it's starting at the beginning of the communication, so it can be ambiguous. Here, the negotiation (establishing the rules for communication) could happen in the middle of a transfer (in between packets), as we want to adapt to constantly changing environmental conditions for a more reliable connection.

 

[Blue Miaplacidus]

I kind have gone on an autism obsession, my family has some cheap motorola t470s that we use every day, it also gets noaa alerts. I got tired of missing messages when I had my headset on at my PC so I coded a crude little vox recorder and put a spare shitty mic next to my charging station. Now it auto repeats any broadcasts to a private mumble channel that only I can hear, transcribes the message with whisper and sends me a text notification. It got me wanting to fuck around with an SDR, I saw I could get images straight from the NOAA satellites and a bunch of other "fun" and definitely more interesting projects I could tinker with. I was thinking about getting the cheap RTL-SDR blogv3 kit to start, will the antennae be sufficient or should I spend the extra on something better? I am not buying any fucking RAM or pc parts any time soon so I am looking for more electronics to tinker around with.

 

[r/oldpeoplefacebook]

no one shows up to the kiwifarms bitchat anymore

 

[888Flux]

I kind have gone on an autism obsession, my family has some cheap motorola t470s that we use every day, it also gets noaa alerts. I got tired of missing messages when I had my headset on at my PC so I coded a crude little vox recorder and put a spare shitty mic next to my charging station. Now it auto repeats any broadcasts to a private mumble channel that only I can hear, transcribes the message with whisper and sends me a text notification. It got me wanting to fuck around with an SDR, I saw I could get images straight from the NOAA satellites and a bunch of other "fun" and definitely more interesting projects I could tinker with. I was thinking about getting the cheap RTL-SDR blogv3 kit to start, will the antennae be sufficient or should I spend the extra on something better? I am not buying any fucking RAM or pc parts any time soon so I am looking for more electronics to tinker around with.

Your setup is dope lol. If it werks it werks and Mumble is actually a great way to do jank remote rig stuff on the fly.

I would get the V4, and also the included dipoles should be fine but the NOAA satellites have been decomissioned and you'll want to use the METEOR-M network instead which is in operation until 2040

https://www.a-centauri.com/articoli/meteor-satellite-reception (archive)

Follow this guide above

For decoding NOAA weather radio messages you can look at https://github.com/cuppa-joe/dsame which is a SAME EAS decoder

 

[Blue Miaplacidus]

jank

I even tried (and failed) to print out a little mechanism to press the transmit button. Which is how I ended up down the rabbit hole. Thanks for the information I am definitely going to grab the v4 today. My workshop is in a shitty prefab shed in my back garden so putting the dipoles up on the roof is easily done.

 

[Channel Catfish]

Tried setting up a vertical on a parking garage (going portable), hearing the rebar in the concrete acts as a great ground plane. Personally, results were kinda mixed for me, it looked like my signals were getting pretty far on PSKReporter but actually establishing contact was a different story. I was doing 20-40m with a shorter whip + coil though, so maybe that's just par for the course. Anybody else tried the idea?

I like the concept but that requires full-duplex for handling that. We are only half-duplex as we can't listen while we transmit. But maybe the ratio of ACKs per packets can be driven by SNR too.

In the wire for the ACK and packet's instead of sequence it's gonna be byte offset.

HF is very tricky because prop conditions can change over the minute. I plan to implement some MFSK modes using https://github.com/limosky/mFSK which will be slower, but better suited for traditional modes of propagation. Both decoders will just get fed the same audio samples.

So maybe there will actually end up being 3 gear ladder tables, HF, HF skywave, and VHF/UHF (line of sight where channel is stable)

I have a few ideas now and will start wo,rk on it next week.

I wish I had more technical knowledge to be able to contribute to this discussion effectively. I might be talking out my ass here, but maybe instead of doing explicit SNR reports, you could monitor the error rate from the FEC (for example) over a window of time or a set amount of packets and if it increases or decreases by so-and-so over the previous window or reading, you can move up or down the rungs that way? You could even combine this with the SNR idea. Start with a beginning SNR exchange, monitor error rate over X packets and if it escapes the window, either move rungs based off that or do another SNR exchange and determine the new rung that way. Apologies if I just spoke utter nonsense.

You'd probably want separate rungs for VHF/UHF if you want to take full advantage of the properties of those bands. Noise characteristics and acceptable bandwidth are quite different there and I see no reason (besides simplicity) to not take advantage of that. Now, the question is, how could you handle propagation modes like tropospheric ducting or sporadic E? That's the fun part.

 

[888Flux]

I wish I had more technical knowledge to be able to contribute to this discussion effectively. I might be talking out my ass here, but maybe instead of doing explicit SNR reports, you could monitor the error rate from the FEC (for example) over a window of time or a set amount of packets and if it increases or decreases by so-and-so over the previous window or reading, you can move up or down the rungs that way? You could even combine this with the SNR idea. Start with a beginning SNR exchange, monitor error rate over X packets and if it escapes the window, either move rungs based off that or do another SNR exchange and determine the new rung that way. Apologies if I just spoke utter nonsense.

SNR is too faulty of a metric after testing, and going with bit error rate actually works much better (basically what your suggestio,n was). After the CRC passes you just re-encode all of the data through the polar encoder and measure against the received hard decision bits. I was worried it would be too expensive to do this but it works with very few problems.

BER on the right, SNR on the left. Some loopback testing with AWGN. The SNR is inflated for some reason and I have to figure out why, but BER works better.

ou'd probably want separate rungs for VHF/UHF if you want to take full advantage of the properties of those bands.

Yes for sure, there's going to be HF, HF skywave, and VHF/UHF+ tables. You'll select which one you're using on startup or in the settings.

Aiming for a first test release here very soon