-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
Reading the attached UIST document I see in the sections "limitations" and "future work" some issues PJON could accomplish efficiently. |
Hi, thanks for sharing the protocol. It looks really interesting, and very nice implementation. I will definitely check it out in more details. Some quick questions about PJON: |
Ciao @adementyev thank you again, and I am really pleased by your comments on PJON 👍 The 5.3kB/s is a bottleneck imposed by I sincerely never considered the hardware serial usage and I would not take it for bias 👍 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. |
@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 :) |
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
The text was updated successfully, but these errors were encountered: