Thursday, August 8, 2013

First thoughts on Philips Hue LightStrips

Bottom line, congratulations Philips! Great addition to the Hue LED lighting family.
 Philips hue
Apologies upfront for my initial paragraphs focus on unpacking and my inches rather than metric measures. 
First challenge is to figure out how to remove the unit from the box without destroying the box.
My box did not have any kind of tamper seal on the outer tab, so I could open the outer box without any sign.
Inner carrier slides out of the main box with out any problem.
Two tabs on the left side of the inner carrier allow you to open the top of the carrier like a book. But the lower tab is hot glued in place, just rub off the small glue bead.
Next I was able to slide the controler unit (a white box about the same size as the old Apple IR remote) out of the upper part of the inner carrier without damaging the packaging.
Then I was able to slide the round plastic carrier for the LED strip out of the inner carrier. Success, no damage to the packaging.
There are two paper documents in the package, a larger white 10 page (1/2 size of a sheet of standard letter paper) manual titled 'Philips LivingColors / LightStrips Safety Instructions - Part B' with a clearly visible text stating 'Last update: 05/06/13' (yo international company Philips is that May or June??) This document has at the top of the first page a set of 11 icons that I believe are used by Google or Apple as part of the interview process for new engineers and programmers. The second part of the document, if used in a job interview, would clearly show age discrimination, as it is set in a type font that cannot be larger than 4 point type. But good news about this manual, it is just safety instructions nothing to do with setup or operation of the LightStrips. And if you care, to the education value, it is written in 29 languages!
The second document, titled 'Friends of Hue Personal Wireless Lighting' is a small 2 inch by 2 inch square document, is the true 'getting started' document. Would be nice for them to say something like 'start here' on it. This document is another Google or Apple interview question, as it opens it's pages right to left and left to right. The correct answer (I think) is right to left. Lucky this manual (kind of) only has 12 languages, and they are all read left to right, which kind of corresponds to opening the document from the right. Anyway, as I said, this document is kind of multilingual, except the first six pages are all in English. Good news, the pages really don't tell you anything other than launch the Hue app on your mobile and click the button to add a new light to your system. The first really text page, that is duplicated in 12 languages, basically says cut your LightStrip to the length you want (but does not clearly show you the correct places to cut the strip, the strip itself kind of shows this), then stick it to the surface you want using the adhesive back, plug the strip into the power jack and then go back a couple pages in this manual to see how to add the strip to your system. Not a good job on instructions Philips.
 Hue lightstrips 01
The last two pages of the manual show you that you that you should not bend the strip where a LED is located and that the maximum recommended bend is 90 degrees. The last page gives you another chance to pass the Google or Apple job interview 'icon' test and then tells you to read the 'B' second manual on safety that I described above.
This is probably a good time to read the safety manual, because I just thought of something as I look at the strip of LED's. It is not clear to me that the voltage on the LED strip section is a safe voltage, rather than mains voltage. I am wondering what would happen if I plugged the unit into the wall socket and then decided to use by metal scissors to cut the end of the strip! At least it does look like the voltage is only 12 volts (I think DC) down from wall wart. Other than if you got at least the first two icons correct in the above mentioned safety test, the only place that it says that you should only use LightStrips in a dry indoor location is on the wall wart.
Bottom line, Philips could have done a much better job on the setup instructions by just taking advantage of the QR code they place on the front of the box. They should add a QR code reader in the HUE app and have a simple icon in the app that says 'Add New Light' and instructs you to scan the QR code. This would take you to a useful installation video on your mobile (as opposed to the marketing one that is currently displayed  on the 'Friends of Hue' page that the QR code and URL on the back of the small manual takes you to. Also Philips, make your web page recognize that you are coming from a mobile and format correctly. And make sure you grovel to Google YouTube so that your video plays on day one without stopping!)
The unit I purchase here in the USA is a USA socket device with a rating of 100-240 volts 50/60 Hz.
The LightStrips has 5 unique sections:
  1. The wall wart. The USA one that I purchased is a USA 2 prong ungrounded and unpolarized plug.
  2. A 38 inch 1/8 inch flexible round white cable that runs to the ZigBee control unit.
  3. The ZigBee wireless control unit, a white 3 1/4 inch by 1 1/4 inch by 1/2 inch box with the long sides rounded. As I said it is about  the size of the 1st generation Apple IR remote control that came with Macs. The unit has two 3M sticky tape points to attach it. The cables run in and out the small ends.
  4. A second section of 1/8 inch flexible round white cable that is 96 inches long (I will wait for my second unit to cut the cable and try and figure out how to extend). 
  5. The LED strip, the LED's are 1 9/16 inches  apart. The LED strip is 78 inches long. The transition from the 1/8 inch round cable to the flat LED strip is covered with a 1 1/2 inch piece of white heat shrink tube. There are 60 LED's on the strip. The cut points are every 4 inches.
The LED strip is similar to others I have seen in the current generation. It is 1/4 inch wide and 3/16 inch thick at its highest point. The strip is white with visible capacitors, LED's and cut points, along with the Philips name in off white every 4 inches. The back is a continuous strip of 3M double sided sticky tape.
When I first powered it on, all sixty LED's came on in an orange color.
I launched the Hue app on my iPhone and it found the LightStrips and named it 'LightStrips 1'. Clean and easy, I should have started here from the outside of the box!
The app continued to search for lights for about another 45 seconds and then gave me a 'Done' option. This screen is another example of where Philips could do a better job on the user experience. I do not think it would be very hard to put a 'count down timer or thermometer indicator' to tell you how much longer you have to wait for the search to complete.
The LightStrips added to my network without any problem and are working exactly like my other Hue bulbs. I will have to point you to others that are more qualified to talk about the light quality and color of the LightStrips. My initial two thoughts are as follows:
  1. The LightStrips do not seem to have as fine a level control as the Hue.
  2. The color of the LED's in the LightStrips do appear to be different and not as vibrant as the Hue bulb.
I think both of these assessments may be 'feelings' rather than any science differences in the LED's.
At USA $90, these are not going to be a main stream product for 85% of American consumers. That said, for those with a good application and the money, the Philips Hue LED system is the beacon to guide all of us to both better and more energy efficient light for all. The prices will fall, and I hope that Philips opens their technology enough to allow other quality lighting providers to work in a common system architecture. We do not need competing and different lighting control systems! The energy efficiency needs of the human race and planet need to be a higher priority than localized corporate profit. Consumers should be able to go out a buy a reasonably priced lighting device from quality providers that is 100% interoperable with all the other vendors. We do not have the luxury of time for the 'best socket' to slowly wind its way to market dominance, it is time for the big lighting corporations to get together and do the right thing together. Soap box off.
I was able to control the LightStrips with the same JSON and python code that I have been using with my original Hue bulbs. I admit I have not followed the API's closely since Philips published their official API documents, so perhaps their are more functions waiting to be exposed with these second family members of Hue.
The last set of LED strips I installed were about 5 years ago,  dinosaurs in the current scope of progress. Those were from Ikea of all places, I can say I have not saved enough energy to replace those with LightStrips as yet, but for folks that are a bit behind the 'beading' edge, Philips LightsStrips might be a great place and time to start in wireless LED lighting.
Bottom line, congratulations Philips! This is a useful and quality 2nd product in your wireless LED lighting direction. You are a leader and innovator! Keep it up. All my nit picks aside, okay one more 'Friends of Hue'????? WTF?????? I am not getting it. Don't let this EXCELLENT AND TIMELY FAMILY OF GREAT AND USEFUL TECHNOLOGY get tripped up by dumb marketing slogans, bad installation experiences, price and lack of interoperability. You have the Edison Socket by the 'horns', use this wonderful position you are in to lead the world to better light!
Hue lightstrips 02

Sunday, January 8, 2012

Initial look at the new Bluetooth wireless hardware and software, know as Bluetooth LE, 4.0 or Smart

The Apple iPhone 4S was the first hardware out the gate with support of this new wireless protocol. Now a few months later 3 or 4 Android phones are hitting the market with support as well.

A couple things make this technology really interesting for sending data at low to mid range data rates, say from 10 bytes per second up to a hundred thousand bytes per second.

It does look to have a few warts out the gate and there are other players in the market today and on the way. But my sense is they have put together enough of the right pieces, that in combination with the 'Bluetooth' name, market penetration and consumer understanding such that it will become the low power device connection standard.

The first benefit is that the sensor or 'end point' devices will consume very low power, battery life should range from multi-days to years and the power source need not be more that one AAA battery. Or even smaller, for example hearing aid batteries. And not to far out devices powered by solar and also using other energy harvesting methods.

The second benefit is that it is under the Bluetooth wireless family name. With Billions of phones and computers currently in the market with Bluetooth 2.x built-in, so many consumers know how Bluetooth is able to make a wireless headphone or data transfer connection today. This is a consumer adoption barrier reducer. Although Bluetooth Smart is really a combination of new wireless hardware and software that only shares some common data structures, high level API architectures and runs in the same frequency range as the current Bluetooth 2.x technology. To make it clear, a 'Bluetooth Smart' device will not communicate with ANY of the existing Bluetooth 2.x phones, devices or adapters in computers, cars or anything else prior to the iPhone 4S. More on these family incompatibilities in a bit.

Bluetooth sits in a 'distance between devices' area between 'under a foot' to 15 feet. This is a space that the current Bluetooth devices have done a very good job of providing 'cable-less', reliable and low cost connections. Bluetooth Smart improves that with lower cost and lower power while improving the connection setup speed and simplicity. There is and will be overlap with this technology and Wifi on the high speed and distance side and the new emerging NFC ( near field communication ) technology on the close in financial transaction side. However the strength of Bluetooth Smart will keep it in control of this zone around your phone and computer. And it is going to open up wireless communication by many other devices in this zone. Examples include household appliances, door locks, sensors, medical devices, fitness devices and many yet to be thought of applications.

Another huge benefit that Bluetooth Smart has, has nothing to do with technology, but rather that the benevolent technology dictator, Apple, [ or happy walled garden, if you prefer a positive spin on Apple's control ] has now opened Bluetooth Smart on the iPhone 4S and most likely all future iOS hardware to all hardware and software developers. Prior to iOS version 5 and the iPhone 4S only limited types of wireless data transfers in and out of iOS devices was allowed. Now a iPhone 4S can send and receive any type data from a custom iOS app with no restrictions placed on it by Apple [ although the app will still need to be 'approved' by Apple for sale in the App Store ]. So what does this mean? It means that a hardware developer can build one device that will communicate with Apple, Android and other phones and devices, as long as they have the Bluetooth Smart hardware and software support. Examples of this include health and fitness equipment [ I am wearing a Bluetooth Smart heart rate sensor as I write this ]; gaming devices, it will now be possible to write a app or game that will easily communicate between a iOS device and an Android device. There is no doubt that leading edge wireless connected devices [ The Internet of Things ] will often first appear in the Apple iPhone space, now these devices will be able to appear on the larger market [but often lower priced] Android market at the same time [ the availability of the app on the device is the only gate ].

All of these positives make me believe that Bluetooth Smart is going to be the standard going forward in this 'zone' and we are about to see a big wave of new wireless connections between things.

The roll out of devices with Bluetooth Smart is going to take a couple years, that is the turn over period of many 'smart phones' today based on carrier contract length and the technology price/pain obsolescence curve. The hardware development kits are starting to rollout and get on the radar screen of companies and developers with ideas. The first Bluetooth Smart devices have hit the market already, including the Wahoo heart rate belt I am trying. The ramp up of more of these devices will take about twelve to eighteen months, and getting the software bugs and battery life tuning will take about the same period. So the two year window [ starting from 4th Qtr 2011 ] of mass adoption seems about right.

To some of the challenges that the adoption faces......

First, there is the good/bad thing that is the name Bluetooth. Yes, many current phones have Bluetooth. However, they will not talk to devices with this newer Bluetooth Smart hardware. New phones that are rolling out, including the iPhone 4S have both the old and new Bluetooth radios and software built in. This will allow them to talk to both type devices. Devices that have this ability are given the Bluetooth marketing name 'Bluetooth Smart Ready'. Get the difference? The word 'Ready' at the end signifies that the device has the hardware and software to talk to Bluetooth 2.x and Bluetooth Smart devices. So, having devices around for a number of years to come that only take old Bluetooth 2.x is going to be one of the challenges to adopting this new Bluetooth Smart. I think the naming of the technologies is not very clear, though I am not sure I can think of a better set of names that would make it clear to the consumer market. Plan a lot of devices returns and tech support hours during this transition period. Here is a web page at the Bluetooth industry group that tries to explain the terms and technologies.

Another challenge is from the other wireless technologies either encroaching on this zone or directly compete with it. The biggest [and perhaps the only ] direct competitor is a wireless technology called ANT+. It has been used in the sports and fitness areas for the last 18 months. It is probably an equally good wireless technology as Bluetooth Smart, it just did not get traction in the other areas of use in this 'zone'; for example wireless audio, headphones speakers. Not getting adaption in this large use case has limited its adoption. A number of Android phones have ANT+ technology built into them today, probably millions of phones, but a vast majority of the phone owners have no idea it is there. Most of the ANT+ hardware vendors are moving to Bluetooth Smart, but this transition will be a small slow down. Mostly, I think, will be due to media sound bites playing up this 'dead end' for some users and their devices.

The other direct challenger in this area is the Zigbee/802.15.4 technology. They have been a long time player in this space, the longest I think and perhaps have the strongest technology. However, other than their new standards in the home remote controls and home energy market [ smart meters ] they have not been able to gain a foot hold in the consumer space. I do not think they will either, perhaps too bad. But perhaps one of the examples of the better technology not winning.

The 'encroachment' challenges may come from the WiFi hardware manufactures. They have been promising a WiFi radio that will cover the current WiFi use cases as well as the current Bluetooth ones. And do all of the same 'new' low power/low cost stuff as good or better [ their belief ] as Bluetooth Smart. But these radios have seemed to be 'right around the corner' for at least the last year. I think they will produce a hardware device that may meet all of these goals, but I think will be too late to market. Wifi will need to scale across a very large data transfer range, from gigabits to bits while doing this with compatibility [ at least in name like Bluetooth ] and power budget. I don't think WiFi will win, but I think we will see devices and this will add to the transition confusion of Bluetooth Smart. At the other end, I do not see the NFC/RFID technologies trying to move 'up' into the Bluetooth zone, the technology does not seem to support the data rates and power budgets that Bluetooth use cases need. There is talk that Bluetooth Smart will try to move down into the NFC zone, specifically for financial transaction applications. This battle is still to be fought, however NFC has a strong foot hold and seem to be getting support from the credit card companies. There are other battles going on around who owns this market, other than the encryption chip technology, I do not think this will be decided by wireless chip vendors.

Another thing that I think will cause some bumps in the Bluetooth Smart adoption is the current licensing and developer tools costs. While the cost of Bluetooth has been going down for the consumers, these price reductions have come due to more sales of phones and other devices not due the Bluetooth license and tools costs being reduced. As the open hardware trend is expanding, Bluetooth licensing remains proprietary. I think this closed development community will stifle innovative ideas for use of this ubiquitous connectivity of devices.

I have been experimenting with a Texas Instruments prototyping kit for Bluetooth Smart, it is based on their CC2540 chip family. I have several devices that I have wired up talking to a iPhone 4S and desktop computers using the Bluetooth Smart system. I do not have a Android device as yet with the Bluetooth Smart hardware. I've been following the developer forums at TI and a couple of other hardware manufactures that have Bluetooth Smart chip sets just now in the market. It is still a learning period of a lot of developers [ and hacks like myself ], but much progress is being made. At least by those that have deep enough pockets for the compilers and license fees.

Get ready for a MASSIVE explosion of The Internet of Things [ #IoT ] in the next couple of years, our phones, tablets, appliances and transportation devices are going to be connected to tens of other devices during the day and night.

TI CC2540 Development KitTI iOS CC2540 Demo

Sunday, December 18, 2011

Updating TI Beagleboard to 3.x Linux from Angstrom Embedded Distro

I've have one of these neat TI Beagleboard for a couple years, have not used it for a while. TI recently released a new hardware implementation of this family called the Beaglebone. This device looks to be more useable for hardware interfacing, so I picked up a couple to explore. At USD 90, the price of the Beaglebone shows the continued downward price curve of powerful embedded hardware.

I dusted off the older Beagleboard to do some comparisons with the newer Beaglebone hardware. So first off I decided to get the distro version as close as possible. Angstrom appears to be most used and updated distro for the family, but the Android folks look to be getting some steam up.

Here are my notes on getting the most current Angstrom distro running on the Beagleboard.

The one big gotcha that may trip up forever n00b's like me was the change of the TTY port naming conventions. The correct port name for the serial port on the Beagleboard is:


that is a capital OOOOOO as in Oscar not a zero!

After Linux kernel version 2.6.36 the naming convention appears to have moved from:




I'm sure there is a really good reason to slipstream this change in, but not only is it not clearly announced / documented around the various Linux and embedded internet resources [one of those "weed 'em out events perhaps?"] but using the capital 'O' character seems to be making for more opportunities for mistakes by confusing it with the number zero '0'.

The standard instructions to create a SD card with the two partitions containing the u-Boot and linux kernel on the first FAT partition and the remaining core Linux core OS files on the second [one of several types] Linux/Unix formatted partition is straight forward and does not vary from prior configs.

The main two changes to get the console output and the a serial terminal login prompt are as follows:

1) change the Linux bootargs console value to be:



my basic u-Boot environment variable 'bootargs' is as follows:

bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait

2) Before you put the SD card into the Beagleboard, or after via the X Window session that comes up by default, edit the inittab file in /etc and change the following line from:

S:2345:respawn:/sbin/getty 115200 ttyS2


S:2345:respawn:/sbin/getty 115200 ttyO2

this will give you a login prompt on the Beagleboard's serial port.

Results and experiences to date.

I am still testing the 3.x kernel on the Beagleboard, so far so good. The serial port might be exhibiting some slow down after a the machine is up for a while. I need to get more data on this. Unfortunately, most of my focus is on the new Beaglebone, so the '..board' is getting the 'old dog' treatment. The puppy is the center of attention.

I updated the two boot modules of the Beagleboard to what I believe is the most current version. You get these by putting the MLO and u-boot.bin files on the FAT boot partition when you download the latest build of Angstrom. There are couple of thinks to be aware of with these upgrades. The version of these files that are in the flash memory of the Beagleboard are the older version until you use the u-boot commands to re-flash them. The instructions to do this are straight forward and worked fine. The 'gotcha' here comes in that the commands in u-boot have changed considerable and the boot scripts are stored as environment variables in the flash. So your old boot scripts will work with with your old SD cards and when you boot these files from flash [by removing the SD card or holding down the 'user' button during power up]. However, when you boot with the newer u-boot, thinks quit working. And, unfortunately, it appears to be even worse than the new versions don't work the same as to older version. It appears that the documentation and perhaps some of the commands do not work as documented that you will find on the 'help' sites on the web. I have not got my arms around these 'additional' issue yet so take this with a grain of salt, but do watch carefully as commands run. One example of what I am talking about is the 'mmc' command family to work with the SD card. There is much discussion of a 'mmcinit' command, but I could not find that command anywhere. What I did find is that before reading from the SD card, it is a good idea to do a 'mmc reset' each time before loading a file or doing a directory of the mmc. Below is my before and simple v1 'after' environments:

-- before version of environment variables that booted a October 2009 Angstrom Linux --
OMAP3 # printenv

bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi
mmcargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
nandargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}

Environment size: 1056/131068 bytes

-- simple 'after' version that boots the Angstrom November 2011 3.x Linux --

OMAP3 # printenv
bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait
bootcmd=mmc rescan 0; fatload mmc 0 ${loadaddr} uImage; bootm ${bootaddr}

Environment size: 412/131068 bytes

Here is what is running on the Beagleboard now:

Linux beagleboard 3.0.8+ #1 Tue Nov 1 21:14:19 CET 2011 armv7l unknown

Some useful web sites:

Good basic setup instruction of the Beagleboard. Old so it does not address the problems I highlighted above, but still a good anchor to go back to:

Beagleboard web site:

Angstrom Linux for Beagleboard latest version. NOTE: go to the Amazon AWS mirror of this web site to get much faster download of files:


Pretty frustrating waste of time I had as a n00b here because the 'in the know' folks that are maintaining this stuff did not take five minutes to document some of the rather major changes. Glad I have it working! The Beagleboard and Beaglebone are great training ground for the amazing world of embedded connected inexpensive devices we are moving to.

Monday, May 30, 2011

Simple learning example for digital to analog on Arduino with MicroChip MC 4921

The Arduino hardware only provides PWM pseudo-DAC support. I had the need to create a simple set of signal wave forms, so I though I would try and accomplish it with the Arduino. I had a AdaFruit Wave Shield v1.1 sitting around, a neat device that does a number of things, but primarily focused on playing back audio files from it's attached SD card reader. I looked around for some code to create wave forms with its on board MicroChip MC 4921 12 bit DAC, but found nothing that was written directly for the Wave Shield. Several folks have posted info on using the MCP 4921 with the Arduino in projects, so I follow their leads and hacked up the code I needed. Below is a simple first step I used to learn to talk to the DAC chip, might give others a starting point. It also shows the basics for storing data in the program code memory of the ATMEL x28 processors. The sine table is far too big to fit in data memory on the Arduino.

Thanks to the folks cited in the comments below for their work.


// DAC-programming01
// 30-May-2011
// direct programming of Microchip MCP 4921 12 bit D to A on the AdaFruit WaveShield v1.1
// Dave Proffer
// demonstrates programming the MCP4921 to generate several different wave forms
// look like about 0.666 hertz or 1.5 seconds per cycle on Dumilanove with ATmega328 16 Mhz
// sine wave generated by :
// initial MCP 4921 code from: Prof. G. C. Hill at CSULB


#define DATAOUT 4 //MOSI
#define SPICLOCK 3 //sck
#define SLAVESELECT 2 //ss
#define LDAC 5

#define ledPin 13

word sensorValue;
word interval;
byte data = 0;

// this sine wave table, 1024 12 bit words is too big for the RAM of the Arduino, so we use the ATMEL rountes to store in in the much larger program non-vol mem
PROGMEM prog_uint16_t sineLookup[1024] =

void setup() {
// -------------------------------------------------------------
// default pins on Wave shield connected to DAC
pinMode(LDAC, OUTPUT);

// seems to put the DAC in known state, but zero worked too!
// sendIntValueSPI(1000);

// basically keep this line low for the DAC to output signal is what I read

// start serial interface

// this is the routine that clocks a word of data to the DAC using SPI type transfer logic
void sendIntValueSPI(int value) {
// -------------------------------------------------------------

// initiate data transfer with 4921

// send 4 bit header

// send data
for(int i=11;i>=0;i--){

// finish data transfer

// top of first byte of pair is commands for DAC
void sendSPIHeader() {
// -------------------------------------------------------------
// bit 15
// 0 write to DAC *
// 1 ignore command
// bit 14 Vref input buffer control
// 0 unbuffered *
// 1 buffered
// bit 13 Output Gain selection
// 0 2x
// 1 1x *
// bit 12 Output shutdown control bit
// 0 Shutdown the device
// 1 Active mode operation *

// basic clock of each bit with is routine
void sendSPIClock() {
// -------------------------------------------------------------

// some simple wave forms for testing

void loop() {
// -------------------------------------------------------------

// triangle wave
for (int i=0; i<25; i++)
for (int i=24; i>=0; i--)
// precision triangle wave
for (int i=0; i<=4095; i++)
for (int i=4095; i>=0; i--)

//sine wave lookup
for (int i=0; i< (sizeof(sineLookup)/sizeof(int)); i++)
// according to the doc, you cannot simply access data stored in the program mem like you would in data mem, so you must use the ATMEL functions to move data so you can use it.

unsigned int tabVal = pgm_read_word_near(sineLookup + i);
// Serial.print(i);
// Serial.print(", ");
// Serial.println(tabVal);

//square wave

interval = 0;
for (int i=0; i < 50; i++) sendIntValueSPI(interval);
interval = 4095;
for (int i=0; i < 50; i++) sendIntValueSPI(interval);

// for (interval=0; interval < 4096; interval++)
// {
// sendIntValueSPI(interval);

// }


Thursday, January 6, 2011

Dual monitor setup ideas, great price on a useful base monitor stand: Planar 997-5253 at

This week [1st week January 2011], has a pretty good deal on a desktop monitor stand that will get a dual monitor setup working for your desktop. Here is the link that is good for a least a week more. I paid thirty dollars more for the same unit at a while back, this is 'all in' with same shipping options and taking into account that charges CA sales tax where does not. I am amazed at the shipping efficiency that has, I ordered a 2nd one of these from yesterday with their cheapest shipping option, free, and it was delivered via Fedex Home Ground the next afternoon. Clearly your physical location relative to's logistics sites will make a difference, but wow!

I'm a big fan of portrait monitor orientation as you can see by the second picture below. What is nice about the Planar dual monitor stand is that is able to handle monitors up to 24 inches in either landscape, portrait or a combination. The ability for Windows, Linux and Mac OS X to handle multiple monitors and monitors turned 90 degrees [or 270 degrees] has greatly improved over the years. I still find Apple's OS X operating system to handle it the best 'out of the box'.  Much of their advantage is that they control both the hardware and video display drivers. In Windows and Linux you often have to deal with one or more third party video card drivers to get it working. That said, my configurations on Ubuntu Linux 10.02 work really well. I have been using nVidia cards for a while and they works solidly, but do expect to spend more time in the setup phase than you will on OS X.

The Planar 997-5253 stand is really easy to setup and is very stable on your desk. I'm using 21 inch monitors in portrait orientation and there is no way they will tip over. In the past, I've used stands that attached to the sides of desks or into drilled holes. While these are the ultimate in stability, they are more difficult to get a good ergonomic setup.

The price and selection of LCD monitors is wide open now, so you have to shop around for price point, size and display quality. The most important item for the dual monitor setup is to make sure the monitors you buy have the ability to remove their standard base and mount via the industry standard 'VESA 100 mm by 100 mm' or 'VESA 75 mm by 75 mm' third party mounting option. Be careful with some of the lower cost LCD monitors, as they do NOT have this option. Apple's LCD monitors do not have this option either, though people have hacked the Apple monitor mounts to make them work. So for a OS X dual monitor configuration; Mac Mini, Mac Book Pro, or Mac Pro I recommend using non-Apple monitors. You might wonder how you drive multiple monitors on a Mac Book Pro or Mac Mini, if you search, you will find a number of people that have made this work using various configurations of the internal video card and cables. For my configuration on a MacBook Pro, I went with a external USB video card device from . Their latest OS X drivers support display rotation, the video quality on the DisplayLink device that I have not as high a quality as the built in video card of the MacBook Pro, but has been fine for my old eyes and has been running solidly with no memory leaks or crashes. On the Linux machine, where I do most of my work, I use nVidia video cards that have dual monitor support build in. The Apple MacPro has similar video cards available. Having a powerful video card with dual DVI or HDMI monitor support is the ideal machine to run. But I can say that my MacBook Pro configuration, which is really a THREE monitor solution, since the display on the notebook works as well. It is solid and a good setup for email, coding and document review.






Tuesday, December 21, 2010

Another iPad problem, or rather a 'feature' -- the mute switch

I ran into another issue on the Apple iPad that is another interesting reflection on software and Man-Machine Interface issues that are becoming more and more prevalent and important in our lives.

It appeared that all of a sudden several of my video playback apps on my iPads quit playing audio. The video was streaming fine, but in total silence. Being a standard human user, I immediately and it turns out incorrectly jumped to the conclusion that the apps that were silent had some type of bug.

After taking a step back and turning my 'logic brain' back on, what I have found is that the apps that were silent are the ones working correctly. And the combination of my incorrect operation of a new function on the iPad and other apps incorrectly ignoring this function is the root cause of the 'silence' I was encountering.

With the new release of the iPad's iOS operating system, Apple changed the function of a small switch on the upper right side of the iPad. The switch is just above the volume up/down buttons. Prior to the 4.2.1 release of iOS, the switch locked the screen orientation, so that rotating the iPad did not cause the screen to change orientation. With the latest release of iOS, this orientation lock function was moved to a software button located in the 'task bar' of the iOS system and the function of the physical switch was change to a sound mute function. Moving the switch to the down position, mutes the sound output. Moving the switch up, un-mutes the iPad and allows the volume up and down buttons to change the sound level.

There has been considerable debate online about these changes in these user interface functions. Even to the extent that for jailbroken iPads, there is a way to put the functions back to their original definition. When I started to use the new functions, I found the new definitions to be more useful, but this one of the challenges that UI developers face, there is NOT one standard way that people are comfortable with.

And I believe that this 'multiple ways of doing things' challenge is what has lead, at least partially, to the problem that I encountered with the sound playback on the iPad.

What I have found, is that there a number of apps that are ignoring the mute switch position and generate sound output regardless of the position of this switch. Apps that are ignoring the mute switch, include Apple's own YouTube app and Netflix. I think the first problem is that there is a way outside the operating system to ignore the switches function. Especially in such a controlled hardware/software environment as the iPhone/iPad world, being able to 'repurpose' this hardware does seem to be a bug from Apple's perspective. Second, is that apps are either ignoring the mute switch on purpose or have failed in their updates to correctly adapt to this change in system level UI functionality.

So what I've found, is that thru my own poor 'ass-umptions' that the apps that were silent were the ones with the problem and due to the combo of apps ignoring the new function and Apple allowing this to occur I see another big occurrence of software causing a lot of consternation in the daily lives of people operating electronic devices. We face some big issues as software continues to rule!


iPad button problem, looks like a software issue

This issue I have recently encountered on one of my iPads supports the unfortunate fact that there is a lot of computer and electronic hardware that gets returned because the products seem to exhibit hardware problems. When in fact, there are either software bugs or 'software features' that make it appear that there are problems with the hardware, but the hardware is just fine.

I started to see the home button on the front of the iPad to quit responding. You would push it and nothing would happen, so you could not exit apps, bring up the task manager or any other function that required the button to respond to a push. The problem was very intermittent, sometimes it was completely non-functioning and other times worked fine. I tried cleaning the button area and removing the iPad from the Apple case, at first this seemed to improve the issue. But then it came back. The button does appear to be a mechanical button, unlike the capacitive buttons that many of the Android devices use.

I should note here that, sad but true, I own three iPads, and this unit was the only one showing the problem. This was reenforcing my belief that I had a hardware issue on just the one iPad.

I searched Google and found others with similar symptoms. A number of people were going to the Apple store and getting their iPads replace. I decided to make an appointment with the local Apple Genius Bar at the Santa Barbara store. I went in and the helpful technician was able to duplicate the problem with me there, though I sensed she remained skeptical. Her next step was to request that the iPad be totally reset, wiped and reinstalled as a new iPad. We did this in the store and I gave it another 'button pushing' spin, with the iPad cleared of all apps and data. I thought that I could reproduce the problem still, but it seemed to have significantly reduced. The technician at this point was willing to swap out my iPad for a replacement unit.  She was multitasking and helping another person at the same time, so I continued to test by button. After about 10 minutes, I told her that I felt the problem might have been fixed, and before swapping the hardware I wanted to reinstall my data and apps and test the unit further.

The Apple Guru continued to be very helpful and said that since we had done this first 'software' reset step, and the fact was logged in the Apple Support system for this iPad, I could come back and go directly to the hardware swap step.

Well, two weeks later, I  will report that I have NOT seen the problem again. It has been a real PIA to reinstall apps and data in the unit. The Apple Guru recommended NOT restoring the backup image to the iPad. I think this has been the right route to the solution, it does appear that something in the operating system or in one of the apps I installed was causing the button to misbehave. I had installed beta releases of the iOS operating system on this machine along the way to its current state with a production release of iOS 4.2.1 (8C148).

If the problem is due to a bug in one of the apps I have on the machine, or an interaction between two or more apps, I may not have yet hit this ignition point. And there is still a small possibility that the problem is mechanical hardware related and has just gone into hiding.

However, as I said at the beginning of this post, I feel strongly that my experience and what I read in the press support the fact that there is a huge number of electronic returns that are working just fine from a hardware perspective. Electronic hardware today is amazingly robust!  But us humans are extremely fickle and quick to point the finger at incorrect sources of problems. This combined with the unfortunate fact that it is often simpler, quicker and less expensive to use a 'swap' rather than diagnose and fix route to the solution is a sad truth that poor software is causing.