-
Notifications
You must be signed in to change notification settings - Fork 239
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
Communication over TS #384
Comments
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? |
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). |
Hi @gioblu thanks for you reply. So KNX style of communication with TS or TSA is a bad idea? |
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. |
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 |
@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. |
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 |
Ciao @akadlec I would evaluate SoftwareBitBang and see if fits your use case at the edge, and use TCP or UDP in a master. |
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. |
@EternityForest so you are using MCP2515 with PJON? |
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?
The text was updated successfully, but these errors were encountered: