Slipcasting Resin Prototypes

[Eric Strebel] doesn’t need an introduction anymore. If there is a picture of an elegantly designed part with a professional finish on our pages, there is a good chance he has a hand in it. This time he is sharing his method of making a part which looks like it is blow-molded but it is not. Blow-molded parts have a distinctive look, especially made with a transparent material and [Eric’s] method certainly passes for it. This could upgrade your prototyping game if you need a few custom parts that look like solidified soap bubbles.

Mold making is not covered in this video, which can also be seen below the break, but we can help you out with a tip or two. For demonstration’s sake, we see the creation of a medical part which has some irregular surfaces. Resin is mixed and degassed then rolled around inside the mold. Then, the big reveal, resin is allowed to drain from the mold. Repeat to achieve the desired thickness.

This is a technique adapted from ceramics called slipcasting. For the curious, an elegant ceramic slipcasting video demonstration can be seen below as well. For an added finishing touch, watch how a laquer logo is applied to the finished part; a touch that will move the look of your build beyond that of a slapdash prototype.

More education from this prolific maker can be seen in his video on painting with a professional-looking finish and his tips for working with foam-core.

Continue reading “Slipcasting Resin Prototypes”

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.

ESP Cookbook Goes Beyond Chips and DIPs

Are you putting ESP8266s in all your projects these days, whether they need one or not? We don’t blame you. These boards are cheap, tiny, oh and they have WiFi.

If you want to spend less time writing code and more time blinking RGB LEDs over Wi-Fi, then check out this ESP cookbook over on IO. [Turo Heikkinen] and team are writing a soup-to-nuts guide to these darlings of IoT. The cookbook leads off with pinouts and networking (of course) before moving into more intricate recipes involving popular sensors and displays.

This cookbook is funny, it’s helpful, and it’s really well-organized. We love that they used the details section to create a linked table of contents. The links all drive to a specific Instructions page where each group of code snippets and explanations can be found. It’s still a work in progress, so you might want to follow it for updates. We have a feeling they’re going to expand the dessert section next.

Love the ESP8266, but hate programming them in that wonky form factor? Here’s a handy programming jig you can build.

Pimp My Scope

Most of us have heard some form of the adage, “You can buy cheaper, but you’ll never pay less.” It means that cheaper products ultimately do not stand up to the needs of their superior counterparts. Hackers love to prove this aphorism wrong by applying inexpensive upgrades to inexpensive tools to fill up a feature-rich tool bag. Take [The Thought Emporium] who has upgraded an entry-level microscope into one capable of polarized and dark-field microscopy. You can also see the video after the break.

Functionally, polarized images can reveal hidden features of things like striations in crystals or stress lines in hot glue threads. Dark-field microscopy is like replacing the normally glaring white background with a black background, and we here at Hackaday approve of that décor choice. Polarizing filters sheets are not expensive and installation can be quick, depending on your scope. Adding a dark-field filter could cost as much as a dime.

Like most mods, the greatest investment will be your time. That investment will pay back immediately by familiarizing you with your tools and their workings. In the long-run, you will have a tool with greater power.

Simple mods like the light source can be valuable, but upgrades are not limited to optical scopes, an electron microscope was brought back to life with Arduino

Continue reading “Pimp My Scope”

Impossibly Huge Depth of Focus in Microscope Photographs

Sometimes, less is more. Sometimes, more is more. There is a type of person who believes that if enough photos of the same subject are taken, one of them will shine above the rest as a gleaming example of what is possible with a phone camera and a steady hand. Other people know how to frame a picture before hitting the shutter button. In some cases, the best method may be snapping a handful of photos to get one good one, not by chance, but by design.

[The Thought Emporium]’s video, also below the break, is about getting crisp pictures from a DSLR camera and a microscope using focus stacking, sometimes called image stacking. The premise is to take a series of photos that each have a different part of the subject in focus. In a microscope, this range will be microscopic but in a park, that could be several meters. When the images are combined, he uses Adobe products, the areas in focus are saved while the out-of-focus areas are discarded and the result is a single photo with an impossible depth of focus. We can’t help but remember those light-field cameras which didn’t rely on moving lenses to focus but took many photos, each at a different focal range.

[The Thought Emporium] has shown us his photography passion before, as well as his affinity for taking the cells out of plants and unusual cuts from the butcher and even taking a noble stab at beating lactose intolerance.

Continue reading “Impossibly Huge Depth of Focus in Microscope Photographs”

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!