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

What kind of bandwidth and latency would you get using this? Say, in the suburbs of a major city, two people 5 miles apart... how many bytes/second?

I'd love to see something like old school BBS systems take off again, an off the grid/off the internet network for hobbyists.

According to https://meshtastic.discourse.group/t/data-bandwidth-and-late... "But for the default very long range config it takes about 3 seconds to send 60ish bytes." Hmm, a bit slower than a 300 baud modem.



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.


If you are licensed there are 5W repeaters for 70cm under $100 - https://www.ebay.com.au/itm/194144864187.

Also, you can buy 1 watt Lora modules made by Ebyte, Sparkfun sell them.


In the US, the 70 cm ham band is 420 - 450 MHz. The transceiver you referenced is listed for 410 - 441 MHz. It could be used by a licensed ham to transmit data, if he/she determines how to modify or control it to avoid transmitting on the 410 - 420 MHz frequencies. It would also be necessary to send station identification[0] per Section 97.119(a) of the rules, which requires an amateur station to transmit its “assigned call sign on its transmitting channel at the end of each communication, and at least every 10 minutes during a communication.”

It would also be necessary to assure that any harmonics of 433 MHZ were within regulated limits.

EDIT: ETCI has specified 433 - 434 MHz as a LoRa band. In the US, the ARRL band plan[1] specifies those frequencies as auxiliary/repeater links, so they should be usable for LoRa, assuming no local frequency coordination disputes arise. The radio in question should be configured by the ham for that frequency.

EDIT2: In the US, and in general worldwide, hams can only communicate with other hams. So, 433 MHz LoRa would be limited to a mesh exclusively between hams, and with the necessary identification added. Unless you have specific reasons for using higher power, are a ham, and know what you're doing, it would be wise to use standard commercial LoRa radios, and stick to the 902 - 928 MHz radios in the US. (Which is shared with the 33 cm ham band - but the LoRa radios are low power.)

[0] http://www.arrl.org/news/fcc-proposes-18-000-fine-in-louisia...

[1] http://www.arrl.org/band-plan


In the stipulated Lora bands in most countries generally you get increased wattage allowable, but only allowed to transmit 1% of the time, or similar.

This is less punitive than it seems, especially with the preamble "chirp" you can keep a link "alive" with a handful of seconds every ten minutes or so, without transmitting a message.

If the Rx woke up once a minute for a few seconds on a synched clock, then you are never more than a minute away from a message. This also aids in power management for battery life.

I am not sure how it would be policed, and what time period is acceptable for measuring, eg per hour, or is it ok one weekend a year at 20% continuous duty cycle, and technically is it per device or per user, and so on. (I think I know the reasonable answers to these questions, just saying).

But intent obviously is with higher power and range to ensure a minimum number of devices can operate in a given region.

But you can broadcast, so one transmission can hit many other users, and they could re-broadcast on your behalf as a store and forward type protocol, all for one transmission by you.




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

Search: