Behavior, Content, Money – 3 Things you should never give away for free!!!

BCmoney MobileTV

SmartWatch showdown – Pebble .vs. the rest

Posted by bcmoney on October 19, 2016 in IoT, Mobile with No Comments


No Gravatar
English: Picture of a wristwatch band, showing...

Picture of a wristwatch band, showing in detail the locking mechanism (Photo credit: Wikipedia)

Pebble, a company and SmartWatch brand started by Eric Migicovsky in 2012, set the standard for SmartWatches and in many ways single-handedly ignited an entire SmartWatch industry, totally separated (yet later tightly integrated) to the Fitness Band & Activity Tracker craze which was separately growing. Each of these types of products fall within the broader Wearables market, and often get lumped in with a plethora of other devices which are all considered to be part of the “Internet of Things (IoT)”. The goal of a SmartWatch product (other than generating sales and profits for its company) in many cases, is thus to be capable of acting as a “control platform” for the IoT. There is much promise in being able to be more productive and manage one’s digital lifestyle, without being one of the so-called “SmartPhone zombies” who are constantly staring down at their smartphones rather than interacting with the people and world around them.

As a device, the SmartWatch promises to maintain the level of “constant connectivity” society, work and family/friends have come to expect of one another somehow in this crazy hyper-digital modern era, yet teases at the possibilities of a little relief in manageability and having information available but only taking out your phone to “dig in further” when absolutely necessary. In short, it makes it that much easier to ignore the constant buzzing, vibrating, bell chiming & ringing of SmartPhones as they receive Message Center Notifications, SMS texts, IMs, Chats, Emails, Calendar event updates, Video conferencing sessions (Facetimes/Hangouts/Skypes), and yes how quaint, even still occasionally Phone calls. At a glance you receive notifications pushed over to the watch from the phone via Bluetooth and can see at a quick glance without taking out your phone whether a given piece of distraction is truly worth your time or not at a given moment. Time is valuable, and watches not only help you be more timely but when they are smart they help you manage your entire life better as well. It also helps simplify keeping track of your physical activity (if you’re into that sort of thing) without needing a myriad of other wearable fitness gadgets. Let’s take a look at how the various options stack up, premising it with the following graphic which represents the “Hollywood-fueled” somewhat unrealistic dream of what a SmartWatch can do for you:

Read the rest of this entry »

Raspberry PI 2 – Python controlled circuits Button & LED experiments

Posted by bcmoney on August 31, 2016 in IoT, Python with No Comments


No Gravatar
이진 카운터가 구성된 큰 빵판

RaspberryPI digital clock/counter (Photo credit: Wikipedia)

So the last set of experiments definitely piqued my interest in the Raspberry PI platform and its capabilities to measure, control and otherwise interact with the physical world. In reality though, all I’ve done is play with some cheap hobbyist parts that could be picked up at any electronics shop. Still circling around the true capabilities of the PI, I realize I now need to connect the hardware capabilities to the software for creating a proper controller or event-driven system. Afterall, the hardware is where the “Things” aspect of the “Internet of Things” comes in to play and the software is what potentially reaches out to the “Internet” to connect multiple distributed devices or call out to cloud services for message relay between systems, analytics or additional intelligence.

As with the last article I sifted through the web resources out there to try to find the most relevan ones. The following videos show you how to extend the basic Breadboard/Circuit knowledge with the use of logic gates to do “code-on-chip” types of behaviors where your board/circuit can add a bit more intelligence to its basic input/output capabilities, how to safely extend the basic components with real-world sensors, and how to connect directly to the Raspberry PI as a power source via GPIO ribbon cable to control physical electronics experiments with code:
Read the rest of this entry »

Raspberry PI 2 – Hardware kit unboxing & first circuit LED experiments

Posted by bcmoney on July 24, 2016 in IoT with No Comments


No Gravatar
English: Logical 4-bits adder where sums and l...

Logical 4-bits adder where sums are linked to LEDs on a breadboard. (Photo credit: Wikipedia)

Hard to believe its been over 6 months since I finally decided to buy into the IoT hype train and pick up my own Raspberry PI, to try my hand at creating some useful IoT-ish experiments of my own. I’d like to say its been interesting just tinkering around and seeing what the possibilities are, but thus far I’ve really only been scratching the surface and playing around mostly with the software and on-board peripherals side of the PI’s capabilities, which is really only half of its true potential.

One of the biggest strengths of the Raspberry PI and similar “open hardware” Microprocessor platforms (Arduino, BeagleBoard, etc) is that they enable you to connect what is essentially a “cheap but fully-funtional computer” to the broader physical world. In the Raspberry PI’s architecture, this takes the form of the GPIO expansion slot, which stands for General Purpose Input Output and as the name suggests, provides a number of raw inputs/outputs to be used by ambient sensors (temperature, pressure, air, water, motion, etc) in the more complex use-cases and basic indicators like lights (LEDs), speakers, etc in the more straightforward use-cases.

If you are like me, coming from a predominantly software-based development background, and as we are in the software world often far removed from the “nuts and bolts” of the systems we build thanks to high-level programming languages, levels of abstraction and working mostly in the “application layer” of the OSGI stack; then even setting up the basic use-cases with a blinking light can seem a little daunting at first. This is compounded by the stories online of people who admit they really didn’t know what they were doing (and sometimes even of those who did) and managed to make a little mistake somewhere which resultied in frying their entire PI due to incorrectly wired circuits, overloading with incorrect power supplies/balances, or in some cases even static electricity introduced by an improper work surface not properly grounded.

To help anyone in a similar situation I will attempt to share the few things I’ve picked up in the first few weeks of owning a hardware kit for my Raspberry PI, and some experiments/resources that can come in handy for learning to teach yourself, which is arguably the most important skill of all.
Read the rest of this entry »

Raspberry PI 2 – Complete Starter Kit unboxing & config (IP/DNS/SSH/FTP/VNC/VPN/HTTP)

Posted by bcmoney on January 17, 2016 in IoT with No Comments


No Gravatar
English: Extract from Raspberry Pi board at Tr...

English: Extract from Raspberry Pi board at TransferSummit 2011 (Photo credit: Wikipedia)

This blog post will summarize my recent Raspberry PI 2 – Canakit unboxing & configuration. I purchased the kit as a sort of “from-me-to-me” post-holiday gift as I have been thinking about doing so for quite some time and when the Raspberry PI 2 kits fell in price due to rumors of the pending release of the new Raspberry PI 3, I realized the time had finally come to dive into the world of PI.

The first thing you’ll notice if you’re looking to make the same sort of “pre-RPI3 release” purchase, is that this kit does not include the extra attachments required to do DIY electronics projects, and you would have to buy a separate components kit later or find the components piecemeal elsewhere. In hindsight, I would suggest to go with the full kit if you are even slightly thinking you might want to get into the electronics experiments. If you just need a really cheap computer or have a plan for a basic DIY Home Theater or DIY ROM/Emulator Gaming Console, then you can stick to the first cheaper starter kit and have pretty much everything you need (except possibly a few peripherals like console-specific USB controllers if you’re doing gaming).

I had no idea what I wanted to do, so I started out with the basic kit, which I got slightly cheaper on Amazon in a post-holiday sale than what the same kit is advertised for elsewhere.

Unboxing the Hardware

As soon as you take everything out of the box, ensure you have all the components needed. The official hardware guide shows you everything you need to begin (all of which should be included in your kit).

Ensure that you have:

  • Raspberry PI (any model will do, but I personally chose 2… with 3 Bluetooth & WiFi are onboard so don’t need to take up USB slots)
  • TV or Computer Monitor to hookup to initially (won’t need this later once we are done configuring)
  • HDMI cable to plug into both the Raspberry PI and the TV/Computer Monitor
  • USB Keyboard to type into the command-line (you’ll be typing alot initially!)
  • USB Mouse to navigate to the required applications (and check out the menus and various apps installed)
  • AC Adapter (power supply to turn it on)
  • 8+ GB MicroSD card or SD card (depending on the Raspberry PI model you chose)

 

OS Installation

Without an OS, the Raspberry PI is just a curious box of chips and hardware with so much potential waiting to be tapped, but largely nothing more than a fancy paper weight. The first thing you’ll want to do is pick an OS and install it onto an SD card (or MicroSD card) so you can begin experimenting.

As the instructions on the official Raspberry PI site state, your best bet as a beginner will be Raspian (a Linux distro derived from Debian but designed and streamlined specifically for the Raspberry PI). I had trouble with the Operating System that came with the Canakit “Complete Starter Kit” and had to flash (wipe out and reformat) the provided MicroSD card in order to put a later and greater version on to the card. Once I did that, I was finally able to get through the boot process and get it installed. After you follow the steps in the official Software guide you should have done the following:

  1. (optionally) Flashed the provided SD or MicroSD card to start fresh
  2. Downloaded the ZIP file for NOOBS “OS installer” (offline version, or files for your chosen OS directly)
  3. Extracted the ZIP file to your computer to make it available to card
  4. Setup the NOOBS OS installer (or chosen OS directly) to your card
  5. Connected all the Raspberry PI hardware
  6. Gone through the NOOBS installer wizard on your Raspberry PI
  7. CHANGED THE DEFAULT USERNAME & PASSWORD (can’t stress this enough, do this before you connect it to the internet or even before opening up your device to Bluetooth connections for the first time)
  8. Connected to your local (home/office) WiFi on the PI (if you have a WiFi dongle or PI model with built-in WiFi)
  9. Tested your Bluetooth connectivity (if you have a Bluetooth dongle or a PI model with built-in Bluetooth)
  10. Restarted your PI and ensure the OS comes up successfully and saved all your configuration changes (if not troubleshoot)

CAUTION: Many in the PI community online have mentioned they corrupted their SD card during poweroffs before the PI had completely halted. For that reason you also have to be extra careful if you’re thinking of doing “portable/mobility PI” projects where you’d use an external battery pack or power source to enable the PI to be used on-the-go. When this happens you’ll need to reinstall everything and potentially lose all your files, so be sure to only power down once you have fully shutdown your PI. Thanks to  it’s low power usage and heat radiance, most people just  leave it running 24×7 once setup, but you don’t need to do this, just take care with the shutdowns and reboots. If you have alot of time-consuming changes or important work you’re doing with the PI that you’d be devastated to lose, remember to back everything up to another device and/or on a file-hosting service. I use a combination of backing up indivudal key files to my laptop, backing up the whole image to an external hard-drive, and all my code changes go to a Git repository (i.e. local, GitHub, BitBucket, etc). I don’t do the files or image that often, but at least once a month or more when I’m particularly active with it and alot of changes are made. Code will be saved for every commit though.

Configuration

There are some things you’ll still want to configure, but you could stop here if you just wanted to make sure everything in your kit works correctly. Completely hooking up to your main TV or PC screen can be a little inconvenient if that screen gets shared with other members of your household, unless of course you have a dedicated screen to use just for your IoT/PI projects. Even so, for practical software and hardware/electronics development projects, you will probably want to proceed with the following useful configurations for remote access to your PI without needing to hookup a keyboard, mouse, screen, audio converter cables, etc: Read the rest of this entry »

HSVO project problems and NRC’s SAVOIR 2.0 SDK solution

Posted by bcmoney on December 13, 2015 in E-Government, E-Learning, IoT, Web Services with No Comments


No Gravatar

In the last post I set the context for the HSVO project and how I winded up a member of it via my contract at NRC, setting the stage to help any potential readers understand all the partners and the objectives they had going in.

English: National Research Council of Canada, ...

National Research Council of Canada, Institute for Information Technology (NRC-IIT) in Fredericton, NB (Photo credit: Wikipedia)

Now I’ll talk about the major problems faced on the project (also suffered by Healthcare IT & Medical Schools all over the world and in any shared E-Learning initiatives in general). Hopefully, any time you need to have so many partner systems work together based on the anecdotes shared here, you’ll quickly realize the importance of establishing an Electronic Data Interchange (EDI) amongst your partners, specifically, a simple to parse Canonical Data Model (CDM). These constant communication and data formats must form the foundation for any cross-organizational initiatives like this involving high levels of integration between two or more devices, services, systems, apps and/or courses.

 

How we did it

NRC management was essentially the lead on the project as far as owning the largest piece being delivered (i.e. their mission assigned by the HSVO was to “provide the glue that would join all these separate devices being built by our research partners”). After about 6 months of initial research, the plan formulated by my superiors before I was even hired on by NRC as an Application Developer to implement it, was to extend their existing SAVOIR 1.0 source code. It is common for government organizations like NRC to look to past work and projects/experiments from within their portfolio which can potentially be leveraged or extended beyond their initial expiry date and use cases. Nothing wrong with that, but its not always the best fit, especially when dealing with complex problems which might be better served by green fielding a totally new solution based on Agile development using direct interaction with the customer (in our case, our research partners, but primarily NOSM who the entire project was tailored to in the name of the promises of “E-Learning for Remote Medicine”).

That said, SAVOIR 1.0 was basically a glorified Application Launcher which acted as a sort of dock that could run any application installed on your Operating System with a single-click. Think RocketDock but without any of the slick animations, and, implemented in Java so it could at least work cross-platform on Windows, Unix/Mac, or Linux. It was originally intended to simplify the lives of Architects as part of a separate project that finished up in 2008. Behind its code were also two basic Web Services:

  • User Management (called “SAVOIR_UserMgmt“) this allowed the system to keep track of who was using the SAVOIR dock to run their applications and which applications they launched at which time. It also allowed system administrators to turn on an optional desktop-based login popup in Java if desired, to force specific users to login with their username/password before using the applications in the SAVOIR dock; however of course if the applications were installed outside of SAVOIR’s install pack, then those applications could be launched anonymously as usual at any time, by going directly to their “exe” file on the system, or clicking on a shortcut (such as in their Program Files menu).
  • Session Management (called “SAVOIR_SessionMgmt“) this allowed a unique identifier to be attached to each running instance of the SAVOIR dock, regardless of whether or not anyone was actually logged in, or if the login feature was turned on by the system administrator for the network on which SAVOIR was running.

We delivered what could really be called SAVOIR 1.5 after approximately my first 6 months on the job, with some heavy modifications to the core Java Swing GUI including the ability to drag & drop to the dock or slide/move applications up and down in launch order, and, the ability to also launch particular websites/webapps in the browser for the first time. This browser launch feature was probably the one we were most proud of, and only became reasonably easy to do in Java 1.6+. Now, any link could be placed on the Dock, either of the form:

  • file://path/application.exe (for locally installed apps)
  • http(s)://domain:port/path/#hash?param1=abc&paramN=etc (for apps on the web)

This gave the SAVOIR launcher a great deal of flexibility, we even developed a couple canned demos of the new capability which we thought would delight our partners. By being able to popup a simple search window (also in Java) and navigate straight to deep search results of the CMA Guidelines Infobase, PubMed medical journal archive, Wolfram Alpha as a calculation tool, and Wikipedia as a general info resource, as per the user’s selection.

The reception was lukewarm at best though, which came to a bit of a surprise to me after all the hard work myself and the team had put in, doing exactly what our superiors had requested. What I began to learn was that there was a growing disconnect between what our partners (who these partners were is covered in my last post) were expecting and what we were delivering. What our partners were telling us, was that they did not simply want a customized version of SAVOIR 1.0 rather what they wanted was a more unique application with some intelligence that basically not just got out of the way so they could use their applications in a particular order, but they wanted something that could do alot more heavy lifting and facilitate communication between their separate applications.

A brief word on EAI
Enterprise Application Integration (EAI) is the dilemma we face when trying to integrate large complex applications (but the cocepts really apply to applications of any size). With two applications, the integration is easy. Expose one or both as an API and send data, one or two ways, as needed:

It quickly becomes tough to manage as you add in more applications to support/integrate:

If you have any kind of external scalability requirement to support alot of external services/devices, just forget about point-to-point integrations:

Of course the ESB vendors like MuleSoft, WS02, TIBCO and even Apache ServiceMix evangelists promise their ESB products will instantly make your EAI efforts look and feel like this:

Not quite. Even with proper use of JMS for messaging, HTTP for addressing, and an ESB to broker transformations, what we learned the hard way is that despite all the hype of the ESB providers, you can’t expect to just plug in the services to an ESB and walk away laughing, problem solved (its possible that certain members of our team who sha’nt be named bought this notion a little too much though). You simply won’t be able to avoid the need to gain at least a rudimentary amount of working knowledge of each of the given devices or APIs you want to integrate, before you can even try to do anything meaningful with the data inputs they send and outputs they can receive. What that also means is that you’ll need to gain some basic domain knowledge and/or work directly with a domain expert in the initial design stages (akin to Agile development). We lacked that domain expertise at NRC, and at first management also relucted on opening direct lines of communication between our developers and main clients (which from the broader group were NOSM and McGill). At first the reaction was all around frustration, then lots of talk of from the medical experts on our project needing something they were calling “The Eye of Sauron” followed by a rash decision to implement a Rule Engine (in our case Drools) which could live on the ESB to help determine the routing of messages based on business logic defined by our HSVO partners. We struggled with this, not just the implementation and integration of the Rule Engine as yet another endpoint on the ESB and whether that was helping us or hurting us in the long-run. Perhaps most significantly what we struggled with was how to simplify the Domain-Specific Language (DSL) Drools required as input down to a simple enough format that it could be either hand-coded in Excel (one of Drools’ supported input formats) then uploaded periodically before running E-Learning classroom simulations (aka “Scenarios” as the team dubbed them), or, to a consistent enough format that the rules could be automatically generated in the backend by an Authoring Tool (yet another piece of new technology that would have to be built to support this growing monstrosity). Next came discussions about the need for a “Rosetta Stone” behind the scenes of SAVOIR, which I codified as a “Term Dictionary” which was capable of mapping concepts between endpoints (i.e. Blood Pressure in one system may be the input “BP”, but in another system it might be “kPa”; in some it could be split by S-Systolic and D-Diastolic while others it could be together as “S/D mmHg”). Finally, a need for a “Unit Converter” to convert different medical units of measurement (i.e. metric to imperial to bridge gaps from Canada/UK/Ireland to United States, differences between Med School SOAP notes, etc). So much for an Application Launcher huh? We went through several student placements but none of them made a very significant dent in the Rule Engine (aka. Eye of Sauron) piece, or, the Message Translator/Mapper/UnitConverter (aka. Rosetta Stone); so it was up to myself and Roger Sanche at NOSM to come up with a way to get this beast working. Working with the domain experts daily we realized the main problem. Interaction in one application/service/device must be able to fire-off events in a predictable way to the Message Bus and get routed through to the next application/service/device yes, but we are doing this in support of multiple learners at multiple locations, this was the key. It was one of the hardest things I’ve ever done but after many late nights we pulled off a working integration that would show the recipe. We called it the SAVOIR SDK, mostly because we had spent our creative reasoning powers and were too exhausted come up with anything else.

What we realized is that if we could apply Sturgeon’s Law (aka. KISS, DRY, YAGNI) and simply start thinking of each of the complex devices we were trying to integrate as nothing more than differing set of inputs/outputs, with some unique endpoint “addressing needs” based on their own scalability and protocols (i.e. HTTP based web app that can support thousands of users at once, or, a UDP camera that only one person or classroom could use at a time) then we could start to see a different more manageable picture. Finally we could realize something similar to the ESB simplification we were promised; to get SAVOIR 2.0 anywhere near our partners’ desired level of integration, we needed to create just three simple CDM and thin wrappers (SDKs) for our partners to use to send and receive messages in a single consitent format. That simple realization finally got us the big breakthrough we needed, and a matching of Scenario (path to scenario being worked through), sessionID (learner unique identifier), and instanceID (learner’s device’s OS/browser/tab identifier) as attributes of the services we were describing would be the last step to the messaging delivery problem. I’ll be the first to admit, its such a simple concept. To this day I wish I’d bought the infamous EAI book sooner, but it was a chance landing on the book’s website that lead us down the right path. Check out the schema we put together:
Read the rest of this entry »

BC$ = Behavior, Content, Money

The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:

1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.

2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.

3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.

  • Archives