Difference between revisions of "Protocol decoder:Pjon"

From sigrok
Jump to navigation Jump to search
(nits, link from PJON to PJDL, split still TODO (many PJDL details here in the PJON page))
Line 1: Line 1:
{{Infobox protocol decoder
{{Infobox protocol decoder
| id              = PJDL V4.1
| id              = pjon
| name            = Padded Jittering Data Link
| name            = PJON
| description    = asynchronous serial data link for low-data-rate applications that supports both master-slave and multi-master communication over a common conductive medium
| description    = The PJON protocol
| status          = Work in progress
| status          = in progress
| license        = GPLv2+
| license        = GPLv2+
| source_code_dir =  
| source_code_dir = pjon
| input          = logic
| input          = pjon-link
| output          = PJDL
| output          = —
| probes          = Data
| image          = [[File:Pjon_pd.png|250px]]
| Info           = https://www.pjon.org/PJDL-specification-v4.1.php
| info           = [https://www.pjon.org/PJON-protocol-specification-v3.2.php pjon.org]
|
}}
}}


Pjon protcol desciption can be found on: https://www.pjon.org/PJON-protocol-specification-v3.2.php
The [https://www.pjon.org/PJON-protocol-specification-v3.2.php PJON protocol specification] documents the layout of frames which can get transmitted by means of several link layers, among them [[Protocol_decoder:Pjdl PJDL]]. Communication peers have local addresses in the 1..254 range, and optionally can reside in busses with 32bit IDs (often written in dotted quad notation similar to IPv4). Many of the protocol's frame fields are optional to reduce the overhead during transmission, their presence is controlled by a header configuration field. Both the essential header of a frame as well as the complete frame content are checksummed, the CRC method gets picked by the transmitter (longer frames mandate wider checksums beyond a given threshold).
 
 
'''TODO''' Split the common PJON parts (upper layer) from the PJDL specific link layer parts. Two layers of protocol decoders will exist such that other link layer types can get added transparently. Perhaps link to the external spec if the text here would be a verbatim citation? Keeping a summary here may be helpful, keeping a copy might be less so (license should not be an issue, the spec was released to the Public Domain).




Line 88: Line 90:
== Decoder ==
== Decoder ==
Work in progress.
Work in progress.
== Resources ==
== Resources ==
* [https://www.pjon.org/PJON-protocol-specification-v3.2.php Pjon protocol Documentation]
 
* [https://www.pjon.org/PJDL-specification-v4.1.php Pjon PJDL strategies web site]  
* [https://www.pjon.org/PJON-protocol-specification-v3.2.php PJON protocol spec]
* [https://github.com/gioblu/PJON/tree/master/src/strategies/SoftwareBitBang Github Pjon project page]
* [https://www.pjon.org/PJDL-specification-v4.1.php PJDL link layer spec]  
* [https://github.com/gioblu/PJON/ github project] (reference implementation, and documentation) and its [https://github.com/gioblu/PJON/tree/master/src/strategies/SoftwareBitBang PJDL implementation]


__FORCETOC__
__FORCETOC__


[[Category:Protocol decoder]]
[[Category:Protocol decoder]]

Revision as of 22:05, 23 June 2020

pjon
Pjon pd.png
Name PJON
Description The PJON protocol
Status in progress
License GPLv2+
Source code decoders/pjon
Input pjon-link
Output

The PJON protocol specification documents the layout of frames which can get transmitted by means of several link layers, among them Protocol_decoder:Pjdl PJDL. Communication peers have local addresses in the 1..254 range, and optionally can reside in busses with 32bit IDs (often written in dotted quad notation similar to IPv4). Many of the protocol's frame fields are optional to reduce the overhead during transmission, their presence is controlled by a header configuration field. Both the essential header of a frame as well as the complete frame content are checksummed, the CRC method gets picked by the transmitter (longer frames mandate wider checksums beyond a given threshold).


TODO Split the common PJON parts (upper layer) from the PJDL specific link layer parts. Two layers of protocol decoders will exist such that other link layer types can get added transparently. Perhaps link to the external spec if the text here would be a verbatim citation? Keeping a summary here may be helpful, keeping a copy might be less so (license should not be an issue, the spec was released to the Public Domain).


The PJON protocol v3.2 in local mode supports connectivity for up to 254 devices.

The packet format is dynamic therefore meta-data can be optionally included using the header as a bitmap of selected features. 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). PJON can be used for simple low-data-rate applications as an alternative to 1-Wire, i2c or CAN but can also be applied in place of IP to interconnect more complex networks.

alt text


The graph below shows the conceptual model that characterizes and standardizes the communication. Its goal is the interoperability of diverse systems on a wide range of media with the use of a new set of Open Standards. The graph partitions represent abstraction layers.


BASIC CONCEPTS

Packet transmission is regulated by a 8 bits header:

- Devices communicate through packets with a maximum length of 255 or 65535 bytes
- Devices are identified by a unique 8 bits device id
- Buses are identified with a 32 bits bus id
- Many buses can coexist on the same medium
- Synchronous and or asynchronous acknowledgement can be requested (see Acknowledge specification v1.0)
- Network services are identified with a 16 bits port id

HEADER CONFIGURATION

The header is a bitmap of the meta-data contained and the configuration required. Unlike other protocols, PJON has a dynamic packet format designed to include in each packet only what is strictly required to carry out the exchange. Depending on the bitmap configuration a variable overhead (5-22 bytes) is added to information.

alt text
- MODE bit informs if the packet is formatted in shared (value 1) or local mode (value 0)
- TX INFO bit informs if the sender info are included (value 1) or not (value 0)
- ACK bit informs if the synchronous acknowledgement is requested (value 1) or not (value 0)
- ACK MODE bit informs if the asynchronous acknowledgement is requested (value 1) or not (value 0)
- PORT bit informs if a 16 bits network service identifier is contained (value 1) or not (value 0)
- CRC bit signals which CRC is used, CRC8 (value 0) or CRC32 (value 1)
- EXT. LENGTH bit informs if the packet contains 8 (value 0) or 16 bits (value 1) length
- PACKET ID bit informs if the packet contains (value 1) or not (value 0) a 16 bits packet id

Unacceptable header configuration states for standard transmission:

----1-0- or ACK MODE bit high, and TX INFO bit low (requires transmitter info)
-10----- or EXT. LENGTH bit high and CRC bit low (forced CRC32 for length > 15)

Unacceptable header configuration states for a broadcast transmission:

-----1-- or ACK bit high (acknowledgement not supported if broadcasting)
----1--- or ACK MODE bit high (acknowledgement not supported if broadcasting)
- symbol means irrelevant bit value


PACKET TRANSMISSION

A local packet transmission is an optionally bidirectional communication between two devices that can be divided in 3 phases: channel analysis, transmission and optional response. In the channel analysis phase the medium's state is assessed before starting transmission to avoid collision. If the medium is free for use, the transmission phase starts in which the packet is entirely transmitted in network byte order. The receiving device computes the CRC and starts the response phase transmitting an acknowledge (decimal 6) in case of correct data reception. If no acknowledgement is received, after an exponential back-off delay, the transmitter retries until the acknowledgement is received or a maximum number of attempts is reached.

Inside the packet the bits are transmitted LSB first. The length of the packet depends on the header configuration bit. More examples off the different packet configurations can be found on Pjon webpage[https://www.pjon.org/PJON-protocol-specification-v3.2.php Documentation

Dataframe Communication Example - two stm32f103c (blue pill) programmed using the library of Pjon available on Platformio.io using arduino framework under the example of Pjon/ARDUINO/Local/SoftwareBitBang/SendAndRecive/device1 and device2.

alt text

Device 1 has bus address 44 and Device 2 has bus address 45.

The device 1 send the byte "B" to device 2. The device 2 receive the data, and check for the "B" payload, blink a led and then respond sending a message with the same "B" Payload to device 1. The speed mode used is mode 1


Available modes are:

alt text


The protocol is software implemented in the micro controller and the micro controller need to listen actively to be able to catch the communication. In this example the time set for communication listening is 500ms.


Decoder

Work in progress.

Resources