jswalden
commented
4 months ago Further field reporting suggests that this message may, by one camera, in fact be sent not merely at startup, but also either every ten minutes, or after ten minutes of inactivity. I'm still waiting on feedback to determine which case it is.
But either way, merely dealing with startup isn't good enough, so it seems fairly clear we'll have to let the message through the read-return-messages loop and process it as just another return message, if we want these cameras to work as they're going to end up being used.
Some non-PTZOptics cameras send a "Network Change Message",
z0 38 FFwherez = device address + 8, at startup.The purpose of the message is to indicate the "address" of the device for communication if you're communicating with a camera over a RS-232 serial connection, possibly with additional cameras daisy-chained beyond it. Messages identify the target camera in their first byte, e.g.
8x=81for a camera that identifies itself asz=9, and earlier cameras in the chain just forward messages not intended for them to subsequent cameras.But this doesn't have any relevance to VISCA over IP, because the IP address used to connect to the camera uniquely identifies just that one camera. (Sony cameras in fact don't send this message for the VISCA over IP use case, only for serial connections.)
PTZOptics cameras don't send this message. And in fact they don't send anything that matches
z0 xy FFwherex=3(the only classes of messages sent are ACK90 4y FFand Completion90 5y FF). So we can safely just skip the message if we get it, thereby leaving the primary PTZOptics use case unaffected while allowing the module to support some non-PTZOptics cameras (as it has supported some in the past).I got a report on this from the field, as it were, so I plan to get it into a v3.0.2 release as well as in a subsequent v3.1.0 release.