Campark T85 get pictures from camera using WLAN/Wi-Fi

The Trail Camera pro2 (was Hunting Camera Pro app before) for Campark T85 trail camera connects an Android device with the Campark T85 trail camera. Unfortunately it can only download a very limited count of pictures/videos at once. Therefore it is not appropriate to regularly get the data from the camera, if the camera takes several hundred pictures a day. While you need a lot of time for selecting, deleting etc. the WLAN consumes the battery of the camera.

T85 get on Ubuntu Linux

Looking for a solution to this problem, I wrote some bash scripts running on Ubuntu Linux which switch to that WLAN, fetch all the data from the camera, switch to the standard WLAN and move the data to the wanted destination on the NAS or another fileserver.

Download T85get archive

You need to call T85get.sh. You can either set the defaults in the environment and call it without parameter or call it using

T85get.sh [-T85cmd] (T85destdir) (T85nasdir) (T85camWLAN) (T85stdWLAN) (T85WLANPWD) (T85stdWLANPWD)
T85cmd: Always starts with hyphen (-), may be omitted. Default -r for repeat. See T85get.sh -h
T85destdir: Put the data from the camera temporarily here
T85nasdir: After fetching data from the camera and switch WLAN back to T85stdWLAN, move the data from T85destdir here
T85camWLAN: SSID of the cam WLAN
T85stdWLAN: SSID of your home WLAN
T85camWLANPWD: Password of cam WLAN
T85stdWLANPWD: Password of home WLAN

Usually the call with T85destdir and T85nasdir will suffice, if you did not modify Default SSID and password of T85 WLAN. The T85stdWLAN will be the WLAN currently active before starting the script restored automatically (default is *keepWLANasis - if your WLAN starts with * you need to double this), and the T85stdWLAN password will be asked or known to the linux anyway.

It seems that sometimes the WLAN of the camera stays active long time after the pictures got fetched, much longer than the timeout of 1/2/3 minutes. In that case the app should be connected and exited, so it tells the camera to turn off WLAN.

The camera does give the stored length of the file. This is being checked after the transfer of a file. If the file is incomplete, it does not get deleted from the camera. But the incomplete transmission gets removed. If the transmission is complete, the file gets deleted from the camera. There is a little risk as the file has no checksum. If somehow a correct count of incorrect bytes (eg all zero or some bytes incorrectly zero) get transmitted, the skript will not recognize this.

There is good chance that this implementation also works for other cameras built by Campark. The Campark T86 should be identical except for some optics. If my tools can be used for T80 and T100 without some adaptions, I have no idea. Also the Campark T85 is my first and only trail camera, therefore I also have no idea, if trail cameras from other manufacturers use the same webserver and if they are to access in the same or a similar way.

If the photos are too many, it is more efficient to get the card out of the camera and move the photos to the T85nasdir manually. Usually my camera transmits a photo with a size around 1 MB in 2-3 seconds, carefully arranging the notebook to have the best reception. But sometimes that does not succeed and every photo takes at least 12 seconds to be fetched from the camera. A transfer time of more than an hour consumes a considerable amount of battery power.

As the WLAN consumes really a lot of battery power, I usually do not use the transfer via WLAN anymore. If I read the images for an hour, getting the pictures which were made in one or two weeks (about 500 pictures a day in my case), the battery level reduces so that it lasts art least a week shorter. So I dedicated a second card which is ready for swapping. After changing the SD cards, I use a card reader to move the pictures into the NAS in-directory.

Problem repeating filenames

After the pictures got fetched from the camera, it will start using the first filename again. Therefore you can not always move the files to the same place. The files need to be renamed and for some overview (and to not slow down filesystem with tens of thousands of files) moved into folders.

Simple rename only using exiftool

For an easy rename of files without all these batches, you can just save the following line as skript exifrename

exiftool '-filename<CreateDate' '-filemodifydate<createdate#' -d %Y%m%d%H%M%S%%-c.%%le -ext jpg -ext mp4 -ext mov $*

Then in the right dir just call exifrename * oder exifrename . - or exifrename (dir) and all the pictures and videos will get renamed. Calling exifrename IMG* you omit the already renamed files, if you want to move everything in a single place. The mighty Exiftool is available not only on Linux, but also on Windows and MacOS. Some version with GUI can be found also in Android Play Store. As perl skript it runs where perl is available.

There will be some circumstances where this simple line is not sufficient. If the camera has date/time not set, it will default to some earlier date like 2019-01-01. That's why I use more than one step.

rename files without tags (incomplete transmission, this one never occurred since I run the skripts):
exiftool '-filename<filemodifydate' -d %Y%m%d%H%M%S_nodate_%%f.%%ue -if 'not defined \$createdate or \$createdate eq \"\"'  -ext jpg -ext mp4 -ext mov .
rename files with wrong date (before 2020, date of camera was not set):
exiftool '-filename<filemodifydate' -d %Y%m%d%H%M%S_wrongdate_%%f.%%ue -if '\$createdate lt 2020 and \$filename !~ /^20[0-9]{6}/'  -ext jpg -ext mp4 -ext mov .
rename files that are not already renamed:
exiftool '-filename<createdate' '-filemodifydate<createdate' -d %Y%m%d%H%M%S_%%f.%%ue -if '\$filename !~ /^20[0-9]{6}/'  -ext jpg -ext mp4 -ext mov .

Pictures rename and move on Synology NAS (according to EXIF data)

It makes totally sense to utilize a NAS for this task. It is the right place for the data and it is always running. The data is directly on the local disc of the NAS and not being accessed via network. For Synology DS218+ I use Exiftool like mentioned. My scripts for Synology take the photos from some incoming-directory (usually T85get nasdir), rename them and move them into directories named YYYYMMDD (per-day). Running this script automatically keeps nasdir for T85get empty from pictures or movies. If you want, you can use the skripts inside this dir.

To install exiftool on Synology, you need the Synology package Perl. Then you download exiftool without installing, and call that somewhere in the path in a file "exiftool" (do not forget chmod +x for this):
(path_to_exiftool)/exiftool "$@"

Download T85exifren archive

For renaming T85exifren.sh is to be called. You can call it using

T85exifren (srcdir) (destdir)

To make sure exifrename is called after one copies pictures or movies to the NAS, there is a script called T85exifwait.sh which checks the in-directory for new pictures and calls exifren.sh when a given count of seconds no new file was written (hopefully copying is finished then). Whatever is given as parameters will be called, you just add the complete call to T85exifren.sh after the T85exifwait.sh. It is made singleton, that means that only one copy of it will run at a time. I'm running it via crontab, so it will be checked on a regular basis that it is still running. My line in the crontab of the Synology looks like this:

19 5 * * * root /(volumename)/(somedir)/skript/T85exifwait.sh /(volumename)/(somedir)/skript/T85exifren.sh /(volumename)/(somedir)/in /(volumename)/(destdir)

Inside the destdir the directories will be created for every day.

T85exifwait utilizes inotifywait from the inotify-tools to watch the srcdir for files coming in.

These bash scripts for exifren also work fine on a standard Ubuntu, you only need to apt install curl.

It would be possible to completely remove these scripts and just call exiftool with parameter -d (directory) to say where to move the files. I'm not sure how it behaves if files exist. I wanted a real dupecheck using binary compare, that's why I did this myself. My T85move checks if the files are binary identical. Only if they are, the move is fine by deleting the source file. If they are not identical, user interaction will be needed (e.g. move the completely transferred file to the right directory - or just remove the corrupted file and let the batches do their job in the next hour).

Running on a computer without Linux

Using mkusb it is easily possible to create an USB stick booting e.g. a persistent Live Ubuntu 20.10. I created a directory named T85 on the usbdata partition. Made Terminal a favorite. Unpacked exiftool on usbdata. Added an alias in .bash_aliases for /media/ubuntu/usbdata/T85/get which was a script which exports T85exiftoolcall according to the place where exiftool is, calls first T85getrepeat.sh, then T85exifren.sh. It was an earlier version of the scripts, now it would call T85get.sh (not T85getrepeat.sh which got obsolete by option -r of T85get.sh) and set T85exifrencall (which did not exist by that time) instead of calling T85exifren separately, although that of course still is perfectly fine also.

This stick is a fine solution for people who want to use a portable solution to read the data from the camera, but don't run a NAS und usually don't use Linux. The data can be moved away from the stick on a regular basis, but there is no necessity to do this at any time.

 

Contact:    Email Timm Ganske