PJON, pronounced like the iridescent sky rats found in every city, is a cool one wire protocol designed by [gioblu].
[gioblu] wasn’t impressed with the complications of I2C. He thought one-wire was too proprietary, too complicated, and its Arduino implementations did not impress. What he really wanted was a protocol that could deal with a ton of noise and a weak signal in his home automation project with the smallest amount of wiring possible.
That’s where is his, “Padded Jittering Operative Network,” comes in. It can support up to 255 Arduinos on one bus and its error handling is apparently good enough that you can hold an Arudino in one hand and see the signals transmitted through your body on the other. The fact that a ground and a signal wire is all you need to run a bus supporting 255 devices and they’ll play nice is pretty cool, even if the bandwidth isn’t the most extreme.
Aside from the cool of DIY protocols. We really enjoyed reading the wiki describing it. Some of the proposed uses was running your home automation through your ducting or water pipes (which should be possible if you’re really good at isolating your grounds). Either way, the protocol is neat and looks fun to use. Or check out PJON_ASK if you want to do away with that pesky single wire.
Is he one of Massimo Bonzi’s guys? There’s no proof that this actually works 50 ft with 255 devices. Bullshit.
LOL :)
https://github.com/gioblu/OSPREY/blob/master/OSPREY.h
// General constants
#define MAX_BUSES 10
#define MAX_HOPS 10
#define MAX_KNOWN_BUSES 10
#define MAX_PACKAGE_LENGTH 50
#define MAX_PACKAGES 10
#define MAX_ROUTERS 10
#define MAX_DEVICES 10
#define ROUTER_INFO_TIME 15000000 // 15 seconds
– Yes 255 devices in a PJON bus may not work nominally (we still didn’t find the limit with dozens).
– I personally tested with a 50 meters copper wire and was working fine with few
I personally had a work offer from Massimo in the far 2011 but I refused.
Live a happy life.
Gio.
I read through the protocol specification, and I’m not sure I understand how collisions are dealt with. If two nodes start transmitting at the same time, presumably either the receiver ID will be corrupt or the checksum will be bad, so both transmitting nodes would either time out or receive a NACK from a receiver. They will both back off the same amount of time and then transmit again, colliding again and again. Once synchronized, I don’t see how they could recover except through dumb luck (oscillator drift, asymmetrical code behavior) It would be interesting to experiment with a bunch of transmitters running at a non-trivial amount of bus utilization.
Another interesting thing from looking at the code is that transmitters both push and pull the bus when transmitting. If one transmitter drives 0 and another drives 1, you end up with two drivers fighting each other. I guess if it’s a short enough timespan or the wires are high enough resistance you won’t cause damage. It would be interesting to rig up two transmitters running in the worst case, one sending all 0x00 bytes and the other sending all 0xff bytes over a short wire.
i havent read the documentation yet. dont worry, i will, but i the delays are implemented without a RTC, they WILL be different on each arduino due to clock speed diferences.
*shrug* the CPUs crystal oscillators probably won’t drift much apart over the timespan of even the max retry delay. Also, since every node aupposedly synchronizes to every byte received on the wire, any NACKs will reset the drift. :-)
No kidding, there is a reason most of these simple protocols use pullup resistors. To use this code as-is I’d definitely recommend a series resistor of a few hundred ohms.
Aside from the previously-mentioned collision issues, what’s the maximum practical transmission speed? I poked about a bit but couldn’t find it (and don’t have time right now to wire up a sample net. :)
The Github page claims:
Performance
Transfer speed: 42372Bd or 5.29kB/s
Data throughput: 2.68kB/s
Accuracy: 99.995%
Oops. I was reading the wiki, and thus completely missed that, thanks.
I’m curious to see what more knowledgable people think of the design. The speed is slower than I would like, but I have to give the guy props for putting it together. Might have to look into it some time soon. :)
The licence says you must include attribution, cool credit where deserved, and you can’t use the name to endorse or promote your product without prior permission.
Together this means to me that all uses of this library, or the standard, that are not for private use, must be approved by the authors to avoid breaking the license. Is this correct or am I missing something?
– All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes PJON software developed by Giovanni Blu Mitolo.
– Neither the name of PJON, PJON_ASK nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
You just can’t say “Now PJON compatible” as a feature point for promotion. You can consider it as an unofficial trademark. No where it say you can’t use it and give it credit.
Hi there I am Giovanni the creator of PJON I never considered this side. Probably should be better to give freedom to people and businesses to do that. Which license form you suggest?
That really depends on how you want it used, but the Creative Commons Attribution Share-Alike licence would be my pick.
“Why not 1-Wire?
1-Wire is almost what I needed for a lot of projects but has its downsides: it is propietary, in my opinion is over-engineered and Arduino implementations are slow, chaotic and not reliable.”
Chaotic? That standard is perhaps older than author of this words.
Why not LIN?
Why not RS-485?
Why not CAN?
Because he can? It doesn’t hurt to try it and see if it beats out the competition, and if anything it’ll just be a fun learning experience. Think about it like this: the designers of those protocols you listed probably got similar heat from people in their industry when they contemplated designing those “new” protocols. If they had let that criticism stop them, do you think we’d have those protocols to reference right now?
If you want to really do everyone some service, test PJON against those above 3 protocols, and create a list of advantages and disadvantages of each. That way we’ll all have a useful reference when deciding on which of these protocols one should implement for a specific project.
“It doesn’t hurt to try it and see if it beats out the competition”
If You have proper knowledge in that area, You won’t try “invent” new one.
I’ve had specially asked about LIN,RS485 and CAN – in that order.
Do not invent PJON…just learn LIN.
CAN is especially interesting – everyone with IT education should learn how collisions can be avoided.
But it costs too much (in many aspects) and that’s why LIN was designed
Haha, no. It’s on the author to convince us that the new protocol is better in any way, form or shape. He presumably has done his research already before deciding to start over.
I might have missed it, but I’d like to see a state transition diagram.
Came here for this, why not LIN?
I spent way too long trying to figure out what an iridescent sky rat was :-P
… you might also want to spend some time on this other rat :)
http://www.fimfiction.net/story/248095/the-iridescent-iron-rat
How about a hint? I no idea what “pee-john” refers to.
Someone check me on this but that ‘character’ format is just a funny twist on standard async serial with a start bit and stop bit.
Hi there, I am Giovanni, creator of PJON. I am sorry not to have answered before but only now I saw 700 visitors to the repo in an hour. How much people is looking this website?? O_O Thanks for the publication.
In any case
– Delay to avoid infinite collision is missing, we are near to the release of the 2.0 version that includes this fix.
– Yes probably with 255 devices a PJON bus would not work nominally (we still didn’t find the limit with dozen of boards).
– I personally tested extensively with a wire of 50 meters copper wire and was working fine with few devices.
– If you have some suggestions for license modification / alteration we are open to bring it as confortable as possible to makers and businesses to use PJON happily and for free.
If you want to know the story, I am not a Massimo Bonzi guys. I have created my startup in the far 2010 http://www.gioblu.com I was simply sharing my builds and people of the arduino forum started asking to produce my components also for them. Also Massimo came to my place offering me to “Close my business and become his fellow” but I answered that I wanted to continue experimenting by my own and I perceived his position a little ambiguos. History demonstrated that my presentiment was correct. I am now free from my second startup dedicating time to PJON, because I feel is something important I have to bring forward for me and for the community.
Happy tinkering :)
While I don’t have the attention span nor the experience to read through the repo and do my own tests of the protocol, I respect you coming over to HaD to help answer questions and clear up any misconceptions that we clearly have. Regardless of whether your protocol works well or not, or can fit a niche, good on you for putting in the time and effort to develop something like this. And please, ignore the people who just complain and cry and say “stop reinventing the wheel, XYZ protocol does this already.” Sure, maybe there are other protocols out there that work similarly or even better, however innovation never comes from attitudes like those. You have my respect, for whatever that may be worth :D
I think you did good work, but maybe the time would have been better spent to adapt LIN to a 5V network, instead of the 12V automotive. I know I wanted to do that…but then made my home automation with radio.
From my experience, I want to warn you to be cautious: a few devices on a long line does not mean more than a few will work. Did you take into account how much degradation of signal there will be when you have 200 inputs? Capacitive load? Are they also drawing power from that ground wire? Will there be peaks? How thick should the bus cables be, does that not make them expensive? How much drop do you accept on the cable?
These are all things that LIN has answers to …
how about “nooooooooo”
Seriously, the world really does not need Yet Another Half-Baked Slow Wire Protocol From Someone Who Doesn’t Understand What Went Before. You don’t like the 1Wire implementations? Make a better one. Or use CAN. Just… not this.
Putting “standard” in the first paragraph of the wiki describing your github hackjob does not make it a standard. That’s not what it means. That’s not what ANY of this means.
Jesus, I’m going to go and cry in my beer now.
Hi I am Giovanni the creator of PJON.
Arduino appeared as an opensource standard to ease the approach to embedded systems.
It comes with its quirks, limitations and absurds as every framework / standard.
PJON as a framework / standard comes for sure with its limitations also because is only an early release (1.1), but is the result of 6 years of tests and experiments, of me and a lot of other people involved and contains a lot of experience, and information. I tried to bring it as clear and as commented as possible to be a valid piece to have a clear and maybe not too technical sight to digital communication, also for who wants to learn something.
I am sorry if this made you so unhappy and I am sorry if for you and a lot of people, a Standard is good only if comes out of big corporation, military contractor or institution. Look and feel the results of this mindset around you. Also if anyone will use PJON your life will still be fool of buffer overflow and monstruosities occurred because of the “serious stuff” you trust in.
Don’t mind the sourpuss, Hackaday tends to attract those kinds of people who whine and rage about something for no good reason.
I am the perfect fish for trolls, but its normal I am Italian.
Thanks for the work Giovanni:)
I wonder if it’s a bit of a terminology ambiguity. I would consider your document to be a protocol specification. A “standard” usually implies a regulatory process exists to ensure interoperability. That might explain some folks’ agitation.
Protocol wise, since you are bit banging it anyway, you could consider implementing some form of bit level arbitration scheme so that a message still goes through on a collision. Regardless of “fairness”, an arbitrary message transferring successfully is strictly better than writing messages of gibberish.
We really should stop eating our own. A criticism is best served with critique. A criticism is easy to make, while a good critique takes time and skill to craft.
+1
I came to realize that stepping all over your peers doesn’t get you anywhere but to the top of a pile of angry people and no friends left to share it with. I’m all for trying out new protocols, and everyone likes options. Let’s just work to prevent fragmentation, and giving suggestions, rather than verbal assaults. This guy isn’t reinventing the wheel. He’s taking the wheel and putting some tread on it.
I also agree with this. And I think sometimes the purpose in doing projects like these are more about the process of learning than anything else. I’ve done things like write my own SPI library and write a basic database / archiving program from scratch. Are they as efficient, resilient or feature-rich as other available options? Probably not. But my problem-solving and programming skills were tested along the way and that was reason I did it. I’ve gained so much more in practical knowledge by taking the difficult approach to solving a problem.
I see so many clock and “3D printer from scrap” builds, but far less people shrieking, “That’s already been done before1!!!1!~!” What if they are just doing these things to learn? As an exercise? Why is sharing what you know so far a bad thing?
Sometimes it’s necessary to “reinvent” things, so that you’re equipped with the understanding to make other things, and even make them better. I like the comments actually giving him intelligent suggestions he may not have been aware of to build on his project, rather than those choosing to be a living steaming kettle. Even explaining the benefits of another protocol you think is better in comparisoin would be reasonable, too.
Someone proudly sharing their work on a subject that interest them will never hope to be even remotely as cancerous as the dull droning whine of a HaD comment-section’s fussy ‘donebefore’ plebeian.
Well said Gerrit. Personally i think this project is awesome – Ive struggled with XBee+ZigBee and meshbee and others for past 3 years as a hobby. All these protocols generally have a place for the right scenario. PJON appears to me (Ive not tested it yet) to be suitable for large numbers of arduino devices in a closed area – think home automation or a raft of different sensors inside a tank.
As for those that say why not xyz some quick reading up on wikipedia would have self answered that:
LIN – limited to 16 devices …. PJON limitation is 255 on one bus….and unlimited buses . It also is master-slave while PJON is simply a protocol that allows communications so it should be possible even to develop a mesh using PJON as the protocol (I will leave it to brighter minds to do that…..i know my own limitations).
CAN – patent royalties payable to Bosch for every deployment. Need i go further?
I2C – i have used this with different types of sensors and it works. But if you need to have a library where you have all the source (goodness me maybe open source?! shock horror) then you have no choice but to create one.
Kudos to the author. Great job for the purpose for which intended. I can see this being especially useful in wired and wireless implementations for connecting multiple arduino based gadgets and sensor.
The mathematics and statistics of bussed serial information systems are well known. What defines your choice of system functional specification is the system requirement specification, and money. I see none of this prerequisite work presented by the Author before coding was done. Therefore, I declare this “new” protocol to be notional, rather than rigorously designed. Truly an example of “Making” vs. “Engineering”.
Engineers were makers once. One does not become an engineer without the drive to make. Give it a chance to simmer, improvements will come. I agree with you, that this probably isn’t the best option for commercial setups. However that being said, this is fairly new. It didn’t come from a large corporation, it came from a lone developer. Don’t beat the guy up for dancing different at the party. Everyone standing aside and watching will pass criticism, while the other dancers might learn a few new moves from this guy.
I did something similar a few years back although not quite as good as this.
I basically just used Morse code. It was way too fast to read by ear but not nearly as fast as I2C.
It worked very well and supported a lot of devices on the bus.
I made a small device that I could clip onto the signal wire that would read the super-fast Morse
and then play it back as audio at about 25wpm so I could troubleshoot by ear…handy!
I only needed something of modest speed and I just adore Morse so I said “Why the F not!?”
Nice work Giovanni. You are a true hacker (trying to do something – group 1), not just a talker (just complaining about stuff group 1 did).
Hi Gio.
I think about PJON, and can be a rough & efficient 1-wire bus when I use instrumentation cable(paired), adjust dry-resistances in non parasitic mode and solve the collisions conflict. In advance I forked your repositories and make it new test versions for raspberry-pi in future.
Regards from Tarragona(Spain)
Santiago Frias
Ciao Santiago! Quite interesting, if you want to share your idea feel free to open an issue in the repo.
Ok, man. :-)
I feel I have seen a similar use of a i.c years ago, although it worked on a DC rail with 1 of 8 switches created a frequency superimposed on the DC rail. a receiving i.c monitored the signal from the DC rail giving a suitable output, the i.c could be
serial to a second i.c this would be 25-30 years ago the company was German possibly Telefunken. If you class a 1 wire system this would be the forerunner. there may be traces of copyright in the technique, I also remember the clock used 1 cap and 1 resistor and resistor or resistor connecting to the +ve rail