IPC-T5442T-ZE IPC-T5442TM-AS IPC-T5842T-ZE SMD 3.0 Smart IR Latest New Firmware From EmpireTech

All

As promised, I’ve completed my testing of this FW (22-02-18). I tested this against 4 x 5442’s in the end (3 turrets with different HW versions + 1 bullet cam) and other VOLT cameras including the 5241-Z12. As long as you use this FW with 5442’s only (based on my findings and issues with 5241 & other VOLT cams) then in summary, I do see improvements here.

Let me break down some of the key areas below:


SmartIR - This is now more on point to the recommendations I made last year and that we saw implemented early on BUT needed a little further work based on additional feedback I sent Dahua inline with SMD releases branches. Glad to say this has now made it into this release and overall works pretty well (see quick video below). With that said, there is 1 issue I have with it and that is the transition of SmartIR isn’t as smooth as I’d like. To be clear (and you can see it in the video below) its a more pronounced step ladder in its approach to kicking up or down IR strength BUT certainly the ending result (no IR washout) is what we all want to see and a marked improvement on previous SMD based releases. I am feeding back the ‘step ladder’ IR approach to see what can be done there in future to adjust it to be smoother / quicker as it was on the early SmartIR FW I tested last year after my feedback and approved wholeheartedly. Again, this is not a dealbreaker BUT I think with a little more tweaking this can be perfect. I'm also testing a 5842 SmartIR FW and on that it works very smoothly so will be looking into implementation in that code to identify differences between these for Dahua.​
SMD 3.0 - I also saw improvements here in my testing. Specifically in the areas of Target Identification (where I saw no false hits, even from deer in multiple days of testing) and in Target Acquisition Speed. To be clear, thats not to say that you'll never see false hits BUT in other versions I would have typically experienced some within this longer testing period. The latter (Target Acquisition Speed) has improved albeit I still think a little more work can be done here which would assist in tighter FOV’s. Either way this release represents an overall improvement here in my testing. As an example, I was seeing vehicles tagged as SMD hits and in reviewing the clip wondered IF the algorithm would actually target correctly and sure enough even at a distance of over 100’ from cam, the target would be acquired and tracked even as it passed foreground objects. This worked well with Human identification as well. From an overall SMD 3.0 perspective on these cams, while I think a little tweaking can be done here, I want to be clear that I think this is getting close to the limits of what is possible (theoretical max If you will) with current SOC and algorithm in use on this range of cams. Will be interesting to see SMD 4.0 this year and how that performs (I feel a comparison feature video coming up SMD 3.0 vs 4.0 etc) :)
IVS - Similar to SMD, I saw improvements in both identification and acquisition although depending on HW version and IVS rule type, this is still a little slow. While I didn’t see any mis-categorizations on this FW so far, I DID see the speed of acquisition was still somewhat delayed (for clarity: improved but delayed) especially when pushing the camera. Specifically, I noticed this more so on Tripwire rules where in a perfect storm scenario test I did (distance to target about 80ft, target crossing right to left of FOV) that there was about a 1-2 second delay in target box acquisition. This can be more problematic with super tight FOV's as although you have a more clearly definable target, if your FOV only allows it a limited time within the FOV, then you might miss a cap. Just remember pre-record is your friend here and be careful that if you rely heavily on Trips + have a tight FOV with limited time on target, to configure your rules accordingly for improved success. Reach out to me if you need any assistance on that.​


So, overall, definitely an improvement over the last FW in the areas above, just remember the caveats I call out to set expectations correctly. I’m going to feed back these additional findings to Dahua as well and have already let them know about the issues with ‘other’ VOLT based cameras such as the 5241 for further investigation by them.

HTH and as always, let me know with any questions

SmartIR Test Video - No Light On Scene Except In Background

@Wildcat_1 , thanks for your insights on this new firmware, although I sometimes get the impression that your words are very carefully chosen to limit any strong negative assessments, and potential for subsequent backlash from our favorite suppliers and camera manufacturers. For example, the broad statement that only tells us "I saw improvements in both identification and acquisition although depending on HW version and IVS rule type, this is still a little slow" leaves out the details of which hardware revisions are more negatively impacted: the newer ones, or the older/early release 5442 cameras.

Still, great to see that some progress is being made with firmware tweaks. In your opinion, is the December 2020 version still the best performing in terms of speed and accuracy of target acquisition in IVS rules, or would you characterize this new one as superior in that regard?
 
@Wildcat_1 , thanks for your insights on this new firmware, although I sometimes get the impression that your words are very carefully chosen to limit any strong negative assessments, and potential for subsequent backlash from our favorite suppliers and camera manufacturers. For example, the broad statement that only tells us "I saw improvements in both identification and acquisition although depending on HW version and IVS rule type, this is still a little slow" leaves out the details of which hardware revisions are more negatively impacted: the newer ones, or the older/early release 5442 cameras.

Still, great to see that some progress is being made with firmware tweaks. In your opinion, is the December 2020 version still the best performing in terms of speed and accuracy of target acquisition in IVS rules, or would you characterize this new one as superior in that regard?

Hey @jrbeddow thanks for reaching out and for your comments. Wanted to take a moment to respond and address your key points. Certainly not concerned about backlash which is why I go deep when reviewing and testing cams (where possible comparing against other units to highlight pro's and cons) or FW and in both cases highlighting those that need works vs those I outright recommend against. The goal being always to keep people informed and by diving as deep as possible into both cams and FW, looking for, identifying and highlighting issues so they can be improved for an overall better experience of all of us.

I try and balance the dealbreakers vs those just needing more work, hence per my update above, while none are dealbreakers in this FW, there is still room for improvement hence calling those areas out. I did mention the detail about which rule types are more affected (tripwires) above but you are right I forgot to add in HW revision specifics so I'll address that below and go even deeper across both revisions.

First, in my testing I find that you see a mix in HW revision handling of features within the FW. To be clear this is nothing new and has been going on for years when manufacturers move from 1 HW revision to another. While it would be great to think that most manufacturers would continue or adopt an N-1 strategy to releases, this is generally not the case and you find more of a hard cutover of FW support especially when a new HW revision is released (except security vulnerabilities for a limited period of time). In a lot of cases manufacturers outright stop supporting an older HW revision in FW and instead focus on the newer revision. Due to that, as I've mentioned many times before, I do give kudos and credit to Dahua for listening to feedback and specifically to their dev teams working with myself and others directly to resolve ongoing issues even with legacy HW/FW. I also do appreciate @EMPIRETECANDY helping Dahua prioritize our feedback and findings. While we know users, installers etc benefit from improvements in the FW, many manufacturers don't address or even listen (I can list many that don't do this) regardless of spend or size of account(s) so do appreciate Dahua's focus here. The 5442 range is a perfect example and I'm happy the FW is still an area of critical focus by Dahua and that we do see work being done to resolve remaining issues raised to them by myself and others. To be fair, the chipset has remained the same so that makes it easier but still happy to see S1 issues being addressed too. Also as I mentioned last year, my findings with SmartIR are relevant to the underlying SmartIR code across the majority of the Dahua portfolio hence them getting this right will not only help all of us BUT critically lead to a better experience for them (manufacturer) by implementing that particular fix across the entire portfolio IMO instead of continually reinventing the wheel.

With that out of the way, let me break my findings in this FW (22-02-18) nto further HW revision details based on my testing:

  • S1 is slightly faster at close to mid range target acquisition, S2 overlaps and generally takes it at mid as well as generally being better than S1 for longer distance acquisition*. To be clear, we're talking about 1 second (faster) on average BUT can be significant based on FOV hence calling it out
  • S1 handles speed and accuracy of targets crossing Tripwires quicker than S2 (*even at distance) BUT S2 identifies targets on the edge or periphery of Intrusion zones better than S1 which can falter and/or miss
  • S2 generally handles targets moving past foreground objects better than S1
  • S1 identifies faster moving objects quicker than S2
  • S2 processes SMD targets quicker than S1
  • S2 processes multiple rule hits (at the same time within an FOV) faster than S1 (tested with 3 x Trips + 1 Intrusion zone in FOV)

To answer your other question about this vs 12/2020, I would recommend you (and others) load this one up. As I mentioned, overall some nice improvements here and in the extended testing I did, did not see any false hits. Doesn't mean there isn't a need for improvements as I continue to mention (and have already passed this info back to Dahua) for both the 5442's and the other VOLT cams including 5241's but this certainly is an improved release in my testing. Again though, I DO NOT recommend this being loaded on 5241's

HTH
 
Hey @jrbeddow thanks for reaching out and for your comments. Wanted to take a moment to respond and address your key points. Certainly not concerned about backlash which is why I go deep when reviewing and testing cams (where possible comparing against other units to highlight pro's and cons) or FW and in both cases highlighting those that need works vs those I outright recommend against. The goal being always to keep people informed and by diving as deep as possible into both cams and FW, looking for, identifying and highlighting issues so they can be improved for an overall better experience of all of us.

I try and balance the dealbreakers vs those just needing more work, hence per my update above, while none are dealbreakers in this FW, there is still room for improvement hence calling those areas out. I did mention the detail about which rule types are more affected (tripwires) above but you are right I forgot to add in HW revision specifics so I'll address that below and go even deeper across both revisions.

First, in my testing I find that you see a mix in HW revision handling of features within the FW. To be clear this is nothing new and has been going on for years when manufacturers move from 1 HW revision to another. While it would be great to think that most manufacturers would continue or adopt an N-1 strategy to releases, this is generally not the case and you find more of a hard cutover of FW support especially when a new HW revision is released (except security vulnerabilities for a limited period of time). In a lot of cases manufacturers outright stop supporting an older HW revision in FW and instead focus on the newer revision. Due to that, as I've mentioned many times before, I do give kudos and credit to Dahua for listening to feedback and specifically to their dev teams working with myself and others directly to resolve ongoing issues even with legacy HW/FW. I also do appreciate @EMPIRETECANDY helping Dahua prioritize our feedback and findings. While we know users, installers etc benefit from improvements in the FW, many manufacturers don't address or even listen (I can list many that don't do this) regardless of spend or size of account(s) so do appreciate Dahua's focus here. The 5442 range is a perfect example and I'm happy the FW is still an area of critical focus by Dahua and that we do see work being done to resolve remaining issues raised to them by myself and others. To be fair, the chipset has remained the same so that makes it easier but still happy to see S1 issues being addressed too. Also as I mentioned last year, my findings with SmartIR are relevant to the underlying SmartIR code across the majority of the Dahua portfolio hence them getting this right will not only help all of us BUT critically lead to a better experience for them (manufacturer) by implementing that particular fix across the entire portfolio IMO instead of continually reinventing the wheel.

With that out of the way, let me break my findings in this FW (22-02-18) nto further HW revision details based on my testing:

  • S1 is slightly faster at close to mid range target acquisition, S2 overlaps and generally takes it at mid as well as generally being better than S1 for longer distance acquisition*. To be clear, we're talking about 1 second (faster) on average BUT can be significant based on FOV hence calling it out
  • S1 handles speed and accuracy of targets crossing Tripwires quicker than S2 (*even at distance) BUT S2 identifies targets on the edge or periphery of Intrusion zones better than S1 which can falter and/or miss
  • S2 generally handles targets moving past foreground objects better than S1
  • S1 identifies faster moving objects quicker than S2
  • S2 processes SMD targets quicker than S1
  • S2 processes multiple rule hits (at the same time within an FOV) faster than S1 (tested with 3 x Trips + 1 Intrusion zone in FOV)

To answer your other question about this vs 12/2020, I would recommend you (and others) load this one up. As I mentioned, overall some nice improvements here and in the extended testing I did, did not see any false hits. Doesn't mean there isn't a need for improvements as I continue to mention (and have already passed this info back to Dahua) for both the 5442's and the other VOLT cams including 5241's but this certainly is an improved release in my testing. Again though, I DO NOT recommend this being loaded on 5241's

HTH
Wow, a million thanks @Wildcat_1, I never imagined the highly detailed and thoughtful response you just provided. That completely answers any remaining questions I had on the nuanced differences in response between not only firmware versions but also how hardware revisions play into that as well.

I stand corrected and apologize if my comments came across as offensive in any way, they certainly weren't meant to be.
 
Wow, a million thanks @Wildcat_1, I never imagined the highly detailed and thoughtful response you just provided. That completely answers any remaining questions I had on the nuanced differences in response between not only firmware versions but also how hardware revisions play into that as well.

I stand corrected and apologize if my comments came across as offensive in any way, they certainly weren't meant to be.

No offense taken @jrbeddow appreciate your comments and feedback
 
No offense taken @jrbeddow appreciate your comments and feedback
By the way, I plan on following your recommendations with regards to the firmware upgrade procedure you outlined in post #95 of this thread (IPC-T5442T-ZE IPC-T5442TM-AS SMD 3.0 Smart IR Latest New Firmware From EmpireTech).

One question: is it ok to reload a saved configuration after the factory reset, or does this follow the same advice as applies to router firmwares: never reload a previously saved config onto a newly flashed and factory reset device unless you want to import the old problems back onto it. Or, is the saved configuration in this case "safe" and "generic" enough to be re-applied onto the newer firmware?
 
By the way, I plan on following your recommendations with regards to the firmware upgrade procedure you outlined in post #95 of this thread (IPC-T5442T-ZE IPC-T5442TM-AS SMD 3.0 Smart IR Latest New Firmware From EmpireTech).

One question: is it ok to reload a saved configuration after the factory reset, or does this follow the same advice as applies to router firmwares: never reload a previously saved config onto a newly flashed and factory reset device unless you want to import the old problems back onto it. Or, is the saved configuration in this case "safe" and "generic" enough to be re-applied onto the newer firmware?
You can reload BUT I advise against it. Start fresh
 
I have 2 x IPC-T5442T-ZE with a 2020 FW. Would you guys recommend me to update or leave it as is?
1646414317457.png
 
Last edited:
Just update it. This version Worth to update

I just did and happy I did it. Since the beginning I was using Chrome as browser and I thought it worked fine. After reading different posts I've decided to update using Internet Explorer. Right after logging in I've noticed way more icons in the livestream than I ever did before (see bottom left and upper right for the differences).

Internet Explorer
IE.PNG

Chrome
chrome.PNG
 
Last edited: