SOTA - Raft River Hat Trick

In pouring over SOTA Maps a couple years ago, I noticed a location where three 8-point peaks were in close proximity:

• W7U/BO-002 - an unnamed peak "9335," 
• W7U/NU-045 - George Peak, and 
• W7U/BO-001 - Bull Mountain

After three attempts and hours on Google Earth, I finally figured out how to get up there. This post is an attempt to make the directions more clear for others--with luck, this can be a 24-point day!

I first activated George and Bull back in 2018. Didn't make it back until ARRL's 2020 Field Day, when I activated 9335 and George the day before Field Day, and participated in Field Day from Bull Mountain (until the wind hit sustained gusts over 40 mph and thunder and lightening "appeared" in the imminent forecast).

The Route

Google Maps and most of the other online maps really don't understand how to get here. Plus, jeep trails and routes on maps in real life end up either 1) completely faded and overgrown or 2) on private land. So finding a safe, feasible, legal way to get up there was a challenge! In short, it's a series of Forest Service roads as you leave Standrod, UT:

1. From Snowville, UT head west to Standrod
2. From Standrod, take FS 005 south
3. At the "T" take FS 011

FS 011 is not for the faint-hearted and absolutely requires 4WD (4L, in fact). At times, I locked my rear diff to get through steep sections with loose rock (rock, not gravel - rock). 

"9335"

As you hit the top of the mountain, you'll see 9335 in the distance. Park anywhere that's safe (there's a lot of undergrowth, so don't take risks and cause this place to burn), and head up to 9335. This is the view from 011 about 1/2 mile south of where I parked to activate 9335 in 2020.

 For 9335, you're above treeline so mostly it's sagebrush, grasses, some flowers, and a whole lotta cow pies. The hike up is just walking over, around or through sage. There is a fence line that cuts the actual summit off - I was on the "wrong" side of the fence line but well within the 250' activation zone, so I activated just west of the actual summit.

George Peak

Your next adventure will be George Peak. You'll still be in 4L for this, for sure! Continue east on 011 until it turns south. It'll connect first with 022 and then with 009.

Follow 009 to the southwest all the way until you hit George Peak. You'll come to a gate (might be closed, might be open) and signs about a private hunting club. You are allowed to pass through but you must stay on the road. 

The route is mostly road, with a lot of grass and sage. 

The views are, however, amazing -- you can see the Great Salt Lake, Promontory Point, even Antelope Island off in the distance.

If you've programmed the coordinates into your GPS, you'll find George Peak easily. On the map, the flat spot on the ridge appears to be the same altitude as the peak in the distance, so it's unclear which is the actual peak.

This either is, or is not, George Peak.

And yet this either is, or is not, George Peak. For the sake of SOTA (and since Bull is literally a drive-up), I activate the craggy peak each time.

One geological survey marker is good, but...

Two must be better :)

Panoramic view from George Peak looking from west to north to east (panning from 270 to 0 to 90 compass degrees). Not a lot of trees up here, but very green.

Bull Mountain

The final "peak" in this hat trick is Bull Mountain. I'm always torn up about this one - honestly, the road literally drives across the summit--how do you consider it activated? It's a moral dilemma but for the purists, you can park somewhere and hike a ways in.

The area around Bull Mountain is incredibly beautiful, with plenty of grassland and some wildflowers.

Not a bad place to watch the sun set!

Bull Mountain itself? Not so much special, just a grassy area where cows like to munch.

This is my SOTA setup for Field Day 2020. I lasted about 6 hours in this spot, after moving here around 10 am. By 3 PM the winds were blowing my antennas down and literally lifting half of my rooftop tent. Tuning into the Weather Service forecast, it was obvious I needed to beat a hasty retreat!

Overall, this 24-point "hat trick" is a fun trip with a couple nice peaks and a flat area that's amazing for propagation. There are other peaks nearby, so the area still has some opportunities for exploration. It's neat to have first activations on all three summits but I hope these directions help other SOTA enthusiasts get out and visit this range. Let's not make it too popular, but more people should have the chance to enjoy the incredible views up here!

- 72 de K7JTO

Winter Field Day Prep Project - Yaesu FT-897 Headset Interface

Clearly it's been too long since I last blogged--plenty of catch-up posts to publish this winter. But with Winter Field Day around the corner (as in tomorrow), I wanted to get this project wrapped up - a low-cost interface for an electronics store headset into my FT-897. Yes - I can get much better sound (TX and RX) with a Heil headset, and I'm saving up for one. I just happened to have this older headset laying around, and I typically just use it for Webex and Skype, so I figured it'd meet my needs: a quiet way to operate radio, easier on the ears, but at a fraction of the cost.

After some research, I found this article, which included a wiring diagram: http://www.n1gy.com/yaesu-headset-adaptor.html



The diagram is nicely designed, with polarity guides for the 47 uF capacitor. I could have built this for less than $15 if I'd only ordered one of each components, but I realized my "junk box" is a bit inadequate, so I ordered 10 3.5mm stereo components, a mixed box of caps, and a mixed box of resistors. All told, this build cost $30, with a bunch of parts left over.

For ease of construction, rather than using the brown wires (as in the circuit above) to splice in the RX audio, I simply paired a 3' audio extension cable to the 3' CAT5 cable I used for the TX audio and PTT circuits.

Prior to committing the build to solder, I set everything up on a breakout board:

As you can see below, my breakout board is a bit small, so I had to use jumpers from the stereo input over to an adjacent space on the board, then to the resistor and cap, etc.

 It all seemed too easy - the PTT switch simply closes a circuit (green and blue wires below), which puts the 897 into TX mode, and then the audio feeds along the blue-white and green-white cables (with the audio jack grounded to the solid blue wire that's part of the PTT circuit), but it worked when I tested it. The PTT, TX and RX audio worked great.

With the circuit designed and prototyped, I laid it all out on a simple breadboard. I spent a couple days modeling the wiring in my head, in an effort to shrink the size of the board (my original goal was to have something small enough that I could heat shrink "inline" to the cables, but the audio cable makes it a bit too large for that). You can see one challenge I overcame in the photo below: the ground from the 3.5mm stereo connector has to pass under the trace from the cap. I put a small bend in the cap's trace, and passed a jumper made from leftover CAT5 wire underneath it.

With everything wired up and tested, I drilled a few small holes for a couple zip ties, tidied everything up, and tested it out - great audio report from my local repeater.

The next step is to either trim the board to the minimal necessary size and heat shrink it, or create some sort of enclosure. For Winter Field Day, I intend to simply cover the bottom with cardboard to prevent accidental shorting, and to make a ton of contacts.

73 and good DX!

Pi vs Arduino vs NodeMCU vs ???

It's official - the Internet of Things has a lot of, um... things. So many options! Consider this: my friend and I are working on a weather station. Of course, it can't just be a simple weather station, it eventually needs to be a cluster of stations that can be used to measure differences in micro-climates. More on that later, LOL.

The initial goal is to put a weather station on a roof, without wires. With so many little devices, the question is simple: which is the right device for the job?

• I started in on this the other day when I started messing around with the GPIO pins on the Pi. In about 10 min, I was reading in temp and barometric pressure data and thought "Dang, that's easy!". The Pi is awfully powerful and, now with the Pi 3, wifi-enabled.
• And then there's NodeMCU. Very cool little wifi-enabled device that can take signal on a variety of analog, digital and serial-dedicated pins. And then it can run Lua to actually form that data into "IoT" capable packages, like HTML pages or JSON packets. Finally, it can be a rudimentary http server, so data can be retrieved (conversely it could be written as a client, to push data directly into the cloud). Seemed to me to be the perfect solution.
• My friend Chuck is a strong advocate for using the Pi with an Arduino on a Pi alamode board. The arduino collects the data, the alamode board pushes that data into the Pi, and the Pi processes it.

My take? I see four viable solutions for getting the data off the Sparkfun weather shield and into "a consuming sink" such as the cloud, a data aggregator like a database, or published to the web.

1. Weathershield to Pi via GPIO interface
2. Weathershield to Pi via Arduino
3. Weathershield to NodeMCU
4. Weathershield to Arduino with WiFi chip

Each solution has advantages and disadvantages, and that's what we're doing to explore now.

Weather Shield to Pi via GPIO

This is an elegant solution - it requires the Weather Shield, some connecting wires, and a Raspberry Pi. It's elegant in that there are few moving parts - wire it up, good to go. Right? Wrong. Not all of the Weather Shield components seem to have Python libraries available, which means the coding would need to be done in C. Not impossible, but not necessarily straightforward.

Acquisition cost: 

• Weather Shield: $39.95 + shipping
• Raspberry Pi 3: $35.95 + shipping
• Misc parts: $5
• Total: $80

Development effort:

• Moderate to high

Weather Shield to Pi via Arduino

This is the easiest solution to build, frankly. The weather shield runs great on the Arduino, all sorts of libraries and sample code abound on the Internet. 

Acquisition cost:

• Weather Shield: $39.95 + shipping
• Raspberry Pi 3: $35.95 + shipping
• Raspberry Pi Alameda: $35.00 + shipping
• Misc parts: $5
• Total: $115 + shipping

Weather Shield to NodeMCU

By far the most elegant solution, holy cow... Suspend disbelief briefly and take a walk with me... You have a weather station on the roof, which feeds data into a Sparkfun weather shield. That shield, in turn, feeds data into a NodeMCU chip - tiny, quarter-size chip with wifi on it. The NodeMCU does three things: 1) it pushes the data to a cloud service, every N minutes; 2) it serves the data up via JSON string to anyone on the local network, and 3) it serves up data via formatted HTML on the local network. Awfully cool, and the cost? Nominal.

What's the issue? Simple - the libraries for the components of the weather shield only exist in part, and it's a process of porting them to Lua to make them work. The other problem: NodeMCU only has a single analog pin, whereas the weather board uses three or four.

--> Caveat: the NodeMCU *can* be programmed via Arduino, using Arduino libraries. I need to look into this more; not sure if there's enough memory to do it, though. And the Arduino environment has convoluted support for outputting HTML. I think I just need an afternoon to figure it out though. But still, the bottom line is it's not the right tool for this job.

Acquisition cost:

• Weather Shield: $39.95 + shipping
• NodeMCU: $15.00 + shipping
• Total: $55 + shipping

Weather Shield to Arduino with Wifi Chip

This solution is honestly just a variant on the above solution - the weather shield speaks to an Arduino (great library support) and the Arduino uses a Wifi chip on a shield to publish the data. 

Slightly more expensive than the standalone NodeMCU solution:

• Weather Shield: $39.95 + shipping
• Arduino Uno $24.95 + shipping
• Ada fruit Huzzah wireless shield: $39.95 plus shipping
• Total: $105 + shipping

Summary

The cheapest possible solution, using the Weather Shield with NodeMCU, is not possible because NodeMCU only has a single analog pin and the weather shield needs multiple. That doesn't mean NodeMCU isn't a useful tool - I have a couple of other projects it might be perfect for. It does mean, however, that it's the wrong tool for this job.

From a financial perspective, the lowest cost solution is the Weather Shield plus the Raspberry Pi. It presents some problems - probably not insurmountable, but there'll be some effort to integrate the Weather Shield natively into Pi via Python or C. The time spent may not be worth the money saved over the alternatives (which both make use of an Arduino to read and interpret results).

So a little research is needed, to see how well the Pi can work with the Weather Shield's components. That's how to solve this specific application, but making a global rule overall? Globally I think it's easy to say that the NodeMCU is a low-cost solution but will almost alway have a steep implementation curve, at least until the dev community matures and catches up with Arduino. Overall from a sheer convenience perspective, the best solution is either 1) Arduino with Pi or 2) Arduino with wireless.

Bottom line: my buddy Chuck is right. When I insisted I take some time to look into building this solution with something other than Arduino, he told me I was wasting my time. I *was* right in that it would be more elegant, but he is right from a practical perspective. Everything is just "there" and ready to use, if Arduino plays a role in the solution.

NodeMCU for the Absolute Beginner - Lessons Learned

About a year ago, a buddy of mine who knew I was really into Raspberry Pi and Arduino encouraged me to look into NodeMCU. It's an IoT hardware platform with an onboard Wifi chip as well as a linux-based OS which is programmable in Lua. I messed around with it long enough to see it connect to the web and download a test page from Adafruit, but honestly? I was starting my own business and absolutely swamped.

Fast forward a year. A long year. A year of almost no hacking - Arduino, Pi, nothing... On a whim, I broke out my Pi and started messing with the GPIO interface and soon had a BMP085 sensor connected to a Python script, writing temp data into a csv file. Pretty cool! Not included to quit while I'm ahead, and finding myself waiting on a couple of clients (and therefore with some 'flexible' time), I decided to break out the NodeMCU. Turns out, someone had gotten the BMP085 working on NodeMCU. After several hours across a couple of days, and running into a steep learning curve, I finally got my BMP085 working on NodeMCU as well!

NodeMCU - This Ain't a Piece of Pi (or Arduino)

OK so you want to jump aboard the IoT craze and get involved. You're familiar with Arduino but you want something lighter, faster, and network enabled. That fancy NodeMCU dev board has been calling you, right?

All in all, it's a nifty idea and it works well (once you get past the learning curve). But if you're coming in from Visual Studio, from Xcode or even from Arduino Studio, be warned: this is not a polished experience. In fact, it's pretty ugly and dirty. Lots of flashing, formatting, serial communications await you before you actually have a working application. It is definitely not for the faint of heart, but if you persist, you'll get there.

Not a Tutorial

This article isn't a tutorial, per say, but a collection of things I picked up over the past few days. Really, there are 3-4 'gotchas' that I'm going to document. There are plenty of tutorials out there, but many of them skip over the 'what the heck do I do now' scenarios. Hopefully I can fill in the gap for you a bit:

• Flashing can be tricky. Use Windows.
• Establish a serial connection as the Node device powers up, so you can see any error messages.
• Debugging is a pain - you need to check for messages as soon as the device boots.

Flashing

I did most of my work on my Raspberry Pi--not really sure why except that it's a throw-away environment where I'm always in screen or minicom, so I wasn't overly concerned about messing things up, and I had all the tools I needed. It might be faster to work elsewhere (I'm running a Pi 3 B+ so it's actually not heinous). There's even a fancy flashing tool (esptool) available for Linux. However... don't do it. I ran into a really weird issue where I saw symptoms like:

• Device showed up online, but worked 'wonky'
• I could program it in Arduino studio with the NodeMCU plug in
• I could not connect to it on Linux over serial comm, unless I tried 115200, but even then things were just weird.

I tried refreshing it with the esptool, which appeared to succeed, but which in the end actually failed.

The answer? Use the Windows flasher tool to flash the build. I spent a good 2 hours one evening digging around trying everything I could think of and finally powered up a Windows machine, flashed it and <poof> everything worked great.

Don't. Seriously, just don't flash it on Linux. Use Windows. It's worth the time you'll save.

Establish Serial Quickly

When the NodeMCU powers up, it very quickly spits some diagnostics to the serial port. It's important that you catch those diagnostics, to be sure you see any messages that might crop up, oh, if your code has a syntax error or such. There is NO INTELLISENSE and NO DEBUGGING on this platform. If you write a mistake, you're not going to catch it any other way besides 1) manual code review or 2) catching the Node as it boots. So be quick on the "screen /dev/ttyUSB0 9600" command, as soon as that device boots.

Debugging

I said it above, but... I created a web page to serve up my inside temp information. I had some syntax errors on the page (not surprising, since I was editing in Leafpad and had some rather convoluted HTML code). I tried three ways from Sunday to get the thing to run. I rebooted it 15 times, but each time I tried to connect, Safari or Android Chrome responded with a connection reset error. I could ping the device (and get responses), but it just wouldn't serve a page.

So then I remembered my point about establishing serial quickly. The next time I powered up, I opened up a serial console ASAP and sure enough - the device spat out some error message about malformed HTML. Fixed it and I was good to go, but I lost a couple hours on this.

Conclusion

I see a lot of great uses for the NodeMCU devices. Remote weather stations no longer need wires. You can put moisture sensors in the far corners of your damp basement. I'm even planning to use one for model rocket telemetry information. It's really a clever device, and the Lua language is rather fun to use. This is going to be a fun device in my arsenal. Keep an eye, by the way, at my other blog securitygeezer.blogspot.comsecuritygeezer.blogspot.com because I have a feeling the NodeMCU device is going to come in handy on penetration tests and such.

Ultimate Telemetry Platform

I have been working for the past 4 years, off and on, on building the ultimate telemetry platform for rockets and balloons. I started originally with a set of stackable Arduino shields - GPS, SD card, etc. Over the years my understanding has grown and the technology has shrunk quite a bit, to the point where I've designed what I think to be the ultimate platform.

Ultimate Telemetry Platform

The ultimate platform consists of:

1. Arduino Mega
2. Mega proto shield
3. Adafruit "Ultimate GPS" breakout
4. Adafruit microSD breakout
5. Adafruit 10 DOF IMU
6. 2m amateur "radio on a chip"
7. 3.3v power supply

I liked the Mega because of the extra size. My vision is that my local Scout troop will start a NOVA team and that the kids will throw additional experiments onto the telemetry platform, and the Mega gives me plenty of pins!

Thanks to my employer, Caliber Security Partners, I was able to stock up on supplies for the project:

Arduino Uno, Mega, and the breakout boards.

My original design focused on ballooning, but I ran into an opportunity to launch the telemetry platform via a rocket. My buddy and amateur radio "Elmer" has a high-power rocket with a payload. Perfect for the Mega!

Here's a shot of the Mega proto shield with the breakout boards:

Mega proto shield with the GPS and IMU. Radio chip and power supply will go in the empty spot on the left.

With the radio chip and power supply, there's not enough acreage for the microSD card, so I put it on the bottom!

This tangle of wires is the 3 sensors on a breadboard, tied to an Uno

Life Is Full of Opportunity

I ran into a number of issues building my platform:

• My buddy had to back out - no motor, his high power license expired, and he's out of time.
• The radio and power supply haven't arrived
• The microSD card draws too much power to use without an external power supply
• ...

So now I have an opportunity! My launch is scheduled for 11/15, and it's 11/11 today. I have to build a solution practically overnight.

Options

Launch Platform

I have an old Estes "Maxi Force" 3-motor cluster rocket that I can launch with. It wasn't made for payloads, so I'm taking a bit of a risk here but at this point I am going to go for it. The nose cone is just exactly wide enough to fit an Arduino Uno:

It's this, or we launch with a kite (and the kite's not all that exciting, especially since we're launching rockets the boys built as part of Space Exploration merit badge).

Telemetry Package

I have a few options on the telemetry side:

• Powered Arduino sd shield, with is big and bulky
• Strip out the GPS and send up the microSD shield and the IMU on an Uno
• Do the same, but use a PC board and solder on a nano

The next few hours will be telling, as I hook the Nano up to the breadboard to see if it can handle everything. I have a number of 3.3v batteries from various cell phones, so I think I can actually use them to power the microSD card. If the nano idea pans out, I just need to find enough power to bring up the Nano and the sensors.

Rocket Repairs

I was hanging on with my Elmer Chuck (WB6YOK) the other day and the conversation turned from radios to radios in balloons. We have been "working on" a balloon project for what, five years now? We started in with Arduino several years ago and, while we haven't launched anything yet, we've got solid plans and a lot of functioning code for various sensors. As we were talking about the balloon project, I mentioned that I am interested in starting a BSA Nova program (BSA's new STEM initiative, to encourage youth to study science, technology, engineering and math). I told him that we are doing space exploration merit badge in Novemeber and mentioned that I would like to launch a rocket at October's Jamboree on the Air campout, to start to generate some interest.

Well, as it always does, the conversation quickly devolved into some wild fantasizing about having a rocket that was large enough to carry the balloon payload, so we could test it. As we were discussing that, Chuck said "Hang on, wait a minute..." and left the room. He returned with an enormous 3-peice rocket (base, payload bay, and nose cone). "This ought to do what you want," he said. Turns out, Chuck is high-powered certified. This is the rocket he certified with--it's powered by a single "H" motor and should go as high as 8,000 feet or more. 

As we talked further, I got more excited about the possibilities. That rocket could carry an Arduino, a Pi with a camera--pretty much anything! Suddenly Chuck left again and returned with this rocket:

An Estes Maxi-Force 3-engine cluster 50" tall rocket. These were a short-lived rocket built by Estes in the early 80's. Chuck said "It's yours if you want to fix the fins." Well, gosh... How difficult could that be? I took it before he could change his mind! 

Two out of three fins needed repair. The first had several cracks lengthwise, and the second had lost its leading edge. Today's project was to swing by Hobby Lobby after my trail run, to grab a few motors and some balsa wood, and then to fix the fins.

These are the cracks on the first fin (above).

And this is the broken leading fin. 

The fins are made of several peices: the main or base fin, a leading fin above it, and some edging which appears to be made of tougher material to withstand the bumps of landing.

My first plan was to just rip all three fins off and replace them with laser cut plastic fins (another buddy has a laser cutter). The more I thought about that, though, the more I realized it was more work than it's worth. As I looked over the fins again, I realized they were totally fixable. I needed to trace one of the leading fins to make a pattern to cut a new one from balsa, and I needed to glue the cracks together on the other. 

So today I dropped by the store and picked up balsa. After a few chores, I started in. First I opened up all the cracks in the fin, as shown below:

Then with a toothpick, I started to slip Gorilla Glue into all of the cracks. It's not as precise as I would like to be, but it worked. Here is the fin, drying, with a little pressure supplied by a couple rubber bands:

Next I traced an intact leading fin, cut some balsa, and dry-fitted a new leading fin. First I had to carve away the remainder of the leading fin--it isn't perfect, the surface of the rocket body was a bit wavy when I finished but the glue will help with that. Balsa is a really forgiving medium, and the dry-fit went quickly.

Knowing that it would be a challenge to have the new leading fin attach at every point and stay aligned, I opted to only glue where it touches the base fin and where it contacts the rocket body nearby. Once it's dried, I will glue up the rest. It's that easy...

I had to laugh--I spent more time thinking up a variety of ways to replace the fins than I actually spent repairing them. In fact, I've spent more time writing up this blog entry! With only an hour's effort, everything is glued except the front of the leading fin.

My next steps are to sand out the excess Gorilla Glue, then using a light putty I will fill in gaps and holes. Once the fins are smooth and straight, I think I'll paint the base again--probably black, just to put my own touch on the rocket.

The Scouts don't know about this rocket, but this is the one we will launch at JOTA, in an effort to pique their interest. I think it'll get their attention!

If I had unlimited time and funds, I would put together a tiny XBee unit, with an XBee 2 transceiver and a GPS. Then I would find a way to slip that into the nose cone so we could stream telemetry while flying the Maxi-Force. But I decided to keep my focus on building a package for the November launch, instead.