Hey y’all.
Interested to see if there is a recognised way or possible collaboration to open up multi channel gateways and MQTT topics for transport over significant networks at height in UK.
Of course, should the grid be unsurrounded by backhaul and the nuclear winter be upon us it would be unhelpful but interetsted to revitalise a previous LoRa mesh using Pycom boards to see how fast we could send a signal around the big ellipse.
White Alice is the frame of reference.
Meshtastic uses lora p2p, which is not compatible with lorawan gateways
I think the idea makes sense, as LoRaWAN (LW) operates many gateways and in combination with Meshtastic (MT) for sensors a higher coverage would be possible.
An MT-LW-Bridge module would be conceivable. In addition, MT would need a central LW-MT bridge server with a forward to MT-MQTT.
Scenario: MT sensor sends via MT nodes without Internet and nodes with active MT-LW bridge module also send messages to LW gateway. LW gateway sends to LW-MT bridge server and this to MT-MQTT.
The Meshtastic network would not need a node with an Internet connection and would use LoraWAN for this.
Edit: I created a new feature request [Feature Request]: LoraWAN gateway module · Issue #3838 · meshtastic/firmware · GitHub
There is no support from the Meshtastic project for cooperation with LoraWAN. The feature request was closed directly.
Technically this is possible, but Meshtastic is closing itself off here or the decision-makers do not understand the idea.
On the Meshtastic Discord server, there’s a “moonshots” channel, where people have been discussing all sorts of big-picture ideas in a “what-if, one day” context. Could be a good place for this topic?
This is a channel for discussing and planning (potential) revolutionary changes to the Meshtastic project. We’re looking for ideas that will move the project in an exciting new direction!
If you don’t see an idea similar to yours, please create a new topic so we can keep discussions focused
While there are some limits that we don’t want to push (legal, for example), we’re looking for ideas that think outside the box. Think of this channel as a place to sell the community on your vision. Once there’s consensus around an idea, feel free to submit an RFC! GitHub - meshtastic/rfcs: Storage for RFCs (Requests for Comment) for the Meshtastic project.
Please don’t spam this channel with a large number of ideas. We want to hear from everyone!
Indeed so, LoRaWAN and p2p are very different.
LoRaWAN is really one way only. Due to legal duty cycle limits there have to be significant limits in place on messages being sent from a Gatway back to a node as an ACK etc.
And in the UK a lot of LoRaWAN Gateways are TTN and the backend infrastructure for that is provided by TTI for free, not sure how they would react if their platform was used for a messaging app.
There are different layers of Meshtastic. The base layer is a (today) LORA bases mesh network. In theory you can also add BLE as communication protocoll. In this way Smartphones could extend the mesh via BLE mesh.
The chat is only one application layer. Telemetry and sensors imho are a different one.
I understand the differences. I am not referring to TTN, it is a closed stack. It is possible to add bridges to multiple endpoints already using open source LoRa Network Servers.
Locally decentralised networks are usually better at self-organising behaviours, my suggestion is more about extending functionality and utility not replacing them. GWs are able to collect, demodulate and store all phy frames and analyse certain aspects that are not encrypted or encoded to recognise how busy the spectrum is and help apply offsets based on user preferences.
It would be interesting to test MQTT-SN as a means of better managing pub / sub and to create a simple ACL list on the GW with dev_addr, nwk_swkey and app_swkey as ABP is more robust than OTAA given the need for the latter to do key exchange and instruct the device to change behaviours possibly. The latter obviously goes against the spirit of decentralised comms.
The current battery reqs for a super chatty codestack are high, I am currently running a meshtastic “client” on the OTII to see what it’s average current draw is (vhigh if serial output is anything to go by). I mention this as the router_client option would super helpful to explore in a similar way to border routers and how roles can change within a decentralised network.
Static configs are one way to provide mesh, I am intertested in how they can become dynamic and far reaching without disruping the meshtastic evolution.
Ok. LoRa and LoRaWAN are cooperating within the spectrum already, areas of heavily amplified devices and massive duty cycle consumption is a certainty.
It is the age old question of “where is the duty cycle violation (and there are many) happening” at TX or RX?
Shame if no collaboration is possible becasiue I really don’t think that a device with the ability to over ride the duty cycle and unwittingly cause collisions helps anyone.
I am not interetsting in such things.
We have network on large infra covering huge swathes of potential coverage. I am referring to integration of the same PHY layer.
Thanks for the link though.
ABP has no such ACK overhead. I actually also think that ABP is more secure in the real world and would require a hacker to visit every device location to steal or otherwise intervene.
I am not referencing TTN either, they are closed source black box.
You can use mqtt to bridge them, this is not a feasible plan.
Where are the LoRaWAN servers that Meshtastic could potentially co-operate with, as in who owns and pays for them ?
