Wyze Cam Pan v3 Drift Update

Problem Statement

We have identified noticeable drift for Waypoints when Pan Scan is used on Wyze Cam Pan v3. This is a general challenge across all of the Pan-Tilt-Zoom (PTZ) cameras due to hardware limitations.

On Wyze Cam Pan v3, we can pre-set 4 Waypoints (A, B, C, and D) in total. When monitoring Waypoint B, there are two track paths: 1) it moves from Waypoint A after monitoring Waypoint A; or 2) it has moved from Waypoint C after monitoring Waypoint C. With these two different paths, an observed drift will occur between the two Waypoint B images.

Here’s an example demonstrating the observed difference on Waypoint B:

  1. Waypoint B moved from Waypoint A 2) Waypoint B moved from Waypoint C

Root-Cause Analysis

After investigating, we found that the drift is caused by the cumulative tolerance contributed by 1) the gear backlash, 2) the motor air gap, and 3) the assembly clearance.

Solutions Explorations

We measured the gap of individual devices in the production line and made sure this gap was accounted for during the movement and rotations. The following images are a comparison of before and after pics with the adjustments.

Experiment I - indoor, close shot within 8ft


  1. Waypoint B moved from Waypoint A 2) Waypoint B moved from Waypoint C


  1. Waypoint B moved from Waypoint A 2) Waypoint B moved from Waypoint C

Experiment II - outdoor, distant view of 32ft


  1. Waypoint B moved from Waypoint A 2) Waypoint B moved from Waypoint C


  1. Waypoint B moved from Waypoint A 2) Waypoint B moved from Waypoint C

Implementation Plans

From the experiments, we can see that the drift issue has been improved a lot, but it is still visible after the adjustments. Wyze will continue to explore and try our best to improve it as much as we can from this point.

  • For future devices, we will measure the gap of individual devices in the production line and ensure to get this gap covered to reduce the drift as much as possible.
  • Once we have implemented this strategy in the production line, we can start to collect more data points about hardware deviation that causes this drift issue.
  • With the new data points, we will release a new firmware that uses the optimal adjusted value to get those produced devices improved on this issue.
  • We are also working on exploring new solutions to allow the current devices to be calibrated in the user end through the app. We have not figured out a good solution for this one yet.

Thank you for reading! We appreciate your patience while we work on this problem.


Thanks for the detailed update!!


Thanks for this explanation however my v2 will incrementally drift more and more over time. If gear lash was the only issue, the view would remain within the orbit of the gear lash. I do not use waypoints or pan and scan. I use just a home point.

If the home or waypoint is located at x,y then the camera could simply go to 0,0 and relocate to x,y to recalibrate occasionally or if one of the extents is reached unpredictably while scanning or tracking it could recalibrate after the current event instead of a regular return to home.

When the camera restarts is there the possibility that it uses the current cam position as home instead of one stored in software? If not, it should calibrate on boot. Maybe I’ll program a bunch of reboot rules and see what happens.


Thank you Jason, and also thank you to the Wyze Dev and design team working on the issue. It is reassuring to see such detailed analysis of the problem and the plan to deal with it! Looking forward to Beta Testing potential firmware fixes.


Just for general principles, I have rules set to reboot all my Cam Pans around 1 AM every morning. Rebooting is the only reliable way to re-sync the time, and in addition it resets any minor deviations in the home position if I’ve been panning any cameras around during the previous 24 hours. At present, I do not use Pan Scan or Motion Tracking.

When my v3 restarts it always looses the home position–especially aggravating when there’s a power outage and I’m away from home. I do Not use Waypoints or Pan, because they are undependable at this point.

I like this presentation, a boon to the capable and curious. I hope it suggests a series has begun.


What I like the most about this post is the thorough transparency for those who want to understand it.
Obviously the action plan is really important, and maybe the most important from most peoples’ standpoint, but the transparency is something I strongly appreciate here. This is the kind of thing that I sort of expect from Wyze when they tell me that one of their core values is to “Be friends with users.” I would expect someone to treat me this way and give me the courtesy of a full explanation of what’s going on, and why, and what their plans are from there.

Please thank whoever spent the time on this presentation. They did an excellent job and it is thoroughly appreciated!


What is the Wyze / Forum policy on disclosing if a company post has been generated in whole (or in substantial part) by AI?

In general, I don’t mind if posts are written in part or in full by AI as long as it is a reply that is meaningful, on topic, and in the flow of the topic.

But if it makes you feel any better, I ran this through some AI Content Detectors (GPT4, ChatGPT, BARD, Human, AI + Human, etc) and they concluded that this post has a 95.2% probability for being written by a human and not an AI.

That sounds pretty conclusive to me.

But even if it was written by AI in part or whole, it still would’ve needed Wyze to give it all the applicable data and Wyze still approved being transparent and disclosing the information to us. That is main thing I like about it, regardless of the method of organization and dissemination. At least it was shared.


Do what this guy does toward the end. That will make me feel better. :slight_smile:

I’ve spent a fair portion of my working career balancing at the juxtaposition between the competing expectations of software/control engineering, mechanical engineering/industrial design, and manufacturing engineering/production. Each realm makes assumptions about the capabilities of the other realms, and each realm ultimately needs to make compromises to accommodate the one real “ring that rules them all”, namely cost.

Mechanical lash/play/slop in a gear system is not something that can ever be eliminated, since the lash is actually what allows the gears to turn and mesh with each other without binding and excessive friction/wear. Trying to control the lash such that the tolerance does not impact the desired output of the mechanical system, can drive the manufacturing time and cost of each component up by orders of magnitude. Unless we’re talking about a low-volume production, high-consequence risk component for a space mission, it’s simply not realistic to achieve. There’s simply too many factors that contribute to the variability: manufacturing process (injection molding, machining, etc), gear design, lubricant used, material properties (resistance to temperature changes, surface wear), the list literally goes on and on. These same factors mean that it cannot be assumed that the lash will remain constant during use, since all the environmental factors are beyond control.

Therefore, it is always best to accept that there is variable lash whenever a gear system is used, and accommodate it through automated measurement/feedback downstream in the process if that variability affects the end result. This is where Wyze has an advantage. The desired end result is a user-defined waypoint for the camera to travel to, as represented by what the camera sees. So, use what the camera sees as the measurement/feedback input to improve the precision of the waypoint.

Wyze already has:
a) the ability to identify and track an object within the video frame, and translate that to movement for the panning system,

b) onboard logic to continuously adjust the position if the object moves outside of a defined region within the video frame, and
c) basic AI to support recognizing an object under different lighting conditions (the smart object detection beta from a while ago).

So, this should enable Wyze to implement a solution based on:

a) when a waypoint is configured by a user, automatically (or with additional user input) select a static object within the video frame to act as a fine-tuning reference point,
b) whenever travelling to a configured waypoint, use the existing coarse motion calculations to “get close enough”, then
c) using the static object and the known position that object should be at within the video frame, cycle through micro-movements until the object is substantially where it should be.

This way, there is no need to increase manufacturing process costs to improve dimensional variance between manufactured units, there is compensation built into the process to accommodate environmentally-influenced variability, and this opens up potential improvements to the movement tracking capabilities of the camera in the future (micro-tracking versus coarse tracking).

Just my thoughts!


Lots of words to suggest a fairly solid solution. Have the recognition software do a fine adjustment based on its previous sample of the waypoint. Large shapes should suffice.

All the best

That’s absolutely the solution WYZE should pursue and, as you said, they have a unique advantage being in control of the software and the opportunity to use visual feedback for calibration.

Provided the motor and driver are capable of microstepping, a reasonable degree of accuracy should be achievable.

Fine calibration should be made part of the setup process as well as offered on-demand in the app. Periodic (perhaps user-defined frequency) auto-calibration or event-driven auto-calibration (upon activation of Pan Scan) would also be beneficial.

Accounting & compensating for the rather wide range of variables and their impact in both long- and short-term is especially challenging. I can see temperature changes occurring over a short period of time being an especially tricky factor to deal with. With it mounted outdoors or in a unconditioned space, the potential impact is even greater. Without auto-calibration occurring frequently, noticeable drift could be reintroduced within hours.

Some additional factors that may pose a challenge for this solution are the existing low resolution due to the relatively low tooth count of the driving gear, substantial loss of torque when microstepping (upwards of ~30%) and that, interestingly, a decrease in accuracy can occur if the degree of microsteps is made too small.

While I also think microstepping and reference image/static object-based calibration likely has the best chance of providing a workable solution for the issue, it doesn’t take into account use cases in which the camera may not have a clearly-defined static object constantly present to reference. Randomized AI edge detection in the reference image(s) may be able to mitigate that somewhat, but still wouldn’t be able to cover all cases.

As well, if the user would be required to manually bring a static object into the field of view for initial or periodic auto- or on-demand calibration, that can pose further complications with regard to physical accessibility of and proximity to the camera. As a one-time step, that wouldn’t be a big deal, but I can’t imagine people would be too thrilled having to do it on an ongoing basis. I sure wouldn’t be.

The improvements they’ve made so far have helped. However, with the time, cost and complexity of implementing a higher accuracy fix, I wonder how far WYZE would reasonably be willing to pursue it and at what point “good” becomes “good enough”. It’s a lot to expect of an inexpensive device, but at the same time, disappointing when a touted feature can’t be made to work as stated, regardless of the price. Hopefully, the lessons learned carry over into an improved hardware revision or successor model.

I’ve gone through three v3 pan cams due to this defect. I now have 1 waypoint + scan + tracking. I have to adjust the waypoint at least once every 2 days.

You’ll have to forgive me that I’m not going to applaud you for identifying the symptoms because most of us have already done that a long time ago. What I would like to know is can you fix this or am I going to bring this one back too…

Wyze customer service is appalling. When someone actually does bother to get back to you they are clueless and almost seem blissfully happy about being clueless.

I don’t care how much the camera costs, even if I would have paid $4 for it, I would still expect it to do what you claimed it could do but I’m in Canada so I had to pay a zillion dollars for this camera because Canadians are stupid enough to allow themselves to get ripped off. So $75 later with our taxes, I have a camera that has to get tweaked every second day…

From the very beginning I’ve said that wise needs to stop working on 11,000 products at once and just make one that works properly. While I’m at it, 1080p in 2023 is what 480p was in the early 2000’s. I’d rather pay $150 for something that actually works and I can actually see something properly. You must be making enough money off of gouging people for your stupid cam plus which I would never pay for.


This is still a major issue I have three of these cams and I will find them looking in a random direction every day. This product should be recalled until its corrected


Just got one today and is already doing the same thing. Any idea of a fix?

My camera doesn’t drift it goes completely out of saved set waypoints, like 180 degrees out on all four points.

1 Like

I have this same issue except I’m only using 1 waypoint without pan scan so it should just return to the home view/only way point. Yet every few days i notice I’m not getting correct notifications because the camera is not pointing in the area i set it. I appreciate the acknowledgment but it’s pretty disappointing such a basic feature doesn’t work where a camera cannot return to the 1 and only position i want it pointing at. Hopefully a fix soon.

1 Like