5 ms·
PJON – Padded Jittering Operative Network
- thanksforfish 7y agoHmm, I don't get it. Looks like a way to build your own networks with whatever physical layer you want with a goal of avoiding 3rd parties that may monitor traffic. But what problem is it actually solving? If you can make your own devices and setup your own physical network, this doesn't seem like it adds value over existing approaches, like using encrypted network tunnels. The video shows someone in a far future, automated house who watches a rocket put a satellite into space. Huh? The homepage could probably use some work.
- thanksforfish 7y agoFor me, this page helped it click: https://github.com/gioblu/PJON/blob/master/specification/PJON-protocol-specification-v3.2.md#pjon-v32 https://github.com/gioblu/PJON/blob/master/specification/PJO... If you are an engineer looking to connect devices you built together, this is a cool protocol to consider. Some examples of projects people have built would be helpful to showcase and help show which problems this solves.
- fastball 7y agoI think the idea is that it is a successor to other networking protocols, without "baggage" and various (in the author's opinion) other missteps that make our existing networking stack a bit bloated / inefficient.
- halbritt 7y agoCANBUS is an example of that.
- traverseda 7y agoIt doesn't really have enough throughput to be an alternative to things like ethernet or wifi. It's intended for hooking low-powered embedded devices together, think of it as an alternative to i2c or canbus, not ethernet.
- battery_cowboy 7y agoAgain, I wish that every project would have a single "explain like I'm 5" sentence description to say what it does. For this project, I might say, "An improved networking protocol for bus based devices, similar to i2c or spi, but with wide support for several physical mediums." Would I be correct?
- robbles 7y agoFor people wondering what this is useful for: I've been using this as a protocol for a project connecting a Raspberry Pi to a microcontroller project. Currently I'm prototyping using the serial transport, but at some point I will likely switch to using I2C to accommodate a more minimal interface between the two and allow for more devices to be connected to the RPi. This makes it so that I can swap out out with minimal changes to the code on both sides and keep a standard protocol in place. Also the libraries are pretty easily to use, so it's a little nicer to work with than rolling my own serial framing protocol.