DEV Community: w4ilun

Building an IoT badge with ESP8266 + ePaper

w4ilun — Sat, 22 Aug 2020 21:38:15 +0000

(Note: these posts are migrated from my previous medium.com blog)

I’ve recently come across some e-paper display modules and thought they were the coolest thing ever. For those not familiar with e-paper, it’s a display technology similar to what’s used in e-readers (such as the Amazon Kindle).

These displays don’t require any power to stay on, it’s only when you need to update the image do you need to give it power. The image on the left shows a high-level concept diagram of how these displays work.

For battery powered IoT devices, there are many advantages to using these type of displays; you can pretty much shut off everything to preserve battery life and wake up only when you need to perform some action, all while displaying pertinent information to the user.

So what can you do with an ESP8266, a battery, some buttons, and an ePaper display?

Smart Home Remote (Note the 5-way switch, up/down/left/right/center)

Weather Dashboard

WiFi Manager

Display Notifications (IFTTT or other integrations)

Name Tag

…and pretty much anything you can think of. It’s a tiny battery powered computer with WiFi connectivity!

Building the badge

These e-paper displays support the SPI protocol, so you’ll need to connect the right wires to the right pins on your microcontroller (the ESP8266 in our case) to drive the display. The display also requires a driving circuit to work, of which you can either get an adapter board for , or build your own. I decided on the latter, as the documentation was sufficient, and I didn’t want messy wires.

As with many of my recent projects, I usually skip the breadboarding phase and jump straight to designing the PCB on KiCad (hurrrray for open source software!). While building the driver circuit, I also threw in a coin cell battery + USB charger to make our little badge portable.

After double/triple/quadruple checking everything, I sent the design off to a PCB fab to have the boards made…

The datasheet also thoroughly describes the timing and signals over SPI on how to control the display, but luckily for us, GitHub user ZinggJM created an Arduino library that abstracts all of that away :)

ZinggJM / GxEPD

A simple E-Paper display library with common base class and separate IO class for Arduino.

It also leverages the Adafruit-GFX library, so you can use graphics primitives to do your drawing and rendering of images/text.

After 5 long days, the boards finally arrived!

I used 0805 footprints for most of the components so they’re easier to hand solder, though there was no getting away with the 24 pin FPC connector (drag soldering did the trick)

Notice the empty pin headers on J1; these are connected to the TX/RX/GPIO0 pins of the ESP8266 and used for programming the chip with a USB-Serial adapter. You can either solder on pin headers and have a permanent programming connector, or you can do what I did and simply pushed pins against the pads to load the OTA firmware once, then you could always upload any new sketches over WiFi (as long as the new sketch doesn’t crash/fail).

Right now, I’m doing some real world tests on battery life, but based on my calculations I should get about 40 days of battery life in deep sleep mode:

120 mAh coin cell battery / (60uA regulator + 20uA deepsleep ESP8266) x 0.70 miscellaneous factors = 1050 hours ~= 43 days

Switching up the battery technology may also extend this a bit further; a 500 mAh LiPo has a similar footprint, and should theoretically offer a 4X battery life.

All source files will be available on GitHub, feel free to contribute and build your own! If you support Badgy, you can get one today on Tindie. Enjoy :)

sqfmi / badgy

Home of Badgy - IoT Badge

Building Your Own Midi Fighter

w4ilun — Sat, 22 Aug 2020 21:30:17 +0000

(Note: these posts are migrated from my previous medium.com blog)

What’s a Midi Fighter?

A Midi Fighter is a music controller equipped with high quality arcade buttons for a great tactile feel, low latency action, and durability. Every button is also backlit with RGB LEDs, illuminating the translucent buttons with customizable colors and animations.

What can you do with a Midi Fighter?

Me? Not much. But check out what other skilled people can do:

Design Process

After spending a few hours on YouTube watching amazing performances by these talented individuals (check out Shawn Wasabi’s YouTube channel), I decided I wanted to build my own! There were plenty of DIY projects out there on building a MIDI controller with an Arduino, but most of them lacked LEDs, or were in a larger form factor.

Designing the enclosure was the first step. I came across a lot of designs that used MDF or Acrylic boards as the mounting plate. I didn’t want any flex when pushing the buttons, and also a premium feel to the end product, so I opted for anodized aluminum plates to form the enclosure.

The PCB would be sandwiched between the top and bottom plates, and held together with M3 machine screws; on the 4 corners, aluminum standoffs would provide support and clearance for the arcade buttons, and components on the PCB.

For the arcade buttons, I chose the Sanwa OBSC 24mm translucent buttons; these are high quality Japanese arcade buttons rated for 15 million presses! They require very little actuation force, and are spring loaded to provide quick feedback. It was also important to choose translucent buttons to let the RGB LEDs shine through :)

For the PCB, I designed everything using KiCad. The layout wasn’t too complicated as the board was fairly big (~15cmx15cm), so I had plenty of room to route the components. I did spend some extra time on the PCB art and also making sure all the dimensions were correct. The microcontroller is an ATmega32u4, with each of the 16 buttons connected to a GPIO pin. I chose this MCU because it’s the same one as the Arduino Leonardo, and I could take advantage of the many already available libraries.

You may have noticed that there are 32 RGB LEDs on this board! To provide even lighting without using light pipes, I decided to place two of these LEDs at a diagonal underneath each button. Now because of the layout, the normal sized 5050 Neopixels were too large to fit, so I went with the SK6812 minis which are only 35mm x 35mm.

Assembly

All the designs were submitted for fabrication and after about 10 days, I received all of the parts:

The first thing I wanted to test was to make sure the PCB, the buttons, and the mounting plate were all aligned properly:

The buttons were really snug with the mounting holes. In retrospect, I should’ve designed it with a little more wiggle room and not precisely 24mm, as it is now close to impossible to remove the buttons.

All of the components were then soldered onto the PCB; I didn’t actually have to solder the arcade buttons because the mounting holes had enough friction to keep the pins in contact. Everything was then sandwiched together to form the final device:

Code

The first order of business was to flash the device with the Arduino bootloader, this would allow us to upload our firmware via USB with the Arduino IDE. This can be done using another Arduino as an ISP (in-system programmer). Once this is complete, your device should be recognized by the IDE as an Arduino Leonardo. I’ve included an ISP header on the top right corner of the PCB.

For the firmware, I used Adafruit’s NeoPixel library and the MIDIUSB library. All of the buttons were mapped to a different note, and the LED underneath would change from pink to white when pressed:

Firmware source code and hardware design files are all open source and available on GitHub: https://github.com/w4ilun/midifighter

Showtime!

I made the above track with GarageBand, it immediately recognized my Midi Fighter when plugged in; other music creation software e.g. Ableton Live, Traktor, etc. should also be supported.

Next Steps

It would be great to have some GUI software that would allow you to easily design LED animations/patterns, as well as configure the button mappings to play different notes. Right now, everything is hardcoded, so any changes would require directly modifying the sketch. This would be a great opportunity to use WebUSB and do everything over a browser :)

GLHF!

Build a Google Home assistant with Android Things

w4ilun — Sat, 22 Aug 2020 21:26:44 +0000

(Note: these posts are migrated from my previous medium.com blog)

After playing around with Android Things for the first time, I’ve decided to explore the APIs and try out all the other cool things you could do with this platform. Though blinking an LED was only fun for about 5.2 seconds, that accomplishment prepared me with knowledge to tackle some of the more advanced projects. There are quite a few examples on GitHub, ranging from toggling GPIOs, Bluetooth audio, and even one on TensorFlow.

At around the same time, Google announced their AIY Voice Kit: a DIY AI assistant using a Raspberry Pi. I got super excited and couldn’t wait to build one myself; it looked like a fun little project, and I’ve always wanted to compare Google’s experience with the Amazon Echo’s.

Much to my dismay, the kits were sold out everywhere, and scalpers were selling them for upwards of $90 on eBay :(

The kit was essentially a cardboard box with a Voice HAT that connects the button, speaker, and microphones to the Raspberry Pi; the magic was within the Google Assistant SDK, which provides the APIs for the voice-based AI interactions.

Luckily for me, the Google Assistant APIs are supported on Android Things! Would it work on the Edison?

It works! Now let’s see how to put it together…

Things You’ll Need

Intel Edison with Arduino Breakout (though any Android Things supported device should work)
USB sound card with mic input (not needed if your board has audio jacks for in/out)
Speakers (I used my headphones because I don’t have any handy)
Microphone
Arduino Shield + Button (you could also wire a momentary switch directly to a GPIO pin)

Running Google Assistant on Android Things

The first thing you’ll need to do is to flash Android Things onto your device, you can follow my previous article or use the official guide. It might be a good idea to at least get to blinky first, so you know that you have a functioning Android Things device.

Once that’s done, you can then open the Google Assistant sample in Android Studio. You can find the sample code **here, **which I forked from the official repo; I’ve made some minor changes to make it work with my setup, namely:

Changed the button to activate on high instead of low

Button.LogicState.PRESSED_WHEN_HIGH
Mapped button to IO4 (in BoardDefaults.java)

    public static String getGPIOForButton() {
        switch (getBoardVariant()) {
            case DEVICE_EDISON_ARDUINO:
                return "IO4";

Default to USB sound card instead of the Voice HAT for the Raspberry Pi

    AUDIO_USE_I2S_VOICEHAT_IF_AVAILABLE = false

Before you build and deploy onto the device, you’ll also need setup your credentials so your device can use the Google Assistant APIs, and grant permissions via Oauth:

Follow the instructions here to enable Google Assistant APIs and get your client secret JSON file. You can then rename that file to **client_secret_NNNN.json **to keep it short (if you want to). I also found this guide pretty useful .
Copy that file over to your projects root directory, then run Google’s oauthlib tool to generate the credentials.json:

pip install google-auth-oauthlib[tool]
google-oauthlib-tool --client-secrets client_secret_NNNN.json \
                     --credentials app/src/main/res/raw/credentials.json \
                     --scope https://www.googleapis.com/auth/assistant-sdk-prototype \
                     --save

All set! Now click run let the app build and deploy. It should build successfully and you’ll be greeted with:

Yay! Except nothing works, because the USB sound card is not connected…what?!

The Edison Arduino breakout board is setup in a way that there’s a tiny toggle switch between the larger USB-A port and the micro USB port. You can only use one or the other, by moving the toggle switch. Which means you can either use the micro USB port for the ADB shell connection to deploy and debug your application, or **you can switch and use the larger USB host port for your sound card, **but not both at the same time :(

Thankfully, the solution is simple: you’ll need to connect a 12V power supply so you can keep the USB host port active for the sound card (i.e. tiny toggle switch facing up). However, you’ll lose the micro USB connection and need to use ADB shell over Wi-Fi instead:

$ adb tcpip 5555
$ adb connect <DEVICE_IP_ADDRESS>:5555
$ adb shell

Now deploy and run your application again. Your device will start listening when you press the button, and stop when you release it. Your voice query gets sent over via the Google Assistant API, and you get a response almost instantaneously. Neat! Since the service is linked to your Google account, you can even tell it to add events to your Calendar and access other information. Ask for a joke, find out tomorrow’s weather, and when you run out of ideas, check out this comprehensive list.

Well, that’s it. Again, this has been a lot of fun and it’s great to see how easy it is these days to sprinkle some AI into any project. I still haven’t fully explored the capabilities of my DIY Google Assistant yet, but I think there’s a lot of potential for interesting projects here. I’d love to find out if it can control other IoT products as well, perhaps a spoofed WeMo switch? :)

Android Things — Getting to Blinky

w4ilun — Sat, 22 Aug 2020 21:21:13 +0000

(Note: these posts are migrated from my previous medium.com blog)

Android Things brings Android and the mobile development ecosystem to IoT devices. It’s currently in developer preview 4, and has support for a variety of platforms, such as the Raspberry Pi, Intel Edison/Joule, and the NXP pico. You can learn more on the official site, but in essence, a developer can now use the same Android tools and APIs on IoT devices, including access to Google services, such as Google Drive/Search/Maps/Fit/Firebase/etc.

Having zero Android development experience, this caught my interest and I figured I’d give it a go to see what it takes to get to the “Hello World” of hardware: a blinking LED.

Hardware

Android Things currently supports the aforementioned platforms. Naturally, I went with an Intel Edison that I have lying around (many of you may also have one, if you’ve attended one of the many hackathons in the past year :) If you have another supported platform, you could skip the setup section below and follow https://developer.android.com/things/hardware/developer-kits.html instead.

Software Setup

We’ll need to download/install a couple of things to get started:

Intel Flash Tool Lite (For updating the firmware on the Intel Edison)
Android Things System Image (Android Things System Image for your board)
Android Studio (Our IDE and tools for development)

The first thing you need to do is to install Android Studio and update to the latest SDK/tools. You’ll need to use these tools later for updating your board and deploying your application. After installing, make sure you have **adb **and **fastboot **in your command prompt.

Once that’s ready, download the Intel Flash Tool Lite along with the Android Things System Image. You can follow this guide here for details on how to update the firmware and install Android Things. The flashall.sh script mentioned in the guide didn’t work for me, so here’s a summary of the steps I took to get the board up and running:

Run the Intel Flash Tool Lite to update the firmware, it should take about 30 seconds, with the board booting into FASTBOOT MODE if it was successful. You can monitor this from putty or screen terminal.

Once booted into FASTBOOT MODE, run the fastboot tool in a command prompt of your host computer to install the image:

$ fastboot \
    flash gpt        partition-table.img \
    flash u-boot     u-boot-edison.bin \
    flash boot_a     boot.img \
    flash boot_b     boot.img \
    flash system_a   system.img \
    flash system_b   system.img \
    flash gapps_a    gapps.img \
    flash gapps_b    gapps.img \
    flash oem_a      oem.img \
    flash oem_b      oem.img \
    set_active a \
    reboot

Let your device reboot and wait for the adb shell:
```
$ adb wait-**for**-device
$ adb shell
edison:/$
```

…and you’re done! You now have Android Things running on your board!

You could also connect your board to Wi-Fi (we won’t need to for blinking an LED, but you’ll probably need connectivity for future projects)

edison: am startservice \
     -n com.google.wifisetup/.WifiSetupService \
     -a WifiSetupService.Connect \
     -e ssid <SSID-name> \
     -e passphrase <SSID-password>

Wait a few seconds then try pinging an IP e.g. 8.8.8.8 to make sure it works.

Creating your Android Things app

Follow this guide for creating an Android Things app. The steps are essentially the same as creating a regular Android app, but since I have zero prior experience, I followed this guide for creating my first Android project. You’ll need to target **Android 7.0 (API 24) **and make sure the SDK tools are up to date. Once the project has been created, you’ll need to modify the **build.gradle **and **AndroidManifext.xml **files to configure itself as an Android Things app:

build.gradle

dependencies {
        ...
        provided 'com.google.android.things:androidthings:0.4-devpreview'
    }

AndroidManifest.xml

<application
        android:label="@string/app_name">
        <uses-library android:name="com.google.android.things"/>
        <activity android:name=".HomeActivity">
            <!-- Launch activity as default from Android Studio -->
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>

            <!-- Launch activity automatically on boot -->
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.IOT_LAUNCHER"/>
                <category android:name="android.intent.category.DEFAULT"/>
            </intent-filter>
        </activity>
    </application>

Build and run your project, it should succeed but it won’t be doing much at this point…

Interacting with Peripherals

The cool thing about Android Things (ha) is that developers are now able to interact with hardware peripherals in their application. Through the PeripheralManagerService APIs, you could interact with your device’s GPIO, PWM, I2C, SPI, I2S, and UART, allowing you to communicate with any sensor/actuator using these standard protocols.

In addition to the peripheral APIs, Android Things also has the concept of User-Space Drivers; these drivers are essentially abstractions so you don’t have to worry about the hardware implementation and board configurations when interacting with a peripheral device. You could easily drop in a GPS/Temperature Sensor/Audio Output/OLED Screen/HID driver and use it right away, without worrying about the sensor protocol and any low-level peripheral IO APIs. Check out the **peripheral driver library ** to see what’s already supported and how to add your own.

For now, we’re going to start thee basic Peripheral I/O APIs. Add the following code to your HomeActivity.java to get a list of available GPIOs on your board (Note: in Android Studio, press Alt+Enter for quick fix, it will import the missing dependencies)

public class HomeActivity extends Activity {
        private static final String TAG = "HomeActivity";

        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);

            PeripheralManagerService service = new PeripheralManagerService();
            Log.d(TAG, "Available GPIO: " + service.getGpioList());
        }
    }

Build and run, open up the logcat window and you should see a list of GPIOs:

Blinking an LED

Finally! So after setting up your board and installing all the software bits, the last step is to run the code for blinking an LED. You could setup your board like the diagram below, or simple use the on-board LED; both the on-board LED and the external LED are connected to GPIO pin 13:

Edit your HomeActivity.java with the following code:

    public class HomeActivity extends Activity {
        private static final String TAG = "HomeActivity";
        private static final int INTERVAL_BETWEEN_BLINKS_MS = 1000;
        private static final **String ***LED_PIN_NAME = "IO13";

        private Handler mHandler = new Handler();

        private Gpio mLedGpio;

        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);

            PeripheralManagerService service = new PeripheralManagerService();
            Log.d(TAG, "Available GPIO: " + service.getGpioList());

            try{
                mLedGpio = service.openGpio(LED_PIN_NAME);
                mLedGpio.setDirection(Gpio.DIRECTION_OUT_INITIALLY_LOW);
                mHandler.post(mBlinkRunnable);

            }catch(IOException e){
                Log.e(TAG, "Error on peripheral", e);
            }

        }

        @Override
        protected void onDestroy() {
            super.onDestroy();

            // Step 4. Remove handler events on close.
            mHandler.removeCallbacks(mBlinkRunnable);

            // Step 5. Close the resource.
            if (mLedGpio != null) {
                try {
                    mLedGpio.close();
                } catch (IOException e) {
                    Log.e(TAG, "Error on PeripheralIO API", e);
                }
            }
        }

        private Runnable mBlinkRunnable = new Runnable() {
            @Override
            public void run() {
                // Exit if the GPIO is already closed
                if (mLedGpio == null) {
                    return;
                }

                try {
                    // Step 3. Toggle the LED state
                    mLedGpio.setValue(!mLedGpio.getValue());

                    // Step 4. Schedule another event after delay.
                    mHandler.postDelayed(mBlinkRunnable, INTERVAL_BETWEEN_BLINKS_MS);
                } catch (IOException e) {
                    Log.e(TAG, "Error on PeripheralIO API", e);
                }
            }
        };
    }

Here’s what’s happening: We’ve created an instance of Gpio, set it to pin 13 using the PeripheralManagerService, **set it to output and off initially with **DIRECTION_OUT_INITIALLY_LOW, then using the **setValue **method to turn it on/off.

That’s it! Congratulations on blinking an LED on Android Things!

If you don’t want to type out these code snippets, you can just head over to https://developer.android.com/things/sdk/samples.html to download the complete, ready to run project. It’s all on GitHub and there you could find a lot of additional code samples as well.

Though still in developer preview, I had a great experience with getting started on Android Things and it was a lot of fun. Feel free to reach out if you have any questions or feedback :)

Building your own keyboard (from scratch)

w4ilun — Sat, 22 Aug 2020 20:10:54 +0000

(Note: these posts are migrated from my previous medium.com blog)

Another interest of mine are computer keyboards. I’ve acquired this interest relatively recently, and have spent many hours since perusing /r/MechanicalKeyboards:

Aren’t these beautiful? They come in all sorts of colors, sizes, lights, layouts, switches, and price. And as a tool that I use everyday, it was easy for me to justify my purchases :)

At the high end, these keyboards are often custom designed and hand assembled: CNC’d aluminum plates, RGB underglow, custom PCB/firmware, etc.

Building one?

As I found out from the /r/MechanicalKeyboard community, there are a lot of members who built their own, and has contributed a lot of their work back to the open source community; from hardware design (e.g. GH60) to software/firmware (e.g. TMK/QMK).

Ever since building my Lego BLE controller, I’ve wanted to take on a more advanced project, and this seemed like the perfect one!

Hardware

A keyboard’s hardware is pretty simple: it’s just a bunch of buttons! The challenge lies in that a typical keyboard has about a 100 keys/buttons; most microcontrollers don’t have that many input pins, and it would be a waste to use them all simply to read buttons. The trick is to use a keyboard matrix (e.g. 5 rows x 15 columns) and quickly cycle through each row/column, allowing you to use 2n pins only for a n *x *n matrix. You can read more about how that works in this excellent article.

For the microcontroller, I chose the popular atmega32u4. It’s got USB support and is also used in the Arduino Pro Micro. The firmware which we will be using later also supports it. The only work that needs to be done is to map our row and column buttons to the microcontroller’s GPIO pins:

Once we have our schematic, now begins the fun part of routing the PCB. In my previous project, I simply used the autoroute feature and let the algorithms do their job. In this design, there were simply too many connections to use that feature, and I wanted a nice clean design (and also throwing in some nice PCB artwork along the way).

I sent in this design to Seeed studio and got it made; I chose a black PCB with white silkscreen. In 2 weeks they showed up:

Software

Luckily for me, there’s already a great open source keyboard firmware project out there, TMK! It already supports a bunch of keyboards and has great documentation on how to customize and compile a build for your own design. The only thing I needed to do was to configure the GPIO pins to the right row and columns and define the keymap, for example:

const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { /* 0: Qwerty * ,-----------------------------------------------------------. * |Esc| 1| 2| 3| 4| 5| 6| 7| 8| 9| 0| -| =| \| `| * |-----------------------------------------------------------| * |Tab | Q| W| E| R| T| Y| U| I| O| P| [| ]|Backs| * |-----------------------------------------------------------| * |Contro| A| S| D| F| G| H| J| K| L|Fn1| '|Enter | * |-----------------------------------------------------------| * |Shift | Z| X| C| V| B| N| M| ,| .| /|Shift |Fn0| * `-----------------------------------------------------------' * |Gui|Alt |Space |Alt |Fn2| * `-------------------------------------------' */ KEYMAP(ESC, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, MINS,EQL, BSLS,GRV, \ TAB, Q, W, E, R, T, Y, U, I, O, P, LBRC,RBRC,BSPC, \ LCTL,A, S, D, F, G, H, J, K, L, FN1, QUOT,ENT, \ LSFT,Z, X, C, V, B, N, M, COMM,DOT, SLSH,RSFT,FN0, \ LGUI,LALT, SPC, RALT,FN2),

Putting it all together

After soldering all of the components and compiling the firmware, I flashed the firmware onto the board over USB using dfu-programmer. To my surprise, everything worked on first try! Typing on it was a lot of fun (for about 2 minutes) and I was pretty happy with the results. Though I probably won’t be using this as my daily driver, I definitely learned a lot about PCB design and embedded development.

You can find all the software and hardware source on my GitHub https://github.com/w4ilun/pocket-keyboard

Building a Bluetooth LE Lego Controller + Web Bluetooth App

w4ilun — Sat, 22 Aug 2020 20:08:38 +0000

(Note: these posts are migrated from my previous medium.com blog)

I’m a big fan of Lego, especially the Technic series. Some of these sets come with Power Functions, which adds motors/servos/lights to the model and lets you control them with an IR remote:

2 of my favourite, the excavator and the Mercedes Benz Arocs

Lego Power Functions

Not all sets come with a remote, and for each channel you would need an IR receiver; wouldn’t it be cool if you could control everything with your phone over Bluetooth?

Power Functions: How Do They Work?

All Lego Power Function connectors have 4 wires; 2 of them carry the +/- 9V from the battery box, while the other 2 provide direction and speed control:

The wires C1 & C2 allows you to control to the motors/servos/lights. Drive one of the wires with PWM and the other at ground to control the speed; swapping the input reverses the direction. A great resource to learn more about the Power Function actuators can be found here: http://www.philohome.com/tech.htm

Concept Diagram

There are 3 main components to this build:

A Bluetooth module for sending/receiving commands
An Arduino to interpret those commands and output PWM signals
A motor controller that can provide enough current to drive the actuators

I would normally just wire all of these components together and call it a day, but this time I wanted a cleaner solution and try creating my own PCB…

PCB Design and Fabrication

Our build is simple enough that you could hand wire everything and be done with it, but where’s the fun in that? Designing your own PCB is a great learning experience that can be both fun and rewarding; it will also help you down the road as you try to tackle more sophisticated projects. There are quite a few free tools out there that let’s you do that now (e.g. KiCad, Eagle, EasyEDA, Upverter, etc.), with tons of online resources to learn how.

I won’t go into details on how to use these tools in this post (YouTube is your friend), but the first step is to turn the concept diagram into a schematic and choosing the right components:

For the main Arduino controller, I chose the Arduino Pro Micro as I have a few of those around. It also has the right number of GPIO pins we need in a small form factor. I chose the 3.3V variation as our Bluetooth module runs on 2.7V — 3.3V.

For the Bluetooth LE module, I chose the HM-10; it’s based on the CC2541 and can be found for a few dollars on eBay. It has a simple UART interface that simply passes through any data you send to it via its custom Service & Characteristic.

For the motor controllers I chose the TB6612FNG from Toshiba. I originally wanted to use the popular L298N as it’s capable of driving more current. Unfortunately, it is commonly found in the Multiwatt15 package, which is too big for my desired form factor. Each TB6612FNG IC can drive 2 channels, so we’ll need 2 of them total. I also threw in some decoupling capacitors to reduce noise (10uF electrolytic and 0.1uF tantalum).

Last but not least, we’ll need 4 pin connectors for the Power Function Lego connectors. We could have soldered the wires directly to the board, but I wanted to keep things modular (plus connectors look nicer). I chose the popular JST XH connectors.

All the above components can be found on DigiKey or eBay. I always order extras in case I mess up the soldering (or when I lose those super tiny SMD components).

The next step is to convert your schematic into a board layout. I chose a 2 layer design and placed the components strategically around the board. The Pro Micro, motor controllers, and connectors go on the top for easy access, while the Bluetooth module goes on the bottom to save space. I also used the auto-route feature so you don’t have to do the routing yourself; I do find, however, that routing your traces manually yields cleaner results. The screenshot above was my first iteration of the design.

Once you are happy with your board layout, you can generate a render of your board. It is a great visual check for any outstanding issues (and it also lets you play around with the design, like adding a Lego man to the silkscreen).

The final step is to generate Gerber files from your design, and sending it off to PCB fabs! Gerber files are the standard for PCB manufacturing, and they serve as instructions for creating the board (e.g. layout, top/bottom silkscreen, drill holes, vias, etc.); think of it as gcode in 3D printing. There are tons of PCB fabs out there but my favourite is OSHpark; they offer quick turnaround times and they also accept KiCAD/Eagle project files, this means you won’t have to generate/convert Gerber files with them and can directly upload your project.

My boards came in 2 weeks after I sent in the designs. I wanted to get a blue PCB like my render, but that costed $10 more :( You can find all of the design files on my GitHub https://github.com/w4ilun/lego-ble-controller/tree/master/hardware

Board Assembly

We only have a few SMD components but they can be tricky to solder if you don’t have steady hands. I used Kester flux and ‘drag soldered’ the SMD components, then did all of the through hole components. An easier alternative would be to use solder paste and put the whole thing in a reflow oven.

You will also need to attach the Lego extension wires to your 4 pin connectors. Make sure you have them in the right orientation by referring to the schematic. You could also solder the extension wires directly to the board without the connectors.

Firmware

The firmware is very basic: read some input string from the serial port and turn on/off the appropriate pins accordingly. Every channel requires 3 GPIO pins to control its direction and speed:

You can find the pin number mappings in the schematic; the code snippet below shows how to turn the motor in one direction at half speed:

digitalWrite(m1en1, HIGH); //CW or CCW
digitalWrite(m1en2, LOW);
analogWrite(m1pwm, 128); //values can be 0-255

For the command protocol, it is simply a string of 4 integer values separated by a #. For example, **128#-255#10#0 **means drive Channel 1 at ~50%, drive Channel 2 at full speed in reverse, drive Channel 3 at 10/255 speed (~4% of max), and brake Channel 4. If a channel is connected to a Lego servo, -255 represents -90 degrees, 0 is center, and 255 represents +90 degrees. Unlike a regular hobby servo, the Lego servo only has 7 steps in each direction, so intermediate values between that range will be ignored (you can learn more about the Lego servo in this YouTube video.

All together, the firmware is simply an infinite loop that waits for commands from the Bluetooth module via serial, then sets the motor direction and speed for each channel. You can find the firmware code on my GitHub https://github.com/w4ilun/lego-ble-controller/tree/master/firmware

Web Bluetooth App

To control our Lego Power Function motors/servos/lights, we will need to talk to our Bluetooth LE module some how. We can create a native mobile app for iOS/Android, or use one of the Bluetooth LE APIs in Python or Node.JS (such as Bleno by @sandeepmistry).

For this project, I’ve decided to leverage the cutting edge Web Bluetooth APIs available in Chrome 45+. You will need to first enable this experimental feature under chrome://flags (though this feature is enabled by default in Chrome 56+)

The cool thing about Web Bluetooth is that it works right from your browser, without needing additional libraries/plugins! It works on both desktop and Android, and you don’t need to download anything extra; simply visit a web page that has Web Bluetooth enabled and you’re presented with option to interact with nearby Bluetooth LE devices. The JavaScript snippet below shows how you can discover devices, connect, discover services/characteristics, and reading/writing to them:

navigator.bluetooth.requestDevice({ filters: [{ services: [service] }] })
    .then(device => device.gatt.connect())
    .then(server => server.getPrimaryService(service))
    .then(service => service.getCharacteristic(characteristic))
    .then(characteristic => {
        characteristicInstance = characteristic;
    setInterval(updateSpeed,200); //send commands every 200ms
    return characteristic.writeValue(str2ab("0#0#0#0"));
    })
.catch(error => { console.log(error); });

The complete code can be found here https://github.com/w4ilun/lego-ble-controller/blob/master/index.html; I’ve also enabled GitHub pages on my repo, so if you built the same controller as I have, you could simply go to https://w4ilun.github.io/lego-ble-controller/ and start controlling your Lego!

I only created 2 control channels in this interface for testing; to expand on this example, you can add additional UI elements (such as toggle buttons, dials, etc.) and simply map them to the command string (CH1#CH2#CH3#CH4, right now CH3 and CH4 default to 0). You can also use your phone’s accelerometer data as input (e.g. deviceorientation ).

Trying It Out

I put together a “car” to test out everything and much to my delight, everything worked perfectly :)

This learning experience has been a lot of fun and I look forward to improving on this design. In the next iteration I plan to consolidate the Bluetooth LE module and the main microcontroller, and not use the Pro Micro + HM-10 (ESP32 perhaps?).

You can find everything you need on my GitHub; I still have a few extra PCBs so feel free to reach out and I’d be glad to send you one to try for yourself.

Enjoy!

Using Web Bluetooth in Chrome to visualize IMU data

w4ilun — Sat, 22 Aug 2020 20:03:04 +0000

(Note: these posts are migrated from my previous medium.com blog)

w4ilun / web-bluetooth-curie-imu

Arduino/Genuino 101 CurieIMU Web Bluetooth Orientation Visualiser

The Web Bluetooth API allows you to interact with Bluetooth LE peripherals from your browser using JavaScript. It’s been available since Chrome 45+, but you’ll have to enable it manually since it’s still an experimental feature. You can check out the API and examples here.

To start, I combined code examples for the Arduino 101 on using the built-in IMU and Bluetooth LE features; all of the Curie’s IMU readings are sent as notifications over Bluetooth LE by updating the characteristic’s value. The sketch below shows how to do so with the CurieBLE and CurieIMU libraries.

On the web side, Chrome’s Web Bluetooth APIs were used to detect, connect, and read notifications from a Bluetooth LE peripheral device (our Arduino 101). For security reasons, all of this is enabled only after the user interacts with the page, so the navigator.bluetooth method is called after you click connect. From then on, you can discover the peripherals services and characteristics; we subscribe to these characteristics and receive IMU data in the callback function:

The IMU data (roll, pitch, & yaw) gets updated, and we update them as globals as well in our script; this allows our Processing.js sketch to read from the global scope the IMU data, and update the canvas WebGL rendering.

Since everything is done in Chrome and no additional server side processing is required, I hosted everything on GitHub pages, so everyone can try it out for themselves https://w4ilun.github.io/web-bluetooth-curie-imu/

You can also find all of the code above on GitHub: https://github.com/w4ilun/web-bluetooth-curie-imu

Enjoy!

Building an IoT power switch with the ESP8266 (and control it with your Amazon Echo!)

w4ilun — Sat, 22 Aug 2020 19:58:09 +0000

(Note: these posts are migrated from my previous medium.com blog)

*Cut to the chase, show me the build!

The ESP8266 is an amazing little module that packs WiFi connectivity and Arduino support for a little over $2 (less if you buy in bulk):

I first heard of this module about a year ago and was attracted by its price point and form factor. At the time, there weren’t a lot of system on a module (SOM) options for prototyping that included connectivity; often, you would have to add on an expensive and bulky WiFi/Bluetooth shield to your project.

The biggest appeal of this module to me however, was the support of NodeMCU: a LUA runtime on the module, with networking and I/O APIs that makes it very easy to perform common tasks such as:

WiFi Config (connecting, setting/saving the SSID, credentials)
Performing HTTP requests, creating an HTTP server
Use the hardware I/O (GPIO, I²C, PWM, etc.)

This was great! I immediately ordered a whole bunch of these (10+) for the many, many IoT projects I thought I would build. I started by building the IoT equivalent of Hello World: Blinking an LED from a browser:

A few weeks later, while casually browsing through my regular sites, I came across this piece of exciting news:

w00t! Arduino support! This meant the module would have access to the vast number of libraries and extensions in the Arduino ecosystem. You could now easily use this module with MQTT, Web Server, Neopixels, Firmata (hence, Johnny-Five!), and many, many more.

Arduino support helped this module gain popularity, and at the same time, the number of board/breakout offerings grew. Most of these boards aim to make development easier by including features like pin breakouts, voltage regulation, reset buttons, USB-Serial converters, etc.

This was all exciting news, but I honestly had no projects in mind. These awesome little modules were tucked away in my toolbox for the next little while…until my GE Lighting smart bulbs stopped working :(

Well, what to do? I can’t go back to using a mechanical switch (*gasp)! I’ve grown accustomed to shouting at my lights to turn them on/off. Time to dust off those ESP8266's and make something!

Building an IoT power switch

1. Bill of Materials (you’ll need these things)

Electronics

ESP8266 module
Solid State Relay (no clicking sounds, yay!)
AC-DC Power Supply 110/220V to 3.3V
Wires (for low voltage DC connections)

Hardware

Electrical Box (for all the components)
Duplex Outlet (socket)
Wall Plate (to hide everything in the box)
Extension Cord (for the socket plug and mains wires)

Tools

Soldering Iron
Glue gun (for insulating any mains connections, be careful!)
USB-Serial adapter (for programming the module)
Jumper Cables/Breadboard

2. Programming your ESP8266

You’ll want to start by programming your ESP8266 with a USB-Serial adapter. The other boards out there (such as the NodeMCU dev board) might have the adapter built in, for those you’ll just need to plug it into your USB port.

With our adapter, connect the pins according to the above diagram using your jumper wires/breadboard. Note the orange line in the above diagram: the pin GPIO0 needs to be pulled to GND during boot in order to flash it, make sure this is done before connecting it to your computer.

You’ll also want to install the ESP8266 toolchain from the Arduino Boards Manager. Type in “esp8266” and install the latest version:

Once installed, you can browse through the bundled examples and play around with the API; you’ll find examples on HTTP servers, sending/receiving UDP packets, connecting to a network, etc. Our project is built on top of these APIs.

3. Amazon Echo, UDP/TCP, & WeMo Spoofing

The Amazon Echo is my smart home hub; all the “smart things” in my home can be controlled via voice with the Echo, thanks to the incredible job it has done to integrate with different smart devices on the market.

The simplest way we can get the Echo to discover and control our ESP8266, is by spoofing as a device supported by the integration, such as a Belkin WeMo switch!

Device discovery is achieved through UPnP broadcast over UDP, the ESP8266 simply needs to spoof the response to pretend to be a supported device (such as the WeMo)

The response looks something like this:

While browsing through the different sites detailing the protocol and data exchange, I came across this incredible GitHub project that has everything I need: WeMo spoofing with the ESP8266!

kakopappa / arduino-esp8266-alexa-wemo-switch

Amazon Alexa + WeMos switch made with Arduino D1 Mini

**Update** the author has an updated the repo to support multiple switches!

kakopappa / arduino-esp8266-alexa-multiple-wemo-switch

multiple belkin wemos switch emulator using ESP8266

Looks like my work is done!!! I edited the WiFi credentials to match my home network and gave the code a go. I told my Echo to discover devices and monitored the serial terminal:

Did it work? Let’s check the app!

So it found my ESP8266! The default name for the device is “box”, set by the String device_name in the code, but I assume it can be named anything (not sure what the rules are, probably best to stay away from symbols and numbers).

Now let’s try some commands! I hooked up a green LED to GPIO2 and yelled “Echo, box on!”

4. Putting It Together

To create out IoT power switch, we just need to swap out the green LED for our solid state relay, and connect all the wires. Here’s the wiring diagram:

Be careful when working around mains AC! I used my glue gun to insulate all the mains connections (exposed PCB traces, wires, etc.).

Now stuff everything in your project box and make sure there are no shorts. Screw on the duplex outlet and the wall plate onto the box:

5. All Done!

The solid state relay is rated for 40A so you could connect this IoT power switch to a lot of different appliances (e.g. a 12,000 BTU air conditioner draws about 10A). Mine’s connected to only 3 LED bulbs, which is well within the relay’s constraints.

The whole project cost me about $10 and 2 hours of time (thanks to kakopappa’s GitHub project!). Time to make use of my ESP8266 stash!

Control your Intel Edison in Realtime with Websockets (and ngrok)!

w4ilun — Sat, 22 Aug 2020 19:42:33 +0000

(Note: these posts are migrated from my previous medium.com blog)

First off, I would like to thank Nathan Meryash for his suggestions! In my next few posts, I will describe using different cloud services and technologies for your IoT project.

Following up with Control your Intel Edison in Realtime with Websockets!, this post briefly describes how you could expose your connected device to the public web using ngrok. This is useful if you would like to be able to control your device from outside of your home network, without having to setup port forwarding and/or DDNS.

ngrok is a service that “exposes a local server behind a NAT or firewall to the internet”. There is no signup required and you get a public URL accessible from the Internet!

There are 2 additional packages that you would need to install:

npm install ngrok --save
npm install express-dot-engine --save

ngrok: an npm module for using ngrok. It allows you to programmatically create a new ngrok instance URL (e.g. https://571a6a18.ngrok.io) and bind it to your local server IP and port.

**express-dot-engine: **a lightweight template engine for embedding our ngrok URL into our index.html file

Here is the new code that has been updated to include the use of ngrok and the dot template engine with Express:

Then, simply run:

node blinkWithSocketsNgrok.js

…and go to the generated URL from anywhere on the web!

$2 Bluetooth Tags and Tangible UIs for IoT

w4ilun — Sat, 22 Aug 2020 19:34:53 +0000

(Note: these posts are migrated from my previous medium.com blog)

I have a “smart” home. All the lighting in my home is wirelessly connected and I also have a “smart” outlet that lets me turn any appliance on/off that’s connected to it. It was one my first purchases on my quest to “internet all the things” at home.

Installation was relatively painless and I enjoyed the novelty of being able to control everything through my phone. It lasted about a full week before I found it quite inconvenient that I have to:

pick up my phone
unlock my phone
load the app
find my device
…then finally clicking the adorable lightbulb drawing to turn on the lights.

My “smart” home doesn’t feel so smart when turning on the lights is now 5 steps instead of the flick of a switch. Of course, this is ignoring the fact that I could also set schedules, dim lights, set scenes, and do all of that from anywhere in the world. But for my day to day operation, this experience feels much worse than it’s “dumb”equivalent.

Interacting with IoT devices has always been an interesting problem to me. A lot of “smart appliances” and connected devices on the market still rely on a smartphone app for controlling and configuring them. While this makes sense for more complex devices that benefit from a rich GUI (e.g. Dropcam), and/or for devices that are highly automated where very little daily interaction is required (e.g. NEST thermostat), it makes less sense for simple devices that are frequently operated.

That is part of the reason why I love my Amazon Echo; its voice based UI (aka Alexa) was a much better experience when interacting with the smart devices in my home. Now all I have to do is say “Echo, lights off” (I can’t help but feel like Iron Man and J.A.R.V.I.S. every time I do this)

But sometimes I don’t want to talk. Sometimes I’m far away and I don’t want to yell. Sometimes people are sleeping and I don’t want to make a noise. I missed my simple wall switch that didn’t have any of these problems.

Enter the (tangible) button

I did some research to find a solution (and often, the solution is to buy more things) and I came across the FLIC button, a small BLE button that you could stick anywhere, and program it to do things.

This solved my problem! It looks like a well engineered product, and also has a very nice app to complement! With IFTTT integration, the possibility are endless.

…but it’s also $35 and I don’t want to pay that price. Don’t get me wrong, I think this price is well justified for all the R&D and design work that has gone into this product (hardware and software). I just couldn’t justify myself buying this particular gadget, given the amount of Arduinos, RPis, Edisons, and BLE/ZigBEE/LoRA/ZWave modules that I had lying around; I wanted to build something.

Enter the ($2) tangible (BLE) button

A quick search on eBay brought me to this interesting little gadget; a BLE button/tag/tracker device that’s meant to serve as a selfie button, but also doubles as a tag that beeps if your paired phone goes out of range. You could also use it as a keychain, and trigger the tag to beep to find it. The description was loose on details, but at $2 I just had to give it a try.

Experimenting with the button

I turned to my favourite BLE library noble by @sandeepmistry to do some service and characteristic discovery (e.g. noble.startScanning(), peripheral.discoverServices()):

GENERIC ATTRIBUTE
IMMEDIATE ALERT
TX POWER
LINK LOSS
BATTERY SERVICE
CUSTOM SERVICE 1
CUSTOM SERVICE 2

Of which CUSTOM SERVICE 1 was the one that was most interesting to me right now, because it had a characteristic with the notify property. You can subscribe to this characteristic and get notified with the value 0x01 when the button is pressed.

So after all that, it was just a matter of hooking the characteristic’s notify callback into the APIs that controlled my “smart” home:

Enjoy :)

Experimenting with Google’s Cloud Vision API + Intel Edison

w4ilun — Sat, 22 Aug 2020 19:31:38 +0000

(Note: these posts are migrated from my previous medium.com blog)

I first learned about Google’s Cloud Vision API at this year’s Google I/O. Though it’s been out in beta since 2015, I had not heard of it, nor had the chance to try it out till today. I came across this blog post and was intrigued by the YouTube demo:

As always, I have an Intel Edison lying around so I decided to give it a try.

Before you begin:

Make sure your Edison has been updated to the latest firmware and has Wi-Fi setup, use the setup/configuration tool found here to do so.

You will also need a Google Cloud account with the Vision API enabled. Follow these instructions here to do so before proceeding.

Things you’ll need:

Intel Edison w/ Arduino Breakout Board (You could also use the mini breakout but you might need a USB adapter to connect a webcam
Logitech C270 Webcam (Any other USB webcam supported by Linux UVC drivers would work too)
Power Supply

Here’s how it’s all connected:

Let’s go!

For the USB webcam to work, make sure UVC drivers are installed and enabled; you can find instructions here on how to do that.
Install ffmpeg. Git clone the edi-cam repository and run the shell script to install ffmpeg:
```
root@edison:~# cd /edi-cam/bin
root@edison:~# ./install_ffmpeg.sh
```
1. Install gcloud. This is the Google Cloud NodeJS module that allows you to easily use Google Cloud APIs.
  
  root@edison:~# npm install gcloud
2. Copy over your service account key JSON created during setup (scp/sftp). You can create a new one here if you’ve lost it.
3. Run the code! Copy & Paste this snippet into VIM or transfer the file over:

root@edison:~# node capture.js

Results

Here’s the image that was captured by my webcam:

And here’s the returned JSON:

root@edison:~# node capture.js

[ { desc: ‘cartoon’, mid: ‘/m/0215n’, score: 85.945672 },

{ desc: ‘machine’, mid: ‘/m/0dkw5’, score: 74.98506900000001 },

{ desc: ‘robot’, mid: ‘/m/06fgw’, score: 69.911 },

{ desc: ‘gadget’, mid: ‘/m/02mf1n’, score: 67.246151 } ]

…I thought that was pretty cool :)

The Google Cloud Vision API actually has a lot of other powerful features, including analyzing emotional facial attributes, text extraction & detection, and detecting any [faces, landmarks, labels, logos, properties] in your images.

Vision capabilities perfectly complement robotic applications (e.g. a drone that tazes you if you’re not smiling, a spray paint bot that corrects graffiti grammar, etc.). I can’t wait to see what kind of cool things people will make with this!

Real time sensor data from the Intel Edison via Websockets

w4ilun — Sat, 22 Aug 2020 19:23:45 +0000

(Note: these posts are migrated from my previous medium.com blog)

It’s been a while since my last post Control your Intel Edison in Realtime with Websockets! There’s been tons of updates on documentation, tools, and libraries that allow setting up and development a lot easier. Check out the downloads page to get the new installer and latest firmware.

The following tutorial assumes an Intel Edison already updated and setup with connectivity. If you have a fresh out of the box Intel Edison, please follow this guide or my previous post.

1. Read sensor data using the UPM repository

UPM is a high level repository for sensors/actuators that uses MRAA. Check out the list of supported sensors here. If the sensor you are using is already supported by UPM, you will save a lot of time by getting a high level interface.

If the sensor you are using is not found in UPM, feel free to submit an issue or a pull request on Github. You can of course always use MRAA to read raw data from your sensor (e.g. via Analog, I²C, SPI, UART, etc.)

For this tutorial, I will be using the temperature sensor from my Grove Starter Kit:

This temperature sensor uses a thermistor to detect temperature. A thermistor is a device that will change its resistance when the temperature changes. By measuring the voltage output from this sensor with an analog pin, we are able to determine the temperature by looking up the sensor’s datasheet. Luckily for us, UPM has done that for use already. Learn more about thermistors here.

I connected my temperature sensor to analog pin A0, as shown in the picture below:

UPM supports the Grove Temperature Sensor and also includes example code. I am going to wget the example code on my Intel Edison and run it:

…and you should see the following output:

If you look at the code in grovetemp.js, you will see that it is basically instantiating the temperature sensor object and repeatedly calling temp.value() to get the latest temperature reading.

2. Pushing sensor data via Websockets

Well that was easy :) Now all we have to do is push this data via websockets to a UI, using Socket.IO like the last tutorial:

Put these two files on your Intel Edison and run:

node tempsensorsocket.js

Be sure to have express and socket.io installed already, and change the IP address in index.html

You should be seeing the live temperature data in your browser, try touching the sensor to see the temperature go up :)

In 40 lines of code we were able to stream live temperature sensor data via websockets! This is only possible with great open source libraries like Socket.IO, Express, UPM, and MRAA.

This tutorial itself serves as a starting point and there are tons of other things you could add on to it. A fancy CSS dashboard? Cloud Analytics? Turning on your AC when it gets too hot? Start the sprinklers?

What will you make?