Failing: Sandisk Ultra microSDXC 128Gb (Class 10, UHS-I, Up to 80MB/s)

The new year just keeps getting better. Sure, the battery in the phone is failing, but the microSDXC card as well?!

The Culprit

The culprit was a Sandisk Ultra microSDXC card of 128Gb capacity, Class 10, UHS-I rated up to 80MB/s. This is not the same card that I previously reviewed, but a newer version of that card that I bought when I purchased my Xiaomi Redmi Note 2. As 128Gb cards (at the time) were not widely available from different manufacturers, and compatibility was problematic for some, I stuck with Sandisk. As I’m aware of the catastrophic consequences of fake flash, I purchased the card from a reputable local seller which sells local stock.

The card was purchased on the 4th February 2016, less than a year ago. To see it run into trouble is rather unexpected.

The Symptoms

The first sign of troubles came about two months ago, when I realized that some photos I took on my Redmi Note 2 came up as “Load Failed!” in Quickpic. It was only one photo, so I dismissed it as probably a glitch such as an interface bus issue – maybe something like a sparking pantograph on a passing train during the photo recording process might have disrupted it.

Later on, it affected three photos in a row sequentially while I was at the conference in Canberra. I thought “gee, something must be wrong with the software” and dismissed it again.

It was only until last week, the phone began to struggle. The camera app started to freeze, taken photos were never recorded, and the phone took forever to reboot. At times, apps stopped starting up and the phone would hang. Removing the microSD card cured everything, so I decided it was the culprit, and seeked to recover as much as I could from the card.

Copying from the card was fast for a few files, and then would stop and stall for a long time before failing with an I/O error.

It wasn’t just one or two files. A large number of files succumbed, including my TWRP backup of the phone. To copy it off and work out exactly which files were affected would take a long while, and because of card misbehaviour, ddrescue was not really as viable as it could be.

The card had a tendency on hitting some error to hang for a while then completely drop off the bus, requiring a cycle of the card (unplug/replug) to regain access. Worse still, some affected sections appear to be directory entries in the FAT, thus even listing certain folders was not reliable.

As I didn’t want to waste a lot of time, I devised a method to copy as much as possible in as short a time. Using Windows 7, I copied all files to a new folder, but when the card struggled, I pulled the card from the reader, provoking this error …

… while at the same time, plugging the card back in, allowing enough time to recognize the card and then hitting skip to bypass the “damaged” file.

In all, I only lost 9 of about 1000 photos, the backup of the phone, and a few random temporary download files. Nothing too major, although if you’re going to yell at me to “use cloud backup”, I’d have to decline since I really don’t want to tie up my limited upload bandwidth with that nonsense. Sharing my 1Mbit/s with another two family members that do use such systems and their friends is enough …

The Curse

Now came the time to consider returning the card under warranty. It had a “limited lifetime” warranty, and the failure occurred in less than a year.

The HDTune Pro error scan failed after 2356 errors, and it seemed the card had fully given up returning data at a point. The errors were real.

But I could not let a card containing my own personal data out to return, so I wiped the card. Unfortunately, as it turned out, post full formatting, it was again able to store and retrieve data across its entire surface correctly.

The fault had cleared, thus making me ineligible to return the card, probably due to internal reallocation or reprogramming of the faulty flash cells. However, it seems highly likely that the issue will re-manifest itself into the future.

After this experience, I cannot recommend any Sandisk Ultra cards. It seems the whole planar TLC memory thing has gotten out of hand, and that their cards of exceedingly poor endurance. This is the third Ultra card I’ve had fail in 2016, and it’s not because I use them harshly at all. In fact, that card had only been fully cycled in commissioning testing, and then was never filled completely. It was used in a phone as photo storage, and never even received a load of video/audio. The other two cards that had failed started similarly, but ended in complete lack of recognition of the cards (a 32Gb and a 64Gb card).

The Final Nail

Unfortunately, it wouldn’t be the end if there wasn’t a little twist. When putting the card back into the phone, I had it formatted as exFAT as per SDXC standards. I didn’t realize (or remember) that the Xiaomi Redmi Note 2 did not support exFAT and required it formatted FAT32. When the message saying “external SD blank or unsupported filesystem” came up, and an offer to format the card correctly was proposed, I leapt at it without thinking twice.

It seems that an interaction between this command and the custom recovery (TeamWin Recovery Project) meant that instead of formatting the external SD card as it should have, it wiped the internal SD leaving the unit back to factory defaults and me without a backup to restore from thanks to the card failure.

So, four hours of my time was spent flashing the newest weekly Xiaomi.eu ROM (why not?) and reinstalling everything … just to get it back to life … with its swollen battery. I’m flying out in four weeks – I really don’t need this.

Conclusion

It’s a shame but it seems the Sandisk brand no longer represents the quality it once did. But that’s not the only brand I’ve had issues with – Lexar is also part of the group too.

As a result, I can’t really recommend the Sandisk Ultra as a good choice anymore – I now look towards Toshiba and Samsung instead, as none have faultered in my hands yet.

However, it seems quite likely that the whole trend towards cheaper flash memory devices and TLC memory means that reliability is on the down-hill. I’d hate to think what people using them for constant data writes (e.g. data-loggers, dash-cams, surveillance-cams) will see in terms of endurance.

Posted in Computing, Flash Memory, Tablet, Telecommunications | Tagged , , , , , , | 1 Comment

Teardown: Swollen Xiaomi Redmi Note 2 BM45 Battery

While I was using my Xiaomi Redmi Note 2 the other day, I realized something strange was happening. It didn’t quite fit in its case as well as it used to, the screen felt a little like it was bowing, and the case itself had blistered a crack along its length.

More interestingly, there was a light leak from the edge of the screen between the phone body and the screen glass which wasn’t there before. Disassembling the phone revealed the culprit.

The battery had slowly swollen, and now no longer sits inside the battery bay correctly, instead being wedged between the rear shell and the body, exerting force onto the back of the screen.

Swelling batteries are nothing new – I’ve had the same experience with Samsung and my LG phone. To me, it seems that the quality of the lithium-ion/lithium-polymer cells that are used may be problematic, but also the way the phones treat the batteries. When fully charged, the charge termination voltages are now pushing 4.35-4.40v to squeeze a little more capacity out of the batteries, and the battery forms an integrated part of the power regulation mechanism resulting in “microcycling” of a cell that is fully charged, quite possibly wearing it out prematurely.

Swollen batteries are a potential safety hazard if they rupture. A high profile case recently is that of the Samsung Galaxy Note 7 where battery swelling (and insufficient clearance to account for it) appears to be a part of the reason why the units failed so spectacularly. In my case, it stopped my phone from really being usable without the risk of physical damage to the unit itself. As a result, I was forced to discontinue using the phone until a replacement battery came in.

The biggest disappointment was that this battery was only used for 11 months before it had failed, right before my upcoming trip, adding more things to worry about. The other cells often lived to 18 months or thereabouts before it failed, so this is a new record in terms of failure. A redeeming factor was that a “claimed” genuine replacement was only about AU$14, thus not breaking the bank. I’d rather that, than ever having to deal with GearBest (where I purchased the phone) ever again.

From the top, the swelling was much more obvious, resulting in the label peeling away from the plastic frame which still held its original shape.

The swelling was more extreme at the edge, and not as steep along the middle, but the gap between the straight edge and the cell confirms it.

In fact, a closer look at the cell shows there is a thin metal plate around the outside, which has lifted up. This suggests the cell is actually a Lithium Polymer cell with a thin metal shell for enhanced safety when handling the battery, required as the unit is user replaceable.

Teardown

Since I have no real reason to keep using the battery, I wanted to get rid of it. But I wasn’t going to just throw it out.

Once the label is off, the internal metal protection plate is visible, and in some ways, it’s constructed similarly to a CF card.

However, this metal plate is not just “loose” – it’s adhered to the li-poly cell pouch with double-sided adhesive. This is not good for disassembly, as being too rough and damaging the pouch can have catastrophic consequences. As a result, I decided to carefully tear the plates off, however, in doing so managed to stretch the pouch slightly so the battery looks more baggy rather than swollen.

The flat side reveals the cell is marked with PGF376279HT FAD97605 B6XFLJ5B1-22-195. The actual capacity is not printed on the pouch, and the actual manufacturer is not known. Maybe its lack of reputable branding is part of the reason it didn’t last as the other phone batteries I had previously used.

No further cell identifications were found on the other side.

The frame seems to be secured well to the cell using some form of potting compound so that it conforms to the shape of the li-poly cell within while sealing out moisture.

The protection board is a black PCB with white screen printing.

All the circuitry is on the opposite side, including a transistor, a polyfuse/fuse/resistor, a few capacitors/resistors, and a controller/MOSFET package under resin.

Conclusion

It’s a shame that just shy of a year of usage has seen my Xiaomi Redmi Note 2’s battery essentially fail. I did notice declining capacity, although that is usually not that unusual. The swelling made it mechanically impossible to continue using the battery without risking damage to the phone, thus I have torn it apart and disposed of it, while ordering a reasonably priced replacement. I suppose it’s a win for the fact this is still user replaceable.

However, I’d have to say that it seems likely the pushing of density and higher charge-termination voltages may have something to do with these failures. All in the name of a little more capacity, a larger number in their product specs, in the hope of drawing in more consumers without much consideration to longevity. Not my idea of sustainability.

Posted in Electronics, Telecommunications | Tagged , , , , | Leave a comment

Happy New Year: Sydney Fireworks Broadcast Side-by-Side Comparison

Happy New Year! Lets start this year off by taking a look at the new year’s eve fireworks broadcast.

This year, just like last year, the televised transmission of the Sydney Harbour new year’s eve fireworks was done by the Australian Broadcasting Corporation (ABC). Unlike previous years though, the ABC just recently launched their ABC HD station and thus will be bringing it to homes in high definition. This is in contrast with previous years and efforts by our other broadcasters including Seven, Nine and Ten who have all had their go (if I recall correctly) with varying levels of quality.

As with every year I’ve looked, this year there was a contribution feed of the fireworks in the clear (i.e. unencrypted). This year, I believe there was two feeds on Optus D2 – I tuned into 12670Mhz Vertical @ 7200kS/s DVB-S2/8PSK FEC: 3/4. Interestingly, the transmission was with Pilots ON, which improves reception stability for consumer-grade LNBs and tuners. The signal was received with 9-10dB SNR, which I consider barely adequate, but the link was very solid with no TEIs or CRC errors detected throughout the night. The uplink was provided by Telstra Broadcast Services. Adjacent, there was a feed that appeared to be related and at standard definition – potentially a path-diversity back-up or for syndicated stations without high definition capable gear.

ABC HD DVB-T Transmission

I recorded the TS throughout the event and demultiplexed just the ABC HD channel. The resulting MediaInfo stats showed a payload bitrate of 4648kbit/s for the video in H.264 [email protected] 1920x1080i 4:2:0 and 384kbit/s for the audio in AC3 2.0-channel. This is a bit more than the 3283kbit/s seen at launch, although I did note that it could increase by about 1Mbit/s just using up more null packets alone.

Video
Format/Info                 : Advanced Video Codec
Format profile              : [email protected]
Format settings, CABAC      : Yes
Format settings, ReFrames   : 3 frames
Bit rate                    : 4 648 Kbps
Width                       : 1 920 pixels
Height                      : 1 080 pixels
Display aspect ratio        : 16:9
Frame rate                  : 25.000 fps
Color space                 : YUV
Chroma subsampling          : 4:2:0
Bit depth                   : 8 bits
Scan type                   : MBAFF
Scan type, store method     : Interleaved fields
Scan order                  : Top Field First
Bits/(Pixel*Frame)          : 0.090

Audio
ID                          : 2321 (0x911)
Format                      : AC-3
Format/Info                 : Audio Coding 3
Mode extension              : CM (complete main)
Format settings, Endianness : Big
Bit rate mode               : Constant
Bit rate                    : 384 Kbps
Channel(s)                  : 2 channels
Channel positions           : Front: L R
Sampling rate               : 48.0 KHz
Compression mode            : Lossy

The transmission was not without a few flaws to the observant viewers. Just prior to the program beginning, the HD station faded into an SD feed, then swapped over to some internal promo card before then starting the actual program. Seems like a little timing issue to me.

Then, when the program started, for the first 3-4 minutes, there was an @ symbol generated by some video overlay device in the top left corner. It might not have been visible to all viewers as it might have been cut-off in the overscan, but it wasn’t supposed to be there. Luckily this was still early in the night before the family fireworks.

The televised DVB-T broadcast carried two watermarks – one in the top right with the ABC logo and one in the bottom left with the “Welcome to SYD NYE 2016”.

Telstra Broadcast Services DVB-S2 Feed

The feed was open, and featured vision throughout most of the night. When not running live camera footage, it would either run this test card above, or a highlight reel for the syndicating stations to record and later play-out. No local talent featured on the feed, and very few ad breaks black-screens featured throughout most of the night.

According to the test-cards and based on listening to the feed, the audio of the two streams were different – and likely because of rights issues with the music used with the fireworks. Hence there’s an “international” sound and “domestic” sound channel. The third sound channel was only ambient background sounds, so that it could be “mixed in” if necessary by syndicated channels in their edits.

While the feed was open, it was unlikely to be watched by many with a set top box because they chose to use a higher quality H.264 [email protected] 4:2:2 chroma subsampling at 10-bits video encoding. This ensures better colour definition in the output video. The data from MediaInfo and TSReader shows the bitrate was about 14Mbit/s, with multiple MPEG-1 audio streams at 256kbit/s.

Network Name: Telstra Broadcast Services
Network ID: 0 (0x0000)
Transport Stream ID: 0 (0x0000)
Original Network ID: 0 (0x0000) Version: 0

Program Number: 1
PCR on PID 1165 (0x048d)
PMT Version: 0
Service name: TBS SNG

Stream Type: 0x03 MPEG-1 Audio
 Elementary Stream PID 1125 (0x0465)

Stream Type: 0x03 MPEG-1 Audio
 Elementary Stream PID 1126 (0x0466)

Stream Type: 0x03 MPEG-1 Audio
 Elementary Stream PID 4144 (0x1030)

Stream Type: 0x1b H.264 Video
 Elementary Stream PID 1165 (0x048d)

Video
Format/Info                 : Advanced Video Codec
Format profile              : High 4:2:[email protected]
Format settings, CABAC      : Yes
Format settings, ReFrames   : 3 frames
Format settings, GOP        : M=4, N=12
Bit rate mode               : Constant
Bit rate                    : 14.0 Mbps
Width                       : 1 920 pixels
Height                      : 1 080 pixels
Display aspect ratio        : 16:9
Frame rate                  : 25.000 fps
Color space                 : YUV
Chroma subsampling          : 4:2:2
Bit depth                   : 10 bits
Scan type                   : MBAFF
Scan type, store method     : Interleaved fields
Scan order                  : Top Field First
Bits/(Pixel*Frame)          : 0.270
Color range                 : Limited
Color primaries             : BT.709
Transfer characteristics    : BT.709
Matrix coefficients         : BT.709

Audio #1
ID                          : 1125 (0x465)
Format                      : MPEG Audio
Format version              : Version 1
Format profile              : Layer 2
Bit rate mode               : Constant
Bit rate                    : 256 Kbps
Channel(s)                  : 2 channels
Sampling rate               : 48.0 KHz
Language                    : English

Audio #2
ID                          : 1126 (0x466)
Format                      : MPEG Audio
Format version              : Version 1
Format profile              : Layer 2
Bit rate mode               : Constant
Bit rate                    : 256 Kbps
Channel(s)                  : 2 channels
Sampling rate               : 48.0 KHz
Language                    : French

Audio #3
ID                          : 4144 (0x1030)
Format                      : MPEG Audio
Format version              : Version 1
Format profile              : Layer 2
Bit rate mode               : Constant
Bit rate                    : 256 Kbps
Channel(s)                  : 2 channels
Sampling rate               : 48.0 KHz

The transmission features a slightly different watermark in the bottom left only – without the “Welcome to” words.

Comparison and Observations

I decided it would be some fun to compare the two transmissions by converting them both to lossless FFV1 AVIs with ffmpeg, determining their offsets, then creating a “side-by-side” FFV1 AVI with the satellite feed video on the left and the DVB-T video on the right. This would allow for a rough side by side comparison of the quality throughout the transmission chain. As we know there are generational losses with lossy encoding, I was interested to know just how much “made it” to the end viewer, and how much might be lost along the way.

As a result, I first needed to know where my respective sources fit within the chain. Without working for ABC, I couldn’t know for sure, but based on the observations above and some which follow, I’d have to assume the chain looked something like this:

The source footage would be collected by cameras and fed into an on-site mixing/editing desk. As I didn’t see multiple angle feeds on the air, I’d assume they’ve done it this way so they wouldn’t need massive bandwidth to haul it back to their main studios. The links from the cameras have been drawn as wireless, as in previous years when I did attend the NYE event, wireless links were most commonly used although for the on-shore cameras, cables could also serve equally well. For wireless links, which the helicopter/drone footage definitely would be, one compression/decompression cycle would have likely occurred. I presume the editing desk on site produces two versions of the program – one copy for international syndication which has the overlay without the “Welcome to” and ABC logos on it and has no local talent shown, and the other for local consumption. The international syndication link would be passed off to a Telstra Broadcast Services van on site with its own encoder, modulator, dish, TWTA/BUC and sends it up to Optus D2 for all to receive. The other version of the program is likely to be passed to the main ABC studios not too far away – possibly by microwave link (possible compression in here) for the overlay to be added and various file clips/ads to be inserted. From there, it will pass through the studio transmitter link (maybe fibre, or something else) to the head-end DVB-T encoder and modulator for broadcast to the wider Sydney area.

So the satellite feed footage is not truly “raw” – it cannot be. It has its own compression, and the links from the camera to the desk may also have another leg of compression. But it does potentially avoid compression from the site-to-studio link (if it is used) and is a higher bit-rate and higher quality encoding. It’s also likely the 10-bit encoding may not be fully taken advantage of, as the input may have been already the decompressed output of an 8-bit depth device.

After synchronization of the two sources, at the time the ratings logo came up on the DVB-T transmission, the count-down on the satellite feed was at 44 seconds to midnight.

Early on in the fireworks program, the image froze for about half a second, and three corrupted frames were emitted. Both feed and DVB-T transmissions contained this error, suggesting the use of a wireless camera link from the shore side camera to the mixing desk which had uncorrectable errors within an MPEG GOP (suggesting the use of compression on this wireless link). Interestingly, already, picture quality differences can be seen in the full size images (click for full size) where the blockiness is more faithfully rendered by the satellite link – the DVB-T link gives a softer block edge. Note that no full size images have been deinterlaced, all of them are raw frame captures.

The drone/helicopter in use to shoot aerial shots had an unusual characteristic in that either it has an aspect ratio not exactly 16:9 or it somehow “robs” lines top and bottom for other purposes, and so they are blanked out. There is also some judder in the footage, and most frames captured do not have interlace – so maybe the camera was working at half the frame rate for better sensitivity, and the link used on the chopper had a different format/compression/aspect ratio which required the use of a media converter and possibly a second wireless link resulting in the less appealing images.

In some cases, side by side did not show too much visual difference at least when watching it in real-time. However, looking more closely, it can be seen that the DVB-T broadcast was more soft than the contribution feed – this is expected due to the bitrate constraint, re-encoding losses, etc. There is a slight colour difference at the seam as well.

There were a few frames where dark areas showed the limitations in the ABC DVB-T encoder, showing some obvious blocking where it had clipped to black almost suddenly and smoothed out details.

On very high detail fireworks, we can see that the satellite feed is crisp around the fireworks, whereas the DVB-T appears smoothed. The same detail loss is clear in the lower row of lights. This is where “high definition” and “1080” get thrown around by various online streamers and broadcasters, but depending on the bitrate, it can look completely different.

The same observation can be made about the detail in the smoke trails of the fireworks in this image. Another observation seems to be that ABC’s DVB-T signal chain has a two-line delay in it somewhere – the top line is black and compared to the satellite feed, it’s two pixels lower. Maybe this is due to some equipment chain requirements (e.g. overlay generators) without full frame stores, instead working on a line by line basis.

In the case of this frame though, the difference at full size is obvious. It’s as if I’m watching two different broadcasts – the closer firework should be even more detailed and resolved, but is less detailed than the satellite feed’s fireworks in the background. The bridge is clear on the satellite link, and murky on the DVB-T.

Ultimately, that shows you what is “lost” in the process of bringing it to DVB-T – I’m sure the quality at the camera and mixing desk would be even better than the satellite feed itself, so it’s a bit of a shame that so much effort goes into making quality footage only for it to be crammed down and lost before it gets to the end viewer, and sometimes due to the needs of “ensuring variety” on the DVB-T multiplexes.

Conclusion

On the whole, with the resources available, I think the ABC did a great job of covering the fireworks. It came through in HD, it was definitely a step up over past years, and it was free to air. It wasn’t without minor glitches, but who really cares about those. Live programs often have them anyway.

I suppose the biggest surprise was the half-second video freeze in both outputs, but things happen. Maybe a seagull flew by the line-of-sight of the antennas. The black bars on the helicopter/drone imagery was an unexpected find.

Having the feed was an interesting chance to see a little more of the fireworks by receiving the signal “further up” the chain in a less compressed form. The lower subsampling in the chroma keeps the colour better, and the higher bitrate resulted in a sharper picture. That’s nothing new or unexpected. The 10-bit encoding was probably unnecessary, but used anyway. Fireworks are a challenging thing for video compression to handle gracefully – sharp contrasty lines and lots of dark areas make quilting and ringing much more visible. However, the satellite feed handled it well – and it has to, because the syndicated stations themselves will edit and re-encode that again as they broadcast. The DVB-T feed handled it acceptably, but noticeably worse.

As for the fireworks themselves, they were claimed to be the best ever. But to me, I don’t know. It just seems pretty much like every year to me … but the TV transmissions weren’t.

Posted in Computing, Satellite, Telecommunications | Tagged , , , | Leave a comment