I've been working on a project for many years. It started as a grant from the USGS, where we are trying to develop cost-effective sensors to measure the quantity, temperature, and quality of stream runoff over the course of a year. There are existing sensors that do this, but they're either expensive, have limited capability, or both. The grant was intended to foot some of the bill for R&D into a solution that would then allow us to sell them to USGS and other customers. Along with a friend and coleague, we worked on this for a few years. The grant ended a while ago, but that hasn't kept us from continuing to work!
The first version of the device was a TI MSP430-based design that wrote sensor data to an SD card. While this did work, we found that SD cards can be finniky, and consume a surprising amount of power. Ultimately, we couldn't get more than a year of logging on a set of batteries. There probably were opportunities for improvement by refining the amount, and location, of on-board capacitance, but we couldn't get around the limitation of the SD cards. One way or another, someone has to go into the field and either swap-out the loggers, or cards. We always wanted to have a wireless solution, but the technology just wasn't there at the time.
Since then, LoRaWAN came out, and proved itself to be a reliable technology for low-power communication over great distances. I bought a some development systems from Seeed studio (who has the best range of LoRa products, in my opinion) and got to work. Slowly, but surely (I have a different full-time job; this is how I spend my weekends), I developed the skills I needed to understand and work with LoRa. Eventually, it became time to branch out on my own, and have some boards built.
About this time, I read an article that described a promotion that Seeed's Fusion business was running. They are offering PCBs and assembly for 2 prototypes for free if your project is using their LoRa-E5 module! Not coincidentally (did I mention that their range of LoRa products is the best I've found), I was using the LoRa-E5 module in my designs. All I had to do was follow the instructions in the article, upload my design, and provide the coupon code they sent me.
As for the design, there were a few things that I had to keep in mind... My design would be assembled much faster if I used components from their component library, which I was able to do. The other thing is, and I figured this out only after getting my boards, is that you probably should design your boards to be single-side load. That means that all the components that are reflow-soldered are on the same side of the board. In my case, it wasn't a single-side load, and there were some transistors and bias resistors on the back. Seeed didn't complain about this at all, and the assembly charges were still very reasonable. I've had other dual-side load boards made at other CMs, and it increased the price quite a bit.
For reference, this design, including 8 bare PCBs and 2 finished assemblies would have cost $220, but with the coupon code cost $0.01. Even without the coupon that would have been a pretty great deal for short-turnaround prototype assembly.
I should note that the coupon code requires writing about your experience with the Seeed Studio Fusion product. This is that post. That said, it is actually very cool. I'm hoping to have to make a much larger run of these boards in the future, and I'm looking forward to being able to do it so simply and easily.
This February, we planned to visit Park City, Utah to go Skiing. We planned on flying ourselves in our Cirrus SR22. Our plane has a "weeping wing" system using TKS, which gives us some icing protection but isn't certified to fly in known icing. As a result, We have to be pretty risk averse when it comes to the weather, especially in the winter. The system performs amazingly well, but it's only useful for getting out of ice, not getting into it! Because this is one of those "gotta be there" situations, where we have reservations to worry about, we booked two sets of one-way tickets from Portland, OR to Salt Lake City, UT, and back. These tickets were setup so that if we couldn't make the flight Thursday the 18th we had a commercial ticket ass-early on the 19th. The second set of tickets was something like 5 days after the planned return date. My reasoning there was that I'd be willing to just camp out in Park City for several days waiting for a weather window. After 5 days, I would have had just about enough of that and would pack it in and go home. I'd have to fly back sometime later to pickup the plane. Of course, these contingencies would also be useful for mechanical issues.
This was also the first time that I've tried using Flightbridge.com to interact with the FBO and rental car company. It was really cool to land and have the rental car waiting at the FBO. I don't know why exactly, but have a particular disdain for the long-winded discussions at the rental car counter. What could possibly be so important that they can't just hand me the keys and send me on my way? This process avoids all that, I'm a fan.
Flight out: (KCVO-U42) on Feb 18 2022
Starting about two weeks before the planned departure, I checked the weather, every day, as if I was going to fly that day. The goal was to get a feel for what percentage of days would be flyable versus not. The weather in Utah was great, but Corvallis had its typical winter "month of fog". Late in the day, the fog typically burns off enough that you could get out. (A quick word about what I mean by that... Flying Part 91 doesn't require any minimum weather to take off, these are called zero/zero, or zero visibility, zero feet of ceiling, departures. Legal doesn't imply safe, though, and I don't know of anyone that would actually depart in those conditions. My "personal minimums" are the same as for a precision approach, or 3/4 of a mile of visibility and 200' ceilings.)
While it's great that I can get out in the afternoon, the problem is that it's a 4-hour flight, and mountain time is 1-hour earlier. Additionally, the VFR routing around the large Salt Lake City airport hugs the Wasatch mountains east of I-15. My wife refused to fly into the area at night because it feels like you can reach out and touch the mountains along this route (she's very smart). The latest we could depart, therefore, was 1PM.
On the day of the trip, we had thick fog in the morning, as usual, but it was forecast to clear about noon. We had originally planned to depart at about 10:30, so we kinda took it easy in the morning and got to the airport without stressing about it. It was still between 1/4 and 1/2 mile visibility when we got there, but we just loaded up and preflighted like normal. After spending about 45 minutes at the airport, the weather lifted enough for us to depart (10 miles of visibility and 500' ceilings).
This flight was entirely uneventful, even routine. The most interesting part, if anything, was that it was my third time into the Salt Lake area, so I knew they were going to ask me whether I really had to go to South Valley Regional (U42) IFR. I got to feel like a pro and tell them that I could cancel IFR, travel direct to Lagoon (an amusement park, and VFR waypoint) and remain east of I-15. They told me to expect that, cleared me into the Bravo, and I was on my way in.
Once at the airport, the rental car was waiting for us. We were allowed onto the ramp with it, and that made loading our stuff so easy. It should be obvious that Utah in the Winter is cold, and I was worried about how cold the engine would be when we wanted to leave. I asked at the FBO whether they had a way to preheat engines. They said no, but that they could put it in the hangar for a "warm up", which is half the cost of a night in the heated hangar. Ordinarily, the heated hanger is about $120 a night for an SR22. That's a little expensive for a pre-heat, but it was awfully nice to not have to get all the snow off the plane, preflight, and load up in the cold and snow!
Flight back: (U42-KCVO) on Feb 23 2022
I spent a lot more time worrying about the flight back. It's one thing to depart commercial, where you just have to get yourself and your stuff to the airport. It's another to fly yourself, where you have your plane sitting on the ramp weighing on your mind for your whole trip. "Is it covered in snow?" "Has the tail struck the ground?", "Will the FBO remember to bring it in on departure?" "Has it gotten hit by a truck of something?" We had planned to come home on Wed the 23rd, but we technically had lodging arranged through March 3, and commercial tickets March 1st. We were even willing to split up, where Katie and Emma go home on the 1st and I could wait it out longer for a weather window, or for something to be fixed.
Essentially the day we arrived, I started checking forecasts for the return window. I use the WeatherSpork app quite a bit, but its forecasts only go out 3 days. To get a route profile further out in time, I've had pretty good luck with Windy.com. Windy's route profiles aren't very good, but they're something. The IFR route profile only has difference in temperature versus ISA (I still struggle to understand why I would care that much about that), and the VFR route profile only goes to 10,000 feet. What I really want from the IFR profile is icing likelihood and severity.
It appeared fairly early on that I'd have to deal with clouds and ice in the Salt Lake region on Wednesday, it also looked like Thursday would be clear. I started making noises to Katie that we should start thinking about Thursday as our departure day. Eventually, though, Thursday's forecast changed completely. Thursday became a much worse day, with ice forecast along the entire route. Meanwhile, Wednesday's ice forecast started looking increasingly manageable. In particular, there was only "light" ice forecast by Foreflight, which based on my experience really means there's a "chance" of ice. Furthermore, the risk should be over by about Ogden to the north. I felt fairly comfortable with this risk, and we kept our planned Wed. departure time.
Tuesday night we packed up all of our bags, except for the clothes we'd need Wednesday morning. That morning, all we had to do was load up the rental car, check out of the hotel, and make our way to the airport. It bears noting that it was -1℉ outside while loading the car 🥶. I called the FBO again to ask whether they brought my plane in for the "warm up" in the morning. They said they had. I also asked if the had icing fluid (TKS) in a sprayer available, but they didn't. I was hoping to pre-wet my wings with TKS because I was concerned that my warm plane would melt the falling snow, which would then refreeze. This turned out not to be an issue. After loading our bags and preflighting the plane, the line personnel towed us over to the pumps. Their fuel truck had been broken the whole time we were there.
Salt Lake City TRACON are awesome.
This is the third time that flown to this airport, and each time I've tried to depart IFR. Every time, Salt Lake TRACON has audibly sighed and convinced me to depart VFR and get my clearance once I'm a little further away from the major airport. This time, that was not an option.
I tried to contact them on their usual frequency of 127.0, but each time my call went unanswered. It was evident I was going to have a hard time getting out because there was a constant flow of commercial aircraft right above me being flow-controlled into SLC. Eventually, I called the TRACON phone number. The guy who answered said "Yah, this is a really bad time. Can you stay on the line and I'll see when I can work you in?" I said "sure!", then he hung up 😑. I called back and said "I think you accidentally hung up, and he said "no, I meant to." He went on to explain...
"I'm just not sure how I can get you out right now. --long pause-- Well, I guess there's a gap coming up. I'm going to give you a clearance now, but you're held for release. Then I need you to be completely ready to go, and I'll give you a short clearance void time. Ok, Cirrus 5123Y, you're cleared to the Fairfield VOR via the south valley one departure. Climb and maintain 9000 feet. Expect further clearance approaching the Fairfield VOR. Contact departure on some frequency, and squawk some code. Held for release."
I read that back, and waited. I had also completed my run-up by then, and had taxied up to the hold short line. He also asked me what the visibility was, and whether I could see the planes coming in overhead. I had to guess at the visibility, and couldn't see the planes. I could see the outline of the sun, though, so I knew the cloud layer was relatively thin (this is a good thing!). Finally, he said "Cirrus 5123Y, cleared for release, clearance void if not off in 1 minute." I practically yelled into the phone "Taking off now, bye!".
Once in the air, I started flying the South Valley One departure, which is a pretty simple RNAV departure. Basically, you fly directly to a waypoint off the end of the runway, then make a right turn direct to the Fairfield (FFI) VOR. You hold south of the VOR until you reach 9000'. I had just turned south direct to FFI by the time Departure started giving me vectors. They turned me northwest directly over the SLC airport, then eventually cleared me direct to CORIN then "own nav". What was interesting to me is that I was never actually given a route clearance, or even a clearance to Corvallis. So, I just assumed that I was cleared, and I was cleared via my "Expected" route (which was basically what I filed). Maybe someone who understands the nuance of being cleared to a waypoint on a victor airway and "own nav" means can clarify for me 😉.
I was in and out of the clouds from takeoff until about Burley Idaho, and we never ended up getting any ice. The rest of the trip was sunny, but cold. The outside temperature was -15℃, or 5℉. For the whole trip, ATC seems perfectly happy with me continuing to fly to my destination, so I didn't push it. Eventually, when I reached Boise, Idaho, I was vectored off the airway for traffic, and rather than being cleared direct to the Boise VOR BOI, I asked to be cleared direct Wildhorse ILR. Big Sky Approach (which serves the Boise airport) gave me this, but sometime after I checked back in with Salt Lake Center, they asked why I was off course. I told them that Big Sky gave me a short cut, and they were satisfied with that.
Much later, when I was getting close to the Cascade Mountain Range, and the Deschutes VOR DSD, Seattle Center gave me a routing change. I had filed U42 TCH OGD MLD BYI ALKAL BOI ILR DSD KCVO, which was more-or-less what I got, except OGD was replaced by V21. This was no material change in routing, as it's the same path. What Seattle Center wanted me to do was fly V536 instead of DSD KCVO. I thought this was pretty weird, because V536 is just DSD CVO. I ended up asking about it, and she said that I had to fly the airway, because there was terrain in the area. The most cross-track error you could get between CVO (the VOR), and KCVO (the airport) is 900', and that's right above the VOR. I assume that's not the real reason, but that it was technically off-airway, so I would have needed a higher altitude. Either way, it made no difference to me, so I just added CVO in the flight plan before KCVO and went on my merry way.
I was gradually descended into the Willamette valley, which was clear and gorgeous, to an uneventful approach and landing. The Corvallis airport was busy as usual, but I'm used to that. I'm glad I departed when I did, and I learned a lot from the trip. I even called Salt Lake TRACON when I got home to tell them how much I appreciated their help.
In my first post about the HP-97 I started restoring the hardware of the device. In my second post I started reading the cards. In this post, I make sense of those cards, and ultimately write a "disassembler" for them. I have disassembler in quotes here, because it's not a true disassembly. The contents of the program cards aren't exactly machine code, and the instructions as you enter them isn't exactly assembly. It is, however, the closest word to what I'm doing that you might already be familiar with.
Checking off Checking Checksums
I left the last post unable to correctly calculate the checksums on the cards. I shared that post with Teenix, and he added another section to his notes document. Embarrassingly, the problem was staring me straight in the face. If we recall the table I shared:
n0
n1
n2
n3
n4
n5
n6
Notes
2
2
2
0
0
0
4
$1F high
b
0
0
9
f
8
5
$1F low
0
3
8
3
9
b
8
$1E high
5
1
4
e
0
0
0
$1E low
5
3
e
0
8
f
8
$1D high
0
0
0
0
0
0
0
$1D low
.
.
.
.
.
.
.
skipped
0
0
0
0
0
0
0
$10 low
17
9
1c
1a
20
22
19
computed checksum
7
9
c
a
0
2
9
mod 16
7
a
c
b
1
4
b
card checksum
0
1
0
1
1
2
2
abs error
Notice that the error on nibble 1 (n1) is exactly equal to n0/16? The portion that would be truncated is actually carried!! The error of n6 is equal to what would carry from n5. Nibble 5 is missing n4. So on, and so forth.
With that sorted, I was able to correctly verify the checksum on all 46 captured cards.
Making sense of the stored instructions
The next struggle was figuring out exactly how the instructions are stored on the magnetic cards. In this case, I spent quite a bit of time going down the rabbit hole of 6-bit instruction words. This was not for no reason, as the users manual, service manual, and the HP Journal article all discuss the 6-bit words. I simply couldn't get the math to work out; no matter how you try, you can't pack 6-bit words into the 56-bit registers in a clean way! They simply don't divide! Ultimately the epiphany came when I made the modification to the calculator that I threatened in the previous article.
I tack-soldered small wires onto the CRC chip for each of the signals that go to the card reader. Even though the motor still didn't work, I could use these signals to learn a lot more about what's happening. By entering a program into the calculator, then trying to write it to a card, I could see the impact of adding single instructions. It became clear that each instruction added exactly one byte to the card.
Then, I was able to derive more value from the thread in the classic notes document relating to how the 56-bit registers in the calculator's memory are written to the card. The program memory sits in the middle of a 64-word memory bank, flanked by the primary and secondary register files. Each of these are organized into 16-word pages. The register files contain registers 0-9, A-E, and an indirect register I, for a total of 16. And, the program memory goes from memory address 0x10 to 0x2F. Interestingly, instruction zero (first) is at 0x2F, and the program grows "downward".
With this information, it was clear that instructions are simply 1-byte wide, and that 7 of them are packed within a single 56-bit register, and a register is stored as two 28-bit records on the card. Any unused instructions are filled with 0x00, which is a Run/Stop or R/S instruction. You can think of those as No-ops.
Once I figured that out, I started looking for some reference for all the instruction OpCodes, and what instruction they mapped to. I initially started entering simple programs into the calculator, printing them out, saving them to a card (virtually) and writing the opcode numbers in the margin of the tape.
Eventually, while playing around with the Stat-Pac that I scanned, and the version I downloaded from Teenix's website (they were similar, but enigmatically different) I realized that I could just rely on the emulator's depiction of the program; the numbers matched. Essentially, I loaded a few cards into the emulator and compared the register contents to the program steps that the emulator displayed. Clearly there was some notion of this mapping in the emulator, but I don't believe it's open source.
Anyway, I spent a couple hours loading programs and adding instructions that I hadn't figured out yet. Eventually, I was left with quite a few opcodes that didn't have instructions. I certainly didn't expect that 100% of the available opcodes would be valid, but I was sure I was missing some. In part, because my disassembler crashes when it hits an unknown opcode, and there were a few in my stack of cards. Then, I noticed in Appendix E that HP had helpfully listed every possible instruction, what it prints out, and what keys must be pressed to achieve it. I was able to enter the remainder of those into the emulator to get the code for them.
Long story short, I now have a complete notion (that I think is accurate) of all the HP-97 opcodes, what they mean, how they'll print, and what keycodes are necessary to create them in my open source HP-97 program card disassembler.
Ultimately, there are something like 7 opcodes that seem not to be associated with a published instruction. I'm dying of curiosity for what'll happen if I write them to a card! Likely, I'll just get an error, but it'll be fun to see if anything else happens. This must be what fuzzers and crackers feel like all. the. time.
Reading and writing HP-97 emulator card files (hpp format)
It should be clear that I found Teenix's emulator to be highly valuable. And, it was clear that I'd want to be able to directly load my scanned cards into it. That necessitated writing a serde (seralizer/deserializer) for the format. While the classics notes document now has a description of the file format, the emulator is extremely fussy, and it won't accept cards that aren't exactly the same as the ones he produces. Everything down to the precise line terminations for each line must match exactly.
For example, the first two lines: NeWe (magic number) and file size have only carriage returns (no, not linefeeds, like unix endings. just carriage returns). The rest of the lines must be carriage return/linefeed combos (windows line endings). And, the end of the file must have a carriage return and linefeed. Once I learned those tricks, his document is accurate.
Having that out of the way allows me to take a real life Stat-Pac card (or any, of course), load it into my HP-97, capture the output, and run it in the emulator. That's extremely cool!!
Disassembler output examples
Just for fun, here's the command-line output of the program, loading that same area of a circle program:
I even tried to get the printing of the lines just right. There was only one frustration around that, and that was the inverse trigonometric operators. The HP-97's printer has a special character set that includes a superscript -1, which is a single-width character. I simply couldn't figure out a way to achieve that with unicode. So, I had to cheat, and let them take up the column that's normally reserved to have an * to let the labels stand out more. For example, from the diagnostics card:
From now, the next steps are more nebulous. I'm still hoping my lead on new sense amplifier and Rom-0 chips comes through so I can repair my device. If that doesn't happen, though, Teenix is still working on a replacement CPU board. I'll certainly buy one of those regardless of whether I "need" it. Also, I'm strongly considering designing a replacement for the card reader board that's based around a mixed-signal microcontroller. I think there are probably devices that had good analog comparators and motor drivers. I think 2 comparators and a motor driver would be all that's needed besides some basic programmability. This, of course, would be a lot more time consuming to design. At a minimum, it's fun to think about making a copy of the PCB that's mechanically compatible with the existing PCB that would let me have a play with loading and reading cards outside of the calculator.
As I mentioned in my last post, the card reader on my HP-97 isn't working. I was able to power the motor directly, bypassing the bad Sense Amp chip, but the calculator still always went into an error state. With a mind to get to the bottom of the problem, and a hope to preserve the contents of the "Stat-Pac" that was included with my calculator, I instrumented the connection between the Sense Amplifier and the CRC (Card Reader Controller).
Capturing Card data
Essentially, I connected the motor to my lab power supply, and set it for 2.5 volts. Armed the Saleae, triggering it off of the change of state on one of the read heads, and run a card through. I scanned both sides of the roughly 25 cards in the Stat-Pac. Then I saved each of these traces in both Saleae capture files, and CSVs.
This ended up taking about 30 minutes to complete, but I ended up making more work for myself. I should have split each file into a side 1 and side 2 CSV file while I was doing the work to begin with. A quirk about how the data is encoded on the card makes it hard to uniformly process the files when they are run through the reader one-after-another.
Processing low-level signaling
To begin, I split the first card into two separate CSV files, one for each side. Then I began writing a quick rust program to process the transitions (output of Saleae) into bits, then nibbles, then words, and finally attempt to check it against the checksum on the card.
Later, I decided that I should bite bullet and split all the traces up into their side a and b. This took another 30 minutes of mindless clicking, but I think it was well worth it. I discovered that two scans had missing bits, likely due to missed phase inversions. It's unclear whether these are real issues on the card, or if they are spurious.
The link to the rust program above is to the repository that contains the rust program source, and all of my card scans, if you'd like to follow along.
Throughout this process, a guy that goes by Teenix has been providing invaluable assistance, both in his website, and messages on the HP Museum. His Classic Notes document is not only the best resource for understanding the low-level signaling on the card, but also the meaning of that signaling. Another fantastic resource is the May 1974 edition of the HP Journal. It's focused on the HP-65, but much of it still applies..
The image above is an example of a captured card header. The data is written via flux inversions on track A and B (RA and RB are "Read A" and "Read B" respectively). A flux inversion on track A is a 1 bit, and an inversion on track B is a 0 bit. The data is sent LSB first, and big endian. In this case, these signals correspond to a header that says "Fixed point representation, with two digits after the decimal, degrees, flag 4 is set, and program card 1. There is one nibble that seems to have undefined meaning in this trace; and that's number 5 (zero indexed). Teenix's document suggests that it should be either 1 for a 1-card program, or 2 for a 2-card program. In this case it's set to zero. All of my cards have this set to zero, and I've very curious why...
Checking out checking the checksum
Now that I have the low-level signaling of the card data working well enough, it's time to look into the checksum. Ideally, I'd be able to use the simple algorithm from Teenix's document and verify all my my captures, but it didn't work out that way.
My ST-12b
Teenix ST-12b
Teenix OpCode
Teenix dissassembly
2220104
2220004
STATUS
FIX2, DEG, No Flags, Prog side 2
b009f85
b009f85
03839b8
03839b8
514e000
514e000
53e08f8
53e08f8
skipped
skipped
skipped
skipped
7acb24b
7acb14b
checksum
There are several things to note in the table above. First, I've listed the contents I've scanned from my own copy of the ST-12b card. This card is a little special in that it's a a very short program card. So, it's a lot easier to look at it bit-by-bit, and nibble-by-nibble. First of all, you should be able to see that my copy and Teenix's copy are almost exactly the same. The only difference is in nibble 4 of the status word. My copy has flag 4 set, and Teenix's doesn't; this is also reflected in bit 4 of the checksum.
I had intended to also disassemble the program data on the card into opcodes and the program listing, but that part of the process is still a mystery to me. I'll probably make another post when I've got that figured out. For now, I'll leave the table columns in place.
This is a very encouraging result, because it does validate that the majority of my data processing pipeline works perfectly. Also, in this case, I have a failure to compute the correct checksum in my rust program. Therefore, this is a perfect case to use to start digging into my failed assumptions about how the checksum is computed.
Teenix's Classic Notes document has this to say about the checksum:
The checksum is the sum of the STATUS and program nibbles
And gives the following example:
Word
Meaning
2220013
STATUS
1111111
Reg $2F high
1111111
Reg $2F low
0000000
remaining
0000000
registers
...
...
4442235
checksum
This implies that each nibble position in the checksum is the simple sum (mod-16) of every nibble above it in that column (including status). Unfortunately, because none of the nibbles in this example overflow we have to just assume that it's mod-16 (discarding all but the least-significant nibble of the sum).
Again, using the Teenix ST-12b example, we can perform that operation by hand (all operations in hex)
n0
n1
n2
n3
n4
n5
n6
Notes
2
2
2
0
0
0
4
$1F high
b
0
0
9
f
8
5
$1F low
0
3
8
3
9
b
8
$1E high
5
1
4
e
0
0
0
$1E low
5
3
e
0
8
f
8
$1D high
0
0
0
0
0
0
0
$1D low
.
.
.
.
.
.
.
skipped
0
0
0
0
0
0
0
$10 low
17
9
1c
1a
20
22
19
computed checksum
7
9
c
a
0
2
9
mod 16
7
a
c
b
1
4
b
card checksum
0
1
0
1
1
2
2
abs error
The table above demonstrates the problem when computing the checksum with this method. Frustratingly, the errors are small in magnitude, but exist on most of the nibbles. Furthermore, the errors don't seem to be related to whether or not it overflows. Nibble zero is correct, even though it overflows, nibble 1 is wrong and doesn't, and nibble 2 is correct and doesn't overflow. Also, the card checksums are always higher-valued than the computed checksum! It's almost like there are some values that aren't being included in the summation.
Next steps
Anyway, that's where I'm at now. I'm going to try and get some feedback from Teenix and the community. I'm at the point where I'm considering soldering semi-permanent wires onto the CRC chip so I can try capturing the same card multiple times and seeing if they're different and by how much.
My wife's grandfather was a professor of agronomy at Oregon State University. He was a brilliant man, but a bit of a luddite. Because of that, I was rather surprised when I found an HP97 in his things after his passing. It was in apparently pristine condition, and still in its box, so perhaps he didn't get much use out of it. Along with the calculator, he had purchased the statistics pac, so I'm guessing that's what he had in mind for it.
Somewhat after getting it, I decided to take it for a spin. I don't remember whether the display looked right, but I do remember that the card reader didn't work. Shortly after that time, we moved, and it spent about 2 years in storage. Lately, I've been watching a lot of Curious Marc on YouTube, which has inspired me to pull it out, and get to work fixing it.
I found the HP Museum; a treasure trove of information about these old HP devices. Though that site, I found the Teenix's website which has even more great information. I set about formulating a plan for getting the calculator back to full functionality.
Battery replacement
The HP97 is a desktop calculator, and is weirdly designed around a rechargeable battery. It has an AC wall-adapter (simple transformer), but it can't really run off the transformer alone. Of course, as the calculator was built in 1976, the batteries are long-since shot.
I didn't want to bother with replacing the cells and reassembling them into a pack just yet, so I figured out a way to make the calculator 5v DC powered. This was pretty simple, because the battery contacts just attach to pins on the PCB. The pins are pretty big, but crimped 0.1" headers fit over them just fine. The image below is where the battery connections attach.
I simply took a spare 5v 2a power supply, crimped some new ends on it, and fed them through the hole in the lock (pre-Kensington).
Printer repair
The next issue was the print rollers. The printer on the HP97 uses some kind of rubber pinch rollers to grab and pull the paper from the roll. Over time, this rubber hardens, and as it does becomes quite smooth. The smooth rubber doesn't have much grip on the paper. Also, the constant pressure of the other pinch rollers on the rubber cause a flat spot to appear on the rubber. Some people take the rubber off of these rollers and replace it with silicone. Others sand it with 1000 grit sand paper to roughen the surface and sand below the flat spot. I elected the latter solution, and it worked perfectly.
There is a trick, by the way, to removing the print head ribbon. The connectors for the HP ribbon cables have metal fingers that are designed for one-way operation. They'll grab the ribbon quite tightly, unless something is inserted (ideally smooth and relatively hard) to allow the ribbon to be removed, the cables will be destroyed. I used cutouts from a spinach container from the grocery store.
With that, I had a functional printer. I was worried about the print output being quite dark, but it turns out that thermal paper degrades, and 40 years of sitting around caused it to stop working well. A quick trip to staples was all that was required to get fresh paper.
Card Reader
The next issue was the card reader. I mentioned earlier that it didn't work, and the reason is well known in the vintage HP community. The rubber they used on the pinch roller that draws the card through the slot degrades. This was the case with mine as well. Again, there are many ways to repair these rollers, I chose the "o-ring method", which is simply taking 2 5/16" O-rings and putting them on the gear/shaft assembly. Mine needed to be sanded down a little to roll freely.
Unfortunately, that didn't totally solve the problem for my HP97. I noticed that the motor simply didn't often start turning when a card was inserted. The signals to/from the read/write head were perfect, as were the flags from the card detect sensors. It was simply that the motor didn't start. Ultimately, I determined that the sense amplifier chip on the card reader board had probably failed in the motor driver section. I'm hoping that I can find someone that's willing to part with one, as this is most certainly not an IC that you can just buy from DigiKey.
So, until I can find a sense amp, I'm kinda stuck. There's one thing that has me a little concerned, which is that, even when I power the motor from 2.5v from my lab power supply, I still get errors reading cards. It does appear that I can write cards successfully, though. I'm hoping that this problem is more related to motor speed, and is something that I can get dialed-in.
LED Display
In the image above, regarding the printer, you may have noticed that the top-left segment of the 7-segment display is lit on every digit. It's not supposed to be like that 😆. What's happening there, which I discovered after some experimentation, is that the ROM-0 output driver for that segment (segment F for those following along) has failed. I suspect that the transistor responsible for pulling it to ground has failed open-circuit.
In the oscilloscope trace above, notice that the lowest that the output for segment F out of ROM-0 never goes all the way to zero. It overs around 2.5v until it's pulled high for the output 0.00. This is another situation where I'm stuck until I can find a replacement IC.
For the curious among you, the above is an image of ROM Zero. All the ROMs in this calculator are very weird. This one converts bus signals to the 7-segment display signals. Normal companies would, one assumes, use a standard 7-segment display driver, but not HP...
Next steps
This catches us up to now. But I have plans, still, for this calculator. I'm hoping I can find a source for the ROM-0 and Sense amplifier chips. Failing that, I'm considering designing a replacement for the card reader. One option on the table is using a microcontroller that can read and write to the magnetic heads and replaces the Sense Amplifier chip and associated PCB. Another is to discard the card reading completely, and replace it with an esp32 (or similar) and allow for the emulation of magnetic cards. For the display, I don't have as many options, but Teenix has been developing a drop-in replacement CPU board for the HP97. This would obviate the need for ROM-0.
Thanks for reading along. I'm hoping that I'll be better about posting blog posts, now that I have my gitlab deployment system setup better. In the past, I had to download the artifacts from gitlab, sftp into the web server, ssh in and move the files all around. It doesn't sound like much, but it was enough for me to not bother... I think I've got it to a place where I can just click a button now.
The early months of 2020 have been a uniquely hellish time. Between the rapidly increasing incidence of COVID cases, varying levels of social distancing, closing of schools, and economic contraction, we've all been trying to find ways to improve the situation for ourselves and others. For some, that has meant sewing masks, for others it has meant designing invasive ventilators (yikes).
As engineers and hackers, a common first instinct in response to a crisis or discovering someone in need is to try to engineer around the problem. In these cases, however, it's important to understand the true needs of the people you're looking to help, rather than your assumption about their needs.
Several years ago, my partner was peripherally involved in the process of Oregon State University starting a Center for Civic Engagement, a group with a charge that included coordinating community groups that needed resources with groups within OSU that may have them. During this process, we talked quite a bit at home about the dynamics of engineering groups designing exactly the wrong solution to a problem. Many of the efforts of people designing invasive ventilators are perfect examples. The person that used a windshield wiper motor to squeeze a bag comes to mind. Such a machine would almost certainly destroy the lungs of a patient in no time.
As engineers, it is imperative that we listen first, develop requirements from the user second, design a solution, then solicit feedback. Armed with the feedback from the user, go back to step two and start over.
Batteries
During the course of this project, I was contacted by a friend of mine, who runs the emergency department at a hospital here in Oregon. He had been tracking COVID for a while, and strategizing about how best to respond. His hospital was in possession of several devices called Powered Air Purifying Respirators, or PAPR, and he rightly concluded that they would be a good way to protect himself and his staff while they deal with the projected influx of COVID patients. The problem, however, was that the non rechargeable battery packs were in very short supply. He sent me an image of the battery and asked if I knew anything about the battery chemistry and whether it would be possible to charge them anyway.
Ultimately, they are not rechargeable. Furthermore, the 3M batteries last 12 hours, and he was only able to find 12 batteries to buy on the open market. This is, of course 144 hours of total run time, or 24 hours of runtime per PAPR (they have 6). This would provide some protection, but it's clearly inadequate for a longterm crisis. Cool, so I had my first concrete way I could help out, and feel some control over this crazy situation. Let's circle back on our process: I listened for the need, PAPR batteries; now I need the requirements. In this case the requirements are:
Readily available
Many hour runtime
Must provide at least as much airflow (CFM) as original
Must be convenient and rugged.
The first design that I prototyped was easily rejected. This design was simply a mechanical adapter that interfaced with the custom connector on the 3M PAPR battery and blower, and a cable that had a Deans connector, common in radio control models. The choice of Deans connector was to leverage the ubiquitous, powerful, and cheap batteries used in R/C models. The places this design fell down were in points 3 and 4. Firstly, the original 3M battery is 6 volts. This is an awkward voltage for LiPo batteries, as it falls between 1 and 2 batteries in series. Secondly, it's not convenient to put the battery in a pocket, then have a cable to another cable. Finally, the cables could easily be disconnected.
The second design is much better; I printed and assembled six of them. This design completely encloses the battery and electronics, and utilizes an off-the-shelf voltage regulator. I elected to use what's called a Battery Eliminator Circuit (or BEC) to regulate the voltage because it's completely contained, well made, readily available, and is less likely to fail than hand assembled circuits. Where this design falls down, though, is in point 4, and slightly point 2. The battery case has a belt clip for mounting on the web straps of the PAPR blower, but it's a little soft, and the nurses have dropped a few. When the case is dropped it can break. With point 2, the BEC may be a simple linear regulator, and therefore wastes more energy in converting the battery voltage. Castle Creations doesn't provide a definitive answer on this, so it's an assumption. Finally, the lowest voltage you can set the BEC to is 4.8 volts, which is higher than required for our design, so it's providing more than the needed power, and this reduces runtime.
Further feedback has suggested a few more changes for the battery pack, that have yet to have been implemented. One is to make the belt clip smaller, and stronger, to reduce the likelihood of a fall. A second is to add a battery monitor alarm. They over discharged one battery because they didn't pay attention to it. There are commodity buzzers that can be easily added to the batteries. Finally, the pins that connect to the PAPR blower can be pushed out if the cable isn't installed carefully. For that, I think the pins will have to be glued into place.
Shortly after contacting me about the batteries, a need for filters also became apparent. To begin with, the PAPRs that the hospital had on hand were chemical filters, not necessarily HEPA. Second, it is impossible to buy new HEPA filters for the PAPRs in this current environment. I was asked, therefore, to come up with a solution to use vacuum filters with the PAPRs. Like the batteries, we can come up with a simple set of requirements:
Readily available
Instils confidence (no tape)
Rugged
Must be HEPA, and resistant to droplets and aerosols
The first things I started considering was whether, and how to, enclose the filter. Originally, I had thought to fully enclose the filter in plastic, and close the sides with essentially gaffer's tape. I mentioned this to the MD and he was concerned that it would appear rickety, and wouldn't instill confidence among the team. Ultimately I figured out that the filter media doesn't need to be enclosed.
Next, I had to find a filter that would be close to the right size and shape. All of this effort would be completely wasted
if the filters it's designed around are hard to find and buy. Also, there's a lot of questionable marketing around HEPA. Unfortunately, HEPA is now a generic term, and it appears that no certification body is able to prevent non-tested nor certified products from using the term on their packaging. I did find a small Milwaukee filter that has a "Certified HEPA" logo. It's very difficult to trace the certification, but as the filter is first party, and name brand, it's among the most trustworthy filters I could find. The filter has a simple mounting scheme, and has only one penetration on the "clean" side of the filter, making it a perfect candidate. I already knew the screw thread size for the original filter canisters, so I developed a cap over the HEPA filter, and adapted it to the cap. It all looked good in CAD...
Unfortunately, because I threw it together without having a PAPR to work with (I had ordered a military surplus one on eBay, but it hadn't arrived yet) it didn't fit at all. Once my PAPR came in the mail, I measured it and modeled it in CAD and designed another version. Because the diameter of the filter was much larger than that of the filter canisters that the PAPR is designed for, I had to make the adapter quite long to allow the filter to hang over the side of the case.
The second attempt fit perfectly, and I started printing them on my Prusa i3 clone. The problem I faced now, however, was that it was taking 26-or-so hours to print them. Not only do I not trust leaving my printer over night, but the room I use as my lab is where my cats are kept at night, and I trust them even less than the printer! To deal with some of these problems (remembering that I need 6-7 of these filter adapters, just for one hospital), I asked around for people that might have printer cycles that I could borrow. Fortunately, an engineer at the company I work for is an alum of HP Vancouver (Washington state), and was able to put me in touch with their 3D printing team!
HP is running a very cool program that connects designs and prototype services with medical facilities that need extra support. While I didn't get connected with this team exactly, I do want to give them a major shout out, and thank them for doing this. The team I was put in contact with was the printing R&D group that works on a powered plastic process based on PA-12 (a type of Nylon). Their printer was able to print 6 filter adapters at once, and a single batch takes about 18 hours, regardless of how many parts are contained within.
That's all very cool, but now we're changing the process used to make parts, so the assumptions I made while designing the second draft are no longer valid. In particular, FDM printers can enclose any volume with little added mass (this is a tunable parameter called infill). However, the process used in the HP printers is more like stereo lithography (I'm not sure about the details of their process; whether they sinter the substrate with a laser, or bind it with resin, but the effect is the same), wherein any enclosed volume will be filled with the substrate, and become rather heavy. So, an engineer at HP and I went through a few rounds of design review and came up with a cool looking design that met the required criteria above, while also minimizing the mass of the part.
The design we ultimately printed has a large adapter diameter to enclose the end of the filter, and mate with the bayonet features on the filter. Then a long tube with a 2-3 mm wall thickness connects the filter internal cavity to the PAPR blower. A cool wheel feature in the middle of the adapter is meant to provide support to the filter, and meet a matching feature on the PAPR body. The role of that feature is to try to prevent the part from breaking if the filter is hit with a wall, door, bed, or medical equipment.
Once the parts came in from HP (and it only took about a week), I couldn't wait to give the system a test. In the above image, I'm testing the full system with a CFM meter that's provided with the PAPR. In this test, the battery is a 2200mAh R/C airplane battery, in the battery case with the voltage regulator. The HP-printed filter adapter and a cloth "sock" that my wife sewed to provide some additional protection to liquid droplets is supporting the PAPR blower. On the output of the PAPR is a 3M CFM meter that they provide in the kit. It maxes out at 6CFM, and this system surpasses that flow rate easily.
At the hospital
The team at the hospital has been using the kit for a few weeks now, and their impression has been positive overall. Discounting the broken battery covers, there haven't been any complaints. In fact, the filter performance has been so good that they're able to get a few more hours of runtime out of the 3M batteries with an acceptable flow rate.
Thanks and acknowledgements
I want to thank my Doctor friend for giving me the opportunity to help out, and provide a sense of control in the completely out of control time. Also, I want to sincerely thank the folks at HP who were able to act so quickly (about a week from first email to parts in the mail!) in helping out. I want to thank Tabor Kelly for making the introductions. Finally, I want to thank you for reading!
Design files and disclaimer
I've provided a public link to the design files in Autodesk Fusion 360. You're free to download them, and use them as you see fit. However, I'm explicitly disclaiming any responsibility for any damages that may arise from the use of these files, and I make no warranty regarding their use or applicability for any purpose.
At this point in the journey, we're all getting tired... Tired of hotels, tired of eating out, just plain tired.
Whitehorse to Prince George (CYXY-CYXS)
After arriving from our long, cold, and challenging flight to Whitehorse, we paid special attention to the global icing model. In particular, I trusted it more than I had in the past. In this case, the model had forecast greater icing risk in the afternoon. I suspected that the weather was going to be substantially similar to what it had been the day before. That is, icing caused by towering cumulonimbus clouds. These would bloom later in the day as the sun caused convection by heating the ground. This would provide the "push" that these clouds need to begin forming.
Originally, we had planned to visit the Yukon Wildlife Preserve in the morning before departing, but due to the afternoon weather, and that the hotel in Prince George had a water park, we decided to get flying first thing in the morning. We ate breakfast, and arranged for a taxi to the airport at 9:15. At the airport, I looked for someone to sell me TKS (anti-icing fluid), but no one was able to. From our flight the prior day, I wasn't sure how much we had left, and with the risk of ice that day, it would have been nice to take off with a full tank. Alas, it wasn't in the cards.
Our flight plan for the day was pretty simple. We took V328 to YXJ (Fort St. John), then V308 to Prince George. The route was a little circuitous, but it was the safest given weather, terrain, and oxygen availability. Ultimately, though, Vancouver Center gave us a shortcut that helped out quite a bit.
While there was forecast icing risk, we never ended up getting any. This is likely because we were much more aggressive about asking for, and deviating around cells. It was cloudy and a little rainy upon arriving at Prince George, and this was actually the only rain we had the entire trip!
When we got to the hotel, we ate right away and immediately jumped in the pool! The water park was a huge hit, and it was nice to have some time to relax and just play around.
Price George to Moses Lake (CXYS-KMWH)
While we were on the ground at Price George, both the night we landed and in the morning, I called every phone number I could find and asked about TKS fluid. Again, there was none available.
The forecast again had icing risk... (Notice a theme?) This time, the ice seemed to be predominately over the cascade range in Southern British Columbia. Originally, we had planned on flying to Seattle, and clearing customs at Boeing Field. I wasn't comfortable with that route any more, and decided it would be much better to remain on the East side of the cascades and clear customs at Moses Lake. I even worked pretty hard during my selection of airways to remain as low as possible. This seems to seldom work for me, and before we knew it we were flying at 11,000'.
It was apparent that we were returning to civilization, because I could almost maintain contact with ATC the entire trip, and we were on radar! The exception that really stood out, though, was when we crossed into the US. Vancouver Center handed us off right before the border, and I couldn't get Seattle Center at all. I kept trying to get them, and even with the squelch open, I got nothing. Eventually I got so frustrated that I finally pressed the ident button. Surprisingly, they called me immediately after, and they couldn't hear me respond. So, they asked an airliner to relay for me. Through the airliner, they asked me if I could climb to 13,000. I said "fine, but you've got a half-hour". For the uninitiated, law prohibits a pilot from flying between 12,500' to 14,000' without supplimental oxygen for more than a half-hour. Katie, keenly aware of this, started a timer the moment we crossed 12,500'. Once at 13,000' we were able to talk to Seattle Center, and coordinate our arrival into Moses Lake.
One thing interesting about our approach into Moses Lake is that we were racing a Boeing 737 (with a Boeing callsign, so not an airliner) to the airport. The 737 wanted to do a practice approach (low approach only), and was trying to convince Moses Lake tower to relax about it because there wouldn't be a runway conflict. The tower's rules about cross-direction traffic were strict, though, and I had to be off the runway before the 737 was on short final. One thing I love about the Cirrus is that you can keep the power on in the descent and pretty easily maintain 170KIAS. This is within the low-speed range of the 737, and so tower could basically tell us both to maintain 170. Other than this, our approach and landing at Moses Lake was routine.
Customs
I got a progressive taxi to the Customs parking box, and was greeted by a line service tech from Columbia Pacific Aviation. After briefly chatting with the CBP Officer, he got us all fueled up and the windows cleaned. The service from them was awesome.
Our customs experience at Moses Lake almost couldn't be more different than that of Ketchikan. First of all, I have to get a major mea culpa out of the way... I did not file my eAPIS before taking off! 😲 Fifteen minutes after taking off from Prince George, I literally slapped my forehead and said "Shit, I forgot to file the eAPIS!" Luckily, I still had cellular service at the time and was able to file it really quickly. I was able to get the confirmation email just before losing service. What I didn't notice, of course, was that there was a phone number I was supposed to call prior to landing. This is because there's only one CBP agent at Moses Lake, and if he had a Doctor's appointment I'd be out of luck. He ribbed me about this a little, but let it go. Once in his office, and going through the paperwork (Passports, Aircraft registration, Pilot's license and medical) he said "This passport is invalid". If you'll remember, I had paid a fair amount of money for a rushed passport, and of course I said "What!? This is a brand-new passport!" He chuckled and read "This passport is invalid unless signed by the owner." Then handed me a pen.
Once paying the Moses Lake user fee ($20), we were free to leave. We went to the small cafe in the Moses Lake airport to get some lunch, and it was ok, and we were on our way.
Moses Lake to Corvallis (KMWH-KCVO)
OUR LAST LEG!
Finally we're on the last leg of our epic adventure. The Moses Lake to Corvallis leg is very similar to another I've completed recently, from Wenatchee to Corvallis. It's a simple route south to the Columbia River Gorge, along the gorge to Portland, then south to Corvallis.
I filed a route that would have put me through Mount Adams (oops), but ATC helpfully offered me the option of deviating or climbing. I asked whether I could proceed direct Corvallis, which would have had me "thread the needle" between Mount Adams and Mount Hood.
I was surprised that they accepted the offer! and I headed directly home! Unfortunately, the next handoff was to Portland Approach, and they were a hard pass on that whole plan. The reason I was surprised to get it was because that would have put me right in the middle of the westerly flow into Portland International. They cleared me direct BTG (Battleground, WA).
Once I was far enough west that I wasn't in their flow anymore, they did end up clearing me direct CVO, and allowed me to begin my descent. When I got handed off to Cascade Approach (from Seattle), I canceled IFR and began setting up for the downwind on runway 35 at Corvallis. It was great to be home.
What an adventure!
Emma decided to tell the plane "Thanks for the trip, you did a great job keeping us safe."
I don't really feel like writing this post, to be honest. This was one of my least-fun flights that I can remember.
We woke up in Talkeetna and finished packing up. We weren't in a huge hurry to get going. This day was going to be only flying. So, we walked to The Roadhouse for breakfast, then back to the airport. I walked ahead, because Emma is a slow walker, and I wanted to visit the Flight Service Station (FSS) at Talkeetna. Flight Service Stations are just about extinct in the lower 48, so I was excited about getting an opportunity to get a real in-person briefing. It was really fun to look at all the forecast products with someone. My primary concern for today's fight was Icing.
My usual tools for evaluating icing risk (the US Icing model and Skew-T/Log-P plots) weren't available for this flight, though the global icing model was. The global model, and the ForeFlight briefing were forecasting ice, but the briefer at the FSS wasn't convinced. He more-or-less dismissed the concerns, saying that there were no AIRMETS, SEGMETS, or remarks regarding icing along the route.
We filed our intent to depart with US CBP, and Canada Border Protection, and filed our IFR flight plan.
After filling up the plane and departing, we headed east. I got Anchorage Center on the radio and tried to open my flight plan. They weren't able to find it, but opened a new one for me anyway.
By the time we reached the Talkeetna Mountains east of town, we were getting into the clouds. Within the next fifteen minutes, or so, we did start picking up trace ice. It was pretty intermittent, and seemingly only in the clouds that had vertical development. We started working to avoid these clouds by deviating left and right. Once we were past the Talkeetna Mountains, the unstable air didn't have the forcing action of the mountains and the clouds settled down. This gave us some time to take stock of things and think about our strategy for the remainder of the flight.
At this point in the journey, we were in a bit of a bowl, and mostly on our own. Anchorage Center was technically responsible for us, but we didn't have radar service or communications. Eventually we did make contact at a reporting point just prior to the border, and were given the instruction "Maintain one-two-thousand while in controlled airspace, contact Edmonton Center one-hundred miles prior to whitehorse". This was a mostly-formal "you're on your own for almost two hours, good luck".
I was a little unfamiliar with how much latitude I had to change altitudes and deviate with such an instruction. We were still hitting some clouds with ice in them, and I was getting worried about how much TKS was left. We were shedding the ice at an OK rate, and we weren't accumulating anything more than a few millimeters on the leading edges. But, this was way more than I was comfortable with. So, I just started deviating anyway.
Eventually, and much closer than 100nm from Whitehorse, I was finally able to get Edmonton Center on the radio. I told them I had deviated left of corse, and that I could accept a vector whenever they wanted. I don't remember the exact response, but it was essentially "We don't have radar where you are, so you can proceed direct Whitehorse whenever you want"
Again, we were in a position where the clouds were behind us, and we had an easy shot to our destination. After a bit of decompressing, Katie and I talked about our experience. I confided that I was stressed about what had happened, and that I was remaining calm to not give her the impression that things weren't going great. She said "that's good, because I was afraid, and I was calm because you were calm." The whole time, though, she was watching for ice build-up, helping me spot bad clouds, helping me decide whether left or right would be a better choice. Katie was a hell of a co-pilot. I feel incredibly lucky to have a wife that not only likes to go on these flying trips, but is able to take the bad with the good, rise to the occasion, and kick ass.
Shortly thereafter, Edmonton Center asked me if I had an approach request at Whitehorse. I said that I could accept the visual. They replied that "altitude is now pilots discretion, contact Whitehorse tower when desired." We ended up descending into a valley and flying that to Whitehorse. I was cleared to land abeam the tower, and pulled off a smooth landing, even though the winds were 4, gusting to 19.
Our only concrete plan for Talkeetna was to get an arial tour of Denali from K2 aviation. We had heard that Talkeetna was kind of boring, and that we should spend the minimum amount of time there. This was not our experience. In some ways, Talkeetna was my favorite town. It had a funky Austin, TX kind of vibe. There were plenty of pride flags flying, a clear environmental conscientiousness, and lots of cool, very yummy, restaurants.
As it happens, our time in Talkeetna had a very strange Man V. Food connection with us. On Thursday, after our K2 flight, we went to the West Rib for lunch, and noticed there was a film crew working. We went in anyway, and a production assistant asked us if we'd be willing to be on the show. We agreed, and had a 10 minute interview with Casey Webb. The episode will probably air in late Fall. The next morning, we were eating at The Roadhouse and I noticed that Katie was sitting in the seat that the original Man v Food host, Adam Richman, sat in during a 2009 episode.
We also ate at the Wildflower Cafe, Denali Brewing, and a small food truck selling fireweed ice cream, Emma's new favorite flavor.
In addition to all the interesting and fun man-made stuff in Talkeetna, the natural beauty is abundant. There are trails everywhere that let you explore. Be a little careful, though, it can be hard to tell when you start venturing onto private property. Our final full day here we mostly spent exploring and made our was across the rail bridge to a small beach on the river and let Emma play and splash around while we dug our toes into the sand and glacial silt. This was also the only place on our trip that we experienced the legendary mosquitos we were warned about, Katie didn't notice at the time, but later that night discovered at least dozen very itchy bites.
K2 Aviation
K2 has a stable of De Havilland aircraft. They use mostly Otters, but also one Beaver, and one Piper Navajo. These tours can be either the south-side of the mountain, around the mountain, or flying up to the summit. All-but the summit flight have a glacier landing option. The summit flight is in the Navajo, because pressurization is required. We elected for the Grand tour, which goes around the mountain, with a landing.
Of over 400 hours in small planes, this was probably the most amazing hour I've ever experienced.
There's really only one real IFR route between Juneau and Talkeetna for a plane without a turbo and oxygen. The route takes you to Sister IslandSSR, intercepts T269 at HAPIT, then keeps going all the way to Anchorage TED. Once at anchorage, just turn north to Talkeetna. In my plane, it's about a 4 hour flight.
We did the entire flight at 10,000'. When we initially flew out to the ocean, the HAPIT waypoint is a fair bit away from the shore, so I asked for an early turn direct to YAK. ATC cleared me for this, but then turned us a little to keep us far enough away from Mt. Fairweather.
The geology in this region is much more interesting that we had seen so far. The mountains are just starting to get pretty huge. In the distance, I saw a huge peak, and thought "woah, can we see Denali already!?" Turns out, no. I hadn't known that there was another enormous mountain that's only 800' shorter than Denali: Mt. Logan.
Another amazing thing to be able to see were the various stages of glacial geology. All glaciers start as Cirques, which are the bowls which collect snow over the ages, compressing it into glacial ice. Eventually, these fill up enough that the ice flows into a valley glacier. We got to see many amazing examples of glaciers in every stage of their formation and life-cycle.
A glacial terminus can be either on land, or on water. We got to see great examples of both. In this case, the glacier is terminating at sea, and the ice is breaking off to become icebergs.
In other cases, the glacier melts while still on land, and produces these silt flats that lead to beautiful waterscapes
Finally, over even more time, these silt flats become beautiful lush landscapes
The only real complication during the flight was the handoff from Anchorage Center's 119.0 frequency to 119.3. I was told to contact them on 119.3, and if I couldn't make contact in ten minutes. This was at 14:51. At 15:11 I tried again. And again. And again. It ended up being almost an hour before I could finally get them on the radio. In that time, I did have luck relaying messages to them via airliners and freighters above me, so I wasn't overly concerned. But, I was conscious that if I couldn't re-establish communication by Cordoba, AK, then I'd probably be required to land. It's a little bit of a grey-area to me whether I was actually having a communications "problem" that would have required squawking 7600 and doing the communications failure stuff. Another irony is that I didn't have radar service, so no one would see me squawking anyway!
In my 
