A few small tweaks to the YouTube player UI for Android have caused a few issues of late - digital issues. And by digital, I mean digits, as in fingers. In summary: it's hard to touch stuff right.

You see, the YouTube app for Android has been experimenting with this new player UI for some time now, but as it rolls out to more and more users, some issues are cropping up.

New button layout in Android's YouTube player UI is fomenting finger frustrations was written by the awesome team at Android Police.

Hovertext: Dad! It's 3AM! I don't wanna paint the shed again!

I wanted to try my hand with ESP8266 modules, so I got a witty cloud development board. It's running a proprietary firmware from gizwits which I backed up if anyone wants to look at it.

The board is in two parts: programming board("cape") with ch340g usb serial and 3.3V converter (plus flash and reset buttons); and main board with the esp module, ams1117 3.3V voltage regulator, a button, a blue led, an rgb led, and a light sensor(photo resistor). All this for the price of a nodemcu board, but in a smaller form factor.

One of the greatest things of the ESP8266 ecosystem is nodemcu-firmware, an environment allowing you to program the microcontroller in lua, greatly simplifying the prototyping and familiarization.

After backing up the flash with esptool (see esptool read_flash), I flashed the latest release of nodemcu-firmware. Then, using nodemcu-uploader, one can access the lua REPL (nodemcu-uploader terminal) and uploads lua scripts (nodemcu-uploader --baud 9600 upload init.lua); init.lua being the first script being run at powerup.

Quick doc

I reverse-engineered the various goodies that are on board, since I didn't find any documentation on this specific board online:

Blue LED: use the PWM 4. High duty cycle = OFF.

-- Use a LED with a 500Hz PWM
function led(pin, level)
    pwm.setup(pin, 500, level)
    pwm.start(pin)
end

-- Control the Blue LED: 0 -> 1023 higher means light off
function blueLed(inverted_level)
    led(4, inverted_level)
end

blueLed(10) -- test at high intensity

RGB LED: use PWMs 8, 6, 7. High duty cyle = ON.

-- Control an RGB LED: three 0->1023 values; higher means more light
function rgb(r, g, b)
    led(8, r)
    led(6, g)
    led(7, b)
end

rgb(500, 0, 0) -- test RED

Button: GPIO 2. button pressed = 0 level.

-- launch connect() on button press
gpio.mode(2, gpio.INPUT)
gpio.trig(2, "down", connect)

Light sensor: use the ADC.

-- Print light sensor value
print(adc.read(0))

Going further

I then discovered the official nodemcu-firmware documentation currently points to the dev branch; which has many new modules and functions I wanted to use (like the wifi event monitor or http module) that weren't available in master yet. I used the nodemcu cloud builder, a service provided by a kind community member to build a custom version of nodemcu-firmware on the dev branch and the modules I needed enabled.

This allows to do this kind of code, that connects to wifi on a button press, and reacts with a simple HTTP request:

function connect()
    -- if wifi is already connected (config saved), launch job directly
    if wifi.sta.status() == wifi.STA_GOTIP then
        doOnlineJob()
        return
    end
    rgb(1000, 50, 0) -- turn orange
    for event=wifi.STA_IDLE,wifi.STA_GOTIP do
        wifi.sta.eventMonReg(event, monCallback)
    end
    wifi.sta.config("mynetworkssid", "mynetworkpassword")
    wifi.sta.eventMonStart(100) --the event mon polls every 100ms for a change
end

function monCallback(prevState)
    state = wifi.sta.status()
    if prevState == nil then
        prevState = "unknown"
    end
    print("Wifi status " .. prevState .. " -> " .. state)
    blueLed(state*204) -- led intensity depends on status, with success = OFF
    if state == wifi.STA_GOTIP then
        rgb(0, 200, 150) --blue/green-ish, wifi OK
        print("Got IP " .. wifi.sta.getip())
        wifi.sta.eventMonStop("unreg all") -- stop event monitor
        doOnlineJob()
    end
    if state == wifi.STATION_NO_AP_FOUND or state == wifi.STATION_CONNECT_FAIL then
        rgb(150, 0, 0) -- red/fail
        wifi.sta.eventMonStop("unreg all") -- stop event monitor
    end
end

function doOnlineJob()
    rgb(150, 0, 150) -- working, purple
    http.post("http://example.invalid/api/pushed", nil,
        '{"hello": "from_esp_witty_42"}', function(status_code, body)
            if status_code == nil or body == nil then
                print(status_code)
                print(body)
                rgb(200, 0, 0) --fail red
                return
            end
            print("Got code " .. status_code .. " answer " .. body)
            if status_code == 200 then
                rgb(0, 0, 200) --success, blue
            end
        end)
end

This is reproducing the software function of the DASH/IoT Button, Netflix Switch or Flic.

There are a few projects that will guide you through the hardware part of building a button with an ESP module.

PS: Be careful of big https cert chains, there's a hardcoded limit of 5120 bytes for the SSL buffer in the firmware, that might make the handshake fail.

Recently, I was the studying the Beacon technology, and more precisely the Eddystone format.

Beacons are cheap devices that could be deployed anywhere that has a meaning for your business, for the city but even more importantly, for the user. (If you want to know more about beacons, I gave a talk at DroidconParis in november 2015, so check out the video).

I also participated at a hackathon on Intelligent Mobility early October 2015 in Bordeaux, France. There, I exposed two solutions for solving a global problem that lots of cities are facing (regarding the Public Parking Places).

I made the local news :)

Problem

I live in a big city, and if you are a car driver living in that kind of big city, you should probably know that it’s a nightmare to find a public parking place available. We often waste a huge amount of time looking for a place, we get stressed, we pollute, we generate congestion. That should end, and for good.

Solution #1

Of one the solution could be to deploy and glue Beacons on the field and thus, equiped each public parking place with a beacon. The beacon would have an extra proximity sensor that could detect whether a car is parked above it or not. Thus, we could have, in real time, a network of availability places in the city.
Based on this real time data, a simple mobile application could then drive you to the nearest public parking place in the city.
It is a cheap investment for the city (glue-ing a beacon on each place) but could dramatically de-congestion the traffic.

Cons of solution #1

The solution #1 is cost effective but has some limitation. Firstly, an enhanced beacon has to be designed. This enhancement requires R&D to include a power efficient proximity sensor on top of the beacon.
Also, the beacon has to be rugged so is won’t break out on the car’s weight. Also, it has to be protected from weather (snow, rain…). So this enhanced beacon requires some technical challenges.

Solution #2

The solution #1 is a good candidate for solving our issue, but requires more engineering. The idea is to find a solution that is simple and easily deployable. That’s solution #2.

Instead of deploying and glue-ing beacons on each public parking place, what about having a beacon inside each car, in the glove compartment ? This beacon would stay is the driver’s car and paired with driver’s smartphone. So, whenever the driver is parked and is leaving his car, his smartphone is able to detect that he is moving away from his car (because beacon is all about range, so you can easily detect that you are in or out of the range of your beacon).

Having this information, your smartphone knows that your car is parked now and that in this precise location, the parking place is no more available.
Similarly, when you are getting back to your car, your smartphone will detect the beacon and then consider that you will leave the parking place. This information could then be broadcasted and anyone who is looking for a parking place in the area could be notified of that availability.

What’s next ?

I highly think that this will solve for good the issue of parking your car in any big city.
In term of investment, the city could give away a beacon for each driver, for free. The investment is really low compared to the issue it is solving (less pollution, less congestion, less stress, more happyness).

If you want to be part of that adventure and make the world a better living place, please contact me, I would be more than happy to have your collaboration.

Hovertext: The silk neckerchief bubble was a dandy catastrophe.

Last year's lineup aside, a good balance of specs and price has become a hallmark of Google's Nexus line, but this year not everyone around the world will be getting the same bang for their buck.If buck. If you live in Europe, you may end up paying over 40% more for a Nexus phone than stateside, and you won't receive Google's $50 Play credit either. stateside.

We've gathered the prices from several countries for both Nexus phones, as well as the Chromecast, and arranged the numbers out in the table below for your viewing pleasure.

Prices For Nexus 5X, Nexus 6P, And Chromecast 5X And Nexus 6P Across The Globe was written by the awesome team at Android Police.