There are several scenarios where it would be beneficial to be able to bridge from the LORA radio over USB serial or IP connections. Pretty much all of these scenarios open the door to allow more than just MeshCore nodes to interact on the MeshCore network.
The proposed addition of adding 2 new bridge types would transport the raw packets over the chosen connection using the following frames:
- USB: packets would use the RS232 framing so that they could be detected and extracted from any console messages if using the same USB stream.
- IP: packets would be transmitted as raw octets given there would be no other data transmitted over the connection.
Use Cases
- Bridging MeshCore traffic from one band to another band (i.e. 915 MHz to 433 MHz)
- Transporting MeshCore traffic around barriers (e.g. mountains, forests, deserts)
- Connecting virtualized services
In use case 1, this might take the form of a point to point link to extend the network footprint or allow users running equipment on other frequencies to communicate across both bands.
Use case 2 is where this idea started from. Where I live here in Florida the county is divided right down the middle by about a 15 mile wide state forest. Trying to communicate across the forest has been problematic at times although it is better now with the 1W transmitters. Even with the higher power repeaters, we are still dropping packets at times. Being able to transport the MeshCore traffic over the internet or a private network connection would allow reliable communication around physical barriers until better infrastructure is in place.
Use case 3 is a solution where there does not need to be any middleware between the MeshCore node and a software service running. My need for this use case is to have virtualized Companion nodes running at home. Right now I have one node running on WIFI so that I can connect to the MeshCore network from anywhere in my house or 14 acre property.
Very early on I found it was going to be a bit unreasonable to always be grabbing my Companion to carry with me as I worked around the house or property and then to find out that the Companion node was not charged just added injury to insult. Now add a significant other that is not as technical and will almost never carry a Companion node with them.
So my solution for this use case is to build a Companion node that will run in a Docker container that will provide a network connection to the Companion app. I can then spin up a virtual Companion for each member of the family without having to maintain hardware nodes.
I have a third bridge type that I have build to make use case 3 more feasible which is bridging over MQTT. The MQTT bridge will be submitted under a separate PR. Using MQTT actually simplifies the use case where the MQTT topic is a virtual extension to the MeshCore network. This would allow all the virtual Companions to subscribe to the same topic and all the Companions would go through the same repeater to get on and off the actual MeshCore network.
I also have plans to build a virtual room server where multiple rooms could exist on a server without having to use node hardware for each room.
There are several scenarios where it would be beneficial to be able to bridge from the LORA radio over USB serial or IP connections. Pretty much all of these scenarios open the door to allow more than just MeshCore nodes to interact on the MeshCore network.
The proposed addition of adding 2 new bridge types would transport the raw packets over the chosen connection using the following frames:
Use Cases
In use case 1, this might take the form of a point to point link to extend the network footprint or allow users running equipment on other frequencies to communicate across both bands.
Use case 2 is where this idea started from. Where I live here in Florida the county is divided right down the middle by about a 15 mile wide state forest. Trying to communicate across the forest has been problematic at times although it is better now with the 1W transmitters. Even with the higher power repeaters, we are still dropping packets at times. Being able to transport the MeshCore traffic over the internet or a private network connection would allow reliable communication around physical barriers until better infrastructure is in place.
Use case 3 is a solution where there does not need to be any middleware between the MeshCore node and a software service running. My need for this use case is to have virtualized Companion nodes running at home. Right now I have one node running on WIFI so that I can connect to the MeshCore network from anywhere in my house or 14 acre property.
Very early on I found it was going to be a bit unreasonable to always be grabbing my Companion to carry with me as I worked around the house or property and then to find out that the Companion node was not charged just added injury to insult. Now add a significant other that is not as technical and will almost never carry a Companion node with them.
So my solution for this use case is to build a Companion node that will run in a Docker container that will provide a network connection to the Companion app. I can then spin up a virtual Companion for each member of the family without having to maintain hardware nodes.
I have a third bridge type that I have build to make use case 3 more feasible which is bridging over MQTT. The MQTT bridge will be submitted under a separate PR. Using MQTT actually simplifies the use case where the MQTT topic is a virtual extension to the MeshCore network. This would allow all the virtual Companions to subscribe to the same topic and all the Companions would go through the same repeater to get on and off the actual MeshCore network.
I also have plans to build a virtual room server where multiple rooms could exist on a server without having to use node hardware for each room.