Flueron, V380 Pro and Raspberry Pi Zero as wireless CCTV cameras

A while ago I wrote a few articles describing how to use the Flueron, V380 Pro as well as the Raspberry Pi Zero (with the camera module) as cheap wireless CCTV cameras for home usage. A couple of months has passed and my setup is still running flawlessly with very few issues observed.

Among the cameras, the Floureon CCTV units can be considered to be the best. These cameras are self-sufficient and requires very little intervention from the end user. Over a period of a couple of months, I observed only four incidents among the Flueron units. In the first incident, the camera continued to be accessible wirelessly, just that all RTSP streams only produced the following static picture:

The picture looks as if the camera sensor was covered with something, which was obviously not the case. The timestamp and camera name (not shown in the above picture) were still displayed, which indicated that the CCTV was otherwise still functioning properly. The failure was detected by my server which constantly analyzed the CCTV snapshot via imagemagick, and looked for any unusual changes in its standard deviation (stdev) factor. The following is a typical output of imagemagick running on Raspbian on a similarly corrupted image:

pi@mainrpi:~ $ identify -verbose image1.jpg
Image: image1.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Mime type: image/jpeg
  Class: DirectClass  
  ..........
      standard deviation: 0.098153
      kurtosis: 2.8199
      skewness: 1.63857
      entropy: 0.865447
pi@mainrpi:~ $

The standard deviation in the above output is 0.098153. Standing alone, this number is not useful. However, you can run the same command on the snapshots taken over a typical day, look for the minimum and maximum values, and have your monitor script generate a warning if the stdev of one or more snapshots falls outside the expected range. A typical range would be something like [0.15, 0.25]. This is how I managed to detect this failure shortly after it happened.

In the second incident, the camera still produced a recognizable picture, albeit with some red artifacts. As the artifacts do not significantly alter the characteristics of the image, the failure was not detected by my monitor script using imagemagick. Below is a portion of that image:

In the third incident, despite losing wireless connection and failing to recover after that (I waited for more than two hours), the camera still worked normally and produced recordings on the SD card.

In all of the above incidents, rebooting the camera (via the web portal for the first two incidents, and manually for the third incident) helped solve the problem.

In the final and probably most serious incident, the pan-tilt-zoom (PTZ) mechanism of the camera failed and the camera lenses could not be set to a specific position. After a reboot, due to the faulty PTZ mechanism, the camera lenses would always point upwards after a few rotations. Although I can manually move the camera lenses to point to where I want, the firmware is programmed such that the camera would automatically perform a PTZ self-check after a reboot. Although there is an option called “centered while self check” in the Settings > Terminal menu of configuration web portal, this option cannot be used to disable the PTZ self-check at startup but can only be used to configure whether the camera lenses will return to the first preset position or to the default position at the center:

I worked around the issue by manually moving the lenses to the desired position, switching off the camera, opening the case manually and finally cutting power to the PTZ motor. On my unit, the PTZ mechanism is open-loop. There are only two wires to the motor to provide power and there is no feedback signal to tell the micro controller whether the PTZ rotation has been performed. With this, cutting the power to the PTZ motor does no harm and the camera with the faulty PTZ mechanism can be used again as a normal camera pointing a fixed location. If your camera PTZ motor has a feedback path, then cutting the power might not work as the micro-controller might know that the motor no longer works and refuse to power on. If this is the case, you might need to keep the wires to the PTZ motor and simply remove the mechanical parts connecting the motor to the lenses so that the camera will not return to an awkward position after a reboot. Obviously a better way would be to modify the firmware to disable the PTZ self-check, which is a tall order without the source code.

It is worth mentioning that the Flueron units that have issues are all semi-outdoor units located further away from the main router; one of them is also subject to occasional rain drops.This indicates that the issues were mostly due to intermittent wireless reception and outdoor conditions. For example, tiny water drops could have come into contact with the circuit board and temporarily shorted out the camera sensor or wireless chips. On the other hand,  those units which are located indoor are still working fine after several months without any issues observed.

For the V380 Pro camera, no major issues were observed, except for once, the camera lost wireless connection and required a manual reboot. In my setup, as the V380 Pro does not have an option to upload the footage remotely, I have an ffmpeg process running on another server to periodically (e.g. every 60 second) take a snapshot from the camera RTSP stream. While almost all snapshots are satisfactory, once in a while I received the following corrupted snapshot which contained nothing but repeated patterns:

As the color patterns on the corrupted image somewhat resembled the expected image, I suspect the corrupted image was created when connection was suddenly lost in the middle of taking snapshot, and ffmpeg was forced to use whatever data was available in its buffer to generate the output. The remote MP4 recording taken by ffmpeg at the same time did not have such issue. The issue was therefore most likely not caused by the V380 Pro camera itself.

As for the CCTV units running on Raspberry Pi with camera modules, no strange behavior was observed. As a fallback, I have a script running on each unit which automatically reboots the machine if it cannot ping my main router. Fewer than five reboots were observed, which all came from the units located further from the main router. If time permits, I will study how to add an external antenna to these units, but as of now, this is not an issue for me.

All things considered, I think the setup suits my needs well, both in terms of functionalities and costs. I also purchased a few more v380 Pro, Flueron as well as Raspberry Pi Zero as backup units but so far no replacements have been needed yet. Needless to say, you should configure your router to disable Internet access for the V380 Pro and the Flueron cameras to rule out any security concerns. Remember to replace the SD cards on the cameras every 1-2 years to avoid flash memory wearout, and the setup will be almost as good as any professional setup, at a much lower cost