Copasetic Flow

 Eeeeeep! It's been, well, 11 days in since my last week notes. Sigh.... Here's what's been going on. I spent the first half of that ime working on getting the time stamps back into the ham radio qso kml maps, and I did it ! While working on this, I discovered that I didn't quite know how to include jinja templates inside other jinja templates. I figured it out though. Meanwhile, I've been methodically trying things as far as adding elevation plots to the kml maps. Things are moving along slowly ... and!!! ChatGPT may have just told me how to do the whole thing??? Anyway... Also! Data (and therefore Datasette) is good !

 It's kinda awesome to have data! Earlier today I was working on the elevation profile project I've been writing about throughout the week. I've moved the project up to the point where an enrichment provides the elevation at the transmit location of the QSO, (my end of the path.) Looking at the results, at first I thought I must have introduced a bug at some point. The first two QSO elevations were meters and 3 meters high. That seemed awfully close to sea level, especially considering that most of my POTAs are made from the sides of various mountains. Looking at the table row for the 3 meter QSO I inspected the date: March 14th of 2024. I checked my photos to see where the gang and I were on that day and found this So! We were at just about sea level, that being the sea just to the right-hand side of the picture. What about the two meter high QSO? At this point it occurred to me that I didn't need to look back at pictures to see where we'd been on the 23rd of Ma...

 I've been slowly but surely working through this week's ham radio QSO elevation profile project. The way I want to use the tool (Datasette) doesn't feel like a good fit for the tool. That's made things more difficult. In short, here's what I hope to achieve: Plot a partial QSO path for each contact from the transmitting station (me), about 10 wavelenghts or so out towards the receiving station, so about 200 meters or so in this case. This path should be on the kml map of the QSO This is done. Place a png picture of the elevation profile into the Datasette row for that QSO. This is what this post was about. Add this picture to the kml map as well. So! I think I was wrong! The point of this whole operation was to have elevation profiles directly available in kml animated maps. I wanted them to be automatically included with each QSO, but my ownw specification was that they should be in the map. Not the database! Basically, there's data, the dates, times, callsign...

 All of the Datasette plugins and enrichments contain this development instruction towards the bottom of their documentation page: Now install the dependencies and test dependencies: pip install -e '.[test]' However, on windows, the above pip install line does not work. It returns an error message: ERROR: '.[test]' Note that the single quotes are still in the message. That is in fact the issue. This command: pip install -e .[test] Does work on Windows. I've updated the documentation on the datasette-enrichments-gmap-geocode package to reflect this.

 One of my goals this week is to add elevation profiles between QSO stations as a Datasette enrichment to our ham radio QSO Datasette utility. It's turning into a bit more of a convoluted project that I'd expected, so I'm taking the time to right down the first pass of the steps in the process. Here are the broad strokes: Complete a partial path Datasette plugin to find the coordinates of a small portion of the path between stations to use as the endpoint for an elevation profile path. This is already done . Use those coordinates as an input to a Datasette plugin that returns the elevation profile as json data. The first step of this has been prototyped . (It's looking like installing jq for Python on Windows is going to be a bit of an issue , so I'll find a different way to parse the returned json. I've done similar tasks with the ionosonde data and the rx station geocoding data. Produce charts as images for each row so that the query immediately presents a sum...

 There's a running joke on  HamRadioWorkbench   about operating mobile from a riding mower. I'm proud to announce that through the wonder that is Project TouCans, WiFi, and Bluetooth, the team here at antigravkids is releasing their first QRP mower w/ ham radio prototype. Both the mower and the 20 meter rig are QRP :) Go ahead, take a listen. The prototype is enabled by the following technologies: Project TouCans Pico-W Enabled Keying Bluetooth Audio ala JBL Clip 3

 Having learned how to make timestamps again, I'd wound up with quite a lot of lines of template that didn't really do anything too, too awe inspiring. In short, I needed a twelve line block of kml to display a single digit of a time or a date. I decided the spiffy thing to do would be to move this kml template into a file that I'd include from the base kml map jinja template. It was more difficult than I originally thought it would be. Turns out that simply adding the include line did not do the trick. I got back the error message: no loader for this environment specified A little bit of research led to a solution. Jinja template objects in Python needs to have an Environment that is properly setup if you plan to include other templates from inside a template. That led to this line tmpl = Template(f.read()) changing to this line tmpl = Environment(loader=FileSystemLoader("./plugins/templates")).from_string(f.read()) At which point the template was located. Then,...