Skip to content
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

Open
akadlec opened this issue Jan 28, 2021 · 10 comments
Open

Communication over TS #384

akadlec opened this issue Jan 28, 2021 · 10 comments
Labels

Comments

@akadlec
Copy link

akadlec commented Jan 28, 2021

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 akadlec changed the title Communication direction over TS Communication over TS Jan 28, 2021
@akadlec
Copy link
Author

akadlec commented Jan 29, 2021

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
Copy link
Owner

gioblu commented Jan 29, 2021

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
Copy link
Author

akadlec commented Jan 29, 2021

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

@gioblu
Copy link
Owner

gioblu commented Jan 29, 2021

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
Copy link
Author

akadlec commented Jan 29, 2021

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
Copy link
Owner

gioblu commented Jan 29, 2021

@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
Copy link
Author

akadlec commented Jan 30, 2021

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
Copy link
Owner

gioblu commented Jan 30, 2021

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
Copy link

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
Copy link
Author

akadlec commented Sep 4, 2021

@EternityForest so you are using MCP2515 with PJON?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants