Seems like this would support institutional/campus environments or changing environments where the sensors at the edge are sending higher bandwidth ultimately back to an Internet node using LoRA mesh--instead of directional WiFi? I'm trying to envision the application of a mesh like this. These could be examples? - interconnected nodes need to share data (like images) - interconnected nodes are acting as a collective…
BYOMesh – New LoRa mesh radio offers 100x the bandwidth
21–30 of 168 posts
Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#22There are some significant regulatory issues with the current popular mesh network protocols in the USA, namely that neither MeshCore or Meshtastic are compliant with the actual FCC regulations. 100x bandwidth because you're breaking the rules isn't the same as 100x bandwidth legally.
Here is the issue discussing this in the MeshCore repository: https://github.com/meshcore-dev/MeshCore/issues/945
Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#23Correct me if I am wrong but I thought the primary appeal of LoRa was range? Also isn't the primary factor in making long range radio go through things is the frequency? So 2.4ghz is the same frequency as consumer wifi right and thus would propagate about the same right? It doesn't seem like this would be that useful except that the protocol is LoRa so you can have higher bandwidth between two devices if they happen…
Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#24Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#25nice to not see some non-ai titles
Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#26Earlier quoted context omitted.
Metricom Ricochet used dual-band radios, operating in 900MHz and 2.4GHz, to form a routable mesh that delivered internet access and other services, in 1999.
Ah, thanks, I didn't find any reference to that from a search (found a messaging app).
Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#27Correct me if I am wrong but I thought the primary appeal of LoRa was range? Also isn't the primary factor in making long range radio go through things is the frequency? So 2.4ghz is the same frequency as consumer wifi right and thus would propagate about the same right? It doesn't seem like this would be that useful except that the protocol is LoRa so you can have higher bandwidth between two devices if they happen…
LoRa would go much farther than Wifi on 2.4ghz. Lora uses Chirp Spread Spectrum (CSS) modulation while wifi uses OFDM (Orthogonal Frequency Division Multiplexing). The first being designed for extreme range while the latter for bandwidth. At 2.4ghz you could probably get LoRa connections up to 6 miles with the right antenna height.
Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#28Correct me if I am wrong but I thought the primary appeal of LoRa was range? Also isn't the primary factor in making long range radio go through things is the frequency? So 2.4ghz is the same frequency as consumer wifi right and thus would propagate about the same right? It doesn't seem like this would be that useful except that the protocol is LoRa so you can have higher bandwidth between two devices if they happen…
So you could probably pull off a 2.4GHz mesh outdoors in rural areas? It'd be feasible in the same places a microwave-laser hilltop-to-hilltop link would, but instead of "fast but point-to-point" it's "slow but meshed" (and with much larger tolerance for slop — you don't need to put everything on fixed masts so they have perfect line-of-sight, you can just stick them on the tops of trees or whatever and if they wave in the wind it still works.)
Mind you, the authors' motivating use-case for the hardware seems to be their project (https://github.com/datapartyjs/MeshTNC) to (AFAICT) bridge LoRa (or some specific LoRa L2 protocol — Meshtastic, probably?) to packet radio, i.e. digital packet-switched signalling over amateur (HAM) radio bands.
In that context, the tradeoff of high throughput for low propagation makes sense. Insofar as you're working with LoRa, and want to build and experiment with a bunch of site-local devices that mesh between themselves and interoperate with LoRa data-link protocols, you'd likely be speaking something like LoRA over 2.4GHz (LoRa itself doesn't spec a way to do that, but you could make it happen within the closed ecosystem of your own home/office.)
And in that context, you could use a MeshTNC device as something like "LoRaLAN" router. It'd be something you'd keep somewhere central in your house (like a wi-fi router), plugged into power + an antenna (internal to your house, like a wi-fi router) and plugged into a packet-radio transceiver with its own even-bigger antenna, outside your house. (Like a wi-fi router being plugged into a gateway modem on its upstream WAN port.)
This MeshTNC device would then pick up signals from:
- regular LoRaWAN IoT devices and Meshtastic handsets in your building
- more custom devices in your building†, that you've built yourself, that use another MeshTNC module; where these other devices do their part of the meshing only on the 2.4GHz band, which means they don't need big fiddly external antennas like LoRa devices do, but can be quite compact
- and possibly, a separate bidirectional LoRa repeater (made from any existing "high-gain" LoRa module, i.e. the kind used in mains-powered LoRaWAN base stations) — which brings in LoRa mesh traffic from outside your building, and picks up and carries away "destined for elsewhere in this area" LoRa mesh traffic that your "LoRaLAN" device has emitted (either due to forwarding it from your 2.4GHz-only mesh handsets/devices, or due to forwarding it after receiving it from packet radio.)
Though keep in mind you only need that complexity for the 2.4GHz-only mesh devices, since there isn't an existing mesh to forward those packets. But this whole setup is still also a regular LoRa mesh, and so you can still use regular LoRa (e.g. meshtastic) handsets, and put out packets that make their way through your regional mesh, back to the packet-radio bridge in your building; and from there to who-knows-where.
† To be clear, the 2.4GHz mesh handsets would only work reliably inside your building (if the 2.4GHz antenna is inside your building); but knowing HAMs, half the point would be seeing how far away you could get from your house/office and have your 2.4GHz mesh handsets keep working. (You'd probably want to have a second MeshTNC "base station" with a building-external antenna to try that. Pleasantly, that doesn't complicate the topology; it's all still just mesh, so you can just drop that in.)
Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#29Earlier quoted context omitted.
TBH Meshtastic's code isn't great either. It's neat to play with but not robust.
It sucks how everything feels like a toy. I think meshtastic is the closest thing to a “product”. They made a bunch of bad architectural decisions that are haunting them now like how nodes broadcast its info.
If IP were designed today the packets would have 500+ bytes of plain text JSON as headers and the spec would support hundreds of extensions.
Re: BYOMesh – New LoRa mesh radio offers 100x the bandwidth
#30Seems like this would support institutional/campus environments or changing environments where the sensors at the edge are sending higher bandwidth ultimately back to an Internet node using LoRA mesh--instead of directional WiFi? I'm trying to envision the application of a mesh like this. These could be examples? - interconnected nodes need to share data (like images) - interconnected nodes are acting as a collective…
I’m guessing it’s just haloW without the licensing requirements.
HN has a lot of us that have ~0 idea what you'd use this for, even when we steelman, all we can do is vaguely handwave about easier to setup wireless internet on a vast compound we own.
Would be really cool if someone could hop in and just give a couple one off examples, i guess? Only other one handwave I can think of is IOT x assembly line stuff for businesses, but I'm real curious why individuals are so into it -- or maybe they're not, and that's why the codebase quality is so poor? Idk.