Whistler Update

[kruser]

Yours would seem to be the minority opinion as there are a lot of positive reviews on the Uniden forum and the scanners seem to be flying off the shelf.

I agree with this 100%. My 536HP decodes my P25 systems better than any scanner I've ever used. Systems that the PSR 500, 600 and 800 will not even detect.
I do take advantage of the manual P25 decode settings that can be set per site in the x36HP models.
I thank Uniden for bringing that feature back since it was removed with the XT series. The XT's did have a hidden P25 settings menu but it was no good as it affected all P25 sites programmed into the radio.


cherubim, saying Uniden "dropped the ball" is way out of line. Yes, they do have some issues but many are simply user error from not understanding the complexity of these new models.
No comment on the headphone issue but it seems Uniden is taking care of those that choose to send them in. In all fairness to GRE, they did the same for the PSR-800 owners whose paint wore off their shiny new 800's.

I have a PSR-600 that is near dead. If I turn it off for more than a few minutes, it will start corrupting its own internal memory and I must reload my programming when I want to use it.
I've only seen this on the main 600 I use daily. The other GRE's I own sit unpowered most of the time. More are reporting memory issues with the 500 and 600 series which makes me think there will be widespread failure with those units that are used a lot as the memory cells fail.

 

[SCPD]

Flying off the shelf maybe, Uniden forum from what I've seen has a lot of upset buyers. Aren't they sending back units on a recall ? Don't get me wrong, I can't say enough about my BCD996XT, awesome, and I do feel for Paul, what a black eye he has taken.

 

[garys]

Flying off the shelf maybe, Uniden forum from what I've seen has a lot of upset buyers. Aren't they sending back units on a recall ? Don't get me wrong, I can't say enough about my BCD996XT, awesome, and I do feel for Paul, what a black eye he has taken.

Before you make disparaging comments, don't you think you might want to read the actual threads so you know what you are talking about?

 

[KC0CSE]

I agree with this 100%. My 536HP decodes my P25 systems better than any scanner I've ever used. Systems that the PSR 500, 600 and 800 will not even detect.
I do take advantage of the manual P25 decode settings that can be set per site in the x36HP models.
I thank Uniden for bringing that feature back since it was removed with the XT series. The XT's did have a hidden P25 settings menu but it was no good as it affected all P25 sites programmed into the radio.


cherubim, saying Uniden "dropped the ball" is way out of line. Yes, they do have some issues but many are simply user error from not understanding the complexity of these new models.
No comment on the headphone issue but it seems Uniden is taking care of those that choose to send them in. In all fairness to GRE, they did the same for the PSR-800 owners whose paint wore off their shiny new 800's.

I have a PSR-600 that is near dead. If I turn it off for more than a few minutes, it will start corrupting its own internal memory and I must reload my programming when I want to use it.
I've only seen this on the main 600 I use daily. The other GRE's I own sit unpowered most of the time. More are reporting memory issues with the 500 and 600 series which makes me think there will be widespread failure with those units that are used a lot as the memory cells fail.

Well your having the same issues as my self with the PSR 600 mine will lose it's memory at times also..will have to re-program with win-500 then it will work for a while then dies again some time later...thought maybe I was the only one....also a weird thing happened it will no longer work on 12volts...5volts 2.0amps only now...I cannot explain this one...had to change my car adapter to a cell phone one for it to work right....the screen would "freeze" up on one talk group and not move...till I made the change...just out of the blue one day it changed and never went back to 12volts..

 

[bigcam406]

ive owned my 500 for 5 years and my 600 for 3 years and ive never experienced this problem,just saying...

 

[SCPD]

GRE

ive owned my 500 for 5 years and my 600 for 3 years and ive never experienced this problem,just saying...

Me neither.And if you did,just rehit it with software and you are back working!

 

[cherubim]

None of the GRE digital scanners I own have given me any significant problems. They all work as expected from day one. I'm still critical of the sensitive front end these scanners employ and my workaround for this is to use my PSR-600, Pro-197 and Pro-106 for monitoring P25 TRS leaving my Uniden's for analog monitoring.

I certainly don't hate Uniden nor do I want to see them exit the scanner market. Customers and potential purchasers should be be entitled to constructively criticize a manufacturer if they release a flawed product.

I find it disturbing that some people in these forums have this misguided belief that people making legitimate complaints and negative remarks about Uniden's new line of scanners are somehow anti-Uniden or whining for no good reason. Whatever happened to expressing one's point of view without fear of reprisal ?

 

[kruser]

Me neither.And if you did,just rehit it with software and you are back working!

The fact of the matter is, the radio uses flash type memory which has a finite amount of writes before cells start failing.

Once enough fail, you won't be able to 'rehit' it with your stored data as there will be no working memory to store it.
In theory, yes you can rehit it if the working memory uses a different type ram but as soon as you change something or power cycle it, it will not be able to read from the flash memory again and you will need to reload from a computer every time you turn the scanner on.

Some of my V-Scanner folders are now failing as well and the contents of them is corrupted so I cannot simply reload a working set from them like I could when this memory issue surfaced.
Does this ever make you wonder if this is not why GRE built in memory tests that one can run at power up?

This is a known problem and has been discussed in several threads right here in this forum and the radioshack forum as well as other internet message boards.
Some speculate GRE used some flaky chips for some of the units.
That's surely possible and could be the reason many are still working.

My 600 is on nearly 24x7 every day so it sees a lot of use. I did turn off the hit counter as that writes to the cells each time it sees a new hit and that seems to have slowed down my problem when I do turn it off.
Had I known the memory was going to fail, I'd have never used the built in hit counter and would have relied upon external software for that info. I'm sure other things are writing the internal memory though and slowly eating away at it.

This is no different than SSD hard drives. They too will fail after time and it won't be nearly as long as a good old mechanical drive lasts.
I've know many that have had their SSDs fail already from excessive memory cell failure. It's the nature of the beast when a device uses a flash type memory.

I've also had my 600 since the day it came out. The GRE models I own other than this 600 still run fine but I don't use them often.
For this failing 600, leaving it on always is the only way I can use it without needing to reload my data each time.

The PSR-800 may also not be affected as its flash (SD card) can simply be swapped for a new one. It still writes the SD data to some type of internal memory though but I don't know what the 800 uses for that memory. Being as it is volatile type ram, I suspect it won't be subject to failure like those that use a form of flash ram for everything.

 

[John]

I wonder if the same applies to the new Uniden series since they also use SD memory and read that into working memory each time you reinitialize it.

The fact of the matter is, the radio uses flash type memory which has a finite amount of writes before cells start failing.

The PSR-800 may also not be affected as its flash (SD card) can simply be swapped for a new one. It still writes the SD data to some type of internal memory though but I don't know what the 800 uses for that memory. Being as it is volatile type ram, I suspect it won't be subject to failure like those that use a form of flash ram for everything.

 

[John]

Do you mean a 500 or a 600? The 600 runs directly off of 12 volts so there is no 'car adapter'.

Well your having the same issues as my self with the PSR 600.....also a weird thing happened it will no longer work on 12volts...5volts 2.0amps only now...I cannot explain this one...had to change my car adapter to a cell phone one for it to work right.....

 

[kruser]

I wonder if the same applies to the new Uniden series since they also use SD memory and read that into working memory each time you reinitialize it.

I suspect it will but the new Uniden series appear to transfer the SD contents into working memory which is more like computer ram. It is volatile so it looses its contents when power is removed. That type of ram seems to go forever.
That may be why Uniden did this so when the SD card fails, you just insert a new one.
Same would apply to the PSR-800 and whatever models RadioShack sold that are SD card based.

 

[captaincab]

i personally have owned scanners by uniden gre radio shack all of them currently i have a pro2053 running as my main base and a gre psr300 as my main handheld the only digital system near me is philadelphia i will most likely be buying a new whistler when the time comes to monitor the philly system unless either one of 2 things change uniden fixes all the problems i have been hearing about or philly switches back to a non digital system which is possibile the whistler is a proven design with the gre psr800 already having been in the field and tested i only need digital for one system so if i am gonna drop 450.00 dollars or more on a scanner it better damm well work right. i am not sure if the pro2053 was still a true radio shack scanner a gre rebrand or a uniden rebrand i do doubt it is a uniden rebrand that being said the only issue i ever had with it or my gre psr300 is problems monitoring a 500mhz type 2 motorola system and i am sure it was a programming issue on my part i just got too pissed to try to figure it out lol.

 

[SCPD]

garys, I have read the threads, maybe you ought to read them again, I think you missed some.

 

[KC0CSE]

Do you mean a 500 or a 600? The 600 runs directly off of 12 volts so there is no 'car adapter'.

PSR 500 sorry

 

[N8OAY]

I wonder if the same applies to the new Uniden series since they also use SD memory and read that into working memory each time you reinitialize it.

That would apply to anything that uses that type of memory. I'm glad someone mentioned this. I just turned off the hit counter on my PSR-500.

 

[DonS]

The EEPROM used to store user programming (which includes object hit counts) in the PSR-500 family is good for at least 1,000,000 writes per page. The only time writes happen at anything beyond a negligible rate is when you're in scan mode and hit counts are enabled.

For a scanner that's on 24x7 and is running in scan mode, a talkgroup or conventional channel that is active, on average, once every 5 minutes will get 288 hits per day. Due to internal memory structures, each hit is two writes to the EEPROM. You'd be in danger of using up the 1,000,000 writes to that object's memory area in about 5 years.

Additionally, hit counts are limited to 10,000. Once an object reaches that limit, its hit counter will not be updated (and, thus, no more writes to the EEPROM for that object). You'd have to manually clear the objects' hit counters so that they'll be updated again. Even for a scanner that's on 24x7 in scan mode, once you hit the 10,000 limit on an object, you'll stop "eating up" the writes to that object's memory area.

Scanners that store their data on SD cards are not nearly as susceptible to the above. SD cards (the halfway-decent ones, at least) contain internal wear-leveling algorithms that "spread out" writes among various pages of the underlying physical memory. That is, successive writes to the same file system sector (e.g. updating the same part of the same file over and over again) are not hitting the same physical memory cells on each write, and thus don't "eat up" the limited number of writes for a particular block of cells.

 

[kruser]

The EEPROM used to store user programming (which includes object hit counts) in the PSR-500 family is good for at least 1,000,000 writes per page. The only time writes happen at anything beyond a negligible rate is when you're in scan mode and hit counts are enabled.

For a scanner that's on 24x7 and is running in scan mode, a talkgroup or conventional channel that is active, on average, once every 5 minutes will get 288 hits per day. Due to internal memory structures, each hit is two writes to the EEPROM. You'd be in danger of using up the 1,000,000 writes to that object's memory area in about 5 years.

Additionally, hit counts are limited to 10,000. Once an object reaches that limit, its hit counter will not be updated (and, thus, no more writes to the EEPROM for that object). You'd have to manually clear the objects' hit counters so that they'll be updated again. Even for a scanner that's on 24x7 in scan mode, once you hit the 10,000 limit on an object, you'll stop "eating up" the writes to that object's memory area.

Thanks for the info Don.
I always wondered if there was a limit for the hit counter.
I monitor a few systems that have thousands of hits per day for several of the talkgroups and with the radio now several years old, I'd say I've well exceeded the million writes per page.

Your info on the wear-leveling algorithms used in most of today's flash ram is true and something I've known about for a pretty long time. I think the early 1st generation of SSDs did not have very good wear-leveling algorithms or none at all and that is why some of those have failed. I know technology is improving in this area so we can only hope it keeps getting better and better and one day, they will have a type of flash ram that does have a truly infinite amount of writes. Well, maybe not infinite but something way up in the high billions.

Question, which memory chip sees the hit counts, the small 8 pin chip or the larger 48 pin chip?
If the 8 pin, that one would not be that bad to swap out using basic SMD rework tools.
If the chip is the 48 pin chip, then replacing it would be much harder and I doubt my tired eyes would hold up for a good job. I do have the rework tools needed for all types though but my eyes are just not what they used to be.
But... is there any code on the 8-pin chip in a protected space that would cause a new empty chip to not work? I see that the larger chip does contain code that must be placed on the chip before the radio will boot but nothing is mentioned about the small 8 pin chip.

Thanks for the info!

 

[DonS]

Thanks for the info Don.
I always wondered if there was a limit for the hit counter.
I monitor a few systems that have thousands of hits per day for several of the talkgroups and with the radio now several years old, I'd say I've well exceeded the million writes per page.

Yes, if (and only if) you're periodically going in and zeroing the talkgroups' hit counters. Otherwise, they'll hit 10,000 and won't be updated again.

For example, I have a local Sheriff dispatch talkgroup that gets well over 2000 hits per day. I'd have to reset its hit counter at least every 4 or 5 days or it will stop at 10,000. If I did that, I'd use up the 1 million writes in about 8 months; otherwise, it will stop at 10,000 and further hits will have no effect on the EEPROM.

Oh - uploading data from a PC counts as "resetting", if the PC "image" of the scanner's programming has something less than 10,000 in the objects' Hit Count fields. So, in case you make changes to a PC file every couple of days and send those changes to the scanner, you're "resetting" the hit counters.

Of course, if you're leaving the scanner on 24x7 in scan mode, you're probably doing some kind of logging, recording, streaming, etc. In that case, you should be using the external software to do the hit counting.

Question, which memory chip sees the hit counts, the small 8 pin chip or the larger 48 pin chip?

It's IC301, an 8-pin part. After removing the back chassis and the RF board, the logic board is left attached to the front chassis. Viewing that assembly from the rear, IC301 is at the bottom-left of the logic PCB - right above the battery area. It will have an identical, unpopulated PCB location above it (IC302). The part is an STM24512, 512kbit serial EEPROM. (The empty location is not used; even if IC302 was populated, it would have no effect).

But... is there any code on the 8-pin chip in a protected space that would cause a new empty chip to not work?

No. A new, empty part will work fine. That part only holds user programming (i.e. what you send to it from an external program or enter from the keypad) and "power-off state" info (global atten modes, scanner's mode, etc.).

 

[kruser]

Thanks Don, most informative!

I did have a bad habit of zeroing the radio's hit counters.
Don't know why I did that as I do rely upon software 99% of the time to do my logging and any "hit counting".
When I started seeing the memory errors, I thought about that and realized the hit counter was on in the radio. I've since turned that off a month or more ago as it is not needed.

When I don't actually use the radio for monitoring, I use it sitting on a P25 CC only for logging the CC data. That is now what I use it for most of the time as that works fine and nothing should be writing too IC301.
I did a lot of monitoring with it before the memory problem surfaced though and I'm certain my bad habit of clearing the hit counter from the radio's menu is what caused the failure. Also, when our new statewide system came online, I was using software to update the radio a LOT!
Sometimes I'd make several changes per day getting my text tags the way I liked. I'm sure that did not help based on what you said about software uploads resetting the hit counter each time.

Replacing IC301 looks easy plus it's a common and easily obtainable chip so I'll give this a go once the chip(s) get here. I checked and I don't have any 512kb size chips here but I do work with them a lot, just smaller sizes most of the time.
It does not look like ST makes it in any type of a DIP package otherwise I would socket the thing if there is room.
I am working on a 600 and not the 500 in this case but I know where the chip is and did notice the empty pads for what you said is 302 should it have been used.

 

[N8OAY]

Wow! Thank, DonS and kruser. Nothing like reading about a hobby and getting a good, free education! I've known about the problem with too many writes to that type of memory. Now I know why it affects certain varieties more than others. And yes, all of my SD cards are the better type made for cameras rather than the elcheapo generic stuff.