Show HN: PJON – Digital communication framework for IOT | Hacker News Reader

Show HN: PJON – Digital communication framework for IOT

github.com

25 pointsgioscarab8 comments

Open articleView on HN

Previous discussion:

https://news.ycombinator.com/item?id=13671587

https://news.ycombinator.com/item?id=10283028

A couple of questions:

* How does it compare to Modbus

* You mention in a previous post some data rates, what cable lengths are being used for those?

Ciao anfractuosity, Modbus have more "dedicated" and shorter (255 bytes) data frame and in my opinion is a little more narrow in its applications, its overhead if I am not mistaken is also high (11 bytes). PJON works with no additional hardware at the voltage level you prefer, totally software emulated, is a network protocol stack of 2 layers (data-link and protocol layer) can send packets of 255 or 655353 bytes, can support up to 255 devices connected on the same wire, or up to 1.090.921.692.930 devices in a bus network of up to 4.294.967.295 buses, it supports CRC8 or CRC32 at users choice and have an overhead added to information varying from 3 up to 19 bytes (thanks to a header configuration driven packet format). PJON also supports 2 different types of acknowledgment (sync and async).

Being the data link level handled "agnostically" PJON protocol layer is able to run over Serial, RS485, TCP and UDP (with the necessary hardware additions).

PJDL (Padded Jittering Data Link) https://github.com/gioblu/PJON/blob/master/strategies/Softwa..., that is the default data-link we propose for PJON procedure, it is generally tested with 50 meters cable, working fine. We actually still haven't find a range limit, and maximum devices limit.

Thanks for the response. That's interesting wrt the cable length, so you're simply using the IO pins directly for that, rather than a transceiver (e.g. rs485)?.

Exactly is funny to think that this bunch of methods are doing all the data-link job with no additional hardware using only micros() and delayMicroseconds(): https://github.com/gioblu/PJON/blob/master/strategies/Softwa...

Here instead using AnalogSampling PJON can communicate wirelessly using only 2 visible light LEDs, used both as transmitters and photodiodes on the same pin :) https://github.com/gioblu/PJON/tree/master/strategies/Analog...

PJON defines things up to level 3 -- you hand it a bunch of bytes, and tell it: "deliver to node 12". It is up to you to decide how the bytes must be interpreted, and to ensure the recipient can handle them properly.

PJON has a number of data/physical link layers: a network running on a single arduino pin, link over LEDs, TCP, UDP, supercheap radio modules, RS485 serial.

Compared to that, Modbus defines things up to application layer (layer 7). You tell it, "read input 1" or "write 75 to register 33" and it does it for you. You can also send arbitrary packets like PJON, but this is rarely done.

Modbus also has number of physical layers: serial (usually used with RS485 or RS232), TCP, UDP, and high-speed proprietary links. It is not designed for low speed links, so it would not work well over LED link, supercheap radio modules, or a single arduino pin link.

Ciao IshKebab as far as I know still no integrated circuits has been designed or produced to handle PJON if that was the question.

PJON protocol layer contains many features not present in the i2c specification, and also its physical layer runs over only one wire and doesnt need precise clocking as i2c does. Infact with i2c you can have unreliable communication with a meter long wire, and it is designed to connect integrated circuits over a board and not to connect many arduinos around a house, it stricly depends on the requirements you impose for your application.

What problem does this solve that isn't already handled by I2C etc?

I appreciate it is software-only, but if your hardware uses a different bus already using this seems like it would be futile. If you've got control over both ends, otherwise, and you're not constrained by any existing bus why would you just PJON over TCP/IP, UDP, or some other similar standard?

Struggling to see how this could be useful - what problem does it solve, exactly?

I can't see this ever being implemented in hardware. Also what is the actual advantage of this over I2C/I3C, SPI etc?

Reply on news.ycombinator.com