
Show HN: PJON – Digital communication framework for IOT - gioscarab
https://github.com/gioblu/PJON
======
anfractuosity
Previous discussion:

[https://news.ycombinator.com/item?id=13671587](https://news.ycombinator.com/item?id=13671587)

[https://news.ycombinator.com/item?id=10283028](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?

~~~
gioscarab
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...](https://github.com/gioblu/PJON/blob/master/strategies/SoftwareBitBang/specification/PJDL-
specification-v1.0.md), 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.

~~~
anfractuosity
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)?.

~~~
gioscarab
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...](https://github.com/gioblu/PJON/blob/master/strategies/SoftwareBitBang/SoftwareBitBang.h)

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...](https://github.com/gioblu/PJON/tree/master/strategies/AnalogSampling)

------
gioscarab
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.

------
stevekemp
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?

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

