Morphing Digital Clock Will Show You A Good Time

A few weeks ago, [HariFun] set out to emulate a 7-segment display with an LED matrix. Seems easy enough, right? Right. He also wanted to come up with a new way to transition between digits, which is a much harder task. But he did it, and it’s really cool. At a viewer’s suggestion, [Hari] used the transition as the basis for a mesmerizing clock that brings the smooth sweep of an analog second-hand into the digital age.

This is the coolest way to watch the time pass since the hourglass. You can almost hear the light move as one digit slides into the next. Each transition is totally unique, so depending on the digit this involves one or more vertical segments sliding from right to left, or multiple segments moving in a counter-clockwise circle.

You too can watch time glide by with little more than a 64×32 RGB LED matrix, a NodeMCU, and [Hari]’s digit transition code. It only costs about $25 to build, and you really can’t beat the quality of instruction he’s put together. Take a second or two and check it out after the break.

If you prefer OLEDs and vertical transitions, there’s a clock for that, too.

Continue reading “Morphing Digital Clock Will Show You A Good Time”

Move Aside Mercury: Measuring Temperature Accurately with an RTD

Temperature is one of the most frequently measured physical quantities, and features prominently in many of our projects, from weather stations to 3D printers. Most commonly we’ll see thermistors, thermocouples, infrared sensors, or a dedicated IC used to measure temperature. It’s even possible to use only an ordinary diode, leading to some interesting techniques.

Often we only need to know the temperature within a degree Celsius or two, and any of these tools are fine. Until fairly recently, when we needed to know the temperature precisely, reliably, and over a wide range we used mercury thermometers. The devices themselves were marvels of instrumentation, but mercury is a hazardous substance, and since 2011 NIST will no longer calibrate mercury thermometers.

A typical Pt100 RTD probe

Luckily, resistance temperature detectors (RTDs) are an excellent alternative. These usually consist of very thin wires of pure platinum, and are identified by their resistance at 0 °C. For example, a Pt100 RTD has a resistance of 100 Ω at 0 °C.

An accuracy of +/- 0.15 °C at 0 °C is typical, but accuracies down to +/- 0.03 °C are available. The functional temperature range is typically quite high, with -70 °C to 200 °C being common, with some specialized probes working well over 900 °C.

It’s not uncommon for the lead wires on these probes to be a meter or more in length, and this can be a significant source of error. To account for this, you will see that RTD probes are sold in two, three, and four wire configurations. Two-wire configurations do not account for lead wire resistance, three-wire probes account for lead resistance but assume all lead wires have the same resistance, and four-wire configurations are most effective at eliminating this error.

In this article we’ll be using a 3-wire probe as it’s a good balance between cost, space, and accuracy. I found this detailed treatment of the differences between probe types useful in making this decision.

Continue reading “Move Aside Mercury: Measuring Temperature Accurately with an RTD”

Internet of Smells: Giving a Machine the Job of Sniffing Out Spoiled Food

Has the food in your pantry turned? Sometimes it’s the sickening smell of rot that tells you there’s something amiss. But is there a way to catch this before it makes life unpleasant? If only there were machines that could smell spoiled food before it stinks up the whole place.

In early May, I was lucky enough to attend the fourth FabLab Asia Network Conference (Fan4). The theme of their event this year was ‘Co-Create a Better World’. One of the major features of the conference was that there were a number of projects featured, often from rural areas, that were requesting assistance throughout the course of the conference.

Overall there were many bright people tackling difficult problems with limited resources. This is how I met [Yogesh Kulkarni] who runs a FabLab in Pabal, a farming community not far from Pune, India. [Yogesh] has also appeared on TED Talks (video here). He explained to me that in his area, vendors sell milk-based desserts. These are not exactly refrigerated, and sometimes people become ill from eating them. It would be nice if there was a way for the vendors to avoid selling the occasional harmful product.

I’ve had similar concerns with food safety in my area (Vietnam), and while it has been fine nearly all of the time, a few years ago I nearly died from a preventable food-borne illness. I had sufficient motivation to do a little research.

Continue reading “Internet of Smells: Giving a Machine the Job of Sniffing Out Spoiled Food”

Simple Ethereum Vending Machines with NodeMCU

Recently, we covered how to use the Etherscan API to query data (a wallet balance) from the Ethereum blockchain with NodeMCU. It’s a very useful method for retrieving information from a blockchain on embedded systems where storage and memory are an issue.

It has some limitations though. Most notably, it’s polling the API at some interval to retrieve information whether it has changed or not. I would like to be able to receive data more efficiently than this, and quickly enough to make simple vending machines possible. While we’ve seen videos of Bitcoin-based Red Bull vending machines before, they required an NFC card to use.

If we could receive information about Ethereum transactions quickly and reliably enough, we could build a similar vending machine without requiring an NFC card as an intermediary. Simply send to an address via some method, and receive goods!

It turns out we can do exactly that with NodeMCU using WebSocket. Like HTTP, WebSocket is a communications protocol that uses TCP connections (typically over port 80), but it allows full-duplex communication. In other words, you can establish a connection to a server, and send/receive messages without needing to poll the server.

As in the previous example, we’ll use a NodeMCU running Lua. You may wish to refer to it for compile options and information about the screen, which will be the same in this case. Unlike the previous article, you will not need an API key from Etherscan to use this service (not yet, anyway). As usual, we’ll start off by connecting to WiFi:

wifi.setmode(wifi.STATION)
wifi.setphymode(wifi.PHYMODE_B)
station_cfg={}
station_cfg.ssid="Your SSID"
station_cfg.pwd="Your Password"
station_cfg.save=true
wifi.sta.config(station_cfg)

Connecting to a server with WebSockets is easy, but since we’re not using HTTP, we’ll have to remove the https:// and replace that with ws://. (Note: not wss:// because we’ve not enabled encryption yet.)

ws:connect(‘ws://socket.etherscan.io/wshandler’)

Next, we need to report back when the connection is established as the trigger to run additional code. It will return an error code if the connection fails to be established. Handling these error codes in a sensible way is an excellent feature, but we’ll handle that later:

ws:on("connection", function(ws)
    print('got ws connection')
    end)

Now, we need to extend the above to subscribe to an Eth address, and add some new code to do something when a transaction occurs. Note that the API requires that you subscribe to an address within 60 seconds of connecting. It also states that you have to send a ping event to the server every 20 seconds to keep the connection alive, so we’ll need to set a recurring timer for that.

If you’re using ESPlorer, you can send the ping request manually by entering =ws:send('{"event": "ping"}') and pressing Send. This is a useful way to test the connection status.

The address I used seems to have frequent transactions so is reasonable for testing. Be advised though that sitting and waiting for a transaction to happen to test the code creates a slow development cycle so some patience is necessary here.

ws = websocket.createClient()
ws:on("connection", function(ws)
    print('got ws connection')
    ws:send('{"event": "txlist", "address": "0x2a65aca4d5fc5b5c859090a6c34d164135398226"}')
    end)

ws:on("receive", function(_, msg, opcode)
    print('got message:', msg, opcode)
    end)

You should see something like what follows below. The first message is a simple confirmation of connection, the second confirms your subscription to an address, and the third is what you get sent when a transaction occurs. You can subscribe to up to 30 addresses with a single connected device! Note that the data is all in JSON format, which is something we’ll take advantage of later.

got message: {"event":"welcome"} 1
got message: {"event":"subscribe-txlist", "status":"1", "message":"OK, 0x2a65aca4d5fc5b5c859090a6c34d164135398226"} 1
got message: {"event":"txlist","address":"0x2a65aca4d5fc5b5c859090a6c34d164135398226","result":[{"blockNumber":"5532531","timeStamp":"1525098009","hash":"0xe5ec497cb5b38811e8bf5db67a056a2bdd4aa9b68df5c8e8225cb300cbcfa413","nonce":"3363391","blockHash":"0xf446f77d92ed29c221e8451b8048113969ed305a7dd49177e10b422e8e2c4bda","transactionIndex":"172","from":"0x2a65aca4d5fc5b5c859090a6c34d164135398226","to":"0xec5fdfba35c01c6ad7a00085e70e8f30cd121597","value":"24418350000000000","gas":"50000","gasPrice":"4000000000","input":"0x","contractAddress":"","cumulativeGasUsed":"7896403","gasUsed":"21000","confirmations":"1"}]} 1

That’s quite a mess of transaction data, and unfortunately the datum of interest is in the ‘result’ field – which is nested JSON. In the last article, we converted simple JSON to a Lua table using the excellent sjson module. We’ll do the same here after verifying the message type is a transaction (txlist).

ws:on("receive", function(_, msg, opcode)
    print('got message:', msg, opcode)
    ok, ethdata = pcall(sjson.decode, msg)
    if ok then
        msgtype = (ethdata["event"])
        if msgtype == "txlist" then
...

The NodeMCU documentation specifically notes that nested JSON can cause out-of-memory errors. For that reason we use pcall (protected call) to contain any such errors when decoding our JSON message. Next, we extract the contents of the ‘value’ field, nested within the ‘result’ field:

if msgtype == "txlist" then
    wei = ethdata.result[1].value
    print (wei)
    eth = wei/1000000000000000000
    print (eth)
    end

It took me a few hours to figure out how to deal with nested tables, but in the end it was actually quite clean and easy — I was just being dense. Now, we need to add a basic provision to handle errors when the websocket is closed:

ws:on("close", function(_, status)
    print('connection closed', status)
    print('Reconnecting...')
    ws = nil -- required to Lua gc the websocket client
    tmr.alarm(0,4000,tmr.ALARM_SINGLE,transact) -- This reconnects after 4 seconds
end)

To wrap it all up, we encase the code in a couple of functions — first, one to establish a connection, subscribe to the right address, and notify when there is a transaction. Next we need one to display the amount of Eth transferred. Finally, we need a ‘ping’ function to call every 20 seconds or less to keep the connection alive. Overall this turned out to be more robust than expected and has yet to encounter an error. Check out the full code listing here. Note that I’ve also added a little code above to interface with a 128×32 OLED screen, the same one we used previously.

Now that it works, let’s consider im/practical applications. It’s a neat way to display Ethereum transactions in real-time, say if you do livestreaming and accept Eth donations and want them to trigger something fancy. Or, you could make a somewhat insecure vending machine. Clearly, getting a secure WebSocket up and running is the next order of business.

You could also set a timer where the length depends on the amount of Eth received. This would allow for things like public advertisements that go away for a while if someone pays a fee. (Please don’t do this!) Maybe a conference room for rent with the power controlled this way? Hackerspace membership payment? An electric bicycle that charges you for power used?

In any case, it’s not legal to use cryptocurrency as a form of payment in my country so I can’t implement any of the above examples at this time. If you’ve got a better application, please share it in the comments!

Accessing Blockchain on ESP8266 Using the NodeMCU Board

Blockchains claim to be public, distributed, effectively immutable ledgers. Unfortunately, they also tend to get a little bit huge – presently the Bitcoin blockchain is 194GB and Ethereum weighs in at 444GB. That poses quite an inconvenience for me, as I was looking at making some fun ‘Ethereum blockchain aware’ gadgets and that’s several orders of magnitude too much data to deal with on a microcontroller, not to mention the bandwidth cost if using 3G.

Having imagined a thin device that I could integrate into my mobile phone cover (or perhaps… a wallet?) dealing with the whole blockchain was clearly not a possibility. I could use a VPS or router to efficiently download the necessary data and respond to queries, but even that seemed like a lot of overhead, so I investigated available APIs.

As it turns out, several blockchain explorers offer APIs that do what I want. My efforts get an ESP8266 involved with the blockchain began with two of the available APIs: Ethplorer and Etherscan.

Continue reading “Accessing Blockchain on ESP8266 Using the NodeMCU Board”

Simple Decoder Serves as Solo Ham’s Test Buddy

For a hobby that’s ostensibly all about reaching out to touch someone, ham radio can often be a lonely activity. Lots of hams build and experiment with radio gear much more than they’re actually on the air, improving their equipment iteratively. The build-test-tweak-repeat cycle can get a little tedious, though, especially when you’re trying to assess signal strength and range and can’t find anyone to give you a report.

To close the loop on field testing, [WhiskeyTangoHotel] threw together a simple ham radio field confirmation unit that’s pretty slick. It relies on the fact that almost every ham radio designed for field use incorporates a DTMF encoder in the microphone or in the transceiver itself. Hams have used Touch Tones for in-band signaling control of their repeaters for decades, and even as newer digital control methods have been introduced, good old analog DTMF hangs in there. The device consists of a DTMF decoder attached to the headphone jack of a cheap handy talkie. When a DTMF tone is received, a NodeMCU connected to the decoder calls an IFTTT job to echo the key to [WTH]’s phone as an SMS message. That makes it easy to drive around and test whether his mobile rig is getting out. And since the receiver side is so portable, there’s a lot of flexibility in how tests can be arranged.

On the fence about ham as a hobby? We don’t blame you. But fun projects like this are the perfect excuse to go get licensed and start experimenting.

Continue reading “Simple Decoder Serves as Solo Ham’s Test Buddy”

Storm Detector Modules: Dancing in the Rain

Earlier, we had covered setting up an AS3935 lightning detector module. This detector picks up radio emissions, then analyzes them to determine if they are a lightning strike or some other radio source. After collecting some data, it outputs the estimated distance to the incoming storm front.

But that only gets you halfway there. The device detects many non-lightning events, and the bare circuit board is lacking in pizzazz. Today I fix that by digging into the detector’s datasheet, and taking a quick trip to the dollar store buy a suitable housing. The result? A plastic plant that dances when it’s going to rain!
Continue reading “Storm Detector Modules: Dancing in the Rain”