Copasetic Flow

 OK, let's maybe wrap this up. Spoiler: I developed more cool new stuff, but didn't wrap this up. Recap: I set out to see what it would take to map the skips for a QSO, and then try to extrapolate those back to the launch angle of the dipole that KO6BTY and I use for Project TouCans  at our home QTH . Along the way, I learned a lot including another use for the cross product. I also remembered, just now, that dipoles can have more than one launch angle. Taken from Radio Antenna Engineering That'll be important later. Today, as promised, I tried the three skip solution. Here's the angle of radiation from the SF station with three skips. But what's the numeric quantity for the angle in degrees? Well, I worked through yet more math. It's getting easier though. I added the code for the cross product of two vectors (position vectors in our case) as well as the usage I'm making of the cosine and sine laws to to earthmid.py . The numeric result of three skips is 7

Let's get going. Here's the figure explaining the formula we'll be using. It's the one I alluded to yesterday. The formula of which I speak will tell us the minimum F2 height required for a radio signal to skip off the ionoshphere and back to another station. The geometry used to derive the formula has a single constraint: the lowest angle, (radiation angle), the radio signal is allowed to leave the transmitting antenna at is 0 degrees—in otherwords, parallel with and tangential to the ground. The formula will be used in a larger application to programmatically determine the number of skips that are required to make a QSO via the F2 layer of the ionosphere. I'll explain more in a bit. Picking up where we left off yesterday, we're using the measured height of the ionosphere in Pt. Arguello ~330km, and we're assuming the signal skipped twice, (remember that in yesterday's post we saw that if the signal only skipeed once, the only way to reach Sweden was in

 Just an on paper, (so to speak), example of how to do the F2 mapping for QSOs, (and why it's more complicated than it appears at first), today. Let's consider this QSO to Sweden from San Francisco: Retrieving the F2 height data immediately led me to the conclusion that the mapping app has to work in spacetime, (sadly, that's not a relativistic reference), as opposed to just in sapce. Here's the output of the Pt. Arguello ionosonde for the times around that QSO: Notice that there is no value for hmF2 (the maximum estimated height of the F2 layer) at the actual time of the QSO. I'll need to work on statistical data selection as a result, but for now, I'm just going to go with 330 km as an estimate of what the height was at the time of the QSO. Here's what the path along the Earth looked like Turning on the current implementation of F2 mapping reveals we'll have lots of things to look at But the reason I'm writing today is that skip coming from undergr

 I made the first release of the package yesterday. The case for finding the shortest distance from the point to the path when the distance is not along a perpendicular to the path has been implemented . The package has been released with the tag 0.1 .

 I got to play around with spherical trig last week under the guise of improving the accuracy of the model that KO6BTY's and my F2 skip maps utilize.  Today, I took the first steps towards formalizing the algorithm I modeled into a datasette plugin so we can use our kml plugin to create skip maps (I'll probably also add a configuration flag to turn skip mapping on and off.) Using datasette-haversine as a model, I created datasette-haversine-point-path . The new plugin allows users to specify three lat/lng pairs that define the enpoints of a QSO and the location of an ionosonde. Given this information, the newly defined sqlite method will return the shortest distance between the ionosonde and the QSO's propagation path along the Earth. (I still need to add the special case where the shortest distance to the path is in fact between the ionosonde and one of the endpoints. I'll talk about this in my next post.) I re-puprosed the test case from datasette-haversine as wel

 The gang, (12 year-old Diaze aka KO6BTY, 11 year-old Mota, and 8 year-old Tawnse), and I did things with vector cross products, operated Raspberry Pis in the face of radio frequency interference (RFI) and started to update the ham radio exams Javascript charting package calls this week. Ionosphere and Cross Products KO6BTY and I put together kml files that show the approximated F2 skip of a QSO last year. The maps are very approximate because they only take the Pt Arguello ionosonde down the coast from us into consideration. To determine what other ionosondes to use data from, we needed to know how far each of the ionosondes was from the path between an arbitrary pair of QSO stations. In other words, we needed to work with spherical trigonometry. The first step was to figure out the algorithm. The solution was easy to find on StackOverflow, but it was hard to picture at first. I fixed that by getting back into using Sage for demos . The final step is shown below. Raspberry PI

 I've run into an interesting math problem. Project TouCans occasionally makes dx contacts. That's not a problem, that's actually really awesome! However, KO6BTY and I would like to be able to map the F2 skips our radio signal makes on its way to the receiving station. We have plenty of data about the F2 layer of the ionosphere that is captured by ionosondes around the world. The issue is how do we determine which set of ionosonde data to use? Our first guess is that we should use the ionosonde closest to the path of the signal at any point. OK... Now, how do we determine that? First, we'll calculate the shortest distance from each ionosonde to the path of the QSO between ham radio stations. Then, we can sort the distances so that we can only include the ionosondes that are closest to the path. Armed with that data, we can perhpas used the distances to calculate a weighted,  estimated height of the F2 layer at any point along the signals path as it skips from

 We built a keyer! KO6BTY was gifted a FT-840 by the family of a silent key over the holidays. (It was very, very nice of them. Thank you all!) She also received a straight key kit from W1REX . (Thanks Rex!) Daize—as she's kown in these pages—quickly constructed her key; she and I added a 10 meter dipole to our now  growing antenna farm; and the kid was up and transmitting CW on 10 meters with her technician class license! Also! She's a new SKCC member! Here's the thing though. Neither one of us is good enough with a straight key—she's better than I am to be frank—to convince the Reverse Beacon Network that our callsign is actually decipherable. So, to make sure our signal was getting out and to help people spot us for event lke SKCC's SKM. Project TouCans has a memory keyer in the Rockmite that works quite admirably for just this sort of thing, but now so much the venerable FT-840. That's ok though. We built our own autokeyer ! Here it is in all it's early

 I released my first Python Package last week! I've been using Datasette to analyze my QSO logs for several months . It's been a really useful tool since it's already setup with quite a bit of mapping fucntionality via various plugins . At the same time, the gang and I have been working with the Google Maps API and kml files to map the paths between amateur radio staions in our QSOs.  A few weeks ago, Simon Willison announced Datasette Enrichments . One of the first exampels was a geocoder (an enrichment that produces the longitude and latitude of an address) using opencage . This opened my eyes to the possibilities of taking the gang's and my original mapping utilities I mentioned above, and implementing them with a number of datasette enrichments and plugins. What was missing however, was a way to do this with Google Maps instead of opencage. Missing until last week that is! The gang and I worked through creating the google maps geocoding enrichment . Then, I worked

 The gang—the 12, 11, and 8 year-old kids whose dad I am—and I attended Simon Willison's Datasette office hours on Friday to talk about our ham radio Datasette projects and to start a bit of debug on a Datasette geocoding  enrichment we're working on. During our meeting, Simon asked what the longest QSO we'd made with the radio was, and mentioned that the datasette-haversine  plugin can be used to calculate the distance between two locations on the Earth. Coincidentally, I'd already been looking into this in relation to the SKCC 1,000 Watts per Mile award. Consquently, I set out to apply the Haversine to our QSO logbook in Datasette to find the best set of QSOs to send in with our award application. KO6BTY and I did an initial glance on Friday after speaking with Simon. Here's the query we used: select rowid, id, tx_lng, tx_lat, rx_lng, rx_lat, haversine(tx_lat, tx_lng, rx_lat, rx_lng, 'mi') as haversine, floor((((haversine(tx_lat, tx_lng, rx_lat, rx_

 One of the kids' and my great consternations around large language model (LLM) AIs is the variety of claims that they can't match the performance of a search engine, and well yeah, They're Not Search Engines! They're a completely different thing. They're sentence completion engines that have the entire Internet at some set date at their disposal. They organize the information they were trained on into a greater than 1,000 dimensional space (in most cases) and then do a dot product of what you've told them so far with that space to determine what they should say next. Having said all that, after performing the following search on Google this morning: "what do you call a cross frequency radio contact" and getting no useful results, I headed over to ChatGPT to chat with the app about our fictional friend, Penelope . She's a programming and ham radio expert who went away on an expedition. The kids and I are communicating with her via ham radio (all of