Archive for the ‘hardware’ Category

Server replacement

Thursday, February 17th, 2011

It’s been a while since my last post, but I’m still alive and kicking (happy new year btw :P). Another thing-to-do-before -you-die was building a decent server. At the time I found a 2nd hand 14U 19″ rack build by HP. Also picked up a 4U Chenbro 16-bay hot swap case and build a massive storage server. Love the setup, but over the years it only seemed to grow bigger and bigger. The rack itself is build like a tank (and weighs 61 kg without server!), but with a size of 72 x 100 x 60 cm I’ve been on the lookout for something smaller.

Until today! I’ve gotten an offer noone in their right mind would refuse (as in biggest discount ever received). Components won’t be here until early next week, but here’s what’s in the pipeline;

  • HP ProLiant MicroServer
  • 8GB DDR3 RAM with ECC
  • 10TB storage with RAID5

Still working out the details, but as it’s only 27 x 25 x 21 cm in size, weighs under 10 kg  and is much more silent, it should be a major improvement. Interesting times ahead :D

Using a SPI DataFlash

Sunday, December 19th, 2010

Memory chips used to be a pain with all their address and data lines, but no more. Today I hooked up the 32 Mbit DataFlash (an Atmel AT25DF321A in case you skipped my previous post) to the Bus Pirate and I can barely believe how easy it was. Here’s a shot of the entire setup:

All you need to do it hook up the SPI lines and apply 3,3V power. As a first test requesting it’s manufacturer and device ID seemed logical:

SPI>[0x9f r:4]
READ: 0x1F 0x47 0x01 0x00

Only 4 bytes are returned, but it indicates the chip is working as it should be. The first byte (0x1F) means Atmel is the manufacturer. The 2nd and 3rd byte hold device information and exactly match the datasheet (AT25DF series with 32-Mbit density). The last byte is optional according the JEDEC standard and appears to be unused. Well this confirmed things were working, so next would be reading and writing data.


High speed USB protocol analyser

Friday, November 26th, 2010

For those interested in reverse engineering and/or developing USB devices, check out this project: “OpenVizsla” Open Source USB Protocol Analyzer. It’s under development, but looks promising and offers high speed at an affordable price.

USB SATA bridge

Saturday, November 13th, 2010

A while ago I thought about using a SSD instead of a SD card to the musicplayer. Since SATA IC’s aren’t exactly easy to obtain, I headed over to DealExtreme for a Mini USB 2.0 to SATA Dongle with the intention to rip it apart. Took a month to arrive (if you’re expecting stuff from China be prepared for a long wait… packages seem to take ages to arrive these days…) but today the day has come to go berserk (well actually the casing came apart pretty easily).

I was kind of expecting some kind of  JMicron chip, but was surprised to find a Moai MA6116 chip (and an unmarked crystal). Unfortunately no datasheet, but who knows what this thing can be used for. The manufacturers website only mentions this (for the A revision):

MOAI MA6116A is a bridge chip for USB to SATA interface, translating the host SCSI command to ATA/ATAPI command of SATA device, targeting the external HDD application. MA6116A complies with the USB Storage Class specifications ver.1.0 Bulk mode protocol and compatible with Windows 98/2000/XP/Vista/Win7, Mac OS 9, Linux Redhat. With the in-house DMA and Transceiver capability, MA6116A provides the market most outstanding read/write performance and BOM cost.

It’s like a black hole sucking up time instead of light <:)

Wednesday, September 29th, 2010

Dev boards

Monday, September 27th, 2010

Yee a new ‘toy’ has arrived. After waiting only 3 months to the day, a little carton box containing TI’s MSP430 Launchpad board finally found it’s way to my doorstep. It was cheap, comes with free tools and no shipping costs which is a huge pro if you just want to try a new product. No idea what to do with it yet, but I’m sure something fun can be made with it.

Also very nice are the extras. Apart from the nice box it comes in, it includes 2 controllers (2211 and the 2231 which has an USI and ADC), a 32.768 kHz crystal, headers and an USB cable. And to top it off there are 4 anti-slip pads beneath the PCB (it’s often in the small details). Kudos to TI!

Btw, this thing is actually sold below the actual cost of the parts. Just the 2 LQFP IC’s (a Serial-to-USB Converter and a 16-bit ULP MCU with 55kB Flash and 5120B RAM) are over $10 @1k units.

Speaking of dev boards, ST recently introduced a nice STM32 board. According to ST you can get one for under $10, but I haven’t seen those, not even at the distributors they link to. A more realistic value is €12,55 which boils down to $16,90 incl VAT at today’s exchange rate. Yes that’s right, 160% more than ST advertises with. Still not bad, but saying it’s under $10 is just a big lie.

Anyhow, I’m thinking of getting 1, mainly for quick testing. Right now the Futurlec board and some chips is all I’ve got, which is a bit of a pain when you quickly want to swap boards for some simple testing. Besides that I’m looking forward to giving that ST-link thing a try.

The downside is that ST throws up some barriers. You can only buy the board through big distributors, which for us Europeans means you’re screwed as a private person. These distributors won’t even talk to you unless you place a minimum order value which is way higher than the board alone. ST can learn a thing or two from TI when it comes to bringing their products to a wider audience.

Secondly the whole ST-link thing only comes with Windows software. However no surprise there given their complete lack of non-MS support previously. A bit of a downer, but no show stopper.

S/PDIF is here to stay

Sunday, September 19th, 2010

With playback working again it was time for another addition; digital out. After some soldering and enabling I2S on the decoder the setup was ready for test run. Hooked the monster up to an Onkyo receiver and voila.

First some details. Currently the VS1053B is configured to output a samplerate of 48 kHz (this is also the highest supported samplerate for all codecs). This goes directly into a CS8406 S/PDIF transmitter which is wired in hardware mode. A second option would be a 96 kHz I2S signal. Even though the decoder support 192 kHz it can only output it with MCLK divided by 2. The CS8406 only supports clock ratios down to 128 * Fs. For 192 kHz to work it must go down to 64 * Fs.

At the moment it only uses TOSLINK, but the final version will also have coaxial output. It’s just that I don’t have the required pulse transformer lying around.

Back to the receiver. It detects the output as a 44,1 kHz PCM signal. For a more isolated test I hooked up AKG K 701 headphones which is know for it reference like quality. And wow, what a thrill. This was simply the best sounding audio I’ve ever heard not coming from a real CD.

I could still hear some things I didn’t like (high tones), but at this time it’s unknown what the cause is. Could be the recording itself (need to compare with original CD), it could be samplerate conversion (48 kHz to 44,1 kHz), could be the setup (just think of how anal audiophiles can be about the smallest things ;)), etc. Just a matter of proper testing, listening and comparing.

Also one thing that’s bothering me is the interference the setup has on my cable TV signal (doesn’t affect HDMI). At the moment I’m just blaming all the breadboard wiring which probably acts like a small transmitter. The board is located almost directly below the inputs of the TV and since the cable signal already is very weak (some stations are half snow even without any other electronics close by), so it’s not directly a problem (not to mention the lack of programmes worth watching… but that’s another story ;))

Another milestone reached

Sunday, September 12th, 2010

Good news, SDIO is working, including an upgrade from Petit FatFs to FatFs.

Basically there were 2 problems. Some time ago I ripped some stuff from the breadboard to tidy things up a bit. Unfortunately this included a wire connecting the PSU to the right most power rail. As fate would have it this is where I attached the 3,3V of the SD card socket to a few days later. As long as the missing connection was well.. missing, the SD card was powered by the SDIO signal lines through the pull-up resistors. This resulted in unexplainable behaviour such a Kinston card to timeout at CMD8 and a Sandisk card never completing the voltage validation cycle.

The other thing were CRC errors during transfers. 25 MHz is simply too much for the current setup, which in all honesty isn’t really surprising given the long and poor connections. A real PCB and some pull-up resistor tweaking should make a speed increase possible. Currently it’s running at 4,2 MHz (simply because 0x0F is an easy to remember CLKDIV value ;)), but what this means in data throughput numbers… no idea yet.

Oh and it uses DMA, which also is a nice addition!

SDIO power up

Wednesday, September 8th, 2010

Time for a little update. SDIO code is ready and under testing, although that’s not exactly going according to plan. After sending CMD8 it times out and the fun is over. A little annoying problem, but interesting nonetheless. For example did you know what the D0 signal looks like directly after setting the power state to on? Now you do ;)

Notice the long power up / supply ramp up time and the voltage it stabilises at.

STM32 code upload woes

Wednesday, August 11th, 2010

For the past 2 evenings I’ve been trying to figure out a strange problem I was having while uploading code to the STM32 board. As it stands now the mystery is finally solved. What was happening was that the flash loader wouldn’t recognise the controller…. except when I connected the ground clamp of my digiscope to the board’s grounds. Measured everything and all seemed ok, just as long as the clamp stayed on. Checked the entire chain multiple times from beginning to end, PSU, board, USB to RS-232 converter and cable connections. Nothing to be found….

But then in a rare flash of brilliance I noticed the PSU of the board and the power adapter of the laptop were plugged into wallsockets on opposite sides of the room. Plugged both in on the same side and the problem disappeared. At this time I cannot explain what was going on, but I’m glad it’s solved now. Took enough time to figure this one out.