Biasing That Transistor: The Common Base Amplifier

We’ve previously remarked upon a generation lucky enough to be well-versed in microcontrollers and computersised electronics through being brought up on the Arduino or the Raspberry Pi but unlucky enough to have missed out on basic electronics such as how to bias a transistor, and to address that gap we’ve taken a look at the basics of transistor biasing.

All the circuits we worked with in the previous article had the transistor’s emitter taken to ground, took their input from the base, and their output from the collector. This configuration, called a Common Emitter amplifier is probably the most common, but it is far from the only way to use a transistor. Once you have set up the bias voltage as we described to the point at which the transistor is in its linear region, there are several other ways in which the device can be used as an amplifier. The subject of this article is one of these configurations, so described because it takes the transistor’s base to the ground instead of the emitter, as a Common Base amplifier. Continue reading “Biasing That Transistor: The Common Base Amplifier”

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!

How To Build Anything Out Of Aluminum Extrusion And 3D Printed Brackets

The real power of 3D printing is in infinite customization of parts. This becomes especially powerful when you combine 3D printing with existing materials. I have been developing a few simple tricks to make generic fasteners and printed connectors a perfect match for aluminum extrusion, via a novel twist or two on top of techniques you may already know.

Work long enough with 3D printers, and our ideas inevitably grow beyond our print volume. Depending on the nature of the project, it may be possible to divide into pieces then glue them together. But usually a larger project also places higher structural demands ill-suited to plastic.

Those of us lucky enough to have nice workshops can turn to woodworking, welding, or metal machining for larger projects. Whether you have that option or not, aluminum extrusion beams provide the structure we need to go bigger and to do it quickly. And as an added bonus, 3D printing can make using aluminum extrusion easier and cheaper.

Continue reading “How To Build Anything Out Of Aluminum Extrusion And 3D Printed Brackets”

Biasing That Transistor: The Common Emitter Amplifier

If you open up the perennial favourite electronics textbook The Art Of Electronics and turn to the section on transistors, you will see a little cartoon. A transistor is shown as a room in which “transistor man” stands watching a dial showing the base current, while adjusting a potentiometer that limits the collector current. If you apply a little more base current, he pushes up the collector a bit. If you wind back the base current, he drops it back. It’s a simple but effective way of explaining the basic operation of a transistor, but it stops short of some of the nuances of how a transistor works.

Of course the base-emitter junction is a diode and it is not a simple potentiometer that sits between collector and emitter. The “better” description of these aspects of the device fills the heads of first-year electronic engineering students until they never want to hear about an h-paramater or the Ebers-Moll model of transistor function again in their entire lives. Fortunately it is possible to work with transistors without such an in-depth understanding of their operation, but before selecting the components surrounding a device it is still necessary to go a little way beyond transistor man.

Continue reading “Biasing That Transistor: The Common Emitter Amplifier”

Circuit VR: Sink Or Swim With Current Sources

If you got your start in electronics sometime after 1980 your first project might well have been to light up an LED. Microcontroller projects often light up an LED, too, and a blinking LED is something of the “hello world” program for embedded systems. If you tried lighting up your LED with a 9 V battery directly — not that you’d admit to it — you found it would light up. Once, anyway. The excess current blows up the LED which is why you need a current-limiting resistor. However, those current limiting resistors are really a poor excuse for a current source or sink. In many applications, you need a real current source and luckily, they aren’t hard to create.

As always with Circuit VR, we’ll be using LT Spice to examine the circuits. If you need a quick tutorial, start here and come back after that. If you use Linux, don’t be dismayed. I run LT Spice under WINE and it works great. You can find all the Spice files on GitHub.

Continue reading “Circuit VR: Sink Or Swim With Current Sources”

Directly Executing Chunks Of Memory: Function Pointers In C

In the first part of this series, we covered the basics of pointers in C, and went on to more complex arrangements and pointer arithmetic in the second part. Both times, we focused solely on pointers representing data in memory.

But data isn’t the only thing residing in memory. All the program code is accessible through either the RAM or some other executable type of memory, giving each function a specific address inside that memory as entry point. Once again, pointers are simply memory addresses, and to fully utilize this similarity, C provides the concept of function pointers. Function pointers provide us with ways to make conditional code execution faster, implement callbacks to make code more modular, and even provide a foothold into the running machine code itself for reverse engineering or exploitation. So read on!

Function Pointers

In general, function pointers aren’t any more mysterious than data pointers: the main difference is that one references variables and the other references functions. If you recall from last time how arrays decay into pointers to their first element, a function equally decays into a pointer to the address of its entry point, with the () operator executing whatever is at that address. As a result, we can declare a function pointer variable fptr and assign a function func() to it: fptr = func;. Calling fptr(); will then resolve to the entry point of function func() and execute it.

Admittedly, the idea of turning a function into a variable may seem strange at first and might require some getting used to, but it gets easier with time and it can be a very useful idiom. The same is true for the function pointer syntax, which can be intimidating and confusing in the beginning. But let’s have a look at that ourselves.

Continue reading “Directly Executing Chunks Of Memory: Function Pointers In C”

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”