This website does not use any cookie and does not store visitors' ip addresses, personal data or behaviour. This website does not use any analysis or tracking tool. Visitors, while requesting a bus identification, can include an email address along with geographical location and technical data related to the hardware used if it is desired. Email addresses will be used solely to inform visitors about updates, vulnerabilities, critical bugs or network performance/configuration issues. Requests for data deletion from our bus id database can be sent to firstname.lastname@example.org.
Engineers and memes taught us that it is stupid to create a new Standard, it is instead intelligent to use what is already available not necessarily understanding its principles!
Far back in 2009, while following Digital Communication, Advertising and Art Direction at NABA (New Academy of Arts in Milan), I became interested in Professor Massimo Banzi's classes and managed to get a Diecimila. In just one day my vision of the world changed and I slowly started to better understand computers and electronics while sharing results with the Arduino community both on my website www.gioblu.com and on Arduino's forum. I began building robots and this guided me to my first startup experience: a webshop of Arduino compatible, CNC machined, robot kits, boards and sensors.
Me in 2010 testing one of the firsts products developed by Gioblu Robotics, a self-balancing Arduino robot
Let's transmit data
I needed to transmit data through many microcontrollers (or subsystems) on a common bus, so I started developing my own software emulated data link layer because I was not satisfied by the solutions available at the time. In 2010 I wrote the first implementation of the Padded jittering data link layer v0.1 which was basic, full of bugs and working by mere chance. After debugging, experiments proved it was working well not only through wires and the human body, but also wirelessly through radio and infrared light. It showed to be robust operating bidirectionally in spite of interference.
Me in 2010 testing Wireless communication through 1 LEDs per device used both as receiver and transmitter
I want to write my protocol
After noticing that adding quiescent devices connected to the bus was not affecting occurring communication between two other connected devices, I started experimenting with an initial collision avoidance phase, a one byte device id supporting 254 (plus BROADCAST) unique device ids and a synchronous acknowledge at the end of the packet. It was shocking to see that many devices were able to send and receive data through the same wire. In 2010 I released the PJON protocol layer specification v0.1 on the Arduino forum, receiving many "don't reinvent the wheel" and few active contributors.
A PJON bus made of 14 Arduino boards sharing the same single wire as communication medium
With a working protocol layer and support of the community, I went further proposing a 2 level addressing: one (1 byte) to identify a device and one (optional 4 bytes) to identify a group of devices or bus, supporting up to 4.294.967.295 buses and a total of 1.090.921.692.930 devices. This addition released in the PJON protocol layer specification v0.2 enabled coexistence and networking for groups of devices. Thanks to Micheal Teeuw's post on his blog, PJON received contributions, testing, debugging and feature requests. Many talented contributors ported devices like ESP8266, Teensy 3.2 and Node MCU.
Micheal Teeuw in 2015 testing and sharing results with the PJON library on his blog
Let's abstract the data link layer
With Strategies, PJON had finally a way to communicate data agnostically through many different media and to support more than one PJON instance running in the same program. The curiously recurring template pattern or CRTP was adopted to abstract the physical layer in separate classes called Strategies. Thanks to this change from then it was possible to instantiate a PJON object passing the preferred data-link. Initially, I ported two Strategies, one for wired communication called SoftwareBitBang and one for noisy media (such as radio) called OverSampling. Later on, I developed together with Fred Larsen ThroughSerial able to operate through a serial port.
Me in 2015 building a 5km range ASK/FSK HALF-DUPLEX PJON packet radio
Something that seemed to be just a boy's game appeared on many relevant websites and blogs where many trolls, raging, were wondering who was this italian guy without a PhD from MIT, who tried to approach this problem. Hackaday and the Atmel blog wrote about the PJON protocol and from that day an ongoing earthquake began. Since then, the PJON protocol layer specification has been used in academic researches and PhDs in different parts of the world, and the official PJON implementation has already been applied globally in a wide range of different systems.
Hackaday in 2016 reviewing PJON and provoking a hell of trolls in the comments
Why don't we add a header
The release of the PJON protocol layer specification v0.3 is the result of the most interesting proposal I have received so far, by Fred Larsen, who is now a great new friend already even if we never met personally. He proposed the addition of a 1 byte header containing information on the packet and the configuration requested by the transmitter. This left a fixed configuration scenario, where interoperability was impossible, and headed to a dynamic network architecture. An entire new set of possibilities opened up and many contributors started to consider how to take advantage of this new entity.
Mauro Zancarlin in 2015 building a complex home automation system with PJON
PJON over the internet
EthernetTCP and LocalUDP strategies proposed and developed by Fred Larsen enable multiple devices with Ethernet ports using PJON to communicate with each other on a LAN, WAN or across the Internet. So now you can also create a PJON network of devices using an internet connection. A growing community is providing us with PJON implementations in other programming languages like PJON-python by Zbigniew Zasieczny and PJON-c by Matheus Garbelini, thanks to their work, it is now possible to run PJON on a wider range of devices. At the same time the protocol reached is first stable version with the release of the PJON protocol layer specification v1.0 which added a lot of new features.
Atmel in 2016 reviewing PJON on its official blog
Let's make it universal
Implementing the interfaces abstraction, PJON can run and be cross-compiled on different platforms and architectures simply defining a dedicated set of interfaces to system calls. I have developed the RPI interface to support Raspberry Pi, after few weeks Zbigniew Zasieczny developed the WINX86 interface enabling PJON communication on computers running Windows, and soon after, Fred Larsen developed the LINUX interface enabling PJON communication on computers running Linux. Finally, the same codebase running on ATtiny85 can be executed on a real time operative system supporting full interoperability.
Me in 2017 testing SoftwareBitBang operating in spite of AC interference
Mac OS X
Embedded systems connected
PJON® is the first open-source network protocol able to be executed on virtually every computer or microcontroller and to transmit data through every sort of communication protocol or physical medium, such as wires (PJDL, Ethernet TCP/UDP, Serial and RS485), radio (ASK, FSK, OOK, LoRa and WiFi) and light pulses (PJDLS). It can be easily cross-compiled on many architectures like ATtiny, ATmega, ESP8266, Teensy, Raspberry Pi and Windows X86. It is a valid tool to quickly build a network of devices.
If you believe in this project and you appreciate our work, please, make a donation. The PJON project is entirely financed by contributions of wise people like you and its resources are solely invested to cover the development and maintainance costs. Thank you and happy tinkering!