Rebooting?

[troymail]

probably so ...but I've never had a Whistler radio reboot if/when they hit a card issue - they just keep going and going (like an Energizer bunny)...

 

[buddrousa]

Troy what mine do is stop receiving P25 sites and when I look the card is dead. TRX-1 TRX-2 PRO668 PRO18 all have done the same thing. The SD Ultra Cards have lived the longest in all 7 scanners.

 

[garys]

I had the loan of a PSR800 just about the time that GRE was going out of the scanner business. I took it with me on a trip to the south to see what it could do. This was before the x36HP scanners were out, so I had no way to compare the two systems.

What I found with that scanner was that it was incredibly easy to corrupt the card. I think I had to rewrite the data three times over two weeks. Some of that was likely user error, but the scanner sure seemed very fussy about the cards.

Also the WHISTLERS have the same problem with SD cards going bad so it all points to the short comings of the SD cards. I say this because I own 3 Uniden SD Card scanners and 4 Whistler SD Card scanners and have failures with all seven scanners at one time or another. The more busy the scanner the faster the fail time.

 

[troymail]

I suspect any number of random things could occur if an in use SD card starts having issues .. I've seen scanlist names disappear in configurations, lost recordings, etc. If a card is bad, it's all going to depend upon where the card goes bad and what is written there.

However, the issue I have with the Uniden is that it keeps hitting some type of issue (that everyone has opinions about but really doesn't know for sure) and rebooting the radio. The reboot causes numerous issues -- the most annoying of which is the loss of lots of user interaction with the radio that has occurred since the last normal power cycle (settings not saved). This is particularly nasty in the middle of the night when the radio decides to reboot itself and the last stored/known (to the radio) volume setting is very LOUD. It also loses favorites lists and other quick key settings when it reboots as well as temporary lockouts/Avoids - the latter of which I expect when I intentionally power cycle/reboot but not at random times.

Again - I've never had a Whistler radio "reboot" on its own regardless of how old or full the SD card is.

EDIT: The point is - this is either a poorly handled (or unhandled) SD card fault in the Uniden radios. If it were properly handled, the radio would simply disable recording/writing to the card, etc. and continue on - not reboot.

FWIW - I recently acquired one of the Uniden recommended Transcend SD cards (16Gb). I put it in service on Friday 12/1. I will report my findings when (a) the card fills up with recordings or (b) when the radio reboots itself - whichever comes first.

 

[garys]

I've had good luck, so far, with Kingston Class 10 cards. A couple of 8GB, and a couple 16GB.

As I recall with my brief time with a PSR 800, the problem wasn't rebooting, it was not taking updates to the information that caused the problems. Again, there was likely some user error as I was learning how to use the software.

I suspect any number of random things could occur if an in use SD card starts having issues .. I've seen scanlist names disappear in configurations, lost recordings, etc. If a card is bad, it's all going to depend upon where the card goes bad and what is written there.

However, the issue I have with the Uniden is that it keeps hitting some type of issue (that everyone has opinions about but really doesn't know for sure) and rebooting the radio. The reboot causes numerous issues -- the most annoying of which is the loss of lots of user interaction with the radio that has occurred since the last normal power cycle (settings not saved). This is particularly nasty in the middle of the night when the radio decides to reboot itself and the last stored/known (to the radio) volume setting is very LOUD. It also loses favorites lists and other quick key settings when it reboots as well as temporary lockouts/Avoids - the latter of which I expect when I intentionally power cycle/reboot but not at random times.

Again - I've never had a Whistler radio "reboot" on its own regardless of how old or full the SD card is.

EDIT: The point is - this is either a poorly handled (or unhandled) SD card fault in the Uniden radios. If it were properly handled, the radio would simply disable recording/writing to the card, etc. and continue on - not reboot.

FWIW - I recently acquired one of the Uniden recommended Transcend SD cards (16Gb). I put it in service on Friday 12/1. I will report my findings when (a) the card fills up with recordings or (b) when the radio reboots itself - whichever comes first.

 

[troymail]

I've had good luck, so far, with Kingston Class 10 cards. A couple of 8GB, and a couple 16GB.

As I recall with my brief time with a PSR 800, the problem wasn't rebooting, it was not taking updates to the information that caused the problems. Again, there was likely some user error as I was learning how to use the software.

I've had card issues with respect to the GRE and Whistlers. However, this thread isn't about generic SD card issues, it is about whatever is causing the Uniden radios to reboot when other radios do not.

Everyone has opinions but the only one that really matters - I suppose - would be Paul (Uniden) and as far as I know, he has been silent on the subject (or if he did chime in, really hasn't accepted it as a 'problem').

 

[jonwienke]

Does the x36 software / firmware reserve a particular sector or specify what part of the SD card is used for the ' REPLAY ' function to use upon writing of the initial program loading of the Uniden software to the SD card?'

So as has been pointed out, if the ' REPLAY " function is on, the scanner is writing over and over the SAME 240 second chunk of the SD card 24-7-365 , REGARDLESS of the physical size of the SD card in the scanner?

Does the UNIDEN software tell the ' REPLAY ' function ' if while writing to disc, a bad sector is encountered, skip it or STOP the replay function?

How about the ' RECORD ' function? Similar instructions?

Is there a ' Back up ' set of operating instructions kept on thee SD card?

Does the UNIDEN firmware ' Specify ' where on the SD card the specified software commands WILL ALWAYS be found, thus setting the stage for failure when a data sector fails?

You are obviously unaware of wear leveling, something done by EVERY flash memory device. The flash controller dynamically maps between logical sectors and physical sectors, so that all physical sectors get written to approximately the same number of times as data is stored. The scanner firmware has no control over this. Even if the scanner wrote the replay files to the same logical sector numbers every time (which it doesn't, given the way file systems work and the methods used for creating and deleting files), the drive controller constantly changes the physical sector to logical sector mapping as data is written, so that if you write to logical sector X 100 times, you actually write to 100 different physical sectors one time each. The flash controller also tracks bad physical sectors by verifying data after each write (which is why write speeds are always slower than read speeds), and removes bad physical sectors from the pool of physical sectors that can be written to. Flash devices have spare physical sectors to replace bad sectors, and flash failure occurs when the pool of spares runs out, and it cannot offer its rated storage capacity any more.

All of this functionality is handled by the flash controller and its firmware, and the device using the flash memory (regardless of whether it is a scanner, phone, or other device) typically has zero acces to the physical sectors, only the logical ones via the flash controller. None of what you asked about is handled by the scanner firmware, or have anything to do with scanner firmware. It's all handled by the flash controller and its firmware.

 

[SMOKE1]

You are correct!
I AM unaware of how these magic boxes work now.
And thanks to your reply, I have learned something NEW today.
Tank you!
So, I'll not suggest a spindled card in the feed tray or maybe a magnet left near the tape storage rack either. I'll just go back to lurking in the background.

V/R
Ronzo

 

[troymail]

I suspect any number of random things could occur if an in use SD card starts having issues .. I've seen scanlist names disappear in configurations, lost recordings, etc. If a card is bad, it's all going to depend upon where the card goes bad and what is written there.

However, the issue I have with the Uniden is that it keeps hitting some type of issue (that everyone has opinions about but really doesn't know for sure) and rebooting the radio. The reboot causes numerous issues -- the most annoying of which is the loss of lots of user interaction with the radio that has occurred since the last normal power cycle (settings not saved). This is particularly nasty in the middle of the night when the radio decides to reboot itself and the last stored/known (to the radio) volume setting is very LOUD. It also loses favorites lists and other quick key settings when it reboots as well as temporary lockouts/Avoids - the latter of which I expect when I intentionally power cycle/reboot but not at random times.

Again - I've never had a Whistler radio "reboot" on its own regardless of how old or full the SD card is.

EDIT: The point is - this is either a poorly handled (or unhandled) SD card fault in the Uniden radios. If it were properly handled, the radio would simply disable recording/writing to the card, etc. and continue on - not reboot.

FWIW - I recently acquired one of the Uniden recommended Transcend SD cards (16Gb). I put it in service on Friday 12/1. I will report my findings when (a) the card fills up with recordings or (b) when the radio reboots itself - whichever comes first.

Well, that didn't take long.

Brand new Transcend SD card - it went directly from the package to the PC slot, prepared with Sentinel and installed directly in the 536 -- left untouched and recording --

It only took just over 1 week before the radio rebooted itself (I just happened to be sitting here this morning and heard the radio "beep" following the reboot).

Recording 1: 2017-12-01_13-26-53
Last recording: 2017-12-09_09-29-10

Upon removing the SD card and pulling the recordings, once again, there is just over 2Gb of data on a 16Gb card - roughly 43,000 recordings.

I was actually expecting to come back and report that this made a difference - it did not. I see no difference with a "recommended" brand new card.

Not much else I can say.

(In case your are wondering, the radio is running FW v. 1.11.31 but it has done this reboot thing on every version of firmware - as does my 436).

 

[yeg_scan]

Troy ..

It is a firmware issue and not an SD card issue .. as I too had the same thing on my 536HP. It would just stop recording and reboot.

What I did is go back to an old firmware version (before Uniden started messing with DMR etc) and the problem went away. I am using the same SD card.

I am currently running firmware 1.03.03 and no issues. I believe it will max out at 1,000 folders and just over 100,000 files.
I have run this test several times .. and no issues every time.

 

[radioman2008]

i read alot of the posts and wanted to contribute something ive noticed.i have 6 436/536 units all running 24/7 DISCOVERY MODE on trunked and conventional and they all will crash at various times.

good quality Trancend and sandisk ultra SD cards purchased from B and H photo are used in all these scanners so they are genuine and not cheap cards.

i have noticed they scanners are more likely to crash when they stop on a digital signal and get stuck there for some time. these signals are usually the ones that wont open the speaker. they will rarely crash in the 2 meter ham band locally where there really arent any digital signals that it sits on with no audio.
on trunked systems they crash most on Moto P25, and less on EDACS.

when it crashes, it looses the session directory it was writing to and i have to use a recovery program to find the files.