NOTE: The only people this doesn't apply to are full-blooded descendants of Native Americans / First Nations / indigenous peoples of the Americas. All the rest of you, listen up.
Jennifer Mendelsohn got tired of hearing Americans speaking out against immigration. So she took the names of some of the loudest opponents, did some genealogical research, and handed them a copy of their family tree — with immigrants at the roots.
My favorite part of this article about Mendelsohn's #resistancegenealogy research was when she told Tomi Lahren, who said Dreamers were not "law-abiding Americans", that her great-great-grandfather had been indicted by a grand jury for forging his naturalization papers.
Every one of us is a child of immigrants - many of them were "illegal", or refugees, or unwanted. Many of them took the low-paying jobs just so they could have a shot at the American Dream, and they were resented for it. But they stuck to it, and today we get to claim our natural-born citizenship because of them.
Actually, I'm an immigrant, too. Brought here as a child when I was 7 years old. Wanna make something of it?
Essays on current topics and marginally relevant events. Written by a twenty-first century Renaissance man, a father of five with hundreds of children, a papa who isn't a father, and an uncle who isn't an uncle. Written by a computer professional who doesn't like computers, by an outdoorsman who doesn't get enough time outdoors, by a meat-eater who enjoys garden burgers and veggie pizzas, and by a poor man who is rich in things money can't buy.
Sunday, January 28, 2018
The Wall is a Dumb Idea
Come on, somebody say it out loud: The Wall is, simply put, a dumb idea.
Physical barriers have been tried in the past, and people either go through them, under them, over them, or around them. Witness Hadrian's Wall, the Great Wall of China, the Berlin Wall, the fortified border between West and East Germany, the Iron Curtain, and the Maginot Line.
The only counterexample I can think of might be the fortified border between North and South Korea. but even then, small numbers of people just go around the wall, traveling first to China and then to South Korea.
Walls eventually crumble, or become irrelevant - or they're preserved as tourist attractions. Trump's Wall will be symbolic, but not much else, because would-be immigrants will find ways to bypass it. . The attraction (and the desire) to live and work in the United States, legally or illegally, is simply too strong.
Physical barriers have been tried in the past, and people either go through them, under them, over them, or around them. Witness Hadrian's Wall, the Great Wall of China, the Berlin Wall, the fortified border between West and East Germany, the Iron Curtain, and the Maginot Line.
The only counterexample I can think of might be the fortified border between North and South Korea. but even then, small numbers of people just go around the wall, traveling first to China and then to South Korea.
Walls eventually crumble, or become irrelevant - or they're preserved as tourist attractions. Trump's Wall will be symbolic, but not much else, because would-be immigrants will find ways to bypass it. . The attraction (and the desire) to live and work in the United States, legally or illegally, is simply too strong.
What is needed is not a $25 billion physical wall, but an immigration policy that is sound, enforceable, and humane. Both the Democrats and the Republicans in Congress can do better than they're currently doing. And the President is as dumb as his Wall.
p.s. Why not use the $25 to do something useful? Like give it as a grant to the states, specifying that it be used to increase K-12 teacher pay and to hire more teachers?
p.s. Why not use the $25 to do something useful? Like give it as a grant to the states, specifying that it be used to increase K-12 teacher pay and to hire more teachers?
Labels:
congress,
democrates,
immigrants,
immigration,
policy,
politics,
republicans,
stupidity,
trump,
Wall
Saturday, January 13, 2018
Book Review: Boardroom Bullrider: 5 Lessons Learned about Business in 8 Seconds
Bryan Merritt is a turnaround artist, a hired gun who travels around the world, helping companies who have lost their mojo to become vibrant and profitable again. If his clients are willing to take his blunt, straightforward advice, and make the changes he says they need to make, then they win, and he is successful. He loves this kind of work and it gives him great satisfaction.
Much of his approach to business was learned in the arena – the rodeo arena, to be specific. Ever since he got on the back of his first bull at 16, he was hooked. He loved bullriding, and it also gave him great satisfaction.
You don’t get a lot of time to think when you’re on the back of the bull. If you’re good, you get 8 seconds, and then the buzzer sounds, you win, and you look for a graceful way to dismount. But bulls don’t like to be ridden, so you’d better know what you’re doing if you intend to win. In his bullriding career, Merritt identified five key lessons to help him stay on the bull – the same five key lessons that he uses as a corporate fix-it man to save floundering companies.
You don’t have to hire his company, Matrix Management Systems, LLC, to benefit from his wisdom. Merritt also does webinars and workshops. Now he offers those five lessons to you in his new book, Boardroom Bullrider: 5 Lessons Learned about Business in 8 Seconds. Skillfully mixing rodeo stories with stories about the business world, Merritt presents his five lessons and, in his straightforward manner, at the end of each lesson he pushes you to “get on the bull,” to do something that will make you make the lesson part of you.
I won’t tell you what his five lessons are. That’s what the book is for. Read it yourself. I measured it against some of the classics in business literature, and Boardroom Bullrider holds its own.
The one thing the classics have over Bullrider is page count. Merritt manages to make his points in 158 pages, not counting an absorbing introduction. Merritt is a great storyteller, but he doesn’t waste words. That’s his style. It’s part of the 80/20 principle that he focuses on so passionately. Still, you will find yourself wishing that he had spent more time on certain points, turning one sentence into a paragraph or one paragraph into several.
His advice is not just for moneymaking companies. It’s also for nonprofit organizations, government agencies – and you as an individual. Bryan’s advice can help you succeed in life.
Boardroom Bullrider is available from many booksellers, including Amazon.com, or directly from Bullrider Press.
Monday, November 27, 2017
Arduino Project One: More about that Hall effect sensor
Well, I've spent my spare time today doing more research into using Hall effect sensors as proximity sensors. Sometimes you just have to know which questions to ask and how to ask them.
It turns out that the SparkFun ACS712 product may be overkill, or else the wrong part for the job. What I really need are a one-dollar sensor and a ten-cent resistor. This article tells how to do it: https://diyhacking.com/arduino-hall-effect-sensor-tutorial/ .
Better yet, here's a sensor that's all ready to go:
It's available from Digi-key, Newark/Element14 or Amazon for about $14.
I'm going to see if I can bend one of the SparkFun boards to my will, since I already have them. If I can't, then I'll place an order for the parts I need.
You live and you learn.
It turns out that the SparkFun ACS712 product may be overkill, or else the wrong part for the job. What I really need are a one-dollar sensor and a ten-cent resistor. This article tells how to do it: https://diyhacking.com/arduino-hall-effect-sensor-tutorial/ .
| The AH3364Q-P-A, from Diodes Inc. |
Better yet, here's a sensor that's all ready to go:
It's available from Digi-key, Newark/Element14 or Amazon for about $14.
I'm going to see if I can bend one of the SparkFun boards to my will, since I already have them. If I can't, then I'll place an order for the parts I need.
You live and you learn.
To read the other postings about this project, click here and scroll to the end.
Labels:
ACS712,
Arduino,
DIY,
garage door,
Hall effect sensor,
IoT,
remote,
SparkFun
Sunday, November 26, 2017
Arduino Project One: A detour into 3D printing
This is a sidebar to the main project thread. This is all about 3D printing.
By the way, as this entry shows, I'm a babe in the woods when it comes to 3D printing, both the software used to create the models, and the procedure to transfer the model to a printer and to print them. Advice from my readers — knowledgeable and useful advice — would be appreciated. Feel free to add a comment.
In my last update, "Lots of Progress", I repeatedly mentioned SolidWorks because I thought it was the only game in town.
Hah.
Our local library has two 3D printers. They suggest Tinkercad for casual 3D design work, Sketchup for more serious 3D design work, and Cura LulzBot Edition for printing your design on one of their LulzBot printers.
Know what? All of those software packages are free. Actually, Sketchup is available in a free and a Pro ($695 - cough) version.
Sketchup has grown up since Google bought it from that little company in Boulder and encouraged people to use it to plant structures all over Google Earth.
So now I have my 3D printing toolpath defined. As with Corona SDK, I'm sort of familiar with the technology from my computer-game-programming days. I'm sure it's come a long way in 12 years, but it's nothing I can't pick up quickly.
UPDATE, THE NEXT DAY:
Hey! I already have Wings 3D on my computer. It's part of my game-programming toolpath! It can export StereoLithography (.STL) files, the preferred file format for Cura LE. Wings 3D is open source and supported by a huge community.
I may not need to install any new software to do my 3D designs. We'll see ...
UPDATE, THREE DAYS LATER:
I totally ignored 3D Builder, an app first included in Windows 8.1 and currently part of Windows 10. It looks like 3D Builder is for the casual user, similar to Tinkercad. Most screenshots I've found are for toys and trinkets, but here's a not-so-casual design that looks pretty impressive.
Searching online for information on 3D Builder, I haven't found anything written about it (I mean, like reviews or tutorials) that is all four of these:
By the way, as this entry shows, I'm a babe in the woods when it comes to 3D printing, both the software used to create the models, and the procedure to transfer the model to a printer and to print them. Advice from my readers — knowledgeable and useful advice — would be appreciated. Feel free to add a comment.
In my last update, "Lots of Progress", I repeatedly mentioned SolidWorks because I thought it was the only game in town.
![]() |
| SolidWorks, really good 3D design SW by Dassault Systemes |
Hah.
Our local library has two 3D printers. They suggest Tinkercad for casual 3D design work, Sketchup for more serious 3D design work, and Cura LulzBot Edition for printing your design on one of their LulzBot printers.
![]() |
| Tinkercad, by AutoDesk (that's a Raspberry Pi case) |
![]() |
| Sketchup, by Trimble, Inc. (this screenshot is from when it was a Google product) |
![]() |
| Cura LE (Lulzbot Edition) |
Know what? All of those software packages are free. Actually, Sketchup is available in a free and a Pro ($695 - cough) version.
Sketchup has grown up since Google bought it from that little company in Boulder and encouraged people to use it to plant structures all over Google Earth.
So now I have my 3D printing toolpath defined. As with Corona SDK, I'm sort of familiar with the technology from my computer-game-programming days. I'm sure it's come a long way in 12 years, but it's nothing I can't pick up quickly.
UPDATE, THE NEXT DAY:
Hey! I already have Wings 3D on my computer. It's part of my game-programming toolpath! It can export StereoLithography (.STL) files, the preferred file format for Cura LE. Wings 3D is open source and supported by a huge community.
![]() |
| Wings 3D, a powerful 3D modeler used by the gaming and CGI industries. |
I may not need to install any new software to do my 3D designs. We'll see ...
UPDATE, THREE DAYS LATER:
I totally ignored 3D Builder, an app first included in Windows 8.1 and currently part of Windows 10. It looks like 3D Builder is for the casual user, similar to Tinkercad. Most screenshots I've found are for toys and trinkets, but here's a not-so-casual design that looks pretty impressive.
![]() |
| 3D Builder by Microsoft, now an integral part of Windows 10 |
If you don't use 3D Builder, then it and its companion apps, such as Paint 3D, are simply a waste of space on your hard disk. But if they're there and they're free, they may be worth a look.
Searching online for information on 3D Builder, I haven't found anything written about it (I mean, like reviews or tutorials) that is all four of these:
- current
- serious and useful
- written by a serious user, not just a fan or a professional reviewer
- offered by a third party (not written by Microsoft or published on a Microsoft page)
I welcome any serious and useful input from my readers, about 3D Builder.
UPDATE, 15 AUGUST 2019: Two years later, the 3D design landscape has changed. As I finally sit down to design the enclosure for my Arduino project, I re-review my toolset and make a few changes of my own. Read about it here.
UPDATE, 15 AUGUST 2019: Two years later, the 3D design landscape has changed. As I finally sit down to design the enclosure for my Arduino project, I re-review my toolset and make a few changes of my own. Read about it here.
To read the other postings about this project, click here and scroll to the end.
Labels:
3D Builder,
3D modeling,
3D printing,
android,
Arduino,
Cura,
DIY,
garage door,
IoT,
LulzBot,
microsoft,
remote,
Sketchup,
Solidworks,
Tinkercad,
Wings 3D
Arduino Project One: Lots of progress
Introduction
I got to put a lot of time into the project this weekend, and I got some cool stuff done. I ... well, here are two pictures for you, and then the details.
![]() |
| Things glowing in the dark |
![]() |
| Lit by a desk lamp - I have to learn to take better pictures. |
Hardware fully assembled
I put all the hardware pieces together. In the picture above, you will see the Arduino stack at the top. You've seen this before.
The breadboard has two new peripherals. First, at bottom center is a 16-by-2 liquid crystal display that I found while looking for jumper wires in the Sunfounder Project Super Starter Kit. This LCD can run with either a 4-bit or an 8-bit interface, plus 2 more digital pins for the RS and Enable signals.
Second, the little red guy on the right is the Hall Effect sensor. When installed, this will be on the other end of a ten-foot long cable, mounted to the lintel.
You will notice a potentiometer on the left side of the breadboard. That's to control the contrast of the display. This is absolutely necessary with an LCD display. In the final enclosure, I'll use a trim pot that can be adjusted with a jeweler's screwdriver, through a hole in the enclosure.
Arduino software (almost) complete
The Arduino program is almost fully fleshed out. It searches for a Wifi router / access point, connects to it, and displays the SSID (the router's name) and its own IP address. Internally it has a list of access points, and cycles through them until it makes a connection.
In case of power failure, the Arduino program restarts, and with any luck the ESP8266 will have saved the connection information from before the power failure. If not, it will take several minutes for the router(s) to reboot, so the ESP8266 will count down 10 minutes on the display and then try again.
Once it has a connection, it starts a TCP server and opens a socket on an out-of-the-way port, to listen for clients. Every ten minutes it pings the router to make sure the Wifi connection is still good.
That's where things stand right now.
When a client opens a connection to the server, well, that code is still in skeleton form. Before I can finish it, I have to write a client program in Python or C (or Corona!) to exercise the connection. That's one of the next steps.
The display
This was a bit of serendipity. I'd forgotten that Sunfounder kit came with an LCD. This is the standard 16x2 display based on the common ST7066/HD44780 parallel interface. This is a white-on-blue one with not very good contrast, so I'll buy a white-on-black or red-on-black one for the final product. I'd really like an old-fashioned, dot-matrix alphanumeric, 16x2 red LED display, but I haven't seen any of those for a while.
The display uses 4 digital pins for data, and one each for RS and Enable, so it fits within my pin budget.
Incorporating it into the code was a cinch, thanks to the Arduino LiquidCrystal library.
Detour: Who (or what) is "Eorlingas"?
For those of you who already looked it up on the Web, congratulations. For those of you who didn't even have to look it up ('cause you already knew!), I offer you my deepest regards.
For years, every new computer, callphone and game system in our family has borne the name of a fictional horse. When high-speed Internet finally made it to our neighborhood (yes, children, some of us first got our Internet through the phone line - at 2400 bits per second!), we needed a good name for our router, and we chose Rohirrim, the formal name for the Riders of Rohan, from The Lord of the Rings. Since that time, we have worn out or obsoleted four routers, and we're on our fifth one. It's the Fifth Detachment of the Rohirrim, or FifthRohirrim.
The architecture of our house is such that the back rooms don't always receive a good signal from the router. I want the router to be hard-wired into our Xbox and our TV, so I can't move it. So, I installed a Wifi repeater in the back of the house. (By sheer coincidence, although I'd love to claim clever planning, this repeater is located about six feet above the garage door opener.) The repeater can't be named after a horse, since it's part of the infrastructure, not a computing device.
"Rohirrim" is an ancient Gondor word. The Rohirrim didn't use that word to identify themselves. In the ancient language of Rohan, they were descended from a king named Eorl, hence they were the Sons of Eorl — the Eorlingas.
I will claim clever planning for that one.
Back on the main road: the Hall effect sensor
I decided to try the ACS712 dev board first, because it has built-in trim pots for Vref and gain. I only had to connect it to 5V, ground, and an analog input on the Arduino. I wasn't happy with its performance at first. The voltage level drifted all around. I finally got it to settle down, but I can't have it drifting like that in real life.
When I finally got it settled down, I used a refrigerator magnet to manipulate it. I got the Vref and gain pots adjusted so that it pegged at 0.0 V without the magnet, and at 5.0 V with the magnet touching the chip.
Some voltage level in the circuit is floating. I don't understand the circuit well enough to fix it yet. Maybe I need to put a load (you know, a resistor) between the two current input pins.
Other than that, the sensor just works without complaint or fuss. Clearly, I have more homework to do before I can use it in real life, but this weekend's results were promising.
When I finally got it settled down, I used a refrigerator magnet to manipulate it. I got the Vref and gain pots adjusted so that it pegged at 0.0 V without the magnet, and at 5.0 V with the magnet touching the chip.
Some voltage level in the circuit is floating. I don't understand the circuit well enough to fix it yet. Maybe I need to put a load (you know, a resistor) between the two current input pins.
Other than that, the sensor just works without complaint or fuss. Clearly, I have more homework to do before I can use it in real life, but this weekend's results were promising.
It needs a case, an enclosure
I've been thinking about this for a while. I'm going to have to put the Arduino in a case.
All of the Arduino Uno R3 enclosures I've found so far are for just the Arduino Uno R3 board. Once you add a shield to your Arduino, it outgrows the enclosure.
A generic project box might be okay, but it can't be metal, because of the Wifi.
I thought of 3D printing one. I don't know SolidWorks, which I think is what everyone uses, so I'd have to learn SolidWorks. I looked for ready-made 3D printable designs, and the first one I found was, I'm really sorry to say this, ugly.
Okay, I just looked again, and there are some better-looking ones out there. None of them solve my height issue, but if I can get their source and manipulate it in SolidWorks or something, then I can take care of that myself.
I also need to include openings for: the LCD, the contrast adjustment for the LCD, and any LEDs I want to make visible.
I think that making the enclosure, and fitting everything in it, is going to be more work than the hardware and software parts of the project. Maybe I'll just use a cardboard box, an X-Acto knife, and clear packing tape. I'm only half-kidding.
The sensor needs an enclosure too
I can't just nail the Hall effect sensor to the beam in the garage. It will be exposed to a rather harsh environment. I may need to 3D print a case for it as well.
Alternatively, I could encapsulate it in potting compound. That would be just as good - but I'd have to find a way to include mounting holes. And whatever I do has to be nonmetallic, or at least nonmagnetic or nonferrous. Hmm. That will take more thinking.
What's next
I've made good progress so far. Here's what I still need to do
- Write a TCP client in Python or C, to exercise the server.
- Port that TCP client to an Android app, using Corona SDK.
- Finish the Arduino code:
- Hall effect sensor
- Debug the TCP client-handling code
- Finish the Android app as well.
- Get a real LCD display.
- Design and fabricate enclosures for the Arduino stack and the sensor.
- Assemble the whole thing.
Other items that come to mind:
- Try the breadboard design in the garage before I commit to a final design.
- Run Wireshark while the server is running, to see who tries to call my Arduino.
- Configure my router to allow passthrough only on the designated port, or from designated clients.
- Exercise the challenge-and-response algorithm.
- Document the whole thing.
To read the other postings about this project, click here and scroll to the end.
Labels:
3D printing,
ACS712,
android,
Arduino,
Corona,
DIY,
Elegoo,
ESP8266,
garage door,
Hall effect sensor,
IoT,
liquid crystal display,
remote,
Solidworks,
SparkFun,
Sunfounder,
Wifi
Wednesday, November 22, 2017
Arduino Project One: The Arduino program takes shape
Introduction
This week, I created the skeleton of the program for the Arduino stack. I'm not ready to share my source code yet. Let me get the rest of the meat on the skeleton first.
Security
I listed some ideas for my cybersecurity scheme last week. I have incorporated all of the measure I listed into my program. I'm sure there's a hacker out there somewhere who will figure it out. My description here isn't meant as a challenge to them. It's just to inform you of some simple things that worked for me.
- I've chosen a port number, out of the 65,535 available, that's easy to remember.
- The server will only accept client requests from specified devices, and not from the world at large. Although MAC address spoofing is a thing, this will stop all but the most determined hackers.
- The server will use TCP instead of HTTP, trading long and legible transactions for short and incomprehensible ones.
- The router autoforward will be tweaked so that only TCP requests via the specified port can get through to the Arduino.
- The server uses a challenge-and-response mechanism, like two spies swapping passwords. When a socket is opened and the client's authorization is verified, the server sends the client a randomly-generated numeric sequence. The client must reply with the proper numeric sequence. I intend to keep the details of this algorithm proprietary. Sorry, folks.
- It may be necessary to have the server go through the challenge-and-response several times in the life of a connection.
Robustness and Reliability
The terms "robust" and "reliable" are not synonymous. "Reliable" means that the system will not fail during regular operation as a result of stupidity — my stupidity, to be specific. "Robust" means that the system can recover from power failures and loss of Wifi signal all by itself, without any human intervention.
When the Arduino is first powered up, or when it recovers from a power failure, it looks through its list of available Wifi routers and tries each one in turn, until it gets a connection. If it doesn't get a connection at all, then it sets a timer for 10 minutes and tries again. This is because it can take DSL modems and Wifi routers a while to recover from a power failure too, so if it doesn't catch one the first time, it gives it time to reboot.
After it gets a Wifi connection, it sets up a permanent TCP socket to listen for client requests. Although client requests are the whole reason for its existence, they're not very frequent, so it will spend most of its time being idle.
Every 10 minutes or so, it will ping the Wifi router, to verify that it still has the connection. If the ping fails, then the Arduino has lost the connection, so it goes through the power-up sequence again.
When a client requests a connection, the Arduino opens a temporary TCP socket for that client. It will be up to the client to send a TCP query every second or so, unless it's sending a button-push command. It's up to the client, whether it's a webpage or an Android app, to politely say goodbye and close the socket when it exits. (I'm sure that Corona SDK and JavaScript include onExit() event servers, or something similar.)
But it's possible for the remote client to just drop the connection - battery dies, phone gets run over, computer blue-screens, that sort of thing. So the Arduino will set a watchdog timer when it opens the temporary socket. Any query from the client resets the watchdog timer (that's called "kicking the watchdog" in Embedded Programming Land). If the client doesn't send a query for a long time, the watchdog timer expires, the Arduino says goodbye to the client in case the client is listening, and then the Arduino closes the socket.
When the Arduino is first powered up, or when it recovers from a power failure, it looks through its list of available Wifi routers and tries each one in turn, until it gets a connection. If it doesn't get a connection at all, then it sets a timer for 10 minutes and tries again. This is because it can take DSL modems and Wifi routers a while to recover from a power failure too, so if it doesn't catch one the first time, it gives it time to reboot.
After it gets a Wifi connection, it sets up a permanent TCP socket to listen for client requests. Although client requests are the whole reason for its existence, they're not very frequent, so it will spend most of its time being idle.
Every 10 minutes or so, it will ping the Wifi router, to verify that it still has the connection. If the ping fails, then the Arduino has lost the connection, so it goes through the power-up sequence again.
When a client requests a connection, the Arduino opens a temporary TCP socket for that client. It will be up to the client to send a TCP query every second or so, unless it's sending a button-push command. It's up to the client, whether it's a webpage or an Android app, to politely say goodbye and close the socket when it exits. (I'm sure that Corona SDK and JavaScript include onExit() event servers, or something similar.)
But it's possible for the remote client to just drop the connection - battery dies, phone gets run over, computer blue-screens, that sort of thing. So the Arduino will set a watchdog timer when it opens the temporary socket. Any query from the client resets the watchdog timer (that's called "kicking the watchdog" in Embedded Programming Land). If the client doesn't send a query for a long time, the watchdog timer expires, the Arduino says goodbye to the client in case the client is listening, and then the Arduino closes the socket.
TCP/IP
I haven't decided whether to allow multiple clients yet. Normally, only my wife and I will be using the app, and very seldom at the same time. It would be crazily rare to have three people trying to control the garage door at once. Still, it would be annoying for one person to open the app on their phone, and the other person try to open it on theirs, and get the equivalent of a busy signal. So I'll probably have to allow multiple clients.
I haven't put in the actual TCP/IP commands yet. That's for later.
Sensor and Actuator
I haven't wired up the Hall effect sensor, and I haven't written any code for it. And although I haven't actually connected the relay to the garage door opener yet, I have written the relay code, and I've verified that the relay shield plays nicely with the ESP8266 shield.
What's Next
I'll stick with this program until it's finished. Then I'll need to write a server in plain vanilla C, or maybe Python, to test it. Once the program is finished and it works, I'll post the source code.
To read the other postings about this project, click here and scroll to the end.
Subscribe to:
Posts (Atom)










