Better Handling for same Baudrate for Multiple PDs

[Lunaring]

Currently, the only way we have access to COMSET on the CP side to assign a new baud rate to the PD. However, this is the only way to know that this is even possible.

A possible solution would be to add a new tab in PDCAP called "baud rate," which would then contain, for example, a bit field indicating which baud rates it supports (bit 0 = 9600 baud), etc.

This way, you could easily query all PDs with PDCAP to obtain this information and quickly and easily determine the highest common baud rate, and then set them all to that rate.

[sidcha]

Can you describe your use case a bit please? The way I see it, the CP app at any give time always know the current baud rate of each PD. During setup time, it knows because it set the pd_info struct. Then during run time if the PD's baud rate needs to change that information comes from the app and there is also a comset complete notification to indicate when the PD actually picked up the new setting.

[Lunaring]

OSDP is a protocol that each manufacturer implements in some way.
Certain baud rates might not be possible due to chip limitations.

If a CP iterates through the PD IDs to query information using CMD_ID and CMD_CAP, it receives basic information, but not the possible baud rates.

In my hypothetical scenario, if we had 254 Pds, the CP would set the highest possible baud rate using COMSET (at PD 1, receiving confirmation that it worked). It then goes to PD 2 and does the same, but PD 2 can only use a lower baud rate. This means we have to query PD 1 again to see if it can also use that lower rate. We repeat this process for all PDs. The goal is simply to find a common denominator.

However, if we received a bitmask of the available baud rates from each PD (e.g., via PDCAP), we could process all PDs and then have a matrix indicating the common denominator, which could then be set using COMSET.

(Whether the command "(PD)CAP" returns this value or a command specifically designed for this purpose is irrelevant.)

I hope my description is clearer. It's more about extending OSDP as a protocol, since it wasn't originally intended to be used that way.

[sidcha]

PD Capability is OSDP defined concept, we cannot just hook into this path as there is no existing method to do this. The right way to do this is to build this feature with tooling around it. For example, I'm working on this product that will allow users to emulate a CP/PD development and testing (https://osdp.dev/products/osprio-emulate/). But of of the things it can do trivially is to cycle through all possible baud rates and build an explorator map of the bus. If that's something that might interest you, get in touch with me.