4 ms·

Ciao gorgoiler, take a look to PJON's address space: https://github.com/gioblu/PJON/blob/master/specification/PJON-protocol-specification-v3.1.md#pjon-v31 https

Ciao gorgoiler, take a look to PJON's address space: https://github.com/gioblu/PJON/blob/master/specification/PJON-protocol-specification-v3.1.md#pjon-v31 https://github.com/gioblu/PJON/blob/master/specification/PJO... "The PJON protocol v3.1 in local mode supports connectivity for up to 254 devices, in shared mode supports connectivity for up to 4.294.967.295 buses (groups of devices) and up to 1.090.921.692.930 devices." That means 32 bits for the bus id, and 8 bits for the device id. Another interesting side-effect of the address-space scheme and the dynamic meta-data inclusion in the packet is the overhead: "It supports interoperability between systems that use a different configuration and provides with high efficiency including only the protocol's features used and the overhead effectively required (5-22 bytes)" In terms of minimum requirements PJON is uncomparable to IPv4 or IPV6 needing only in the most limited configuration: 1 IO pin, 16MHz clock frequency, 4144 bytes of program memory and 46 bytes of RAM

gorgoiler 7y ago
Thanks for the information, and this release! The minimal memory requirements are impressive. With 32 bits of global addressing space, is that for routing, or more to avoid address collisions when two networks are joined in an ad-how way? I noticed the PJON bus-ID assignment process and it seems a bit like MAC vendor ID assignment, so I’m guessing the latter? I don’t have much experience in this space, but it feels like it would be useful if the bus-addressing could be optionally extended to incorporate IP addressing and routing infrastructure. Perhaps IP to PJON bridging is already very easy?
- gioscarab 7y ago
  Ciao gongoiler, the 32 bits address identify a group of devices that share the same bus id, so yes, many groups of devices (that may have the same 8 bits device id) can coexist without addressing collisions. here: https://www.pjon.org/get-bus-id.php https://www.pjon.org/get-bus-id.php we distribute bus ids for free, for everyone who could need it. I have never thought about the bridging strategy you propose, yes effectively it may not be hugely complicated :) if you would like to share your idea with other users feel free to open an issue here: https://github.com/gioblu/PJON/issues https://github.com/gioblu/PJON/issues
- filar 7y ago
  Although not using PJON addresses as IP addresses, PJON has a few strategies that allow a PJON bus to span a Ethernet+WiFi LAN and/or WAN. I use this in my PJON-based home automation system using clusters of SoftwareBitBang based devices (a bus on a single wire plus ground), linking these clusters together and with the master with routers using the DualUDP strategy over my LAN. PJON is great for cases like this. It could easily cross the Internet as well but in that case I would recommend using site-to-site VPN commections for security as the PJON traffic is not encrypted (encryption is a little too heavy when running on limited devices like Arduino). I have shared my PJON-based automation library here for those interested: https://github.com/fredilarsen/ModuleInterface https://github.com/fredilarsen/ModuleInterface

gorgoiler 7y ago

Thanks for the information, and this release! The minimal memory requirements are impressive. With 32 bits of global addressing space, is that for routing, or more to avoid address collisions when two networks are joined in an ad-how way? I noticed the PJON bus-ID assignment process and it seems a bit like MAC vendor ID assignment, so I’m guessing the latter? I don’t have much experience in this space, but it feels like it would be useful if the bus-addressing could be optionally extended to incorporate IP addressing and routing infrastructure. Perhaps IP to PJON bridging is already very easy?

gioscarab 7y ago
Ciao gongoiler, the 32 bits address identify a group of devices that share the same bus id, so yes, many groups of devices (that may have the same 8 bits device id) can coexist without addressing collisions. here: https://www.pjon.org/get-bus-id.php https://www.pjon.org/get-bus-id.php we distribute bus ids for free, for everyone who could need it. I have never thought about the bridging strategy you propose, yes effectively it may not be hugely complicated :) if you would like to share your idea with other users feel free to open an issue here: https://github.com/gioblu/PJON/issues https://github.com/gioblu/PJON/issues
filar 7y ago
Although not using PJON addresses as IP addresses, PJON has a few strategies that allow a PJON bus to span a Ethernet+WiFi LAN and/or WAN. I use this in my PJON-based home automation system using clusters of SoftwareBitBang based devices (a bus on a single wire plus ground), linking these clusters together and with the master with routers using the DualUDP strategy over my LAN. PJON is great for cases like this. It could easily cross the Internet as well but in that case I would recommend using site-to-site VPN commections for security as the PJON traffic is not encrypted (encryption is a little too heavy when running on limited devices like Arduino). I have shared my PJON-based automation library here for those interested: https://github.com/fredilarsen/ModuleInterface https://github.com/fredilarsen/ModuleInterface