We need a fundamental change …

… in the way we input text into computers.

Just watched a Youtube video of a Japanese explaining how they input sentences on an English keyboard, to construct Hiragana, Katakana, and Kanji glyphs. That sucks, but it is SO weird that they don’t use a dedicated keyboard. Even stranger, other languages such as French (see the first comment) can’t even input their own characters such as diacritical capital letters, so they are re-inventing the AZERTY keyboard.

Years back I reprogrammed a keyboard controller on a mainframe so that I could learn Dvorak keyboards. To my real surprise I found that within a couple of days I could type reasonably fast using the new layout. The real challenge? Doing technical things (I was a programmer) that occasionally required me to find things on the actual keyboard.

There’s the rub.

ASCII and the extended EBCDIC are pretty reasonable, IF you are an English speaker. That’s the whole reason for the invention of Unicode: expand the code space so that other languages can have space! Before that it was DBCS attempting the same. Now along come emojis and we all get funky. But there is a fundamental disconnect between our spoken and written languages AND our text input methods that requires us to learn no less than three or four ways of using it for communication.

Take the swipe type keyboards. These work great for you if you have learned by heart how to type fast on a QWERTY keyboard. I type really really fast on them an it is only autocorrect that gets in the way. But, I am going through three stages of conversion

  • I compose a sentence in my head
  • I visualise this in QWERTY layout
  • I swipe through the glyph that represents the key presses
  • The word appears on the screen.

Essentially, I have reinvented a chinese or japanese way of writing, but for English.

That’s pretty amazing, and someone somewhere should write a book about it.

Water leak detection using LoRaWAN

I’ve used several water leak detectors over the past 20 years. The first was using the simple FSK devices from UK company Ciseco and their simple ‘personalities’. This was a two pronged contact switch on the end of a lead with the main box housed higher up

Ciseco XRF module and water leak detector

More details are here and this was mounted on the side of my shed at the bottom of our sloping garden where the river floods into our property. When triggered by rising water it sent messages via NodeRED to my mobile phone. One time I got a warning text when away from home and was able to talk with my family to ensure nothing was damaged in the flood water.

I cannot stress just how simple it was, and just how easily – even for a technical hacker like me – that the whole system “just worked”. I feel that is fundamental in our gadget obsessed age. They also ran for over a year on a single coin cell battery.

Water leak rope and LoRaWAN sensor

I currently need something like that working at the building where I am a caretaker but for there (and for home) I’d like something that detected water along a horizontal access. An example is my newly refurbished bathroom that I’ve extensively waterproofed (or ‘tanked’ as they say locally) to keep the kitchen below dry. In spite of all the taping and sealant that I have put some water does splash over from the shower-over-bath arrangement and drop onto the kitchen ceiling. My solution is to buy some water-leak detection rope from AliExpress and couple this with a Dragino LWL01, having removed the existing twin-pronged detector and running the water leak cord across the exit for the bathroom where the water now trickles through. Similar detectors are around 5 – 8 times more expensive.

Once working, I’ll connect this via NodeRED (perhaps using the excellent CakeRED from Datacake) and link this back to my intelligent bathroom mirror to generate a synthetic voice via the espeak module saying “Water leak! Water leak!”

Perhaps then I’ll sleep easier knowing that the bathroom floor mat will be used correctly and my kitchen ceiling will be safe.

The way it was before

The BBC had an article about some possible future impacts from our global pandemic. Reduced to a summary I’d have to judge it as “we’ll keep acting like we have during this time”. Full of information about hand sanitisers and touchless equipment I think it was pretty unrealistic.

Humans seem to have an endless ability to forget the past and joyfully repeat it, warts and all. We really didn’t learn much from the second or first world wars and we are gleefully shaking our fists at each other again. it takes little for politicians to rally the population and point at some other group to accuse them of “causing it all”. Today it is China, yesterday it was Russia, before that it was the Hun, tomorrow it will be someone else.

I’d say give it one year and we’ll have completely forgotten about Covid-19.

Back during the 90’s I tried to get my manager to see the sense in working from home. I travelled extensively during that time, thousands of air miles across the world and saw more of airline interiors and weird taxis than my family and home. I enjoyed it to a degree but most often ‘zoned-out’ by ignoring all that happened around me and existing in my own thought bubble. I started writing, took paints with me and spent time in parks and plazas doing water-colours. Most customer meetings were short affairs of a couple of hours at most, and then the whole hotel-taxi-airport-plane-airport-taxi to home would repeat. Mind-numbing, wasteful effort.

At the same time my physical location went through a similar cycle. It began with buildings being expanded in the 90’s, new car parks with space for hundreds of cars, even helicopter pads. Car use seemed to proliferate even in the face of car sharing schemes, bicycle discount purchases, and private bussing from the train station. Nothing halted the growth of the motor industry as much as the internet.

The internet brought freedom from location. I spent most of my time phoning people, creating code, and sending emails to arrange things including travel. On the odd occasion I actually spoke to someone local about an aspect of the project I was working on, but mostly things were don’t electronically. I did have the advantage that working for the world’s premier technology company meant that we’d had internal systems that worked globally well before DARPA and other pieces came together to form what we know of as the modern Internet. I even used Fidonet from a home PC in the late 80’s!

The first decade after the new millennium put in place many of the systems that have given us modern working practise. Video standards and increasing technology convergence in miniaturisation led to tablets, smart phones, and systems that could stream live video with reasonable quality. I watched people try video calling on public transport and saw the issues with technology for technology’s sake: just because you can do it, doesn’t mean that it is a good idea. The same with mobile phone and Bluetooth earpieces – walking down the road shouting to yourself is a good way to draw anxious glances, hold a phone to your ear and everyone understands that you’re not crazy, just occupied.

The 2010’s saw a rise of ubiquitous broadband connection everywhere from homes to coffee shops to businesses. Connection was everywhere, smartphones common and personal video conferencing really worked. I delivered several global training courses across multiple time zones using course-ware and the experience was tolerable, if not even enjoyable. But the need for gathering in large numbers with colleagues persisted, but the purposes seemed to be more about gelling as a team rather than the purported educational reasons. The Brits called them ‘jollies’ and it is just what you’d expect: trips to foreign corporate party cities as a reward. Barcelona, Las Vegas, Dublin, Orlando and the like.

Eventually even my team became dispersed and had no hope of meeting other than virtually. Once a week we’d come together and see each other through a camera. We became adept at passing knowledge, encouragement, interaction and information between us. I often met other team members at customer sites rather than gathered in the manager’s location. We were a virtual team and it worked very well.

I realise that a physical trades person such as a plasterer won’t have that privilege, nor will a police officer or seaman. But even things such as Haulpak trucks on mining sites can be remotely operated, war-fighting drones (with all their sadness), and autonomous cargo ships are being built. Online retail is booming, shopping malls are entertainment centres, and the fundamentals of what we thought are changing. Even my church has swapped from a be here now to a we’ll talk wherever you are approach and has constructed a TV studio, live streaming, and greater online presence. We may need to live in a new normal for a long, long time.

We cannot predict the future, because it is the future. What we can do is stop clinging lifelessly to the remnants of the past.

My struggle during the late 90’s and 2000’s could have been easier if management saw the potential and worked to mitigate the downside. Instead my frustration was only answered by a global pandemic to force the issue of a new way of working.

Environment sensors

As mentioned in the last post I’ve been experimenting again with my LoRa setup and have got my RAK831 gateway running again. Previously I’d used the excellent Balena containerised device control, but the image I was using with it seemed to stop working with the RAK device so I swapped over to using the full tool-chain supplied by RAK themselves and built from their new generic git repository. This worked well and my gateway is live again on The Things Network.

I also purchased and installed the excellent Things Network Indoor Gateway at my work location, and this is running well using the building’s WiFi for back-haul. I’ll distribute environment sensors with the facility manager’s permission around the campus to start measuring conditions such as temperature, humidity, frost levels and external gates opening.

Closed source LoRa device for temperature, humidity measurement

I also found and have started experimenting with the Dragino series of LoRa sensors – I’d have to comment that as a Chinese manufacturer they seem more experienced with producing for a world-wide market, and devices are relatively low priced for mass consumption. The sensors such as the LDS01 and LWL01 easily fit what I need without being in the hundreds of euros bracket. While using development platforms such as the Pycom LoPy or Adafruit Feather devices is better for code development, they do require cases and batteries for waterproofing and field-hardening which take cost and effort to make. A manufacturer can source these in bulk to reduce cost and test before shipping.

I will continue with the Pycom devices for the simple reason that I like tinkering with code, and they are fun to understand the internals of IoT. I also need them for things that do not have a LoRa component such as my remote weather station and my gateway tracking.

These Dragino devices work well and I have started looking at setting up a dashboard for my devices, once they are installed. So far I have looked at:

  • MyDevices, inventors of the Cayenne IoT format which is helpfully produced and consumed by some devices and dashboards.
  • DataCake, a useful European data provider that has a large library of devices already coded into their dashboard.
  • ThingsBoard, DevicePilot, and others are only a Google search away
  • … or self-host using the NodeRED dashboard, my preferred solution if I can get space on my work’s infrastructure for a virtual image.
NodeRED dashboard

Low power for sensors

Following on from my research in sensors for ice detection, I’ve been looking at the different modules available for environment measurement that transmit using LoRa. The ‘development’ platforms I am happy with should use MicroPython (or CircuitPython or variation on same) since I develop best in that language.

Low power is also important – long ago I realised that Raspberry Pi and SBC-type platforms that ran Linux were better on powered supply, as they consume too much current even when doing nothing. Nobody can really run a remote RaspberryPi off-grid, even with large power supplies such as USB cells they quickly deplete. As well, anything that uses WiFi is out as that is a very chatty interface and seems incompatible with low-power embedded operation. Adafruit has a great page to help decide on which processor fits your requirements. The devices I’ve considered:

  • M5Square – a block-building format that clips together the different components so you get a computing base, never tried but seem to have a comprehensive lineup
  • Pycom – I’ve used their various modules from the early WiPy through LoPy (and struggles to get low-power working) and found they are ‘acceptable’ to wrangle into a working module
  • Some sort of ESP8266-based platform such as the Wemo D1 mini and those based on the Expressif ESP32 chips
  • Adafruit and their Feather range of development platforms such as those based on the ESPxxx but more recently on the ATmega32u4 and variations

While all of these are good it is probably more import to choose a platform and stick with it – “a long obedience in the same direction” and all that. The other consideration is how low can they go? Not all chips faithfully power down well and I know that Pycom struggled to get the Expressif ESP32 chips down to very low power. Apparently they can go as low as 25uA for ULP consumption and 1uA for LoRa in standby. Comparing with the Adafruit they say that you can achieve 300uA (0.3mA). This is not as low as the Pycom chips but I am willing to experiment with both to see which performs best.

Although I’ve played with the ESP8266-based ones and have had several successfully running, but as they are primarily a WiFi-based system I will not use them. You also have to remove the LUA software platform and re-flash the µPython environment to get them working. I also won’t attempt the M5Square ecosystem as it would mean purchasing a whole raft of new chips and understanding how to program them. So it is either Feather or LoPy – I think I’ll experiment with both.

Ice detection for footpaths

In my role as a caretaker for a large facility with car park and pavements I need to detect hazards and mitigate the dangers. The particular hazard I wish to know is when my footpaths and pavements are covered in ground ice so that I can apply grit. My paths get icy and it is barely visible – the image below has ground ice on a resin bound surface and even wearing boots I could skate the entire length of path.

Ground ice detection systems are expensive – they are used to detect conditions where warning signs are illuminated, deicing is initiated, or other remedial actions taken such as applying deicing solutions to airport runways. My needs are humbler than these; I simply want to be informed by text when ice may be present and arrive early to sweep some salt and grit over the footpaths so people don’t fall over. And I’d be more happy with false positives than false negatives – arriving to find that there is no ice is better than missing a day and someone is injured.

I intend to use LoraWAN to transmit the data as this is cheap and simple, and I have experience in coding and running such systems. Finding a detector that is simple, cheap, and reliable is a challenge. The components will be:

  • LoraWAN ice sensor
  • LoraWAN gateway through The Things Network (TTN)
  • NodeRED process to combine weather conditions including temperature, humidity, cloud cover, and wind. The latter two will likely come from a weather service.
  • SMS node in NodeRED to send warning texts

In my searching I found a number of systems that are either too expensive, too elaborate, or I don’t have the technology to produce. I can work with wires, wireless, embedded systems, 3D printed plastics, wood, and some metals such as steel in simple assemblies. Exotic plastics and sensors that require electrical potential are probably beyond my simple facilities, although the electric ones may be possible depending on my battery budget.

Meteorological conditions

There are some good references on the Internet that describe the conditions that lead to ground ice. These are likely to be the same conditions monitored by local council maintenance crews that go out and spread rock salt (called ‘gritting’ here in the UK) on the major trunk roads before a freeze. Mostly, to form ice needs:

  • little or no wind
  • water vapour in the air, or water on the ground from rainfall
  • clear skies without cloud cover
  • low temperatures, below freezing point

One way to monitor these things is to use weather sensors and meteorology reports. I could take feeds from something like Weather Underground and combine them, however standard measuring instruments are normally sited well above the ground surface so do not accurately measure the temperature on the ground.

Ice Sensors

Ice sensors come in a variety of implementations from mechanical to electrical through to optical using thermistors or other IR sensors at a distance. Some are well known in the aircraft runway industry while others are more suited to road surfaces. All the commercial ones cost in the hundreds or thousands of currency, and generally come as part of an integrated system with controller, reporting mechanism and loggers.

I need something under 50 $/£/€ so that I can afford at least a couple of them – one locally for reference, one on site to alert me. That rules out most commercial options. In addition even the most well tested commercial sensors only achieved rates of 86% in university tests, therefore I expect less accuracy in my cheap sensors and will tolerate more false positives.

Summary

I will likely go down the route of using a LoraWAN embedded item with temperature and humidity, and using a 3D printed case attach this to a tree or light pole near the main affected pathway. I’ll then combine this with cloud cover and wind sensor data – from locally if possible but if not from a weather service.

Smart Mirror

I’m building a smart mirror for my refurbished bathroom. Starting with a damaged LED mirror as the base I already have half of the underlying infrastructure in place. The LED mirror was already wired safely onto the wall and the insulated steel frame had drivers, transformers and other electrical components inside. Since the mirror itself was damaged when I removed it to store during the bathroom refurbishment, I needed a new partly silvered glass and I ordered this in the excellent Mirropane™ Chrome Spy having selected this from the sample pack sent by Brigla-Therm.

Removing the old broken mirror from the frame wasn’t easy! In fact, it was downright scary slowly prising off shards of glass from their glue and I did it very, very slowly. Once removed, I cleaned the old frame and reattached the new mirror glass using bathroom silicone sealant. Light showed through from the overlapped areas behind the white tiled wall so I covered the overlapped sides using black tape.

I chose a VA type of monitor after looking at the discussions on the MagicMirror forum. Apparently these show better contrasts than TN or IPS types, although their response times are slower and less suited to gaming. That’s fine by me – I’m not planning to run anything fast moving on this display as the primary things will be static text and graphics.

The software is relatively simple; I saw one video where the builder said that ‘maintaining JSON was hard’. As a software developer I find it relatively easy so the approach I have gone for is to run the MagicMirror (MM) server remotely in a virtual container and use a browser on a very small client (Raspberry Pi Zero W) to boot and display a single page in full screen mode. I like and admire DakBoard but firstly it is a subscription instead of a one-off cost, and I feel it is also more geared towards the commercial smart mirror provider with billing plans for your remote clients.

I’d also like to control the monitor’s buttons using the GPIO from the RPi but I am uncertain at the moment how to do this. I’d also like to physically turn off the monitor back light when not in use but again not sure yet how this would work. Relays seem an obvious choice.

Power was a challenge as the space behind the mirror is limited particularly in the thickness dimension. Instead of the hulking wall-warts I have decided to build a small soldered breadboard with miniature power supplies to convert from the standard 230V delivered to the mirror into the 12V and 5V needed by the monitor and RPi.

It’s all about us, not about you

Many decades ago I worked on a time recording system for a large business department. This was to be used by a couple of hundred workers who would enter their time as they completed tasks, and then reported back up to managers. It may sound draconian in these days of zero-hour contracts and gig economy workers, but it was common in those days of top-down project management and still is today on major infrastructure projects.

What intrigued me was how a small, important, vocal minority of stakeholders bent requirements so that their needs were addressed to the detriment of the large body of people who would actually use it and enter information. One effect of this was that the workers took the lazy way out and simply reported in large blocks of work rather than the fine-grained estimation needed by the immediate project managers – too many tasks resulted in too little detail and most reported only when they had finished. In effect they ‘gamed’ the system.

But this isn’t just an historical tale. I’ve seen the same feature creep in a number of places. Take the UK government’s Covid-19 tracking app for example. In an excellently reasoned article one of the developers for that app discusses all of the reasons why they are not using the decentralised model offered by Google and Apple. Reading through, I think it is fair to say they rejected the decentralised approach “because it doesn’t help us, only you”. Therein lies the rub.

In all the systems I developed over many decades one thing I came to understand was that complex and intricate things were used less and less by the very people that were needed to collect accurate data. Unless the lowest and least important people use your system, the data is useless. You need buy-in from the very people you didn’t consult, as the whole premise of the system needs them to accurately, faithfully, and happily use your app.

I was a professional developer who is quite happy for much of my information to be online in the right places but I am concerned about the interconnected abilities of this app. Person-to-person interconnectedness takes this to a sinister level, one that reminds me of the worst excesses under the Iron Curtain. Anonymous entity resolution has been used for a decade or more to trace bad guys but a population mapping of this sort can only be dreamt up by Facebook, and we’ve seen where abuses of that led.

I’ve seen all types of ways to encourage, cajole, threaten, and advertise the use of systems and above all, unless the system gives the end user something back they will not use it. Money incentives, managers checking weekly, making it part of yearly objectives, all of these fail unless the system is simple, easy to use and above all helps users do their work. All other stakeholders are secondary consumers of the information and all the scientists, Public Health England, app developers and National Cyber Security Centre staff are not as important as the millions of ordinary Brits who are expected to use the app. Starting off by excusing privacy-breaking controls isn’t the best way to start introducing a new national app. The reason given? “It will help us”, not “help you”. To quote from the article,

“… and, most importantly, (it) provides the insights the public health professionals need to better manage the virus in the UK.”

… from NCSC blog post written by Ian Levy

MOST importantly?!? While other issues mentioned are interesting in a technical way, such not draining the battery and keeping me secure (from whom?) the article in a profound way exposes the general attitude about such systems – it’s all about us, not about you. We need this because we are important, not because you are important. But if we want people to do things, we need to do things for them, not for us.

How to keep you mobile phone clean from virus

During the corona-virus pandemic keep your mobile phone clean by covering it with cling film / saran wrap / plastic wrap before you leave the home. Don’t leave any bits exposed, only use 1 layer over the touch screen by joining the bits together on the back.

Outside, unlock using a digital method such as a password or pin – don’t use the fingerprint scanner! The power button and volume controls should function as normal. Don’t use a corded headset!

Don’t use the camera. While it does work, it doesn’t look good – sort of like a 60’s dreamy filter over everything. Unless you want that. And flash is a disaster as it plastic wrap makes it go everywhere.

When you get home, clean and wash your hands. Then, carefully unwrap the phone and dispose of the dirty plastic wrap without touching any of the contaminated bits.

Enjoy!

Building an app

For some time I’ve wanted to automate my caretaker job with some software tools. I guess I’m just lazy, but sometimes the sheer amount of side requests that come through to me is astonishing – every day someone will ask questions, suggest improvements to a building, or report a broken thing. Maintaining the list of ‘things to do’ was a full-time job for an artist using colourful Post-it notes on the back of my door. There had to be a better way, and I looked at CMMS suites as an option – many were excellent and even had a mobile app, however as they were all paid it was beyond my budget allocation which is basically zero unless I pay for it personally.

I’ve just started building a new app myself using some interesting tools. I get too interested in the tools sometimes, sometimes to the detriment of the end result and my wallet. Here’s what I want to do:

I want to capture a list of work and maintenance requests into a data store for review and annotation. Some or most of these will be completed by me, while some will be tagged for inclusion into what we call a “working party” where people come to the church, and work! Some party … but actually, it is a lot of fun to have a group of mostly guys hacking and wracking and packing. The break time is a highlight and we all sit around and talk, which is great.

However in the current circumstances it is impossible to get together in such close circumstances and I’ve thought of running it instead as a type of virtual party, one where volunteers can select a job they think they could do alone, then select a date when I’m available to unlock the facilities, then I would bring along needed items such as tools and materials and let them get on with it alone while I am busy elsewhere in the building. A win-win all around – I get things done, they get out of the house, and the building is repaired a little more.

One of the interesting things I have come across is AppSheet – now part of Google Cloud. It is a simple workflow automation tool set that takes structured data as input and displays it on a responsive display (ie. one that adapts to the display size: mobile, tablet, or monitor) with triggers to different events. I love event and flow programming as it fits my mind better than event-oriented programming or object-oriented programming. And as it is visual I can see the immediate effects and links between different classes and objects. Here’s an example:

Taken from AppSheet examples

I am going to take this and join together the data sources held on an organisation data source and meld it into a ad-hoc work-selection process, hopefully one that allows us to operate and encourage our volunteers – who are mostly older men in the ‘vulnerable’ category – to use their skills while the country is on lockdown.