The Ultimate Remote Control and Why I Built It

Posted on January 20, 2016 by cy

I’ve just completed building a new piece of adaptive technology that includes infrared TV remote, infrared mouse control, and Bluetooth switch control of my iPhone. It’s the combination of a project that has been in development nearly 3 years. Here’s the story of the solutions I had before I built this remote, why they no longer serve me, and how the new device solves a variety of problems. It all started with a simple wooden stick…

The History of the Stick

In many of my previous blog posts I’ve discussed how I built custom TV/cable remote controls so that I can watch TV and use my laptop computer in bed. However I’ve not discussed how I use these devices when I’m not in bed. That process has recently had to evolve significantly so I thought I would chronicle the history of my use of remote controls while sitting in my wheelchair.

Of course when I had good use of my hands, I would just pick up a remote and push the buttons like anyone else. But at some point, I don’t recall when years ago, my dad built a little aluminum bracket that mounts on the front of my wheelchair control box. We attach a regular universal learning remote to the bracket with some Velcro. I would then push the buttons using a stick in my mouth. That particular stick system has gone through evolutions of its own.

Johnny Carson used to have a comedy routine called “Dickie the stick”. It was a commercial for a toy that had 1000 uses. In fact it was just a wooden broom handle. He would say with a little imagination you could make it into anything. He would throw it across the stage and say “look it’s an airplane”. His pitch man character made it sound like it was the greatest toy ever made but it was just a stick. Actually that commercial wasn’t far off for me. For almost my whole life I’ve carried around a tool that was nothing more than a big long stick. I used it to push elevator buttons, open doors, and grab things that I couldn’t reach. Someday I’ll do a blog just about my big stick. But for this particular blog will just talk about the small wooden stick that I used for typing and pushing buttons. This particular stick has been a wonderful piece of adaptive equipment for me. As you will see it’s been a big challenge to deal with the fact that I can no longer use it (oops… that was a spoiler).

Over the years my disability has progressed. I used to have pretty good use of my hands so I could type on the computer, handle books and papers, even feed myself. I lost most of that in my early twenties. When I could no longer type on a keyboard using my hands I discovered an alternative way to type. I would prop up the computer keyboard on an easel so that the keys were facing me. I used a very long pencil or dowel rod in my right hand, put my elbow up on the armrest or control box, and I would poke at the keys. In the early days of 8-bit computers I would wire in in a couple of extra pushbuttons on the end of a long wire connected to the Shift and Control keys. I would hold those buttons in my left hand. By the time we got to MS-DOS and later Windows they had a built-in feature called “sticky keys”. Many people think that’s what you get from watching too much Internet porn but this is something different. It is a software driver that turns your Shift, Control and Alt keys into toggle keys. For example you push shift and the next key that you type will be shifted. If you push shift twice it holds the shift key down. Everything remains shifted until you hit it again to unlock it. Here is an old photo of me typing on the keyboard this way.

Me checking my stock portfolio using stick and keyboard on easel. Circa 2000

Me checking my stock portfolio using stick it keyboard on easel. Circa 2000

The photo shows a keyboard that was very near and dear to me. It was made by Gateway Computers and was called the “Gateway Any-Key 124 keyboard”. It had 2 sets of function keys, the traditional ones across the top and an identical set down the left side. It also had a special built in hardware keyboard remapping function. You could reprogram any of the 124 keys to send any remapped keypress that you wanted. It also would allow you to create macros so that one keypress would generate a string of multiple keystrokes. Because it was difficult for me to reach the arrow keys way off to the right side of the keyboard, I reprogrammed the top row of function keys into arrow keys. If I needed a function key I would use the ones down the left side of the keyboard.

You will also notice in the photo just above the keys is a mini trackball. It was the only way that I could operate the mouse. That particular model was small enough that it was handy to just mount on the keyboard with some Velcro. I could poke at it with my stick to operate it. The great thing about that particular model was that it included not only a right-click and a left-click button but it included a drag button. It was sort of like “sticky keys” for mouse buttons. You would toggle it off and on if you needed to drag. It would not right-click drag but you rarely have to do that. The problem with that particular trackball was it would wear out eventually. In the end I ended up buying three or four of them at once for about $50 each and keeping them in my closet just in case. The original Gateway keyboard had a 9 pin D serial connector. I was able to later purchase them with a round PS/2 style serial connector but they never did make one with USB. Fortunately I found some serial to USB adapter devices and was able to continue to do use this keyboard many years beyond its normal life expectancy.

When using a laptop, sometimes I was able to prop up the entire laptop on an easel so that the keys were facing me. I had to be careful when purchasing a new laptop because some of them do not allow the display to open a full 180°. Had I tried to prop up one of those, the display would’ve been facing the floor not to mention how difficult it would be to keep it on the easel. Even when I did put it up on the easel, it was very precarious. Eventually I started using the special Gateway keyboard on the laptop as well by just plugging it into the serial port or USB port with adapter later on. Because the keyboard had been discontinued and I was worried it might break, I even stocked up on those by purchasing a spare on eBay. I see here that they are still being sold on eBay. I still have a couple of them in the closet today. Maybe I should get rid of the old keyboards and make some money.

Vintage Gateway 2000 programmable 124 key keyboard available on eBay.

Enter the Dragon

At some point I supplemented all of this by using speech recognition software. I began using Dragon NaturallySpeaking when it was at version 7. I don’t remember what year that was. The current version is 14. Typically I would use my stick for most of what I did but if I had something long to type like a long email or a blog entry I would use the dictation. I didn’t realize that over a period of a couple of years I began using the Dragon more and more and would use the stick less. I recall one weekend we went to the cabin at Cordry Lake and although I had packed my laptop and extra keyboard, I had forgotten to pack the easel to stand up keyboard. So I had to just use Dragon alone the entire weekend. I was surprised to realize I didn’t really miss using the keyboard and trackball. It was soon after that that I resigned himself to using speech recognition exclusively.

Initially the stick in my hand was only used for typing. When I wasn’t at the computer typing on something, I would let go of the stick and leave it somewhere by the computer. Then one day back in the late 1980s as I was driving my wheelchair into my office, my hand slipped off of the joystick of the wheelchair and I crashed into a bookcase. Over the days that followed I begin to discover my arm had weakened to the point where I could no longer keep it steady on the joystick. After a little experimenting, I came up with a system where I would put the stick in my mouth. I would also hold that in my hand and the joystick as well. The mouth stick would steady my hand on the joystick of the wheelchair. Here is my typical driving position.

My typical driving position using the stick in my mouth to steady my hand on the wheelchair joystick. June 2015.

Can’t Touch This

Eventually I expanded my remote bracket on the wheelchair to make room for an iPod touch. If you’re not familiar with it, the iPod touch is sort of like an iPhone without the phone part. It plays music, video, games, and does Wi-Fi Internet access. I started out with the iPod touch model 1 shortly after it came out. The problem was the stick that I was using was a wooden dowel rod with a glob of silicone rubber on the tip so that it would not slip. Even if I turn the stick around and use the wood end, the iPod uses a capacitive touch system. The wooden stick would not activate it. I needed something metallic. After much experimenting I discovered that the metallic piece had to be a reasonable diameter rather than a sharp point. For example we tried just touching a key or a metal knitting needle but that didn’t work. It had to be flat and make flat contact with the screen. That was a problem because as you reach to the top or the bottom of the screen, the stick makes contact at a different angle. So we had to come up with something flexible.

We finally came up with a piece of foam rubber with a hole in it so that you could put the stick into it. On the front of it we glued a small flat piece of metal. I would’ve thought that would be sufficient but it still wasn’t enough electrical capacitance. We attached a very thin ground wire to the metal tip and it worked fine. Having a wire attached to it also had other positive effects. For one if I dropped it, it didn’t go anywhere because it was tethered to the bracket. Also I can hold on to the wire in my right hand to steady the stick as I drag across the touch screen. Here is a photo of me using the stick to operate an android phone that later replaced the iPod touch. If you look closely you can see the thin red ground wire that I’m holding my hand.

Operating a smartphone and TV remote using a stick in my mouth.

We built a little receptacle on the side of the mounting bracket to hold the tip when I wasn’t using it as seen in this photo.

Small receptacle on the side of the mounting bracket holds the foam rubber tip when not in use.

Years ago I had upgraded the iPod touch version 1 to a version 4 but eventually it became obsolete. It would not run the latest version of iOS. Although there was an iPod version 5, the iPhone was already up to version 6 and I knew the minute I bought an iPod version 5 they would come out with 6. I waited and waited for various Apple product announcements. All of the rumor websites kept predicting that an iPod 6 was coming soon but it still hasn’t. A Google search on the phrase “android alternative to iPod touch” led to several articles suggested purchasing a cheap unlocked android phone. If you did not activate it, you could still use it for apps, Wi-Fi, games, music video etc. So that’s when I did. The image above shows the Motorola Moto G second-generation that I purchased. It is unlocked GSM phone which runs the latest version of android. It only cost about $180 and was a really good deal. I wasn’t sure I really needed a phone but once I was to the point where I couldn’t drive my wheelchair anymore, I could not drive up to get to the land line speakerphone that I usually use. I ended up activating it after all. I got a really cheap pay-as-you-go plan from ting.com that is costing me $12-$15 per month.

One of the problems with the android phone is it is larger than the old iPod touch. That means that as I reach from the top to the bottom of the screen, the angle of the stick varies more. It was more difficult to get a little flat metal tip to keep in contact with the surface. I came up with an interesting adaptation to solve that problem. We took a small piece of conductive foam such as used to protect IC chips from static electricity. We cut it in a little rounded hemispherical shape and glued it on to the little metal plate on the end of the stick. So no matter what angle I used, there was still sufficient surface touching the screen. Here is a photo comparing the size of the new android phone on the left and the iPod touch 4 on the right.

My comparatively tiny iPod touch 4 next to my newer Moto G android phone.

Here is a close-up showing the flat tip on the right that I used for the iPod and the one on the left is the new rounded tip use for the android phone.

That whole system worked really well for several years. It got me through hundreds of levels of Angry Birds and above level 1000 on Candy Crush as well as allowed me to look up countless facts on IMDb, post to Facebook, and check the weather radar anytime I felt like it.

I.R. An Expert

The stick isn’t the only piece of adaptive technology relevant to the story. A lot of what I do is assisted by infrared remote control such as the ones used by TV, cable, DVD etc. It was about three years ago that I got back into tinkering with electronics when I purchased my first Arduino microcontroller. I became interested in infrared remote controls and that led to the building of the TV/cable remote that I use in bed. The whole journey was documented elsewhere in this blog. I came up with another use for the Arduino when they introduced the Arduino Leonardo model. It is capable of emulating a mouse or keyboard when plugged into the USB port on the computer. So I built a little box that would pick up signals from my TV remote and it would create mouse movements as well as some keystrokes most specifically the arrow keys. I could switch back and forth between mouse mode and keyboard mode. Because I don’t have a cable box in my office, I use various codes from the cable box to control this device. However when I built another one for my laptop that I often use in the bedroom, I had to pick a different set of codes for that one so that it didn’t change channels. The one for the laptop used code from my Blu-ray player. I never use the laptop in the living room while watching Blu-ray so that was okay.

While Dragon dictation software does have mouse controls, they are not very flexible. For example you cannot use the mouse scroll wheel, it is difficult to shift drag and you cannot right-click drag at all. But pushing the TV remote with my stick, I can do all of that and more with the Arduino Leonardo and an IR receiver.

My infrared remotes are based on a library of code written by a guy named Ken Shirriff which I later rewrote to make a little more flexible. I published the code on GitHub and on this blog. My version has been so popular, I’m considered somewhat of an expert on IR remotes. It has been really satisfying to get emails from other people who have built their own IR remotes for their elderly or disabled friends and family. One guy build a remote for his nearly blind grandfather using my code. His version has very large pushbuttons and plays back soundbites when you push the button. It includes specialized buttons that automatically jump to some of his grandfather’s favorite channels such as news or sports. The guy just recorded his own voice to play back but I think it would’ve been better to have James Earl Jones say “THIS is CNN!” or the ESPN Sports Center jingle “Duh da dant, duh da dant”.

RIP The Stick

It’s kind of interesting that the stick saved me from two separate situations where I was very emotional over lost ability. When I couldn’t type anymore using my hands I thought it meant the end of using the computer altogether. The stick let me keep typing. Then when I couldn’t drive my wheelchair anymore, the stick let me keep driving. It also had other uses such as pushing TV remote buttons and operating an iPod or touchscreen smartphone. Unfortunately I met another one of those crossroads moments where I can’t do what I used to do. The stick is not going to bail me out. In fact because I could no longer get the stick into position that I needed, I’m not able to use it to operate the remote, the phone, or to assist me with driving. Here’s a brief video that shows how difficult it was for me recently to be able to get the stick into position.

That video was recorded back in June 2015. As I write this in January 2016 things have gotten worse. For the past couple of months I haven’t driven my wheelchair all. I couldn’t get the stick into position without help, so anytime I wanted to go somewhere, dad would have to get into position and even once I was there sometimes it was too difficult to drive. So in recent weeks he just pushes me everywhere. The new wheelchair I’ll be getting should resolve some of that. You can see other videos and blog entries about my quest to get new wheelchair.

Arduino to the Rescue

Now that I am no longer able to use the stick, I had to come up with something else. I had been anticipating this problem for many years especially when it came to using the TV remote. After using my specialized Arduino powered remote in bed with just a few pushbuttons, I realized it was much easier to use than pushing the buttons with my stick while sitting in the wheelchair. This latest remote that I purchased has very tiny buttons and unless you get the tip of the stick in exactly the right place they would not push. So over two years ago, I began working on building an Arduino powered TV remote to replace my usual universal remote.

I started out with an Arduino Leonardo and a 4 x 20 character LCD screen. This was going to be the ultimate remote that not only would control the TV and the computer mouse, it might also be used as a wireless infrared keyboard. That’s why I needed the bigger display. I decided I would put four or five pushbuttons on it to scroll through the menus. I would still using my mouth stick but I would have the options of attaching micro switches that I would hold in my hand. We actually built an early prototype of the device and it was pretty cool but it was a little bit impractical. It was rather large and heavy to be mounted on bracket that I had been using. I wasn’t sure what I was going to do to provide power to it. Also the various types of pushbuttons that I tried worked very well. If I used micro switches on the end of a wire, I had to put my arm in an awkward position in order to be able to use them. This particular device didn’t go completely unused. I programmed it with special codes for a toy helicopter that used in infrared remote as well as a toy dinosaur. I’ve already documented those projects in other blog posts and videos. I never did get around to using it as a TV remote because I couldn’t come up with the right buttons. Also I didn’t really need it, I could still pushbuttons with the mouth stick. Keep in mind this project started almost 3 years ago when I was in better shape. Here’s a photo of the prototype was a large 4 x 20 LCD display that I never did get fully working.

The Leonardo-based IR remote with 20×4 character LCD. I never finished it.

Here are the 5 micro switches connected to the Arduino Leonardo remote that I could have used as an alternative to the pushbuttons on the device itself. I used these switches to control the helicopter and the toy dinosaur. It turns out that 5 switches were too many. I could not comfortably hold them and I could not hold them if my arm was in a position where I could drive the wheelchair with the joystick. Now that I’m no longer using my hand for the joystick, I found a position where I could comfortably hold 3 of these switches with a little adaptation which I will show you later.

Internet of Things in the Interim

Pinoccio Wi-Fi Development Board

In the interim, I found other ways to control my TVs but this time over the Internet. Using the old Pinoccio Wi-Fi module and a webpage I was able to control the living room cable box from my adjacent office by clicking on a webpage. I have an HDMI splitter connected to the living room cable box. One output goes to the living room TV where my dad watches. The other output goes to a very long HDMI cable that goes through the wall into a TV in my office. There I can watch the same thing as dad is watching the living room. Of course he falls asleep in the recliner when doesn’t fast-forward through the commercials. Being able to control the living room cable box remotely is very useful. I also set up a similar system between the cable box/DVR in my bedroom and ran it into the office although I use RF coaxial cable for that link which makes it standard definition only. Still it’s very useful. I also made the webpage sensitive to keyboard presses which meant that I could use my voice control to operate it. For example if I would say “Press P” using Dragon dictation, the webpage would push the play button. The arrow keys were especially useful when browsing through the on-screen guide. I could simply speak the Dragon command “move right 6” or “page down” and it would scroll around the on-screen program guide.

Arduino Yun

The Pinoccio platform was unreliable and eventually discontinued. You can read about my love/hate relationship with that elsewhere. I replaced it with the Arduino Yun which not only made it a Wi-Fi compatible Arduino platform but it had a built in advanced processor running a version of Linux that could serve the webpages rather than hosting them on my PC. The Arduino Yun can be reprogrammed by Wi-Fi which is very useful. I can upgrade the software anytime I want. The unit in the living room is stuck underneath an end table next to my dad’s chair. The one in my bedroom is up on a bookshelf. In recent months as I’ve lost the ability to use my regular remote and stick I even added a third Arduino Yun in the office which is only used to turn the office TV off and on and control the volume. Each has its own webpage and creates its own IR codes specific to the devices in that room. I also have webpage control to a Kodi/XBMC media server running on raspberry pi. So I can control 2 different cable boxes, three different televisions, and three different raspberry pi media players all using webpages designed to be compatible with voice control.

Chris helped Christopher. Christopher helps Chris.

I still miss being able to push remote buttons. Once I realized I really do need a cell phone for safety purposes since occasionally dad leaves me alone while doing errands, I had to come up with a way to control the phone again now that I could no longer use my stick to operate the android phone. I could give up playing Angry Birds. You can play Candy Crush on a Facebook webpage. But I really need the phone. Thanks to a young man named Christopher Hills who lives in Australia, I discovered that my move from iOS to android was a mistake. He has cerebral palsy but he doesn’t let it stop him from pursuing his hobby and vocation of making videos. He is somewhat of an expert in adaptive technology. He posted a YouTube video embedded below in which he describes new accessibility features in iOS version 9. It allows you to use one or more pushbuttons to access nearly every function of the phone. Of course it also works for iPad tablets. The pushbuttons are connected to the phone or tablet over a Bluetooth connection.

Seeing that video was a very emotional experience for me. For one it was the realization that I could continue to use a smart phone after all. But he also reminded me of my late friend Christopher Lee. He was a friend who had very severe cerebral palsy. I had built an accessible computer for him back in the early 1980s. My late friend could not push a button but he could make a clicking sound with his tongue. Of course there was no speech recognition back in those days because of eight bit computer just wasn’t powerful enough to do it. I will write a whole other series of blog posts about my friendship with him and the things that we went through to get him computer access. It’s amazing that 30 years ago Chris Young was building accessible computer for a guy with cerebral palsy named Christopher Lee. Now a guy named Christopher Hills with cerebral palsy extremely similar to the severity of my friend Christopher Lee is demonstrating to me how I can continue to access a smartphone. It all came full circle. Here’s a link to the video demonstrating the switch control features of iOS 9.

Just-In-Time Technology

It’s a bit creepy that the technology that I need, has been developing just in time for me to use it. For example the mouse control via Dragon dictation software is usable but awkward. Once I got into Arduino I wanted to find a way to emulate a mouse or keyboard. While I was investigating various hard ways to do that, they released the new Arduino Leonardo which made it incredibly easy. Just as the Pinoccio platform was shutting down I discovered the Arduino Yun which in the long run was a better solution. And just as I was losing the ability to use a smart phone, iOS 9 was being released with unprecedented powerful switch control features. Then another “just-in-time” technology came along. The electronic supplier that I use, Adafruit Industries, is a phenomenal organization designing and selling maker products around the world. They are where I buy all of my electronic parts and I show off my projects on their weekly video chat “show-and-tell”. They had recently begun slowing various modules for Bluetooth control. The new Bluetooth 4.0 also known as Bluetooth Low Energy or BLE makes it very easy to build gadgets that communicate with computers, tablets, or smart phones via Bluetooth. That was exactly what I needed if I was going to use wireless switch control.

Adaptive equipment suppliers market Bluetooth devices especially made for switch and/or joystick control at a cost of up to $500. There was another model for about $150 that wasn’t nearly as capable but would work with a couple of push buttons. However I could purchase a handful of parts from Adafruit and I could build one for under $75. By building it myself I could customize the software however I wanted. I could incorporate whatever other functions I wanted besides the iOS switch control including making it an infrared remote TV, cable and mouse control.

Step-by-step all of the technology that I needed was appearing exactly when I needed it. They say a coincidence is when God creates a miracle and nobody notices. I was noticing things falling into place.

Goodbye Android… Back to iOS

There was switch control the older versions of iOS however my old iPod touch only worked up to iOS 5 or 6 I forget which. Those earlier versions of switch control left a lot to be desired. Until I saw that Christopher Hills video, I had no idea how capable it had become. Latest android version also introduced switch control but it wasn’t nearly as powerful or useful as iOS 9. It was obvious I was going to have to switch back to iOS.

I recently purchased an iPad for my nephew that he needed for school. Before delivering it to him, I tinkered with it using an Adafruit Bluefruit Micro BLE module and prove that it could communicate with iOS 9. That startled the issue for me. Although it cost me a fortune, I purchased an unlocked iPhone 6. Really didn’t need the 6s or the 6 plus versions. I could still keep my cheap pay-as-you-go plan that’s costing me less than $15 per month. I very rarely am away from Wi-Fi so I don’t need to pay $40 per month for unlimited data. My dad retired his old flip phone and inherited my android phone. He’s having a lot of fun with it learning how to use smartphone features he’s never had before.

Finally the Ultimate Remote “The IRBLE”

Since I was going to be building an electronic device to operate the iPhone, it was time to also incorporate TV/cable remote capability as well. Technology had advanced that things were smaller and more capable than when I first started building the big display Arduino Leonardo remote three years ago. The Arduino Micro BLE has the same ATmega 32u4 processor as the Leonardo. Additionally it has Bluetooth and it is only slightly larger than a USB thumb drive. Instead of the huge LCD display that only display 4 lines of 20 characters, Adafruit now sells an OLED graphic display that is only 1.3 inches across but has 128 x 64 pixels of resolution. Because I no longer had to keep my arm in a particular position to drive the wheelchair, I could place my arm in a position that made it easy to hold the micro switches to activate the device. I now have a 3-D printer which allowed me to make a little gadget that attaches to the micro switches that makes it easier to position them in my hand securely. The only remaining problem was how to get power to device. I had solved that problem a few months ago by designing the Printy Boost battery pack which uses a LiPoly battery, an Adafruit charging module and a 3-D printed case of my own design. Click here to see the tutorial I wrote for the Adafruit Learning System showing you have to make your own Printy Boost battery pack. I had already been using this battery pack to supplement on my android or iPhone. I just needed to run a little cable from the battery pack over to the new remote.

I have decided to call it “IRBLE” (pronounced the same as herbal) which is an combination of IR for infrared and BLE for Bluetooth Energy. Here are a series of photos of the project.

This is me holding three micro switches in my right hand. The orange plastic is a 3-D printed adapter that lets me hold the buttons in the proper orientation.

Here are the Adafruit Micro BLE board, the Adafruit 1.3 inch OLED, and my custom-designed infrared output board that I use for all my projects.

The Adafruit Micro BLE measures about 2″ long.

Here is the 3-D printed case will I made for the new device. Below that are some screen grabs from Blender 3-D when I designed the box.

Here’s the thing all wired up. It looks a mess but it works. Thanks to dad and his excellent wiring skills.

Here are the parts in the case.

Here is the backside of the assembled device showing the infrared LEDs protruding out of the case. These transmit the signals to the TV or cable box.

You can also see the Velcro tabs is to attach it to my bracket on the wheelchair. Between the tabs is a tiny hole which we drilled in the back of the case so I could reach the reset button. A couple of times during the programming I had a glitch and nearly bricked the device. Fortunately if you hit the reset button at just the right moment and initiate and upload it will work again. I was worried I would not be able to recover it After one of the glitches. Believe it or not even though this board was only introduced a few months ago, it has already been replaced by a new model. Adafruit has a new line of development boards called “Feather” that come in a variety of configurations. If I had ruined my board I already had purchased one of the newer Feather models but I would’ve had to redesign the wiring harness and the 3-D printed enclosure. Fortunately I was able to recover it.

Finally here is the final product mounted on my bracket next to my iPhone 6.

You can see on the side of the mounting practice holding the old capacitive touch foam rubber tip for my stick. I probably will never use it again but there is one final thing for which I might use the stick. When playing Candy Crush on a timed level I cannot work the mouse with my voice control or IR remote quickly enough to finish the level. I can only do those levels with the stick in my mouth. But other than that, I won’t be needing the stick anymore.

The TV in my living room, bedroom, and office are all Samsung and use the same codes even though they are different models. The cable box in my bedroom in the living room uses the same codes. In addition to being able to control all of that, and the mouse and arrow keys on my desktop PC, also programmed in the kitchen TV and the surroundsound amplifier in the living room. As I’m writing this, I still need to program in codes for my Blu-ray player. I’m a little bit worried I might run out of space on the Arduino. It is only has 2K of RAM memory and 32 K flash memory. I only have about 150 bytes of RAM remaining and I’ve used 94% of the flash memory. Fortunately Adafruit also has a Feather board that uses ARM Cortex M0 processor. https://www.adafruit.com/products/2995

It runs at 48 MHz, as 256 K of flash memory, and 32 K of RAM memory. I would have to rewrite my infrared code library but I intend to do that anyway.

Among the things I can do besides make phone calls and run most apps, I have an app that gives me remote control of the Kodi media players on my raspberry pi. Of course I could modify the design of the remote to use a Wi-Fi add-on and control the raspberry pi easier than through the phone. Adafruit does not yet make more than has both Wi-Fi and Bluetooth but my guess is by the time I got around that, they will have one. Possibly a Wi-Fi add-on for the Bluetooth board or a Bluetooth add-on for a Wi-Fi board. For now I got a remote do absolutely everything that I need it to do.

We can finally retire my last stick.

Epilog: Recently I was hospitalized and had to be put on a ventilator. The only way I could effectively communicate with doctors and nurses was to use this Bluetooth device to type messages into the notepad application on my iPhone. You can read a multipart blog about my hospital adventure titled “Pray That They Listen to the Man with No Voice“. Also I’ve written a tutorial for the Adafruit Learning System describing how to build a Bluetooth device for iOS switch control. You can read it here.

One more item… After over a year of faithful service my Ultimate Remote gave up the ghost. Here is an article about the replacement unit that I built.

The Ultimate Remote is Dead. Long Live the Ultimate Remote 2.0

R.I.P. Pinoccio… It Was Fun While It Lasted

Posted on May 23, 2015 by cy

Pinoccio Wi-Fi Development Board

I’m a tiny bit sad to report the death of Pinoccio. Note that the missing “H” is deliberate. I’m not talking about Pinocchio the beloved character from children’s literature. I’m talking about “Pinoccio” (without the “H”) open-source semi-Arduino-compatible hardware and software platform. Actually to say that I’m reporting it is a bit of yesterday’s news. It was actually reported here in a blog post on their website dated March 30, 2015. The reason I didn’t see that blog post right away is that I had pretty much given up on the system several months earlier.

Here’s a bit of history… In late 2012 or early 2013 I became aware of this Indiegogo campaign titled “Pinoccio – A Complete Ecosystem Building of the Internet of Things” It was a small 1″ x 2″ Arduino compatible board using a chip similar to the one used by the Arduino Mega. This variety had a built in mesh radio such as used by the X-Bee system. It had a built-in LiPo battery, an RGB LED, a temperature sensor and a Wi-Fi backpack. You could connect to one of the units called a Lead Scout via Wi-Fi and then it would communicate to the other units over mesh radio which were known as Field Scouts. I quickly signed up at the $149 support level which would get me a Lead Scout and a Field Scout. Although the units were a bit pricey, if you added up what it would cost to buy an Arduino Mega, battery, charger circuit, X-Bee radio, and Wi-Fi module it seemed like a bargain at the time. They were seeking $60,000 in funding and end up raising over $105,000. Put this in proper context note that this was several months before Spark Core appeared on Kickstarter. Note that Spark Core has recently rebranded as Particle.io.

Had Pinoccio made its original delivery date of July 2013 they would’ve beaten everyone to market and would’ve been a major player in the Internet of Things movement. There were plans for a smaller version without the battery and sensors that would’ve been easier to embed into production products. There were plans for a variety of backpacks or shields including the one I was most anxious to see… infrared LED and receiver. My goal was to use it to create an Internet capable IR remote. I wanted to create an inexpensive alternative to the RedEye IR Remote from ThinkFlood. And it was a good thing I was planning such because ThinkFlood was shutting down as seen here.

My Pinoccho boards upon arrival.

The folks from Pinoccio quickly learned the hard lessons of crowd sourced funding. Lesson number one is inevitably “If you’ve got a great idea it’s easier to raise money then it is to bring a product to market.” I won’t bother to recount the litany of things that caused multiple delays but the bottom line is that backers did not get their units until April 2014 a full 10 months past the initial estimated delivery. The reasons were the usual things: finding suppliers, finding someone to make the boards, setting up the business itself. It seemed that the main reason/excuse for delays was that “We want to get the software right.” Here is my blog post which gave my initial positive reaction to the devices when they finally arrived.

The software that we waited so long to finally get was indeed quite extensive. There was an Internet portal called hq.pinocc.io that allowed you to do many things without even writing any code. And it included an extensive script language that you could write small programs directly from the HQ application without having to use the Arduino IDE or do any C++ coding. They wanted you to be able to plug the thing in and do something with it right away. That ability is one of the key things that led to the success of the original Arduino. With a built in RGB LED and temperature sensor, you could do more than just blank the LED on pin 13 like you can with Arduino out-of-the-box.

However if you wanted to write your own applications, the learning curve at least for me was very steep. I had no experience in connecting devices to the web. I did know quite a bit of JavaScript programming, CSS, and DOM HTML programming which was useful. I had a little bit of experience with PHP however that did not apply in this case. What I did not have any idea how to do what is called “asynchronous communication” with Web servers.

I was taught as a programmer from day one that execution of a program started at the top of the main module and went step-by-step through the module sequentially unless modified by the if/then/else or some sort of loop structure. But asynchronous coding is something significantly different. You make a request to a Web server and within that request, you send it the code that you want to execute when it finishes the job. That seems simple enough. I figured it would call the code when it was ready and then move on to the next step. But it doesn’t work that way. You move on to the next step immediately after making the request and you have no idea when it’s going to complete that request and invoke your callback function. I would make a request from the server for a piece of information. My callback function would tell the server where to put that information in my program. Then I would try to display that information on the webpage. But it was never there. When I would insert debugging code to see why it wasn’t there, it was there. It reminded me of the paranoid poem about the little man on the stair.

“Last night I saw on the stair
The little man who wasn’t there.
He wasn’t there again today.
Oh how I wish he’d go away.”

I was being haunted by the returned data that wasn’t there 🙂

What I didn’t understand was that this callback function wasn’t a normal subroutine where you call it, it executes, and when it returns you carry on. You have to carry on immediately after the request and you don’t know how long it’s going to take for the Web server to return your data. So you have to put something in the callback function that tells your main program “Hey he finally got what you asked for. You can use it now. It’s really here.”

When you are collecting several pieces of data in a row and you don’t want to proceed until you’ve got them all, the nested callback functions can get pretty hairy. It took me a long time to figure out what I was doing wrong. It also took a lot of patience on the part of the people from Pinoccio in their support forums to walk me through my inadequacies is particular area of programming. I owe them a tremendous debt of thanks. (Humorous note here… When I dictated the previous sentence using my dictation software, it misunderstood me and said “I/O them…”. How appropriate for a “.io” system). Anyway they were most gracious and patient with me.

I did my best to pay back their kindness. I blogged everything I could about the device. I showed it off on the Adafruit Google+ Hangout Show-and-Tell. I blogged about how to get around some SSL certificate problems that cropped up along the way. And I did my best to educate them in the hardware requirements necessary to make an infrared backpack for the Pinoccio system. And ultimately I did get a working Internet-of-Things infrared remote that I used to operate my TV and cable box.

My cable box is located in the living room but I have an HDMI cable that runs into my adjacent office so that I can watch the same thing my dad is watching and living room. I can get on a webpage in the office and control the cable box in the living room. I used it every day for several months and it was a real godsend. I succeeded in replacing my defunct and unsupported RedEye remote.

I included Pinoccio support in my next public release of my infrared library IRLib. I began cleaning up my asynchronous webpage code and preparing to publish it to share with the world everything I have learned so that the next novice who came along would have a clear and simple tutorial to follow I would not have to bother the people in the support forum to learn the things I have learned the hard way.

One of the things that bothered me about the entire system was that it was totally dependent upon the website hq.pinocc.io servers were maintained by the Pinoccio organization. On occasion, their server would crash and I would be stuck with a useless system. I asked them what do we do to remove that dependence. The old RedEye remote system was accessed directly to the local IP address of the device itself. It also included its own Web server in the device. In contrast the Pinoccio system required me to make my own webpage to control the device (as great as HQ was it wasn’t sufficient). That meant I had to install a Web server on my PC. I can only control the system from that PC unless I uploaded the webpage to cyborg5.com which I didn’t want to do. Setting up WampServer on my PC was much easier than I anticipated. That allowed me to host my controlling webpage with no problem.

Furthermore my webpage could not communicate with the device directly. It had to go through their servers. My controlling webpage went to a URL on their server and their server connected back to the device itself. The whole point of Pinoccio, for me at least, was to replace the defunct out of business RedEye Remote. What was I going to do if Pinoccio ever folded? They assured me that they were working on a system that would allow direct connections without going through their server system. And in the end they did so.. They developed a system where you could plug one Scout into a PC and have it communicate directly with the other Scouts using the mesh radio. You didn’t need the Wi-Fi at all. They called it a “Bridge Scout”. While that was of suited my purpose, still wouldn’t have given me all of the capabilities the device should have had. There supposedly is a way to set up one’s own server that would duplicate their part of the infrastructure. I believe them when they tell me that. However doing that myself would required another steep learning curve that I didn’t really feel like attempting. It would require more than I can get out of WampServer. It involved node.JS and a variety of other things that were beyond me.

Unfortunately somewhere along the way the device got a bit glitchy. There were constant software updates some of which I kept up with and some I did not. After not doing updates for several months, I finally decided to do an update in hopes of fixing the glitches. The end result was my device quit working altogether. I spent a couple of weeks presuming that the problem was an adverse interaction between my infrared code and their systems software. It involved going onto GitHub and figuring out which version of the software I had been using that was working somewhat well and then individually applying each and every update that had occurred over the period of several months. I finally found the patch that was causing my code to crash. In the end it was not an adverse reaction between my infrared code and their system. I was able to whittle it down to an example that did not include my IR code at all.

Somewhere in the midst of all this, I ended up “bricking” my lead scout. Somehow during a crash, the boot loader was overwritten. They talked me through a system wherein you could use one Scout as an ISP to restore the boot loader on a broken Scout. Initially that process did not work because I tried to do it with the Wi-Fi backpack still installed. Somewhere along the way while adding and removing the Wi-Fi backpack without disconnecting the power, I permanently damaged the Wi-Fi backpack. That meant that the so-called “Ecosystem for the Internet of Things” was no longer Internet capable. A replacement Wi-Fi backpack would cost $79. I was able to get the system running somewhat using the bridge Scout they described where you had to keep one unit plugged into a PC to communicate with another unit. However I had become frustrated with the whole thing and needed to get away from it for a while.

I ended up ordering an Arduino Yun from Adafruit.com. I immediately fell in love with the device. It consists of a powerful microprocessor running a minimal version of Linux and an Arduino Leonardo in one device. The communication between the Leonardo and the Linux was well defined and easy to use. The Linux portion did include its own Web server. You could also update the onboard Arduino sketch and the associated webpage using the latest Arduino IDE and do so wirelessly for Wi-Fi. That ability to update wirelessly was something that Pinoccio had promised from the beginning but never did fully implement at least from a users perspective. They did allow you to update system software wirelessly but not user programs at the Arduino level.

Although I did have the Pinoccio experience under my belt along with the experience of doing asynchronous callbacks to Web servers, setting up my IR remote on the Arduino Yun took me only a day and a half rather than the weeks and weeks of frustration that I had with Pinoccio. One of the things that was probably the nail in the coffin of Pinoccio for me personally was the fact that I could buy an Arduino Yun with its embedded Linux, Wi-Fi, Arduino Leonardo, and built-in Web server with no external infrastructure needed for about $75. That was four dollars less than the Wi-Fi backpack alone for Pinoccio.

With the success of modules like the CC3000, Particle a.k.a. Spark Core, and the amazing new and inexpensive ESP8266 there was no hope for Pinoccio. They might have salvaged it by ditching their own Wi-Fi backpack and making a backpack using the ESP8266.

My intent had been to take a break from Pinoccio after I got the other system up and running. I still felt like I owed them those tutorial blogs to help other Pinoccio users not have to go through the blood sweat and tears that I’ve been through. But I got distracted with other projects and never was able to do it. Now of course there is no more Pinoccio. Their servers are shutting down at the end of the month and anyone who hasn’t figured out how to launch their own server or who is content with using bridge mode is going to be out of luck.

Ironically my old RedEye Remote has in some ways outlasted the Pinoccio. Even ThinkFlood shut down over two years ago, you could still use their device as long as you didn’t need to update the software. I’ve been using mine as an Internet remote to control my bedroom TV and cable box in the same way I’m using the Arduino Yun for the living room. However I recently purchased a new TV in the bedroom and I cannot update the RedEye with the new codes. I had to order another Arduino Yun.

I had a bit of a scare because the Yun has been out of stock at Adafruit for a couple of months now. Fortunately I found one at my second favorite supplier SparkFun.com. I’m pretty sure that the shortage is a consequence of the trademark disputes between Arduino.cc and their previous hardware manufacturing company which has now rebranded itself as Arduino.org. Is my belief that Arduino.cc should and will win the dispute. And I’m absolutely ecstatic over the new announcement that Adafruit will become the US manufacturer for Arduino.cc. I’m confident that both Arduino and Adafruit will be around for a very long time.

In the end I think I’m going to miss Pinoccio. I was quite fond of the little fellow and a bit disappointed he never really achieved his full potential. I don’t regret any of it however. I learned a lot of useful programming. And I learned some lessons about crowd source funding. And it serves as a cautionary tale about Internet of Things systems that are too closely linked to their infrastructure. I think that as IoT continues to grow that’s going to be an important lesson for everyone.

Zoomer Dino Controlled by Arduino IR Remote

Posted on December 31, 2014 by cy

One of the hottest toys this Christmas is the Zoomer Dino. It is a remote-controlled self balancing two wheel robot dinosaur with an infrared remote. I got one for my 10-year-old nephew for Christmas and after playing around with it I had to get one of my own. I have been thinking about building Arduino powered two wheel balancing robot from scratch but here was one that works right out of the box. I’m not sure if it has a gyro or accelerometer to keep it balanced. He rolls around on his own making noises including burps, farts, and laughs. You can also take over control with an infrared remote. The remote has a joystick and three pushbuttons. The joystick moves the head up, down, left, right. If you hold in the “run” button while moving the joystick he rolls around under your control rather than moving the head. There also is a button for “chomp” which makes his jaw chomp open and closed. Additionally there is a “angry” button which makes his eyes glow red and he thrashes around angrily.

Zoomer Dino and IR remote

As with my IR controlled to a helicopter before, I had to see if I could reverse engineer the protocol it was using for the remote control. It was one of the most challenging IR reverse engineering projects I’ve ever encountered. I finally had to go out and purchase one for myself because I had to wrap up the original one for my nephew.

I used my IRLib Arduino Library for decoding and encoding IR signals. Once you push a button to get things started, the remote puts out a continuous signal that is the neutral position of the joystick with no buttons pushed. I came up with a raw dump of the timing values using my IRrecvDump sample sketch. Here are the results.

Decoded Unknown(0): Value:0 (0 bits)
Raw samples(54): Gap:43480
  Head: m9250  s4750
0:m550 s650	1:m500 s650		 2:m550 s650	3:m550 s1800		 
4:m500 s650	5:m550 s650		 6:m550 s650	7:m550 s650		 
8:m550 s1750	9:m550 s650		 10:m550 s650	11:m550 s650		 
12:m550 s650	13:m500 s700		 14:m500 s650	15:m550 s650		 

16:m550 s1800	17:m500 s1800		 18:m550 s650	19:m550 s1750		 
20:m550 s1750	21:m550 s1800		 22:m500 s1800	23:m550 s650		 
24:m550 s650	25:m500
Extent=53300
Mark  min:500	 max:550
Space min:650	 max:1800

This is a quite typical set of signals used by many protocols. Only the timings and number of bits are unique. We have a header that consists of about 9200 mark and 4800 space followed by 25 data bits and a closing mark. The data marks run about 500 or 550. The data spaces are either about 650 or 1800. This variable spacing is the most common way to encode zeros and ones. We’ll call the short spaces ones and the long spaces as ones. I created a custom decoder object as follows.

#include 
#include 

class IRdecodeDINO: public virtual IRdecodeBase
{
public:
  bool decode(void); 
  void DumpResults(void);
};
#define DINO_HEAD_MARK   9200
#define DINO_HEAD_SPACE  4800
#define DINO_ZERO_MARK    500
#define DINO_ZERO_SPACE   650
#define DINO_ONE_MARK     500
#define DINO_ONE_SPACE   1800
#define DINO_SAMPLES 54
#define DINO_BITS 25

#define DINO (LAST_PROTOCOL+1)
void IRdecodeDINO::DumpResults(void) {
  Serial.print(F("Decoded DINO: Value:")); Serial.println(value, HEX);
};
bool IRdecodeDINO::decode(void) {
  IRLIB_ATTEMPT_MESSAGE(F("DINO"));
  if(!decodeGeneric(DINO_SAMPLES,DINO_HEAD_MARK, DINO_HEAD_SPACE,
    0, DINO_ZERO_MARK, DINO_ONE_SPACE, DINO_ZERO_SPACE)) return false;
  decode_type= static_cast<IRTYPES>DINO;
  return true;
};

IRdecodeDINO My_Decoder;

int RECV_PIN =11;

IRrecv My_Receiver(RECV_PIN);
long Previous;

void setup()
{
  Previous=0;
  Serial.begin(9600);while (! Serial);delay(1000);
  Serial.println(F("Send a code from your dino remote and we will decode it."));
  My_Receiver.enableIRIn(); // Start the receiver
}
void loop() {
    if (My_Receiver.GetResults(&My_Decoder)) {
    My_Decoder.decode();
    if(My_Decoder.decode_type == DINO) {
      if(My_Decoder.value!=Previous) My_Decoder.DumpResults();
      Previous= My_Decoder.value;
    }
    else Serial.println("Unknown");
    My_Receiver.resume(); 
  }
}

Because the remote sends signals continuously, this routine only reports the initially received value and then anytime the value changes to something different. It outputs 6 hex digits but note that there are 25 data bits being received. I then plugged the hex values into an Excel spreadsheet, converted them to decimal, and then parsed out the individual bits to try to deduce a bit pattern. I tried leaving the joystick alone when pushing the 3 buttons individually. Then I tried moving the joystick full throw forward, backwards, left, and right. The results are shown in the table below. You may click the table image to enlarge it.

Table 1-Bit patterns from Dino remote.

In all samples, the first three bits were always zero as was the last bit. It was pretty obvious that after the initial zero bits, there was a five bit field that was the left/right position of the joystick with the left position having a value of zero, the center as 16, and the right was 31. This was followed by another five bit field that was the forward/backwards joystick position with zero to the back, 16 in the center and 31 full forward. The next three bits were obviously the three buttons. There were eight additional bits that seem to have no rhyme or reason to them.

Here is a revised version of the receiving code that parses out the bits into their individual fields.

#include #include


class IRdecodeDINO: public virtual IRdecodeBase

{

public:

  bool decode(void);

  void ParseFields(void);

  void DumpResults(void);

  unsigned JoyX, JoyY, Parity;

  char Chomp, Angry, Run;

};

#define DINO_HEAD_MARK   9200

#define DINO_HEAD_SPACE  4800

#define DINO_ZERO_MARK    500

#define DINO_ZERO_SPACE   650

#define DINO_ONE_MARK     500

#define DINO_ONE_SPACE   1800

#define DINO_SAMPLES 54

#define DINO_BITS 25
#define DINO (LAST_PROTOCOL+1)

void IRdecodeDINO::ParseFields(void) {

  long Temp = value>>1;

  Parity = Temp & 0x0ffL; Temp= Temp>>8;

  Run    = Temp & 0x1L;   Temp= Temp>>1;

  Angry  = Temp & 0x1L;   Temp= Temp>>1;

  Chomp  = Temp & 0x1L;   Temp= Temp>>1;

  JoyY   = Temp & 0x1fL;  Temp= Temp>>5;

  JoyX   = Temp & 0x1fL;

};

void IRdecodeDINO::DumpResults(void) {

  ParseFields();

  Serial.print(F("Decoded DINO: Value:")); Serial.print(value, HEX);

  Serial.print ("\tJX:"); Serial.print(JoyX,DEC);

  Serial.print ("\tJY:"); Serial.print(JoyY,DEC);

  Serial.print ("\tCh:"); Serial.print(Chomp,BIN);

  Serial.print (" Ag:"); Serial.print(Angry,BIN);

  Serial.print (" Run:"); Serial.print(Run,BIN);

  Serial.print (" Parity:"); Serial.println(Parity,HEX);

};

bool IRdecodeDINO::decode(void) {

  IRLIB_ATTEMPT_MESSAGE(F("DINO"));

  if(!decodeGeneric(DINO_SAMPLES,DINO_HEAD_MARK, DINO_HEAD_SPACE,

    0, DINO_ZERO_MARK, DINO_ONE_SPACE, DINO_ZERO_SPACE)) return false;

  decode_type= static_castDINO;

  return true;

};
IRdecodeDINO My_Decoder;
int RECV_PIN =11;
IRrecv My_Receiver(RECV_PIN);

long Previous;

void setup() { Previous=0; Serial.begin(9600);while (! Serial);delay(1000); Serial.println(F("Send a code from your dino remote and we will decode it.")); My_Receiver.enableIRIn(); // Start the receiver } void loop() { if (My_Receiver.GetResults(&My_Decoder)) { My_Decoder.decode(); if(My_Decoder.decode_type == DINO) { if(My_Decoder.value!=Previous) My_Decoder.DumpResults(); Previous= My_Decoder.value; } else Serial.println("Unknown"); My_Receiver.resume(); } }

But what to do about those parity bits? I had to presume they were some sort of checksum or other data verification field. Normally when capturing and decoding IR signals I really don’t care what the data represents internally. I point a TV remote at my receiver circuit, capture the hex value, and then re-create that value using my IR transmitter. I could have just quit now and build an application on the Arduino that would transmit button pushes and fixed joystick positions but it would be nice to be able to use any joystick position that I wanted from 0- 31 in either X or Y directions in any combination. But to do that I needed to figure out how to compute those additional eight bits of data.

Most consumer-electronics protocols use a simple checksum of adding the previous data fields together. Sometimes you take the 1’s complement of the data and repeat it. Sometimes you use bitwise XOR to combine the fields. I spent three days playing around with various versions of my Excel spreadsheet analyzing lots of bit patterns captured from the remote and could not deduce the pattern. I asked a couple of online acquaintances if they had any suggestions but they’re only input was to try checksum, XOR etc. A cyclical redundancy check or CRC was another option but that would be hard to reverse engineer and they generally are not used for such short streams of data. Keep in mind were only talking about 13 bits of actual data if you don’t count the leading and trailing zeros or the eight check bits.

At one point I remembered there was something called a Hamming error correction code. I had learned about them in college in my CS 484 class with Dr. Judith Gersting over 25 years ago. I barely understood how they worked back then and I’ve not used them ever since so the chances of me being able to figure it out on my own were represented by the three initial zeros in the data stream 🙂 Dr. Judith Gersting was not my only mentor in college. Her husband Dr. John Gersting told us on the first day of programming class that he was not going to teach us programming. He was going to teach us to teach ourselves programming because the minute we walked out the door, everything would probably be obsolete anyway. He literally handed us a textbook that he wrote and told us to go teach ourselves the course. I guess I was going to have to do some Google searches and teach myself everything I needed to know about Hamming codes.

As it turns out there is no one single way to create an error detecting/correcting code. There are entire websites devoted to multitudinous ways and they all use notation that I didn’t understand. I did find one website from UMass linked here.

http://www.ecs.umass.edu/ece/koren/FaultTolerantSystems/simulator/Hamming/HammingCodes.html

One thing I have learned about Hamming codes was that they typically only add a vary few extra bits. Using the calculator linked above if I put in a 16-bit value it would only add five additional bits. I was getting eight additional bits on just 13 bits of data. But the one thing I did learn from that page was the way you calculate those extra parity bits. There is a matrix that tells you which of the data bits to add together to get each of the individual parity bits. I really had to do was figure out which data bits contributed to each parity bit. I had already noticed that if you push the “run button” which I have listed as “B0”, that parity bits P2,P1,P0 all inverted from their normal position. Similarly the “angry button” which is “B1” toggles parity bits P3,P2,P1. Similarly the “chomp button” labeled “B2” toggles P4,P3,P2.

So I made a new set of columns in the spreadsheet to compute the parity bits. I begin by saying…

P0=B0 P1=B0+B1 P2=B0+B1+B2 P3=B2+B1 P4=B2

Additionally the center position of the joystick had only a single bit set, the highest order bit of the five bit field which was value 16. By comparing those to the joystick positions which were all of the way left or on the way back (which consisted of all zeros) I could figure out which parity bits changed based solely on X4 and Y4. Quite by chance I also found had captured samples with X positions of exactly 8, 4, and 2. So that told me which parity bits were based upon X3, X2, X1, and X0. As I updated the formulas for calculating each parity bit, I compared the computed results to actual capture values for every hex value I’d captured. I had a list of over 30 values that I had dumped from simply wiggling the joystick around. Eventually I was able to fill in the blanks and came up with the following formulas.

P0=X4+X0+Y4+Y3+B0 P1=X4+X1+Y3+B1+B0 P2=X4+X2+X0+Y3+B2+B1+B0 P3=X3+X1+Y4+Y0+B2+B1 P4=X4+X0+Y1+Y0+B2 P5=X3+X1+Y2+Y1+Y0 P6=X4+X2+Y3+Y2+Y1 P7=X3+Y4+Y3+Y2

Comparing my computed results to all my captured results I was convinced I had completely deduced how the parity bits were calculated. When you put those results in a table as follows, there is a definite pattern to them. It looks a lot like the patterns that had been seeing on various websites.

Table 2-Parity calculation matrix.

Finally I was able to create a sending routine that allowed me to test all of this out. This is a somewhat stripped-down version of what I ultimately came up with. You upload the sketch, call up the serial monitor, and type various characters into the monitor. The sketch then interprets those as commands and sends the proper hex code to the IR transmitter.

#include #include


class IRsendDINO: public virtual IRsendBase

{

public:

  void send(unsigned long data);

};

#define DINO_HEAD_MARK   9200

#define DINO_HEAD_SPACE  4800

#define DINO_ZERO_MARK    500

#define DINO_ZERO_SPACE   650

#define DINO_ONE_MARK     500

#define DINO_ONE_SPACE   1800

#define DINO_SAMPLES 54

#define DINO_BITS 25
#define DINO (LAST_PROTOCOL+1)
void IRsendDINO::send(unsigned long data) {

   sendGeneric(data,DINO_BITS,DINO_HEAD_MARK, DINO_HEAD_SPACE,

   DINO_ONE_MARK, DINO_ZERO_MARK,DINO_ONE_SPACE, DINO_ZERO_SPACE, 38, true, 0);

   delay(27);//Average gap was 26700 us

};
IRsendDINO My_Sender;
int RECV_PIN =11;
IRrecv My_Receiver(RECV_PIN);

char Mult, Normal, Chars;

#define COUNT 7

void SendMultiple(unsigned long Data, char Count) { for(char i=0;i<(Count);i++) {My_Sender.send(Data);}; }; void setup() { Serial.begin(9600);;delay(2000);while (! Serial);delay(2000); Serial.println(F("Enter one of the following letters A,C,U,D,L,R,F,B,<,>,N,0")); Normal=1; }; void loop() { char Cmd; if (Serial.available()>0) { switch (Cmd) { case 'A': SendMultiple(0x2105a0, 9); break; //anger case 'C': SendMultiple(0x201984, 6); break; //chomp case 'U': SendMultiple(0x21f162, COUNT); break; //head up case 'D': SendMultiple(0x2000ae, COUNT); break; //head down case 'L': SendMultiple(0x010112, COUNT); break; //head left case 'R': SendMultiple(0x3f003a, COUNT); break; //head right case 'F': SendMultiple(0x21f36c, COUNT); break; //forward case 'B': SendMultiple(0x2002a0, COUNT); break; //backwards case '<': SendMultiple(0x01031c, 5); break; //spin left case '>': SendMultiple(0x3f0234, 5); break; //spin right case 'N': Normal=1; break; //send neutral commands case '0': Normal=0; break;//send wiggle commands } } else {//if no serial data then send either normal play mode or sit still if(Normal) { //Un-comment next line to have Dino do normal behavior. // My_Sender.send(0x2101bc); //Comment out to turn off continuous transmission } else { //wiggle slightly in an attempt to set still My_Sender.send(0x21132c); My_Sender.send(0x20f27e); } } }

The actual remote sends continuous streams of data even when you aren’t doing anything. If you don’t touch any buttons or move the joystick for about one minute it eventually shuts down. If you are not pushing a button and the joystick is in the neutral position, the dinosaur engages in various preprogrammed behaviors. I needed a way to get him to sit still while I’m typing in the next string of letters. If you select “Normal” mode. It doesn’t send any signals. If you press a “0” it continuously sends a tiny forward and backwards code which basically has him sit in one place. He wiggles a tiny bit and make some noises but he doesn’t go off on his own. Then when you type other letters he goes in the direction you want him to. You can look at the “switch statement” to see which characters perform which functions. I send multiple transmissions of each code. The default number of signals is defined in COUNT so it was easy to change the default. I have a more advanced version of the sketch which causes him to move at various speeds, shake his head repeatedly, travel in zigzag motions etc. I also added commands to make him go forward and right or forward and left simultaneously. That way he doesn’t spin in place, he turns in a broad curve. In the demo video below I use that feature to make him travel in an oval-shaped pattern.

Know that all of the driving patterns I put him through in the video below could be done with the actual remote. You’ll have to trust me that they were created using an Arduino and my software.

My ultimate goal is to port my code to my pinoccio board which includes Wi-Fi and mesh radio. That way I can control him through a webpage similar to this. I will end up with an “Internet of things” remote control dinosaur. The pinoccio has a LiPo battery and is very small. I might just velcro it with an IR LED to the back of the dinosaur and not worry about maintaining a line of sight from my transmitter. I will post more details when and if I ever get that working.

Here is where I demonstrated the project on the Adafruit weekly Show-and-Tell on Google Plus Hangouts.

IRLib Updated to Version 1.5

Posted on June 18, 2014 by cy

We are pleased to announce that IRLib has been updated to version 1.5. IRLib is a library for Arduino-based microcontrollers that allows for the receiving, decoding, and sending of infrared signals. These new changes are a step forward in making the library less hardware platform dependent so that it can be more easily used by a variety of microcontrollers. These changes include…

New bit-bang option for PWM output frequency setting. Now can use any output pin with no hardware timers. Note:bit-bang output not as accurate as timer-based frequency selection.
Major rewrite of IRLibTimer.h to facilitate bit-bang. Separated hardware timer selection and specification into sending and receiving sections in order to implement bit-bang.
New IRfrequency class for detecting input frequencies. Previously was a stand-alone special sketch but now is a class including a DumpResults method.
New IRfreq and IRrecvDumpFreq illustrate simultaneous detection of frequency and pattern with both an IR learner and IR receiver is connected.
New #define USE_IRRECV define can be commented out to completely remove the interrupt driven IRrecv receiver class from the library. This resolves ISR conflicts with other libraries such as Tone() when not using IRrecv class.
New #define USE_DUMP define can be commented out to disable DumpResults methods. Saves code space when these methods are not needed.
Revised user manuals to document new features and correct previous documentation problems.

Note: The included user manual update is not yet available on the website at http://tech.cyborg5.com/irlib/docs/ but it will be updated shortly. New user manual is available with the library itself as a Microsoft Word .docx file as well as PDF and EPUB versions.
This library is available on GitHub at . For more information on this library see http://tech.cyborg5.com/irlib/

Pinoccio Internet of Things IR Remote Demo

Posted on May 4, 2014 by cy

Here is a YouTube video demonstrating how I created an internet of infrared remote using the new Pinoccio platform. The Pinoccio is an Arduino compatible board based on the ATmega256RFR2 chip. It uses a Wi-Fi backpacked and built-in 802.15.4 mesh radio.

~~As mentioned in the video I have not yet released my source code for the Pinoccio port of my IRLib but I will do so very soon.~~ The source code is now available on GitHub here. Read more about Pinoccio (and yes it really is spelled without an “h”) at https://pinocc.io. And my IRLib at http://tech.cyborg5.com/irlib/

Update: I also did a live demonstration of this project on the Adafruit Industries Google+ Hangout weekly Show-and-Tell which you can see here…

At some point I will post an extensive tutorial on this project.

Pinoccio Wireless Arduino Compatible Board: First Impressions

Posted on April 7, 2014 by cy

My Pinocchio boards arrived today in the mail. By the way I’m going to continue to call them Pinocchio rather than it to spelling Pinoccio simply because it’s easier to dictate using my voice control software wherein I do not need to go back and delete the “h” each time I type the word. For an explanation of the name you can see their FAQ here.

This board started out as a crowdsource funded project on indiegogo.com. It was billed as “A Complete Eco-System for Building the Internet of Things”. It consists of an ATmega256RFr2 microprocessor, a USB interface, a temperature sensor, an RGB LED, and a LiPo battery. The mesh radio built into the chip is a 2.4 GHz transceiver supposedly capable of ZigBee and IEEE 802.15.4 transmission although I’ve not yet seen anything about how to communicate with X-Bee or ZigBee modules from other manufacturers.

The package I ordered as part of my funding sent me two modules, one of them with a Wi-Fi shield or backpack as they call them. They call the boards “Scouts” so the one with the Wi-Fi shield is the “Lead Scout” and those without Wi-Fi are called “Field Scouts”. As a milestone perk I also got a prototyping shield and a small USB cable for charging and configuring. Here are some photos of the devices as shipped. (Click the images for larger view.)

Everything I Got

Topside view: Lead Scout with Wi-Fi on top. Field Scout below.

Bottom view showing battery.

The units use a micro USB cable. The first one I tried was a mini USB with an adapter on it. The adapter was too large because it got in the way of the Wi-Fi shield. I finally found a cable in my pile of cables. I wanted to be able to plug in both of them at once but as it turns out that may be a bad idea.

There was a card included that says to get started I should open a chrome browser and go to hq.pinocc.io and download their chrome app. I thought about browsing around the website and reading a bunch of documentation but one of the things the designers have said is that it ought to be easy to get started. They spent a lot of time working on the software and the front end for this thing rather than just creating the hardware and sending them out. In fact the original deadline for shipping was last July and here is the following April. So I thought I would give it the acid test and play dumb and see what I can find.

The app loaded just fine and I got a screen that told me to click to add a Scout control panel. They call the control panel “HQ” The first thing it said I had to do was to downloading Windows driver and install it. They tell you to plug in the device first and then it would tell me that no driver was available. Then it suggested I go to Device Manager via Control Panel in Windows and then I would find the device under “Ports (COM & LPT)”. It was not there it was under “Other devices” which is no big deal. I downloaded the driver and unzipped it into a folder. I would’ve preferred a self extracting installer but that was no big deal. When I tried to install the driver, Windows for bid me because it was not signed. No mention of that fact in any of their documentation so minus a few points for that problem as well. This was a Windows 8.1 64 bit machine. I had had trouble loading Arduino drivers on my laptop for the same reason and I found a website that explains how to permanently turn off that feature. I don’t know why I had not had the similar problem with Arduino drivers on my desktop Windows 8.1 PC. If you are interested… here is the website that tells you how to do it. That went relatively well.

Then I went to the process of configuring the lead scout. It took me several attempts and some email exchanges with their technical support people. Eventually it did start working but I’m not really sure what we did to fix it. It seemed to me that the steps they outline history followed in an exact precise manner.

Scouts in a mesh are configured together in something called a “troop”. So the first thing you have to do is give it a troop name. I chose “The Collective” (as an homage to Star Trek’s Borg). Then you name your lead Scout. I chose “Picard”. It then searches for Wi-Fi signals and asks you which Wi-Fi it should try to connect to. You are the Wi-Fi from the list and enter your password. There’s also a manual option if it cannot detect your Wi-Fi. When you completed that a screen pops up telling you that it succeeded adding your lead Scout to the Scout HQ. It then tells you to unplug the device so that it will reset and reconnect to your Wi-Fi. After that you click on the button that says “Done”. Apparently they are very picky about the order. You cannot click done until you’ve unplug the device and give it time to reset. Even then I had difficulty getting it to work right. In the end the only reliable way I could configure it was to unplug it and turn its power switch off and on. Then wait a few seconds before clicking done. Oh by the way when you first plug it in, the HQ searches for it and tells you that he could not find the device and that you probably forgot to turn it on. But it doesn’t tell you where the switch is. It’s not obvious. Anyway after unplugging, cycling the power switch, waiting a few seconds, and then clicking the done button it seemed to work okay.

You go to the same process for the field Scout although it does not prompt you for Wi-Fi information since it doesn’t have Wi-Fi.

The HQ app gives you the ability to turn on the RGB LED and change colors. It tells you the percent your battery is charged any gives you the temperature from the temperature sensor. I took my field Scout outside to see what the outside temperature was. Unfortunately it was raining so we had to put it in a plastic bag when sitting it out on the back porch. I don’t know how accurate the temperature was but it did change to a reasonable value. There are also controls for configuring the several I/O pins. There’s also a command line for sending for sending script commands. Here are some screen grabs showing the two scouts.

HQ control panel for the lead scout “Picard”

HQ control panel for field scout “Seven-of-Nine”

There are variety of script commands that you can use on the command line. Here is a link to the reference page.

The next thing I tried to do was use the Arduino IDE. You have to download a beta version because the current IDE does not support that chip. Again is a zip file rather than an installer. I already had the current production Arduino IDE installed on this machine. I took a chance and just copied the new files over the old ones. Apparently that was not the right thing to do because when I tried to compile an example sketch I get a “compiler error” with no error message whatsoever. I will probably go back and uninstall original Arduino IDE and delete all the files and try to reinstall the beta version from scratch. But that’s a task for tomorrow.

It’s going to be a steep learning curve to do anything really useful with this. Of course my ultimate goal is to port my IRLib and use it to make an “Internet-of-Things” infrared remote. Let’s going to take lots of time with data sheets and schematics. It looks like as powerful system but are not a long way to go in order to get it to do what I wanted to do.

Revised Remote-Controlled Remote-Control with Call Button

Posted on March 26, 2014 by cy

Imagine yourself being a severely disabled person lying in bed at night and needing assistance. It might be that you’re uncomfortable and need to roll over. Sometimes it’s just something annoying like a bug crawling across your arm. Other times it’s more serious such as a severe coughing spell, nausea, or potentially even a heart attack. A couple of months ago I woke up in the middle of the night with chest pains. I was 99% sure it was just a muscle cramp. I had had my back brace on a little bit crooked that day and I was pretty sure it was just the aftermath of that. But I wasn’t really sure that it was not a heart attack. I tried calling my dad who sleeps in his bedroom which is pretty far from my room. As both of us have gotten older, my lungs are weaker and his hearing is worse. I can usually yell and wake him up in 10 or 15 minutes. However some nights he sleeps very soundly and it’s not unusual for me to lie in bed awake for an hour or even two until he gets into a lighter sleep cycle and can hear me.

As I was lying there in bed wondering if I needed to be calling 911 or if I just needed a rubdown with some BenGay, I wished that I had some sort of a call buzzer that would alert him that I needed something. Years ago I had a call buzzer that we built out of parts from RadioShack. It was part of their home security line of products. There was an emergency call button that you would wire into their control boxes and that control box could in turn be hooked into an auto dialer. We really didn’t need a button to call 911. We just wired in a loud buzzer. We had one for me and one for my grandmother. The radio on the button was strong enough that she could trigger hers in her home next door and it would buzz here.

In 1990 my grandmother passed away and I was using the buzzer myself less and less. We ended up putting it away somewhere because it wasn’t as critical for me and typically if dad didn’t hear me my mom did. In recent years I’ve looked for that gadget all over the house. I’ve looked through closets and junk boxes and junk drawers and cannot find it. RadioShack no longer makes the kind of gadget that we used. Their newer home security systems do not seem to have something similar. I guess they expect you to buy some commercial home security system that is monitored. You know the famous “I’ve fallen and I can’t get up” type of gadget.

So anyway I’m lying there thinking it would be really nice if I had a button in my hand that would trigger a buzzer to wake up my dad. But wait… I did have the button in my hand. I had four of them in fact. Unfortunately all they would do would be to turn on my TV. No buzzers attached.

In previous articles I’ve talked about my “Remote-Controlled Remote-Control” project that I use to control my TV, cable box and DVD players while in my bed.

Sitting in my wheelchair I have no problems pushing buttons on a remote. I use a wooden stick in my mouth.

When sitting up in my wheelchair, I poke at the buttons of a traditional universal remote by using wooden stick in my mouth. But when I’m in bed, I don’t have sufficient dexterity to handle a bunch of buttons.

Arduino-based device with LCD menu sits atop my TV probably displaying an Adafruit “As Seen on Show & Tell” sticker.

Instead I have a system that uses a set of micro switches, universal remote, and the special electronic gadget that I built that sits on top of my TV. That gadget is based on an Arduino microcontroller. It has an LCD screen and an infrared receiver and transmitter. Below is a diagram of how down the original system worked. I have a set of four micro switches that I hold in my hand. They can be seen lying on the bed connected by wire to universal remote that is sitting on top my cable box. I would push the micro switch causing the universal remote to send an IR signal to the Arduino box on top of my TV. After selecting an item off of the menu the Arduino box would then send an IR signal back to the cable box. Note you can click on any of the images in this blog to see a larger version.

Original “Remote-Controlled Remote-Control” System

What I needed was an additional function to ring a buzzer. The problem is that infrared IR signals are just ordinary beams of light that happen to be of such a frequency below what the human eye can see. While it is possible to bounce the IR signals off of a shiny object or a light-colored wall, there’s no way that the signal was going to reach all the way to my dad’s room. That means we needed some sort of radio RF signal.

X-Bee Series 1 Radio

My microswitches were wired directly into a traditional universal remote. The box on top of my TV was designed by me and built by my dad and it was based on the Arduino series of microcontrollers. Lots of types of gadgets have been designed for use with these controllers. The most popular RF module is called an X-Bee radio.

I thought about adding an X-Bee to the Arduino on top of my TV, however to trigger it I would need to select that option from the LCD menu. However sometimes I sleep on my side and I could not see the menu. That meant that the X-Bee would have to somehow be connected to the microswitches directly. I concluded that I could build another Arduino gadget to replace the universal remote. The microswitches would wire into the new transmitter Arduino. It would send the IR signals to my set-top Arduino just like the remote did. But it would also have an X-Bee module that was sent RF signals to my dad’s room.

The X-Bee does have some digital input/output pins to which I could connect a buzzer directly. However I wasn’t really sure if it was going to be a buzzer perhaps something that would turn on a light or perhaps trigger an intercom. Since I wasn’t completely familiar with the capabilities of X-Bee and I do know a lot about Arduino I decided that the receiver in my dad’s room would also be an Arduino with an X-Bee connected to it.

Adafruit X-Bee Adapter

I went to my favorite electronics supplier Adafruit.com and ordered the following gadgets (2 each) an Arduino micro, an X-Bee adapter that makes it easy to connect a 3 volt X-Bee to a 5 volt Arduino, an X-Bee Series 1 radio module, a USB cable, a 5 volt USB power supply. I already had parts to make an IR transmitter. The only other item I needed was some prototyping boards and a 5 volt buzzer.

I had no previous experience with X-Bee. It’s a pretty powerful system that allows you to create a network mesh of transmitters and receivers. You can configure them as a master controller which can control either end nodes or routers. The routers can talk to the master controller and to end points. I had several online tutorials and an e-book that many of them talked about the newer X-Bee series 2 devices and I was using the older and slightly less expensive series 1. It was a pretty steep learning curve until I finally found an article that explains how to set up the simplest possible X-Bee network. Here is the link…

http://jeffskinnerbox.wordpress.com/2013/03/20/the-simplest-xbee-network/

The author explains that X-Bee is really just an ordinary serial modem. In fact the firmware recognizes escape sequences and text commands that are based on an old system used by Hayes Smart Modems. I remember the days when I had an old Hayes Smart Modem 300 sitting on top of my S-100 bus-based computer back in the early 1980s. By the way that “300” wasn’t just a model number… It meant that it communicated at 300 baud. That is approximately 300 bits per second. Today’s Internet traffic is not measured in hundreds of bits per second rather in megabits per second. That shows you how old this system is. Typically an X-Bee radio communicate that 9600 baud.

FTDI USB cable and X-Bee Radio with Adapter

Anyway you simply connect them to a USB port using an FTDI or an Arduino. Then you use a serial communication program to type text into the radio. Using the Hayes protocol you type “+++” with a pause before and after to get it into command mode. Then you type text commands beginning with the letters “AT” to configure various parameters. Once it is configured, anything that you type into one X-Bee gets transmitted and appears on the other radio. It’s like a little 2 man chat room.

There is a more advanced mode called API mode that allows you to send packets of digital data. But for my purposes all I needed to do was send one character of data that would be interpreted as “Ring the buzzer”.

I first prototyped everything on a breadboard to get it working. Then I had dad solder it all together neatly on a prototype board. Here is a photo of the receiver device that goes in my dad’s room. It consists of an Arduino Micro, an X-Bee radio sitting in the 5 V adapter board, and a buzzer.

Receiver module with buzzer

Here is a photo of the transmitter device that sits on top of cable box. It shows the sets of 4 micro switches next to it. The small board on top is an IR transmitter consisting of three transistors and 2 IR LEDs.

Transmitter with IR emitters and microswitches

Here is an illustration of how the system worked using the Arduino transmitter with X-Bee radio and IR transmitter in place of the universal remote.

Communication between Arduino devices

I spent several days tinkering with the timing of the system. I had to deal with de-bouncing the micro switches. I also had to deal with conflicts between the IR signals going back and forth between the two boxes. The signal going from the transmitter to the box on top of the TV show by the green arrow would interfere with the signal going from the LCD menu box back to the cable box shown with the blue arrow. The Ghostbusters were right “Don’t cross the streams!”. The original universal remote had been configured to only send a signal once even if you held down the button. I wanted to be able to hold the button to send repeat signals so that it would be easier to scroll through the on-screen channel guide for example. But as the transmitter box with send a second signal, the LCD box would be trying to talk to the cable box and it would get confused.

One of the problems was that the transmitter was too intense. Those double LEDs each with their own driving transistor were putting out too much power. IR receivers have something called an automatic gain control or AGC. They automatically adjust to the amount of infrared light coming in. My ultrabright transmitter was bouncing off of the TV and other objects in the room and temporarily “blinding” the AGC on the IR receiver of the cable box. I ended up putting a piece of tape over one of the LEDs and that helped my timing issues a little bit. While I was able to get it working as well as the old system, I still couldn’t get the timing right to be able to hold the buttons for a continuous stream of pulses for scrolling through on-screen menus.

On the other hand the call buzzer worked pretty well. The first couple of nights that I tried it, my dad was able to hear the buzzer and come and roll me over or do whatever else I needed. I programmed the transmitter Arduino to only trigger the buzzer if I held down 2 buttons simultaneously for a duration of five seconds or more. That way I wouldn’t accidentally set off the buzzer while trying to change channels or do some other function on the TV. Also it meant that I did not need to add any additional buttons.

Completed buzzer with cone.

However a few nights later, dad was in a deeper sleep than he had been during the initial tests and did not hear the buzzer. I was going to go looking for a new buzzer that was perhaps louder. I had also considered adding a relay to the receiving Arduino that would perhaps turn on a lamp in his bedroom. But my dad had a better idea. He noticed that the sound coming from the buzzer was a bit directional. Since he is a retired sheet metal worker he naturally thinks of solutions that involve making things out of metal so that is what he did. He created a little metal cone that he fitted atop the buzzer using a little plumbing elbow. Here is a photo of the modified device and the little plastic box that he used for an enclosure. So far this modified device is working really well.

X-Bee mounted atop LCD menu box

I still was not happy with my timing problems on the transmitter. I realized that I could avoid the IR interference if I added an X-Bee to the LCD box on top of my TV. Then we would have an RF signal going from my transmitter box to the LCD box and it would not interfere with the IR signal going from the LCD box to my cable box and DVD etc. I ordered another X-Bee and X-Bee adapter from Adafruit and it arrived in few days. We mounted it on top of the LCD box and wired it into the Arduino inside. Here’s what it looks like now.

We cut away the IR transmitter board from the transmitter Arduino and removed it. We then mounted the device in a plastic box. The boxes we were using were boxes that originally contained a deck of cards. It turns out they are just the right size for the Adafruit half-size prototyping board.

Completed transmitter with IR board removed

Completed transmitter painted black and sitting atop cable box

I eventually painted my box completely black because I didn’t like all the blinking LEDs lighting up my room at night. There is a green power LED and a red transmit LED on the X-Bee adapter and there is a bright blue power LED on the Arduino Micro.

Here is an illustration of how the new system works.

Communication between boxes in final version

The X-Bee on the transmitter box sends RF signals to my dad’s bedroom and to the LCD box on top of the TV. That signal is shown by the magenta arrows. The LCD box then transmits IR signal back to the cable box shown in blue arrows. There is of course no interference between IR and RF so I don’t have to build in the special delays. I can pump the buttons as quickly as I want to or hold the button in and let the software pump the signal for me at whatever rate I want. It works wonderfully.

I mentioned earlier that X-Bee was capable of creating complicated networks with master controllers, routers, and in points. Was a bit worried I was going to have to learn how to do all that once I had added the third radio. As it turns out the simple system of everyone-talks-to-everyone works just as well with more than two radios. Therefore the same RF signal in the same data goes from the transmitter box to my dad’s receiver buzzer and to my LCD box. The data I am sending is just a single text character. If it sends a “^” character then the buzzer goes off. If it sends a “U”, “D”, “L”, “R”, or “S” character than it tells the menu box to move the cursor up, down, left, right, or select. Actually I do not have an up microswitch in the system. It’s easier to get by with just 4 buttons. The menu wraps around and sue if I need to go up, I just go down several steps.

The whole thing is working really well. I demonstrated my original “remote-controlled remote-control” on the weekly Adafruit Show-and-Tell videoconference on Google+ Hangouts over a year ago when I first created it. Here is a link to that blog entry which contains the video demonstration. A few weeks ago I also demonstrated on the Show-and-Tell the initial X-Bee system that did not include the third radio. Below is the YouTube video of that Show-and-Tell.
Part of the segment begins about 8:30 into the video. I will probably do a follow-up demonstration of three radio system.

Here’s a list of the parts used with links to Adafruit.com

Arduino Micro with headers
X-Bee Series 1 module
Adafruit X-Bee adapter board
Breadboard friendly 5 V buzzer
FTDI Friend or FTDI USB cable
Adafruit half-size prototyping boards
USB micro cable
5 V USB power supply

And in case you’re wondering, I never did figure out if it was a heart attack or not. I tried calling my dad for over an hour that night until I finally got him to wake up. By that time the pain was gone. I’m pretty sure it was just a muscle cramp. Next time I’m prepared!

New Software for Analyzing IR Signals

Posted on November 19, 2013 by cy

It was my pleasure to be an Indigogo supporter and beta tester of the new software solution for analyzing infrared signals using Arduino, Raspberry Pi and other controllers. It is a Windows application called AnalysIR. Software is now available for the general public here http://www.analysir.com/blog/

One of the nicest features of this system is that it allows you to use and IR learner chip to directly decode raw IR signals rather than using a decoder bandpass filter and AGC style chip that I normally recommend for my projects. This is essential if you do not know the base frequency of an unknown protocol.

The Arduino portion of their software is freely distributable at some point I will be adding something to my IRLib library for Arduino that will allow you to do frequency analysis. But no matter what I come up with it’s not going to be as useful as this full-featured package which is now available at a reasonable price considering the effort they’ve put into it.

I’ve had many requests for output of IR signals in different formats such as ProntoHEX that I’ve not yet been able to implement in my code. However this software easily outputs that format.

I highly recommend you check out the software.

IRLib Tutorial part 4: IR Remote Mouse

Posted on June 10, 2013 by cy

Click this logo to see my Adafruit Show-and-Tell presentation June 22, 2013

The reason I got into working with Arduino and IR remotes was to create adaptive technology for disabled people like myself. After building a specialized TV remote, the next project I tackled was to create an IR remote controlled mouse and keyboard emulator that allows me to use my IR remote to move the mouse, the arrow keys, and even type complete messages using a full keyboard.

First I would like to share with you some background as to why I created this device and then we will show you how to make a simplified version of this IR remote mouse that would be useful to anyone who uses a computer… not just someone with a disability.

My Dragon Isn’t Draggin’ Very Well

Normally I control my computer using dictation software known as Dragon NaturallySpeaking however there are some things which Dragon does not do well. Ironically a program called “Dragon” isn’t very good at draggin’ the mouse. There are mouse control commands but they are sometimes difficult to use. Also it is very difficult to use control click, shift click and (although I’ve never had to) alt click. I also have a graphics program which occasionally requires you to drag the mouse holding the right button. To my knowledge there’s no way to do that with Dragon. I also have an app on my iPod touch which allows me to wirelessly control the mouse. However it has even fewer dragging capabilities than Dragon. And there are just times when Dragon gets locked up for some reason and doesn’t work. I needed an alternative way to access my computer when something goes wrong with my usual methods. So creating an Arduino-based IR controlled mouse has been a real godsend.

Okay you’re thinking “Come on Chris isn’t it a little bit egotistical to call a device you designed a godsend?” But it really has been a blessing that such technology is available for me to create this device. When I first came up with the idea for it I was going to have to use a Arduino Uno. But it isn’t very well suited to doing mouse and keyboard emulation. You have to use an ISP to reprogram the USB controller and then you have to use an ISP to upload sketches. I had done Google searches to learn how to do it and it wasn’t going to be fun. There were some libraries available but I thought it was going to be a pretty steep learning curve about USB protocols in order to write the code to make this happen. I was still very new working with Arduino and I wasn’t looking forward to getting into something that complicated.

Arduino Leonardo

Leonardo to the Rescue

Finally one day I did one last Google search on “how to emulate a mouse using an Arduino” and up popped something new! A new kind of Arduino called “Arduino Leonardo“. It was designed specifically for this purpose to be able to do mouse and keyboard commands. It has all of the necessary libraries built in. I could use the device as a mouse or keyboard and I could still upload sketches directly through the USB port using the traditional Arduino IDE. It literally brought tears to my eyes when I realized that what I feared was going to be unbelievably difficult was now going to be almost trivially easy. I immediately went to the Adafruit website and ordered a brand-new Arduino Leonardo and other necessary parts to build the device shown below. Inside the box is a Leonardo, and IR receiver, and a 20 character by 4 line LCD text display and then I2C backpack for controlling the display. Here is an image of what I built and use every day.

My Leonardo-based Mouse and Keyboard Emulator

Mouse Mode Display

The device had three modes of operation. In mouse mode you could move the mouse up, down, left, right and all 4 diagonal directions. You could left click, right-click, scroll wheel and you can also left drag or right drag. You can also toggle the control, shift, or alt keys by pushing a particular button. The display on mouse mode really didn’t tell you much except for the status of the control, shift, or alt keys and the speed at which you move the mouse. The “lr” changes to “Lr” or “lR” if you are dragging with the left or right buttons respectively. The “sca” change to uppercase if you are toggling the Shift, Control, or Alt keys respectively. The other strings of text shown on the screen are some universal keyboard commands that work in mouse or arrow modes. They are only on the screen to remind me which buttons do which functions. For example the text “Pl=^V” reminds me that the “Play” button on the remote sends a “ctrl-v” which is the same as a “Paste” function.

Arrow Mode Display

In arrow key mode the arrows on the TV remote don’t move the mouse, they move the arrow keys. This has been an especially useful feature for me when selecting large numbers of files in Windows Explorer. To do it with voice control I would select the first file an attempt to say the phrase “press shift down” dozens of times to select a bunch of files. If you accidentally mispronounce that phrase or if it misunderstands you it can do something completely different and you have to start over. This image shows arrow mode which again doesn’t really show you much except the status of the control, shift, alt keys and the reminders of other program keys.

Finally there is a full keyboard mode and that is the reason we needed the 20×4 character LCD display. In this mode there is a blinking cursor that you move around on the screen and when you get to the key that you wish to press you hit the select button on the remote and it types that key. It can type any key that is normally available from a standard PC keyboard including function keys and any combination of control, shift, and alt keys. This was really more of a proof-of-concept than a practical application but there have been times when everything else on my PC was locked up and I could type commands using this mode. I even plugged this device into my Raspberry Pi when doing the initial configuration although it was a bit tricky to type in the passwords before the session timed out. Here is an image of keyboard mode.

Keyboard Mode Display

Here is a YouTube video that I created for the weekly Adafruit Google+ Hangout Show-and-Tell where I demonstrate the various uses of my device. Unfortunately technical difficulties prevented me from showing this video on the live chat however you can see the video below and you can also click on the Show-and-Tell icon on the left to see the actual Google+ Hangout where I attempted unsuccessfully to show the video.

Sometimes Smaller is Better

Recently I purchased a new Windows 8 laptop from Dell. I knew I needed to make another IR mouse but I didn’t want something as big and bulky as a full-size Leonardo and a 20×4 character display. I really didn’t need the keyboard mode. It was more just a proof-of-concept. I really only needed mouse and arrow key mode. I thought perhaps I could get by with just a few indicator LEDs to let me know if I was dragging the mouse or if the control, alt, or shift toggles were on.

Fortunately the technology has improved yet again since I built my first mouse and keyboard emulator. There is an even smaller Arduino available known as the Arduino Micro. It was designed by our friends at Adafruit Industries. It uses the same ATmega32u4 chip that the Arduino Leonardo uses. It is essentially a miniature Leonardo and it can also be used as a mouse and keyboard emulator. Here’s what it looks like…

Arduino Micro: a mini Leonardo

Adafruit RGB LED NeoPixels

I still needed some sort of indicators to show me if I was holding down the shift, control, or alt and if I was dragging with the left or right mouse button. I would also need an indication if I was in mouse mode or arrow mode. This was a total of six indicators. Rather than wire up six individual multicolored LEDs complete with current limiting resistors and to take up six output pins, I decided to use two of these tiny Adafruit NeoPixel RGB LEDs. You can string dozens of them together and control them all with a single control wire. Add the +5v and ground wires and thus you only need three wires for an entire strand. The driver chip in each pixel controls the current so you don’t need to add resistors or anything. Since they are RGB I decided I can get by with just two of them. The wiring diagram below shows two of the pixels and an IR receiver wired into the back side of the Arduino Micro.

Wiring Diagram for IR Mouse

I placed a piece of double stick tape on the backside of the Micro and stuck the IR receiver and pixels onto the back of it. Arranging the parts in this particular way made it very easy to wire up the circuit. Here is an image of the completed device.

Completed Project

At some point I will probably cover the exposed wires with some hot glue or perhaps encase the entire device in some Sugru putty. I will need to maintain access to the six pins on the front side in case I ever want to rewrite the boot loader and access to the reset button might be necessary.

This new miniaturized person of my IR mouse not only helps me with my computer in light of my disability but it could be a useful gadget for anyone to use. Although you can purchase IR mouse controllers from a variety of sources, it’s always more fun to build your own and you can custom program in additional features not available in the commercially available products. For example if you are controlling a PowerPoint presentation on a projection monitor you might want to be free to move around the room while talking and using a small IR remote to click on the next image or do various other functions.

You can use any IR remote control such as a TV, DVD etc. to control the mouse as long as it uses a protocol that IRLib can understand. For this tutorial we are going to use a mini remote from Adafruit. It has 21 buttons and uses the NEC protocol. It’s small pocket-sized would make it ideal for controlling a PowerPoint presentation. Here is what the remote looks like

Adafruit Mini Remote

Programming the Commands

That takes care of the hardware. Now we need to write some software. We have 21 buttons available on this remote. Obviously we want to assign the mouse directions to the four arrow buttons. The four buttons diagonally from these arrows are an obvious choice for moving the mouse diagonally. And in arrow mode those corner buttons are obviously a good choice to assign the Home, End, Page Up, and Page Down functions. Among the other mouse functions are left and right click, left and right drag, faster or slower mouse movements, and scroll wheel up and down. Other arrow mode functions will include Backspace, Space, Escape, Tab, and a GUI key such as the Windows key. You can modify the program to put any command in any of these slots. This is just a suggestion.

Several of the buttons operate identically in either mouse or arrow mode. The top row of buttons toggle the Alt, Control, and Shift keys. The “Mode” button toggles between mouse mode and arrow mode. The “Release” button releases all held mouse buttons and toggle keys. Here is a graphic which shows which of the buttons on the remote performed which functions in either mouse mode or arrow mode.

Assigning Commands to Buttons

One of the RGB pixels will show red, green, or blue if the Alt, Control, or Shift toggles are on. The other pixel shows blue when the left mouse button is dragging and read when the right mouse button is dragging. It shows green when you are in arrow mode.

The NEC protocol we are using sends a special code of 0xffffffff as a repeat code whenever you hold down a button. In order to process this we will always store any received codes so when we receive the repeat code we know what function to repeat. However the toggle keys should not be repeated without lifting off of the button so we have zeroed out the previous code when pressing one of those toggles.

Here is a complete listing of the code.
/* Example program for from IRLib – an Arduino library for infrared encoding and decoding * Version 1.1 April 2013 by Chris Young http://tech.cyborg5.com * "IRmouse" Control a PCs mouse or arrow keys using an IR remote */ #include #include #include //The IR codes shown below are for the Adafruit mini remote //which uses an easy protocol. The comments after each code refer to the buttons //on that remote and not to their actual function on this device.


//Codes used by both mouse and arrow modes

#define CodeAlt   0xfd00ff //Vol-

#define CodeCtrl 0xfd807f //Play/Pause

#define CodeShift 0xfd40bf //Vol+

#define CodeRls   0xfda857 //5

#define CodeMode 0xfd9867 //8
//Used by mouse and arrow but have different meanings

#define CodeUp 0xfda05f //Up arrow

#define CodeDown 0xfdb04f //Down arrow

#define CodeLeft 0xfd10ef //Left arrow

#define CodeRight 0xfd50af //Right arrow
//Used only in mouse mode

#define CodeUpLf 0xfd20df //Set up

#define CodeUpRt 0xfd609f //Stop/mode

#define CodeLfClk 0xfd906f //Enter/save

#define CodeDnLf 0xfd30cf //0 10+

#define CodeDnRt 0xfd708f //Repeat

#define CodeLfDrag 0xfd08f7 //1

#define CodeRtDrag 0xfd8877 //2

#define CodeRtClk 0xfd48b7 //3

#define CodeFaster  0xfd28d7 //4

#define CodeScrUp 0xfd6897 //6

#define CodeSlower 0xfd18e7 //7

#define CodeScrDn 0xfd58a7 //9
//Arrow mode only

#define CodeHome 0xfd20df //Set up

#define CodePgUp 0xfd609f //Stop/mode

#define CodeEnter 0xfd906f //Enter/save

#define CodeEnd 0xfd30cf //0 10+

#define CodePgDn 0xfd708f //Repeat

#define CodeGUI 0xfd08f7 //1

#define CodeInsert 0xfd8877 //2

#define CodeDelete 0xfd48b7 //3

#define CodeBkSp 0xfd28d7 //4

#define CodeSpace 0xfd6897 //6

#define CodeEsc 0xfd18e7 //7

#define CodeTab 0xfd58a7 //9
#define Bright  16  //brightness of pixels
#define MOUSE_MODE 0

#define ARROW_MODE 1

#define MAX_MODE (ARROW_MODE+1)
#define MOUSE_LED 0

#define SHIFT_LED 1
Adafruit_NeoPixel strip = Adafruit_NeoPixel(2, 6, NEO_GRB + NEO_KHZ800);//Output pin 6

IRrecv My_Receiver(11);  //Input pin 11

IRdecodeNEC My_Decoder;
int Speed;

int Current_Mode;

char Control_State;

char Shift_State;

char Alt_State;

long Previous;

uint32_t Shift_Status, Mouse_Status;
void UpdateStatus () {

  Mouse_Status=0;

  Shift_Status=0;

  strip.setPixelColor(MOUSE_LED,Bright*Mouse.isPressed(MOUSE_LEFT),Bright*Current_Mode,Bright*Mouse.isPressed(MOUSE_RIGHT));

  strip.setPixelColor(SHIFT_LED,Bright*Alt_State,Bright*Control_State,Bright*Shift_State);

  strip.show();

};

//This Change_Mode routine is overly complex but it's a holdover from earlier code

//where I had three modes instead of two. Note we do not want to repeat feature

//on this function or on the toggle functions so we set Previous=0

void Change_Mode () {

  Current_Mode=(++Current_Mode) % MAX_MODE;

  Previous=0;   UpdateStatus(); delay(500);

};
void setup() {

  strip.begin();    strip.show();

  Shift_Status=0;   Mouse_Status=0;

  My_Receiver.enableIRIn(); // Start the receiver

  Current_Mode=0;

  Control_State=0; Shift_State=0; Alt_State=0;

  Speed=8;  Previous=0;   UpdateStatus();

  Mouse.begin();

}
void Toggle_Mouse(int Button) {

  if(Mouse.isPressed(Button)) Mouse.release(Button);

  else Mouse.press(Button);

  Previous=0; UpdateStatus();  delay(500);

}
void Mouse_Mode() {

  switch (My_Decoder.value) {

  case CodeLeft:       Mouse.move(-Speed,0,0);     break;

  case CodeRight:      Mouse.move( Speed,0,0);     break;

  case CodeUp:         Mouse.move(0,-Speed,0);     break;

  case CodeDown:       Mouse.move(0, Speed,0);     break;

  case CodeUpRt:       Mouse.move( Speed,-Speed,0);     break;

  case CodeUpLf:       Mouse.move(-Speed,-Speed,0);     break;

  case CodeDnLf:       Mouse.move(-Speed, Speed,0);     break;

  case CodeDnRt:       Mouse.move( Speed, Speed,0);     break;

  case CodeLfClk:      Mouse.release(MOUSE_LEFT);  Mouse.click(MOUSE_LEFT); delay(400);break;

  case CodeRtClk:      Mouse.release(MOUSE_RIGHT);  Mouse.click(MOUSE_RIGHT); delay(400);break;

  case CodeLfDrag:     Toggle_Mouse(MOUSE_LEFT);     break;

  case CodeRtDrag:     Toggle_Mouse(MOUSE_RIGHT);     break;

  case CodeFaster:     Speed=min(30,++Speed); delay(100); break;

  case CodeSlower:     Speed=max(1,--Speed); delay(100); break;

  case CodeScrUp:      Mouse.move(0,0,1); delay(100);    break;

  case CodeScrDn:      Mouse.move(0,0,-1); delay(100);     break;

  };

};
void Toggle_Key(char *Toggle,char Key) {

  if(*Toggle){

    Keyboard.release(Key);  *Toggle=0;

  }

  else{

    Keyboard.press(Key);    *Toggle=1;

  };

  Previous=0; UpdateStatus(); delay(500);

};

//Releases all held mouse buttons and toggle keys

void Release_All() {

  Keyboard.releaseAll();

  Mouse.release(MOUSE_LEFT);   Mouse.release(MOUSE_RIGHT);   Mouse.release(MOUSE_MIDDLE);

  Alt_State=0;   Control_State=0;   Shift_State=0;

  UpdateStatus();

};

//In my experience some keys work better if you put a little extra delay.

void Key_Press (char Key,int D) {

  Keyboard.write(Key);   delay(150+D);

}

void Arrow_Mode() { switch (My_Decoder.value) { case CodeLeft: Key_Press(KEY_LEFT_ARROW,0); break; case CodeRight: Key_Press(KEY_RIGHT_ARROW,0); break; case CodeUp: Key_Press(KEY_UP_ARROW,0); break; case CodeDown: Key_Press(KEY_DOWN_ARROW,0); break; case CodeInsert: Key_Press(KEY_INSERT,0); break; case CodeEnter: Key_Press(KEY_RETURN,100); break; case CodeBkSp: Key_Press(KEY_BACKSPACE,100); break; case CodePgUp: Key_Press(KEY_PAGE_UP,200); break; case CodePgDn: Key_Press(KEY_PAGE_DOWN,200); break; case CodeHome: Key_Press(KEY_HOME,0); break; case CodeEnd: Key_Press(KEY_END,0); break; case CodeGUI: Key_Press(KEY_LEFT_GUI, 100); break; case CodeSpace: Key_Press(32, 100); break;//ASCII space case CodeEsc: Key_Press(KEY_ESC, 100); break; case CodeTab: Key_Press(KEY_TAB, 100); break; }; }; /* //You can uncomment and use this routine to send control characters such as //control-z for an undo button or control-c for copy etc. void Send_Control(char Key,int D) { Release_All(); Keyboard.press(KEY_LEFT_CTRL); Keyboard.write(Key); Release_All();delay(150+D); Update (); } */ void loop() { if (My_Receiver.GetResults(&My_Decoder)) { My_Decoder.decode(); //Adafruit remote uses NEC protocol which sends a special repeat code //if you are holding down the same button. We store each received code //in "Previous" so that we can properly handle repeat codes. if(My_Decoder.value==0xffffffff) My_Decoder.value=Previous; else Previous=My_Decoder.value; switch(Current_Mode) { case MOUSE_MODE: Mouse_Mode(); break; case ARROW_MODE: Arrow_Mode(); break; } switch (My_Decoder.value) { case CodeMode: Change_Mode(); break; case CodeAlt: Toggle_Key(&Alt_State,KEY_LEFT_ALT); break; case CodeShift: Toggle_Key(&Shift_State,KEY_LEFT_SHIFT); break; case CodeCtrl: Toggle_Key(&Control_State,KEY_LEFT_CTRL); break; case CodeRls: Release_All(); break; }; My_Receiver.resume(); } }
For reference purposes here’s a link to the documentation on the keyboard and mouse libraries for use with Leonardo or other comparable Arduinos.
http://arduino.cc/en/Reference/MouseKeyboard

You will also need the special library for Adafruit RGB NeoPixels which can be downloaded from GitHub.
https://github.com/adafruit/Adafruit_NeoPixel

Simply download and unzip the library into your library folder.

Note that the latest Arduino IDE (version 1.0.5 as I write this) lists the Arduino Micro as one of the boards it supports. When using either the Leonardo or Micro you will need a special driver for Windows computers. This driver is available in the driver’s library of the latest Arduino IDE. The latest drivers combine drivers for all of the supported boards into a single Windows 8 compatible signs package.

Simply plug the Arduino Micro into the USB port, upload the sketch, and then point your remote at the receiver. The device initializes into mouse mode so you should be able to move the mouse around using the arrow keys. Try switching to arrow mode using the “Mode” button. Go back to mouse mode and try pressing the faster or slower buttons. You won’t notice anything while pressing them however subsequent mouse movements will be faster or slower.

Here are links to the hardware mentioned in this tutorial:

Arduino Micro Adafruit or RadioShack
RGB LED NeoPixels Adafruit
38kHz IR receiver module Adafruit or RadioShack
Mini IR Remote Control Adafruit

Here are links to hardware used in the original IR mouse and keyboard emulator. At some point I will clean up the code on that project and publish it. If you have an immediate use for such a device, feel free to contact me and I will give you what I have but for now it’s not really fit for public consumption.

Arduino Leonardo Adafruit
20×4 LCD Character Display Adafruit
I2C/SPI character LCD backpack Adafruit
Small Plastic Project Enclosure Adafruit

IRLib Tutorial part 3: Overview Sending IR Codes

Posted on May 30, 2013 by cy

Part 3 of this tutorial is so big we have spread it over 4 installments. This blog post is just to pull all of those post together in a single location.

Part 3a: Sending IR Codes
In this segment we create a small Arduino sketch that allows you to type IR codes into the serial monitor and have them transmitted by your IR LED.

Part 3b: Creating a Virtual Remote Using Python
In the segment we use a Python script on a PC or Raspberry Pi to communicate over the serial port with the Arduino. By clicking on the virtual buttons on the PC, the Python script transmits the codes to the Arduino which in turn translates into your device by your IR LED.

Part 3c: Python, PySerial and PyGame Installation on Windows
Because Python and the other tools for creating the Virtual Remote may not be on your system, we have included this extra tutorial on how to install the necessary software on a Windows PC. While it isn’t technically connected to IRLib, we thought it would be useful to a variety of people not just users of our library.

Part 3d: Installing the Arduino IDE on a Raspberry Pi
Again this is not strictly related to IRLib but if you want to run the Part 3b example on a Raspberry Pi you will need to install the Arduino IDE. General users of Arduino and Raspberry Pi might be interested in this even if they do not use our libraries. If you do not use a Raspberry Pi then you do not need this part of the tutorial.

CY's Tech Talk

How I Use Technology and Articles of Interest about Technology

Category Archives: IRLib