Firmware suggestions for PTZ/Focus controls

Steven Kan

I did some snooping of the http traffic from the client to the camera, and I now understand why manual focus is nearly unusable. Here's what the web client sends when you depress Focus In, e.g. a MouseDown() event:

[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"FocusInc","speed":32}}]

and when you release the mouse button, e.g. a MouseUp() event:

[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"Stop"}}]

The focus motor doesn't increment to a numerical position or by a numerical amount; it goes forward (or backward) until it's explicitly told to Stop, and timing of the Stop is based on a MouseUp() event in the browser. With the inherent latency in the video preview and the high latency of controlling this over the internet, accurate focusing based on visual feedback is virtually impossible.

I've also observed that changing the Speed value in the slider has no apparent effect on Focus and Zoom. The commands appears to change, but the Focus and Zoom motors appear to move just as fast at "speed":1 as they do at "speed":32.

So here's my proposed solution, which should be doable in software:

Interpret the Speed slider as a duration instead of as a speed indicator

Accept mouse clicks as discrete events instead of using MouseDown() and MouseUp()

Set a timer of X milliseconds, based on a factor of the Speed slider value

Run the selected motor for X milliseconds and then Stop, on each click of the mouse

It wouldn't be as good as a true numerically encoded position, but it would far, far better than what we have now. We'd be able to slowly increment the zoom or focus in or out, until we can visually verify the results we want, and it wouldn't be subject to the latency of the viewer or the connection.

In fact I might even try this from a .js application and see how well it works, since it can be done purely on the client side.

Steven Kan

So this sorta works and sorta doesn't. I have two bash scripts set up. The first gets a token, so that I can authenticate commands for the next hour:

#!/bin/bash

ReolinkToken='curl -s GET "http://192.168.1.11/cgi-bin/api.cgi?cmd=Login&token=null" -d '[{"cmd":"Login","action":0,"param":{"User":{"userName":"admin","password":"MyActualPassword"}}}]' | jq -r '.[].value.Token.name''

echo $ReolinkToken

[if you attempt to copy/paste that into a real bash script, it will fail until you replace the single quotes ' around the curl command with other kind of quote character, `

I can't paste that into the forum, because it screws up the formatting]

This will return a token like "411d80b6c8c4dd0"

Then I have another script that accepts a token, a command, and a pause value in seconds:

#!/bin/bash

ReolinkToken=$1
Cmd=$2
Pause=$3

curl -s POST "http://192.168.1.11/cgi-bin/api.cgi?cmd=PtzCtrl&token=$ReolinkToken" -d '[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"'$Cmd'","speed":32}}]'

sleep $Pause

curl -s POST "http://192.168.1.11/cgi-bin/api.cgi?cmd=PtzCtrl&token=$ReolinkToken" -d '[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"Stop"}}]'

So if I execute:

./CommandPauseStop.sh 411d80b6c8c4dd0 ZoomDec 0.1

it will command the camera to Zoom Out, pause 0.1 seconds, and then Stop the camera.

It works for ZoomDec and ZoomInc, with pause intervals as short as 0.1. After each zoom event the camera autofocuses, and I have no control over that. But it appears to work properly.

FocusInc and FocusDec don't seem to work as well. Sometimes the commands appears to work, and sometimes they appear to do nothing, although I always get a rspCode of 200, which is "success".

FocusInc/Dec appears to work more reliably with a longer pause duration, but then that makes them less useful, since I have less granular control. It's possible that it takes a fraction of a second for the focus motor to start moving, so the Stop command comes in before it's actually done anything.

I'm still experimenting with this. But if the focus motor does have some latency and/or hysteresis, then this approach might require a firmware change, so that the timer runs internally to the camera instead of just on the client. If the focus motor latency is highly variable and the firmware has no way to detect whether it's actually moving or not, then it's possible that none of this might work. But I doubt that, because the firmware is capable of starting and stopping the focus motor quickly during autofocus, so somewhere inside its tiny brain it's capable of controlling it in small steps. We just need to be able to figure out how to tap into that control from the outside world.

Carl

Hi Steven Kan, thanks for your testing and sorry for the inconvenience. Could you please take a screenshot of the System Information tab and send it to support team to check? Also, you may tell then more details about your issues and they'll help you soon. Refer to https://support.reolink.com/hc/en-us/requests/new.

Steven Kan

Attached.

There really isn't an issue with my unit; it's just a general observation on all of your zoom cameras. They don't store focus points, and I was trying to figure out why.

Because they can't store focus, they rely on autofocus or manual focus, and manual focus has proven itself to be very difficult to use over high latency links, and I was trying to figure out why.
RLC-423_SystemInfo.png

bon bon

This post is deleted!

Mitku

In my view considering the lag, the better fix for manual focusing would be to consider every mouse click as a single command to move the focus with a single “step” in the desired direction.
No matter how long is mouse clicked down and no matter when it’s released.
And this will need a slider or numeric input cell to set the said “step” length.
Or the “step” could have only some default value and thus to be not user changeable if the next additional buttons are added.
So could be implemented additional buttons for let’s say 5x“step” for faster rough closing the desired position or even “step”/5 buttons for fine tuning. Or of course some other than 5 value of the multiplier/divider after testing. 5 is just for instance.

Pros: This way the time and lag or network issues wouldn’t matter at all.
And the accuracy will depend only to the “step” length and eventually the multiplier/divider.

Cons: The downside would be to require many clicks to actually reach the desired position.
And with shorter “step” for better accuracy the clicks could be quite a few let’s say.
And eventually would be needed these additional buttons for rough and fine tuning.

Cynthia

Hi,if there is any assistance need please feel free to send your request to support@reolink.com they will help you out, thank you!

Cynthia

Hi,if there is any assistance need please feel free to send your request to support@reolink.com they will help you out, thank you!

Cynthia

Hi,if there is any assistance need please feel free to send your request to support@reolink.com they will help you out, thank you!

Steven Kan

Mitku, of course that would be the preferred solution, but all the evidence in the way the Reolink cameras operate suggests that they lack the hardware necessary to move by a specific physical step. If the cameras had physical steps that could be incremented or addressed, then the cameras would be able to store focus points instead of invoking auto-focus every time they go to a preset.

The fact that they _don't_ do this leads me to conclude that the motors in the cameras lack the hardware required to provide positional feedback to the controller.

That's why my proposal uses time instead of position, because that's the only way I can it working.

sarahladonna2

This post is deleted!

user_759336928293012

This post is deleted!

user_759345026633902

This post is deleted!

user_759406018809987

This post is deleted!