lora

Radio is the playground of coincidence.

— Sarah Vowell

lora “long range” radio is a semi recent advancement in radio technology (2015 - present). i recently bought a few devices and have been enjoying checking out the mesh networks in the bay area. in north america, lora radios operate in the industrial, scientific, and medical (ism) radio band (type b) which is between 902 and 928 mhz. while the different meshes and software and apps and firmware are slightly different, they are all operating over standard radio and the differents are mostly just groups of conventions and layers of application usage on top of the foundational radio technology.

devices

two devices i have were purchased from muzi ᴡᴏʀᴋꜱ - who print small plastic enclosures with a battery pack to use with cheap lora radios. one is using the heltec t114 aka the h2t. the other is is r1 model, which is using the rak4631 wisblock module as its main chip. they’re both adorable to be honest. both of these devices are meant to be portable and moved about on a regular basis, and are built so.

i also have one static node that I have on my fire escape. It’s also a RAK4631 module (maybe actually 4630, but, basically identical), but has a solar panel attached to it with a larger ALFA Antenna (ALFA AOA-915-5ACM). i purchased it from an etsy seller called PeakMesh.

meshes

the two major mesh network softwares are meshtastic, and meshcore.

meshtastic

community sites:

• https://bayme.sh/

• i first got all my nodes connected to meshtastic - as there is a big meshtastic network in the bay area. meshtastic uses the concept of “presets” to allow for different tradeoffs - for example, “Short Range / Turbo” can communicate at 21kbps but needs to be much closer to work - whereas “Long Range / Fast” can reach must further distances but only can communicate at 1kbps. the entire bay area mesh made a move from one preset to the other (i think they’re using medium fast now) - but you can see on their map that a lot of nodes are still stuck with the default presets. these presets are in addition to the regulartory bands that you must operate the radio in. meshtastic is pretty easy to get started, the app and flashing instructions are really easy to get started. you can see the various presets used in the meshview map - you can see a decent number of presents used, but mostly things are MediumFast or LongFast. you can see some MediumSlow that haven’t switched over to the more widely used presets one downside of using meshtastic is that every node is also a repeater. meshtastic allows for node roles, so you can set up something to just be a router, or have other special roles (e.g. TRACKER, SENSOR, ROUTER, etc.) - but the default role, CLIENT, still does rebroadcasting. while this “spray and pray” approach does work well - it causes a lot of channel utilization (i.e. congestion) in the network. when the utilization gets too high, there is packet loss and collision. this is then what necessitates a different preset that has more redundancy at the cost of lower transmission speed

• the meshtastic network has their own broadcast algorithm, which includes a thing called “channel activity detection” (CAD). this means that if the channel is busy, the radio will wait before broadcasting until a free “slot” opens up. overall, the general idea here is called “managed flooding”. every node will try to rebroadcast messages up to a certain “hop limit”. this hop limit is configurable. each node will check to see if they’ve seen the message already rebroadcasted, if not, and the hop limit isn’t up, it will rebroadcast. different roles like ROUTER get higher priority to rebroadcast

• for direct messages, it is slightly different. after the managed flood approach delivers a message, the route taken is rremembered and the messages attempt to use the exact same sequence of nodes/hops as the other message (with a fallback to the managed flooding approach)

• meshtastic nodes also have defaults that sort of spam the network with information about the user, their position (GPS), as well as information about the device (such as battery level) - while this is useful, larger meshes like the bay area mesh request folks to reduce these types of regular broadcasts as they increase channel utilization and impact message deliverability rather, which is deemed more important

meshcore

community sites:

• https://bayareameshcore.org/

• https://www.73mesh.com/

• i’ve now switched my nodes to using MeshCore - which is simlar to meshtastic, but has a few important differences - the radio and module presets are the same, so you really just have one set of configurations (instead of radio + preset), which simplifies things. there are also less roles overall - client, room server, and repeater. it also uses a different routing/broadcasting algorithm - namely - that clients do not repeat by default. this is what meshcore calls the “messaging first” design, and makes meshcore unsuitable for usage with ATAK.

• the room server concept in meshcore is distinct - as that acts like a inbox for the messages for a particular room (a group message or chat room). this allows users to get the messages that were sent in the room later, just like an email server would hold onto your emails even if you weren’t logged into your email client at the time you got the messages. in contrast, meshtastic has no “state” in and of itself (though people do forward messages from the mesh to the internet for a log) - whereas meshcore has a way of keeping some state of messages in a room server.

• one thing that tripped me up as that when you flash the firmware with meshcore, you need to choose the repeater firmware type. secondly, once you do that, the node seem unresponsive, but rather, you need to administer the repeater over LoRA itself - by using the companion app (and a different radio). this is very different than meshtastic, where all nodes have the same firmware and then can modify their roles from the same app.

• meshcore also has a map and you can see my repeater node there listed as 🪆 little russia

---