Beginning of hard apple cider

Lately, I’ve been getting into brewing; beer, wine, hard apple cider, you name it! In this post, I’ll be talking about hard apple cider, but I may add more posts on other brews later. I’ve now made hard apple cider twice and have definitely enjoyed the results!

For those inexperienced with brewing hard apple cider, its pretty straight forward. Throw 1 tsp of yeast into a gallon of apple juice or apple cider in a sanitized 1-gal fermenter. Shake the mixture to increase the dissolved oxygen which helps build a healthy yeast colony. After a week, transfer (or “rack”) into another sanitized fermenter to allow the brew to clear.  For those interested in the terminology, the initial fermentation is “primary fermentation” and upon transferring is “secondary fermentation”. Generally, primary is when most of the alcohol is produced and secondary is when most of the clarity is achieved.

Once the brew is done fermenting (no longer bubbling), it is ready to be bottled. For bottling, “natural” carbonation is typically used (kegging is another article altogether). Natural carbonation is achieved by throwing a certain amount of sugar (usually 1oz per gal of white or brown sugar) into the brew. This restarts the fermentation causing more CO2 to be released. Once the sugar is mixed in, the result is put into bottles and those bottles are capped. You then have dry, carbonated cider ready to enjoy in a little over two weeks. However, aging the brew for a few more weeks produces a better result (some people age for months). Calculating alcohol by volume (ABV) requires the use of a hydrometer; you compare the density of the non-fermented liquid to the fermented liquid and multiply by 131.25. A typical apple juice has a density of 1.060 and typically finishes fermenting at 1.000; (1.060-1.000)*131.25 = 7.88%.

For sweet, non-carbonated apple cider, you can add more sugar before bottling and either add chemicals that prevent further fermentation or pasteurize to kill the yeast (otherwise way too much CO2 will be produced and you’ll potentially shatter your bottles). For sweet and carbonated hard apple cider (my preferred style) it gets more complicated; we’ll have to cover that in another article.

I recently received a few NodeMCU boards from Ebay. They came with a custom program loaded (not NodeMCU) and were a bit cryptic to figure out. Instead of messing with a custom program that I couldn’t find much documentation for, I tried flashing NodeMCU onto the board. I tried a few different methods and a few different versions and was unsuccessful. During my troubleshooting I ran across a Micropython implementation. I decided, what the heck, might as well give it a try. A few minutes later I was logged into the WebREPL server (more on this later) running python code on my ESP board. As I’m not fixated on using NodeMCU, I’m going to stick with what works easily — Micropython.

At this point you may be asking, “why the heck do I care about an ESP board with Micropython”, well, you might not. But I happen to care and here is why: with the combination of cheap WiFi enabled hardware and an easy to program platform, creating an IOT device is easier than ever. By adding a few custom functions that handle the typical tasks I want my devices to do, I can create wirelessly controlled devices with little effort.

After some messing around, I’ve found that Micropython is extremely stable and has enough functionality to be nearly identical to Python. Functionality is well implemented for writing to/reading from pins (analog and digital) as well as sending messages over WiFi. A handy feature is the WebREPL server hosted on the ESP which allows access to a Python shell running on the ESP. This is extremely handy, and if you generate a static IP for the ESP, it can be easily controlled anywhere in the world without much effort.

What next? Well, I have two applications in mind currently. First, I plan to make a motion sensor that will trigger my SmartThings lights. The device will be mounted in my room with a LiPo battery and a PIR sensor. Whenever motion goes off, the device, depending on the mode, will turn on the lights in the room. Second, I plan to create a WiFi enabled train controller. I’ve recently been given some American Flyer – O gauge model trains and want to move away from manually controlling the speed of the trains and the various switches to wireless control. I’ve already started both of these projects and should have the first one done soon.

For just a bit of fun, I’ve been working on a repeating pattern generator which can generate fractal-like-structures. Currently the generator begins with one node, generates two children attached to the first, and then two children attached to those nodes, and on and on; it creates a tree like structure. The process looks like this:

4 levels generated using default settings

This can be continued forever, however, I’ve created an input that limits the number of layers or levels of the tree. This generates quite interesting patterns like:

Interesting Rendering

or

Interesting Rendering 2

It can also be used to generate interesting animations such as this:

Simple Animation

Implementation

The implementation for this is fairly straight forward if done recursively; in pseudo-code:

func processNode(inputNode)
    drawLine
    drawCircle
    if (inputNode.level < MaxLevel)
        child1 = new Node(child1Location, inputNode.level + 1)
        processNode(child1)
        child2 = new Node(child2Location, inputNode.level + 1)
        processNode(child2)
    endif
end

This code would execute fine, however, for large numbers of recursions, this will quickly fill up the available stack space and eventually crash the program. For this we can convert it to a more iterative approach. I chose to place all nodes in a queue as they are generated and to pull from the queue constantly. This provides an easy way to save the children nodes as well as removes the recursive nature.

Below is the core of the logic, you would add a first node to the queue at the beginning and then run processNodes continuously until all nodes are processed.

func processNodes()
    node = nodeQueue.dequeue()
    if (node.level < MaxLevel)
        DrawNode(node)
        children = GenerateChildren(node)
        nodeQueue.add(children)
    endif
end

Code Details

I originally chose javascript for portability reasons. I found javascript to be a pretty good language for this application, however, I wanted to try to make a faster program. I switched to WPF with C# to speed it up. However, the usual way of drawing things in WPF is to use FrameworkElements, which doesn’t work for large number of elements. Then I tried the DrawingVisual and DrawingContext which is the next best way to render images. This too was much too slow with large amounts of drawing calls. I considered Direct 2D but ultimately chose to draw directly to bitmaps because this seemed a little more straightforward.

I found a NuGet package called WriteableBitmapExtensions which adds a few very handy extensions to the WriteableBitmap class. I implemented the code close to the above pseudo-code. First, I executed the processing function on a timer interrupt. This wasn’t efficient enough, so I threw the processing into an infinite loop on a background thread, which uses the dispatcher to put any UI calls onto the UI thread. This resulted in much much better performance then Javascript, FrameworkElements, or DrawingVisuals implementations.

For more info on the performances: WriteableBitmap executes around 100x faster than when I used Javascript. Javascript performs about 10x better than DrawingVisuals. DrawingVisuals performs about 2x better than FrameworkElements. This makes a certain amount of sense since DrawingVisuals and FrameworkElements draw at a very high level with low optimizations.

TL;DR start here:

After finding a speedy way of drawing (with writable bitmaps in C# WPF), I moved onto putting the work into more than one background thread. This wasn’t too difficult, but required moving a lot of the global variables to local variables that are passed into other functions. The program uses nearly 100% of all my 8 CPUs on my desktop with around 95% of the program’s computations going to the drawing calls. I was able to render 2^26 nodes in only a minute or two (that’s over 67 million nodes).

Conclusion

This isn’t as good as I would expect with say Direct2D or another more optimized solution. However, this was a lot of fun and was a good way to practice optimization and multi-threading. I’ve found myself spending quite a while messing with the settings finding interesting patterns.

Source Code

I’ve included the source code below. As this is not a large project, I was willing to break some best practices to speed up development; very little “proper” design patterns were used. Feel free to use and modify the code.

Fractals.zip (Click link, look for download button on the top right)

Future?

If I work more on this, I’m would like to create an automated way to generate large numbers of frames. Something to the effect of having a start frame with certain settings, an end frame with certain settings, and an option for the number of in-between frames (n). The program would generate n frames and save them to a specified folder. Long animations could be created quickly and easily (the above animation took absolutely forever).

Another possible next step would be to use/make a more optimized way to draw shapes and lines as the draw calls do not seem to be as efficient as they could be (and they aren’t using the GPU).

After only a few hours of work, I’ve completed the circuit and it looks great! The big blue thing is the standard ESP-12 module. To the left is the programming connector. Below the blue part is the 3.3V power regulator. All around the board are 3-pin connectors that are compatible with servos. The connectors are all GPIOs except the A0 connection which is only for the internal ADC.

Up next, I’ll order the boards and all the components. I intend to order the PCB through OSHPark, the ESP-12 module from Ebay, and the rest of the components from Mouser (at least the ones I don’t already have).

For anyone wanting to look at this board in CircuitMaker, I believe you can search ESP IOT Breakout and it should come up. Let me know if that doesn’t work in the comments or by using the contact page. I’ll put up a parts list soon!

In my last post on the ESP8266 and IFTTT, I said that I would prefer keeping the ESP8266 decoupled from the overall system. This meant using the standard AT commands to control the default firmware. However, after a few attempts at sending AT commands and parsing the responses, I’ve given up that idea; using the AT commands is too annoying and slow.

Instead, I plan to go in the opposite direction completely. I’m going to make the system completely coupled to the ESP8266s. The plan is to design a circuit board with the ESP8266-12 module which comes in a small surface mount layout. The GPIOs will be broken out similar to 3-pin servo connections to facilitate easy connection of various devices. If I can keep the overall circuit below $10 including the ESP-12 module, this circuit will be a very nice development board for low-cost smart home devices.

Here’s a quick snapshot of the CircuitMaker schematic in development (very basic start):

The circuit still needs all of its connectors and the power regulator. As soon as I have the first version done, I’ll include a reference so that anyone can order these boards/fork the project.

Stay tuned for more updates on this project…

Introduction:

The first stage of creating my own smart electronics was getting the communication between the device and my SmartThings hub. I decided to use IFTTT for a number of reasons. IFTTT allows my circuit to control much more than just SmartThings, and it also does not require me to write a smart app. The best way to get a custom device to communicate with SmartThings is by using the maker channel in IFTTT. This allows any device capable of basic HTTP requests to trigger IFTTT events.

For my overall project, I intend to keep the communication device (ESP8266 here) decoupled from the actual system. This is partially so that I don’t have to deal with writing custom code on the ESP, but it is also so that I can swap the radio for another in the future. As a result, I’m using the default AT firmware and a separate MCU (just needs a UART peripheral that can operate at 9600 baud).

IFTTT Setup:

Setting up IFTTT is fairly simple. Just create an account, create a recipe using the Maker channel trigger and the desired action. For testing, this could be an email or IF notification.

Before any commands are sent to the ESP, it is good to know what format we need to use. IFTTT’s maker channel uses simple HTTP requests, and the HTTP GET request is the easiest to use. A minimal GET request is shown below.

GET /internalReference?value1={val1}&value2={val2}&value3={val3} HTTP/1.1

HOST: maker.ifttt.com

If you were to format this as a string, it would be:

“GET /internalReference?value1={val1}&value2={val2}&value3={val3} HTTP/1.1\r\nHOST: maker.ifttt.com\r\n\r\n”

Note: the extra “\r\n” at the end tells the serve that the message is done.

As you can see from the HTTP GET message, we have the ability to send back 3 data values which can be used in the maker channel. If you don’t want to use these values, you can leave them off (everything after and including the ‘?’).

Now that IFTTT is setup and we know our message format, we can begin interacting with the ESP.

Hardware Setup:

For this part of the project, I’m connecting the ESP8266 to an Arduino as a USB to Serial converter. I hooked up the ESP to the Arduino (with chip removed) as shown in the image below. It is advisable to use an external 3.3V regulator, however, when I used the Arduino, the on-board regulator worked fine for me.

AT commands:

To configure and use the ESP, we need to use the AT commands. All the AT commands can be found here.

The first thing we need to do is configure the ESP:

AT+CWMODE=3    // allows both client and host capabilities

AT+CIPMUX=1      // allows multiple connections

We can list the available APs:

AT+CWLAP

To connect:

AT+CWJAP=”SSID”,”PASSWORD”    // no spaces, quotes are required

To disconnect (quit)

AT+CWQAP

Once connected to our AP, we need to make a TCP/IP connection and send our data.

To make a TCP connection (no spaces, quotes required) we send:

AT+CIPSTART=CHANNEL,”TCP/UDP”,”ADDR/IP”,PORT

In our case we send:

AT+CIPSTART=0,”TCP”,”maker.ifttt.com”,80

After this point, you have a connection to maker.ifttt.com. This connection has a timeout, so it is best to have the next command ready.

Now we need to send our HTTP GET message. In general the message is:

AT+CIPSEND=CHANNEL,LENGTH

GET /internalReference?value1={val1}&value2={val2}&value3={val3} HTTP/1.1

HOST: maker.ifttt.com

Here, the string we defined earlier is very useful (that is as long as your serial terminal supports the escape characters \r\n, I use RealTerm). This allows us to send the entire command all at once and can be essentially dropped into a program:

“AT+CIPSEND=0,LENGTH\r\nGET /internalReference?value1={val1}&value2={val2}&value3={val3} HTTP/1.1\r\nHOST: maker.ifttt.com\r\n\r\n”

For example, triggering the “light_on” event through the maker channel:

AT+CIPSEND=0,91\r\nGET /trigger/light_on/with/key/YOUR_KEY_HERE?value1=1 HTTP/1.1\r\nHost: maker.ifttt.com\r\n\r\n

One note on the send message: I’ve found the most annoying part of these commands is calculating their length. The length is everything after the AT+CIPSEND=0,x including the \r\n and you count all characters (\r = 1, \n = 1). The above message should be accurate in its length.

Finally, its good practice to close the connection:

AT+CIPCLOSE=0

All together now:

AT+CWMODE=3

AT+CIPMUX=1

AT+CWJAP=”SSID”,”PASSWORD”

AT+CIPSTART=0,”TCP”,”maker.ifttt.com”,80

AT+CIPSEND=0,91\r\nGET /trigger/light_on/with/key/YOUR_KEY_HERE?value1=1 HTTP/1.1\r\nHost: maker.ifttt.com\r\n\r\n

AT+CIPCLOSE=0

After sending all these commands, you should get a response from the IFTTT server, stating that you successfully triggered the event and you should also have your action triggered.

Stay tuned for the next post about executing all these commands from a MCU connected to the ESP.

For anyone who has seen my blog, they might realize that I haven’t posted in a while. I created this blog to show off some of my projects, but beyond that, it had no other purpose. As soon as I became busy, I lost the determination to keep posting about my projects.

I’ve now been involved with UNL’s Maker Club and have regained my passion for sharing my projects. But this time, I’m sharing them to teach others and excite them about “Making”. I have a few projects I’ve already completed and some exciting projects I will be working on.

As I need to gather some pictures and details, I won’t include any detailed projects in this post. However, I will give you a brief summary of posts you can expect soon.

• Home-built quadcopter (how-to)
• Cheap WiFi enabled circuits
• DSLR timelapse circuit with Arduino
• LED Strips controlled over XBees
• Oculus Rift DK2 experiences
• Game design (VR support)
• Powerful ideas for embedded programming (Make coding easier/better for embedded C/Arduinos)

Stay tuned for project details!