Archive for the 'Software' Category

Philips Hue: Almost the Perfect Lighting Solution

Saturday, October 12th, 2013

Update (3/28/14): Today, Philips announced the “Tap” switch for the Hue..

While it is very very cool technology (battery-less, wireless, scene direction for the Hue), it still doesn’t solve the very basic problem of integrate the Hue with the dead, simple, stupid, 100 year old this switch controls that light model of lighting control in use in just about every household that exists.

While you could hardwire the existing light switch to be always on and then use the Tap to control various lights, it would be aesthetically unpleasing and not nearly as convenient.

Until there exists a Tap-like device that is the same form factor and provides the same dead, simple, stupid “flip this to turn on/off that” mode of operation, the Hue — and every other pending solution like it — will not be a true home lighting solution.

Worse, it won’t achieve the promise. Right now, I have two if-this-then-that recipes that control the lights in our bedroom to wake us up and tell us about the pending day. One light will glow yellow or blue to indicate sun or rain. The other light glows from blue to orange to yellow to red (which, btw, was a pain in the butt to set up in IFTTT) depending on the high temperature for the day.

And we never see these programs run. Why? Because the last thing we do before going to bed is hit the light switch on the wall, cutting power to the Hues entirely. As does pretty much everyone.


Nearly a year ago, I upgraded all of the standard incandescent lights in the house to Philips Hue. The Hue is an LED lamp that gives off a decent amount of light — 60 watt incandescent range.

The Hue can also be remotely controlled via ZigBee. The Hue starter pack comes with a hub and 3 lamps. The hub has an ethernet port (no Wifi) and communicates with the Hue lamps throughout the house wirelessly.

It works really well. Better yet, there is a full API for controlling the Hue lamps and, as a result, there are a couple of dozen apps for controlling the Hue for both iOS devices and OS X. As well, the fabulous if-this-then-that site can control the Hue lamps based on various inputs. Want to have the Hue in the living to glow red on a warm day and blue on a cold day? No problem. What the Hue in your office to glow red when $AAPL is down and green when it is up? Easy peasy.

Yet, unfortunately, I can’t really recommend the Hue as anything beyond a novelty. Not because of any flaw in the Hue itself as it is a fantastic product, but because of what is lacking.

The critical missing piece is Hue compatible light switch. For example, when I walk into the bedroom at night, I hit one or both of the wall switches at the door, and I expect there to be light. Similarly, when I flip the switch off, the lights should go off. Now, unfortunately, this — as expected — kills all power to the Hue. No amount of remote control is going to light a lamp that isn’t plugged in!

One possible solution is to use something like the WeMo switch. It can be integrated with if-this-then-that to turn on/off a Hue or set of Hues when the switch is toggled. Beyond being expensive ($50/switch), there is a 7 to 10 second lag between the switch being activated and the light state changing. That assumes, of course, that the myriad of moving virtual parts between the light switch and the light are all up and running.

Way too Rube Goldberg to be acceptable.

Another possibility would be to configure a web server on a computer to receive the WeMo input, then fire a command off against the Hue hub. This would, at least, confine the Complex Machine to our house, but I’m really not interested in adding yet another server that needs administration to my life.


Kickstarter Opportunity!

To complete the Hue as a home lighting solution, there needs to be a light switch optimized to the Hue hub itself. Ideally, it would communicate over Zigbee to talk directly to the hub, reducing the switch-light hop count to 1. The switch would leave the Hue always powered. While it could be automatically configurable, that really isn’t necessary. The Hue management app could easily provide a list of switches and lights. Toggle the switch and it highlights. Select which lights should be controlled by the switch and you’re all set.

Alternatively, there is definitely a Kickstarter opportunity here and no one has come close (there have been a couple of “TCP/IP switches” on KS, but they all go for the kitchen sink of features). The key is dead simple; the switch could be as simple as on/off. Even basic dimming isn’t really necessary. Just an on/off toggle that doesn’t power off the device it is connected to, but sends a command to the Hue Hub over Wifi (because Philips has not opened ZigBee interface). Only need a 2-way switch because 3-way could be done entirely in software and could be implemented as n-way. The switch could be Hue compatible primarily, but that pretty much implies that it is a TCP/IP switch. Configuration is an obvious challenge; a bit of a chicken and egg situation there. Unless something like WPS (Wireless Protected Setup) could be used to automatically configure the switch, then I suppose it would have to have a USB port or something.

In any case, keep it simple. Go for maximal cost reduction while still producing an attractive product. I’d back it in a heartbeat, as I expect would many Hue owners.

OS X Client Software for Owon SDS7102 Digital Storage Oscilloscope

Monday, April 15th, 2013

Ever since using my first Oscilloscope in the ’80s, I’ve wanted one. Though I’m a software person by trade, my hobbies have long included electronics in many forms. Heck, I’ll take a well tuned, clean, pinball game over a video game any day (and if it isn’t well tuned and clean, I’ll do that, too). An oscilloscope has long been the ultra-expensive super tool that my hobbyist pursuits just couldn’t justify the expense.

Not any more.

Recently, I picked up a cheap treadmill to turn into a “walking desk”. It works fine, save for the annoyance that it turns off ever 30 minutes and the control box is this big, ugly, clunky thing that clearly is a whole lot dumber than the LED display indicates. In adding some extra length to the control box’s cable, I noted there were only three wires; power, ground, and a signal wire.

Clearly, given price point and lack of real communication between control box and treadmill, the “protocol” between the two is likely nothing more than a PWM signal.

Which, given that the treadmill (Confidence Treadmill) is for my health, health is vital, and the best way to explore that signal deeper, I investigated picking up an oscilloscope for the first time in 15 years.

Boy howdy. What a difference those 15 years made! I was used to seeing depressing 4 digit numbers on scopes that were somewhat slow, very bulky and had little to no means of exporting data save for snapping a picture. Now? Less than $500 gets you a multi-input ‘scope capable of handling up to 100MHz signals with lots of analysis features and the ability to dump it all to USB or, in some cases, the network.

A bit of research revealed that the Rigol DS1102E is the most popular of the sort of entry level digital scopes.

However, the Owon scope pictured at left was only $50 more, has a much larger screen, and a LAN port. Rigol’s ds2072 is similar, but nearly $400 more and is backordered pretty much everywhere. While the Owon has had some negative reviews, the latest version seems to have addressed almost all of the criticisms. That, combined with the realization that I’m not exactly going to be pushing it (and a bit of a desire for immediate gratification) and I went with the Owon.

Couldn’t be happier. The Owon SDS7102 seems to work just fine; more than enough for my needs. The user interface is pretty mediocre, but passable.

I’ll let people far more competent than me properly review the scope.


Read the rest of this entry »

Ratchet & Clank Infinite Bolt Hack (and Much Much More)

Saturday, December 29th, 2012

The whole Ratchet & Clank series of games is just fantastic (save for the last one or two that kinda lost the plot). This year, the first 3 games were remastered for the PS3; 1080p and a bunch of new content. If you like 3D platformers and haven’t played R&C, I highly encourage you to do so.

R&C features a whole slew of upgradeable weapons. You collect bolts — the in-game currency — and use those to buy new weapons (and ammo). There is one incredibly powerful black market weapon available called the R.Y.N.O. (the “Rip Ya A New One” gun). Priced at 150,000 bolts, it would take many, many hours of repetitive game play to harvest enough bolts (until you beat the final boss once and start over in challenge mode where bolt collection is 2x to 3x faster).

Photo
Photo 1

There aren’t any cheat codes that’ll get bolts any faster, but there are bugs that can be exploited. Specifically, you can exploit a flaw in the geometry engine to go through a wall, fly through a roof and then fly to a race track where the game engine rules are tuned to you being on a hoverboard. In particular, you can use “the taunter” to break boxes of bolts in a way that the boxes keep breaking for as long as you hold down the “taunt” button.

It takes about 3 or 4 hours of taunting boxes to generate the 150,000 bolts to grab the R.Y.N.O.

Now, of course, this hack — “cheat” implies a Konami-Kode, this is much more of an exploit than a purposeful feature — is well documented online. This is a pretty typical example video.

It, however, is the hard way. A much easier way to do this is to go to the room containing the two health globes (screenshot(s) forthcoming) that said video shows you flying to. Once in the room, stand in the corner behind the globes and knock yourself through the wall using the decoys. Once through the wall, walk to the left along the narrow ledge until you are between the building and a really tall wall that goes over the race track. Wall jump up to the top of the building and fly to the race track as the video shows.

Much, much easier than the video for several reasons. First, going through a right-angle corner is a lot easier than that nuttiness in the raceway plaza. Secondly, no need to fly nearly blind from way up high through the roof of the building.

Of course, the hacker in me immediately asked “Why does this happen and can we exploit this further?”

Turns out that the answer is a resounding yes. It is really easy to find flaws in the game geometry that can be exploited. Look for sharp corners and aim your decoy gun (or any gun with a target) into them. If the gun’s target jumps between planes rapidly — better yet, if there are places where it will steadily oscillate between two planes — you can almost assuredly use the Decoy trick to knock yourself through that spot into whatever is beyond.

The glitches that result can be pretty mind bending. I have yet to see the game crash, but “divide-by-zero” would be an apt description of some of the results.

I’ve now used this in a few places in the game to complete a mission without doing any of the intervening bits or to get into a secret room without bothering to find the oft-well-hidden entrance.

Roger & I now have quite a few worlds to explore!



Xcode: Sometimes a return is not a return (emacs brain damage)

Sunday, December 23rd, 2012
ExpectedExpression
Indention and Insertion Prefs

Every now and then, I’ll be coding along merrily in Xcode and I’ll get an error much like the one at left. Or “expected identifier or ‘(‘” is another variant.

Huh? That code is fine. Maybe it is an invisible character? Nope. Nothing shown.

Took a bit, but I figured out the cause; 25 years of using emacs as my command line editor of choice, along with the folks at NeXT that implemented the AppKit’s text editor.

In emacs, you quite commonly navigate about by holding down the ctrl- key and banging on various keys to go to the beginning/end of lines, etc. Many of these control sequences are honored by Cocoa’s text editing system and quite a few more are supported in Xcode’s editor.

Seemingly unrelated, ctrl-return is mapped to Insert Line Break.

Thus, if you are an emacs head and you commonly hit ctrl-e<return> to start a new line of code and you happen to hold down the return key just a tad too long, it causes the error shown (or a variant depending on where the insert happens).

The easiest way to tell if this is the case is to go to the line of code after the line reporting the error and hit ctrl-a. If the cursor ends up at the beginning of the previous line, that line is ended by a line break and not a true newline. (ctrl-n – backspace – return to quickly fix).

While it is easy enough to fix once you know the ctrl-a trick, a better fix is one that makes it such that it’ll never happen again.

To do that, go to Xcode’s Key Bindings Preferences, click on “Text”, and scroll down to Insertions and Indetions. On Insert Line Break, delete the ctrl-return (hat + u-turn arrow) key sequence. For convenience add the same to Insert Newline.

Problem solved.

Arduino on Mountain Lion

Tuesday, August 21st, 2012

In my “spare” time (hah!), I hack on Arduino a bit. Mostly because there are tons and tons of 3rd party libraries that make hacking up a hardware solution mostly a bit of soldering followed by gluing together some pre-made software bits. The Arduino IDE is Java based and… well… not terribly awesome (to be fair — it isn’t awful, just quite lacking beyond the basics).

With the release of Mountain Lion, most Arduino installations were broken. Fortunately, this can be fixed by grabbing the latest bits from here and there.

  • Grab the latest Arduino.app for Mac OS X
  • Run it and it’ll insist on installing the latest Java VM. Do so.
  • If you use Teensyduino, grab the latest installer and install it. If Mac OS X (rightly) complains that the software is from an unidentified source and can’t be opened, you can ctrl-click on the installer, select “open” and it will present the option to bypass the security check. Do so, but not without a bit of misgivings.
  • Install the latest FTDI driver.
  • If all went well, you should see the device show up in /dev/ as something like /dev/tty.usbmodem12341.

    3D Printing: Oh, The Tuning We Shall Do.

    Sunday, March 25th, 2012

    After a while with the Ultimaker, a series of notes on the various things one can do to tune the 3D printing experience.

    Some of this is specific to the Ultimaker, but most of it is not. Much of this is personal preference and, frankly, there is probably some stuff in here that is wildly sub-optimal. But, hey, it has worked for me and it worked better than it did when I started.

    I.e. feedback and corrections are quite welcome!

    First, a note on consumables. I have stuck with PLA (polylactic acid) exclusively. It is a plant derived material that requires a lower temperature and is quite thoroughly non-toxic (there are lots of articles about fume-venting ABS… not so with PLA). As well, when I screw up — which is often — the resulting garbage is biodegradable (however, I’m donating my “pile of PLA” to someone who needs input into a PLA scrap-to-usable-filament project).

    PLA also doesn’t require — though it can benefit from — a heated print bed. ABS, the other common material, seemingly really does (though one can live without).

    Thus, these tips are optimized to PLA.

    These tips are also somewhat ordered in the steps that they should be done to maximize benefit. In some cases, that is because the earlier steps have a bigger ROI than later ones. In others, it is simply that the later steps really require the earlier steps first. Read the rest of this entry »

    Teensy Based IR Blaster

    Saturday, March 17th, 2012

    Evolution of a Design

    photo

    When I started this, as can be seen in the image at left, the case was two parts that fit together in a semi-complex manner (Actually, the very first version just had a little plastic square that covered the AVR, but nothing else). It was hard to print with any quality and, frankly, the front looked awful. So I simplified it such that the IR LED could stick out a small hole, as seen in the middle. But then it dawned on my that the translucent plastics might just be transparent enough to IR that no hole was needed at all.

    And sure enough, it just worked!

    Thus, the design is now even simpler (assuming you have translucent filament).



    photo

    Both professionally and as a couch surfer, I’ve found myself interacting with a great deal of devices that can be controlled via infrared remotes. Often, remotes lost in the depths of a couch or misplaced in the fridge (it happens). Clearly, I needed an IR blaster that could be controlled from a computer to both eliminate the “losing the remote” problem and to integrate control of multiple devices into a single UI. Conveniently, Arduino micro-controllers with integrated USB ports are commonly available and quite cheap. Adding an IR LED to an Arduino is trivial, as the ever popular TV-B-Gone project demonstrates.

    Thus, the Teensy IR Blaster was born. I started with the Teensy v2.0 AVR-based micro controller that includes USB support. It unofficially supports Arduino using the Teensyduino extension. To this, I added Ken Shirriff’s IRremote library modified fro the Teensyduino environment and Read the rest of this entry »

    3D Printing: Upgrading Firmware & Printer Driver (For Ultimaker & More)

    Sunday, February 12th, 2012

    Out of the box, the Ultimaker shipped with a stable, but relatively ancient, version of the firmware. This, combined with the stable, but relatively ancient, version of ReplicatorG available from the Ultimaker site was sure to produce useful prints with a relatively minimal of fuss, but nothing that remotely approaches either the blazing speed or amazing quality possible from this printer.

    To achieve that requires some significant upgrades to the software stack. And, in some cases, it requires outright replacing some of the pieces entirely.

    While this writeup is specific to the Ultimaker, there is a lot of general knowledge in here, and the various bits of software are largely universal to a number of printers. When my Printrbot shows up, I’ll write a revised version specific to that printer while generalizing this a bit.

    Note that this is all moving very quickly. When I first wrote this, it required about 3x more steps and was considerably more fragile. It is improving rapidly! However, there is still a long way to go before any of this is easy.

    Note: At the time of writing, you need to perform both of these upgrades simultaneously. ReplicatorG really does’ want to talk to the new firmware (of course, by the time I write this, it’ll likely be fixed). Read the rest of this entry »

    retainCount is useless.

    Sunday, December 18th, 2011

    The retainCount method just isn’t very useful as has been indicated in the answers to about a zillion StackOverflow questions.

    The documentation has this to say:

    Important: This method is typically of no value in debugging memory management issues. Because any number of framework objects may have retained an object in order to hold references to it, while at the same time autorelease pools may be holding any number of deferred releases on an object, it is very unlikely that you can get useful information from this method.

    Makes it pretty clear that you shouldn’t be calling retainCount, but it really doesn’t illuminate exactly how useless the method is outside of a very narrow context.

    So, let us count the ways:

    1. The absolute retain count of an object may change at any time once an object has been passed through any system API.
    2. Any subclass of any system provided class counts as “through system API”; the retain count may be impacted by implementation details.
    3. The retain count never reflects whether an object is autoreleased.
    4. Autorelease is a per-thread concept whereas retain counts are global; race condition derived hilarity can easily ensue.
    5. The retainCount method can never return 0.
    6. Some classes are implemented as singletons some of the time.
    7. Some classes may internally manipulate their retain count directly (I.e. no swizzle for you!).
    8. While retain/release are effectively thread safe, there is always a race between calling retainCount and having the actual retain count change in some other execution context.

    Bottom line: the only time the absolute retainCount can be conclusively used for analytic purposes is if you have the backtrace of every retain and release that contributed to the current retain count’s value (there is another use case, documented at the end). If you have that, then you don’t need the retain count and, fortunately, Instruments is already generally quite adept at producing a per-object inventory of retains and releases for you (see Analyzing Data with the Allocations Instrument“.

    In general, you should consider the retain count as a delta. Your code causes the retain count to increase and decrease. You don’t +alloc an object with a retain count of 1. Instead, you +alloc an object with a retain count of +1. If you want that object to go away, you need to do something — release, always and eventually — that causes the retain count to be decremented by 1.

    It really is that simple.

    Almost.

    Concurrency — whether through threading or GCD — throws a bit of a wrench in the works (as it always does). Namely, the retain count should really be considered as a per concurrency context delta. If thread or queue A wants to do something with object X, it should hold a +1 retainCount on X for the duration of said operation. One subtle detail that will bear repeating later; an autorelease‘d object does not contribute to thread safety. That is, if thread or queue A wants to pass X to thread or queue B, there must be an explicit retain in A that is balanced by a release (or synchronization event back to A) in B.

    Now, some of the enumerated claims may either seem specious at best or, certainly, not obvious as to exactly how it undermines the validity of the retain count. Read the rest of this entry »

    iOS 4.3: imp_implementationWithBlock()

    Thursday, March 17th, 2011

    In iOS 4.3, there are 3 rather low level functions in the runtime that provide a new kind of bridge between Objective-C and Blocks with a specific goal of facilitating the dynamic generation of method implementations.

    Specifically:

    IMP imp_implementationWithBlock(void *block);
    void *imp_getBlock(IMP anImp);
    BOOL imp_removeBlock(IMP anImp);
    

    In particular, imp_implementationWithBlock() takes a block as a parameter, copies it to the heap, and returns a trampoline that allows the block to be used as the implementation — the IMP — of a method in any Objective-C class (as long as the block’s arguments and the method’s arguments are compatible).

    Quite literally, this allows:

    int j = 12;
    IMP skewIMP = imp_implementationWithBlock(^(id _s, int k) { return k*j; });
    

    Where skewIMP would then contain a function pointer that could be used as the IMP for a method declared like:

    - (int)skew:(int)k;
    

    Details on the flip side…. Read the rest of this entry »