All things tech/ beautiful: introduction

Showing posts with label introduction. Show all posts

Friday, February 09, 2018

Programmable Things. An introduction. Plain and simple

Just make it!

Original image source: Wikimedia, just search for The Thing :)

This is a great time to be a part of the hardware+software maker movement. The things that you make here are called- Things! Seriously :) and by extension, we have IoT, aka Internet of Things.

There is such a wide variety of low-cost, easy to program and reasonably simple to integrate micro-controllers out there that its literally a bonanza. And, it only keeps getting better! There is a huge community of makers and there are tons of videos and tutorials on the web that can help you know more about anything and everything that you will need to make your own Thing. If you have a problem to solve and a solution in mind, my attempt here is to give you a primer: A meek peek into this wonderful world. Perhaps, in the near future, I will share my notes on a few deep-dives as well.

System

Almost all projects are of the following nature:

Input(s) → Processing → Output(s)

(OH: cmmon!) This simplified view is a great place to start as we dive a bit deeper. A simple example of such a system could be:

There is a button, pressing it (input) will turn the connected light (output) ON or OFF (processing: toggle light state).

Input

Inputs are read from sensors that either translate some physical phenomenon, human intent, commands or instructions through some physical activity (like a button press), into electrical signals.

Now these electrical signals could be analog. Analog signals are those where a variation of the signal amplitude/ strength (measured in Volt, or ‘potential’) or current (measured in Ampere or ‘flow’) could be measured to infer something about the phenomenon being measured.

The signals could also be digital, where the measured quantity is represented as zeros and ones. So, essentially a set of ON/ OFF pulses (binary representations, that the microprocessor understands) that encode a number/ value say in the decimal system (which we tend to relate to much better).

Bonus: Read a quick recap on number systems here:

Number systems
Recap counting!medium.com

When the signals are analog; for the computer to make any sense of it, it must be turned into its digital or binary form through what is called sampling. This is done by an ADC (Analog to Digital Converter). Most micro-controllers have on-board ADCs but one could use a separate ADC as well.

So, sampling involves taking a snapshot of an analog signal at a point in time and then the ADC converts that value into a binary (base 2) representation.

To get a meaningful representation of the original signal, the sampling rate must be high enough. So, higher the sampling rate (frequency or the number of times you take the sample reading per second), the better the signal fidelity. For example, if you record your sound using a microphone on a computer, a typical sampling rate would be 22KHz. Which means, the sound card has an ADC that takes 22 thousand samples of your voice signal amplitude from a microphone per second and stores each of them up onboard!

Also, the number of bits that the system uses to represent each discrete signal sample determines its accuracy. For instance, an 8 bit sampler can represent 2⁸ or 256 different signal values (from 0000 0000 to 1111 1111). Assuming we are measuring a maximum of 1 Volt using this sampler, this gives a resolution of 1/256 or 0.0039V. So this system is capable of measuring variation in voltage as small as 0.0039V or more up until 1V but if the increment in the voltage is less than that, it will not be able to measure it. Now, if the sampler supported 10 bit, that would give 2¹⁰ or 1024 possible values between 0V and 1V. This translates to a resolution of 0.0009765V ! This is evidently a lot more granular than an 8 bit sampler.

So, the higher the sampling rate and the higher the number of bits returned per sample, the closer will the digital signal come to represent the analog one that it just attempted to digitize. So, theoretically, what it means is that digital always loses ‘some’ of the original analog signal during the process of conversion, however hard it may try. But then, these losses tend to be negligible in high fidelity systems and once the signal is digital, well, its food for a microprocessor and you can do a zillion things with it that you may not have been able to pull off when it was in the analog form.

So what kind of sensors are available? Well, a whole lot. Here’s an indicative list:

a. Temperature
b. Pressure
c. Sound
d. Vibration
e. Location
f. Motion
g. Magnetism
h. Touch
i. Light
j. Humidity
k. Presses (buttons)

Just google for ‘x sensor’ where x is the thing you wish to measure/ read as an input and you should get to some sensor that does the job for you. There are some sensors that come with an ADC built in, so you could read their output straightaway.

Output

For systems to be useful, they need to be able to present their output in some form. Where humans are involved, these better be human readable/ interpretable forms. This is where output systems come in.

Simply put, the output systems do a reverse of what the input systems do. They translate the digital output values into some physical phenomenon, like: displaying them on a screen (light), voice output or creating a buzzer sound. At times, they need to be sent to other systems which will take them as inputs. One example would be if this needs to be transmitted to a server so that a log could be maintained, or an email sent!

The following is an indicative list of output systems:

1. LCD/ OLED/ LED displays
2. Speakers
3. WiFi, Bluetooth, RF transmissions
4. Tactile feedback

Processing

Consider a weather station which needs to measure, temperature, humidity, wind-speed and location. Evidently, more than one input is necessary here. And you might need to convert the read inputs into some other scale and notify a central system periodically and raise an alarm if there is a huge variation in any of the input values. Or combine multiple inputs to predict whether a storm event is likely. This needs a processor. A processor, in simple terms is something that can execute a defined set of operations on given inputs. Microcontrollers have a ‘computer’ inside them. Usually they are RISC(Reduced Instruction Set Computer), which means that it may not have a whole set of capabilities that your desktop computers have, but they would have just enough to pull off your job. So, now you need to choose a suitable microcontroller for it.

These are a few important considerations while narrowing down your choices:

a. Number of inputs you will need and their types (eg: 2 analog inputs and 3 digital inputs)
b. The voltage levels of the input sensors
c. Physical size limitations
d. The amount of processing required
e. Number of outputs you will need (eg: LCD display + WiFi + SD card logging)
f. Power requirement (access to mains power? Long battery life? Low cost of power? Solar?)
g. Ease of prototyping and scaling

Once you have narrowed down your requirements, just search the net to find the suitable options.

What options do you have, as of end-2017 (what I love and know for sure is that this list is bound to get obsolete soon 😊)

1. Raspberry Pi

[https://www.raspberrypi.org/]

For more complete systems that can interface with a set of peripherals like keyboards, mice and monitors. Their most recent addition is Raspberry Pi Zero W which has HDMI out, WiFi and Bluetooth, costing about Rs. 1500 (all connectors etc included!).

2. The Arduino family

[https://www.arduino.cc/]

A wide variety of choices. These guys literally did set the maker movement on fire by introducing a simple programming interface and easy to prototype input/ outputs. Most of them use ATMEL processors.

3. ESP8266

[http://espressif.com/en/products/hardware/esp8266ex/overview]

The hip youngster on the block. Developed by a Chinese manufacturer called Expressif, ESP8266 and its clones are inexpensive devices with WiFi capability and a decent spread of input/ output options

4. ESP32

[http://espressif.com/en/products/hardware/esp-wroom-32/overview]

Evolution of ESP8266 with Bluetooth/ LE support added and a lot more!

5. nRF51/ 52 series

[http://www.nordicsemi.com/eng/Products]

Low power BLE capable devices from Nordic Semiconductors are slightly difficult to program but are powerhouses enabling a revolution in portable devices like smart-bands and other wearables. Most of these use ARM Cortex processors.

There are a lot more options out there, I’ve only picked up my favourites that get most of the jobs done. Of course, we have folks like Intel playing catch-up with their Edison series et al, but, the kits above rule the roost.

So, there you are; You have now been introduced to programmable things! Go figure and make!

API + RESTful API. An introduction. Plain and simple

Connect!

Courtesy: https://pixabay.com/en/plumbing-pipe-wrench-plumber-840835/

From Appliance Plumbing Interface…

Imagine that you have just designed a water faucet/ tap which dispenses water only if your fingerprint matches (however strange this may sound, I believe creativity should know no bounds ;). Now, for this to be actually used in a real wash-room or a kitchen sink, it needs to have a receptacle that exactly fits the common water pipe end-point. Lets say, it needs to have the female threaded end 1/2 inch diameter pipe to couple neatly into the male threaded pipe end. In other words, this new contraption of yours needs to follow the same plumbing interface definition as the pipes it needs to work with.

…To Application Programming Interface

Now, imagine if you were more of a software dude/ dudette than a pipe-hardware one. You might design a piece of software that will allow money from your bank to flow out only if your fingerprint matches (this sounds a lot more familiar, right? :). For this widgety creation of yours to be actually used in a real banking app or website, it needs to be able to be ‘integrated’ into the money flow interface definition of the bank(s). As a developer of this new functionality, you therefore need to follow what is called as the Application Programming Interface (API) definition exposed by the banking entity that you intend your software to work with. There you are! You have been hereby introduced to APIs. Simple right?

Why API?

The advantage of defining an API is this. Once defined, and published, it opens your platform up to a limitless set of different applications by independent innovators. So you might see some developer making an app that sends money from a bank account every time someone likes her profile pic on Facebook, or another who develops an app that makes a donation to a random NGO every time you use a swear-word on twitter…I hope you get the drift. There is no limit to the variety of innovation this can spawn. And all this while you enjoy a nice cold iced lemon tea reading some news-feed on your tab.

In short, APIs decouple application use cases, innovation, revenue generation and growth from your core platform. The better defined your APIs and the partner on-boarding processes are, the more you can relax and count the beans :)

API is also important because it helps make as much sense of the options available, to the humans implementing it as it does to the machines consuming or exposing it. This is an act of fine balance.

An API once said, “I need some REST”

Lets now focus on something a bit more technical. RESTful APIs. For a start, Restful does not refer to the relaxation that I’d mentioned a short while ago. The REST in RESTful refers to REpresentational State Transfers.

From verbs…

A lot of us have come from the functional programming world. In simple terms, the interfaces defined there would correspond to the verbs that were being exposed. For instance, in a banking app, you could have an interface defined as getBalance(account) which would return the account balance for a given account. Or, sendMoney(account1, account2). Or, listAccounts(customer). These functions could also be exposed as APIs and they do something based on its input parameters. The response of the API call would be the action defined as the verb and output parameters that would provide more details on the action done.

This kind of API has one inherent problem. An API description could be really arbitrary and it would be difficult to imagine all the functionality exposed without having explicit access to the API creator’s documentation.

…To nouns

RESTful APIs are a different breed altogether. They focus a lot more on the resources or nouns, instead of verbs. For example, ‘customer’ could be a resource, ‘account’ could be another and so on. As for the actual action that you would want to take with a resource, REST simplifies it all down to a set of pre-defined verbs in the WWW HTTP definition.

When you visit google.com, for example; the browser actually executes a GET request for the index page based on the URL (Uniform Resource Locator) http://www.google.com.

The idea (RESTful lends its origin to the doctoral thesis of a genius named Roy Fielding) is that, given these constant verbs; All that a developer needs to know is the set of objects/ nouns that he might have to deal with.

For instance, assume a simplified banking application. It may have a resource called customer or transaction or account. So, in the simplest sense, assume the base URL is https://myxyzbank. Now the base URL is like the rootdirectory for all resources (nouns). So, accessing a customer within the bank would likely be baseURL/customer.

There are a few more properties of RESTful APIs. I would only want to touch upon the fact that these API calls are also stateless. That is, a RESTful API call is in itself complete and independent of previous or future calls. In other words, the API calling entity’s state is not preserved on the server in between calls.

Singular and plural

Also noteworthy is the singular and plural use of these nouns.

While /customer/id refers to a particular customer with a given ‘id’ as its identity;

/customers/ refers to all the customers collectively.

So, executing an HTTP GET request on https://myxyzbank/customers should likely return a list of all customers within the bank, executing GET request on https://myxyzbank/customer/id would return a particular customer only. So, simple plain English “get a list of all customers in this bank” translates to an API, GET on https://myxyzbank/customers/ and the bank should spew out its long list (Of course it ain’t that simple. Security, roles, access and privileges have been excluded from the scope of this article).

Now back to the 4 main primitives and why they are pretty much sufficient for most applications.

Get, Post, Put and Delete is all you need

GET- as the name suggests would simply fetch the resource(s) identified
POST- use it when you intend to create a new resource(s) on the server
PUT- updates an existing resource on the server
DELETE- deletes the identified resource(s)

This sounds a lot like CRUD framework (Create, Read, Update, Delete) used for data storage.

Parameters

Additional parameters could also be passed to and from the server along with each resource request. This data could be in different formats, the most popular and elegant one around is called JSON (Java Script Object Notation). Another excessively verbose and elaborate protocol from our good ‘ol days is XML (Extensible Markup Language).

Beauty and the beast

There is a certain sense of beauty, logic, crispness and cleanness in the structure of truly RESTful API. The sad part is that most implement it with varying degrees of RESTful-ness. To the extent that I have even seen a bank call GET /getCustomerBalance as a RESTful API! That’s a verb on verb action and totally looses the plot.

My attempt was to only provide a plain and simple outline to API and RESTful API. There is a lot more in it and the world wide web should be your best guide.

May the POST be with you!
And May is hot!

Thursday, November 16, 2017