Troubleshooting Circuitry in Old SD49225T-HN PTZ Cameras

Xgecu arrived. Now we await the slow delivery via China post of the chips and adapter.

Meanwhile Delta did a spontaneous reboot - after five days not doing so.
 
The fact that there was still a reboot is of course annoying. :rolleyes: OK, then the problem with the reboots doesn't just seem to be the battery, because you also changed the battery with Delta. Then I can probably save myself having to change the battery on my SD49225T-HN if that doesn't fix the reboots. :( I suspect that if it happens after five days, it could also happen after just one or two days and there doesn't seem to be a direct connection between the reboots and a weak or defective battery.
 
There is some sort of correlation. It went from once or twice daily down to once in several days. Not a direct cause effect, but does have an effect. We also know zero battery causes complete non-function. Easiest solution is of course to replace the camera entirely
 
I have something similar here too. Sometimes there is no reboot for two, three or four days and then again, for example, twice a day. This different behavior can (in my opinion) not only be explained by the battery. That means I'm afraid you'll have times in the near future when the camera will reboot after just a day or two. Although of course I don't wish that for you. :)
 
You guys use an sd card, when reboots happen?
 
No and I never have. :)
 
Yes, it's better to have a reboot every few days than multiple reboots every day. :)
 
Today I changed the battery in my ptz camera, there is no change, it still does not appear in configtool and it seems to be more of a memory issue than anything else.
 
New EEPROM chips arrived from China. Now, awaiting the TSOP socket adapter to arrive via "slow boat"

Meanwhile, I thought I would install the software and driver for the XGecu programmer to get ready. Broke out my windows laptop that I keep around for such low level tasks and found just how long it has been gathering dust. We're primarily MacOS in the house and Windows machines don't get much use. Even so, I was a bit shocked to find it was back in the days of Celeron, Windows Vista, and hard drives that I had last fired it up. Funny enough, its CMOS failed checksum. How time flies while life goes on!
I likely need to get another Windows laptop to do this little project. :(
windows laptop.jpg
 
ROR!!!! That bodged on capacitor on the POE power board. I had forgotten I had added that ages ago to permit powering a microphone.
Found it in an old thread of mine.

 
Meanwhile, I thought I would install the software and driver for the XGecu programmer to get ready. Broke out my windows laptop that I keep around for such low level tasks and found just how long it has been gathering dust. We're primarily MacOS in the house and Windows machines don't get much use. Even so, I was a bit shocked to find it was back in the days of Celeron, Windows Vista, and hard drives that I had last fired it up. Funny enough, its CMOS failed checksum. How time flies while life goes on!
I likely need to get another Windows laptop to do this little project. :(
The old laptop may just need a new CMOS battery :lmao:, though that was near the peak of bad caps in PCs.
If you have any Macs with intel chips, you can always load windows via bootcamp or virtualbox.

But, you don't need to do any of that. Just use minipro and use it natively in Mac OS.

ROR!!!! That bodged on capacitor on the POE power board. I had forgotten I had added that ages ago to permit powering a microphone.
Did you test if the cap was even necessary? I'm sure a powered mic already has some decoupling. I'd be tempted to use a PTC with a resistor and leave out the cap or just use a tiny ceramic.
 
Last edited:
Wow. I have these same problems on my SD49225T-HN. Really disappointing to find out its a common problem as none of my other Dahua non PTZ cameras have had any problems throughout all the years. I finally pulled it and put the SD49225T-HN a few months ago and have it on my bench trying to figure out a suitable replacement. It would reboot / loose its memory sometimes days, sometimes weeks, then finally its gone to the point of no recovery. Waiting on a suitable replacement. Just heard there was issues with auto-tracking working correctly with the newer cameras.
 
After a few hours of fruitless work trying to get MiniPro GUI installed and running on my Mac....

1. MiniPro on MacOS will not work with the T48 programmer, not at least with the release version of MiniPro. Apparently, brewing from GitLab directly might get a revision that does support T48, but otherwise it is the land of USB error sadness.

2. OK installed the Xgpro software on a PC and got it running. Recognizes the T48 programmer (black case) and the programmer firmware update went OK. Tried to read a fresh EEPROM, but pin error after pin error. Looked ok in TSOP48 adapter. Then I notice the program is asking to use adapter ADP_F48-EX-2. On the adapter I have, it says NAND for TL866II, but on the order page it was for MiniPro Tl866Ii Plus.

The T48 is supposedly 3rd generation TL866 programmer, but maybe it expects different adapters?

I think I have the wrong adapter for TSOP48 on a T48 programmer. Ordered another adapter. Another month long slow boat from China wait!!!!!
 
That sucks.
 
From what I'm now gathering Xgecu makes their adapter incompatible between models of their programmers. The T48 (3rd Gen TL866II) won't work with TL866II or TL866II plus adapters. Given the same 40 pin ZIF socket and TL866II family, I had not expected that to be an issue.
 
After a few hours of fruitless work trying to get MiniPro GUI installed and running on my Mac....

1. MiniPro on MacOS will not work with the T48 programmer, not at least with the release version of MiniPro. Apparently, brewing from GitLab directly might get a revision that does support T48, but otherwise it is the land of USB error sadness.

2. OK installed the Xgpro software on a PC and got it running. Recognizes the T48 programmer (black case) and the programmer firmware update went OK. Tried to read a fresh EEPROM, but pin error after pin error. Looked ok in TSOP48 adapter. Then I notice the program is asking to use adapter ADP_F48-EX-2. On the adapter I have, it says NAND for TL866II, but on the order page it was for MiniPro Tl866Ii Plus.

The T48 is supposedly 3rd generation TL866 programmer, but maybe it expects different adapters?

I think I have the wrong adapter for TSOP48 on a T48 programmer. Ordered another adapter. Another month long slow boat from China wait!!!!!

Did you try to read anything else from the native adapter before you put the (add on) adapters on? like a standard 128Kx8 flash chip ? or something from a old motherboard. Just to make sure you are getting the correct voltages and make sure it reads and writes proper? I had a older HP laptop that the programmer said was working fine but would just spew errors from time to time. That was quite the rabbit hole. I ended up using my bench cloning computer and it worked fine. I was watching activity with the scope and it was clearly not right compared to the bench computer.

Here, You can use this one?

adap.JPG
 
Last edited:
  • Like
Reactions: looney2ns
That is the adapter I am now awaiting. End of April - early May estimated arrival.

I have not (for decades) had any old school EEPROMS that would fit the 40 pin ZIF without an adapter. Back then, it was cobble together your own programmer with an external power supply, parallel port, and write your own assembly code to drive the whole thing.
 
  • Like
Reactions: c hris527