1. Pingback:How (some) Trail Cameras Fail - Winterberry Wildlife

2. Great work! My only point of disagreement is that this has not been rare at all in my experience, but a huge issue which has ruined half of my 3 season camera placements with HP-5s. Card capacity seems to be a bigger risk factor than speed.

   Reply ↓

   • Thanks. The failure was “rare” in terms of the time it took me to reproduce, but I can see that it wasn’t rare for you! If you try one of my new firmware images, please let me know if it fixes the problem. It’s possible there’s another bug lurking out there, but I hope not.

     Reply ↓

     • I set out my old Recon Force Edge with the new firmware for a week. The card was not corrupted, but all videos were in black % white, even in mid day. When I was at the camera, the lights came on, even though it was during daylight.

       Reply ↓

       • Hmmm. That’s not good. In tests I did here, I get the correct behavior. So I can reproduce the bug, can you post the camera settings you were using? Thanks.

         Reply ↓

         • This has no happened with my Spec Ops Edge, as well: Browning Spec Ops Edge. Video, 1 minute, ultra, Motion detection long range, trigger speed fast, battery type lithium.

           Unfortunately, I set this camera out in a spot that had been DEAD for 8 months, and, of course a cougar with 3 young kittens came by at 10AM. The videos were all in B&W. While the videos were all obtainable, the card will not now format in my Mac.

         • Very sorry to hear. This will require some detailed debug. Please expect an email from me shortly

3. Good morning.
   I have this problem on my Spec Ops Elite HP5 and it’s not rare to happen, it’s a frustration.

   At the time, I contacted Browning, sent my camera to them, as I’m from Brazil, I spent a considerable amount to send it to the USA.
   After a week they sent me the same camera back free of charge.
   They just configured the camera differently than I use, with a high recording interval and short videos, but that’s not how I use it.

   I configured it my way and installed it in the woods, same problem as you described, corrupt card and no power in the batteries.

   I sent a message that I would send the camera again to the USA, they told me it wasn’t supposed to be sent and they sent me a note free of charge for me to Brazil, this new one still works perfectly today.

   Even using slow cards, the problem persists, I use the 128GB SanDisk Ultra.

   You speak of slowness in writing and not in reading, correct?

   See my table.

   https://docs.google.com/spreadsheets/d/1PcZkJ588yCqOAqZog6W6LRzFaBPUECyqMhWF9BUPT7s/

   I really don’t know what to do, the camera is great and it’s unused here at home.

   Yours sincerely,
   Erik from Brazil.

   Reply ↓

   • Thanks for the additional data on card types! Please try downloading and installing my new firmware image for the BTC-8E-HP5 at my GitHub site: https://github.com/robertzak133/unified-btc-reverse You are looking for the image at https://github.com/robertzak133/unified-btc-reverse/blob/main/targets/btc-8e-hp5/created-burn-images/RELEASE/brnbtc82.BRN I bet this will fix your problem. Let me know.

     With regard to speed. The answer is a little involved, which is why I left it out of my original post. The Read and Write speeds are the result of several factors. The first is the maximum data rate. These have been steadily increasing, requiring more complex circuitry and firmware. I have found that these Browning cameras can handle a data rate of 50 Mhz * 1/2 byte = 25 MBytes/second. Newer SD cards are capable of peak data rates of 100 MHz * 1/2 Byte = 50 MBytes/second, and 200 MHz (100 MBytes/second), and higher. The key thing for this bug is the data rate, which I’ve found needs to kept at 50 MHz * 1/2 byte = 25 MBytes/second. The advertised write speed for SD cards includes other effects, which reduce the bandwidth. For example, the maximum rate at which the SD card allows new write operations to be posted (the SD card firmware itself has some fancy book-keeping and allocation tasks to do to support writes). I don’t think these factors contribute to this bug.

     Reply ↓

     • Good afternoon.
       I understood your explanation.

       It’s strange that the new camera that Browning sent me works perfectly, regardless of the card used.

       Did Browning fix it via hardware on the new Spec OPS HP5 cameras or was it a new firmware that they didn’t release to the public?

       Thank you very much.

       Reply ↓

       • I have a theory 🙂 As I understand the current firmware, it always tries to run an SD card an its maximum frequency. If it detects an error while doing this, it reduces the clock frequency and tries again. The sooner the firmware encounters an error, the earlier it will switch to the lower (reliable) clock speed, and the less likely it is to corrupt the file system. I believe that some (most?) hardware, due to manufacturing variation, *always* fails at higher frequency. Ironically, these cameras are likely *never* to encounter the bug, since the firmware will quickly switch to a lower frequency. This is essentially what my firmware fix does by always operating the card at a lower frequency.

         Of course, it could be that there is a newer, unannounced firmware patch available. What firmware version does your working camera have (visible on “firmware update” menu)?

         Reply ↓

         • Goodnight.
           Sorry for the delay, here’s a photo of the original firmware that was in it.
           I installed your firmware and put the camera in the woods.

           https://i.postimg.cc/zvP9JgcS/IMG-8178.jpg

           When I check the camera, I’ll tell you if it hasn’t crashed with your firmware.

           Thank you for your hard work in providing us all with alternative firmware.

         • No problem. The version of firmware in your camera is the same mine, so I’m pretty sure Browning has not released their own firmware fix for this bug.

           I really hope my firmware fixes the issue you’re having 🙂

         • Good afternoon Mr Bob Zak.
           Yesterday afternoon I went to see the trail camera in the woods with its alternative firmware and it was still working correctly.

           In summary.

           recorded: 91 videos of 30 seconds, 9.68gb. (03/12-16/12)

           [img]https://i.postimg.cc/26WjdWWw/bob-zak-firmware.png[/img]

           I was very happy to see the camera still working and recording records.

           Thank you very much for your hard work in researching and developing a fix for the problem cameras.

           The camera recorded a newborn deer with its firmware.
           https://www.inaturalist.org/observations?place_id=any&user_id=polones&verifiable=any

           Thanks.
           Erik from Brazil.

         • That’s great news! And congratulations on the capture of a newborn fawn. I was quite confident the fix would work, but it’s always reassuring to hear that it does, and so many thousands of miles away. Your file listing confused me for a second, with the different convention for listing DD-MM-YYYY vs. MM-DD-YYYY. Make sure to try out the new time format options in the extended menu, which can get you the DD-MM-YYYY version of the date on the info-strip.

         • Good morning.

           unfortunately I got the year wrong in the configuration and didn’t notice it in the woods. Worse, I forgot to fix the year again.
           I was a little nervous, I almost pissed on a snake(Bothrops jararacussu), I was wearing high-top, protected boots, the snake didn’t attack, but I was scared.
           In January I will look at the camera again and fix the date and take the opportunity to put it in the official format used here in Brazil, DD/MM/YYYY.

           Snake
           https://postimg.cc/gallery/26njSqQ

           The snake is on the left of the photo, above the stick. I didn’t even see the snake when I passed by, my friend saw it and told me to run right away.

           Have a good day.

           Erik from Brazil.

         • Well, that’s terrifying. I recall reading about the dangers of snakes in the tropical jungles in Alan Rabinowitz’s 1991 classic “Jaguar”. Fortunately, that’s about as close as I’ve gotten.

4. I WAS NEVER GIVEN A CONFIRMATION ACKNOWLEDGEMENT OF PURCHASE OF CAMERA TRAPPING TECH. PLEASE SUBMIT ACKNOWLEDGEMENT

   Reply ↓

   • ?? Sorry, Dave, I don’t understand your question. The only thing for sale via our website is Janet’s Book: Camera Trapping Guide, available on Amazon at https://www.amazon.com/Camera-Trapping-Guide-Behavior-Wildlife/dp/0811719065 Is this what you’re referring to?

     Reply ↓

5. I have 3 HP4’s and one Edge. I haven’t seen the problem. I have mine set for video only and 2 min long. (the night time defaults to 20Sec)

   Reply ↓

6. Thanks. I had my Spec Ops just last month fail 100% after a 3 week set to capture any videos. I had the same cam give me a format fail also a set before that but after reinstalling the SD into anther camera and reformatting it and reinstalling it into the HP5 it worked. I format SD cards every time I set a cam no matter what. The last set I had no problems with the camera. I own 3 HP5s and haven’t set the 2 new ones yet and now I’ll do the test. I also have 3 I run for a customer, but I haven’t had any problems with them yet. I run only MacBook Pro computers and now I’m testing all cams with a test trip every time as you suggested and realize I was doing this the last time I set my HP5s. Thanks

   Reply ↓

   • Thanks for commenting and for this additional information. Indeed, in previous posts I have described our process or formatting SD cards in the PC (or Mac), and then again in the camera itself. In all honesty, I don’t have any strong data to suggest this is necessary or sufficient. However, the idea of triggering the camera once, after a new (blank) SD card has been installed *does* actually have data. In particular, as I describe, the bug seems more likely to occur when the firmware has to create new directories before storing an image file. A write error at this time can apparently wedge the file system. A test trigger will create these new directories, and thereby reduce the impact of a write error.

     Reply ↓

7. This is great work, Bob, thank you so much for doing this! In my experience, the SD card wasn’t always completely corrupted beyond use, but it would have anywhere from 1 to 10 videos before it just stopped recording for the week. Sometimes the batteries were completely drained, but not always. I hope that you will send this blog post directly to Browning service. The brand new camera they sent me to replace the camera that had this issue had the exact same issue on its very first deployment. As far as I could tell the SD card wasn’t corrupted, but the batteries were drained completely to zero in less than a week. Browning service tried to blame the fact that I was using an external battery rather than the battery tray. I’ve been using these rechargeable 12 V batteries for years with other model cameras with no issues whatsoever. Browning needs to know that this is a serious issue with their cameras and they need to fix it and give people refunds. This is completely unacceptable.

   Reply ↓

   • I am interested to see if the bug you describe (which has slightly different symptoms that have I’ve seen) is fixed by my firmware upgrade. Let me know if you try.

     A while ago, I made some weak attempts to find someone technical at Browning to discuss bugs like this. I never got any bites. Since then, my work reverse engineering their firmware has probably made it even less likely that they’ll respond to me directly. Frankly, it has also made me less likely to try to contact them. Still, everything I do is public — feel free to forward a pointer to this blog in your next exchange with Browning support!

     Bugs like these expose the weaknesses of the network of various business relationships which go into a “Browning” camera. Browning itself merely licenses their brand. The Prometheus Group, based in Georgia in the US, markets the cameras, and provides customer support. I believe Prometheus specifies the requirements for new cameras to 3rd party IP providers which then develop the hardware and firmware. Thus, fixing bugs like these, especially those that are hard to reproduce, or deeply technical, must somehow make it 3 levels deep through commercial interests and relationships that are mostly focused on the next generation. Of course, this is an explanation, not an excuse. I agree that at least Browning and the Prometheus Group should be more interested in fixing these things.

     BTW — in the post I mentioned that we have never encountered this problem on our Advantage series cameras. I confirmed that the Advantage firmware can *only* operate SD cards at low clock rates, which avoids this bug. All more recent cameras (the Edge and Elite HP4, HP5s) in the SpecOps/ReconForce line, based on my findings, have newer firmware (and likely hardware) that is subject to this type of failure. Some specific cameras more than others. All I’m saying is that it may be hard for your to find a stock Browning camera that is sure not to have this problem.

     And, finally, I have reason to suspect that due to common hardware and software modules used by 3rd party suppliers who develop most of the firmware for all trail cameras (Browning or no), that Browning Cameras are not the only ones subject to this failure.

     I know, I’m just full of sunshine today 🙂

     Reply ↓

8. I have a Browning Elite HP 5. Was running a 32 gig San Disk Ultra 80 mb/s from my old Bushnell cam. HP 5 ran with no problems. Bought two 64GB San Disk Ultra 140 mb/s. I shot several videos and still shots after formatting 1 of the cards via the camera. Upon checking the videos and pics on my lap top I could view the photos but they wouldn’t delete using the computer. Computer said the photos were write protected. SD card protection switch was not in the locked position. The switch was worked back and forth numerous times with the same message saying the card was write protected. The card was then formatted in the cam again. Pics were deleted but computer said the card was write protected when trying to format the card on the computer. The other identical card was never formatted in the cam. The card was able to be formatted on the computer with no problems. This card was then put into HP 5 cam, several pics were shot. Cam recorded pics and could be viewed on my lap top. Photos could not be deleted and the card could not be formatted via the laptop. Same message as first card. Card is write protected. The 32gb card appears to not have been affected when used in the HP 5.
   I contacted Browning and they stated I probably had got bad cards. Stated they haven’t been having any problems. Advised me to try a new card.
   I bought a a new San Disk Image Mate 64gb 140mb/s. Put it in cam took several shots and viewed them on my laptop. Couldn’t erase any pics and the card would not format on the computer. Just like the other two cards the computer said the cards were write protected.
   Fast forward: After several times (10-15 or more)of re-formatting the 64 gb card, taking several pics and formatting in the cam. Then checking them on the computer 2 out of the 3 cards started working correctly. Still working on the third card.
   It appears that the cam is somehow writing something to the cards during the formatting process which makes the cards seem like they are write protected. Don’t know if others have had the same problem.

   Reply ↓

   • Gary — this is very interesting behavior. I believe you are spot on. The SD cards do allow protocol-level write protection of files and blocks. I agree with you that the camera is writing undesired contents into the card. I believe this is done as the camera is waking up to take a picture and trying to operate the SD card at a speed the camera (firmware) can’t handle (As opposed to during the “Delete All” function. I had this same idea, and wrote some diagnostic programs that tried to elicit flaky behavior from the “delete all” command — all unsuccessfully). Eventually, while trying to access the SD card at high speed, the firmware recognizes that it needs to operate a lower speed. But the longer this takes, the more potential there is to write bad data almost anywhere in the SD card (including into the control structures which enable write protection). If this hypothesis is correct, the firmware fix I describe in this post should also fix this problem.

     Reply ↓

9. Good morning everybody.

   Stopping by once again to leave my story.
   Just remembering that the camera was unused and at home, because of this problem in the topic.
   I installed the firmware developed by Mr. Bob and everything was resolved, firmware installed on 12/03/2023 and yesterday (01/06/2024) I went to check the camera again and everything is working perfectly.

   My camera and its settings:
   Browning Spec Ops Elite HP5 firmware WWL8EH5_231114P
   Smart IR Video: on
   Video recording only: 30 seconds
   Delay: 1s
   IR Flash: long range

   I am immensely grateful to Mr. Bob, without the firmware, the camera would be unusable, at the time it was sent to Browning for repair and they did not solve the problem, the camera was already condemned due to this software problem with no solution until today on the Browning website.

   Yours sincerely,
   Erik from Brazil.

   Reply ↓

   • Thanks for checking back in. I’m very happy the firmware fix worked for your camera!

     Reply ↓

10. When taking a video in the live view mode, what buttons do we press to stop the camera from recording to it can be set up in the field. After recording one video in live view mode I had to turn the camera off for it to stop recording

    Reply ↓

    • Once you start taking video in view mode, by pressing the “E” button, you have to wait for the camera to take a video of whatever duration you selected in the “VIDEO LENGTH” menu. E.g. if you set the camera to take 1 minute videos, the camera will take a full minute video after pressing “E” . After that, it will automatically arm itself. You can see this happening by watching the video time count down to zero in the upper right corner of the display. When it’s done it says “Ready”. After 20 seconds or so, it will arm itself.

      Reply ↓

11. Please help! We got several Browning Dark Ops Pro DCL model BTC-6DCL and deployed with 256 Gigabytes SD with write speed of 200 MB/s. In typical camera, I got approx 8 good videos (MP4) and the others recorded but unreadable. What is the fix? Thanks: we are conservation biologists and this is a fundamental Italian project. Yours, Marco

    Reply ↓

    • Marco — sorry to hear of your plight. It sounds like you have an SD card with 8 readable files and lots of other (properly named), but unreadable files? Is this the case? What does the file system say about the sizes of the unreadable files? Are they about the size of the readable files? How about the creation dates? Do they look reasonable?

      And when you say “Unreadable” — I assume you mean they won’t open in your favorite video viewer.

      Assuming all these, the best I can recommend is to use a photo/video recovery tool. I’ve had some luck with a product for the PC called “Stellar Photo Recovery”, but there are others.

      Because you can see a lot of other files, I don’t believe this is a variant of the “card corruption” bug described in this post. But this also means I can’t be much more specific with advice.

      Reply ↓

      • See below in capital letters and thanks!

        It sounds like you have an SD card with 8 readable files and lots of other (properly named), but unreadable files? Is this the case?
        YES

        What does the file system say about the sizes of the unreadable files?
        NOTHING

        Are they about the size of the readable files? How about the creation dates? Do they look reasonable?
        I CAN ONLY SEE INFO FOR THE WHOLE SD CARD. IT SAYS THERE ARE SOME GIGABYTES OF VIDEO ON THE CARD

        And when you say “Unreadable” — I assume you mean they won’t open in your favorite video viewer.
        DO NOT OPEN. CANNOT COPY AND CANNOT PASTE SOMEWHERE ELSE

        Assuming all these, the best I can recommend is to use a photo/video recovery tool. I’ve had some luck with a product for the PC called “Stellar Photo Recovery”, but there are others.
        YES, BUT FOR THE FUTURE, WHICH CARD WILL WORK. IS IT TRUE THAT 200 MB/s TOO FAST?

        Because you can see a lot of other files, I don’t believe this is a variant of the “card corruption” bug described in this post. But this also means I can’t be much more specific with advice.

        Reply ↓

        • I think the short answer is likely, “Yes — a 200 MB/s SD card is too fast.” Sounds like you should be using SD cards rated at 80MB/sec or lower. Longer answer: (On second thought) This does sound like a variant of the “SD card corruption” issue described in this post. It seems likely that this problem exists in the BTC-6DCL, given the high degrees of software sharing between different camera models. I suspect that the “200 MB/s” SD cards are in fact too fast for this camera. Not fundamentally so: the camera does not require this speed to capture video; and the camera could choose to operate these parts at lower speeds. But in practice, as the firmware tries to operate the SD card at the highest speed possible until it detects errors. The problem is that data corruption, including of the file system structure can occur before the firmware switches to a lower speed. That would account for the behavior you’re seeing.

          I’ve not worked with the BTC-6DCL, so I don’t have a firmware fix for it.

          In general, the more modern SD cards with higher capacities also operate at higher speeds. I was able to find a 256GB micro-SD card from SanDisk advertised as “low speed” (60 MB/s). It comes with an adapter to standard SD card form factor. I’d give it (or an another low speed SD card) a try. https://www.newegg.com/sandisk-256gb-microsdhc/p/0DF-07XM-00026 Let us know if it fixes your problem.

          PS: with regard to data in your current SD card. If this is the “card corruption” bug, there’s a fair chance there is really no additional data there, as the camera itself cannot read the SD card to boot and take new photos/videos. The size of data given by the OS could be the result of a corrupt of file system metadata, and not the presence of actual files. Still, if the data is important, at least looking for it with a forensic tool is probably worth it. But be prepared for disappointment 🙁

          Reply ↓

12. Hello Bob, on Browning website have a software update for BTC-7E with a similar correction of what u have done, do u know if this software update from them will correct the same problem u found? I’m asking this because my BTC-7E is with the same problem u found and I don’t know if the software update from Browning will correct this issue or I will have to use yours.

    “The Recon Force Edge trail camera is designed to work with SD cards ranging in size from 8GB to 512GB. See your cameras instruction manual for the brands we recommend for optimal performance. Faster SDXC memory cards will have the UHS rating, or Ultra High Speed, represented by a number inside the letter “U.” U1 means it’s 10 MB/s; U3 means it’s rated at 30 MB/s or higher. This refers to the write speed of the SD card.

    Some users may experience problems when using a SD card with a U3 rating. This can range from the display giving different SD card related errors to 0kb and/or unreadable files. The software upgrade and instructions provided below will resolve this issue. Should you have any questions or need further assistance our Support Services team is available Monday through Friday from 9am to 5pm CST at 888.618.4496, Option 2

    Download the instructions below labeled: SW Upgrade Instructions – Recon Force Edge. Open and carefully read and follow.

    Download the software below labeled: BRNBTC70.BRN. Do not open. Follow instructions provided.”

    Reply ↓

    • The latest Browning firmware update for the BTC-7E *does not* have the fix for the “corrupt SD card”. I know this because I used this file you mention as the foundation for my firmware additions and the fix to the “corrupt SD Card” bug. In general, all the firmware images for the {7,8}{E, E-HP4, E-HP5} that I’ve published on my GitHub site are based on the most recent Browning firmware updates that I am aware of. I would install the latest Browning firmware on your camera, as it’s possible your camera is experiencing a different bug. It can’t hurt. But if you are still get corrupted SD cards, the only fix I’m aware of is in my hacked firmware images. If you go down this path, let me know how you make out.

      Reply ↓

      • Thanks for the reply Zak! Yes, I tested yesterday and u are right, for mine BTC-7E the official firmware from Browning didn’t work. I installed yours and until now without error. Thank u very much, I’ll keep u informed.

        Reply ↓

        • That’s great news! Hope to the new firmware works out for you. Let me know if you run into any problems with it.

          Reply ↓

13. 1st – what a trove of fabulous help! I have 2 x Recon Force Elite BTC-7E-HP4. I have downloaded your fix to the SD Card issue but I get ‘Card Error’ almost immediately and at the FW Upgrade screen I cannot select ‘Yes. Current FW is BTC7EH4_MO2240F

    Thanks again.

    Reply ↓

    • Thanks — it certainly represents a fair amount of my time 🙂

      OK — so you have copied an image onto an SD card for the BTC-7E-HP4. But when you put the SD card in your camera, the screen shows a “Card Error”. Subsequently, the menu system doesn’t let you select “update firmware”. Bummer 🙁

      Have you tried the same SD card back in the PC? Is it readable there? If not, you could try reformatting it in the PC and reinstalling the firmware file. I would remove it from the PC and reinstall it to make sure it’s readable there. If it’s not, I’d try a different SD card.

      Let me know if this doesn’t work.

      Reply ↓

      • Hi – Yes, card error immediately on switch on. I have tried with 3 SD cards and all readable on PC. Followed all of your steps. Am going to try a brand new slower sd card – hopefully arriving today. Will report back of course. Thanks again.

        Reply ↓

14. Hi Bob, thanks for all of your efforts, your articles are an invaluable resource for me. I have a recon force BTE-7E-HP5 which shows exactly this problem, every time. However, it’s still happening after installing your firmware. Any ideas? Do I need to get the EEPROM replaced?
    It’s also notable that we have 9 other cameras (same model) which don’t show the bug, at least yet. Is it normal for certain units to be buggy while others are fine?
    Cheers from Germany.

    Reply ↓

    • What ?! 🙂 To your first question: As long as you are able to update the firmware and change settings, I’m pretty sure that replacing the EEPROM won’t help anything.

      I have found that the rate at which the bug (I fixed) occurs can depend on cameras. Some cameras never seem to fail, others seem to fail every once in a while.

      I have never seen a camera fail in this way *all the time*. This, and the fact that my firmware fix didn’t help, leads me to believe that your 7E-HP5 has a different problem. Just so we’re on the same page, can you describe exactly the symptoms you’re seeing on the failing camera? Do you have access to a slow SD card, and if so, does it fail in the same way?

      I’m happy to try and debug this online, but if you are more interested in getting a camera out in the field ASAP, a camera that fails all the time, even with a slow SD card, seems like it would be an easy warranty case.

      Reply ↓

15. Hello Bob, thank you for the post! We did encounter the same issue repeatedly and came across your post, which is actually introduced from Browning technician. It seems like they did take your test very seriously! Another common issue we’re having now is that the battery drained relatively fast in recent models, especially 7E-HP5. We thought it might be something to do with the LED, since Browning claimed to have the new Radiant 5 illumination technology. Under the same environment and the same setting, 7E-HP5 operated shorter, sometimes up to a month’s difference. Just wonder have you, or have you heard anyone encountered the same situation. Cheers! 🙂

    Reply ↓

    • Thanks for the info! First I’ve heard that Browning follows my blog 🙂

      Regarding “faster battery drain” in your 7E-HP5’s, what is the “IR Flash” setting you’re using, and what is your comparison point? One of the things I did notice when hacking the firmware for these cameras is that the “IR Flash” settings behave differently in different cameras models. For example, the power with “Economy Flash” on the HP5’s (4.6 Watts), is about 5% more than the “Economy Flash” settings on the HP4 (4.4 Watts). In the other settings: Long Range (4.6W), and Blur Reduction (9.2W), the power was the same for both HP5s and HP4s that I measured.

      Then there’s the firmware. There is code in these cameras which is intended to modulate the actual flash power used depending on the lighting conditions. If it were my design, I would have the user setting be the “max” power consumed, and adjust the LED power down on a video-by-video basis depending on the ambient lighting, if possible. I spent a long time trying to understand the existing code, but never did figure it out, so I’m not sure if it works, or works the way I would do it :(. It’s pretty convoluted. In any case, it’s possible that there is some difference in the firmware between camera models which could lead to different actual flash power.

      Reply ↓

16. Hello Bob,
    I’m wondering if the sd card corruption & link with internal clock spped is due to the fact they can provide 60 fps videos.
    I ‘m fan of browning & 60fps smooth video which are not available in other trail camera manufacturers but may be they do not manage correctly the need of “fast writing” & sd card speed.
    does the problem is the same if 60fps videos are not selected but only 30fps?

    hope they will read your blog & fix it quickly!

    Reply ↓

    • We’re big fans of the 60 FPS capture HD (“Ultra”) video capture supported by Browning Cameras. But I don’t think support for this feature is at the root of the “SD card corruption” bug. Here’s why:

      As it happens, writing MP4 compressed “ULTRA” (HD) video out at 60 FPS consumes less than 1 MByte/second of bandwidth into the SD card. This rate is easily handled by relatively slow (by current standards) SD cards. This data rate has remained consistent over the last 4 generations of Browning Cameras, starting with the Advantage series, whose firmware only supports relatively low clock and data rates.

      [This requires that the SOC be capable of compressing an incoming HD (“ULTRA”) video stream from the Sony image sensor at full video line rate – which the iCatchTek V35 and V38 devices do]

      I suspect this bug was inadvertently introduced into the Edge/HP4/HP5 Browning models when the software library for SD card support was upgraded to handle higher bandwidths for other camera applications, but the end-to-end design was not adequately verified. The fact that the new firmware often negotiates to the lower clock rate supported by the Browning cameras without errors allowed this bug to “slip through the cracks” in Browning’s validation methodology.

      Reply ↓

17. Hi Western MA Bob, I just stumbled upon your site while looking for troubleshooting help for my BTC-8E-HP5. The problem I am experiencing is that I put the camera out in the field and come back later a week later to find the batteries dead and the SD card filled with thousands of images with no motion in them. I’ve got nothing to lose on this unit so I will be installing your firmware in hopes that your superior engineering skills surpass those of the folks at Browning. Curious though if you’ve seen the phenomena I’ve described before. In your judgement a hardware or software problem?

    Reply ↓

    • Glad you found us. Unfortunately, I don’t have high hopes that my firmware will help with your problem.

      Maybe it will, but in the likely case it doesn’t, here are some other ideas:

      1. If the images are all taken one after another, or in clusters of consecutive “false” captures, you may be dealing with “run-on triggering” (you can find a description of this in my continuously updated How (some) Trail Cameras Fail This didn’t use to be an issue with the HP5s, but for some reason, the recent batches of this camera are prone to this problem. You should be able to reproduce this problem with the camera in a still room. Trigger the camera once (e.g. by walking in front of it). If you get more than a single image or video, you likely have this problem. If this is the problem, I would try decreasing the PIR sensitivity, and increasing the Photo Delay to 5 or even 10 seconds. Also, don’t use “Smart PIR” setting. I suspect this is a hardware problem, caused by an out-of-spec (or incorrect) component in the PIR sensor amplifier, but I don’t know this for sure. It’s not a firmware problem.

      Or… (much less likely, in my experience)

      2. You may have a bug with the PIR sensor itself. Set the camera up for “Aim Test”. The red LED on the front of the camera should only come on when you trigger it by walking in front of the camera, or waving your hand in front of the sensor. If the camera is in a still room, stably mounted, the LED should stay off. If its coming on, there’s a problem with the PIR sensor. You could try changing the PIR sensitivity setting, but if that doesn’t work, it will need to be replaced.

      Reply ↓

    • I’ve had run on triggers on HP4 and maybe HP5. I don’t get thousands, but I’ve seen 15+ recordings in a row. Each time camera was under warranty and was replaced by Browning.

      Reply ↓

      • Thanks for the information. This is disappointing. If you get to the point where vendor won’t replace, let me know. I’m curious about what’s actually going on with these cameras.

        Reply ↓

18. I’ve had this corruption happen a couple times. It’s been awhile, so I’m not sure if it was Recon Force Elite HP4 and/or HP5. Usually I have to toss the card. All my cards are 64gb because I can have a lot of activity and sometimes a day or two of wind can trigger 100+ recordings. I record for 1 minute with 1 second delay.
    Also the cards are 170mb/sec and now every order they are coming as 200 Mb/sec. Great speed for moving from card to computer.

    I just yesterday received 4 more cards from Amazon. 2 are for a new camera but 2 are for spares when I get corruption.

    Is this firmware just for the HP5 or for both regarding the card corruption?

    Reply ↓

    • I’ve never had a case where a PC could not reformat a camere-corrupted SD card. But it sounds like this is what’s happening with yours? This would point more towards and SD card failure than the Browning bug.

      You’re right about almost all large capacity SD cards operating at much higher clock frequencies than can be used safelyl on Browning Elite, HP4, and HP5 cameras (at least). It takes a long time to access such huge capacity at low data rates (though a low data rate works perfectly fine in the camera, since it will keep up with the rate at which images/video can be generated). I would expect the “corrupted sd card” issue to occur more frequently with faster cards.

      BTW — if you are planning to try my firmware fix to this problem, wait a little while. Turns out my earlier fix was incomplete. I’m planning on a fix to the fix in a week or so.

      Reply ↓

      • Glad you mentioned to wait. I just setup 2 cards with each of the firmware.

        I also like that you added some many useful additional features such as battery % on the info strip. Regarding the battery %, all my Browning cameras have either the solar panel or battery pack and when plugged into the camera the screen shows Ext Pwr. In that situation, will the strip show the internal battery %.

        It’s possible I might be mistaken regarding being able to reformat a corrupt card. However, I think the card would not even mount on the iMac to be able to reformat. I also believe there might have been some times I actually could reformat.

        Reply ↓

        • Regarding battery life in the info strip — nope, sorry, the info strip will also say “EXT” (power).

          Working on that firmware fix to the fix for “SD card corruption” bug today.

          Reply ↓

19. Hi Bob,
    I recently got a new Elite HP5 and before putting it out in the field, I loaded your upgrades with those much wanted features. I tested the camera at home and to my dismay, it experienced run on triggering. Flash screen did upgrade to Red Fox. As a test, I went back to the original firmware (thank you) and the camera did not experience run on triggering while tested.
    This was done quickly and could have been a one time event as I did not test this multiple times because I wanted to get the camera out in the field.
    I don’t remember if I had a 128 GB card in the camera for the test, but it was very possible, incase that plays into the equation somehow. I did not get the “Reformat” error message.
    Just wanted to share this if it ads info but it may be a one time event related to my camera.
    I wonder if the newer HP5’s are somehow different than your original model that you wrote the software for or that it matters if it was a Recon Force vs Spec Ops model?
    Thanks

    Reply ↓

    • Hmm — thanks for the info. That’s too bad 🙁 Haven’t seen that before, but I’ll double check this function in my next release.

      I’m not aware of any changes in the HP5 firmware.

      (I have had folks report that the the fix to corrupted SD card bug doesn’t always work 🙁 )

      Reply ↓

20. I too had failures with the older HP5 firmware — battery was dead after just one evening, SDXC card was corrupt. The more recent firmware update worked much better, but I’m still seeing corruption. This is on a SanDisk Extreme Pro 200MB/s 128Gb SDXC card.

    I’m also seeing the battery report “B100” all the time. When I recharge I know for a fact they are not 100%. These are Eneloop NiMh.

    Reply ↓

    • Rats. This is not the first I’ve heard that my fix for corrupted SD cards is incomplete. The big challenge with this bug is that it is difficult to reproduce 🙁 If you, or anyone else, has a camera + SD card combo that fails reliably with my latest firmware, please let me know. I’d be interested in “borrowing” your camera to help debug this problem further.

      Short of this, I’d be interested to know if first taking test photo/video when using a new card helps at all in preventing this problem. You can do this easily from the “preview” menu just by pressing the “E”(enter) button. It will take a photo (if in trail camera mode), or a video (if in video mode), and then automatically arm itself. This step causes the necessary directories to be created on a newly formatted SD card. I think “corrupt SD card” bug occurs when the firmware tries to create these directories on the first trigger, but confirming data is hard to come by.

      Re: Battery meter. The enhanced info-strip in my firmware just displays the Browning factory battery status, which just isn’t that accurate, even when the “battery type” menu is set correctly (in your case to NiMh). Doe the on-screen battery meter in preview mode show the same value as the info strip?

      Reply ↓

      • I always keep at least one video on the card at all times so I am not tripped up by the first-time corruption. That trick definitely helped. I don’t have a lot of data nor can I come up with some pattern when it fails. I always do 20s videos.
        I will get back to you on the battery reading it doesn’t match preview mode.
        If you have a debug version of the firmware I’d be happy to try to run that for a while to see if it reproduces.

        Reply ↓

        • Just so I don’t forget it, I’ve added “incorrect battery meter in info strip” to my list of bugs (“issues”). I’ll await your confirmation before working on it, though.

          On the corruption issue, the challenge I face now is reproducing the problem so I can figure out come up with a new hypothesis. When this was first reported, I went back to my code fix, and I believe that it is doing what is should, and reducing the clock speed on the SD card. This suggests the remaining bug isn’t directly related to clock speed. If I come up with a new hypothesis and fix, I’ll touch base with you for a test.

          -bob

          Reply ↓

21. I’m wrong about the battery meter. I found that after 150-200 20s videos, it finally starts dropping below 100%. I had never collected that many so never saw it drop (unless it hit that drain-the-batteries situation). So, not a bug.

    Not related, but I have been having a hard time getting the time/date change to stick. Maybe there is some nuance in how to exit setup mode that I’m doing wrong… I’ll RTFM.

    Also random item I’ve observed: after I turn the unit on, I am not seeing the splash screen. However if I cycle power with the SD card out, I always see the “insert card” screen right away followed by the splash screen after inserting the card. Not too many data points yet, I’ll monitor that to see how reproducible it is.

    Reply ↓

    • Thanks for following up on the battery meter. I’ll remove it from my bug list.

      After you set the time, make sure to press the “E” (Enter) key in the center of the up/down/left/right button cluster. This should save the time you set, an return you to the previous menu. Pressing the “M” (Mode) button will also take you back to the previous menu, but without saving the time (or, in general, a new setting).

      The “no splash screen” behavior you’re seeing is consistent with a corrupted SD card. The contents of the card are so confusing to the camera, that it crashes the firmware before the camera can boot. I bet putting in a newly formatted SD card will fix this problem. Your PC (or Mac) is likely able to reformat the corrupted card.

      Reply ↓

    • Good evening.
      I always use the Sandisk RescuePRO® Deluxe software from LC Technology.

      Only after recovering the records do I format the memory card.

      That’s the tip.

      Sincerely, Erik from Brazil.

      Reply ↓

22. Good evening Mr RobertZak.
    Greetings from Brazil.
    After months of my Spec Ops Elite HP5 working perfectly with your firmware, today I went to check and the memory card had been corrupted.
    After recovering the corrupted card, I saw that the camera recorded for 5 days before crashing.

    I used a 128GB Sandisk Extreme SD card.
    I’m going back to the 128GB or 64GB Sandisk Ultra card.

    I saw that a new version of the firmware came out this month, has anything changed in relation to the recording speed of the memory cards?

    Thank you for your incredible work.

    Translated with DeepL.com (free version)

    Reply ↓

    • Unfortunately, my latest release does not have an update for the “data corruption” issue. Apparently, the root cause(s) of this bug continues to elude me 🙁 I do believe it’s related to the firmware trying to operate the SD card reader at a faster speed than the hardware actually supports. So using SD cards with the slowest speed possible helps.

      The fact that the camera worked for 5 days before corrupting the card is significant information, and points to a failure mode I haven’t yet considered. Can you tell me more about the files that were captured during this 5-day period? Video or still? Length of video (or burst size for stills)? Day and/or night?

      I do hope to get to the bottom of this bug, eventually.

      Reply ↓

      • Good morning Sir.
        I’m going to use the slowest card I have, the Sandisk Ultra 64GB.

        Here’s a summary and the files to download, if you prefer.

        There were 17 files in total, all 30-second videos at 1080p/60fps.

        15 videos during the day
        02 videos at night

        First registration:
        05/01/2024 09:23 AM
        Last entry:
        05/05/2024 10:53 AM

        Link to download the videos in a new post, because I don’t know if the blog system will consider it spam.

        Sincerely, Erik.

        Reply ↓

        • Got it! Thanks for these details. I’ll order a SanDisk Extreme 128GB card, and take some logic analyzer traces as the camera triggers for 30 second videos. Hopefully, I will find the spot where the clock frequency is above the 50 MHz the SD card reader seems to be able to handle reliably.

          Reply ↓

        • I just released a new version (dated 5/31/2024) which has (the final!) fix to the sd card corruption issue. It turns out I understood the problem — the SD interface in the camera is unreliable beyond 25 MHz clock speed. Unfortunately, my first fix did not cover all the code paths by which the SD interface could be set to a higher frequency. I purchased the same 128 GB 200 MB/sec SanDisk Extreme Pro SD cards that you were using, and was able to confirm that indeed they were sometimes operating at 50 MHz with previous firmware. After that, I went through the code exhaustively and patched out all the transitions to clock speeds above 25 MHz. Verified on the same SD cards. Let me know if you still run into this problem with the new firmware.

          Reply ↓

      • https://mega.nz/folder/sCFBDKiA#dbqwq38uEqJhFMRRc_iEpg

        Reply ↓

23. Good afternoon, Mr. Robert Zak.
    I saw that a new firmware update has come out and I’m going to see if I can install it on my Spec Ops Elite HP5 which already has your previous firmware.

    I want to thank you for all your development work and for allowing cameras that were previously unused to be used again.

    There is a Browning importer here in Brazil now and I bought another Recon Force Elite HP5 from him just over a week ago and twice it crashed with the same problem in the forest.
    It crashed after only 1 day in the forest and the other time it crashed after 3 days in the forest.
    The first time I used a 128gb Sandisk Extreme Pro card and the second time I used a 256GB Sandisk Extreme card.
    The seller exchanged the camera for another sealed one and it is still in the forest.

    Apparently Browning hasn’t corrected this factory problem yet, since this camera was defective. I hope that the new camera that has been replaced is OK.

    I think I’ll see the new camera by Sunday and take the opportunity to install the new firmware available on my old Spec HP5.

    Let me know if everything went well.

    Thank you.
    Erik from Brazil.

    Reply ↓

    • I hope you have kept at least one camera that is failing “reliably” so that we can confirm my new firmware fixes the problem 🙂

      I don’t believe this is a manufacturing defect with the camera. This is marginal behavior, which mixes together the normal variation in camera hardware, the normal variation in SD cards, and edge cases in the error handling code in the SD card library. Unfortunately, the whole trail camera ecosystem is based on a “replace if failed” model, so it’s really the only thing that your supplier can do. I believe there are cameras that may be less likely to exhibit this failure with a given SD card, but they all have a probability of failing. In the US, I’ve heard Browning respond with advice to “use slower SD cards” — which the SanDisk Extreme Pro’s you’re using certainly are not. This will likely work, but precludes using the newer, larger capacity SD cards, and so is not very satisfying. Especially, since by listing SD cards supported up to 512 GB on their advertising material, Browning implies that any variety of SD card up to 512GB should work with their cameras.

      I also believe that Browning (actually Prometheus Group, in Atlanta, Georgia in the US) lack the technical resources to debug this problem on their own. I think they rely on their off-shore IP providers for all the hardware/firmware development. These IP providers likely charge $$$ to debug problems, which leaves Browning little incentive to chase down these difficult to find bugs.

      On the other hand, having spent a considerable amount of time developing tools, and debugging this problem, I’ve already done the hard part. Perhaps Browning will read this post, and send a copy to their firmware supplier. If this happens, we should see a firmware update for the HP5, and a new firmware version listed on new cameras. But I’m not holding my breath.

      Reply ↓

24. Good morning.
    This SD card problem really does affect some and not others.
    There are cameras that I use the fastest cards and I don’t have any problems, in fact, so far I’ve only had problems with two, the spec ops elite hp5 which has your firmware and has solved almost all the crashes.

    And this new recon hp5 that I replaced, but I haven’t been to see if it’s working properly, without crashing this new replacement.

    I think I’ll check the cameras this afternoon and update with the new firmware.

    The slowest cards for sale that I can find today are the “Sandisk Ultra” cards, which are the cheapest. Even so, they’re 30 Mb/s write and 140 Mb/s read.

    Do you have any memory cards in mind to recommend?

    Sincerely,
    Erik.

    Reply ↓

    • I didn’t mean to support Browning’s “company line” — I’m not aware of any new SD cards with sufficiently low bandwidth to avoid this problem.

      A firmware fix is definitely the right answer. Hopefully this most recent release works. Let us know.

      Reply ↓

      • Good afternoon, Mr. Robert Zak.

        I just got home and unfortunately, the card was corrupted and the batteries were out of power.

        I left the Sandisk Ultra 64GB card the last time I went, and even with the slowest card I have, it still had issues. It’s worth noting that this problem rarely occurs.

        I took the new firmware on another Sandisk Ultra 64GB card, but the camera wouldn’t load the firmware and didn’t enable the installation of the new firmware. Using my cellphone’s internet and a memory card reader, I downloaded the firmware again and noticed that you posted a new one. The firmware I took had about 400 KB, but the one I downloaded in the morning in the forest was over 4 MB. I also saw your note on GitHub mentioning that you recompiled it due to missing files.

        I installed this new firmware and everything worked fine. I replaced the batteries with new ones. When I check it again, I will inform you of the result.

        After recovering the corrupted card, I even found a puma recorded.
        First video: 05/19/2024 at 09:14:13 AM.
        Last recorded video: 05/29/2024 at 01:23:10 PM.
        In total, there were 45 videos of 30 seconds each.

        Sincerely,
        Erik from Brazil.

        https://i.postimg.cc/7ZY3qVDg/IMG-9596.avif
        https://postimg.cc/MvNMD1nT

        Reply ↓

        • Excellent. This will be a good test case. I have my fingers crossed for more puma and no card corruption!

          Reply ↓

25. Good morning.

    I have good news and bad news.
    I went yesterday, the 10th, to see the trail camera with its new firmware and it was working perfectly using the Xtar 1.5V rechargeable batteries and a 64GB Sandisk Ultra card.

    It recorded 18 files.
    first: 06/02/2024 at 10:23:55 AM
    last: 06/09/2024 at 03:03:27 PM

    Bad news, the new Recon Force Elite HP5 camera, which has already been replaced once, corrupted the files in the second week of activity, in the first week there was no problem with the camera.
    I changed the detection setting from 0.1s to 0.7s, I don’t know if it will influence, but I did it.

    Sincerely,
    Erik

    Reply ↓

    • Just to be clear, both the “good news” and “bad news” cameras have my new firmware? Can you confirm the current firmware version from “update firmware” menu from both?

      Reply ↓

      • Good afternoon.

        Only the Spec Ops Elite HP5 camera is on its penultimate firmware, I haven’t yet updated to the latest one on the site today. I only have one camera with your firmware.

        The bad news is that a camera I bought recently was exchanged for a Recon Force Elite HP5 using the factory firmware, meaning that even if I exchanged the camera for a new one, it still had the same defect, meaning that there are still cameras manufactured recently by Browning with the same defect.

        This second new camera lasted 10 days in the woods before crashing, using Sandisk Ultra 64gb and fully charged batteries.
        I can’t tell you which firmware came from the factory, as the camera is in the woods.

        The next time I go into the woods, I’ll take a photo of the firmware that came with it so we can see if it’s still the same as the old cameras I have of the same model.

        Sincerely,
        Erik.

        Reply ↓

        • Sorry — didn’t mean to be demanding 🙂

          I just wanted to make sure that my firmware since 6/3/2024 wasn’t corrupting cards. (The 6/5/2024 release just adds an unrelated timelapse mode feature). The fact that it isn’t (so far) leads me to hope that I’m finally to the bottom of this tricky bug and can continue to work on other things.

          It is disappointing that Browning hasn’t released their own firmware fix for this problem. I predict that when you visit it in the field, the RF HP5 will have the same Browning firmware version that has shipped with these cameras since this model was first introduced.

          Reply ↓

          • I recalled that I had made a video of the first camera that malfunctioned with the original firmware before returning it to the seller weeks ago, and I recorded the camera’s menus. I took a screenshot of the video so you can see the firmware version.

            I do not understand why some cameras fail and others do not, despite having the same factory firmware. I believe there may even be a hardware defect involved in the manufacture of the camera. In the video below, the recording does not stop, and this Recon HP5 has never had any problems.

            https://youtu.be/vXn5cN4Og24

            Here is the firmware of my penultimate camera, which was returned for exchange with the local seller here in Brazil:
            https://i.postimg.cc/nzSqmLfB/IMG-0679.jpg

            I visited Browning’s website and found that there is no new firmware for the HP5. However, I noticed that there is firmware with a fix for cards from another camera.

            I am not knowledgeable about code programming, but would it be possible to use lines of code from this firmware to help correct the HP5?

            I apologize for the layman’s question above, but it was just a thought I had.

            https://browningtrailcameras.zendesk.com/hc/en-us/articles/1260802687030-BTC-PATRIOT-FHD-U3-Speed-Rated-SD-Card-SWU

            Yours sincerely,
            Erik.

          • Never underestimate the complexity of a modern piece of electronics  Here is a detailed description of the bug, provided free to you, or any camera manufacturer out there who might be interested 🙂 Apologies — it is necessarily somewhat technical. I hope most of it survives translation.

            Your intuition that the same firmware should behave the same in all hardware, unless the hardware is “broken” is good in general, but it’s not perfect.

            The short answer is that marginal interface timing, semiconductor device variation, interface design, and firmware error handling code can lead to probabilistic failures.

            But I know you want the longer explanation 🙂

            I believe that the root of this bug is the electrical interface by which the camera transfers data into and out of the SD card. In its simplest from, this is a “clocked, parallel data transfer” interface. It consists of a clock signal, and a set of 4 parallel data signals. The clock signal is a periodic square wave at some nominal frequency – let’s say 25 MHz. On the rising edge of each clock signal transition, the destination samples the value of the 4 parallel data signals produced by the source. Over a series of many clocks, data is transferred 4 bits at a time.

            There are rules for this type of interface on the validity of the data. These rules include restrictions on the “setup time” – the time before the rising edge of the clock that all 4 data signals must be stable and valid; and the “hold time” – the time after the rising edge that the data must remain stable and valid. As long as the hardware meets these two requirements, data is transferred reliably.

            If, however, any of the data signals change within the setup and hold windows, then there can be errors.

            One thing that can affect setup and hold windows is “process variation” – both between different integrated circuits, and even within the same integrated circuit. As good as it is, modern integrated circuit fabrication technology (“process”) is not perfect. Thus, the speed of the transistors used to implement the SD card interface vary by a small amount.

            The speed of transistors can also be affected by temperature.

            Thus “Good Parts” do not have identical timing characteristics. Instead, they are variable in some distribution of process and temperature behavior that the vendor specifies.

            At low clock frequencies, this variability can often be ignored. But at higher frequencies, and higher data rates, process and temperature variability becomes more of an issue.

            The more temperature and process variation between camera and SD cards, the more of a chance that sometime, somewhere, some data bits will be incorrectly sampled, resulting in corruption of the data transferred. To accommodate this, the SD card interface contains a number of error detection and correction mechanisms.

            For example, when transferring a block of data during a write operation, each “side” of the interface keeps track of a “digest” of the data. The “digest” is a small combination of all the data in the transaction . It could be something as simple as a “sum” of all the data elements (called “checksum”). The SD card specification uses a more complex “Cyclic Redundancy Code” (CRC), which covers more types of errors. But the idea is the same – if the data received is different than the data transferred, the CRC values will be different.

            After each data transfer, the source side sends over the CRC it has calculated. The destination side then compares this value to the CRC it has calculated. If they are the same, the receiver assumes the entire data transfer contained no errors. If they are different, the receiving side discards the data and asks the sender to retry.

            If too many transfer errors are detected, the firmware responds by lowering the clock speed.

            This sounds like it should work, right?

            Wrong. A correct CRC check does not guarantee that the data was successfully sent. This is because there are many possible data values that generate the same CRC. The CRC check merely reduces the probability that a data error makes it through the interface undetected. If you keep sending data through a marginal interface protected by a CRC check, eventually some bad data will slip through.

            All this as prelude to what I think is going on.

            Starting in the Edge and Elite series cameras, the SD library introduced new code which allowed the camera to operate at up to 50 MHz, vs. the 25 MHz limit of the Advantage series cameras.

            This was likely an incidental change, intended to keep the library up to date for other applications, as the higher clock speed is not required for the any camera function or speedy operation.

            When mounting an SD card, the firmware sequences the clock frequency from 390 kHz, and then to 25 MHz, and then (if the SD card is capable) to 50 MHz.

            On these cameras, operation of the hardware is marginal at 50 MHz. That is, either due to process or temperature variation in the camera SOC or the SD card electronics, or noise introduced by operation at higher frequency, the setup and hold times for writes to the SD card are sometimes met, and sometimes not. This results in data that is sometimes corrupted going over the interface.

            When this happens, a CRC error is (almost always) detected. Upon detection of this error, the firmware drops the frequency down to 25 MHz and retries the write operation.

            Now let’s look at some cases:

            With (now very) old SD cards that cannot operate at a 50 MHz clock, everything is good. The firmware always operates these cards at 25 MHz, and data transfers are reliable.

            For slower 50 MHz-capable cards, errors occur immediately and copiously, and are very likely detected by the CRC check. When this happens, the firmware kicks down to 25 MHz, and the camera operation proceeds. We perceive this as the camera “working”, even though, from the firmware’s perspective, the writes to the freshly mounted SD card are always “failing”. These failures are effectively hidden by the error handling code paths in the firmware dropping the clock frequency.

            With more capable (higher speed) SD cards, errors occur less often. The rate at which these errors occur also depends on the process/temperature variation for the specific SD cards and the specific camera instance, as the setup/hold times become more or less marginal. As a result, many (in some cases most) write operations succeed, even at 50 MHz.

            The result of this is that the firmware keeps transferring data at 50 MHz. It’s possible that some SD/Camera combinations never fail at 50 MHz, but some (many?) do. Occasionally.

            When such an error happens, it is likely detected by the CRC check, causing the firmware to drop the clock frequency down to 25 MHz.

            However, like someone who keeps rolling dice, eventually the interface gets “snake eyes”. As the firmware keeps writing data to the card at 50 MHz, a corrupted block of data will inevitably pass the CRC (or other) error check. When this happens, the bad data is written into the card. If this happens while the firmware is updating the file system (e.g. to create or open a new file), the file system will be corrupted.

            It is a fair question to ask how other devices successfully use the higher speed SD cards. I believe that the answer is that they take advantage of features in faster SD cards which allow the firmware to dynamically calculate the setup/hold/sample times, and then use this information to update control registers for the clock and/or delay settings on the data signals.

            For whatever reason (possibly to reduce trigger delay), I find no evidence that the Browning firmware does this.

            This has been a long answer, and I could be wrong on the details. I don’t have the test equipment and documentation that would be required to know for sure. But I bet I’m pretty close. And it at least gives an example of how marginal interface timing, semiconductor device variation, interface design, and firmware error handling code can lead to probabilistic failures. These types of bugs are among the most difficult to debug – especially for products (like trail cameras) – whose production involves different companies, and different engineering teams.

            Now I’m really hoping that my newest firmware fixes the problem

            -bob

            PS: I noticed the earlier firmware update for the Patriot. It certainly sounds familiar, but I do notice the symptoms listed are slightly different. If it’s the same root cause, it may well be that the firmware fix for the Patriot could be incorporated into other camera models by Browning. But I suspect this fix addresses a different variant of this bug, and is already in the firmware for (later) Browning models. I have not reverse engineered the Patriot firmware, so I’m not sure.

26. Good afternoon,

    I understood most of the explanation. Nowadays, the translation provided by deepdl.com greatly facilitates understanding.

    I hope that the texts I write are well translated, so that everyone can comprehend them adequately.

    Regarding CRC, I have had experience with this type of verification in the 2000s when I used to download series. The files often came in multiple .rar archives accompanied by a .sfv file to verify the data before extracting with QuickSFV. At that time, I used to watch Smallville in xvid and divx formats.

    Returning to the topic of cameras:

    I considered another possibility that might be causing errors in the camera’s communication with the SD card.

    If my considerations are incorrect, please treat them as just another thought I had. (laughs)

    I use XTAR AA lithium batteries in the cameras. In some online reviews, I observed that most AA lithium batteries exhibit a high level of noise. This noise might be contributing to the camera’s defects, especially if it is already prone to issues.

    Sincerely,

    Erik

    Reply ↓

    • Not sure how we survived without computer translation 🙂

      I haven’t checked the noise on the AA lithium batteries. I could see where noise from the little switching power converter could be substantial, are there are typically not a lot of filtering going on in the small volume. You’re right that this could make the problem worse. However, I know of others that run their Browning cameras on Li+ batteries without card corruption; and who have had card corruption without Li+ batteries. So I don’t think Li+ batteries are determinative of this bug.

      Reply ↓

27. Dear Bob,
    I have tried the new upgrade for the BTC-8E-HP5 but one of my cameratraps is giving me the following problem:
    after startup (the countdown to activation) the cameratrap activates, but then the power screen immediately restarts with the countdown.
    I have tried to restore the factory firmware but the problem persists.

    Can you help me?

    Barbara

    PS
    In our field experience, this Browning trailcamera model is far from satisfactory. The photo quality is poor, the video quality is barely acceptable and there are a lot of operational problems.
    Uffa

    Reply ↓

    • Sorry to hear about your HP5. The fact that it behaves the same way with factory vs. my custom firmware suggests that the problem is not some variant of “corrupted SD card” bug.

      It sounds like there is some consistency check which is failing when the camera tries to go to sleep, causing it to reboot. I haven’t seen this problem before.

      You can try doing the “Verification” test sequence in the internal test mode (with factory firmware). See: https://winterberrywildlife.ouroneacrefarm.com/2021/08/31/hidden-test-mode-in-browning-trail-cameras/

      This internal diagnostic may, or may not provide more info on your camera’s fault, but it’s an easy place to start. Let us know what you find, and I’ll do my best to recommend next steps.

      Reply ↓

28. Good evening Mr Robert.
    Making a comment to update the information.

    The Spec Ops Elite HP5 camera is still going strong with the penultimate version of its firmware, in fact, it recorded a huge mountain lion.

    The new Recon Force Elite HP5 camera, which has already been replaced once by the local dealer, has corrupted the card again, twice in just over a month, using the original factory firmware.

    On Saturday or Sunday I’m going to update it to your firmware.
    I thought about having the camera replaced again, but I’m afraid it’ll be worse.

    Sincerely,
    Erik

    Reply ↓

    • Thanks for the update!

      Reply ↓

29. Good afternoon, Mr. Robert.

    Here is my update for this week.

    The Spec Ops Elite HP5 has been running without any issues for over a month now.

    Yesterday, I also installed your firmware on a Recon Force Elite HP5. I decided to install it because the camera was corrupting the memory card. This is a new camera that has already been replaced by the local vendor.
    However, the new camera exhibits the same defect, although less frequently: there have been 3 occurrences in one month. I check the camera weekly.

    Reply ↓

    • This is great news! Thanks for the update.

      Reply ↓

30. I’ve been using the latest firmware and am reporting that after many hundreds of video the camera has been rock solid. No drained battery, no SD card corruption.
    Thanks for all the hard work you’ve put into this, it is greatly appreciated!

    Reply ↓

    • This is great to hear!

      Reply ↓

    • Hi Chris,

      What size cards are you using?
      I did not know there was a fix to the card corruption problem.
      I have experienced it only once in awhile and
      I attributed it to a bad SD card.
      Great to hear you are having no problems.
      I’ll have to upload the newest version on
      the BTC 7e HP5 cams I have.

      Best
      Tom

      Reply ↓

      • Tom, I have been using the SanDisk Extreme PRO 128GB SDXC UHS-I Memory Card.

        Spec sheet says:

        SD Bus Mode: UHS-I
        SD Speed Class: Class 10
        UHS Speed Class: U3
        Video Speed Class: V30

        Chris

        Reply ↓

        • That’s very interesting. Erik in this thread also used the SanDisk Extreme PRO 128GB SDXC UHS-I Memory card, which failed repeatedly on some cameras. Following his experience, I bought a couple of these. They were “great” in as much as they failed reliably with the older firmware, allowing me to figure out what was going on, and (critically) to test whether I had fixed the problem or not.

          Reply ↓

        • Thanks, Chris. I am going to try the 256GB Sandisk card. It has a 120mb/s bus speed.
          It works on some of my BTC 7e HP 5 cameras, bot not on others. I only check this location once a month
          because its in a tough spot to get to. I use auxiliary 12 volt batteries on all my cams.

          Reply ↓

31. Good afternoon,

    Last Thursday, I checked the Recon Force Elite HP5, which was having issues with SD card corruption. It remained error-free from July 11th to July 18th; the SD card was not corrupted with your firmware.

    I believe the latest firmware has a small bug, as several videos show a black screen in the first frame. This occurs on both the camera and the phone, resulting in a black thumbnail. It is necessary to press “play” on the camera to see what triggered the recording. This problem does not occur at night, only during the day.

    https://youtu.be/dmWYVykdLj8

    Aside from this minor detail, everything worked well.

    I am uploading the video to YouTube and providing some files for download in the video’s description. Only the first frame is black.

    https://we.tl/t-uaWMgwoh6W

    I have the Spec Ops Elite HP5 with the previous firmware, and this minor issue does not occur.

    Sincerely,

    Erik

    Reply ↓

    • Darn. I’ll add this to the issue list, and see if I can reproduce. Thanks for the examples! Can you confirm what settings you are using? (especially any of the new settings in my firmware). Thanks!
      -bob

      Reply ↓

      • Yes, I can.

        – video only
        – HiGH photo quality
        – 30 second video
        – ultra video quality
        – smartIR ON
        – fast shooting
        – photo delay in 1s
        – temperature in degrees Celsius
        – long-range detection
        – IR at long range

        Just a reminder that the Spec Ops Elite HP5 with its penultimate firmware doesn’t have this, only the Recon HP5 with the latest firmware.

        Everything else is off.

        Reply ↓

        • Got it. Thanks.

          Does this problem happen with every video? Or just occasionally, on some videos? (I just tried it on a handful of video capture in the lab, and didn’t get the behavior)

          Reply ↓

          • Unfortunately, I deleted most of the videos on my cell phone, as I usually only leave them with rarer animals. If I hadn’t deleted them, I would have been able to count the videos with this problem.
            I’d say it was half of the videos, more or less, remembering that this problem only occurred with videos during the day.

            I used a 256gb Lexar 1066x memory card.

            I don’t know if this card could be the problem.
            I changed the card in the camera, but I can’t remember which one I left installed this time.

            The next time I go, I’ll let you know which card I had installed and if there were any problems.

          • I decided to improve the data. I used the sdcard data recovery program and selected the files that were related to the recording with the latest firmware.

            I was mistaken that it was half and half.

            Total files: 236 files, 30 seconds.
            Normal daytime: 63 files
            Abnormal daytime: 107 files
            Night: 66 normal files

            The percentages are approximately:
            – Normal day: 26.69%
            – Abnormal day: 45.34%
            – Normal night: 27.97%

            Just a note, the black thumbnail was seen on the viewfinder of the trail camera itself and on the tablet I use.

            On my pc with winndows 10 pro, the thumbnails are not black, you only notice them when you play the video, so there is a black frame.

            Changing the subject: I’ve sent a message on the EEPROM post.

          • Thanks for tracking down this data. Here’s a theory that I’m hoping we can prove/disprove with your file sample set.

            When waking up to take a new daylight video, the camera firmware uses the exposure values it calculated at the end of the previous video as the initial “guess” for the first frame in the current video. It calculates the new exposure value frame by frame after that. Thus, if the prior video were taken (say) in direct sunlight, and the next (abnormal) video taken in low light, that could cause first frame to be black (way under exposed).

            Can you check the videos taken immediately prior to the “abnormal” daytime videos. If these prior videos are taken in a lot of light (maybe false trigger when looking directly into the sun?), that could lead to the behavior you’re seeing.

            Of course, if you tell me that this is the same location you used in a prior set that didn’t have the problem; or if the prior videos are taken in similar lighting conditions, that will send me back to the drawing board. Don’t worry — I can take it 🙂

            -bob

            PS: Haven’t seen any new comments on EEPROM post. Possible that they didn’t get committed? Please email me if “comments” are working.

32. Good afternoon.

    I analyzed some videos to see your theory, there are some videos that the ambient light changes, for being different times during the day, but it was not a very big change, there are several videos that are in sequence and even so present the black frame.

    Maybe it’s the memory card I’m using. Next time I go, I’ll check if the other card has the same problem.

    Here’s a sample of these 3 videos in sequence.
    https://we.tl/t-Lf6QB1mADP

    note: I’ll send the message to the EEPROM post again, as I sent links, it may have been considered spam.

    Reply ↓

    • OK — so the theory about exposure settings is disproven!

      Could be the SD card. I don’t understand why this would be so, but I don’t understand why changes I made could cause the problem either.

      I did notice some funny business in the battery reading at the bottom of the info strip for the first few frames. The battery meter reads ~82/83 (%) before jumping up to to 97/100%. Are you running the rechargeable Li-Ion AA’s in these cameras? Another experiment to try would be to change these.

      Reply ↓

      • Correct, I use AA lithium rechargeables in all my Browning trail cameras, I also noticed this variation in the Spec Ops Elite HP5 with your firmware, but no thumbnail problems.

        The next time I go, I’ll change the battery again, although these were charged so that I could do the firmware update and not run the risk during the update.
        This little black screen bug doesn’t bother me at all, just that the camera doesn’t crash anymore and is 100% functional, that’s all I wanted. And to think it’s a brand new camera.

        Looking at Browning’s website, I saw that they sell 64GB SDHC memory cards, not SDXC. I can’t find any 64GB cards that aren’t SDXC, only the 32GB ones in Sandisk’s cheapest series are SDHC.
        Maybe because of this card corruption problem, Browning only sells slower cards and with this old memory card technology, SDHC.

        note: I’ve posted for the third time on EEPRON’s post, now I’ll be using googlephotos for the images.

        Reply ↓

        • I’m glad to hear that the dark frames aren’t keeping you awake at night. Still, I’m interested in finding out if they’re being caused by something in my firmware. I’ll keep this issue open on the Github site while we try to rule out other causes and/or until I can recreate the problem.

          Interesting that Browning is only rebranding slower/lower capacity SD cards. Given that a new set of AA EUL batteries will produce greater than 128GB of daylight video, we’ve switched over to 128/256 GB cards to get the most out of our longer running sets. Since you’re using the (lower capacity) rechargeable Li-Ion batteries, you may not miss much of anything 64 GB cards.

          Just replied to EEPROM question on that thread.

          Reply ↓

          • Update.

            I went to see the camera today and even using the Sandisk Ultra 64gb card several videos showed the first black frame.

            Otherwise, the camera worked perfectly and didn’t crash.

            Sincerely,
            Erik from Brazil.

          • Thanks for this data. I still have the issue open. Please continue to let me know if you notice any patterns in this behavior. I’ll see if I can spend a little more time trying to recreate it locally.

33. Hello Robert, I’ve had issues with 0kb files on my BTC-8DE Spec Ops Edge cameras. Before I upgraded to your firmware, as many as 30% of videos on some cameras were 0kb files. However, the remainder of the videos were OK.

    I’ve installed your firmware but I am still getting some 0kb video files. Until now I haven’t been able to spot a pattern pertaining to the 0kb video files. Today I noticed an anomaly in the files’ date fields that might be a clue. When reviewing the contents of an SD card with 80 video files from a Spec Ops Edge camera named WC2 in Windows Explorer, I noticed something strange with the “Date” and “Date modified” fields.

    Of the 80 video files, 77 were playable. For these, the “Date Modified” field shows the correct local time, Pacific Daylight Time (UTC-7), which usually matches the timestamp in the videos’ data strip but sometimes is one minute after the videos’ data strip timestamp. However, the “Date” field is usually 7 hours behind the Date Modified timestamp – that is, “Date” is UTC-14. Occasionally, the “Date” field is 7 hours and 1 minute behind the “Date Modified” field (vids with 7:01 difference between “Date” and “Date Modified” are the same where “Date Modified” is 1 minute after the data strip timestamp). This is strange – why is “Date” using some nonexistent UTC-14 time zone, and is it a coincidence that the difference between “Date” and “Date Modified” is approximately the same as between “Date Modified” and UTC, and what’s up with the occasional 1 minute additional difference?

    Of the 80 video files, 3 were 0kb. For these, the “Date” field is the same as the “Date Modified” field. I happened to have another camera at the same location as WC2. This second camera recorded videos with “Date Modified” that is the same as the “Date Modified” for two of the three 0kb files from WC2 – meaning that for the 0kb files, the “Date Modified” and “Date” fields are showing the correct time that WC2 attempted to save the 0kb videos. Watching those two videos from the second camera that were taken at those times, I didn’t notice anything special – they were in daylight and were of people and deer strolling past the cameras.

    Why would the 0kb files have the correct “Date” and “Date Modified” values, while the normal playable videos would have an incorrect “Date” value? Maybe the camera is doing some kind of processing after the video is taken, and that process creates the (incorrect) “Date” value, and so when the process fails the new “Date” value isn’t created? Is the variability in the “Date” value the cause or an effect of the camera’s failure to successfully store the video?

    Reply ↓

    • Let’s start with the easiest question – why the occasional 1-minute difference? I think this is just caused by the firmware sampling the current time at slightly different points. The banner and file creation time are sampled at the start of the video; and I believe the “modification” time is sampled at the end of the video. These will be different by the length of the video. If the video runs over the minute barrier, then the times appear 1 minute apart.

      Now, to the harder question – “What’s behind the 0-length videos”?

      I’m going to start by assuming that you’ve ruled out things like weak batteries (by using new batteries), and a flaky SD card (by swapping SD cards). You mentioned that a second camera caught the video missed by 0-length video, and that it was during the day. This argues against weak batteries, in any case, since these start by causing problems at night. I’m also going the assume that you meant SpecOps Edge, model BTC-8E (not BTC-8DE).

      I don’t understand the 7 hour difference between “Date” (Creation Date?) and “Date Modified” in the “valid” files. I just ran a simple test on an Edge (BTC-8E) and couldn’t reproduced this. Maybe I didn’t wait long enough?

      In any case, I’m more interested to learn that my latest firmware, which has a fix for a different problem, causes this camera to behave differently. The only thing that I can think of is that your camera is having trouble writing to the SD card, and that lowering the clock frequency, as I do to avoid a different problem, somehow partially fixes this problem. If it’s not the SD card, it could be something in the path of SD card writes which causes them to fail, occasionally. I’m not sure what this would be, or how to fix it.

      Sorry – this has been a long response without much helpful in it 🙁

      Reply ↓

34. Hello Bob,

    I seem to have lost where my last two posts are relating to SD card corruption in Browning 7E/8E cameras.

    Could you point me in the right direction?

    Thanks Sir.
    Mike

    Reply ↓

    • Sure. You can find them in the comments section of:

      https://winterberrywildlife.ouroneacrefarm.com/2024/07/21/deep-tech-hacking-trail-camera-firmware-3-business-considerations/

      PS: Working on a reply to your latest comment

      Reply ↓

    • OK – I think I understand now. Somehow, it seems like the camera recorded some 4000 photos, then became confused and “forgot” about these, before correctly storing an additional 2400 photos.

      My theory is that the creation of the of the 104_BTCF folder (necessary after 4* 999 photos) failed, and corrupted the file system. For whatever reason, this corruption wasn’t so bad that it crashed the camera’s firmware. It merely caused the SD card file system to appear empty and the firmware happily started over from scratch.

      This sounds like a variation on the “Corrupted SD Card Bug” https://winterberrywildlife.ouroneacrefarm.com/2023/11/16/fixing-browning-edge-elite-hp4-and-hp5-sd-card-corruption/

      If you notice this problem happening with some significant regularity, you could try loading my latest firmware hacks, which contain a fix for the bug.

      I would be most interested if this fix *didn’t* solve the problem.

      PS – I’ve responded to this thread, originally in https://winterberrywildlife.ouroneacrefarm.com/2024/07/21/deep-tech-hacking-trail-camera-firmware-3-business-considerations/
      To this post, which seems more relevant

      Reply ↓

35. Thanks Bob

    Reply ↓

    • Hi Bob,
      Browning is returning my camera and my SD card They couldn’t reproduce the problem, which I fully expected. I expect this problem to be back and will let you know
      Thanks again
      Mike

      Reply ↓

      • I’m not surprised. These types of intermittent bugs are difficult to reproduce. Of course, Murphy dictates that when it does fail, it does so in the field, in a particularly difficult set to get to :/

        (Especially) If it fails again, for sure try my firmware.

        Reply ↓

36. I have a different issue with a BTC-7A. The camera will not stay in video mode. It reverts right back to Trail Cam mode. This happens if I turn the camera off and back on but more importantly it does it as soon as I set it. New lithium batteries, cleaned off the ports, tried a different battery case. Same issue.

    Contacted Browning….”you can pay to send it to us and we’ll see if we can fix it if it’s in warranty.” It’s not…just outside the warranty. They never fix anything I send to them. I own at least 28 of their cameras, thousands of dollars, and they don’t care.

    Anyone have this issue and a solution? Thank you.

    Reply ↓

    • Sorry to hear about your 7A — one of our favorite cameras. The problem you describe is consistent with a failure of the firmware to write settings to a local file system stored in the camera. The result is that the camera then always reads the old settings. I’ve seen two causes of this. The first is a corruption of the parameter file itself. This can sometimes be solved by reloading the firmware. If this doesn’t work, then it is likely that the entire EEPROM which hosts the file is no longer writable. Unfortunately, this is a much more involved fix, which I describe in: https://winterberrywildlife.ouroneacrefarm.com/2024/01/23/deep-tech-repairing-eeprom-in-browning-trail-cameras/

      I would certainly start by trying to re-install the firmware. In your comment on a different post, you say that you had trouble trying to re-install the firmware. Specifically, that you couldn’t get the “yes” option to become hilighted in the “update firmware” menu. Two things: for the BTC-7A, make sure that you find the file named “brnbtc70.BRN”. This is the firmware for this specific camera model. Second, make sure the the firmware file is in the “top level” of the file system on the SD card. I.e. “D:/brnbtc70.BRN”, and not in a subfolder on the SD card (e.g. “D:/DCIM/brnbtc70.BRN”). The firmware only looks for the firmware file in the top level of th file system.

      I’ve published the firmware image for the BTC-7A on my github site: https://github.com/robertzak133/unified-btc-reverse/blob/main/targets/btc-7a/factory-firmware-images/Baseline/brnbtc70.BRN Select the “download raw” (right of the file name) to get the file brnbtc70.BRN file.

      Let us know how you make out.

      Reply ↓

37. Hi Bob.
    Incredible research and troubleshooting work on these cameras. Your selfless dedication is greatly appreciated, thank you so much!
    In my case, I had bought 10 units of the HP5 model. They don’t have the fault in SD, but in 6 of them, the battery management is terrible and unpredictable. Sometimes it records a dozen videos, sometimes 50, sometimes 100 (in this case many of them are false shots)? In the field they last 1 or 2 weeks… I’ve tried changing cards, different batteries, different locations… But it persists. It’s frustrating to arrive after 1 month and a half and see so much work lost.
    I’m surprised it’s a problem with the small internal battery, it seems to be a widespread recurring fault…there are too many units.
    Any suggestions? Does it happen to anyone else?
    They are under warranty, but the sad thing is that even if they replace them, I suspect the same thing may happen sooner or later.
    *I don’t use rechargeable batteries

    Thank you very much from Spain.

    Reply ↓

    • Hola, Oscar! Glad you find the information in my posts useful.

      Sorry to hear about your HP5s. As I’ve noted in other posts and comments, the most frequent cause of “early battery drain” is associated with the internal battery (now ultracapacitor) used to store energy for the real time clock during main battery exchanges. An internal charger for this battery draws a maximum of a few mA as it’s charging. In a properly working camera, this charge current goes to a few uA after the internal battery is charged – something that takes only a few minutes.

      If you are inclined, you can test your camera with an ammeter put in series with the battery or an external power adapter. With camera “off”, you should see a current of 50-70 uA. This current is used to keep the boot controller and RTC powered. If you see a current of several mA, then it’s likely your camera has this problem 🙁

      The failure I’ve seen most often is the result of corrosion forming between the battery terminals, which effectively “shorts” them out, causing the charger to draw 2-5 mA continuously. This will deplete a new set of batteries in 10-15 days (even with no video/image captures).

      However, recently I’ve heard of several folks experiencing this problem with new cameras. This is really disappointing, as you say. I suspect there is an issue with the ultracapacitors used to store energy for the RTC, possibly a bad batch.

      I’ve heard about this often enough now that I’d be interested in getting to the bottom of it. (Fortunately) We don’t currently have this problem with any of our HP5’s. If you’d be willing to mail one of your failing cameras to me for debug, I’d do my best to fix and send back to you. This is made somewhat more cumbersome (and expensive) due to international shipping, so I understand if you’re not interested.

      In any case, I would definitely exchange the failing cameras while they are under warranty. Warranty returns are one of the few ways that Browning has to monitor issues in their supply chain :). Given your experience, I would certainly recommend testing any new cameras you receive with an ammeter before putting them out in the field.

      Hope this helps.

      Reply ↓

38. Hello Bob,

    I have another Browning 7E-HP5 with run-on trigger problem. Recorded 9300 in 3 days before batteries wore down. Did I see this mentioned someplace in your blogs?
    Happened on two different cameras this summer.
    Thanks
    Mike

    Reply ↓

    • Sorry to hear. I’ve documented this behavior in the Advantage series camera – especially the Spec Ops models. See: https://winterberrywildlife.ouroneacrefarm.com/2021/06/30/how-some-trail-cameras-fail/#run-on-triggering

      I’ve heard of it in the HP5s, but I don’t have any first hand experience (yet). The HP5s have a different thermal path to the PIR sensor, a different PIR sensor, and a different amplifier circuit vs. the Advantage, so the details of the root cause of the problem are likely different.

      You may be able to work-around this problem by increasing the “photo delay” from 1 to 5 (or even 10) seconds, and avoiding use of the “SmartIR” feature.

      I’ll also send you an email on the topic shortly.

      -bob

      Reply ↓

This site uses Akismet to reduce spam. Learn how your comment data is processed.

HTML tags allowed in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>