A129 Pro firmware

Updated to 1.7T.
Then I formatted using dashcam (exfat)
After 4 minutes slow double beeps and then fast double beeps (or viceversa).
To resume, I had to push twice REC.
Lost almost 2 minutes of video.
 
Yep, the firmware is still pretty unstable. I have two A129Pro units now and both have some random chaotic issues as well. One of them started to beep fast/slow, freezes, shuts down, etc. The second one just shuts down by itself from time to time.

I'm starting to miss my DR900S with overheating issues. :ROFLMAO: (at least it was recording quite constantly)
 
So, the issue is not caused by a full micro SD. The problem is somewhere else.
 
I can't even make the 20 minute loop from home to the chemists and back via the local moors without it beeping 5 times at least once on v1.6T or v1.7T even with a freshly formatted FAT32 or exFAT card even when dropping the bitrate down to Medium. Same in h264 or h265 mode with a 2 minute loop.

It does seem to get upset when I hit what would be a complex scene for the encoder, ie lots of trees etc.

I gave in and bought a new Sandisk Extreme Pro 400GB U3 A2 card which came today - this card is going to be for my drone but figured I might as well see if it behaves any differently in the A129 Pro to the other cards I've tried (which have all worked fine in my drone at 120Mbps).

I didn't get any beeps on the way to the chemists and back with the new card but as soon as it went into parking mode it was beeping like mad and threw a memory error - the card only had 45 minutes worth of video on by then.
 
I'm on 1.7 and I've only had one of two A129 Pro 4k's bleep at me, and stop recording. And that was on the one without the rear cam connected to it. Both run fine - but they only get used to record as I'm driving - all other settings are off.
 
I can't even make the 20 minute loop from home to the chemists and back via the local moors without it beeping 5 times at least once on v1.6T or v1.7T even with a freshly formatted FAT32 or exFAT card even when dropping the bitrate down to Medium. Same in h264 or h265 mode with a 2 minute loop.

It does seem to get upset when I hit what would be a complex scene for the encoder, ie lots of trees etc.

I gave in and bought a new Sandisk Extreme Pro 400GB U3 A2 card which came today - this card is going to be for my drone but figured I might as well see if it behaves any differently in the A129 Pro to the other cards I've tried (which have all worked fine in my drone at 120Mbps).

I didn't get any beeps on the way to the chemists and back with the new card but as soon as it went into parking mode it was beeping like mad and threw a memory error - the card only had 45 minutes worth of video on by then.
Personally I think this has nothing to do with the SD card issues. There has to be something done with the firmware. I had pretty much the problem isolated in the V1.2ACC.T where I didn't have anymore beeping issues for about 3 months. With recent firmware versions the camera has become way too picky.
 
Personally I think this has nothing to do with the SD card issues. There has to be something done with the firmware. I had pretty much the problem isolated in the V1.2ACC.T where I didn't have anymore beeping issues for about 3 months. With recent firmware versions the camera has become way too picky.
We did set the MAX numbers of locked files on V1.2ACC.T

For the beeping issue, can you also share the SD card brand and model?

As we know, this will happen more often if use the parking mode often. We recommend trying the time lapse options as it will record less files.
In previous firmware, there is a bug for timelapse, it is fixed in V1.7T.
 
Personally I think this has nothing to do with the SD card issues. There has to be something done with the firmware. I had pretty much the problem isolated in the V1.2ACC.T where I didn't have anymore beeping issues for about 3 months. With recent firmware versions the camera has become way too picky.
Same for me, i have two WD Purple cards and it doesn't matter if i swap them between the units, the behaviour is still the same for each A129Pro (there must be more factors). EDIT: Btw my sample unit was nice and stable with 1.2ACC as well but then it got mad at me...

But i have something which came to my mind recently. Did anybody, tried to just cool the dashcam? What if the issues are heat related? I may probably sound repetitive by now :ROFLMAO: but i was investigating my sample unit (and the worse behaving one now) and in order to get to chipset i had to remove the heatsink, faraday shield cover and copper spacer/shim (between each of them is a thermal paste) so obviously i was forced to replace the thermal paste (i used good old Arctic Cooling MX-2) and i think the dashcam behaves calmer, more predictable after the procedure. I will give it some time but looks promising.
Actually, I was up to looking for something like an UART access and there really are four pads for, as it seems, two interfaces...


EDIT: In case someone is interested :) :
_DSC2425.JPG _DSC2419.JPG _DSC2417.JPG _DSC2415.JPG
 
Last edited:
Same for me, i have two WD Purple cards and it doesn't matter if i swap them between the units, the behaviour is still the same for each A129Pro (there must be more factors). EDIT: Btw my sample unit was nice and stable with 1.2ACC as well but then it got mad at me...

But i have something which came to my mind recently. Did anybody, tried to just cool the dashcam? What if the issues are heat related? I may probably sound repetitive by now :ROFLMAO: but i was investigating my sample unit (and the worse behaving one now) and in order to get to chipset i had to remove the heatsink, faraday shield cover and copper spacer/shim (between each of them is a thermal paste) so obviously i was forced to replace the thermal paste (i used good old Arctic Cooling MX-2) and i think the dashcam behaves calmer, more predictable after the procedure. I will give it some time but looks promising.
Actually, I was up to looking for something like an UART access and there really are four pads for, as it seems, two interfaces...


EDIT: In case someone is interested :) :
View attachment 51736 View attachment 51737 View attachment 51738
You have made a good point! I need to pay good attention to the temperature conditions when beeps happen. I live in Texas where we are already experiencing much hotter days. We are just at the beginning of the hot season.
 
We did set the MAX numbers of locked files on V1.2ACC.T

For the beeping issue, can you also share the SD card brand and model?

As we know, this will happen more often if use the parking mode often. We recommend trying the time lapse options as it will record less files.
In previous firmware, there is a bug for timelapse, it is fixed in V1.7T.
I do use 2 Samsung Evo Plus , 2 Evo Select and 2 Sandisk Extreme Plus. The camera behavior is the same with either card on the V1.7T
I do not use any of the parking modes.
 
The symptom of it failing in parking mode suggests to me that it might have something to do with the voltage the camera is receiving. When the car is parked, the battery is not being charged, so the voltage will be lower. I had a problem where my rear camera (did not matter which of my cameras was in that location) would reset while driving. I fixed it by replacing the USB cables with power only cables of much heavier wire gauge.
There seems to be a lot of variables associated with this issue: memory card, voltage, temperature, and firmware version. Possibly others. It would be nice if the camera would report why it is beeping, or beeped in a code that we could look up.
My cameras appear to be working, so I am not going to upgrade them to beta firmware.
 
I did have a read through one of the Novatek SDKs once and it was showing the API exposed errors which included write errors and then also write errors due to the storage being too slow so you'd think it's possible to write it out to the camera screen although in reality probably more useful to stick it in a variable and then write that to the metadata stamped onto the video.

It would make life debugging some of these random issues much easier over time - yes you'd lose some errors when multiple errors stack up but would make it a lot easier to work through one by one.

Likewise with the UART connection it's a shame those pads aren't more easily exposed on more devices, the wife tidied my logic analyzer a while ago and I'm getting close to buying a new one as I haven't seen it since :D
 
exFAT (even if the card was previously FAT32)
I tried formatting on device, but it remains FAT32. I have to connect it to my PC and format it to exFAT from my PC.

Running my unit on a power bank for an hour, no more beep. Going to test it in my car later. Before this, it beeps like hell and I'm getting pretty annoyed.
 
I did have a read through one of the Novatek SDKs once and it was showing the API exposed errors which included write errors and then also write errors due to the storage being too slow so you'd think it's possible to write it out to the camera screen although in reality probably more useful to stick it in a variable and then write that to the metadata stamped onto the video.
there are various options available for logging faults, can be logged to file, UART, embedded in video, we've used each method depending on what bug it is you're looking for, it's really only useful for the engineers though as a lot of it just looks like jibberish
 
there are various options available for logging faults, can be logged to file, UART, embedded in video, we've used each method depending on what bug it is you're looking for, it's really only useful for the engineers though as a lot of it just looks like jibberish
Yes mate, it's just that they've had these issues reported since last at least October time when I emailed with no real sign of fixing the random beeps yet, the engineers need as much data as possible to fix this once and for all.

If Novatek are pushing back saying it's not a defect then odds are this could be affecting more cameras going forwards if this is their shared filesystem SDK code with an issue.

At the end of the day if there's a random write issue then at some point that is going to happen to someone as they have an incident, and the dashcam with the write issue is as much use as a chocolate fireguard.
 
It would be jibberish to me but it would seem to be a prudent thing to do one way or another until the 'bug' is identified and fixed ;)

Phil
 
It would be jibberish to me but it would seem to be a prudent thing to do one way or another until the 'bug' is identified and fixed ;)

Phil
it's quite possible (and very likely) that the engineers have been doing this already, debug type firmwares aren't normally given to the public as they're often limited in other ways
 
Isn’t hat heatsink design pretty rubbish? Not an expert but to me covering the copper with something else will mean the heat will get trapped in the void below it.
 
Isn’t hat heatsink design pretty rubbish? Not an expert but to me covering the copper with something else will mean the heat will get trapped in the void below it.
We are missing the photo of the heatsink, the copper is not there as a heatsink.

Ideally you would form the copper into the Faraday shield instead of having 2 separate items, but I don't imagine that was possible on cost since the copper could not be thin sheet. So, no, looks pretty decent to me, and it is proven by this dashcam having over twice the bitrate of any other 4K dashcam ;)
 
Back
Top