Open Source LXI Tools Free Us From Vendor Bloat

LXI, or LAN eXtensions for Instrumentation is a modern control standard for connecting electronics instrumentation which supports ethernet. It replaces the older GPIB standard, giving much better performance and lower cost of implementation. This is a good thing.  [Martin Lund] has created the open source lxi-tools project which enables us to detach ourselves from the often bloated vendor tools usually required for talking LXI to your bench equipment. This is a partial rewrite of an earlier version of the tool, and now sports some rather nice features such as mDNS for instrument discovery, support for screen grabbing, and a LUA-based scripting backend. (API Link)

SCPI or Standard Commands for Programmable Instruments is the text-based language spoken by many instruments, allowing control and querying of an instrument. Just to be clear, SCPI is not at all a new thing, and older instruments that have GPIB or RS232 connectors, still could talk SCPI. lxi-tools is not for those. Some instruments can also be very picky about the formatting of commands, especially if they’re buggy, so the ability to interactively debug commands is very desirable. It is quite possible to make poor use of SCPI commands in your test script and end up with tests that just take far longer to execute that they need to. lxi-tools has a benchmarking tool too, which helps you to dig in and find out where all the time is going and make suitable adjustments.

We’ve not seen much about LXI on Hackaday, but we did cover using PyVISA for dealing with SCPI-over-GPIB in python.  If you have an older instrument  with GPIB and you don’t want to sell a internal organ to pay for a USB adaptor, here’s one you can make yourself.

Dynamicland Makes The Whole Building The Computer

Every once is a while a research project comes along that has the potential to totally shake up computing and what it even means to interact with a system. The project Dynamicland.org, is a result of [Bret Victor]’s research journey over the years, looking into various aspects of human computer interaction and what it even means to think like a human.

One of the overhead projectors tied to a realbox
In Realtalk, paper is your programming medium

Dynamicland is an instantiation of a Realtalk ecosystem, deployed into a whole building. Tables are used as computing surfaces, with physical objects such as pieces of paper, notebooks, anything which can be read by one of the overhead cameras, becoming the program listing, as well as the user interface. The camera is associated with a projector, with the actual hardware hooked into so-called ‘Realboxes’ which are Linux machines running the Realtalk software. Separate Realboxes (and other hardware such as a Raspberry Pi, running Realtalk) are all federated together using the Realtalk protocol, which allows communication from hardware in the ceiling, to any on the desk, and also to other desks and computing surfaces.

Realtalk itself is described as an environment for authoring and using computation media. The Realtalk system provides a language extension to Lua. Together these form a domain-specific language. Realtalk is also a kind of reactive database, which means that the emphasis is on the flow of data and connections between data producing things, and data consuming things. For a bit more explanation of how reactive programming can be used with modern relational databases, check out this article on the subject.

For a good overview of how this works in practice, from a programming perspective, checkout [Omar Rizwan]’s article about his ‘Geokit’ project. Another interesting read is the work by [Andrés Cuervo.]

Continue reading “Dynamicland Makes The Whole Building The Computer”

Slaying Dragons In Notepad

We all have our favorite text editor, and are willing to defend its superiority above all other editors by any means necessary. And then there’s Notepad. But what Notepad may lack in text manipulation features, it compensates with its inconspicuous qualities as a gaming platform. Yes, you read that correctly, and [Sheepolution] delivers the proof with a text-based adventure game running within Notepad.

What started out with [Sheepolution] jokingly wondering what such a game may look like, ended up as an actual implementation as answer to it. Behind the scenes, a script written in Lua using the LÖVE framework — for which he also created an extensive tutorial — monitors the state of several text files that make up the game world. Each location is a separate text file to open in Notepad, showing the current state of the game, telling the story with text and ASCII art, and offering choices to the player. The game is played by modifying and saving those text files, which the script then processes to push the gameplay forward by simply updating the content of those files with the new state. Check out the game’s trailer after the break to get a feel of what that looks like.

Unfortunately, Notepad itself doesn’t automatically reload the file when its content changes, so to provide a smoother gaming experience, [Sheepolution] modified the open source implementation Notepad2 to work around this, and bundled it as part of the game’s executable. Initially, he even added animations to the ASCII graphics, but in the end decided against most of them to avoid constant disk writes and race conditions caused by them.

Sure, this is no Game Boy emulator in a text editor, and it may not be as groundbreaking as Notepad’s latest feature, but it’s always amusing to see alternative uses for well-established tools.

Continue reading “Slaying Dragons In Notepad”

LuaRadio Gives Insight Into SDR

In theory, you shouldn’t need any help to develop a software-defined radio (SDR) application. But in real life you really don’t want to roll your own code every time to read the IQ samples, perform various transformations on them, and then drive audio output. At worst, you’ll use some libraries (perhaps GNU Radio) but usually, you’ll use some higher-level construct such as GNU Radio Companion (GRC). GRC is a bit heavyweight, though, so if you’ve found it daunting before, you might check out some of the material on the LuaRadio website.

We’ve looked at LuaRadio several years ago, but it has undergone a lot of changes since then and has some excellent documentation. Like Lua itself, LuaRadio emphasizes fast scripting. It supports quite a few pieces of common hardware and nearly anything that feeds data through a soundcard.

Continue reading “LuaRadio Gives Insight Into SDR”

Compiling NodeMCU For The ESP32 With Support For Public-Private Key Encryption

When I began programming microcontrollers in 2003, I had picked up the Atmel STK-500 and learned assembler for their ATtiny and ATmega lines. At the time I thought it was great – the emulator and development boards were good, and I could add a microcontroller permanently to a project for a dollar. Then the ESP8266 came out.

I was pretty blown away by its features, switched platforms, except for timing-sensitive applications, and it’s been my chip of choice for a few years. A short while ago, a friend gave me an ESP32, the much faster, dual core version of the ESP8266. As I rarely used much of the computing power on the ESP8266, none of the features looked like game changers, and it remained a ‘desk ornament’ for a while.

About seven weeks ago, support for the libSodium Elliptic Curve Cryptography library was added. Cryptography is not the strongest feature of IoT devices, and some of the methods I’ve used on the ESP8266 were less than ideal. Being able to more easily perform public-private key encryption would be enough for me to consider switching hardware for some projects.

However, my preferred automated build tool for NodeMCU wasn’t available on the ESP32 yet. Compiling the firmware was required – this turned out to be a surprisingly user-friendly experience, so I thought I’d share it with you. If I had known it would be so quick, this chip wouldn’t have sat on my desk unused quite so long!  Continue reading “Compiling NodeMCU For The ESP32 With Support For Public-Private Key Encryption”

Demystifying The ESP8266 With A Series Of Tutorials

If your interest has been piqued by the inexpensive wireless-enabled goodness of the ESP8266 microcontroller, but you have been intimidated by the slightly Wild-West nature of the ecosystem that surrounds it, help is at hand. [Alexander] is creating a series of ESP8266 tutorials designed to demystify the component and lead even the most timid would-be developer to a successful first piece of code.

If you cast your mind back to 2014 when the ESP8266 first emerged, it caused great excitement but had almost no information surrounding it. You could buy it on a selection of modules, but there were no English instructions and no tools to speak of. A community of software and hardware hackers set to work, resulting in a variety of routes into development including the required add-ons to use the ever-popular Arduino framework. Four years later we have a mature and reliable platform, with a selection of higher-quality and well supported boards to choose from alongside that original selection.

The tutorials cover the Arduino and the ESP, as well as Lua and the official SDK. They are written for a complete newcomer, but the style is accessible enough that anyone requiring a quick intro to each platform should be able to gain something.

Our community never ceases to amaze us with the quality of the work that emerges from it. We’ve seen plenty of very high quality projects over the years, and it’s especially pleasing to see someone such as [Alexander] giving something back in this way. We look forward to future installments in this series, and you should keep an eye out for them.

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!