Explore PJON as alternative communication method

[paidforby]

In https://github.com/sudomesh/disaster-radio/issues/48#issuecomment-605714890 @elimisteve brought up the idea of using/supporting the PJON protocol, https://www.pjon.org/. It seems like a cool project and something we should definitely keep in mind. Currently their "ThroughLoRa" strategy does not support the ESP32, but I believe creating that support would be very simple as that strategy is little more than a wrapper around Sandeep's arduino-LoRa library, which we are also using.

However, I see two issues with using PJON as the primary communication method for disaster radio,

1. they don't appear to have any mesh routing protocol, which is the main value of our LoRaLayer2 protocol.
2. this is the bigger issue, their addressing and routing setups have to be very organized, since PJON addresses are only one byte (0 to 255), you can't randomly assign addresses to devices and all the devices you want to talk need to be using the same bus id. This makes the network less dynamic and means an installer would have to actually plan the network instead of just distributing nodes.

There are some good take aways from PJON, the bus id isn't a bad idea as a way of scaling the network and the way the protocol is abstracted from the physical layer is super cool.

It could interesting to add PJON as an optional client or to collaborate with them on to create a more meshy routing method.

[Juul]

Thanks for doing the research! From what you wrote it sounds like PJON isn't trying to solve the same problem. Still interesting.

[elimisteve]

their addressing and routing setups have to be very organized, since PJON addresses are only one byte (0 to 255), you can't randomly assign addresses to devices and all the devices you want to talk need to be using the same bus id. This makes the network less dynamic and means an installer would have to actually plan the network instead of just distributing nodes.

I don't think so; there can be a router in between to route packets between devices that are on different buses. The GlobalUDP strategy lets you route packets all over the world through a gateway of your choosing, for example.

A bus id seems to be analogous to a vendor-specific MAC address prefix, but in this case they're person-specific. It's 256 devices per person, not 256 devices per network :-). A bus id is 32 bits/4 bytes, not 1 byte; mine is 0.0.1.186, for example.

The installer could request its own bus id by doing an HTTP POST to https://www.pjon.org/bus-id-service.php ; see view-source:https://www.pjon.org/get-bus-id.php line 289 for the JS send() function that gets called when the user manually submits that form.

[gioblu]

Ciao @elimisteve thank you for your clarification, I have waited to answer not to influence too much your user's following responses.

The GlobalUDP strategy lets you route packets all over the world through a gateway of your choosing, for example.

Absolutely, you can also route packets through the internet using the MQTTTranslate strategy, which is able to transport also the MAC address if present/required.

A bus id seems to be analogous to a vendor-specific MAC address prefix, but in this case they're person-specific.

A bus id is just an address of a group of devices, each user can request (responsibly) more than one if required. Just take in consideration that all PJON users have 4,294,967,296 bus ids available (just like IPv4 addresses). Each bus id represents a subnet in which up to 255 devices can be present and uniquely addressed.

The installer could request its own bus id by doing an HTTP POST to https://www.pjon.org/bus-id-service.php ; see view-source:https://www.pjon.org/get-bus-id.php line 289 for the JS send() function that gets called when the user manually submits that form.

I have never considered to expose the API publicly, but now I see why you are suggesting it, I will work on the website to explain how to access to the API automatically and avoid the manual registration if required. Thank you for the suggestion.

[paidforby]

I don't think so; there can be a router in between to route packets between devices that are on different buses.

This requires a concept of "router" and "device", in disaster.radio, these are one and the same, every node is both a router and a device. Might be worth looking closer at the PJON DynamicRouter, if it makes sense to make for each node to be a dynamic router with it's own bus id, obviously we would only want to use this in a "local-mode."

A bus id is just an address of a group of devices, each user can request (responsibly) more than one if required. Just take in consideration that all PJON users have 4,294,967,296 bus ids available (just like IPv4 addresses). Each bus id represents a subnet in which up to 255 devices can be present and uniquely addressed.

Currently, disaster.radio uses 6-byte addresses (though we plan on reducing this to 4-bytes) that are based on the ESP32's wifi mac address, this creates a near zero chance of address conflicts.

While 255 is plenty big enough for potential disaster.radio networks, it's not large enough to dynamically assign addresses without a centralized person/server managing the addresses.

A solution could be for disaster.radio to hold a few bus ids and then, assuming the range is large enough, we could randomly/dynamically assign devices from within that range, with the combination of bus id and device id. This introduces a host of other conceptual issues like, where is the router? what routing method are they devices using? what if the addresses "get online"?

I think the structure inherent to PJON just makes it difficult to apply it to our structure-less network. I agree with @Juul that PJON isn't solving the same problem as disaster.radio. This is not to discourage someone from writing a PJON client for disaster.radio, but more so someone doesn't have to retrace my steps in attempting to conceptualize disaster.radio using PJON as its primary communication protocol.

[gioblu]

PJON isn't solving the same problem as disaster.radio.

I agree with this, PJON is just a general purpose network protocol.

This requires a concept of "router" and "device", in disaster.radio, these are one and the same, every node is both a router and a device. Might be worth looking closer at the PJON DynamicRouter, if it makes sense to make for each node to be a dynamic router with it's own bus id, obviously we would only want to use this in a "local-mode."

The InteractiveRouter is a router that can also operate as a node. A way to use it along with PJON for your needs could be to base the communication on local mode and use only the broadcast address, encapsulating the fields you need, and implement a response if that is required.

[gioblu]

@paidforby, just as an example https://www.ad24.cz/ is a startup that have implemented a mesh on top of PJON using the approach I have suggested above, they have a lot of nodes (LCD screens) already deployed which can project advertising around the city of Prague. Advertisers can choose the place and time where their ADV will be shown.