#64. Maker Mindset (Continued)

A few weeks ago, I had talked about building an IoT device (Air Quality Index monitor) and how easy the process has become. In the last couple of weeks, I have been working with my 12-year old daughter to build another device – she wanted to build a sensor that would alert when someone walked her into her room. The main idea is of course, to spark interest in her. Important on many counts – from the personal (after all, Engineering is going to play a critical role in solving some of the big problems that we need our next generation to tackle) to an attempt to make a small dent in a big problem that we often talk about at our dinner table – why is it that the gender gap in engineering isn’t just not going away? Case in point: our local High School robotics club is highly imbalanced – with over 90% boys. And if that is the case in the crucible of Silicon Valley (where we live) with an overwhelming majority of families with at least one parent an Engineer, I don’t expect to be any better elsewhere. And so that’s the challenge we might want to think about: can we ‘hack’ our way to changing that mindset, even by a small amount?

Back to the sensor project: as it always does, this basic requirement evolved – and with it, the design and the MVPs:

1. Req-1: Sensor that would create an alert when someone walked into her room.
2. Req-2: For the sensor to be useful, it needs to alert her when she is NOT in the room. And that meant sending an alert to her phone
3. Req-3: She needs the alert to be activated ONLYin specific time windows: e.g. when is she is at school (let’s assume fixed time intervals – say, Mon-Fri 8am-4pm)
4. Req-4: She needs the alert to be dynamically activated only when she is not in the vicinity of the room.

And as expected, the building blocks are all there:

1. Sensor that generates a signal when it detects movement
2. A WiFi SOC that processes the signal and sends an alert to a cloud account (in this case Telegram)
3. A Telegram app on the phone where you can push the alert (we chose Telegram because it offers a free bot service)

The above took care of the base requirements (Req-1, Req-2) and we knocked it off in a few hours. For Req-3, the interesting (and fun part) was figuring out how to program the device to send an alert only during specific time windows, which obviously required the device to figure out the day-of-week and time. We ruled out the idea of adding a clock timer to the device since that would add to the cost of the device and in any case, seemed like an overkill. So, the question then: given that we have a WiFi connectivity, can we fetch the time from the cloud?

A brief diversion on Time

A little bit of sleuthing around – and enter the concept of ‘Epoch time’ (back to the good old Unix programming days!). There is a cluster of virtual timeservers that provide what is called the The Network Time Protocol (NTP), a free service to synchronize clocks over the internet. This provides the number of elapsed seconds from 1/1/1970 (epoch time) We had to write an API to grab the Epoch time – and then use some basic math to infer the day of the week and the time of the day (which has taken care of Req-3). Disclaimer: this is a simplistic implementation (e.g. assumes a static timezone) but for now, serves the purpose.

Along the way, we had an interesting discussion on the concept of time itself: we don’t bother to think about it, but time has two attributes that we have come to accept for the sake of standards: first, the unit of measure (seconds/minutes/hours) which is obvious; and secondly, the less obvious one – time is actually an offset from an (arbitrary) T₀  which is specific to calendar systems. And one of the feats of the human civilization has been our ability to converge on standards on calendaring (the Gregorian calendar) and the notion of time (24/60/60). It seems obvious now – but the journey from each culture measuring time and defining calendars to a universal global standard is fascinating and a spectacular feat in itself. And in areas where we have managed to nail down global standards, we have made spectacular progress. The challenge of course, is to apply the same sense of rigor in some of our next set of problems – climate, in particular. Topic for another day.

And of course, the NTP timeservers and APIs is yet another example of the numerous building blocks that are available for free and can be easily used for building solutions – the entry barrier is well and truly, going down every day.

What next?

Now that the sensor is up and running, we need to figure out how to make it ‘proximity sensitive’ as well – e.g. can the IoT device figure out the distance of the phone and avoid sending alerts to my daughter’s phone if she is home (Req-4)?

And hopefully (perhaps more importantly), this and projects like these will spark interest in kids (girls in particular) to re-discover the joy of tinkering and building interesting and fun stuff – as I keep discovering, the possibilities are amazing!

Trivia:

1. There is whole sub-culture around Unix time nerds. Apparently there were parties in February 2009, when the Epoch time clocked 1234567890 seconds (!)
2. If you search for ‘Is Time relative or absolute?’ you will get sucked into an absolutely fascinating discussion on Relativity. Still haven’t been able to really understand it. Some things are just not meant to be.
3. Here’s another trick question: how many seconds in a day? 24x60x60 (or 86,400 seconds) is what gets us going, but in reality, 24 hours represents a mean solar day – which actually is a little longer, apparently adds up to 1 second every year. And hence the boffins at International Earth Rotation Service (yes, this is an actual thing) have declared a leap second – which normally happens on June 30 or Dec 31, making it a 86,401 second day.