V1 was deployed in Venao Hills between 29.2.24 and 13.3.24, V2 was deployed in the same location between 16.3.24 and 30.3.24.

• V1 produced very blue photos. This has mostly not been corrected in V2, though interestingly some of the photos (I can't discern a pattern) are colour-corrected.
• V1 had photos with the background overexposed (but most of the moths well exposed) for the first few hours, and dimmed down to a bit underexposed by the end of the first night of deployment. The second day starts underexposed and goes down from there. For V2, the photos start underexposed from the beginning, and still dim by the end of the first night. The second night is all dim ending in difficult to use level of underexposure.
• Interestingly, the relative dimness of the UV and ring lights behaves differently between V1 and V2. In V1 the UV light dies well before the end of night 2, but the ring lights stay usable well after the UV light dies. In V2, the ring lights dim much faster, and get very dim before the UV light goes out.
• The focus is noticeably worse in V2, overall, and especially further away from the center.

We need higher exposure, better focus, and more consistent color correction.

seems like with an older mothbox that had flash and UV power going through the buck converter it may have been too much and it blew it out. Mothbox kept running in the dark though!

I think they saved alright to internal storage, but the USB has all the files, they are just empty

will try to fix the Backup Files script

TODO Add ability to adjust photo FREQUENCY in camera_settings.csv

arms are a bit fragile. especially at right angles

I set up MothBox02 the past two nights and the scheduling was not what it should have been. I was expecting three photos (for HDR) every two minutes, for one hour starting at 7:30, 10:30, 1:30, and 4:30.

First off, 3 photos were taken every minute.

I started it manually at 6:25pm on the 4th of April, and it took photos every minute during the following time blocks, according to the file names (the file names are different from the photo metadata times, which I think are in UTC, another issue):

18:25 - 19:23
19:31 - 21:27 ----- this is strange, ran for two hours. A bunch of the photos are red because it was taking them while in my backpack between deployment sites.
22:31 - 23:29
[now the 5th]
1:31 - 2:29
4:31 - 5:29

19:31 - 20:29
22:31 - 23:29
[Now the 6th]
1:31 - 2:29
4:31 - 5:28

Seems alright, except when I picked up the MothBox at around 11:30 it was still running. You can see that the last photos taken on the 6th are black (in my backpack), and before that it's daylight.

Something went wrong with the clock between the morning and evening of the 5th, while it was deployed in the forest?

I would also be useful to automatically generate a CSV listing the file name, time, and folder of all the photos produced, and a summary of the time blocks those photos represent. There can be a script to update the csv based on the photos in the nightly saved folder, at the end of every night.

Because of the way the backupper script works, if too many files build up internally it can jam up the internal works and crash everything

for instance if you have 20 GB of files and only 18 GB free on the pi, and it tries to make a local backup it stalls

that would be convenient

should find a way to shield it better

We found an interesting bug where she switched USB sticks and RPI continued thinking that the old USB stick was still in, and it went happily backing up to a non-existant USB stick (luckily it saves the backup on the rpi disk as well, so all the data was fine)

some research:

Mount Point Persistence: Raspberry Pi by default uses automounting features that  mount the USB drive to a designated location (usually /media/pi/<drive_label>). Even after physically removing the drive, the mount point directory remains. When you connect a new USB drive, it might not get assigned the same label, leading to the old drive appearing mounted (although there would be no data accessible).

UUID vs Label-Based Mounting: By default, Raspberry Pi might use the drive label for automounting.  If both USB drives have the same label, the system gets confused and continues referencing the old drive information.

Here's how to fix it:

Verify Mount Status: Use the df command to see if the drive is truly mounted. If it lists the old drive but with 0 bytes used, it's just the mount point remaining.

Unmount Manually: If the old drive shows mounted with used space, use the umount command with the mount point path (e.g., umount /media/pi/<old_label>) to unmount it properly.

Identify Drives by UUID: A more reliable method is to configure automounting based on the Unique Disk Identifier (UUID) of each drive. This ensures the system recognizes them distinctly. You can find the UUID using the lsblk command and look for the UUID field under the /dev/disk/by-uuid directory.

The 3rd photo of every set (underexposed) is way too underexposed - none of the insects are usably exposed.
The 2nd photo of every set appears too overexposed - insects have indistinct edges because they're overpowered by the brightness of the sheet. This one I'm less sure about - maybe a large dark moth would need this level of exposure.

The plastic thing inside the box that pushes stuff is too short

here's my drawing of how it should be

Maybe something with the USB output?

One of the mothbox gave me these images after a night's run

every 5th image or so was messed up.

Hubert's clock was randomly off and starts to run sometime after midnight. very odd. not sure if we will ever solve this mystery

Yeah it's just kinda raw and exposed isn't it. Gonna try to get some waterproof connectors and test em out!

Maybe we should get little waterproof silicone plugs for holes too?

opened a discussion here
PiSupply/PiJuice#1070

yeah i know andy, im just putting this issue here to remind you later