BCD436HP/BCD536HP: firmware bug? Scanner stops recording

[gariac]

Firmware 1.11.21
Conditions:
Do a custom search.
Set hold on a frequency with DMR.
Start recording.
Turn volume to zero.
Go to bed.

Problem:
Volume turns itself to 8 all by itself.
After being woken up by voices on the radio, I noticed the scanner is no longer in recording mode.

There was no low battery issue.

 

[Ubbe]

I had that happening to my 536 in the exact same scenario. But ones it happened during daytime and
I noticed that the 536 rebooted, the recording stops and volume goes to the programmed default value.

/Ubbe

 

[benburke]

Firmware 1.11.21
Conditions:
Do a custom search.
Set hold on a frequency with DMR.
Start recording.
Turn volume to zero.
Go to bed.

Problem:
Volume turns itself to 8 all by itself.
After being woken up by voices on the radio, I noticed the scanner is no longer in recording mode.

There was no low battery issue.

Is 1.11.21 valid? The latest firmware (that I found) is 1.11.20.

 

[kruser]

Is 1.11.21 valid? The latest firmware (that I found) is 1.11.20.

Yes, it's valid but as a beta or test version.
UPMan also posted a link the other day to a newer beta or test FW for the x36HP models. It is version 1.11.22 and fixes some issues with 1.11.21 but not sure what.

The last official release should be 1.11.20 as you listed.
I do think I saw a post by UPMan that 1.11.21 was being released officially but none of my x36 models ever showed it when doing a FW update check via Sentinel so I may be dreaming that I read that.

I did install 1.11.22 on a 5 and 436 model and no problems found.

 

[kruser]

I had that happening to my 536 in the exact same scenario. But ones it happened during daytime and
I noticed that the 536 rebooted, the recording stops and volume goes to the programmed default value.

/Ubbe

I never left mine on for very long with version 1.11.21 so never caught the radios rebooting on their own.
I've been running the newer 1.11.22 version that UPMan linked to in another thread the other day and have not had any of the radios reboot on their own that are running that newest beta version.
Maybe that was one of the fixes between 1.11.21 and 1.11.22.

edit: forgot to mention that I installed 1.11.22 on one 436 and one 536 and both have been on since Paul posted the working link.
Only the 536 has been recording though.
I wonder if recording is what triggered the radio reboot you and others have seen happen?
In the short time I had 1.11.21 installed, I'd not have had the recording feature activated.

Here is the thread where UPMan posted the link for FW version 1.11.22 http://forums.radioreference.com/un...-oft-band-plan-issue-logging.html#post2710192

 

[troymail]

FWIW - this sounds exactly like what it does when the SD card gets about 2Gb (+/- 30,000 recordings) also... The radio reboots itself and any settings changed since last startup are lost (it reverts back to last startup settings).

 

[kruser]

FWIW - this sounds exactly like what it does when the SD card gets about 2Gb (+/- 30,000 recordings) also... The radio reboots itself and any settings changed since last startup are lost (it reverts back to last startup settings).

Interesting. I've never let my amount of recordings ever grow to near that amount of files or used space. I always move them off the card.

I think I'll test this and copy all my recordings back to the card and see if that does not trigger these odd reboots some are seeing.

 

[troymail]

Interesting. I've never let my amount of recordings ever grow to near that amount of files or used space. I always move them off the card.

I think I'll test this and copy all my recordings back to the card and see if that does not trigger these odd reboots some are seeing.

I should have said "...what it has always done..."

 

[KevinC]

Long thread about it...

http://forums.radioreference.com/uniden-tech-support/307293-rebooting.html

 

[kruser]

I should have said "...what it has always done..."

That should make it easier to reproduce then!

Thanks for the other thread link KevinC, I'd not run across that one before probably because I never had the problem.

 

[kruser]

Long thread about it...

http://forums.radioreference.com/uniden-tech-support/307293-rebooting.html

So, after reading that thread, it does make me think the card or FAT32 hits one of its limits and the x36HP's (and probably other card based models) freak out and reboot if recording is active.

It sounds like one simply needs to move audio files off the card before hitting any of the FAT32 limits or Uniden needs to re-write the firmware so it can read and write a card formatted as NTFS (if that format type is even allowed on large SD cards).
Does not one of the Unix file system types also have a much greater max limit?

I remember when FAT32 came out and figured that would solve everyone's problems! Just goes to show that newer technology does not always work out if file systems cannot keep up with the demand placed upon them in today's gigabit world and above.

Of course in the Window's world, you also have GPT but not sure if that would be practical for a removable storage card. It does work on external large capacity drives via USB though.

 

[gariac]

I will go along with rebooting being the issue. (I read the suggested long 536 thread.) Rebooting makes sense given that the volume has changed.

I will say I've noticed this problem before with other firmware versions, but thought maybe I didn't set the record feature. But turning down the volume was something new, and having the volume restored totally fits the reboot scenario.

I do not believe the FAT32 limitations come into play. There is a 64K (roughly) limit on the number of files per directory, but the recorder only puts 100 files in any directory. The format should handle 4Gbytes file size, though some reference 2Gbytes. But no audio recording will get that large. The 2Gbyte transition should not be an issue with the card.

I'm using a 32Gbyte card and have filled about 8% of it. The card is a Toshiba rated at 30mbps. (I don't know what came over me since I usually buy the no-name stuff.) Blaming the card is simply a rat hole to waste the users time. (Think of it as a Kellyanne Conway question deflection.) Software people blame hardware. Hardware people blame software. Customer gets stuck in the middle.

I will get the latest firmware, but personally I believe their is a problem in the firmware that has been around for a long time. When the dust settles, some instruction of the code will have written to the wrong place, some watchdog scheme forces the reboot.

Lots of good feedback in the thread, so thanks all.

 

[Ubbe]

I also beleive it is a watchdog issue, the scanner FW thinks it has stuck and reboots.
Never any problem when recording and scanning, only when holding on to a channel over long time.

Not a SD card problem as it was almost clean of recordings and it should have been noticed when recording during scan.

/Ubbe

 

[gariac]

Well I was hearing voices last night. Fortunately (or not) they were coming from the 436 that rebooted. Today I've been running the scanner for about 6 hours without recording but otherwise holding on the search. No reboot yet.

So how do I report a bug?