A few years ago, I got tired of a toaster that didn’t bother popping up before the toast was charcoal, so I got on-line and ordered a commercial-grade toaster from some restaurant supply store. Based on the presumption that restaurants couldn’t afford to have a toaster that didn’t work right, I hoped to have a reliable appliance well into the future. Unfortunately, that hope was unfounded. Within two years, the toaster quit working. You could hold the handle down and the heating elements would do their thing, but it wouldn’t stay down.
Isaac, being one of the bigger fans of toast in this house, rigged up an elastic band that would hold the handle down, but it wasn’t long until this arrangement produced it’s share of carbonized bread. Unfortunately for Isaac, I don’t eat a lot of toast anymore, so I didn’t really have much of a motivation to replace it. However, a few weeks ago I got a bug in my ear, went out to the garage for some tools, and tore down the toaster to see if I could figure out what was wrong.
The toasters I’d taken apart in the past (yes, I’ve disassembled one of almost everything at this point in my life) all used a bi-metalic strip in a mechanical assembly to hold the toast down until it heated up enough and bent far enough to release the mechanism. All in all, it’s a pretty simple setup, if a little unpredictable when trying to set the toaster for the perfect toast. I figured something had been bent or broken in this kind of an arrangement, and that I could probably adjust or repair it. If not, what difference did it make? The worst I could do was to ruin an already broken toaster. However, when I got it apart I realized my original assumptions were wrong.
This high-falutin’ hoity-toity commercial toaster used a digital timer circuit to control how long to leave the toaster on. This, as luck would have it, was a good thing. I’m reasonably good with mechanical stuff, but my bread-and-butter has for years been electronics. I pulled out my well-worn but still functioning test equipment from the days when I actually got paid for fixing things and went to work. Within a few minutes I’d reverse-engineered the simple circuit and identified the bad part. Easy, I thought to myself, I’ll just add this part to my next Digikey order for one of my other geek projects.
As it turned out, Digikey doesn’t carry the integrated circuit I needed. Neither do Mouser or any of the other parts-houses I’ve used before. The defective part was made by a Chinese semiconductor company and only available from China. In fact, the only place I could find to order it from without having to read Mandarin (or whatever language it was) was aliexpress.com, and it would take 2-10 weeks to arrive. The good part was that it would only cost me about $5.00 for 5 of the things including shipping it over on the slow-boat. I placed my order and sat back to anticipate the part’s arrival. What I’ll do with 4 extra “toaster timer” IC’s I’m not sure.
The parts arrived yesterday. Compared with Amazon, the shipping times leave a little to be desired, but I had the part in-hand so I went out to the garage and went to work without grumbling too much. I soldered in the new component, tested the toaster, and put it all back together pleased with a job well done. However, no sooner had I assembled it than I realized it wasn’t working. While it had been working on the bench while disassembled, it seemed to have a different opinion about proper behavior when fully assembled and on the kitchen counter.
I spent the next three hours disassembling, testing, tweaking, reassembling, testing disassembling, etc… Any time I put it all back together it wouldn’t latch the handle down. As it turned out, somewhere along the line, someone pushed a little too hard on the handle, and it bent the assembly, almost imperceptibly, but significantly. Any time the whole toaster was assembled, the case would interfere with the handle and prevent it from fully engaging the locking mechanism. It took forever to get everything straightened out and working reliably.
So, this gets down to my problem… I was seriously considering tearing out the electronics and programing one of my Arduinos to control the toaster. What kind of an idiot would do that? The alternative wasn’t much better. Instead of re-engineering a solution, I spent an inordinate amount of time fixing something that, in the end, is worth no more than half an hour of my time if I were to bill out at an hourly rate. I should have stopped before I even took it apart the first time, little lone the time and energy spent actually fixing it. The fact that I was actually cogitating re-engineering the thing to work with a custom-programmed micro-controller speaks volumes. Normal people would have just thrown the dumb thing in the trash and gone to WalMart for a new one.
In the ham radio community, homebrewing is a term used to describe making your own radio gear. For most hams, this doesn’t go much beyond building and tuning an antenna out of copper pipe or wire, but I’m not really your average ham. For one, I am almost never on the air. That said, as I’ve spent more time recently reconnecting with my roots as an Electrical Engineer, I’ve opted to use my license as an excuse to play around with ideas.
In the process of building my last project (the sunrise light https://diligent5.org/?p=1849) I bought an Arduino Uno to mess around with and compare with the capabilities of the Raspberry Pi I already had. In looking at the availability of A/D inputs and various forms of serial I/O on the Uno, I had a flash of genious (or insanity) where I thought it might make a decent controller for an antenna analyzer driven by an AD9851 direct digital synthesizer (DDS). So, what, you might ask (especially given the nature of the few people who actually read any of this blog), is an antenna analyzer?
Antennas are “resonant structures” which roughly means they are the electrical equivalent of an organ pipe or guitar string. Based on their construction, they will resonate at specific frequencies. The frequencies where they resonate are the frequencies where they work well. Trying to use an antenna that isn’t tuned to the frequency you are trying to transmit on will result in most of the energy going the wrong place (back into the transmitter instead of going out over the air for someone else to listen to), and can actually destroy your equipment. If you are going to build an antenna, you need to be able to tune it the same way you tune an organ pipe or guitar string, and in order to tune it you need a device to send tones into the antenna and measure how the antenna reacts to them. That is what an antenna analyzer does.
Analyzers are commercially available for both ham and commercial radio bands, and range from a few hundred dollars to a whole lot more. I’ve been eyeballing them for a long time so I can start building antennas, but I’ve never been able to talk myself into spending the money on one. But… if it’s a project, I build it a few dollars at a time and get the benefit of feeding my inner geek. Never mind how much it actually costs (especially if you factor in time).
Analyzers are fundamentally pretty simple. First, you generate a signal at the frequency you want to test, then use it to drive a bridge circuit. The rest of the analyzer is all about digitally measuring voltages across the bridge and converting those measurements into the parameters I’m interested in. As luck would have it, I’d been scanning various products advertised for the “maker” community (people who build stuff using Arduinos and such) and had seen an ad for modules based on Analog Devices AD9851. This chip uses a fast digital-to-analog (D/A) converter to generate a high-quality signal output that is digitally controllable from zero up through roughly 75 MHz (million cycles per second). This chip, combined with some filtering and amplification would make a perfect source to build my analyzer on.
Rather than buy an already complete module and have to figure out how to mount it, I opted to start from scratch and build a board that integrated the AD9851, would plug directly into an Arduino Uno, and contained everything needed to take the measurements (except for the user interface). I’d use the arduino to program the AD9851, digitize the measurements, do the calculations, manage communications via USB port to a host computer, and run a display and buttons. I grabbed a bunch of datasheets, opened eagle cad, and laid out my schematic and board.
Like most projects, it wasn’t nearly as straight forward as it seemed. I ran into a host of hiccups along the way, but over the next few posts, I’ll try to explain how it works and the gotchas I ran into.
A few weeks ago, I wrote about a project I’ve been working on that uses a raspberry pi to mimic a sunrise as a sort of alternative to an alarm clock (https://www.diligent5.org/?p=1849) . It’s generated a rather long list of learning experiences including things like the timing issues I wrote about previously. After thinking about it, I figured it wouldn’t hurt to document a few of them.
First, debouncing switches can be easy or hard… If you’re as dumb as me and want to set the system up to discriminate between long button presses, short button presses, and spurious noise it’s hard. I think my completed debounce and conditional sleep code (they’re tired together) are almost a third of the overall code. If all I wanted was to handle single button presses with the code waiting until it got one, it would have been pretty easy. If I wasn’t interested in keeping the processor duty cycle and power consumption down, it would have been easy. If I didn’t want to be able to have multiple functions depending on how the button was pressed, it would have been pretty easy. If I had a better understanding of python’s order of operations and language syntax, it would have been much easier. Unfortunately, I wanted to do all these things. When I first got the prototype up and running, I thought I had a reasonable approach they seemed to mostly work.
When I sat down to write the code to run the new board design that included the hardware PWM controller, however, I made the mistake (or not) of scrubbing all the code. I had seen some anomalous behavior trying to use the menu, and decided to look closer. What I found led me on a rather long detour. I ended up spending probably twenty hours working through the debouncing routines — roughly what I thought it would take to update it for the new controller. Fortunately, it was pretty simple to swap out the old controller logic, so my overall time at the keyboard wasn’t all that different than I expected. I just spent it doing different things than I had planned.
It all came together, but the most disheartening thing of all came when I turned the light on at the lowest brightness level. It still flickers. I can’t explain why. The PWM controller is on a hardware clock that isn’t subject to processor load issues or interrupts. In fact, the only time it should flicker or change brightness at all is when it’s begin commanded to change brightness. However, it’s only noticeable at very low intensities, so I’ve decided to stop there in my quest. It’ll have to be enough the way it is. At this point, I’ve been using it regularly for a few months, and it’s been stable and run as expected with one exception: the real-time-clock module I purchased off of ebay doesn’t seem to be working. Without an internet connection, the time doesn’t update after losing power. I’ll have to look into that later, but for now I’m just enjoying a little taste of success.
This fourth of July we were invited for a second year in a row to go with friends to their family reunion at the family’s farm/ranch outside Grants, New Mexico. I have to say that this family represents the kind of accepting and down right Christian people I think the world needs more of. Let me explain.
Many years ago, when the patriarch and matriarch were young veterinarians just out of school, they landed in this small town west of Albuquerque and set up shop – the husband dealing with large animals, and the wife handling the small ones. As life progressed, kids joined the scene as they often tend to do. If life weren’t already interesting enough for this small-town family, two of the brothers destined to join this family decided they couldn’t handle being separated, so they arrived together as twins. Unfortunately, when he was very young, one of the brothers contracted a severe case of influenza that crossed the blood-brain barrier and caused severe encephalitis. It was by no means certain that the twins would grow up together in this life, and the sick son’s future was precarious for quite some time. After a long time in a coma, he recovered; but the sickness had destroyed the area in his brain that processes signals from the ears. He was deaf. Profoundly deaf.
For the next several years, the matriarch would pack the kids in the car every day and drive over an hour away to take her son to the deaf school in Albuquerque while the other kids played at parks or learned sign language along with their brother. Our friend still remembers these almost daily trips and heroic efforts her Mom made. It was a great sacrifice for all involved, but it was one they all made.
Over the course of the next several years, the son began attending in-residence school and only came home on the weekends. It was a necessary evil as far as the family were concerned, but one that had to be endured none the less. One side effect of this transition was that while he was at school, the deaf son made friends with several other students who’s families had effectively, if not explicitly, abandoned them. Rather than leave them alone at the school, they were invited to join the family, and several began coming out to Grands on weekends rather than sit lonely at school.
I met several of these fine people last year when we first attended one of these family reunions. They were all described to me as being “my son” by a rather proud adoptive father. The family had opened their hearts and home to entire families who were otherwise marginalized or excluded from their rightful place in society. What a neat bunch of people, and what a great experience at a time when I was struggling to see the good in the world.
As I talked with the family over this last trip, I was shocked to learn that many hearing families of deaf children refuse to learn sign language. Even worse, they often completely abandon their deaf family members to social workers and deaf schools. This family was a shining exception to this awful reality. Everyone learned sign, and everyone (hearing and deaf) were made to feel important and a part of whatever was going on. In fact, I was among the few outsiders there who needed an interpreter (they were happy to interpret for me when needed). All around me there were animated silent conversations between friends and family.
I am impressed by the kindness and genuine love this family has for those who the rest of society have basically written off. At a time when the world seems very self centered, unkind, and intolerant; I find hope in the quiet goodness of people like my friends and their family. I hope they see in me a portion of what I see in them.
My family didn’t take a lot of what some would consider vacations when I was a kid. An annual trip camping for a few days in the nearby mountains was about all we managed most years. There were also times when we packed up to go somewhere more exotic like a national park, or to visit relatives far away. Among the memories of these trips I have shadows of memories where my parents were stressing about them — both before and during. I sometimes think a lot of the stress was financial, but the root cause is somewhat immaterial. The bottom line is that I’m not sure vacations were all that fun for my parents.
Universally, the half dozen kids in our family would argue non-stop over petty little things, we’d complain about whatever it was that they had planned for the day, be unhappy with the food they prepared, whine about being tired, and generally do almost anything we could to be ungrateful little twits. It wasn’t enough that we made ourselves miserable… We seemed to feel a need to make or parents miserable too. As I look back, I’m convinced we met with a great deal of success.
As time passes I think I understand better what my siblings and I put our parents through. Liz and I plan vacations and do our best to give the kids great opportunities and memories, but along the way it seems the best they can muster is to whine and complain about almost every aspect of the trip. Take them to one of the greatest wonders on the planet, and the walks are too long, the food we packed isn’t what they wanted, they actively try to irritate each other at least every ten seconds, and just want to sit back in the room and watch mindless cable shows all day. To ice the cake, I’m a stingy and unreasonable jerk when I don’t want to waste money on gift shop trash that I’m likely going to get stuck carrying all day and will certainly be thrown away and forgotten in a few days.
Along the way, I have to keep a calm voice and try to keep the peace as one after another of the party decide it’s time to suck the oxygen out of the room and burn everything to the ground. It’s exhausting, and has happened everywhere from Washington DC to Zion National Park. The hardest part is not burning it down myself.
Now, I have several fond memories of the vacations we took as kids, and have only really understood the burden they were on my parents as I’ve grown older. Because of this, I have hope that I’m not just wasting my time and even more limited energy. However, it is often trying. Pressing forward, hoping that we can keep it together just enough that the good memories float to the top and drown out the bad, is hard to do. It’s a bad day when I’m ready to go back to a job I don’t really like just to wind down from vacation, and I’m just about there again.
Stop, I'm told, and smell a rose.
Pause and take a break.
So I comply.
The smell offends my nose.
Why don't you do what others do?
I'm asked without words.
But I'm not them.
Must I pretend to be like you?
What's wrong with loving work?
Both the process and results?
Rest is wearying.
But labor refreshes and refuels.
Since we moved back into a city and left behind a mostly rural life I’ve had to adjust my hobbies to the new environment. I don’t spend much time planting fence posts, the only animal I take care of now is an old and grouchy dog, I don’t have old or worn out farm equipment to rebuild or repair, can mow my lawn with a weed whacker, and couldn’t fit a car in the garage to work on it if I had to. This has been a hard transition, but it has given me an excuse to reengage with several hobbies that have lain dormant for quite a while. One of the things I’ve restarted has been playing with electronics.
Back in high school I spent a lot of time in the electronics shop designing and building various projects that included a simple television jammer, an all electronic Christmas tree that could flash lights in various sequences, and a custom built clock that was crazy enough that it made airport security really uncomfortable when I took it to Kansas City for a national competition (after x-raying it, they made me disassemble it and show them it wasn’t a bomb). My brother Tolon and our neighbor Mike have tons of stories about the crazy stuff we did with electronics growing up, so needless to say, it was a big part of our adolescence. However, once I left college and the part-time television repair job I had, electronics mostly fell by the wayside. It wasn’t that the interest faded. It was really just that I had a long list of competing priorities and interests. Besides, I don’t have much use for the kinds of simple projects I could build at home. While flashing lights are cool in some respects, it doesn’t do much for me once it’s built. I have a higher standard of applicability for projects these days.
This last Christmas, however, I bought Isaac a robot car that used a raspberry pi for the controller. Unfortunately (or not, depending on how you look at it), the cheap Chinese version I bought came with code that was so bad that I spent my Christmas break learning Python and writing new code from scratch. I hadn’t done much coding for a long time, and in the process of making a functional software set for the robot I remembered how much I like that kind of a puzzle and challenge. Another thing working on Isaac’s robot did was get me back looking at electronics hardware design and thinking about the software/hardware interface in ways I hadn’t before. I have been a Linux geek for over 20 years, and the possibilities of a super-cheap, super-small Linux-based computer with exposed low-level I/O ports really piqued my interest to the extent that I actually had a spell of insomnia while a whole host of ideas for things I could do with it flooded my mind.
It didn’t take too long for me to realize that the best way to get sleep would be to pick a project and get to work on it. As I thought about it, I kept coming back to a project I’d built years ago and decided it was time to update it and build it again. The original project was nothing more than a Mr Coffee that I stripped the electronics out of and repurposed to turn on a light at a given time every day. This light woke me up every morning for several years, but it was bulky and ugly, and the way the light turned fully on instantaneously was rather jarring. In an effort to fix this shortcoming, about five years ago I designed and built an analog circuit to gradually turn on a bright LED lamp. Unfortunately, Liz hated the bright white color and couldn’t stand the fact that the LEDs weren’t diffuse enough. They were rather blinding if you looked right at them. I had to retire the light and Mr Coffee electronics.
In thinking about the possibilities of a super cheap computer with easy to use hardware interfaces, I came to the conclusion that I could easily build a control circuit to digitally dim a three color LED. I decided to build a raspberry pi based project that would mimic both the brightness and color of a sunrise at any time I wanted to wake up. Because it was software driven, I could tailor both the brightness and color to match a sunrise from start to finish. I would also be able to set it up so that I could program different alarms for weekends or any other unusual day. Not only that, but I could even program it to do any kind of goofy rainbow-colored light show if I ever got the inkling (but I have to admit that the odds of that are kind of low).
Now, I haven’t made custom circuit boards in almost 20 years, and I haven’t written much code since I left grad school. A sane person might hesitate to jump into what amounts to two simultaneous complex projects, and you might think it would at least have given me pause. But no, true to form I jumped in. I scoured datasheets from several electronics vendors, ordered materials for etching circuit boards, and began learning Eagle CAD. Before too long, I had a schematic complete. Not long after that, I had a circuit board layout. A few failed attempts later I had a complete board and was on my merry way writing code to see if it would all come together the way I intended it.
The top board is a Raspberry Pi Zero W. Beneath that board is the first completed controller board I built. The piece hanging off the right side is a real-time-clock module that keeps time when the power is off. The LEDs, and the circuit board with the LCD panel and input buttons aren’t connected in this picture.
After fumbling around with Python and learning some of it’s ‘features’ the hard way, I managed to make the LCD and buttons I bought work as a menu of sorts, and got it to start the sunrise sequence on-schedule. Pretty stoked about my progress, I plugged it in near my bed and set it to go off the next morning. Unfortunately (or perhaps fortunately) I woke up a few minutes before the alarm and was watching it as the first blue-gray light started to come on. Almost immediately, I realized my design wasn’t going to work. At low brightness, the light flickered enough to really bother me. I wanted to understand why, and what I could do about it.
As it turns out, one of my day-job responsibilities is setting design criteria for safety critical systems, and I had spent a good deal of time recently getting familiar with what are known as “real-time operating systems” and their role in safety-critical applications. In any modern computer, multiple processes (programs) compete for processor time. The operating system will hand control to a process, and how long that process has control before the next process gets to do it’s part is not tightly controlled. For example, if you’ve ever been working on a computer that suddenly ‘hiccuped’ for a second and then caught up with you, you have been the victim of a non-real time system.
For routine applications, a slight hiccup that results from a process taking too much processor time isn’t all that important. The process will eventually finish and the computer will catch up without any dramatic consequences. However, if that computer were flying a plane or guiding a missile, even a slight hiccup could result in a crash. For these situations, a special type of operating system is put in place to make sure that the important stuff always gets the processor time it needs, and only the unimportant stuff occasionally gets stuck with a hiccup (if at all). Everything runs on a heartbeat, and important stuff gets done every heartbeat, every time. When done properly, this kind of a system ensures that there aren’t any hiccups on things that matter.
So, how does this apply to my stupid little project? First, it’s fundamentally difficult to efficiently dim an LED the way you would dim a conventional light bulb — especially using a digital controller. Instead, to dim a high power LED you turn it on and off very rapidly, and our eyes average the intensity naturally. To make the light brighter, you leave the light on for a longer percentage of the time.
Well, as it turns out, the code that determines how long the LED stays on works by deciding every few microseconds whether to turn the light on or off. Because the ultra-bright LED’s I used are so bright, when I want them to be very dim the lights are only on for a few of these cycles before they turn back off again. Even small changes in how long the lights are on in that case make a big difference in how bright the light looks. The way this thing is set up, it turns the LED on and off 200 times a second (each cycle is 1/200th of a second) to make sure the human eye can’t see it flickering. To make the sunrise work, I break that 1/200th of a second into 1024 chunks (why not just a round 1000 you ask… 1024 = 2^10, and computers do most things best with powers of 2). When the light is at it’s dimmest, it’s on for 1 chunk (about 1/200,000th of a second) every cycle. When the light is all the way on, it’s on for the full 1024 chunks and never turns off.
When the light is at it’s dimmest (where I start it in a sunrise sequence) even a five microsecond delay (about 100000 times faster than a blink of the eye) will cause the light to stay on twice as long as it should and change the brightness by a factor of two. Small glitches make a big difference. As the code runs through it’s loop deciding when to turn the light on or off, other processes randomly run a little long, and the decision to turn off the light is delayed just a bit. Because the raspberry pi isn’t running a real-time operating system, there is competition for processor time, and that shows up as a flickering light that flickers worst when it’s on very low. Because I’d just been through the wringer working through the real-time operating system stuff at work, I instantly recognized the situation for what it was.
Unfortunately, this realization meant that my design was fundamentally flawed. I had relied on the pi for timing, and even using the most optimized code I could find to run the timing, the light still had a noticeable flicker. Did that stop me? If you are reading this, the odds are pretty good that you know a fair bit about me already, and could guess that I don’t quit that easily. One solution would be to implement the code in a real-time operating system. However, I’m not really an expert on those systems, and I don’t believe they’ve ported real-time linux to the pi. The answer would have to be a hardware-based timer for the lights, and the best part is that I already knew where to go to find one.
Something I learned while working with Isaac’s robot car was how servos work (the small motors that steer the car and point the camera). They work by generating a pulse with a very specific width proportional to the turn angle at regular intervals, just like the way I was trying to control the lights. Robot designers don’t use the I/O pins on the pi to control servos for the same reason it didn’t work well for the lights — flickering, but in the case of servos, they don’t flicker, they jitter back and forth. If you’re using the servo to control a remote-control plane for instance, that jitter would make the plane uncontrollable and result in a crash. In Isaac’s car, the designers had actually re-purposed an LED controller with built-in timing to generate the servo pulses, and I was already familiar with how that controller worked and how to program it using the pi. It would be an easy answer.
Frustrated, but unwilling to give up, I pulled open the schematic, deleted the control lines that I had been using, and added in the controller. A few days of spare-time later, and I had a new board layout ready to process. Thankfully, when I originally ordered parts for the first board, I had planned for the probability that I’d ruin several boards and had ordered plenty of extra resist film and copper-clad board. I was also willing to bet I’d break something or need to re-build another board, so I had spares of all the parts. I etched and solder-masked another board and built it out with everything but the new controller. At this point, I’m waiting to order the new part and am looking forward to getting the code written and version 3 up and running (version 1 died before the first hardware met the real world).
Version 3 of the board. The new controller IC goes where the copper pads are. I’m pretty confident this one will work to my satisfaction. The three big black things are the drivers for the red, green, and blue LEDs. The cluster of components towards the bottom of the board are a 5V power supply to power the pi and all the other electronics. I also added a real-time-clock module that keeps track of the time when the power is out, but that’s on the other side of the board.
At this point, if I were to add up the number of hours and the money spent on parts and processing stuff, this would definitively be the most expensive clock I’ve ever owned. To make it worse, I’m looking at probably 20 more hours of coding to fix bugs in the current code and integrate the new controller (I’m not particularly efficient with Python). Given my going labor rate, I can’t afford my own time. But then again, it’s not really about either the cost or the time.
I'm told it'd be better and cost less,
If I hired the experts to do it.
They reason true.
I know.
My time's too costly for stuff like this,
I should just pay someone else.
Again, they're right.
I know.
But money and time aren't the point,
I do it myself 'cause I can.
Joy has value.
I know.
Isaac has become quite a good shot. I had to move the shooting position back from where Michael had been, and he still shattered all the little bits of clay pigeon Michael had left on the backstop. Several cans suffered the same fate, but with the 22 pistol instead.Michael hasn’t shoot much before, and didn’t really groove on it when he did (that probably had more to do with the chaos of shooting with a bunch of crazy cousins and uncles who are going Rambo all around him). This time he got all the time he wanted without a lot of distraction and had fun watching as clay pigeons shattered and jumped around on the backstop.Dinner was a plate of rice and beanless chili. I only ever make this concoction when I’m camping — it’s become something of a tradition now.
Isaac snapped this while I was supervising Michael destroying a bunch of clay pigeons with the 22
We hiked up this mesa in the morning. The boys found several arrowheads and flakes left from people making arrowheads.
Isaac was preparing for a campout with the young men from church a couple of weeks ago when Michael asked when I could take him camping. The weather has been mostly cooperating, so I told him we’d go in two weeks if the weather cooperated. Two weeks went by and the weather was fine, so we packed up the truck and headed to an area just outside the Ojito wilderness.
We found a place just off the road and made a fine camp for the night. After setting up camp, the boys and the dog explored a deep arroyo nearby while I made dinner and gathered firewood. We spent the evening watching the fire and just hanging out until bed.
When we woke up the water was frozen solid, and Michael was none too happy about the cold. However, a campfire, some hot chocolate, and a pancake breakfast make everything better… Even the cold of an early spring morning in the high desert. I love the high desert in the morning.
After the sun came up, we put out the fire and hiked up a nearby mesa to explore. Thornton had a blast sniffing around, and even managed to flush out a rabbit, but I don’t think he’d make a good coyote… The rabbit got away with a large margin of safety. Along the way, the boys each found several partially complete arrowheads along with a bunch of other interesting rocks. After the hike, we set up targets and the boys spent about an hour shooting at clay pigeons they had found the day before.
One downside of BLM land is that there are always people who don’t seem to care what condition they leave it in. The area we were camped in was littered with spent cases, beer cans, and all kinds of other trash. Before we left, the boys and I policed up the area — filling a large (55ga) trashbag in the process (I take huge bags with me just for this reason). I hope my boys understand how important it is to take good care of what God has given us. I was proud of them for not complaining that the mess wasn’t theirs. The area looked much better when we left.
