rns.recipes

Greetings from the Tahanea atoll in French Polynesia!

We're two programmers long-term cruising with a small (<10m sailboat). On a trip like this there are often times when we're held by the weather, and those are good opportunities to work on our open source projects (NoFlo, various Signal K plugins).

The boat is powered by renewables (mostly solar, occasional help from a deployable wind or hydrogenerator). With that we need to conserve energy and can't (and won't) run Starlink all the time. Back in Europe we could fall back to an LTE uplink but here in deserted islands that is not an option.

This makes the distributed development model as described by Reticulum manual a great fit for us.

I have currently two rngit repository servers up: one running on the onboard Raspberry Pi NAS, and another on an online VPS (adafb3153efd4d96d532568a5208b3b5), set to mirror the repos from the boat.

Idea is that we can locally work with the boat-hosted repos, including managing work documents and making releases. When the boat happens to be connected to the internet, our VPS pulls the latest changes so they're available to others.

This works well, except for the fact that Work Documents (and Releases) are not mirrored. The manual states that Release mirroring is planned, and so my question is whether it's better to wait or to set up some temporary way to move the msgpack files over.

If we do so, is there anything to keep in mind except to place the files in the right directories? Copying could maybe be done over rncp, though we also do have Syncthing set up on both machines.

rngit is currently our only use of Reticulum. For messaging and alerting purposes in these off-grid places we are using Meshtastic, where we have a relatively extensive setup as documented here:
https://blog.noforeignland.com/off-grid-boat-communications-with-meshtastic/

Right now plan is to switch this setup also over to Reticulum RNodes, maybe around November when we're settling in for the cyclone season.

out of curiosity cause this is a really interesting usecase, are you guys also using rngit to distribute between Raspberry Pi and your own personal devices like laptops when programming, and what interfaces are you using to connect them if so.

sorry I don't have anything to say about working with rngit, but I will say that having rncp as a backup makes sense anyways because rngit is still new and having to make a bug report at sea would suck

welo wrote:

out of curiosity cause this is a really interesting usecase, are you guys also using rngit to distribute between Raspberry Pi and your own personal devices like laptops when programming, and what interfaces are you using to connect them if so.

Development happens on personal laptops and on smartphones with Termux (rngit, rnsd etc run quite nicely there!). Right now only TCP interfaces over internet or just the boat WiFi. We have a stack of LoRa devices, and do carry Seeed T-1000e cards always with us, but right now all of those run the Meshtastic firmware.

There are two things we need to happen to be able to go fully Reticulum:

Columba still needs to mature a bit. Though it isn't far! And preferably it'd be in an app store (Play, or even better F-Droid).

The Meshtastic integration we have with our boat systems is critical. We control digital switching over it ("turn decklight on") and get alerts ("anchor is dragging"). I'm planning to port the signalk-meshtastic plugin to Reticulum and LXMF, but first I need to sit down and get rns.js to a workable state. Signal K plugins need to run on Node.js.

I can see being able to push changes to our rngit repo from the beach over LoRa in the future....

Interesting, on Android you can perhaps replace Columba with this app: https://github.com/thatSFguy/reticulum-mobile-app or eventually Ratspeak (https://github.com/ratspeak/Ratspeak). I found them both better and less batter-hunger than Columba.

bergie wrote:

welo wrote:

out of curiosity cause this is a really interesting usecase, are you guys also using rngit to distribute between Raspberry Pi and your own personal devices like laptops when programming, and what interfaces are you using to connect them if so.

Development happens on personal laptops and on smartphones with Termux (rngit, rnsd etc run quite nicely there!). Right now only TCP interfaces over internet or just the boat WiFi. We have a stack of LoRa devices, and do carry Seeed T-1000e cards always with us, but right now all of those run the Meshtastic firmware.

There are two things we need to happen to be able to go fully Reticulum:

Columba still needs to mature a bit. Though it isn't far! And preferably it'd be in an app store (Play, or even better F-Droid).

The Meshtastic integration we have with our boat systems is critical. We control digital switching over it ("turn decklight on") and get alerts ("anchor is dragging"). I'm planning to port the signalk-meshtastic plugin to Reticulum and LXMF, but first I need to sit down and get rns.js to a workable state. Signal K plugins need to run on Node.js.

I can see being able to push changes to our rngit repo from the beach over LoRa in the future....

Sideband has a telemetry feature with a very simple to develop on plugin system. It might be exactly what you are looking for
https://github.com/markqvist/sideband

p1ld7a wrote:

Interesting, on Android you can perhaps replace Columba with this app: https://github.com/thatSFguy/reticulum-mobile-app or eventually Ratspeak (https://github.com/ratspeak/Ratspeak). I found them both better and less batter-hunger than Columba.

I haven't encountered any battery issues with Columba, and the power drain issues with Sideband have been fixed for awhile. Running on my old A10e.

https://github.com/markqvist/Sideband/tree/main/docs/example_plugins

Thanks Zenith :) I was about to mention that, but you beat me to it!

Sideband is really quite good for that kind of stuff. I use it for everything from monitoring servers, controlling remote relays and devices, monitoring solar power production and battery storage systems, controlling stuff in Home Assistant to viewing remote security cams and getting news.

On Linux, you can run it in headless daemon mode, which is quite lightweight, and runs fine even on small SBCs like the Pi Zero. You don't have to install it with all the UI dependencies (or you can just use the AppImage).

Sounds like an amazing setup you have with the boat there :) At some point, I'm sure I'll get to release and workdoc mirroring/syncing as well. For now, you can most likely make it work by simply syncing the auxillary files over by any means that will work.

Mark wrote:

Sideband is really quite good for that kind of stuff. I use it for everything from monitoring servers, controlling remote relays and devices, monitoring solar power production and battery storage systems, controlling stuff in Home Assistant to viewing remote security cams and getting news.

That sounds very close to the use case we have with monitoring the boat. Now we get telemetry via Meshtastic using their somewhat limited telemetry schema. Meshtastic is transitioning from a push model to a pull model on telemetry, but for now our boat still transmits every 10min.

I have to admit I'm a little confused on how the telemetry functionality in LXMF is supposed to be used. There's mentions of telemetry collectors and such, but not a lot of examples. I was planning to post a question on that here once I get a bit further (now rns.js crashes when it receives an LXMF message, so there's some basic shoveling to be done before I can start integration).

In addition to text commands, I've been thinking an authenticated NomadNet interface might be interesting to see status of things and to control stuff like digital switching.

Sounds like an amazing setup you have with the boat there :) At some point, I'm sure I'll get to release and workdoc mirroring/syncing as well. For now, you can most likely make it work by simply syncing the auxillary files over by any means that will work.

Thanks! And thanks a lot for writing the Distributed Development chapter, that got some gears rolling on my head. If things work out (and there are enough rainy days to code), I might release some tooling related to that and NoFlo.

Offline-first is really the only way that works in situation like ours. And centralized providers like GitHub are proving to be quite problematic.

For copying work documents, I guess I'll do the following:

• On our NAS we have a systemd timer to periodically make a tarball of the work docs
• The VPS periodically pulls the latest tarball over rncp, unpack, and puts the files in the right places

This is obviously one-way sync, so proposed work docs from third parties aren't possible. But it would be a start. And right now there are no interested third parties anyway.

I will additionally note that it is possible to push reticulum traffic through meshtastic if you happen to have meshtastic infrastructure either internally or externally that you cannot replace. There is some overhead but it's not terrible.

welo wrote:

I will additionally note that it is possible to push reticulum traffic through meshtastic if you happen to have meshtastic infrastructure either internally or externally that you cannot replace. There is some overhead but it's not terrible.

Oh, that is certainly interesting! We have a good set of Meshtastic infrastructure now, including a well-situated solar-powered repeater on the mast. Intention is to keep some Meshtastic still around even when we switch to Reticulum - at least the boat node and the repeater. Reticulum LoRa will get its own transport node on the other spreader.

It is a shame Meshtastic allows only one connection to a device at a time, so one will need to stop the Meshtastic app to use this transport. I've been thinking it would be possible to write a multiplexer, but maybe that effort is better spent elsewhere.

In any case, this would allow some experimentation with Reticulum-over-LoRa before we have the actual RNode infrastructure up.

If we go discoverable on the Meshtastic interface, would it show up on the maps?

Which reminds me, the discoverable interfaces spec has fixed lat and lon to be set in the rnsd config. That obviously isn't ideal for migratory Reticulum instances like ours. It might be nice if Reticulum supported a shell script to get current location like it does for IP in reachable_on.

If we go discoverable on the Meshtastic interface, would it show up on the maps?

There's no technical reason why not, I think the implementations does send an announcement but also currently public maps just don't show it though I may be wrong there.

bergie wrote:

• On our NAS we have a systemd timer to periodically make a tarball of the work docs
• The VPS periodically pulls the latest tarball over rncp, unpack, and puts the files in the right places

Ok, this setup works. Now we have what's essentially a read-only copy of the work documents on the VPS. And as nice bonus, this setup uses only Reticulum for networking.

I suppose with Syncthing we could have had bidirectional sync.

cool! sounds like 100R, huge fan

Welo, you shouldn't just give random advice on things you know nothing about. I've seen this several times now, where you'll just yabber something off that's pulled straight out of a hat and on a whim. You've provided a lot of bad advice in aggregate. Friendly reminder: Know, don't pretend you know.

Using Reticulum over Meshtastic is a bad idea. MT is not at all designed for actual networking, things will fall apart horribly quickly, and due to MT's nature, will waste insane amounts of spectrum airtime - it doesn't even have proper listen-before-talk, for crying out loud. You may be able to get a few simple packets or announces through, but other than that, it'll be a complete packet collision and fragmentation mess.

And no, you can't make a meshtastic interface discoverable.

Awesome to hear things are working out @bergie! Dreaming of someday living on a sailboat as well :)

Mark wrote:

Awesome to hear things are working out @bergie! Dreaming of someday living on a sailboat as well :)

Lots of nice boats available in Sweden and neighboring areas! And lovely cruising ground too, though only for the warm half of the year (I suppose Swedish west coast is semi-sailable all year around?)

Things are indeed working quite well, even making some progress on the JavaScript library we need for connecting Reticulum with our boat systems. Yesterday I was able to get LXMF messages going in both directions between nomadnet and Node.js.

Did you see my comment on more dynamic lat and lon in discoverable interfaces above? That would be great for more nomadistic Reticulum setups like ours. If you think the idea is viable, I could try to contribute the implementation.

Yeah, I did see that actually, and then apparently promptly forgot about it again, caus I didn't think of it until you reminded me ;)

It's a good idea, I've added it. It's in the latest commits on the master branch on Aleph, if you want to try it out already. It'll be included in the next release.

Yeah, I'm kinda half-looking at boats for sale every now and then, but with the budget I have available, I'll probably have to count on getting something that'll require a lot of work. Then again, they always do, don't they?

Mark wrote:

It's a good idea, I've added it. It's in the latest commits on the master branch on Aleph, if you want to try it out already. It'll be included in the next release.

Perfect, thank you! We're about to head offshore, but I'll give it a spin when we're anchored. I already prepared a script to get the lat,lon,alt from Signal K. I can share that if you want an example for the docs.

Another little thing: we were testing various rngit Work Document workflows yesterday, and ran into a bug. The activate command only looks into the completed folder, so there is no way to activate proposed work documents.

Yeah, I'm kinda half-looking at boats for sale every now and then, but with the budget I have available, I'll probably have to count on getting something that'll require a lot of work. Then again, they always do, don't they?

They do, the old joke about boat repair in exotic locations is at least halfway true. You have to be not only your own network engineer, but also the plumber and electrician.

I'd say right now the best bang for the buck is in 70s/80s "good old boats" (lots of good Najads, HRs, Malös etc out there). One that is structurally sound but has outdated tech is ideal, as then you can rip it all out and set up a nice modern setup with LiFePO4, Signal K, plenty of solar, etc.

Electric galleys (and even propulsion!) are also starting to become realistic nowadays, even with renewables.

Great to see other sailors adopting Reticulum! I've been daydreaming about creating a LoRa Reticulum mesh between sailboats (pretty good LOS from masthead to masthead) and of course from my sailboat to the shore. Haven't started on that project yet, very cool to see what you're doing :)

+1 on used boats from the 70s/80s in Scandinavia. They've been dirt cheap for years here in Norway, and even though the market has been vacuumed by bargain hunting foreigners there are still some good finds to be made. There was a really nice Storfidra (25 feet bluewater cruiser that has crossed oceans, built as a tank, with standing headroom, great as a liveaboard for one) that was sold for $1500/€1300 recently (with faulty engine, but I see that as an opportunity).

Plenty of people live aboard sailboats in southern Norway and Sweden. It's much cheaper than living on land but it sure isn't for everyone, especially during our winters. And while a sailboat may be cheap to buy, it is not cheap to keep, they do take a lot of time and elbow grease to maintain in good shape.

My boat, a 25' wooden gaff cutter, actually had electric propulsion when I bought it. Range anxiety is an issue, but LiFePO4 prices are coming down so you could get 5 hours out of a new battery bank for a reasonable amount of money. Still, I'd treat it as something to get in and out of harbour, it's not a full replacement for a diesel engine. IMO, not having a diesel engine forces you to become a better sailor by not always relying on one. A diesel engine will fail on you when you need it the most anyway. Electric motors are at least much more reliable, and it is possible to extend the range with a small gasoline generator like the Honda EU2200i (but that sort of defeats the purpose).

Mark wrote:

due to MT's nature, will waste insane amounts of spectrum airtime - it doesn't even have proper listen-before-talk, for crying out loud. You may be able to get a few simple packets or announces through, but other than that, it'll be a complete packet collision and fragmentation mess.

Just coming into this cold, but that didn't ring true to me. RadioLibInterface.cpp and RadioInterface.cpp cover this via RadioLib's scanChannel(). So...

bergie wrote:

Mark wrote:

It's a good idea, I've added it. It's in the latest commits on the master branch on Aleph, if you want to try it out already. It'll be included in the next release.

Perfect, thank you! We're about to head offshore, but I'll give it a spin when we're anchored. I already prepared a script to get the lat,lon,alt from Signal K. I can share that if you want an example for the docs.

Just wanted to note that this seems to work fine. Our boat RNode is now visible on the map on this site (as well as in Columba).

Here's the script in case anybody else wants to get their dynamic interface discovery location from Signal K:
https://gist.github.com/bergie/b075768c4ec7eb519bdcd8c3e1b7bca9