kranenborg
Senior Member
Hello b** and others,
I just learned about this thread and the fact that my SerialPower concept is proposed as a possible solution (but with some challenges to be addressed at the hardware side).
For the discussion here it is maybe indeed good to point out that the SerialPower concept integrates two - fully independent - aspects:
1: The software aspect: A network protocol for regulating messageing between communicating processes (in this case relatively simple since you need only one process per node) with avoidance of message collisions.
2: The hardware aspect: Solution for power and data over two lines.
Regarding the software part I would say that SerialPower would fit very well and would be very easy to program and test for this very interesting and practical app. You can even develop/test/prototype the software on a small scale on the simple diode-mixing network version as discussed in the SerialPower thread regarding the updated SerialPower II code for M2 processors. Next you could switch to the power+dataline version hardware by just switching the "SimpleDiodeMixing" flag in the code. You can use any of the discussed ways to assign an identifier per process/node. In fact SerialPower might be "overkill" in a certain sense since in your application all the nodes have to send only to a single master, so you could use the node identifiers as qualifiers used by the master by the SEROUT command. However, the SerialPower software has all of the communication timing already implemented for a fully distributed system and - most relevant for your system - is much more flexible since the slaves themselves can "choose" an ID (as long as it is unique, of course) as they are roamed for and then registered just after the network has been powered up. Any ID will work as long as it is a byte value between 10 and 254.
Regarding the hardware part I have to remark that I never intended the current hardware solution (either separated or combined data & i/o) to be used on such a scale (or better said, never thought of in detail), and several people here have pointed out the issues. However the suggestion by graynomad today (post #78) to combine the SerialPower software protocol (i.e. point 1) with RS485 (which is an electrical standard only, it does not say anything about the software protocol used, so it addresses points 2 well) is most interesting and would significantly increase the usability and relevance of the whole SerialPower concept. I will therefore definitely try to dive into this issue, hopefully some other members can as well in order to see whether we can find a simple, cheap but also reliable system (In the end it is always the non-functional engineering aspects that create the greatest challenges in realizing a working system)
Thanks for your interest, I'll return asap.
Best regards,
Jurjen
I just learned about this thread and the fact that my SerialPower concept is proposed as a possible solution (but with some challenges to be addressed at the hardware side).
For the discussion here it is maybe indeed good to point out that the SerialPower concept integrates two - fully independent - aspects:
1: The software aspect: A network protocol for regulating messageing between communicating processes (in this case relatively simple since you need only one process per node) with avoidance of message collisions.
2: The hardware aspect: Solution for power and data over two lines.
Regarding the software part I would say that SerialPower would fit very well and would be very easy to program and test for this very interesting and practical app. You can even develop/test/prototype the software on a small scale on the simple diode-mixing network version as discussed in the SerialPower thread regarding the updated SerialPower II code for M2 processors. Next you could switch to the power+dataline version hardware by just switching the "SimpleDiodeMixing" flag in the code. You can use any of the discussed ways to assign an identifier per process/node. In fact SerialPower might be "overkill" in a certain sense since in your application all the nodes have to send only to a single master, so you could use the node identifiers as qualifiers used by the master by the SEROUT command. However, the SerialPower software has all of the communication timing already implemented for a fully distributed system and - most relevant for your system - is much more flexible since the slaves themselves can "choose" an ID (as long as it is unique, of course) as they are roamed for and then registered just after the network has been powered up. Any ID will work as long as it is a byte value between 10 and 254.
Regarding the hardware part I have to remark that I never intended the current hardware solution (either separated or combined data & i/o) to be used on such a scale (or better said, never thought of in detail), and several people here have pointed out the issues. However the suggestion by graynomad today (post #78) to combine the SerialPower software protocol (i.e. point 1) with RS485 (which is an electrical standard only, it does not say anything about the software protocol used, so it addresses points 2 well) is most interesting and would significantly increase the usability and relevance of the whole SerialPower concept. I will therefore definitely try to dive into this issue, hopefully some other members can as well in order to see whether we can find a simple, cheap but also reliable system (In the end it is always the non-functional engineering aspects that create the greatest challenges in realizing a working system)
Thanks for your interest, I'll return asap.
Best regards,
Jurjen
Last edited: