Report in - x36HP SD Card Problems/Corruption

[JamesO]

I had a card error once with the 4GB card that came with my 436HP, but it was in a reader in my laptop at the time, and I was trying to write to it from Sentinel. I had to reformat the card, but it worked fine on the second attempt, and has not had any errors since then.

Explain how that is a scanner problem when the scanner was powered off and in a different room than both the card and laptop when the error occurred. The card still seems to work OK, but for now I'm using it as a backup, and have a 16GB card in the 436HP.

IMO going after Sandisk for warranty card replacement makes far more sense than blaming Uniden for the problem.

Seems that your "once" situation using Sentinal may not be related to the issues others hav had with the SD cards as your car was recoverable. Most of the card problems with the 4/536HP were not recoverable.

So as I said when I originally started this thread, we will let the data speak for itself.

Going after SanDisk for 4GB flash cards is like beating your head against the wall as we/scanner owners were not the direct purchasers, we have no specific receipt for the cards, and I am not sure how many man hours I care to invest in chasing SanDisk on the phone as well as having pay to return a defective card.

I can have a decent meal out for the amount of time I would spend chasing my tail with SanDisk.

But on the flip side, if Uniden ever fesses up, most of those who have posted problems here have documented their issues and maybe one day in the next year when the dust settles, many of us may be able to get replacement cards from Uniden??

Not holding my breath on this one!

 

[jonwienke]

Seems that your "once" situation using Sentinal may not be related to the issues others hav had with the SD cards as your car was recoverable. Most of the card problems with the 4/536HP were not recoverable.

Which still points to it being a card problem, not a scanner problem. If the scanner was frying cards due to overvoltage, they wouldn't last very long because they would be damaged by both reads and writes. And replacing cards wouldn't help--the replacement card would consistently fail after a short period of use.

I went through the actual problem reports in this thread, and tossed out card errors that did not occur while the card was in the scanner, so that the only data points reflect errors that happened while the card was in the scanner. Here's the results:

95.0% of the errors involve the original 4GB cards.
31.6% of the original cards were reformattable/recoverable.
8.3% have have had unrecoverable problems with replacement cards.

Seems pretty clear that the problem is a bad batch of original 4GB cards.

 

[JamesO]

Being a Devils Advocate, you think the problem is with the SD cards, how do you know something in the scanner is not zapping/damaging the cards?

Could be either, will take some time to see if replacement cards have issues. I recall?? at least one person claiming a replacement card had problems, it may or may not have been included in this thread.

Glad you think you can make a concrete conclusion from this sample of comments without further investigation/testing.

Also I can guarantee that this thread is not all inclusive off all the problems out there. Many owners do not belong to RR, many may not speak up on RR, many may not even contact Uniden. So I conclude the problem is larger than the documented cases here, but how large, who knows?

I think the only thing that can be concluded at this point is there is a problem.

Uniden SHOULD be the one looking into this, however, I am doubting UPMan even focuses on anything other than "features"??

 

[FeedForward]

95.0% of the errors involve the original 4GB cards.
31.6% of the original cards were reformattable/recoverable.
8.3% have have had unrecoverable problems with replacement cards.
Seems pretty clear that the problem is a bad batch of original 4GB cards.

Thanks for tallying up the problems in this way. I have a couple of rhetorical questions after looking at the data.

First, I'm curious about how an SD card is actually made unusable or unrecoverable? Do internal parts simply smoke, or is there a "bios" inside the card that can be bricked? Whatever the case, 69% of the original cards had it happen.

Second, 8.3% of replacement cards unrecoverable is still far more than I would consider an acceptable failure rate. We would certainly not tolerate that failure rate for computer SDRAM or hard drives. What's the solution?

FF

 

[sibbley]

Second, 8.3% of replacement cards unrecoverable is still far more than I would consider an acceptable failure rate. We would certainly not tolerate that failure rate for computer SDRAM or hard drives. What's the solution?

FF

This is the point of the day. The only solution is to find the problem. I don't feel that replacing a card every few months is a solution.

As I mentioned in a previous post. I now use the original 436 card in my PSR-800. I want to see how long till I have a problem with the original card from Uniden in another scanner. I use the 800 every day for at least 8 hours. I make sure that I'm writing to it every day, and I use it to record everyday. We'll see what happens. Only time will tell.

 

[JamesO]

This is the point of the day. The only solution is to find the problem. I don't feel that replacing a card every few months is a solution.

As I mentioned in a previous post. I now use the original 436 card in my PSR-800. I want to see how long till I have a problem with the original card from Uniden in another scanner. I use the 800 every day for at least 8 hours. I make sure that I'm writing to it every day, and I use it to record everyday. We'll see what happens. Only time will tell.

^+1.

Unfortunately many that had issues with non recoverable cards have no other option to have a brick on their hands.

Not sure what the ultimate resolution is, this issue just may fade away over time, which would then likely indicate without real facts that the cards were the issue.

Time will tell.

 

[jonwienke]

Being a Devils Advocate, you think the problem is with the SD cards, how do you know something in the scanner is not zapping/damaging the cards?

The difference between people reporting problems with original cards vs replacement cards is pretty definitive. If the scanners were damaging the cards, the 95-8.5 differential would be a lot less--more like 95-75 or something.

 

[jonwienke]

Glad you think you can make a concrete conclusion from this sample of comments without further investigation/testing.

Right back at you. You've taken the position since the beginning of this thread that Uniden is somehow at fault for this, that the scanners are damaging the cards, and continue to do despite the data sample gathered so far clearly indicating otherwise. The ratio of problems with original cards vs replacement cards is over 10:1, which is pretty definitive, even given a small sample population of 20 incident reports.

 

[JamesO]

Right back at you. You've taken the position since the beginning of this thread that Uniden is somehow at fault for this, that the scanners are damaging the cards, and continue to do despite the data sample gathered so far clearly indicating otherwise. The ratio of problems with original cards vs replacement cards is over 10:1, which is pretty definitive, even given a small sample population of 20 incident reports.

Not sure what you have been reading, I have been very neutral on all of this with the exception of commenting that the short term replay storage should probably have been normal non-volatile RAM rather than SD card storage, and for all we know, this may be how things work??

You are the same guy that "Believes" that these SD cards will last 25-50 years under severe use, I say lets have a beer and discuss how our orignal 4 GB SanDisk card is still working in 50 years. I'm buying if my 4 GB SanDisk card is still functioning in 2064 after recording non stop.

I promise I will keep my word and honor my offer!

 

[sibbley]

^+1.

Unfortunately many that had issues with non recoverable cards have no other option to have a brick on their hands.

Not sure what the ultimate resolution is, this issue just may fade away over time, which would then likely indicate without real facts that the cards were the issue.

Time will tell.

I hope this issue just fades away over time. Every time I turn my scanner off I am worried that the next time I turn it on I'll have the card issue again. It's a crappy feeling.

 

[jonwienke]

Not sure what you have been reading, I have been very neutral on all of this

Uniden should have designed these scanners with volatile replay buffer chips. If all the replay audio is being written to the SD card, there is just too much going on and unnecessarily.

I expect that faster and higher quality, larger SD flash cards may yield better overall performance in these scanners, but I expect to see continued issues on units that are recording on a 24 hour a day basis.


Maybe there is a firmware issue with the x36HP where there is some wait state or timing problem writing to the cards?


I would hope that UPMan/Uniden is watching this thread and thinking about what may be going on and if there is a firmware/hardware issue with the scanner or if this seems to issues with the SD cards.


But on the flip side, if Uniden ever fesses up, most of those who have posted problems here have documented their issues and maybe one day in the next year when the dust settles, many of us may be able to get replacement cards from Uniden?

Seems like a pretty clear "blame Uniden" slant to your remarks to me...

 

[jonwienke]

This is the point of the day. The only solution is to find the problem. I don't feel that replacing a card every few months is a solution.

According to the data posted here, replacing the card once resolves the card error problem >90% of the time.

 

[scanman1958]

Lots of good back and forth banter guys. It is great to hear all of our ideas. However there is one thing that is 100% here. And that is we have not heard word one from any rep from Uniden. Not one!! The only way to clear this up is to have someone from Uniden speak the truth. Period. This will not fade away. Have a nice weekend.

 

[sibbley]

According to the data posted here, replacing the card once resolves the card error problem >90% of the time.

I really do hope you're right. I like nothing more than to put this to rest. We'll see I guess.

 

[jonwienke]

That's what the data gathered so far indicates pretty clearly.

 

[AE7Q]

WiFi support vs. GPS connection?

Well said. The Wi-Fi and analyze features are probably wanted by more people than you think. For me I have no interest in the Wi-Fi but the analyze feature sounds really cool. I think I could learn to like it. And I hope to see it soon. Either in the scanners that are out now or in new models in the near future.

Well, given the 3rd party supplier (firmware?) problems with the WiFi unit, I'd really love the option to return the WiFi dongle and have instead firmware support for plugging a GPS into the USB port used by the WiFi dongle.

 

[kruser]

Well, given the 3rd party supplier (firmware?) problems with the WiFi unit, I'd really love the option to return the WiFi dongle and have instead firmware support for plugging a GPS into the USB port used by the WiFi dongle.

Support for a USB powered GPS unit would be nice even though the radio already supports serial based GPS units. That may be asking a lot with the large amount of USB based GPS units. I don't think there is a popular standard for USB based GPS units like there is for serial based GPS devices.
I'd also like to see support for hardwired ethernet dongles over wireless (WiFi) based dongles. There are several common chipset based hardwired ethernet dongles on the market that work and share a fairly common driver base.
Ssomething that will allow the end user the ability to program their favorites other than through the front panel based USB port only..

With that said and getting back on topic, I've never had a problem with the original SD card included with my 5 or 436 models.
I've since swapped them both out for larger cards though for greater audio recording space but the originals were both well used without any issues ever.
I still keep them updated as spares with my current favorites and the updated database that I put on the cards at least every other database update.
I don't write my audio files onto the original cards though.

 

[AE7Q]

Support for a USB powered GPS unit would be nice even though the radio already supports serial based GPS units. That may be asking a lot with the large amount of USB based GPS units. I don't think there is a popular standard for USB based GPS units like there is for serial based GPS devices.

The advantage of a USB-based GPS is that it could be powered from the USB port, which could appear as just a generic USB-to-serial converter. I don't know if the 536's serial port's DTR/RTS lines are even present, let alone can provide enough power for a serial GPS (separate power is a nuisance).

I second your idea of support for a hardwired Ethernet connection. For mechanical reasons, I dislike using the front USB port for programming. WIth the BCD996XT, one could use the rear serial port for both GPS and for programming. Unfortunately, Sentinel does not have that option. However, other than firmware updates, I believe that one can update the database and favorites on the SD card by temporarily removing it from the 536 and inserting it into a microSD card reader connected to a PC.

 

[FeedForward]

Dear AE7Q,
It would be interesting for everyone to know a bit more about how SD cards actually work Since you are an expert in this field, are there some things that you can share with us that may get us thinking correctly about this subject? I would personally be interested in knowing - in a general way of course - how much on-board processing goes on in the card itself. We are aware of load-leveling, but in terms of i/o and file allocation, are these functions performed on the card or by a card interface in the host?

Thank You!
FeedForward
Seattle, WA

 

[AE7Q]

Everything you wanted to know without having to kill you

Dear AE7Q,
It would be interesting for everyone to know a bit more about how SD cards actually work. .... We are aware of load-leveling, but in terms of i/o and file allocation, are these functions performed on the card or by a card interface in the host?

Thank You!
FeedForward
Seattle, WA

File allocation is done in the host operating system, just like it is on a normal disk. Typically that OS does nothing special for a flash drive, except possibly limited caching to reduce writes.

The CPU on the card has usually has no formal interaction with the host OS, although there is sometimes code to detect (by observing writes to low-numbered sectors) that the host OS is attempting to reformat the memory. Such information can be used to decide that all data on the device can be discarded (erased). This can slightly improve performance for a while after a format, because a sector write will not then require the reading (by the card's CPU) of all the prior data in a 64KB block, in order to write a new 64 block.

Some cards do this (making deleted files unrecoverable after ANY format), and some do not. Note that a quick format on a normal disk leaves prior data untouched until overwritten.

Note that a sector write is NORMALLY done in the following sequence:

1. The 64KB block that is to be written to, is read by the card's CPU.
2. That 64KB is scheduled for erasure.
3. A previously-erased 64KB block is obtained from the available-block list on the card. Depending upon the code for the card's CPU, this can require the erasure of an available block if no previously-erased blocks are available. Erasures (and writes) are MUCH slower than reads.
4. The new sector to be written is merged with the prior data from the 64KB block.
5. The merged 64KB block of data is written to the card's memory.
6. The card's virtual-to-physical sector map is updated. Note that updating the sector map can require a fresh 64KB block for the sector map itself, so the process can be somewhat recursive. This step is where trade secrets and patents enter the picture. It's more complicated than it appears.

However, if the sector write is being done to a 64KB block where the target sector has been erased, the data is simply written to the erased sector in the block, and none of the above steps are necessary.

This is why replacing a USED card with an identical NEW one can DOUBLE the performance for a while (until all never-used 64KB blocks have been written), leading one to the conclusion that the old card "has gone bad".