If you have a prototype board where your sensor works nicely, but when you get a new revision of the board but the sensor suddenly stops working, try these things:

• Check I2C device voltages. They are usually 3.3 or 5.0 volts. If not, trace back to your regulator or power supply. Always measure the voltage directly from the device power supply pins. If you use a circuit common ground point, you might see voltage but if the ground is not connected to the device, this will cause a problem and you will be scratching your head.
• Check that SDA and SCL are idling high. I2C data lines are always pulled up by resistors. Check that the lines are at 3.3 or 5.0 volts, depending on your voltage levels.

If the device isn’t responding, but the previous steps are OK, move on:

• Check that SDA and SCL are the right way round. Double check. Triple check. The I2C device will simply not acknowledge its address if the data lines are swapped and you are left scratching your head.
• If the device is operating at 5.0 volts but your MCU is working at 3.3 volts, there might be a problem with voltage level interpretation. For CMOS devices, it’s common to have logic high signal’s lowest voltage around 0.75 times the supply voltage. For 5.0 this is 3.75 volts. 3.3 volt I2C causes a problem where the device doesn’t recognize the 3.3 volts of the bus as logical 1. The solution would be to raise the I2C voltage if, your MCU permits. Some MCUs are 5V tolerant, or their supply voltage range might extend to 3.8 volts or beyond.
• Some I2C devices will work on practically any bus frequencies. Other devices may require specific operating frequency. Check the datasheet to see what the working frequencies are for your device.
• Timing is just like the frequency. Some device don’t really care, while others are extremely picky. This is where an oscilloscope comes in handy. Check that your start and stop conditions are as they are supposed to (see below). Also some devices may “lock up” if the SDA pulses when SCL remains steady. Check the device datasheet or ask the manufacturer if you suspect this kind of behaviour. You can also try to start-stop between sequences to clear these lock-ups.

The I2C defines a few signal level conditions. These are the start and stop conditions. Below is an oscilloscope screenshot from Silicon Microstructures SM9541 differential pressure sensor communication.

• The start condition is when SDA goes down, while SCL is held up.
• The stop condition is when SDA goes up, while SCL is held up.

Example I2C communication

It’s also easy to read I2C communication by hand, when you have an oscilloscope and the traces are lined up nicely. You simply look up what SDA is when SCL is going up. The screenshot above contains three 9-bit messages. Here is the first, decoded:

• Start condition (SDA down while SCL is up)
• 0 1 0 1 0 0 0 — 7 bits, device address
• 1 — 8th bit is high, this means it’s a read request
• 0 — 9th bit is low, this means that device on the bus acknowledges and communications can proceed
• The rest of the bits are device specific

In read requests, every 9th bit is the master’s acknowledgement. When the bit is 0, the master acknowledges (ACK). This way the device knows to keep going. When the master issues bit 1, which is not acknowledged (NACK), the device stops. The master then issues a stop condition.

I hope this little blob of I2C info helps you along in your project!

Anyway, back to the topic. You usually want to have a copper pour on your boards, be it ground or a power plane. Sometimes it just so happens that you send your Gerbers to the PCB fab but they reply back saying the V-groove will cut the copper, is this OK? Well, in one of my prototype boards I just told them “go ahead”. This is what came back:

The result (click for bigger)

It looks nasty, but the board is totally usable. You wouldn’t sell this to the customer, and actually I had one short caused by the bent copper near a connector. If you know the risk and you’re in a hurry, you can certainly let the V-grooving cut the copper. But I would advise to fix it anyway.

With typical V-groove specifications, you need to leave a guard area of 0.4 millimeters around the border of the board.

void probeAllAddresses()
{
 int i = 0;
 int addr = 0;

 for(i = 0; i < 128; i++)
 {
 addr = i << 1;
 printf("Probing address WRITE %x (%u)...", addr, i);
 i2c_start();
 if(i2c_write(addr))
 {
 printf("no ack.\n");
 }
 else
 {
 printf("device found!\n");
 }
 i2c_stop();
 delay_ms(100);

 }
 printf("\n");
 for(i = 0; i < 128; i++)
 {
 addr = i << 1;
 addr = addr + 1;
 printf("Probing address READ %x (%u)...", addr, i);
 i2c_start();
 if(i2c_write(addr))
 {
 printf("no ack.\n");
 }
 else
 {
 printf("device found!\n");
 }
 i2c_stop();
 delay_ms(100);

 }
 printf("\n");

}

For spammers: don’t waste those poor Indian people’s time on solving reCAPTCHA’s for my site. No one of your stupid spams have ever got through.

If you wish to contact me, my account is mristila and the email server is gmail.com.

To help me in this, I made a simple lookup table from mils to millimeters and back. I also included ITead Prototype PCB service rules since I think many hobbyists order their PCBs from ITead. Below you can find links for the PDF as well as the original Excel sheet, so you can modify it to your liking. If you like it, or find any mistakes, please leave a comment!

PDF cheatsheet: mils_to_millimeters_cheatsheet.pdf
Excel original:  mils_to_millimeters_cheatsheet.xlsx

Here is what I received:

The packaging

And here are the parts inside all of that packaging:

The goods

I bought a Samsung SCX-4200 around five years ago. I was just starting my engineering studies and figured I’d need a printer. Searching around for a suitable candidate, the SCX-4200 popped up. In addition to being a USB-connected laser printer it was also a scanner-copier. I think it cost 160 euros back then, so it was perfect for a poor student. The toner cartridge ran out after a year and in the end I didn’t really need a printer since I could do all my printing for free at school anyway. The scanner has seen twice the action than the printer part ever did.

Little over a year ago I finally decided to get a new toner cartridge. I ended up ordering a cheap knock-off cartridge from Germany but that didn’t end up too well. Read all about it from my blog post from January 2011.

Since I got a better printer (a used HP LaserJet 2300DN) there was no need for the printer part of the Samsung anymore. I did however need a scanner every now and then and yesterday I just decided to start doing something about it. The SCX-4200 had been in the closet for over a year, collecting dust. I took it out and started dismantling it.

Still intact (see the toner seepage in the paper tray)

You can see that the scanner part is “self-contained”, and sits at the top of the device. The gap between the body and the platen deliberate (you can lift it up to allow more prints to accumulate in one go).

The CPU board

The main CPU is an ARM7TDMI called Chorus2. It is, ofcourse, a Samsung-developed unit specifically designed for printer-scanners. It runs at 66 MHz, has 1 megabyte of RAM and 8 megabytes of memory for print/scan jobs. (If you want more details, get the SCX-4200 Service Manual.)

In the picture above, you can see a flat-flex cable and three different cable harnesses. The double-white is the fuser thermistor, so that’s unnecessary. The flat-flex is directly connected to the line camera unit in the scanner. The one behind the flex is scanner motor drive (bipolar stepper) and the red-blue one is the front panel data/power. The front panel communicates via UART at 9600 bps so it is very hacker friendly. It’s not necessarily needed but I connected it anyway.

Toner spillage

As I was rotating the device and unscrewing things the toner was spilling from every nook and cranny. The pirate cartridge had really spewed a lot of toner inside the printer. In case you’ve never encountered laser toner, it is really fine. Like flour but even finer. It stains textiles so be careful.

Main drive assy

As I was disassembling the unit I uncovered a lot of interesting things that can be definitely used again somewhere else. Notice the toner which has covered the gears.

Finally separated

Finally after half an hour or so I managed to separate the scanner unit from the rest of the device.

Inside the printer

Inside the printer is a lot more toner and more salvageable parts. The black flat box on top, that is secured to the piece of steel is the Laser scanner unit as Samsung calls it. This is the thing that actually “draws” the image in the process. It has a polygon mirror inside it and a 0.22 milliwatt laser emitter. (What to do with this thing? Any hack ideas?)

Power supply and logic

Engine assy, sounds fancy eh? That’s what Samsung Service Manual calls the green PCB. Anyway, here’s the other needed bit in addition to the scanner unit. Half of the power supply is redundant since we no longer need -400 V or 1.25 kV but I’ll use it just like this.

Test run

I decided to test the units separately before proceeding. It worked right off the bat. Windows 7 installed all necessary drivers automatically (from Windows Update), which is nice.

The operating panel LCD complains about the door being open and paper tray being empty but the scanner works fine nonetheless. I haven’t had it on for more than 15 minutes at one go so I don’t know if the CPU gets upset about the fuser unit not warming up to temperature. From reading the Service Manual I know that there are error conditions for too low a temperature, overtemperature and something called “open temperature”. These haven’t triggered yet, though. If they do, I might have to fool the unit by adding a resistor over the thermistor connector or something similar. I could get around the door open -error by figuring out which harness has the door limit switch but it’s just a waste of time for no gain.

Finished prototype

We’re nearly there. I took the power supply/logic thing and glued it to the bottom of the scanner unit. Some felt pads were adhered to the bottom. I have no materials/tools to do any better job so this will have to do for now.

This is a perfect opportunity to hone my 3D modeling skills though. Design a housing for the bottom part and have it 3D printed at Shapeways maybe… I’ll see if I ever get to that.

Scanning some PCBs

The scanner works just like before, only now it’s much smaller than before. Yay!

The loot

Here’s all the goodies that were salvaged. A beefy stepper motor with gears, the laser scanner unit (LSU, not pictured here), two solenoids, a round fan, a limit switch and an acrylic “sword”. I’m not quite sure what this sword does, it has grooves that rotate and get closer together. Either it’s an illumination device or it contains a photodiode in the end to capture light. Maybe it’s used in calibration of the LSU?

I call this project a success!

An Android device running on 450-megahertz ARM9

The processor I’ve chosen is probably the only hobbyist-friendly CPU capable of running real Linux. It’s Freescale’s i.MX233 which can be obtained in a TQFP package. The i.MX233 runs at 454 MHz but sadly doesn’t have any graphics acceleration. There are some videos on YouTube that show Android (mainly old 1.6 Donut) running so it’s definitely possible. 64 megabytes of DDR will be complementing the CPU. I haven’t decided on the display yet, but most probably I will go for a 320×240 LCD with a resistive touch screen. i.MX233 conveniently allows you to boot directly from an SD card so it’s impossible to brick this thing. If something goes wrong, just rewrite the filesystem on the card and pop it back into the i.MX233 system.

So far I’ve done some schematic capture on this project (CPU, DDR and SD portions drawn, PSU and display still needs to be done). After the schematics are complete, I need to verify them and proceed to PCB layouting. This thing definitely needs a 4-layer PCB which will be a first for me. I hope I can get this thing up and running with minimal troubleshooting because my 50 MHz Rigol scope or even the Openbench Logic Sniffer aren’t fast enough to debug DDR memory lines. I wish I had the bucks to buy a fast scope!

A GPS logger

See a pattern here? Yes, the best way to learn is to re-invent the wheel.

I’m aiming for a polished, end-user friendly project. This will be simple by specifications, but still takes quite an effort to get finished. A generic GPS receiver will provide location and altitude data to a microcontroller. I haven’t yet decided on an MCU but I’m probably going for a Microchip PIC simply because I want to learn about them. In the past I’ve always used Atmel AVR so this is a perfect opportunity to try out something new.

User interace works via a few buttons and a small LCD. The device will save the location and other data to an SPI Flash memory. Power is provided from an onboard single cell lithium polymer battery. When plugged into a computer the device will charge its battery and provide a method for offloading the collected GPS data to the user. The MCU is probably configured as a virtual COM-port and a small program on the computer side will query the data and output suitable files (for Google Earth perhaps).

The most trouble for me at the moment is proper handling of the battery. You can’t overcharge it nor overdischarge it. This is practically always handled by the battery, but I don’t want to risk it. I have decided on the battery charger chip (MAX1811) and the system power regulator (MAX710). Overcharging protection is handled by the MAX1811 but I’m not so sure about overdischarging. MAX710 has a low-battery comparator and a shutdown input so theoretically I could set the low-battery comparator to, say, 3.2 volts and then run the comparator output straight into the shutdown input. That might start to oscillate as I have no idea if the low-battery comparator operates after shutdown is active. The datasheet is a bit ambiguous about this.

So far done: nothing else but component selection. I might just have to order the Maxim chips and see if my theory about the low-battery comparator works or not.

HDMI Philips Ambilight clone

This might be a world-first. An Ambilight clone that works stand-alone from an HDMI video stream. There are a gazillion different Ambilight clones in the internet, but every single one of them relies on a computer to do all the heavy lifting. The actual hardware usually consists of a slow microcontroller that does nothing else but receive light intensities over a serial port and modulate RGB LEDs. This is a very effective method on one condition — that the source is a PC.

A few projects have aimed for stand-alone, such as Chameleon, but they work off of relatively slow signal like composite video. Chameleon showed promise but it’s development has ground to a halt over four years ago.

My idea is to pair a FAST microcontroller (the STM32F4, ARM Cortex-M4 running at 168 MHz) to an HDMI receiver (Analog Devices ADV7611). The trick is not to capture the whole image but only portions of interest. That way the processor is able to pull this off on its own.

Another idea that I came up with is to have a daisy-chained RGB LED boards instead of having the main controller modulate all the individual RGB LEDs. I have actually already designed this board (schematic and PCB layout). They consist of a very small ATtiny microcontroller and three MOSFETs to drive the RGB LED. Three leads come in to the board and three leads go out. These are power, ground and data. Data format is not yet decided upon, but it is going to be something simple. One candidate is to have four-byte packets that contain one address byte and three bytes for intensities for each RGB component. The main controller needs to know where the daisy-chained boards are and how many of them there are to calculate suitable values from the image data and pass them on. Data link from main controller to RGB boards is unidirectional.

In addition to the RGB board I’ve started work on the HDMI receiver. The schematic is ready to go. PCB layout is doable in two layers. The first prototype will only contain the ADV7611 and its power supply. Pixel data is broken out to a pin header that can be wired into an STM32F4DISCOVERY development board for post-processing. HDMI is also receive-only, so an active HDMI splitter is required. In the final revision there should also be an HDMI transmitter on the board to allow simple pass-thru operation.

What about HDCP I hear you ask? The ADV7611 has built-in HDCP decryption and keys. I don’t know how this works in practice but again it should be doable.

Touch-screen GSM phone

This one’s pretty old, the idea dates back to summer 2011. A simple 320×240 LCD with touch screen is paired with an STM32F4 and a SIM900 GSM modem. I’ve done the schematic and PCB layout. Both need verifying and revisioning before placing an order on the PCB though. 80% of this project is ARM software, which I’m not very keen on.

Laptop DJ’ing device

The idea is to combine two PCM2706 (as used in my USBDAC), a USB-capable microcontroller and a USB hub to a single device. The microcontroller would mimic a MIDI device that would send control messages to the PC. This would then be used as a companion to Traktor or Serato and a separate DJ mixer. Traktor outputs the two decks’ audio into a DJ mixer’s A and B channels. User can then apply effects using potentiometers that are translated into MIDI control messages that Traktor interpret. Pre-fader listening and mixing is done outboard on a separate mixer, while beat-matching and pitching is left for Traktor.

Done: component selection, schematic capture 75% done.

–

Phew, that’s the ones that I have on the top of my head. Believe me, I’ve got TONS of ideas stirring in my head. I just wonder where I’m going to find all the time to work on these and more importantly, just think of all the money that is going to go into the components alone…

1. Introduction

In this article I will discuss my own experiences about designing a USB sound card, which is the USBDAC. DAC is an acronym for Digital-to-Analog Converter because in a sound card, digital data representing the sound is converted into analog voltage that moves the speaker cone.

My device is loosely based on the PCM2706 reference design. I will not go through the tecnical details but instead concentrate on my own experiences in the design of the device. This is to keep people not familiar with electronics, as well as newcomers to electronics design, interested. You will see that one working product is the result of many failed prototypes.

2. The PCM2706

First, let me introduce the star of the occasion. PCM2706 is a USB 1.1-compliant peripheral, that implements the USB audio device class. This means that when you plug in the PCM2706, the operating system knows that its a standard device and can start using it without a separate driver.

The PCM2706 was designed by Burr-Brown, but since TI bought BB, it’s now being manufactured by TI. PCM2706 supports up to 16-bit 48 kHz sampling rate. This corresponds to CD level quality. It has a built-in headphone amplifier and a digital S/PDIF output for example home theater amplifiers. The headphone amplifier puts out a reasonable 175 milliwatts (0.175 W). The device is available in prototyping-friendly 32-pin TQFP package. It has a built-in 3.3 V regulator, so practically it doesn’t need any other than passive components to function.

More details and datasheet can be found at TI’s PCM2706 info page.

One PCM2706 costs around 8.4 euros (0% VAT) at Digi-Key, so it’s not very cheap. In volume the price will, of course, drop, but hobbyists might want to check out TI’s excellent sample service. A few PCM2706 samples will arrive from USA in less than a week and TI pays all the expenses (duties and taxes included, if applicable).

A small moral notice on behalf of the electronics enthusiast community: don’t order samples just because it’s free. If you have no intention of using the samples, don’t order them. Manufacturers give out samples very generously, and if people start taking advantage of them just for the fun of it, they might stop. This has happened in the past with some smaller semiconductor companies.

3. A Gallery of Failures

In this chapter I will go through all the revision from the first to the last. You will see that to make one functional device, you have to fail atleast once or twice. :-)

3.1 Prototype Revision A

Prototype A was a 1:1 copy of the datasheet reference design. I had made atleast five different mistakes that caused the device not to function even after I had bypassed the mistakes with jumper wires. The device was caught in an endless USB enumeration loop that was illustrated by the Windows “new device found” sound being heard ad infinitum. The PCM2706 was probably killed because USB’s 5 volts was fed into its 3.3-volt regulated pins. In addition, I was missing crucial pull-ups/pull-downs and the digital out lines that I chose to include didn’t work because they were configured incorrectly (also pull-ups/pull-downs).

In respect of PCB layout design, no rules were followed. There isn’t even a copper fill on the top layer. The design is in effect one-sided since the whole bottom layer is a ground plane.

Populating this board was the first time I did surface-mount soldering and it shows. All small resistors and caps are 1206. Bigger electrolytic caps have wrong footprint, so I had to bend their leads down to get them soldered.

3.2 Prototype Revision B

B-version was much more polished. I removed all the errors that I found in the A-version and checked the schematics a couple of times before ordering. I ordered the PCBs for the revision A without even a second look which of course was very stupid. Experience has taught me that.

The “beta” didn’t work the first go (surprise!). A couple of mistakes made it through to this version as well. The device VDD (3.3 V) does not equal USB VBUS (5.0 V), so I cut that trace. In addition the USB D+ line has to have a 1.5 kilo-ohm pull-up but I had instead specified a 1 megaohm resistor. These were easy fixes though. It wasn’t recognized by Windows though. The USBDAC was caught in the enumeration limbo again, just like the prevision version. I deducted it must be toast because I again fed five volts into its regulated pins. I soldered together another board with the aforementioned fixes and this time it was recognized immediately. The feeling of success was intoxicating as I watched the analog output bounce up and down on the oscilloscope screen.

I quickly soldered together the analog output stage and added the 3.5-millimeter headphone jack that was now part of the PCB design. After connecting the headphones I made to discoveries. Firstly; the headphone amp is very powerful. On earbuds (Sennheiser CX-300) Windows mixer’s sound level has to be 1/100 so that it’s not too loud. On bigger headphones (Beyerdynamic DT331) a nice level is around 5 to 10/100. Secondly; the bass was completely non-existing. Otherwise the sound was very nice, with a lot of crispness in the mid-tones and higher end. I started to investigate the bass problem by looking at my schematics. It didn’t take long to find the source of the problem.

The output stage has an RC-type high-pass filter with a 100 microfarad electrolytic cap and a 3.3 kilo-ohm resistor. The corner frequency of the filter is around 0.5 Hz to filter out DC from getting into, and ruining your speakers. Somehow in my schematic I had specified 100 uF cap and a 16 ohm resistor giving me a corner frequency of 100 Hz which nicely cuts out all the bass frequencies. This was, again, a quick fix as I replaced the resistors and now it sounded magnificent. About 25% of that magnificence was just from the success but in the following days I used it to listen to a lot of music while at work and it didn’t start to sound any worse. Compared to my work PC’s built-in Realtek HD, it actually sounds better. The reference setup consists of Edirol MA-10A monitor speakers’ headphone out and Beyerdynamic DT331 headphones.

There was one problem with the layout as well; the audio channels were swapped. This is no problem with music but it would have to be fixed to the next revision.

3.3 Revision C — Third Time’s the Charm

I worked on the third revision patiently since I no longer had any rush to success. I started designing the schematic back in September 2011. I drew the board layout on one hung-over sunday in one go in October 2011. I made necessary modifications and fixes in the following months as I perfected the design.

The PCB design was again in practice one-sided since the bottom was a single continuous ground plane. This time I paid attention to signal trace lengths (clock signal), USB differential signal routing and grounding. The grounding is star-type since all ground points are connected directly to the ground plane. The clock source is no longer a crystal with parallel loading caps, but a self-contained crystal oscillator. At the moment I have a regular XO (Xtal Oscillator) installed but in the future I plan to try out if a TCXO (Temperature-Compensated Xtal Oscillator) makes any difference. There is also a spot for a 128-byte I2C EEPROM on the PCB for providing a custom USB identification. By default the device enumerates as “USB Audio DAC”.

A bigger change in this revision is that I designed it to fit in an existing case. The case is a Hammond 1551S, which is small at 50×50 millimeters. I got the case only in March 2012 and even though I designed the board in October 2011, it fit perfectly.

After populating the board it worked instantly. It sounded like it should. The only “problem” at the moment is the output stage aluminum electrolytic caps which are too tall to fit in the case. I have ordered the replacements, Nichicon Muse F95 premium audio tantalums. They should make the bass even better. I haven’t yet tried the I2C EEPROM identification but after checking the schematics and comparing to the datasheet many times, I don’t think it will be a problem. A bigger problem will probably be the tiny physical size of the EEPROM. :-) There is a solder jumper P4 on the board that selects between default ID and the EEPROM.

Here is the finished Rev C board being tested:

4. Thoughts After The Project

When I started this project I didn’t really have much experience or knowledge in designing a PCB. It showed. In the past year I’ve gathered a huge amount of real-world knowledge and experience which is invaluable. I don’t think I will learn quite as much in such a short time ever again.

The foremost thought on my mind is that you should never be too rushed to order the PCBs. Part of that problem for me was that getting finished PCBs from ITead Studio takes almost a month. The other part of the problem is my short attention span. :-)

I’m happy with the project. The only thing that I think about is the real performance of the device. Does it meet TI’s specs (THD, SNR)? Does it exceed them? What is the real power of the headphone amp? I have no way of measuring these, so they will be a mystery.

I would be happy to receive comments from more experienced designers about my PCB design and other things. What could I have done better? What did I do well? If you are a beginner, I hope this brings your expectations about electronics projects closer to reality.

Since the gf wouldn’t approve of buying a new phone, I decided to root and mod the Desire. A few hours of Googling and trying to find clear instructions how to do the job I finally had ICS installed. Most, if not all, of the instructions assumed a thing or two which made the process not work for me. All of them recommended using unrEVOked 3 which should take care of all HTC phones. I downloaded unrEVOked, installed the HBOOT driver as instructed. It was very important not to have HTC Sync installed, which I didn’t because that program is a piece of shit. All good, right? Wrong. unrEVOked couldn’t find my phone. What’s wrong? I did all the necessary steps but it still doesn’t work. The problem is that all the instruction writers assumed I had, at one point, had HTC Sync installed which also installs some kind of “ADB” drivers which are required. After installing HTC Sync, confirming it works and then uninstalling (making sure not uninstall the “HTC Drivers”) unrEVOked finally found my phone.

Off it went, restarting the phone into HBOOT, doing its thing. 5 minutes later I was greeted with the “failed to get root, is your software too new?” error message. *sigh* Indeed I had the most recent HTC OTA update which defeated the poor old unrEVOked.

45 minutes worth of Googling for all kinds of FAQs, I accidentally stumbled upon one blog comment which mentioned Revolutionary. I downloaded it, generated a key for myself and finally was able to root the phone. Revolutionary kindly asked me if I also wanted the Clockwork Mod to be installed. I answered yes and moments later I had a rooted phone capable of installing ROMs. (Btw, what a stupid name for a firmware package. Why not just call it “firmware” or “operating system”?).

I backed up everything from the Clockwork Mod menu, switched the MicroSD card from 4 GB to a blank 8 GB one, formatted it and installed ICS. Installation went smoothly and soon I had it running. The first start took very long, probably 5 minutes. After that I was ready.

Android 4.0.3 on HTC Desire

There’s a few bugs with the current ICS Beta 0.4.1.1 from Sandvold but if you avoid those, it works quite OK. The bugs are:

• Camera preview doesn’t work. When you take a pic, they come out fine, but it’s kind of hard to compose the picture if you can’t see any preview.
• The phone usually freezes if you tilt it horizontal in home screen. Sometimes it copes, most of the time not. The Desire boots automatically if it freezes. Solution: turn off automatic rotation of screen (Settings -> Display) or try to always hold it vertical while in the home screen. Tilting works just fine while you are in a browser for example.

Other than that, I’ve not encountered any other problems so far. Thumbs up for Sandvold & co. for making the ICS for Desire happen!

To my great surprise, the UI is very snappy. All the menus work nicely, and best of all, the web browser seems much faster (the UI responsiveness most of all) than the old 2.2. I recommend you try out this ROM.

Here are the necessary URLs to root and mod your Desire:

• ICS Beta 0.4.1.1 mod ROM
• Revolutionary for rooting and installing Clockwork Mod