Your leaking thatched hut during the restoration of a pre-Enlightenment state.


Hello, my name is Judas Gutenberg and this is my blaag (pronounced as you would the vomit noise "hyroop-bleuach").


decay & ruin
Biosphere II
dead malls
Irving housing

got that wrong

appropriate tech
Arduino μcontrollers
Backwoods Home
Fractal antenna

fun social media stuff

(nobody does!)

Like my brownhouse:
   rediscovering the high cliffs
Sunday, April 14 2024

location: 940 feet west of Woodworth Lake, Fulton County, NY

After drinking my usual coffee, playing my usual Spelling Bee, and feeding the dogs, I returned to my remote control project. I wanted to confirm that it was all working reliably before moving on to other things. So I opened up a web browser pointed directly at the web page being served by the ESP8266 itself (that is, what I've been calling local control) as well as another web browser pointed at the server (the more traditional non-local form of control). I then changed the state of various pins to see how the information propagated through the system. When changing it on the server, the ESP8266 typically takes a few seconds to poll the server, get the information, set the appropriate pins the appropriate states, and then confirms that state to the server again. That's been working for awhile now. But now I wanted to also make changes locally and see the data back-propagate (that's a term for an unrelated concept related to the training of an artificial intelligence) to the server on a mechanism piggy-backing on the updates that set values in the last_known_device_value and last_known_device_modified columns of the device_feature table. It wasn't long before I found problems, some of which required a deeper understanding of the tick-tock timing of all the parts. Sometimes a state change would happen and then immediately be reset back to the value it had before I'd initiated the change, a reversion that wasn't supposed to be happening. So then I'd make a change in hopes of fixing that problem only to introduce a new problem. Eventually I added some logging to a text file, were I discovered that some of the updates that were supposed to be happening were not happening. A lot of the problems were a consequence of the work-around I'd made to deal with the fact that the Apache server insisted on gzipping web results that were larger than a certain size. This workaround made the server step through the pins one at a time, requiring N responses to produce complete data for an N pins. After reorganizing the conditionals in that code, I got it working nicely. But later I discovered that when I reset the NodeMCU, it was no longer getting sufficient data to correctly render the local controller web page. But some further tinkering fixed that problem as well. It still wasn't perfect; sometimes a change made locally would quickly get undone but then it would correct itself and ultimately the correct states would arrive at the correct pins. Even when I switched back and forth between making changes locally and on the server, the system reliably did the right thing.
Interspersed with this work, I took the dogs on a number of walks west of the cabin on my nascent Lake Edward Trail, which, even after several years of very light use, only really goes about 1000 feet, which is a quarter of the distance to the east shore of Lake Edward. I've been stymied for over a year by the fact that I can't find the subtle marks I'd made on the trees along a crude westward trajectory any further west. (Well, I've found marks further west, but not any that connect to them from the 1000 feet of trail that I can reliably find.) Today though, I decided to soldier on and not worry about whether or not I was on that tentative alignment from last year. Unfortunately, I'd neglected to bring a compass and it was a cloudy day, so there was a real potential for getting lost (though not too lost; this wilderness was not of unbounded variety). So I paid close attention to the landscape as I proceeded forward without the benefit of any artifacts or known landmarks. The existing trail ends at a small mostly-permanent brook, and there's a convenient log across it I can use as a bridge. I then climbed over a ridge and saw a small forest pond on a shelf in the landscape across a small valley to the west. After crossing that valley, I'd forgotten about the pond and was now in a dense hemlock grove bounded on the west by a series of sheer cliffs. Could these be the cliffs Gretchen and I randomly stumbled upon on a stormy afternoon in 2021? I found my way around down to the bottom of the cliffs (43.117868N, 74.347826W) and confirmed that they were indeed! I'd been wanting to find these cliffs again ever since we first saw them, though I'd been thinking they were further to the south given how lost we were when we first saw them. The great thing about these cliffs is that they're not just cliffs; in places huge bolders have slipped slightly out of the rock face, leaving voids behind them that creatures have used as shelter. Indeed, there are massive deltas of midden fanning out from some such voids. They contain a lot of pelleted feces of the sort produced by rabbits or deer, though the deep woods doesn't seem like a great habitat for rabbits and I didn't think deer spent much time in caves.
I figured I could avoid getting lost if I hiked northeastward to the Woodworth Lake outflow creek (one of the "bounds" on the wilderness I was in). Somehow, though, the landscape instead guided me back to what looked like the end of my 1000 foot nascent trail to Lake Edward. I couldn't tell for sure, but the log lying across the small brook sure seemed familiar. I started walking east from there and I was right.
I returned some time later, this time with just Charlotte, a compass, and the big Kobalt electric chainsaw so I could get some fallen trees out of the nascent trail. I returned to the top of the high cliffs, finding that woodland pond along the way (prime snapping turtle habitat!). I also found an old hunters' blind made of tarps and a piece of roofing. It was set in the midst of a flat, boulder-strewn landscape with a view of the woodland pond. This one contained no artifacts, not a single shell casing or beer bottle (or, for that matter, broken glass). Some people can't enjoy being outdoors unless they're killing things, though in this case they wouldn't really be outdoors. There's a shoddy grimness to hunting structures, and yet people keep building them.
On my third and last return to the high cliffs today, I brought an ax, my phone, a compass, and both dogs. I'd brought the phone so I could get the precise coordinates of the landmarks I was discovering so I could see where they fell on the map. I've never had a very good app for tagging locations. There's always some problem with whatever I try. Sometimes they want to nickel-and-dime me just as things are getting interesting. Other times they depend on a cell signal, which is really something you can't depend on in the wilderness of the southern Adirondacks. So I was just to get by using Google Maps, since I knew that it wouldn't nickel-and-dime me (for Google, I am the product). But Google Maps sucks too. I'd want to "drop a pin" at my present location (whether I was near the woodland pond, the top of the cliffs, at the hunters' blind, or at the end of the 1000 feet of trail) and Google wouldn't give me a save button. Was it because I didn't have a cell connection? If so, why couldn't it just store the pin until it had a way to save it in the cloud? Was it really engineered to depend on the availability of a cellular connection? If so, that wouldn't make it very useful as a hiking (or treasure hunting) tool. At some point it offered that it could save my position as where I'd parked my car. (I don't know why it hadn't before and now it suddenly did.) That was better than nothing, so I said sure, and a car icon appeared in the middle of the wilderness. But you'd think Google would've thought about their product a little more and come up with something better. This suggests that the engineers at Google need to do a lot more hiking.
I saw on the Google Maps that when I was at the hunters' blind, I wasn't all that far north of Woodworth Lake Road. So I hiked south through a landscape studded with massive boulders the size of school buses until I reached the road. Then I walked back to the cabin using that. I found Neville had already beat me home, and Charlotte wasn't far behind.

One other technological challenge I've been working on at the cabin concerns getting data somehow from the SolArk inverter (the unit that converts raw DC power from the solar panels into electricity for the outlets and other high-power devices). As I've mentioned in the past, this inverter logs data to a web page that I can check, and I use that information to guide my decisions for when to do things remotely. But ideally the data could algorithmically do the same things, with no human intervention necessary. But to do that, I'd need the data in a machine-readable form. This has been a surprisingly difficult nut to crack. SolArk doesn't document how to do this, and there's no API provided for PowerView, the web app that I use to look at the data. I've tried looking at the JSON data that the frontend of PowerView uses, but I it's a bit of mess. And then I'd also have to somehow fake logging in as a human to get to that data. It would be much easier to get the data directly from the SolArk, without it having to be processed on a server out on the internet. I've followed instructions for hooking up an RS-485-to-USB adapter to various ports on the SolArk. Today I went so far as removing the battery's digital connection to the inverter and using its port (which the instructions suggest I needed to do). None of this worked. So then later today I wondered if I could use something like WireShark to intercept the data packets being sent by the WiFi dongle and interpret those. When that turned into a mess, I decided to take an even more direct approach. I diassembled the WiFi dongle (something I did once before) and examined it carefully, wondering if I could solder some wires onto the 3-volt-level serial pins before they get level-shifted to RS-232 levels (the dongle appears to be attached to an old-school nine-pin RS-232 serial port). I quickly found an unpopulated header with three pins labled "GND," "RX" and "TX," the three pins I was looking for. They were spaced 2mm apart, which is denser than the more-conventional pin headers I had on hand (spaced 0.1 inch or 2.54mm) apart. But by distorting such a header, I could stuff it in the holes on the dongle's PC board and it held nicely even without solder. This was essential because there was no angle to solder it from and the pins were very close to tiny surface mount components. Connecting a USB serial adapter to this, I was able to watch the blizzard of data being sent from the SolArk at 115200 baud. None of it was encrypted, but it was cryptic stuff. Still, it was full of English-readable value names. So I decided to log it for about 20 minutes so that I could maybe come up with a plan to turn it into data my systems could use to determine behaviors. Based on the size of the that log, it looks like the SolArk is responsible for 25 megabytes of data use per day, or most of a single gigabyte per month (though this might be compressed before being sent out on the internet).

Neville among some large boulders northeast of the high cliffs. This was before I rediscovered those cliffs. Click to enlarge.

The high cliffs from the west. Click to enlarge.

The high cliffs from the northwest. Click to enlarge.

One of the midden fans coming from a sheltering place in the cliffs. Click to enlarge.

A sheltered nook inside the cliffs. Click to enlarge.

For linking purposes this article's URL is:

previous | next