gioblu / PJON

PJON (Padded Jittering Operative Network) is an experimental, arduino-compatible, multi-master, multi-media network protocol.
Other
2.73k stars 239 forks source link

Communication over TS #384

Open akadlec opened 3 years ago

akadlec commented 3 years ago

Hi @gioblu i have a question on you :)

Right now I have system with one master and n slaves. Communication is controlled by master. Master is iterating through known slaves and asking them for data and slaves reply back with data, or in case slave is actor, master is sending commands and slaves reply with acknowledging

But I think this communication is not ideal. So I think about something similar to KNX, slaves will send packets when they have something to send (sensors) to master. And also master will control actors only when needed. But in this type od communication would be collision if more slaves or slave and master try to communicate at same time. What do you think?

akadlec commented 3 years ago

Maybe my question a bit chaotic :D

Right now I'm using TSA with sync ack. Master is pooling every single slave and reading their registers, similar to Modbus. Each slave have to reply to master request with data. But in real world, almost all slaves will be idling.

So I'm thinking about changing this scenario. Each slave could send their data if had something to transmit. But how to solve communication collision? PJON_BUSY is the solution? When slave try to send packet and PJON return PJON_BUSY that mean that bus is in use, right? So collision is solved by PJON already?

gioblu commented 3 years ago

Ciao @akadlec I suggest you to remove the sync ack if the slave must respond when the master asks (the response is already an acknowledge). Avoid multi-master mode (or letting the slave transmit arbitrarily) TSA does not work well in this configuration (there is no way to avoid collisions).

akadlec commented 3 years ago

Hi @gioblu thanks for you reply. So KNX style of communication with TS or TSA is a bad idea?

gioblu commented 3 years ago

Yes, the ThroughSerial or ThroughSerialAsync strategies do not support multi-master, other strategies can be used applying this approach, for example SoftwareBitBang, AnalogSampling, EthernetTCP, DualUDP, LocalUDP and GlobalUDP.

akadlec commented 3 years ago

Hmm right now I'm locked to use TS or TSA in v12. So there is no way how to detect by slave if bus is ready? I'm thinking about mixed version, where master will pool data from nodes in defined interval, lets say 10s, which is ok for regular sensors like tem, humidity etc., but also give slaves ability to send messages to master when needed, to notify master, something happen for example push button sending click, dbl click, etc. events

gioblu commented 3 years ago

@akadlec yes you can do so if arbitrary transmissions are rare, collisions may arise but PJON will re-transmit if that happens, so the packet should be delivered as expected. Although it would for sure be more reliable if using one of the strategies that fully support multi-master mode.

akadlec commented 3 years ago

Hmm....so in that case, I'm thinking about creating another device which will act as a proxy between PJON devices and RPi master. Because right now I'm locked into V12 and only TS/TSA or UDP via PJON_cython

gioblu commented 3 years ago

Ciao @akadlec I would evaluate SoftwareBitBang and see if fits your use case at the edge, and use TCP or UDP in a master.

EternityForest commented 3 years ago

CAN Transcievers cost just over a dollar in singles and will happily carry UART data(I've done lighting control like this). you can instantly detect any collision this way, because CAN is designed with dominant and recessive states specifically for this purpose. What if you made TS listen while transmitting, and fail and retry later if you ever saw anything other than what you just sent?

The same effect can be achieved with just a diode, you can turn the TX pin into an open collector output and use a pull-up. This would greatly increase the efficiency with random access transmissions and should be simple to implement.

It would also, so far as I know, be completely backwards compatible with TS as it is.

akadlec commented 3 years ago

@EternityForest so you are using MCP2515 with PJON?