It occurs to me that having a feature the user could turn on to cause the openspot to do a UDP broadcast on a known port (or user selectable port) at the beginning and end of each contact with some basic information (talk group, source dmr id, etc for DMR, and appropriately known information for the other modes as well). Perhaps as an advanced feature.
Polling status.cgi more than once a second can be problematic. Having more than one client device polling status.cgi will just increase the load on the openspot. A UDP "fire and forget" broadcast packet as each contact starts, and another as they finish, would be a very lightweight way of scaling to multiple client display devices without increasing the load on the openspot significantly. A user could develop a lightweight device (based on arduino or pi for example) with a smallish screen that could listen on the network for these broadcasts and lookup the contact details via its own internal database, or even do a network lookup (qrz for example?).
1 post • Page 1 of 1