5 ms·

PJON 12.0 – Networking freedom for hackers, makers and experimenters

186 points by gioscarab 7y ago

gioscarab 7y ago
More info here: www.pjon.org
- booli 7y ago
  Great work on PJON! Where can I find documentation/more info on how to build this for STM32 microcontrollers, like the STM32F091CCU7 using SerialAsync (over PLC)?
  - jsilence 7y ago
    Would also be interested in PJON for stm32 based systems.
    - gioscarab 7y ago
      Although stm32 is not the widest support, some strategies work with it, see the compatibility table here: https://github.com/gioblu/PJON/wiki https://github.com/gioblu/PJON/wiki
mxuribe 7y ago
I'm encouraged by more and more of this type of work! Cheers to all involved!
gorgoiler 7y ago
PJON (pronounced pigeon as I have just learned) looks exciting but it seems like it’s trying to provide globally addressable devices, as well as local ones? In the case of global addressing, don’t we already have an open and free protocol in the form of IPv6? Some quick googling found LWIP which provides an IPv6 stack in “tens of kB” which seems comparable to PJON’s “4kB to 8kB” but maybe that size difference really is important? LWIP project: https://savannah.nongnu.org/projects/lwip/ https://savannah.nongnu.org/projects/lwip/
- gioscarab 7y ago
  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
mahesh_rm 7y ago
Happy to see somebody from my city dedicated to such an ambitious project. I wish you all the best Giovanni! I see you are based in Via Larga, do you guys have an office there?
- gioscarab 7y ago
  Ciao mahesh, I do not know many people who is interested in computer science or networking here in Milan. Would be a pleasure to have a chat :)
  - mahesh_rm 7y ago
    Email inviata!
deleted 7y ago
[deleted]
hcarvalhoalves 7y ago
Cool! I see the documentation mentions: > ... during development its scope and features have been extended to cover use cases where IP is generally applied I understand the point is having minimal requirements, but how do you interoperate w/ IP?
- filar 7y ago
  PJON is based on a concept of selectable "strategies" to support using the protocol with different physical media. Some of these, like the one named SoftwareBitBang which allows a bus on a wire connected directly to an I/O pin, are very compact. There are also strategies for TCP and UDP based communication, essentially using the same packet structure but sending them as TCP or UDP over a LAN or WAN. These strategies need the Ethernet library, and use more memory. Still, the memory requirement is small enough to run a router with two PJON objects with the strategies SoftwareBitBang and DualUDP on an Arduino Nano with a W5500 Ethernet shield. This allows easy traversal between different physical media, and IP-based communication, also with PJON-based software running on a Windows or Linux computer.
charlesdaniels 7y ago
I would be curious to see to what extent it supports error recovery. Perhaps I missed it, but I didn't see anything that specifically addressed that. This seems like it would be very compelling, especially for small scale stuff. Being able to wire something as small as an ATiny85 into a computer and communicate over a relatively high-level protocol would be very useful for interfacing with sensors and other peripherals. I wonder how difficult it would be to adapt something like USBtiny[0] build an adapter. For potentially a few $ worth of parts, you could connect to all kinds of nifty embedded peripherals, albeit at relatively slow speeds. One obvious use case that comes to mind would be controlling lights / sensors / fans etc. in custom computer builds. 0 - https://dicks.home.xs4all.nl/avr/usbtiny/ https://dicks.home.xs4all.nl/avr/usbtiny/
- Animats 7y ago
  There's an optional 8-bit CRC and sequence number, with a single bit ACK.[1] This is even weaker than ARCnet, circa 1977, one of the earliest protocols for talking to low-end devices. This is for talking to things like lightbulbs with some US$0.50 CPU inside. It's for really low end devices. It's best for idempotent operations that can be requested repeatedly without harm and are timeout-tolerant. [1] https://github.com/gioblu/PJON/blob/master/specification/PJON-protocol-acknowledge-specification-v1.0.md https://github.com/gioblu/PJON/blob/master/specification/PJO...
  - filar 7y ago
    Small correction: Using CRC is not optional. Setting the crc flag makes it use CRC32 even for very small packets. The default is to use CRC8 for packets of a few bytes and then upgrade to CRC32 over a small size threshold. This is to minimize the size of otherwise tiny packets. Also, the ACK implementation depends on the strategy (physical media type), and it is not a single bit but a single byte, and it seems to me to be robust. I am sure the creator, gioblu, has some more comments about this.
NKosmatos 7y ago
Nice one, never heard of pigeon (PJON) before but it has potential. I understand that it’s mainly for low end devices, but I’d like to see it combined with https://balena.io https://balena.io
ngcc_hk 7y ago
Very hard to read in mobile github read me text. Is this require special hardware? Or usable even if you just have a python interpreter say. Or is it a replacement of ip stack. Wonder.
thebruce87m 7y ago
I work in embedded and I’m still not 100% clear on what this does after reading the README.md. I find that for a lot of projects actually. Is this an MQTT alternative? I find use-cases or working examples to be key, even better if they compare with pros/cons to alternatives.

186 points by gioscarab 7y ago

gioscarab 7y ago

More info here: www.pjon.org

booli 7y ago
Great work on PJON! Where can I find documentation/more info on how to build this for STM32 microcontrollers, like the STM32F091CCU7 using SerialAsync (over PLC)?
- jsilence 7y ago
  Would also be interested in PJON for stm32 based systems.
  - gioscarab 7y ago
    Although stm32 is not the widest support, some strategies work with it, see the compatibility table here: https://github.com/gioblu/PJON/wiki https://github.com/gioblu/PJON/wiki

mxuribe 7y ago

I'm encouraged by more and more of this type of work! Cheers to all involved!

gorgoiler 7y ago

PJON (pronounced pigeon as I have just learned) looks exciting but it seems like it’s trying to provide globally addressable devices, as well as local ones? In the case of global addressing, don’t we already have an open and free protocol in the form of IPv6? Some quick googling found LWIP which provides an IPv6 stack in “tens of kB” which seems comparable to PJON’s “4kB to 8kB” but maybe that size difference really is important? LWIP project: https://savannah.nongnu.org/projects/lwip/ https://savannah.nongnu.org/projects/lwip/

gioscarab 7y ago
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

mahesh_rm 7y ago

Happy to see somebody from my city dedicated to such an ambitious project. I wish you all the best Giovanni! I see you are based in Via Larga, do you guys have an office there?

gioscarab 7y ago
Ciao mahesh, I do not know many people who is interested in computer science or networking here in Milan. Would be a pleasure to have a chat :)
- mahesh_rm 7y ago
  Email inviata!

deleted 7y ago

[deleted]

hcarvalhoalves 7y ago

Cool! I see the documentation mentions: > ... during development its scope and features have been extended to cover use cases where IP is generally applied I understand the point is having minimal requirements, but how do you interoperate w/ IP?

filar 7y ago
PJON is based on a concept of selectable "strategies" to support using the protocol with different physical media. Some of these, like the one named SoftwareBitBang which allows a bus on a wire connected directly to an I/O pin, are very compact. There are also strategies for TCP and UDP based communication, essentially using the same packet structure but sending them as TCP or UDP over a LAN or WAN. These strategies need the Ethernet library, and use more memory. Still, the memory requirement is small enough to run a router with two PJON objects with the strategies SoftwareBitBang and DualUDP on an Arduino Nano with a W5500 Ethernet shield. This allows easy traversal between different physical media, and IP-based communication, also with PJON-based software running on a Windows or Linux computer.

charlesdaniels 7y ago

I would be curious to see to what extent it supports error recovery. Perhaps I missed it, but I didn't see anything that specifically addressed that. This seems like it would be very compelling, especially for small scale stuff. Being able to wire something as small as an ATiny85 into a computer and communicate over a relatively high-level protocol would be very useful for interfacing with sensors and other peripherals. I wonder how difficult it would be to adapt something like USBtiny[0] build an adapter. For potentially a few $ worth of parts, you could connect to all kinds of nifty embedded peripherals, albeit at relatively slow speeds. One obvious use case that comes to mind would be controlling lights / sensors / fans etc. in custom computer builds. 0 - https://dicks.home.xs4all.nl/avr/usbtiny/ https://dicks.home.xs4all.nl/avr/usbtiny/

Animats 7y ago
There's an optional 8-bit CRC and sequence number, with a single bit ACK.[1] This is even weaker than ARCnet, circa 1977, one of the earliest protocols for talking to low-end devices. This is for talking to things like lightbulbs with some US$0.50 CPU inside. It's for really low end devices. It's best for idempotent operations that can be requested repeatedly without harm and are timeout-tolerant. [1] https://github.com/gioblu/PJON/blob/master/specification/PJON-protocol-acknowledge-specification-v1.0.md https://github.com/gioblu/PJON/blob/master/specification/PJO...
- filar 7y ago
  Small correction: Using CRC is not optional. Setting the crc flag makes it use CRC32 even for very small packets. The default is to use CRC8 for packets of a few bytes and then upgrade to CRC32 over a small size threshold. This is to minimize the size of otherwise tiny packets. Also, the ACK implementation depends on the strategy (physical media type), and it is not a single bit but a single byte, and it seems to me to be robust. I am sure the creator, gioblu, has some more comments about this.

NKosmatos 7y ago

Nice one, never heard of pigeon (PJON) before but it has potential. I understand that it’s mainly for low end devices, but I’d like to see it combined with https://balena.io https://balena.io

ngcc_hk 7y ago

Very hard to read in mobile github read me text. Is this require special hardware? Or usable even if you just have a python interpreter say. Or is it a replacement of ip stack. Wonder.

thebruce87m 7y ago

I work in embedded and I’m still not 100% clear on what this does after reading the README.md. I find that for a lot of projects actually. Is this an MQTT alternative? I find use-cases or working examples to be key, even better if they compare with pros/cons to alternatives.