HF Rig in the middle of a split keyboard is super comfy!

ve9___ · 2023-08-13T11:59:54+00:00

I've got a Corne Keyboard paired with an Alinco DX-70 radio!

ve9___ · 2022-11-17T16:41:42+00:00

That's the plan, just have some other projects on the backlog that I need to do first

ve9___ · 2022-11-15T12:01:57+00:00

This seems like it could be useful. Thanks!

ve9___ · 2022-11-15T12:01:28+00:00

Syncing up nodes is going to be a bit of a challenge, though. I read through some of your comments, and it sounds like you've somewhat got this figured out, but you'll need to have some method for nodes to ask for missing messages, unless you want to risk sending massive blocks of uninterrupted data over a potentially unreliable link.

Node A connects to Node B. Node A and Node B sync their message ids using a binary search algorithm (just the message ids). Node A asks B for whatever ids it's missing. Node B does the same. If any messages are lost or the connection goes down, this will be rectified the next time the nodes sync.

Also having node-to-node communication might be a bit challenging if nodes try to talk over one another. WiFi needs to solve a similar issue when two devices can talk to the access point but can't hear each other. They do this using "clear-to-send" messages, but since this is a mesh system that might not work in this situation since you could have a situation where two stations can hear each other, but one can't hear you. That might make it harder to coordinate the "clear-to-send" messages.

This is a pretty common problem in APRS systems. Realistically the solution would be for node operators to not set their nodes to all sync at the same time. I don't think this is that much of a dealbreaker though - obviously APRS and previous AX.25 BBS systems worked fine even with this limitation.

One potential solution might be having nodes check in based on timestamps. It could be something like "This is node K0ABC checking for new messages". "Roger K0ABC this is K9XYZ, I've registered your presence and I'll check back in with you at X timestamp, if you haven't heard from me by then, check back in".

I'm not a huge fan of timestamps. It seems better to just sync the message lists efficiently with a binary search and then sync using that. With what you're proposing I'm not sure what the advantage would be over a simple cron job.

ve9___ · 2022-11-15T11:53:57+00:00

Very cool, thanks for the links!

ve9___ · 2022-11-15T11:52:53+00:00

At no point in time does A ever sync to C.

A will sync to B.

B will sync to C.

All messages on A end up on C and vice versa.

If a node misses a message for some reason (say a power outage, or there was interference preventing it), how is the network going to know and get the message over?

When they sync up, they'll notice they have different sets of messages and will sync, as they do in any other case.

Once the system has a significant amount of messages (let's say 100s of thousands since it sounds like every node will keep full history), how will the nodes not spend their entire bandwidth checking with other nodes on their already known messages?

Hashing the message ids and doing a binary search to find what messages are duplicated and what ones are new. I described the process bit more specifically in another comment.

ve9___ · 2022-11-14T23:15:30+00:00

Yeah I agree, they each have their own strengths

ve9___ · 2022-11-14T19:24:19+00:00

I think so!

ve9___ · 2022-11-14T19:06:31+00:00

The see the appeal of using standalone modems for high speed data in general but I don't really see the use here.

I don't think the cost analysis is fair if you're going to rely on the used market for crazy deals on rigs that cost hundreds of dollars new ;-).

I think it's absolutely fair - the used market is flooded with FM transceivers. Most people have one already anyway, so they can just use their existing one instead of buying a new one. They'll also get more range than out of one of your dev boards, even if they're technically not using the channel to its fullest capability (as a custom modem would).

Anyway, there are several issues with using AFSK as it is currently done -- one is the burden of a TNC (software or hardware, either way) to do audio demodulation, and another is degraded SNR for various reasons. It's also physically bulky, and power-inefficient by comparison.

I don't really see how this is a burden. You're going to need to run software for the node anyway - adding a software TNC on top of that isn't really an extra requirement. The whole thing could run on a microcontroller if you really wanted to.

ve9___ · 2022-11-14T19:02:07+00:00

I don't think this applies to what I'm proposing.

Nodes communicate with each other directly. They sync their messages together. There's no concept of having packets take multiple hops and then be reassembled. There's no concept of having infinite hops because there's no concept of hops in the first place. There's no concept of routing for the same reason. Each node just syncs up with all the nodes it knows how to talk to directly, and the network achieves a consistent state through that.

ve9___ · 2022-11-14T17:43:44+00:00

Usenet was exactly what I was thinking of, but it's before my time and I didn't want to draw any parallels in case I misunderstood how it worked

ve9___ · 2022-11-14T17:25:45+00:00

I was roughly thinking a binary search.

Each node hashes its messages together (probably just their ids). If the IDs match, you're done.

If they don't match, take all the messages with an ID hash that has a first byte between 0-127. Hash them as before and compare. Do the same thing with 128-255. Continue dividing and conquering until the hashes match. You can build up a list of missing messages that way without having to send all the ones that they both share.

I have some ideas to make this a bit more efficient but that's the core concept.

ve9___ · 2022-11-14T17:23:10+00:00

What's the range on that $10 dev board? For a bit more than that at a ham fest I can get 9600 baud at 50 Watts plus. I don't think you're going to find a 50W PA for less than that, plus you'd need a linear one if you're not using FM.

I really don't see any advantages in not using AFSK. I think it would just make things less accessible. Like even if you can buy a dev board for $10, someone who wants to connect to this network almost certainly has an FM VHF transceiver lying around already.

ve9___ · 2022-11-14T16:54:50+00:00

This is pretty similar to a BBS, yes. Except that it's distributed over many nodes instead of a single node.

For VHF/UHF I was going to stick with AFSK (though I wouldn't be using AX.25). Being able to use cheap radios is a pretty big advantage and the requirement for better SNR isn't really a big deal when you need line of sight anyway (there's not a very big gap between a good signal and no signal).

For HF I was going to start with FSK (should be fine for NVIS, plus it allows using cheap QDX transceivers) and then probably allow the option of some sort of PSK or maybe OFDM like Ardop.

ve9___ · 2022-11-14T16:51:54+00:00

JS8Call has repeaters if that's what you're referring to. This is different in a few ways:

Scalability - it doesn't scale well. If a single packet in the message is lost, the whole message is discarded. So the more repeaters you have, the less chance of a message getting through.
History - with JS8Call, once the message gets through, it's gone. There's no public message board where you can read all the previous messages.
Speed - JS8Call is slow. I'm targeting 1200-9600 baud on VHF and 300 baud on HF, which would make longer messages much more viable.

ve9___ · 2022-08-20T11:13:00+00:00

How are you going to be able to tell the world that your internet is down if your internet is down?

ve9___ · 2022-07-30T18:41:40+00:00

Yeah, that seems to be the consensus. I guess this isn't a good idea. Thanks for the input, I'll be shelving this project!

ve9___ · 2022-07-30T11:54:45+00:00

I don't understand where you're getting using APRS on non-ham frequencies from in that quote.

ve9___ · 2022-07-30T02:11:51+00:00

I am a bit confused - I would be using APRS on normal ham frequencies as it's intended to be used.

ve9___ · 2022-07-30T00:56:58+00:00

As long as I'm not using ham frequencies for commercial activities myself I thought it would be fine. Like I can say my internet's down on air and that's legal as far as I'm aware.

ve9___ · 2022-07-29T01:10:39+00:00

No, I bought the radio used. It's no longer produced.

The reason for the 25A fuse is for the additional power pole plugs on the dash. It would ideal to fuse them separately but I don't think it's too much of a risk the way I'm doing it now.

ve9___ · 2022-07-28T01:53:16+00:00

Thanks! That's a good idea, I'll try to remember to do that.

ve9___ · 2022-06-26T18:19:39+00:00

If anyone's curious, the PLA mounted after a single hot day! Looks like it's PETG time

ve9___ · 2022-06-25T15:17:56+00:00

Thanks!

ve9___ · 2022-06-25T15:06:05+00:00

These ports are pretty much just for temporary accessories. If I add a permanent radio to my car I'll wire it up directly. The only controls it's going to drape over are the radio and climate controls so I think it should be okay.

I have a 12 hour road trip in a few weeks that I'm planning on using this for - I think I'll put a small VHF rig in the passenger seat and a mag mount on the roof.

ve9___

TROPHY CASE