PJON (Padded Jittering Operative Network) is an experimental, arduino-compatible, multi-master, multi-media, software-defined network protocol that can be easily cross-compiled on many microcontrollers and real-time operative systems like ATtiny, ATmega, SAMD, ESP8266, ESP32, STM32, Teensy, Raspberry Pi, Zephyr, Linux, Windows x86, Apple and Android. PJON operates on a wide range of media, data links and existing protocols like PJDL, PJDLR, PJDLS, Serial, RS485, USB, ASK/FSK, LoRa, UDP, TCP, MQTT and ESPNOW. For more information visit the documentation, the specification or the wiki.

• New technology: PJON is an experimental network protocol stack crafted in 10 years of research and experimentation. It was originally developed as an open-source alternative to i2c and 1-Wire but during development its scope and features have been extended to cover use cases where IP is generally applied. PJON has been engineered to have a variable footprint (4.2-8.2 kB program memory) and overhead (5-35 bytes per packet) depending on its configuration.
• Multi-media support: PJON operates upon a wide range of protocols like TCP, UDP, MQTT, ESPNOW, USB, Serial, RS485 and LoRa. The PJON network protocol stack specifies and implements also PJDL that operates over a single wire of up to 2000m shared by up to 255 devices, PJDLR that operates with many ASK/FSK/OOK radio modules, and also PJDLS that operates wirelessly with light pulses using off-the-shelf LEDs and laser diodes.
• Increased reliability: Many protocols massively applied worldwide expose dangerous vulnerabilities, have weak error detection algorithms and are not resilient to interference. PJON is based on years of analysis and study not to make the same mistakes present in most alternatives and provide with a simpler and more efficient solution.
• High flexibility: PJON is totally software-defined and it is designed to be easily extensible. it builds out-of-the-box in all supported devices and operates transparently on top of any supported protocol or medium.
• Low cost: With no additional hardware needed to operate, minimal network wiring requirements and direct pin-to-pin or LED-to-LED communication, PJON is extremely energy efficient, cheap to be implemented and maintained. This experimental reference implementation is kept updated thanks to the strong commitment of its growing community.

• Cross-compilation support with the interfaces system calls abstraction
• Multi-media support with the strategies data link layer abstraction
• Modular packet format that includes only the field used (overhead 5-35 bytes)
• Hot-swap support, no need of system reset or shut down when replacing or adding devices
• Flexible local (device id) and shared (bus id) network identification
• Safe error detection done with modern CRC8 and CRC32 polynomials
• Optional inclusion of MAC addresses
• Optional acknowledgement
• Error handling

Researchers are active in many universities worldwide using PJON in different environments. The following list contains all the known published academic studies about PJON:

• Definition and Application of PJON-PLC for sensor networks by Jorge Gómez Segurola, Ingeniería de Tecnologías de Telecomunicación - Universidad de Cantabria (ES)
• Biomimetic electronics by Charlie Williams with scientific input from researchers Vítor Martins dos Santos, Diana Machado de Sousa and Sabine Vreeburg - Artist in Residency at Wageningen University (NL)
• LANC Video Camera Control by Jack Anderson - Department of Computer Science Loughborough University (UK)

Feel free to send a pull request sharing something you have made that could help, if you want to support this project you can also try to solve an issue. Thanks to support, expertise, kindness and talent of the following contributors, the protocol's documentation, specification and implementation have been strongly tested, enhanced and verified:

Fred Larsen, Zbigniew Zasieczny, Matheus Garbelini, sticilface, Felix Barbalet, Oleh Halitskiy, fotosettore, fabpolli, Adrian Sławiński, Osman Selçuk Aktepe, Jorgen-VikingGod, drtrigon, Endre Karlson, Wilfried Klaas, budaics, ibantxo, gonnavis, maxidroms83, Evgeny Dontsov, zcattacz, Valerii Koval, Ivan Kravets, Esben Soeltoft, Alex Grishin, Andrew Grande, Michael Teeww, Paolo Paolucci, per1234, Santiago Castro, pacproduct, elusive-code, Emanuele Iannone, Christian Pointner, Fabian Gärtner, Mauro Mombelli, Remo Kallio, hyndruide, sigmaeo, filogranaf, Maximiliano Duarte, Viktor Szépe, Shachar Limor, Pantovich, Mauro Zancarlin, Franketto, jzobac, DanRoad, fcastrovilli, Andrei Volkau, maniekq, DetAtHome, Michael Branson, chestwood96, Mattze96, Steven Bense, Jack Anderson, callalilychen, Julio Aguirre, Cimex97, der-schne, porkyneal, der-schne and Rainer Schoenberger.

• ModuleInterface - easy config and value sync between IoT modules by Fred Larsen
• PJON-cython - cython PJON wrapper by xlfe github user
• PJON-piper - command line wrapper by Zbigniew Zasieczny
• PJON-python - python interface by Zbigniew Zasieczny
• PJON-gRPC - gRPC server-client by Oleh Halytskyi
• PjonHL - PjonHL is a highlevel wrapper around PJON

All the software included in this project is experimental and it is distributed "AS IS" without any warranty, use it at your own risk. Licensed under the Apache License, Version 2.0.

When testing PJON, extreme care must be taken to avoid any danger. Consider that the implementation is experimental and may not behave as expected, use it at your own risk. When devices are connected to AC power you are exposed to a high chance of being electrocuted if hardware is not installed carefully and properly. If you are not experienced enough ask the support of a skilled technician and consider that many countries prohibit uncertified installations. When testing a SoftwareBitBang bus interference mitigation and protective circuitry guidelines must be followed. When experimenting with AnalogSampling setup safety glasses must be worn and transceivers must be operated cautiously to avoid potential eye injuries. Before testing OverSampling, ThroughSerial or ThroughLoRa radio communication, be sure the frequency, power and hardware used complies with local laws. When connecting a local bus to the internet all devices must be considered potentially compromised, manipulated or remotely actuated against your will. It should be considered a good practice not to connect to the internet systems that may create a damage (fire, flood, data-leak) if hacked.