Show HN: PJON – Open-source Arduino multimaster communications bus system
github.com
github.com
Secondly, is there a way to passively power an Arduino and potentially layer your PJON over it? I actually have an application where I have 2 wires between two point, power (mains) at one side, yet I need to transfer the state of two switches from the powered point to the other side. (it's a switch for an electric curtain that normally needs 3 wires to operate but I have only two). Any way I can use this for that?
Actually passive power on the same communication wire as 1-Wire has actually is not part of the functionalities of PJON, could be developed and is something I am considering to add in future.
Not picking on you, I'm just saying that this is a very confusing item for an electronics amateur like myself. Modbus is the same - many manufactures claim 'works with two wires' but then leave out that you need a ground, so that in pretty much every real-world application you end up running three wires.
So as a constructive feedback, I'd like to suggest that you either make the term very explicit or talk about '2 wire' instead of '1 wire' (I realize that that makes it harder to 'compete' against 1-Wire (which also needs two wires...) before people who don't really understand what's involved, but I think that that price is paid back by the goodwill you get from being 'honest', because 'dishonesty' is what it often feels like when people claim 'one wire' systems that turn out to require two wires, even if for an EE it's obvious what is meant by 'one wire')
* How easy is mixing 3.3V & 5V? * Can I always program the address of a slave? (If not, how do you resolve address clashes?) * Can slaves initiate communication?
etc.
To have it working with mixed 3v3 5v you have to choose main channel voltage and consequently use converter modules.
There is not an autonomous packet id assigner, is the user inside the program code to assign which board has which id
Your signal timing is 20 microseconds which equals a signal rate of 50000 baud, or 50 kBd.
There are 12 signals in each frame holding one byte. So the byte rate is 50000/12 = 4.2kB/s.
"Channel bandwidth may be confused with useful data throughput...":
What does "accuracy" mean here? Successful transmission rate?
This error obviously is detected with CRC, data trashed and NAK sent to inform transmitter of uncorrect packet reception (all in background)
I think the first step on ATtiny compatibility can be ATtiny85 with a decent port on wiring. (I think will work also without external oscillator using only internal PPL clock tuned to 16mhz).
I am thinking to open a wiki defining the standard to enable people like you to build easily an implementation for a still not compatible device.
Why don't you open an issue on github and we will all speak together there :)?
I think can work at standard speed on Attiny at 16 mhz.
If with two wires you mean Serial or i2c: - Serial has only a physical layer and there is no acknowledge or check if the message correctly arrived to the receiver. Infact you can see in the arduino serial monitor junk arriving as first characters, before the connection starts to be stable. With Serial you can connect only 2 devices one to the other. - i2c is a product of Philips and is closed source. Its range is limited and is mainly engineered to connect integrated circuits together on the same board, so is not the right choice for home automation applications, or automotive.
PJON is a system that let you connect up to 255 arduino boards together and has a packet manager that handles all the packet sending and retrasmissions. It is also able to detect network errors, and ask for resend. Every Arduino has an ID and can be contacted from another device in the network.
Speaking about wireless you can find in my github profile ASK_Slang that is a old version of PJON ported to work with a Radio 433Mhz physical layer, using cheap 3 dollars TX RX 433Mhz pair: https://github.com/gioblu/ASK_Slang ASK_Slang is in early beta, I am still working on it :)
I know I am pretty negative but to me once you reach this level of complexity in your applications it is time to move on to microcontrollers with proper networking capabilites such as CAN, Ethernet, etc.
For sure for me was a project oriented to have the knowledge on how a communications bus system is built and which problems an engineer faces writing a new one. After this process, using and testing it I obtained great results in my home automation application and I would be happy if the community eill start to use it.
- Accuracy is the ratio between packets correctly received and packets received with an error expressed in percentage.
- I tried physically with a 50 meters long copper wire.
"Because both ends of the RS-232 circuit depend on the ground pin being zero volts, problems will occur when connecting machinery and computers where the voltage between the ground pin on one end, and the ground pin on the other is not zero. This may also cause a hazardous ground loop. Use of a common ground limits RS-232 to applications with relatively short cables. If the two devices are far enough apart or on separate power systems, the local ground connections at either end of the cable will have differing voltages; this difference will reduce the noise margin of the signals. Balanced, differential, serial connections such as USB, RS-422 and RS-485 can tolerate larger ground voltage differences because of the differential signaling.", cited from:
This looks very interesting as a 'simple' communications protocol, and it would be great to have one available for simple multi-master applications. This one is very close, most of the major things are there.
I think you should look at some things from other common protocols to increase the robustness. Especially CAN (especially single-wire CAN J2411), RS-485 multi-master, and 1-Wire. Here are some thoughts:
- Increased Synchronization / Sampling: Async serial protocols usually sample at 16x the bit rate to determine the sampling point (CAN is 8x?.) You should increase the number of samples taken during synchronization. Clocks nowadays are much better than they were, especially using a crystal oscillator all the time, but you should still try communication +/- a few percent and make sure it is still robust. Look at this article for more information: https://www.maximintegrated.com/en/app-notes/index.mvp/id/21...
Also, a some implementations will 'vote' on the majority value before determining the 0 or 1, i.e. sample 8 times during the bit and return the majority value. This helps with noise resistance.
- Use of timers and interrupt-on-change: This one might turn out to be a lot of work, but it would be nice to see an implementation that uses the timers and GPIO interrupts instead of using delayMicroseconds(). This will give you much better timing accuracy for sending and receiving, and frees up the processor to run an OS or other code in the background without having time taken out to watch the network and spin in delays. Also it doesn't necessarily ruin the timing when other interrupts are running at the same time. I have not done a lot of Arduino work though so I don't know how closely this would fit into the ecosystem... can you configure the timer/interrupt priority to use? Do all pins support interrupt-on-change?
- Better CRC/checksum: XOR CRC is not the best, as it is not as resistant to multiple bit errors. There are good, free algorithms for CRC checking. Look into pycrc which writes all the C code for you. https://pycrc.org
- Physical layer: add a small capacitor to simulate a long bus or many connected nodes. Simulate some bus faults. You should definitely look into getting an oscilloscope for this one, it can be very illuminating. Can you detect faults, by reading from the input while driving, to make sure the line is really what you want it to be? I'm not very familiar with AVRs but I know PICs could do it.
- Some way of auto-addressing: it is a pain to address things on the bus manually, to reprogram devices every time you want to add some more. Look into some sort of addressing scheme (similar to how 1-Wire handles addressing.) Maybe just a 64-bit random identifier and some sort of bus enumeration? Especially since there is no way to detect address collisions on the bus.
- At least wait 10 bit-times of zeros before returning with no collisions, since you can send 9 zeros normally (10 00000000)
- Timer and interrupts are not used to ease the compatibility with Arduino compatible devices and to reduce the amount of code needed to let them work altogether with the same codebase.
- A better CRC is a good suggestion, but consumes bandwidth if you suggest a more then one byte implementation.
- I am now testing this protocol with a category 5 lan based wiring 35 meters long in star configuration (with many branches of different length)
- For sure waiting 10 bits is right, this is for sure a valuable suggestion!!! Why don't you open an issue related to this on github repo!?