Well, they did it! The FCC will now allow Internet service providers to provide differential service based upon content. The reason this is bad is because service should be neutral in relation to content. Think of our First Amendment free-speech rights. Places of public accommodation are not allowed to discriminate against any type of speech on the basis of the content of that speech. As a college administrator, I can’t say to a student or group, “I like the content of what you’re saying, so you get to have this particular space on campus.” This discrimination based upon content is what net neutrality was protecting against. Frankly, I think it’s just another way for the Internet service providers to make money, at the expense of free speech.
Republicans may have ‘awoken a sleeping giant’ by repealing net neutrality
I’m sitting in the public library of Hot Springs, NC, writing this blog entry and contemplating the magnitude of what we all just did. Not because it was a feat of athletic ability, or extreme endurance, or any such example of human exceptionalism. No, rather it was, as it always is, a magnum of human blessings, a bouquet of love and kindness, and a vision of God’s beautiful creation that never fails to stir my heart to tears of gratitude.
It would be impossible to encompass the entire experience in this blog post, and so I won’t try. Rather, I’d like to describe the crew, the trek, and why it was so special. Our crew this year consisted of 16 people, most related by blood, all related in spirit. We had the six Sweeneys (minus our eldest who is currently in Haiti on internship), three Boyds (our patron member, Walker, at 88 years of age, and his two sons, Tim and Austin), father and daughter Katkoskis, three young friends of the families, and Terri, our live-in librarian.
Trail magic was in abundance this year. I found great blessings in watching the Boyd brothers shepherd their father over 61 miles of sometimes treacherous trail, minister to him when he stumbled, and recount memories of their protean steps over this same ground 46 years ago, almost to the day. My heart ached as my MC, turning eight years old on the trail this year, broke out in a refrain of Dona Nobis Pachem as we maneuvered precariously over a knife-edge ridge with stunning views of smokey peaks after a day of heavy fog which shrouded God’s mystery. I was even thankful when a bear decided to walk under my hammock (and not eat me) at two in the morning, though he did manage to take my shirt for a short stroll.
Most of you know that I’m a Boy Scout leader. Part of my current job is to teach young scouts about citizenship as a merit badge counselor for Citizenship in the Community/Nation/World. These are three eagle-required badges that are frankly, in my opinion, the best and most important badges scouts earn. Here’s requirement #1 for CitNation:
Explain what citizenship in the nation means and what it takes to be a good citizen of this country. Discuss the rights, duties, and obligations of a responsible and active American citizen.
The first question I ask is, “What is the most important duty of a responsible and active American citizen?” They invariably answer, “Voting!” to which I answer, “NO! The most important duty of a citizen is to be informed!” After they give me puzzled looks, I then talk about the media. I tell them that they must consume multiple sources of media on both sides of the political spectrum because today all media is agenda driven. While you can argue that the overall objective of media is to make money (at least in this country), in so doing, media target a demographic of reader/listener/watcher and then create an agenda within that bubble.
No more clearly is this demonstrated than at National Public Radio. I’ve been listening to NPR since my college days. Over the arc of that 30 years, I’ve been conscious of a sea change in their agenda (i.e., marketing strategy). Today, NPR is perhaps the most overtly liberal “news organization” in the world. That’s OK, because I can balance out NPR with other, more conservative news sources such as Fox News, which is just as agenda driven as NPR.
But since the election, NPR has literally lost its mind. Virtually every story is about Trump and is negative. For example, on December 13, 2016, there were 19 stories during All Things Considered. Of the 19, 15 of them were either explicitly about Trump, or were topics where Trump was openly criticized for his views or criticized by association (e.g., Columbia Journalism Report Criticizes Exxon CEO’s Position On Climate Change). All of them were negative.
Of course, part of NPR’s hubris is their inconsolable grief over Hillary’s loss. No more clearly is this illustrated than in their focus on the 2.8 million popular votes by which Hillary “won.” (See CNN for an example of this.) Newsflash: Hillary didn’t win by 2.8 million, she lost by 74. The sweet irony of this story is the fact that there turned out to be more faithless electors voting for Trump than Hillary. Oops! I guess THAT strategy backfired! NPR’s focus on the popular vote in an effort to sway the ignorant electorate is disingenuous for an organization that considers itself an elite news organization – clearly manipulation.
I didn’t vote for Trump (I didn’t vote for Hillary, either). I think he’s a dangerous choice for the most powerful job in the world. He’s vain, thin-skinned, self-absorbed, pompous, imprudent, inexperienced, pandering, and self-righteously indignant. But I must admit that NPR’s rabid coverage of his transition plans have been so over the top that I’ve come to even defend him in certain circumstances. If NPR thinks he’s so bad that they are willing to completely sell their soul to the liberal left, I may be able to bring myself to support Trump, or at least to give him a chance. So, thank you NPR, for helping me get over my misgivings.
It’s amazing how clarifying a prototype can be! While I had a general idea of what I wanted to automate for my brewery v3, I didn’t have a clear idea of how to exactly put it together until I got all of the pieces on my dining room table and started to solder and drill. This is apostasy for you double-E types out there, but since I’m not an engineer, this method worked for me.
Case in point: The Smart Hardware STR1160000H RS485 switch controller pictured below. This small board takes an RS485 protocol signal and controls 16 small relays that can drive anything up to 240VAC. My system is all 12VDC. I figured 16 relays would be plenty to expand in the future. To begin with, I decided to control the following 5 things:
System pump (on/off)
Recirculating Infusion Mash System (RIMS) PID controller (Omega CN7500)
Hot Liquor Tun(HLT) to Mash Tun or Boil Tun three-way ball valve (Tonhe 3-wy SS304)
Mash Tun to RIMS or Boil Tun three-way ball valve (Tonhe 3-wy SS304)
Details of getting the Raspberry Pi to communicate in the RS485 protocol are detailed in a previous post. The manual on how to communicate with the board was pretty confusing, but once I figured out how to send the first command successfully, it was pretty easy. It’s worth noting that the vendor of the Smart Hardware board (based in Bulgaria) was total awesome. Stefan answered all of my questions quickly and accurately. He’s an outstanding eBay vendor and I would highly encourage you to use him. At one point, the board was on it’s way to me, and should’ve arrived. I contacted Stefan and he helped me track down the problem – the US postal service had stuck it in a corner in Navasota (7 miles fr0m my house) and forgot about it.
One issue I ran into is that the controller is programmed at the factory to respond on a high controller number (higher than the RS485 shield can handle). Fortunately, there is a command that will rewrite the controller number for all controllers on the RS485 bus using a serial command, so I was able to reprogram it to respond to controller number 02.
The other side of communication was controlling the Omega PID (RIMS temperature controller). I chose the CN7500 because there is a serial driver for this device already written in the minimalmodbus Python package. With this driver, I can read settings from the controller and set things like process value, alarms, and other cool process values.
Within this hardware framework, I used python to write hardware controller scripts that could be used as building blocks for more complicated process “recipes” like Power On, Heat Strike Water, Mash, Mashout, and Sparge. I also created the beginnings of a Python driver module for the STR116 relay board that handles all of the low-level hexadecimal communication stuff. The repo for this project is located here. Keep in mind that it is a work in process, so stay tuned.
The Sweeney Brewery v3 has lots of electrical controls. I have six 2-way electric ball valves – three for tun control and three for gas control, and two 3-way valves for various fluid routing processes. I also have a new Omega CN7500 (more on that later), and the system pump.
Controlling everything, I have an RPi v2. The first problem was how to control all of the devices. the RPi offers support for multiple communication protocols including one-wire, RS232, RS485, and lots of others. After flirting with one-wire, I settled on RS485 for several reasons. First, the Omega could communicate with either RS232 or RS485. I had to design the controllers for the electric ball valves from scratch, so that wasn’t a limiting factor. RS485 can also support up to 32 devices per communications port. Also, RS485 can communicate over long distances. These all added up to a design decision to use RS485.
There’s lots of information on using RS485 with RPi – most of it poorly written, erroneous, or just plain wrong. I went down the road of trying to get the RPi to control RS485 directly but soon gave that up because of voltage conversions. Then I found a neat little RPi shield that takes care of the voltage shifting for you. This was the solution that would allow me to control both the Omega PID and an array of relays that could control the mechanical controls.
And so I set out to configure the RPi to communicate to the serial devices. This was NOT easy. I installed a minimal Raspbian image (September 2016, Kernel 4.4) and updated all packages. I setup SSH and a USB wireless dongle to communicate with my house network so I could work on the RPi headless. I then added the following additional packages using apt-get:
vim
git-core
python-pip
wiringpi
python-serial
This package should be installed with pip:
minimalmodbus (has a custom driver for the Omega CN7500!!)
The setup instructions for the LinkSprite shield are old (2013) and inaccurate. They detail the following tasks which have to be modified on the new systemd enabled Raspbian image.
Install library dependencies (detailed above)
Disable use of the serial port as a TTY. Use raspi-config to do this. Run sudo raspi-config and check if it has the option interfacing-options -> serial. If it has, set it to disabled and you’re done.
Disable the login messages on the serial port. This is tricky because the instructions assume an old version of unix that uses SystemV (i.e., edit /etc/inittab). The newest version of Raspbian uses systemd, which doesn’t have /etc/inittab. The correct way to do this under systemd is to run:
sudo systemctl mask serial-getty@ttyAMA0.service
After I took these steps, I was able to communicate to the Omega controller via a simple python script that extended the custom Omega CN7500 driver for python. Here’s the simple script which returns the current process temp from the controller:
#!/usr/bin/env python
import omegacn7500
instrument = omegacn7500.OmegaCN7500('/dev/ttyAMA0', 2) # port name, slave address
print instrument.get_pv() # print temperature
And so, I made my first successful RS485 communication. More to follow.
RPi3 Update
Well, it turns out that the steps to enable the RS485 on the RPi3 are different. I found an article that deals with much of the subtlety of this. Because of the addition of bluetooth on the RPi3, /dev/ttyAMA0 is reserved for that, and so the procedure is slightly different. In the following steps, we will move bluetooth from the high-performance /dev/ttyAMA0 interface to the lower performing /dev/ttyS0.
Raspberry Pi 3’s and 4’s are great little beasts, and add Bluetooth, yay! However, in order to use the Bluetooth correctly the /dev/ttyAMA0 has been “stolen” from the GPIO header and an inferior second one has been substituted in it’s place. No-one will ever know! Unfortunately /dev/ttyAMA0 was a hardware serial port (uart) and high performance (hence it was nabbed for the Bluetooth) and the second port is partly software and a bit flaky. Many people’s applications got broken.
The second serial port you will see referred to as the “mini uart” and lives at /dev/ttyS0. It also calculates it’s bit timing’s from the CPU cores frequency and if the CPU is under heavy load it can corrupt the serial communications. Not good.
In order to work around this, many people “fix” the CPU core frequency so that the serial port is stable. This comes at a slight loss in performance (though normally not noticeable). I’ll describe how you do this in the next section.
To summarize, the default ports on a Raspberry Pi 3 / 4 and be crystal clear:
/dev/ttyAMA0 -> Bluetooth /dev/ttyS0 -> GPIO serial port.
If you stick with these as is, your Bluetooth will work as nature intended AND you can use a serial port over the GPIO (there is a way of swapping the serial ports around if you don’t want to use the Bluetooth and I’ll cover that at the end of this post).
Enabling
There is yet another wrinkle in that in the latest Jessie / Stretch / Buster releases (as of August 2019) the GPIO serial port is disabled by default. In order to enable it, edit config.txt:
$ sudo nano /boot/config.txt
and add the line (at the bottom):
enable_uart=1
As of May 2016 this will also lock the cpu core frequency for you so there’s nothing else you need to do (If you aren’t convinced and you really like to belt and braces it the command is: core_freq=250 which you add to the same file as well).
Reboot for the changes to take effect.
This should get you good serial communications for most uses.
Serial Aliases
On the Raspberry Pi 3 the second serial port is called /dev/ttyS0 and is by default mapped to the GPIO pins 14 and 15. So immediately, if you have code that references /dev/ttyAMA0 you’re going to have problems and things aren’t going to work.
You could go through your code and replace ttyAMA0 with ttyS0 and that should work. However, if you find yourself use the same SD card on a Raspberry Pi other than a rpi3 your code won’t work again.
In order to try and get around this the Foundation have introduced a serial port alias (as of May 2016 – 2016-05-10). Thus you have serial ports: serial0 and serial1 (rpi3). The Raspberry Pi kernel sorts out where these point to depending on which Raspberry Pi you are on. Thus on a Raspberry Pi 3 / 4 serial0 will point to GPIO pins 14 and 15 and use the “mini-uart” aka /dev/ttyS0. On other Raspberry Pi’s it will point to the hardware UART and /dev/ttyAMA0.
To find out where it is pointing you can use the command:
$ ls -l /dev | grep serial
Default Raspberry PI 3 / 4 serial port aliases
So where possible refer to the serial port via it’s alias of “serial0” and your code should work on both Raspberry Pi 3 / 4’s and other Raspberry Pi’s.
Disabling the Console
If you are using the serial port for anything other than the console you need to disable it. This will be slightly different depending on whether you are running a Raspberry Pi 3 / 4 or not.
For non Raspberry Pi 3 / 4 machines, remember it’s /dev/ttyAMA0 that is linked to the getty (console) service. So you need to perform this command from a terminal window:
remove the line: console=serial0,115200 and save and reboot for changes to take effect.
Swapping the Serial Ports on Raspberry Pi 3 / 4
What if you don’t want to use the Bluetooth and you want that high performance /dev/ttyAMA0 back on the GPIO? Well you can do this and the way you do this is via a device overlay called “pi3-miniuart-bt” i.e. use the mini-uart (/dev/ttyS0) for Bluetooth (you may get some loss of performance on your Bluetooth though).
You can also just disable the Bluetooth all together by using another overlay “pi3-disable-bt”. In both cases if you can find out more of what they do here: /boot/overlays/README
To use add the following line to the /boot/config.txt
Almost 21 years ago, my oldest daughter, Kathryn was born. The night before she was born, I brewed my first batch of beer. It was an American Pale Ale extract recipe that I cooked up on the stove. That batch was to kickoff a lifelong hobby that has taken me through many engineering adventures leading up to my current enterprise.
After several years of extract brewing on the stove, I got fancy and built a three vessel two tier brewing system. The showpiece of version 2 was a Recirculating Infusion Mash System (RIMS). This brewing technique creates a pumped loop in the mash tun that takes sweet wort from the bottom of the grainbed, heats it up to mashing temps, and recirculates it to the top of the grain bed gently via a manifold. The technique does indeed work, increase the overall yield of the mash and setting the grain bed over an hour resulting in crystal clear sweet wort entering the boil vessel.
Version 2 RIMS was controlled by an Omega CN9522-C2 PID controller. This small embedded computing device takes a temp input from the loop, and then uses a pulse across a solid-state relay to heat a hot-water heater coil in the RIMS before it gets recirculated. The only other electrical “thing” in the system was my Little Giant MD2-HC corrosive liquid pump. So the instrument box contained two waterproof light switches (one for power and one for the pump) and the Omega controller. Everything else in version 2 rig was manual. I had tri-clover clamps, brewing hose, and copper lines connecting everything together.
I used v2 happily for more than 15 years. Several years ago, I “got busy” with work, school, church, scouts, and life, resulting in a brewing hiatus for the last 4 years. But two things have happened lately to get me started back into my beloved hobby. First, a friend of mine opened a wood-fired pizza shop several miles out of town. Having tasted my homebrew before, he asked if I was interested in making some beer for his weekend pizza fanatics. This by itself wouldn’t have gotten me started, but Kathryn came to me several months ago and asked if I could make a batch for her 21st birthday (in December). She wanted the same recipe I made the night before she was born. Well, how can I turn that down?
And so, the journey starts. My goal in version 3 is to control the RIMS and all flow control with a Raspberry Pi. There are several reasons for doing this. First, it’s fun. This project encompasses mechanical, fluid, electrical, and software engineering. Second, no one has done it the way I’m going to do it. Third, by extending some new technologies like Internet of Things (IOT), I can do some neat stuff with the controls (eventually).
So this thread will include a diary of my Sweeney Brewery Version 3 adventure. Sometimes, I’m sure it will get tedious as I recount details so that others following behind me can duplicate the work. But it should be an interesting exercise, hopefully not in futility.
I recently read The Art of Business Value by Mark Schwartz. In this brilliant read, the author asserts that not only is business value an ill-defined term in the Agile literature, even if we could define it clearly, how do we estimate it? For example, one of the Agile PM mantras states that the backlog of user stories is prioritized by the product owner according to “business value.” But how does she determine what this is?
Far too often in Agile projects, I’ve seen teams create a “vomit of user stories” first, and then try to estimate the value of these stories, assuming that the “golden nuggets” of business value will be among them. This seems to be putting the cart before the horse. Wouldn’t it be more efficient and strategically aligned to determine what is valued by the business FIRST and then write user stories to satisfy that value?
And even if we are able to determine what is valued by the business, it is almost never stated at such an atomic level as feature X for product Y. When you look at the business value mantra of Agile closely, it’s not as well defined as we’ve thought all these years. Perhaps we’ve been reciting the mantra over and over without really understanding what it means.
I think we (IT and customers) need to spend more time looking at what business value REALLY MEANS in our environment. I’m not sure we have been doing a good of estimating the value of our stories.
A colleague of mine, who is another division-level IT manager, and I are teaching a course in the fall. The course is a senior level elective that focuses on special topics in technology management. Cool – right up our alley. We were given freedom to pick the topic, and of course we chose DevOps. You may have heard of it. It has become trendy is recent years, but I think it will prove to be more than a passing fad. You see, DevOps tries to solve problems, not primarily with technology, but rather with organizational functioning and communication.
The traditional definition of DevOps describes the intersection of communication and automation between IT development, operations and quality assurance. While these three areas are classically highlighted as the main areas of focus, in truth, DevOps is a set of principles for all of the IT disciplines. Recent sources have described DevOps as a philosophy for approaching IT work based upon four pillars; collaboration, affinity, tools, and scaling (cf. Davis & Daniels, 2016. Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale). More accurately, I think of DevOps as an organizational culture. Sure, part of DevOps is tools that enhance automation, communication, and collaboration. In fact, most people mistakenly talk about how to “do DevOps” and usually focus on tools. But what I find extremely useful is the push to break down organizational silos and embrace shared responsibility and authority across the organization.
Here’s the interesting part. As we have been trying to introduce DevOps into the work that we do here at the big school, we are finding that the organizational structure of a large Tier 1 University (or most any other higher education institution for that matter) is the antithesis of a DevOps culture. Higher education embraces vertical structures of organization and authority, delineated responsibility, demarcated services, territorial imbroglios, and finger-pointing when things go south. In IT, we see this among our IT organizations, between us and our customers, and even between organizations with a common purpose like academic colleges.
That is why I think DevOps is so important for Higher Ed IT. It gives us a framework to finally address some of the serious shortcomings of our environments in a way that will prove our worth to the academy. If we can only get over our historical cultures and shift our thinking, I think we can take Higher Ed IT to the next level using principles of DevOps.
