The [hopefully] full story SD Cards

I’ll attempt to summarize the SD card situation as I see it.

There are 3 main reasons why you might have trouble with SD cards in
your USRP2 -

  • You aren’t actually using an SD card. SD Cards have been made in
    sizes from 8MB up to 2GB. Any card of more than 2 GB is NOT an SD card,
    it is an SDHC card. They share the same connector, but they do not
    support the same access modes and will not work with the USRP2.
    Similarly, MMC cards look the same, but are very different inside and
    will also not work.

  • You aren’t programming it properly. You need root privileges to
    properly program the card, for one thing. Make sure the filesystem is
    not mounted in Linux, follow the directions here:

    http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ

  • You have a bad SD card. If you were part of the unlucky group that
    got bad cards from us in November and December, follow the directions
    from here:

    http://www.ettus.com/flash

If you bought the card somewhere else, there is nothing we can do. You
could try another one, or buy a known working one from us. We sell our
SD cards at a loss to encourage you to buy them from us and avoid
trouble.

We currently have very good luck with Kingston 2GB SD and 2 GB micro SD
cards, and that is what we ship now. Patriot 2GB micro SD cards seem to
be good, but recent Patriot 2GB full-size SD cards do not. Purple
Sandisk 2GB cards are good, but they are also the most commonly
counterfeited – because of their good reputation they command a premium
in the market. Older and smaller cards are more likely to work.

=========================================================================

So why would some SD cards work and some not?

We do not 100% understand the mechanisms behind this. It could be
actual problems with the cards, or it could be in the design we use to
read the cards. SD cards have many supported access methods and we use
one of them, SPI. You can see the design which we put in the CPLD on
the USRP2 to read from the card in the FPGA repo under usrp2/boot_cpld
and usrp2/opencores/spi_boot. CPLDs are very simple devices, and it is
not possible to handle all possible error or retry responses which a
card might give in response to a request, and that would make it fail to
boot. SD cards are normally read by a microprocessor which can handle
these cases due to increased resources.

Cards which don’t work with USRP2s usually work in cameras, but not
always. I just walked into a camera store yesterday and bought an SD
card for my camera, and it doesn’t work. It works in other cameras, but
not mine. I don’t have a USRP2 with me to test it, but the point is
that not all SD cards are created equal, as Bunnie Huang and others have
found:

http://www.bunniestudios.com/blog/?p=918

One thing that was left out of the above analysis is the fact that these
cards are made at many different factories, from parts from different
manufacturers. They are also commonly counterfeited or rebadged.
Sometimes a card with some bad flash will be sold as one half as large.
Often is there is no way to tell the difference between 2 very
different cards by looking at the packaging.

The SD card business is very complex. We are unable to buy them from
the manufacturers because we don’t buy 100,000 or more per month. We
are unable to buy them from primary distributors because we don’t buy
10,000 or more per month. Instead, we have to buy them from retailers
who are willing to sell them to us wholesale.

We have found a reputable consistent company to get cards from. But
even then, there can be problems. We shipped hundreds of blue Patriot 2
GB cards with no problems. Then all of a sudden we got a shipment with
half bad (for our definition of bad) cards. There is no way to look at
the card and see if it is bad or good, but the bad ones have a different
chip inside.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs