Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why not PJON? #1

Open
gioblu opened this issue Feb 29, 2016 · 4 comments
Open

Why not PJON? #1

gioblu opened this issue Feb 29, 2016 · 4 comments

Comments

@gioblu
Copy link

gioblu commented Feb 29, 2016

Hi there, I really liked your project and how you engineered it. Maybe my opinion could be a little biased because I am the main developer, but, I think you should consider PJON as an alternative to i2c. Good luck with SensorTape.
https://github.com/gioblu/PJON

@gioblu
Copy link
Author

gioblu commented Feb 29, 2016

Reading the attached UIST document I see in the sections "limitations" and "future work" some issues PJON could accomplish efficiently.

@adementyev
Copy link
Member

Hi, thanks for sharing the protocol. It looks really interesting, and very nice implementation. I will definitely check it out in more details.
I looked at 1-wire and few other protocols, and there wasn't any good alternatives to I2C at the time.
I am currently trying to use serial over RS-485, it can be pretty fast with 0.5Mb/sec and 256 slaves with 8MHz clock.

Some quick questions about PJON:
What limits the speed to 5.3 kbit/sec? Could you use serial module to speed it up, instead of doing in software?
Is 254 devices a physical limit? Realistically they might add capacitance and impedance to the bus, thus limiting number of devices to a smaller number

@gioblu
Copy link
Author

gioblu commented Mar 1, 2016

Ciao @adementyev thank you again, and I am really pleased by your comments on PJON 👍

The 5.3kB/s is a bottleneck imposed by micros() resolution (4 microseconds, crap) infact for me is astonishing to see it working so precisely at these speeds.

I sincerely never considered the hardware serial usage and I would not take it for bias 👍
Could you explain me in more detail what you imagine?

Because of the not enormous communication speed and the initial padding bits or sync procedure it is really resilient in tough conditions and capacitance effect is mild, I tried with up to 30 devices and it works flawlessly and many other users have similar results. Consider that PJON works flawlessly using a human body as a conductor passing from the left hand to the right one with a really small effect in its reliability!!

I will also add in 1.2 tri-state logic to completely exclude from the circuit all devices are not actively or passively using it, to further reduce the average capacitance on the bus.

Thank you again and compliments for your build.

@gioblu
Copy link
Author

gioblu commented Mar 1, 2016

@adementyev Serial over RS485 is really a reliable and professional choice, for sure. And is what in general I suggest for many applications, but, I think RS485 has a little old concept and its bias for reliability in some way limits its use in a real multimaster plug&use environment (a master collission could physically blow up a driver). PJON in some way is an attempt to fill this gap.

What I mean is that could be interesting to cut a piece of your tape and let it work indipendently as a single entity or temporarily join it to another one to higher the new entity's capability. On the other side could be nice to physically build a network of buses (tape sections) in every possible configuration using packet routing with plug and use capability.

But maybe I am now simply describing how I would personally play with this product :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants