Category Archives: Product Reviews

Ahead of My Time

As I take more responsibility over the web services within our department, I’m trying to be more standard in its development and maintenance, including its documentation. While learning how to correctly implement Swagger pages for our services (and, yes, I know, I’m late to the party), I stumbled upon this particular wonderful little feature: interactive documentation!

A couple of years ago, I wrote a piece how documentation should be more interactive, since that would ultimately result in a more effective tool to teach people about anything (an API, a programming method, etc.). Now, since it was actually introduced years before I wrote that piece, you can say that I’m actually behind my time. I’ll accept either. Even though it’s a more basic version of the idea presented in my post, it’s still cool that there’s some work being done in that direction. Much-belated kudos to the Swagger team!


And the Search for (Inexpensive) Indoor Navigation Goes On

So, as for the waiting addressed in the last post (i.e., the latest about the Haunted House saga), it ended when the next package of beacons finally reached my house. Almost immediately upon arrival, I registered the beacons using my Estimote account, and now having a total accumulation of six beacons, I placed them around my home and started the Indoor Location app on my iPad. As excited as Ralpie Parker with his BB gun in A Christmas Story, I started the app and followed the tutorial. “Okay, now I just need to create a location with the ‘Add new location’ button…where is that button…” After a minute of being unable to find it, I looked online and found nothing to assist me, feeling a little like a newb for not being able to resolve my problem.

Defeated (and now feeling more like Ralphie when he shot his eye out), I sent an email to Estimote so that they could enlighten me. Now, they did respond quickly with an explanation…but it wasn’t exactly the one that I had wanted to hear. It seems that the iPad could only navigate an indoor location with their app; if you wanted to setup a location with their app, you needed to have an iPhone. “Say what?” Yes, you’ll want to navigate a location using an iPad’s wide display, but you’ll have to create the location with the phone. It is, for the most part, a two-device solution. (My only guess is that the Bluetooth capability of the phone is more powerful than the pad.) Of course, one can imagine how happy that answer made me, but in fairness to Estimote, they empathized with my plight by refunding the cost of the beacons to me. Still, I would recommend that they explain the hardware requirements in flashing red letters on their site for future customers, since that might be something of interest to them before making a purchase.

So, back on the hunt I went. I was definitely finished with looking for a hardware-specific solution, and after looking around a bit more, I found a compelling product that needed no peripheral hardware at all: Indoor Atlas (i.e., IA). Interestingly, their solution did not need beacons since instead of using Bluetooth or GPS, it relies mainly on the electromagnetic fields that exist within the confines of a building. Based on my limited time spent reading (i.e., scanning every other word) and as I understand it, it seems that each room has an unique signature in terms of its EM field, and if you walk around your appartment with scattered waypoints, it can create a traversal graph based on your walk, with the unique EM fields being nodes. (If some WiFi is available on the premises, that can be of some help as well.) And all you need is your phone and nothing else. Cool! Even though I’d been let down so many times before, I got excited once again, and I downloaded their Map Creator app in order to get crackin’.

So, creating a map went fairly smoothly, with me walking from waypoint to waypoint in order to exhaust all permutations of possible navigation. In fact, as you create all possible edges between vertices in this messy graph, the app shows you its estimation of where you are, and with each new edge, it does seem to get smarter. Once I was done with my walkthroughs, I uploaded the data from the MapCreator app to my Indoor Atlas account, and I proceeded to generate a map of my place. The only question was: how can I use it? With Estimote, they had an app to showcase their tech, so that you could watch it in action before writing one line to call their API…but not so with IA, it appears. Basically, if you want to navigate your generated map, you’re going to need to get dirty: create your own app and access the map through the Indoor Atlas API. Since IA supports both Android and iOS, I was hoping for some sort of Xamarin solution…but, unlike Estimote again, no dice. It looks like I’ll be blowing the dust off my buddy’s aging MacBook in order to see what I can cook up on my own.

Initial Estimations of Estimote

So, in my last post about the Haunted House saga, I had finally found a product that offered me hope when it came to a technical foundation for creating and tracking objects in a very local space. (Just the thought of pouring over books about math and Bluetooth hardware gave me a headache.) So, with joy, I started to read about the services offered by Estimote. Basically, they supplied both IoT devices (i.e., beacons) and a SDK that enabled you to detect their beacons (which you would deploy yourself around a space). That was interesting by itself…but then I found the mother lode: their Indoor SDK package. Basically, with that SDK, they provided the software that created a 3-dimensional model in your app…and helped you track someone/something in it! And their platform was available for both iOS and Android…and Xamarin had even created components for both platforms! Oh Mommy!

Since their business office is here in New York, I got the opportunity to have coffee with one of their sales people, and he was kind enough to offer me a discount on my initial purchase. Excited, I bought a kit of 3 location beacons, and once they arrived, I set them up using their online tutorial and downloaded some of those Xamarin Android projects. (When you create your online account, you can change your beacons’ settings through your account, and then the Estimote app on your phone pushes those settings onto the beacons from the cloud.) First, though, I started by playing with the Estimote app (in order to confirm my beacons were working properly), and even though the app did notify me when I had approached one of my beacons, it seemed to have a hard time with estimating distance…and it seemed to think that I was moving when I wasn’t. Nonetheless, it was working, and I was building a prototype for a game, not a rocket! So, with some positive results as fuel, I dove into their Xamarin projects with more simple functionality, like notifications. I got mixed results, but again, I was prepared to get my hands dirty if needed. Indoor SDK, here I come! Oh, wait a minute…something is not right…I need 4 of these beacons that are sold in packs of 3? And the Indoor SDK is only available on iOS??? Grumble, grumble, grumble… Well, kids, take this lesson to heart: always read the fine print first before you get too excited.

Of course, when I thought about it, it made perfect sense: Android hardware is too varied in quality and specification to write accurate libraries for all of them. I get it..So, at this point, I asked myself the simple question: do I call it quits here? Uhhh…is my name Quitter McQuitFace? Exactly. So, I went ahead and ordered another pack of 3 beacons, bought a refurbished iPad, and arranged to get an old MacBook loaner from a friend. While waiting for my next beacon package to arrive, I’ve played with some of their more fundamental iOS code samples, since it would be a while before I would get to play with the samples for the Indoor SDK. Again, as I noticed when initially playing with the Estimote app, some of my results were anomolous. For example, when playing with a notifications sample deployed to the iPad, I seemed to receive inconsistent alerts when approaching or leaving a beacon’s domain; in fact, at times, it seemed to tell me that I was approaching a beacon when I had walked away from it! Hmmmm…I’m slightly concerned, but my curiosity and optimism is too high to be knocked down. Now, in order to get to the good stuff (i.e., the Indoor SDK), I just need those extra beacons. “Oh, and the waiting is the hardest part…”

Windows IoT Kit: Further Impressions

After the initial session of completing the setup and then succeeding with the first tutorial, I sat down and played with the other sample projects. (Well…all of them except for the photometer project. All of that wiring looked like a headache to me.) For the most part, the tutorials were very easy to follow, and they did a good job of teaching additional basics about peripheral programming with the Raspberry Pi.

On top of learning that the async and await keywords will become the peanut butter and jelly of the future in C#, I became aware of how easily one can leverage the power of certain namespaces, like System.Speech.Synthesizer. (I still marvel how APIs have become increasingly better over the decades, especially in terms of usage difficulty and general organization. If this standard of being easy has truly become prevalent, I’m now more inclined than ever to try some of Microsoft’s other new bold APIs and frameworks, like Cognitive Services and Bot Builder.)

My only complaint about the projects was that some of their results weren’t accurate. For example, the barometer project reported my sea level to be -50m…and though I would love to party with Aquaman, I’m afraid that isn’t the case. In another example, the RGB project reported a vivid red color as purple, along with other mistaken identities. After looking at a few of the calculations in both projects, everything seems fine…and since the kit was economically appropriate, my guess would be the hardware itself as the cause of any inaccuracies. All in all, though, I enjoyed my time with the kit.

So, feeling a bit more confident with the help of this kit, I think that it’s time to start applying my meager knowledge base towards a Haunted House. So, what should be my first prototype? Since a big part of the general design involves proximity detection, I think that my first step should be the creation of a process on the Raspberry Pi that uses a Bluetooth USB dongle to:

  1. Poll all phones with their Bluetooth receiver opened
  2. Measure their signal strength and then estimate their distance
  3. Report the Device ID and estimated distance to a listening Web service, which will write the info to a database table

At first, such a feat seemed a little daunting…but with a little assistance from Microsoft, embedded savants, and friendly helpers on Instructables, there seems to be a little light at the end of the “spooky” tunnel. 🙂 Hopefully, in terms of attainability, that project will turn out to be a pleasant surprise. I have my fingers crossed.

Windows IoT Kit: Initial Impressions

Okay, it’s true that I’m a little late to Adafruit’s Windows IoT Pack party…but, hey, better late than never, right? So, as stated previously, I set out to create a prototype that would give me the chance to try integrating Windows IoT and Azure. In the spirit of keeping things simple, I just wanted to run a program on the Raspberry Pi (powered by Windows 10 IoT Core) that would poll an Azure web service and react appropriately. Sounds fairly simple, right? Well, for an old dog like me, it took a little longer than expected; in fact, it took the better part of an afternoon.

So, the steps required were:

  1. Create a SQL Server database within my Azure account, with a test table
  2. Create an Azure web service and deploy it to my Azure account
  3. Assemble the Raspberry Pi 2 (i.e., RP2) and the circuit (along with the LED light) for the Blinky project
  4. Run the Windows IoT dashboard and connect to the running RP2
  5. Download the Blink project and modify the code so that the pulsing of the LED light would be determined by the results of a call to the Azure web service
  6. Run a debugged instance of the Blinky project on the RP2 through VS 2015

The first two were easy enough. (In fact, since the Azure Management Portal was redesigned from last year, it’s become even easier than I remembered.) When it came to assembling the RP2 circuit, things started off a little awkward, but after a few moments to recollect faint memories of my EE classes, the circuit finally clicked into place.

However, it started to become a little more difficult when I got to Item #4 and attempted to use the Windows IoT dashboard. First, the RP2 would fluctuate between showing up on the devices list and disappearing from it. (Since the WiFi dongle and the Ethernet cord connected my laptop to the device, connectivity couldn’t have been the issue.) When it did appear, it appeared as a mysterious “minwinpc” device…which, as it turned out, was my RP2. Momentarily, I saw it mentioned as a device with “AJ_” as a prefix, and I learned through further investigation that it’ll assign such a name for you. During one of those fleeting appearances, I recorded the IP address for the RP2 and bookmarked the link that goes to its Management Portal page on the RP2. If I were you, I’d quickly do the same before it disappears (as it is wont to do). The Portal page provides general administration of the device (renaming the device, changing passwords, etc.), but if you want to get down and dirty with it (like changing registry values), it’s best to connect through a Powershell session. If you’re having further troubleshooting issues, this might be the best way to resolve other problems.

After I felt like I had decent connectivity to the running RP2 from my computer, I downloaded the Blinky project, in order to modify the code. However, I was surprised to learn that Microsoft had configured these projects to be early adopters of the Universal Windows Platform (i.e., UWP). On top of requiring the download and install of gigabytes of additional framework libraries, I also had to made slight modifications to my approach for altering the code. (For example, the UWP pushes programmers in general to make asynchronous calls to Windows APIs. There may be workarounds to make synchronous calls, but they’re probably designed purposefully to be cumbersome and undesirable.) I had planned on making calls to the SQL Server database in my cloud, but it also appears that the System.Data.SqlClient namespace is missing by default from UWP. Perhaps it can be added as a NuGet package; I’ll look into it more with future iterations and/or prototypes.

In any case, I changed the Blinky project so that the frequency value for my circuit’s flashing LED light would be occasionally updated by the result returned from my Azure web service; the web service would pull the value from the SQL Server table in my cloud. Once I compiled the project, I made sure to connect VS 2015 to the Remote Machine. (Don’t be a dummy like me and be sure to hit the small arrow to the right of the menu option “Device”. That cost me a minute or two.) Then, after hitting F5, I held my breath as the project’s massive content made its way via WiFi to my RP2…and then, success!

The good news is that an old dog can in fact learn new tricks. Once I had the project working, I used SQL Management Studio to connect and then alter the table in my cloud. And, lo and behold, the frequency of my LED light changed accordingly! Prototype finished and mission accomplished!

Overall, I think that the kit has the potential of being a good introduction for novices, as long as they have an adequate background in Windows software and systems. Plus, some patience is required. Even though I haven’t learned anything really useful or broadly applicable yet, I get the impression that it’ll be easy to acquire a broad base of knowledge fairly quickly with this kit. Of course, my colleagues might suggest that to acquire an actual expertise, one should get an Arduino board and become an avid part of its community (as well as become a patron of Instructables)…but, for a newb like me, I believe that this kit is a decent launch point.

Now onto the next project (though I basically covered that ground with my improvised changes to the Blinky project). I’ll still give it a try, in order to learn anything possible…but I’m really looking forward to the sensors project. One more incremental step to an actual Haunted House!