These work across the house, but of course I’m talking to myself so it isn’t very exciting yet.

@requiem I suppose we’ll have to string a line of solar-powered nodes between our abodes, so that we can chat in an impractical fashion.

I’m also planning to try these for “marine” applications — with a larger antenna, on a small sailboat. They aren’t terribly long ranges, but should do better on open water. (LoRa says it can do “more than 10km.”)

These aren’t suited for saltwater spray being exposed devboards. I’ll work on a waterproof case with an antenna connector pass-through.

I’m also looking more at but no promises that I can recreate the LoRa code and and/or meshtastic protocols on top of Forth.

@mathiasx id like to learn more 😁

I have a design for solar-powered mesh WiFi birdhouses that could probably be easily adapted to this 😁

@requiem this has an esp32 but I have heard that the Nordic chips are even better for low-power (solar-powered) run time.

@requiem the other thing to overcome is that there’s meshtastic and (older) protocol, and then any number of IoT things running LoRa at a base level. Multiple protocol support in firmware and a client app seems ideal, but even more work. And then still not guaranteed to be able to mesh much. LoRa isn’t common in devices.

@mathiasx you’re kind of talking me out of it 🤣

I experimented with building a block-wide WiFi network hidden in these birdhouses using some esp8266 firmware that was mostly automatic and quite clever, but what it really taught me is how the biggest barrier to useful mesh networks is more an application problem.

Most of the software we use is designed for high-bandwidth, low-latency, always-on networks and has little affordance for deviance from that. The dumb part is that this isn’t strictly a requirement given the way these applications are used, it’s just that they were designed with these assumptions.

It’s like how most web applications expect constant contact with their server energy though they could probably do the same job with queued asynchronous requests, and if they were designed this way to begin with, they might even feel more performant because you wouldn’t accidentally end up with dumb things like a UI update getting blocked by an unexpectedly long network request.

A counter example is something like SMTP email, which works happily even if connections go down for days, and can relay hop-by-hop between endpoints that are never even on the same network at the same time.

I think we could have nice networked applications over mesh topologies if we address the application layer at the same time.

@requiem yes, but it’d probably be easier and better to have a generic IP meshing protocol that any app can run over. They just don’t do so well without (as you said) fast direct connection to webservers, or things like DNS. The fact that Meshtastic needs an iOS app is kind of annoying, but that is being it defaults to BLE right now. I suppose each board could be a wifi AP that you connect to, and all DNS reqs at its web app. That breaks other apps, though, that think it’ll route to the net.

@requiem (I didn’t get firmware to flash on my boards so not entirely sure how it works.)

@requiem tangent, I’ve got two more little Esp32 boards that they sent me first by mistake, with cameras. No LoRa chips on these. Could it be something like a 3-tier networking scheme? LoRa long range between nodes, slow and small packets. Wifi mesh between local nodes, slightly faster and chatty w/ eachother. BLE to phones that connect to a node with an app. Missing from the current LoRa boards is a bigger screen for message history and keyboard entry. Local terminals as part of the network?

@requiem local terminals as in, the equivalent of a ham radio on a bench for contacting the network: no phone/BLE device needed. Keyboard input, eink screen, big battery since it is stationary?

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!