Alexa And Particle Modernize Coffee Machine By One Iota

When [Steve Parker]’s girlfriend got a tea kettle that takes voice commands, he suddenly saw his fancy bean-to-cup coffee machine as a technological dinosaur. It may make good coffee, but getting the DeLonghi going is inconvenient, because it runs a self-cleaning cycle each time it’s turned on or off.

Thus began [Steve]’s adventure in trying to turn the thing on with Alexa via Particle Photon. Because of the way the machine is designed, simply adding a relay wouldn’t do—the machine would just turn off and back on, only to start the self-clean again. Once inside, he found it’s controlled by a PIC18LF2520. Further research indicated that it is powered by an off-line switcher that combines a power MOSFET with a power supply controller. [Steve] figured out that the buttons are read via square wave and interpreted by a multiplexer.

The project went into the weeds a bit when [Steve] tried to read the signals with a knock-off Saleae. As soon as he plugged it in, the control board fried because the DeLonghi evidently has no reference to Earth ground. While waiting for a replacement board to arrive, he tried replacing the mux and shift register chips, which actually fixed the board. Then it was more or less a matter of using the DeLonghi’s status LEDs to determine the machine’s state, and then to interface with the Photon and Alexa. Cycle past the break for a ristretto-sized demonstration.

[Steve] didn’t do all this to actually make coffee, just turn the machine on with a voice command. The Photon is totally capable of making coffee, though, as we saw with this closed-loop espresso machine.

Continue reading “Alexa And Particle Modernize Coffee Machine By One Iota”

One-key Keyboard is Exercise in Sub-millimeter Design

As [Glen] describes it, the only real goal in his decision to design his single-key USB keyboard was to see how small he could build a functional keyboard using a Cherry MX key switch, and every fraction of a millimeter counted. Making a one-key USB keyboard is one thing, but making it from scratch complete with form-fitting enclosure that’s easy to assemble required careful design, and luckily for all of us, [Glen] has documented it wonderfully. (Incidentally, Cherry MX switches come in a variety of qualities and features, the different models being identified by their color. [Glen] is using a Cherry MX Blue, common in keyboards due to its tactile bump and audible click.)

[Glen] steps though the design challenges of making a device where seemingly every detail counts, and explains problems and solutions from beginning to end. A PIC16F1459, a USB micro-B connector, and three capacitors are all that’s needed to implement USB 2.0, but a few other components including LED were added to help things along. The enclosure took some extra care, because not only is it necessary to fit the board and the mounted components, but other design considerations needed to be addressed such as the depth and angle of the countersink for the screws, seating depth and clearance around the USB connector, and taking into account the height of the overmold on the USB cable itself so that the small device actually rests on the enclosure, and not on any part of the cable’s molding. To top it off, it was also necessary to adhere to the some design rules for minimum feature size and wall thicknesses for the enclosure itself, which was SLS 3D printed in nylon.

PCB, enclosure, software, and bill of materials (for single and triple-key versions of the keyboard) are all documented and available in the project’s GitHub repository. [Glen] also highlights the possibility of using a light pipe to redirect the embedded LED to somewhere else on the enclosure; which recalls his earlier work in using 3D printing to make custom LED bar graphs.

The Pros and Cons of Microcontrollers for Boost Converters

It never fails — we post a somewhat simple project using a microcontroller and someone points out that it could have been accomplished better with a 555 timer or discrete transistors or even a couple of vacuum tubes. We welcome the critiques, of course; after all, thoughtful feedback is the point of the comment section. Sometimes the anti-Arduino crowd has a point, but as [Great Scott!] demonstrates with this microcontroller-less boost converter, other times it just makes sense to code your way out of a problem.

Built mainly as a comeback to naysayers on his original boost-converter circuit, which relied on an ATtiny85, [Great Scott!] had to go to considerable lengths to recreate what he did with ease using a microcontroller. He started with a quick demo using a MOSFET driver and a PWM signal from a function generator, which does the job of boosting the voltage, but lacks the feedback needed to control for varying loads.

Ironically relying on a block diagram for a commercial boost controller chip, which is probably the “right” tool for the job he put together the final circuit from a largish handful of components. Two op amps form the oscillator, another is used as a differential amp to monitor the output voltage, and the last one is a used as a comparator to create the PWM signal to control the MOSFET. It works, to be sure, but at the cost of a lot of effort, expense, and perf board real estate. What’s worse, there’s no simple path to adding functionality, like there would be for a microcontroller-based design.

Of course there are circuits where microcontrollers make no sense, but [Great Scott!] makes a good case for boost converters not being one of them if you insist on DIYing. If you’re behind on the basics of DC-DC converters, fear not — we’ve covered that before.

Continue reading “The Pros and Cons of Microcontrollers for Boost Converters”

DIY Variacs get ESP8266 Upgrades

If you’be been hacking and making long enough, you’ve probably run into a situation where you realize that a previous project could be improved with the addition of technology that simply wasn’t available when you built it. Sometimes it means starting over from scratch, but occasionally you luck out and can shoehorn in some new gear without having to go back to the drawing board.

The two isolated variacs that [nop head] built were already impressive, but with the addition of the ESP8266 he was able to add some very slick additional features which really took them to the next level. He’s done an exceptional job detailing the new modifications, including providing all the source for anyone who might be walking down a similar path.

His variacs have digital energy meters right in the front panel which give voltage, amps, and a real-time calculation of watts. After reading an article by [Thomas Scherrer] about sniffing the SPI data out of one of these meters with an Arduino, [nop head] reasoned he could do the same thing with an ESP8266. The advantage being that he could then pull that data out over the network to graph or analyze however he wishes.

For his older variac, he decided to automate the device by adding a stepper and belt to turn the knob. The stepper is controlled by a Pololu stepper driver, which in turn get’s its marching orders from another ESP8266. He even came up with a simple web interface which allows you to monitor and control the variac from your smart device.

We don’t often see many variacs around these parts, and even fewer attempts at building custom ones. It’s one of those pieces of equipment you either can’t live without, or have never even heard of.

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!

Push it to the Limit: SSD1306 at 150 FPS

A good deal of the projects we cover here at Hackaday are not, in the strictest sense, practical endeavors. If we required that everything which graced our digital pages had a clear end result, the site would be in a rather sad state of affairs. Sometimes it’s enough just to do something for the challenge of it. But more often than not, you’ll learn something in the process which you can use down the line.

That’s precisely what pushed [Laurence Bank] to see how well he could optimize the frame rate on the popular SSD1306 OLED display. After several iterations of his code, he was able to achieve a blistering 151.5 FPS, with apparently still some room for improvement if he’s feeling up to the challenge. But considering his first attempt was only running at 5.5 FPS, we’d say he’s already more than earned his hacker cred on this one.

A few different tricks were used to achieve such incredible performance gains. To start with, while the official I2C specification says you’re supposed to wait for an acknowledgment back from the device when communicating with it, [Laurence] realized the SSD1306 didn’t actually care. He could continuously blast commands at the display without bothering to wait for an acknowledgment. He admits there are problems with this method, but you can’t argue with the results.

To really wring all the performance out of the system he could, [Laurence] donned his Assembly Cap and examined how the Arduino IDE compiler was interpreting his code. He identified a few areas where changing his C code would force the compiler to generate faster output. He notes that this wouldn’t normally be required when working with more advanced compilers, but that the Arduino toolchain needs its hand held occasionally.

This isn’t the first time we’ve seen somebody try and push more pixels through the very same OLED display, and it’s interesting to see the two very different approaches to the same goal.

Flash and Debug ESP8266 Boards on Android

Have an ESP8266 development board such as the NodeMCU or Wemos D1? You’re currently reading Hackaday, so probably. Got an Android device kicking around? Also seems fairly likely. In that case, you should check out ESP8266 Loader by [Bluino Electronics]. This recently released application lets you not only flash new binaries to any ESP8266 board using the FTDI, PL2303, CH34X and CP210X USB chipsets, but also offers a serial monitor for debugging on the go.

You’ll need a USB OTG cable to get your ESP board jacked in to your Android device, but you don’t need root or even to fiddle with the development settings. Here at the Hackaday R&D Dungeon we had somewhat mixed success getting a random selection of Android devices to work fully; all of the ones tried could at least open the serial monitor and read what a pre-programmed ESP was saying, but not all of them could successfully program a board.

Even on the devices where programming worked, it was slow. Just a basic LED blinking Sketch took long enough to write to our test Wemos D1 Mini that we contemplated getting a snack. But still, it shows a lot of promise for managing devices in the field, especially if you don’t have over the air update enabled in your code.

We especially liked that ESP8266 Loader helpfully downloaded a bunch of example binaries, many of which could be of practical use. There are programs for toggling the different GPIO pins on the board, creating Wi-Fi access points, and even a basic web server. With these in hand, you could actually do some testing and diagnostic work right from your mobile device.

This isn’t the first time we’ve seen an ESP8266 team up with a mobile device, but generally speaking, the magic is done over WiFi or Bluetooth.