Dreambook W7: Cheap and apparently features-packed but unusable Chinese-made Android tablet

Well, if you're intending to buy this tablet, the title says it all. This article serves as a reminder to watch out for things that are too good to be true. Save your money and buy a proper tablet!

It all looks promising at first - the Dreambook W7 is an Android 2.2 tablet (upgradeable to 2.3) running on a 1GHz Freescale IMX515 processor, 512MB RAM and 8GB internal storage. The device also has GPS, Bluetooth, SIM card slot (supports 3G, call and SMS), SD card slot supporting up to 16GB, mini-HDMI output and USB host capabilities, all for 350 SGD.

Upon first look, with the HOME button, the device looks like a giant iPhone with a lot of extra connection ports. It is also thicker and heavier than other tablets. No problem yet considering the price, I guess.

However, after some initial testing, problems soon emerged. The following list summarizes my findings:

1. The touchscreen is very sensitive, to the point that makes the device unusable. Scrolling through a list or a web page would just randomly clicks on items or links on the screen. I install this app, which reduces the sensitivity and seems to help a little, but it's still not good enough for web browsing.
2. Sometimes it is very hard to get passed the Android lock screen - the green button cannot move long enough to unlock the phone. I disable the lock by using the NoLock app.
3. In landscape mode, text box occupies entire screen area once the keypad is shown. This is a classic Android bug, reported here.
4. Even in landscape mode, the launcher home screen or program list still shows in portrait. But other screens appear correctly in landscape. Using a custom launcher such as ADW Launcher correctly changes the orientation, but the icon spacing is wrong.
5. No matter which firmware I tried, the FM radio doesn't work and just produces white noise, even when the headset is connected. (The headset is known to be used as an antenna in many phone radios)
6. GPS works intermittently, depending on which firmware I am using. On some firmwares, GPS seems to be working but reports fake location of 0N 0W. Where GPS is working, it reports 2X the speed so it can't be used when driving. Location determination using cell ID and wifi network doesn't work. Neither does the compass work.
7. Despite numerous sites saying that this device has USB host, I could not get it to work. Basically, it doesn't even supply power to the connected USB device such as a mouse or a thumb drive
8. Even with the SD card unmounted, hot-swapping the SD card may hang the device. Changing the SIM card while the device is on will definitely lock it. To reset the device, press and hold the reset button, which is also the power indicator light, on the bottom left side.
9. The device does not seem to support "reboot". The default "reboot" option in Android and all other tools will simply turn the device off.
10. Many firmwares will have problem receiving incoming SMS (the message is not shown and discarded) while sending outgoing messages is fine.
11. Finally, things got worse with the Android 2.3 Beta firmware. Wifi will not work until wifi sleep policy is turned off, and 3G works intermittently.

With the long list of problems, all with common use cases, I guess Synrgic, the manufacturer, does not have any kind of quality control over their products. There is also no good official tutorial to flash firmware for this device and all firmwares I could find are uploaded using various file sharing websites, not on the company official site like other devices.

Flashing the firmware

Flashing firmware is a pain on this device. First, you will need to find the correct ROM for your hardware version (either HD104 or HD105). Then, get the device into recovery mode: press and hold the HOME and BACK key and press the POWER key for a few seconds. Copying the bootimg.tgz and update.zip to /sdcard and use the recovery menu to start updating. Notice that on some firmwares, the internal memory is mounted as /sdcard and  the SD card itself is mounted as /sdcard/extsd so you may need to copy the images to the device main memory.

Sometimes it just seems impossible to start in recovery mode despite pressing the correct key combination - the device will just perform a normal boot. You can get over this by using an app to reboot into recovery mode (the device needs to be rooted via z4root). The Dreambook will then turn off, and when started again, it will show the recovery loader.

Another way to flash is via MFGTool, a utility by Freescale, manufacturer of the device's processor. This should be used only at a last resort since incorrect usage may brick the device and turn it into a paperweight. The steps are as follows:

1. Used Windows XP. Windows 7 may require applications to have admin privilege and different drivers which will just interfere with the flashing process.
2. Download the MFG ROM package of the device. Some ROMs can be found here.
3. Start the device in recovery loader, then choose "Wipe for MFG". Connect it to the USB port of your computer, then press and hold the RESET button for a moment.
4. The PC will then find a new FreeScale BulkIO device which require driver. Install the device using the driver supplied in the MFG ROM package. If the device is identified as Mass Storage, disconnect everything, reboot the device and try again.
5. Run MFGTool.exe. Click “Options” menu at upper-right corner, and further click configuration item, you can find below pop-up window. Click “USB Ports” tab, you can view all the USB port. Choose the one to which your device is connected and click “OK” to close the window. 

       6. Click the green Start button and the flashing process should start. At the end of the process, the tool may say "Connect device" or report an "Updater Error". This is normal and the device should boot up to Android.

The latest firmware available is V25 (27 May 2011). Unfortunately it seems that Synrgic has stopped supporting the Dreambook W7 and decided to move on with their other products and no future firmwares will be available.

My conclusion is that the Dreambook W7, with a lot of out-of-the-box issues, can never be used as a productivity device, only perhaps as an expensive tool for advanced users to learn more about Android by trying different firmwares and applications in an attempt to solve these issues.

Read More »

Rebuilding the Olevia LT19W 19-inch LCD TV Remote Control Unit

I have here in my room an Olevia LT19W 19" LCD television that has no remote control unit. The buttons for this TV are located on the top panel so it would be a hassle to change volume or channel while watching. I decided to buy the RM-68 universal remote control from eBay hoping that I will be able to configure it to be used for my TV.

Unfortunately, I was wrong. None of the suggested codes I found online could make the remote control work with my TV. I also spent half a day trying most of the codes listed in the instruction manual, but none works. My last try is to use the auto-search mode, which automatically tries all supported codes to see which one works:

Finally after 20 minutes of pressing the VOLUME+ key, I got my TV not to show the volume control as expected, but to display "Normal" at the bottom of the screen. What should be the volume control key turned out to be the key to change the "Picture Mode" of the TV. The TV also recognized some other keys on the RM68 but the mapping was wrong. For example, pressing channel 2 on the RM68 would turn off the television! In other words, although the TV responds to some keys on the RM68, it can't be used.

I then had an idea. Since I had quite a few keys on the RM68 working, I may be able decode the remote control protocol for this TV. build a PIC-based remote control to simulate other keys and map them to a learning remote controller, which will be used in the long run.

Decoding the protocol

My initial research shows that most TV remote control use consumer IR which transmits using an infrared wavelength of 930 nm, 870 nm or 950 nm at carrier frequency between 33 to 40 kHz or 50 to 60 kHz, with 38kHz being the most common. To decode the protocol, I picked up a TFMS 5400 IR receiver from my junkbox, which is optimal for 950nm infrared @ 40kHz carrier frequency. Although the RM68 transmits at 38kHz, the "Relative Frequency" graph on page 3 of the datasheet shows that the TFMS 5400 would still detect 38kHz signal, just at 95% of the sensitivity. Following the datasheet, I built the receiver and fed the output to channel 1 of my Rigol DS1052E oscilloscope:

 

By pointing the remote controller at the receiver and pressing a few keys while observing the oscilloscope display, the protocol soon became clear. Each key will transmit a data stream, consisting of an ID byte identifying the TV and a data byte identifying the key, in the following format:

[header] [ID byte] [~ID byte] [data byte] [~data byte]
where ~ represents bit-wise NOT operation

The output of the receiver is active low and will remain high if there's no signal received. Each data stream starts with a header consisting of a low pulse for 9ms followed by high pulse for around 4.3ms. The ID byte (which is 8 for the Olevia TV) and its complement (e.g. bit-wise not) is sent following the header. After the ID byte is the byte for the key pressed, and also its complement. Binary 0 is represented by a pulse for 0.5ms and binary 1 by a pulse for 1.6ms. There is a delay of 0.6ms between every bit. Bytes are sent in little-endian format, with the least significant bit being sent first. Depending on the key pressed, the data stream may last anywhere between 50 and 90ms.

For example, the following data stream represents the POWER key, whose data byte is 0b00000010 (2 in decimal)

[9ms low] [4.3ms high] 00010000 11101111   01000000 10111111

The following screenshot from the Rigol oscilloscope shows the header and the ID byte:

Building the transmitter

To be able to simulate the rest of the keys, I used a PIC16F628 and a TSAL 7400 IR LED, with the information available here to build the transmitter circuit:

For the receiver to be able to pick up the transmitter signal, the transmitter needs to modulate the signal at around 38-40kHz. Since the receiver receives in active low, this means pulsing the output at 38-40kHz for around 0.5ms for a binary 0, and staying low for 1.6ms for binary 1.

But how do I actually pulse the output at the required frequency? Luckily the receiver is quite tolerant and any transmitted frequency within the the expected range will work. I used the assembly source code from here and modified it to suit my needs. NOP instructions are used to generate the required pulse frequency, as seen in the following code snippet:

IR_pulse                
        MOVWF    count        ;  Pulses the IR led at 38KHz
irloop        BSF    IR_PORT,    IR_Out
        NOP           
        NOP           
        NOP           
        NOP            
        NOP           
        NOP           
        NOP           
        BCF    IR_PORT,    IR_Out
        NOP           
        NOP           
        NOP           
        NOP           
        NOP           
        NOP               
        NOP           
        NOP               
        NOP           
        NOP           
        NOP
        NOP
        NOP           
        NOP           
        DECFSZ    count,F
        GOTO     irloop   
        RETLW    0

If you're not an assembly guru who knows exactly how many CPU cycles each instruction will take and is able to calculate the output frequency easily, you'll need an oscilloscope and lots of trial and error to get the desired output. This is when the Rigol DS1052E limited memory becomes a hassle. You will need to set the the TIME/DIV setting to a reasonable value that allows you to view the entire transmitted stream, but not at the expenses of losing too many sample points. Even at 1 mega samples of memory in long memory mode, signal aliasing may occur if the TIME/DIV is set so high that the oscilloscope can't capture enough samples. For example, the following puzzled me for a few minutes when I attempted to transmit 1 bit of data:

 

The code pulses the output at 38kHz, but from the oscilloscope screen, it seems much less. However there was nothing wrong with the code, all that was needed is to lower the TIME/DIV settings and capture the output again:

This is the transmitted signal:

Applying "invert" on the input channel on the Rigol oscilloscope, I got the transmitted signal to resemble the received signal:

The PIC-based transmitter now works properly and the TV responds to it as how it did for the universal remote controller.

Simulating other keys

By varying the data byte, I am able to simulate many other keys. The full list of keys and their data bytes can be found in the following table:

Key	Byte
1	10
2	9
3	8
4	18
5	17
6	16
7	14
8	13
9	12
0	22
Previous Channel	19
-/--	21
POWER	2
MUTE	4
MENU	3
Current Channel Display	24
Sound Mode	25
Picture Mode	26
Next Channel	29
Enter	28

With this, I am able to get my learning remote controller to learn the above keys and use it as the main remote controller for my TV.

The assembly source code can be downloaded here. It will repeatedly transmit the data stream for the "Channel 1" button. Unfortunately I could not find the data bytes for many other important keys, such as the volume control and TV/Video switch button. Perhaps these keys have data bytes outside the range I tried, or require a different protocol. I hope somebody with more time and expertise at PIC assembly programming can use my code and find out how to simulate these keys...

Reference:
1. Infrared TV Remote Decoder
2. PIC Tutorial Five - Infrared Communication

Read More »