Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure about Meshtastic, but in LoRaWAN, with the largest spreading factor (= maximum range) the maximum packet size is 11 bytes. And you get maybe one packet per second at most. Meshtastic is its own protocol and uses repeaters (and wider channels?), so I would expect them to do better, but not several orders of magnitude better.

I worked on LoRaWAN systems a couple years ago, and from what I found the biggest determinant of performance was what frequency band you're in. US915 has a 400ms dwell time limit for single transmissions, while EU868 has a 1% duty cycle limit. LoRa was designed for sending small amounts of data infrequently -- that's the "low-power" in LPWAN. Where I worked we were pushing it to the limits to get a couple hundred bytes per second at close range. LoRa does have some nice properties and I'm glad to see people using it outside of LoRaWAN, which is somewhat bulky for point-to-point communication.



Meshtastic can carry a bit more data per packet -- 200-ish bytes, IIRC -- but the same duty cycle/dwell time constraints apply.

The routing model also makes it hard to add more than a few dozen nodes to a mesh. For small groups over wide distances that's absolutely fine, but it isn't a great option if you want to connect large numbers of _people_, unless said people are clustered around a few devices sharing WiFi or BLE connection time. (Meshtastic also doesn't really support this use case b/c of a "one device == one user/identity/mailbox" model, but that's an application-level choice, not something imposed by the underlying network.)


Does it support protocol upgrades in the case that some nodes are within BLE range? That way someone could act as a local router.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: