P200 sluggish PTZ movement with 3.1.0 beta

[BBrazner]

I have three P200 cameras all at 4.5.3418-LTS. Companion BD PTZ module is 3.1.0 (3.1.0+6050-beta-94ccd9ee) on M1 Mac Mini. vMix also controls the cameras for PTZ ops using VISCA IP. The same problem is observed on all three cameras.

With the BD PTZ module enabled, after several days, the P200 camera becomes "sluggish" in response to any p/t/z command, whether from a module button or from a vMix preset: Two behaviors are observed: 1) the camera does not move for several seconds after which it does move to the desired position; and/or 2) the camera does move right away, but at a very slow speed. After rebooting the camera (via the BD web UI), the camera again responds immediately and at the right speed to p/t/z commands.

As a result, I keep the BD PTZ module disabled. When I need to use a BD PTZ module button, I enable the connection, press the needed button, then disable the module. With this mode of operation, there are no p/t/z problems with the camera.

Side question: Is there a VISCA IP command to initiate a camera reboot?

[sydneyjd]

Hello, I'm not sure if this is the same issue, but am noticing a similar(maybe the same) issue upon upgrading from 2.3.1 to 3.0.0. Running Windows 10, and 3 P200 cameras with BirdDog controller. Cameras are running latest Firmware, 5.5.094. Pan/Tilt/Zoom control becomes quite sluggish on both the PTZ controller and Companion when the companion instance is enabled, and gets worse if I have multiple machines running Companion with a Birddog instance pointing back to the cameras. My hunch is a overload of requests from the module, but could be wrong. A fresh instance with no special feedbacks assigned to buttons, and no control buttons added even slow down control from the PTZ controller. Any thoughts or suggestions?

[bryce-seifert]

I'm going to check in with BirdDog and see if they have any answers for this. Seems like their API should be handling the requests, or rate limiting them as needed to maintain device stability.

[BBrazner]

It's possible the camera is throwing a one-time error after which the performance becomes sluggish. However, the error would be virtually impossible to capture in the Companion debug log due to the overwhelming amount of status polling (discussed in #112) saturating the debug log. Perhaps the status polling could be moved to one of the other tabs (e.g., info)? If that were possible, I could leave the debug tab open indefinitely and then any unexpected error would be easy to spot. Also, it would be nice if all the log messages were timestamped.

[sydneyjd]

I have included what Companion is spitting out upon connection to a camera. I was trying to download this repository as a Zip, modify the polling speed using the developer modules path, but it sees the module and just says "unknown, Disabled" in the connection status. Do I need to install a development enviroment or anything custom for that to work?

debug: ---- Initial State for camera info: Connected to birddog-gf2 debug: ---- Connected to birddog-gf2 debug: ----init udp debug: -----Sending VISCA message: 011000050000004a81090400ff debug: -----Sending VISCA message: 011000050000005a81090438ff debug: -----Sending VISCA message: 011000050000005b81090462ff debug: -----Sending VISCA message: 011000050000005c81090447ff debug: -----Sending VISCA message: 011000050000005d81090612ff debug: ----Camera Setup for - P200A4A5 debug: [object Object] debug: ----init webscoket debug: WebSocket connection opened to birddog-gf2 debug: -----Incoming VISCA message: 020100010000000001 debug: Unknown API variable returned from birddogptzsetup: SpeedControl debug: ---- Unknown API variable returned from birddogptzsetup: SpeedControl debug: -----Gain Limit changed debug: Unknown API variable returned from about: GateWay debug: ---- Unknown API variable returned from about: GateWay debug: Unknown API variable returned from about: MCUVersion debug: ---- Unknown API variable returned from about: MCUVersion debug: -----Incoming VISCA message: 011100040000004a905002ff debug: ---- WebSocket received: {"sys_info_perc":"11","dev_mode":"Encode","aud_ch":"2","src_stat":"Streaming NDI","mcu_ver":"26","net_band_perc":"2","avbr":"50Mbps","aud_sr":"48000","dashboard_vid_status":"active","vid_sra":"422","vid_res":"1920x1080","vid_str_name":"CAM","net_speed":"1000mbps","vid_fr":"29.97","aud_stat":"Mute","gen_status":"Not Active","net_mode":"TCP","vid_fmt":"1080i59.94"} debug: -----Incoming VISCA message: 011100040000005a905003ff debug: ---- WebSocket received: {"sys_info_perc":"12"} debug: -----Incoming VISCA message: 011100050000005b905003ffff debug: -----Incoming VISCA message: 011100070000005c9050020d020cff debug: -----Incoming VISCA message: 0111000b0000005d90500f0f09020f0f0c09ff debug: -----Sending VISCA message: 011000050000004a81090400ff debug: -----Sending VISCA message: 011000050000005a81090438ff debug: -----Sending VISCA message: 011000050000005b81090462ff debug: -----Sending VISCA message: 011000050000005c81090447ff debug: -----Sending VISCA message: 011000050000005d81090612ff debug: ----Camera Setup for - P200A4A5

[bryce-seifert]

@sydneyjd You likely need to run yarn to ensure that the node_modules folder and all the dependencies are installed.

I'm still trying to find time to debug this, it's been busy so hopefully in the next couple weeks I can get to it if someone else doesn't first

[sydneyjd]

You were correct. After running yarn in that folder, I was then able to use that with my Companion build. Neat. I also seem to be able to move that plugin folder to other machines without a fuss. I did increase the polling time from 1000ms to 5000ms, and it has helped with responsiveness greatly. It doesn't seem to be a complete fix, as I notice using the joystick controller, any time there is a movement request via the joystick right as Companion polls the camera, the movement request seems to be delayed. Not sure what a happy workaround is, but we are at least operational now. Let me know if I can do any testing as you dig into it more. Thank you for your help!

[truthseeker308]

@sydneyjd For those of use not as skilled in the inner workings of this module, can you explain more in detail what you did with yarn and how you increased the polling time?

I should also add that I get some sluggish response to direction commands on a p200 with latest 5.5 firmware on 3.0.

[sydneyjd]

@truthseeker308 I don't know a ton either, but just pieced this together with troubleshooting and above comments. First, you need to download this repository, either from this Github page, or do a git clone of this repository, then make sure you install yarn on your system/distrobution(I don't recall how I did once upon a time). Then if you open a terminal in the module directory and run yarn, it should install some module dependencies. That should make the plugin usable by Companion, and you can point the companion developer modules path to it. To change that polling interval, line #469 in the file index.js is what you are looking for.

I'm not sure if this is recommended, but I have attached this plugin with changes and dependencies, as it seems to travel between machines without an issue. If this is not recommended let me know and I can remove it. companion-module-birddog-visca(1).zip

[truthseeker308]

@sydneyjd Thank you for the reply. Regarding the index.js, I can see it as part of the github files here, but cannot see it in my windows installation of companion among the birddog ptz plugin.

[BBrazner]

I want to make sure that we haven't lost focus on the original problem for which I opened this ticket which is the sluggish movement of the P200 cameras. In this ticket I'm seeing an "unknown API variable" message posted by @sydneyjd; is this a separate problem which should be moved to it's own issue?

[bryce-seifert]

I still haven’t had time to dig deep into this, but wanted to point out I’ve cleaned up much of the debug logging that was filling up the console in the latest version of the module, available in the newest companion beta.

So if there are errors being thrown related to this, it should be much easier to catch in the console log for the module

[sydneyjd]

Sorry for not following up sooner. Just installed the latest version(3.1.1+6229), and appears to still have the same issue. The debug info is much cleaner, and doesn't appear to have any errors.

system: Connection started Starting up module class: we Sentry disabled Module-host accepted registration info: Detected camera model: P200A4A5 debug: ---- Detected camera model: P200A4A5 info: Connected to birddog-gf2 debug: ---- Connected to birddog-gf2 debug: ----init udp debug: ----init websocket debug: WebSocket connection opened to birddog-gf2 debug: -----Gain Limit changed

[joakyhsf69]

Hello, I have also noticed similar behavior. With the P200 just started, the P/T works normally, even with the companion module open. Right after calling a preset, the movement becomes extremely slow, or even doesn't move at all, but if you touch the zoom or call the home position, the movement returns to normal, until you call another preset again. It does it from the keyboard, the companion, the ndi studio monitor, that's why I thought it was a problem with the camera's firmware, that's why I opened a ticket with birddog support, I don't know what they will answer me, or if it is a bug known .

[bryce-seifert]

@joakyhsf69 Did you hear anything regarding your support ticket?

[joakyhsf69]

Yes @bryce-seifert , it is a known bug, they even sent me a beta version of the firmware, version “109” but that still had the same problem. They told me they would keep me informed if they fix it in an upcoming version.

[BBrazner]

@joakyhsf69, how does BD state the bug?

[joakyhsf69]

I don’t know, this is the last thing the technical service told me:

“Hi Joaquin,

I spoke with my team about this and I was unaware that this is actually still a known issue even on version 109. I apologize for not catching that earlier.

We do have an issue open with our engineering team, so this will be slated to get fixed in a future release. We have a list of tickets that we update once these fixes go live. If you would like to be added to that list let me know and I'll explain what that process looks like.

Let me know what questions you have, and sorry again for this issue and that it took me this long to find out it is known and being worked on.”

[BBrazner]

Thanks, @joakyhsf69. It would be nice if we had BD's description of the issue other than "we're aware of it and we thought we fixed it but apparently we didn't"). Please continue to post if you find out anything.

[KimP78]

I seem to be having the same/similar issue with my system. I have 4 x P200s on FW 5.5.112 and am using Companion V3.2.2 and am experiencing a lot of lag or commands not being carried out. From the same device, I can control with no lag using NDI Studio controls and the webGUI controls, and I can also use the BD PTZ keyboard with no lag. It all goes through a Netgear M4250 switch on a data VLAN, and I have experimented with changing the prole to NDI5 or Video, neither of which help the situation which makes me think it is more to do with Companion or the BD software. I have also tried V5.5.114 but that broke it even more, so I rolled back. I can't see any debug messages in the companion log tab, not sure if I am looking in the right place. Any ideas?