The gang and I made our first QSO with Australia this week!

The QSO came bundled with two other DX contacts made with Project TouCans—all in a 16 minute window—which I'll write about soon. Our camping site is nestled below Anvil Mountain to the East and across the Million Dollar Highway from South Mineral Springs, about two miles north of Silverton, CO. We're surrounded by peaks on all sides. Bear Mountain peak is framed in my pictures of the rig.

Project TouCans was probably 20 feet up in its dipole. This turned out to be difficult to show in photographs with the proper perspective. I finally decided to make a gif of different zoom levels of a single photo. The picture below starts out focused on Bear Mountain Peak and then zooms out to include the rig and the ground outside my partner's and my tent.

You can see the Bluetooth transmitter that brings the head phone audio down to the ground hanging from the bottom of the rig.

The campsite is gorgeous and almost completely bug free. I managed to make it out on one hike. Tawnse—the nine year-old—our puppy, and I were treated to views like this

That brings us to the circumstances of the QSO with VK3YV, the first DX QSO of that morning. Here's our campsite from a way's out showing the F2 skip path (estimated using real-time data from the Boulder, CO ionosonde), as well as the path of the QSO along the ground. 

So, with all those mountains in the way, how did we talk to Australia?

Project TouCans threaded the valley to the west of our campsite! Check this out!

I'll leave you with the map of the QSO so you can trace along the path at your leisure. Use the time control in the lower left corner or the slider along the bottom of the map to locate the QSO at 12:40 UTC. From there, you can zoom in and out using a mouse center-button wheel. You can also tilt by holding down the control key, and then moving the map using the left mouse button.

Update

Due to a bug in the ionosonde code that I'd immediately introduced, the F2 layer height was not 307 km as shown in the diagram above. It was in fact, 235 km over Hawaii which had data at the time, (Boulder, CO in fact did not), and which was closer to the middle of the QSO path as well. The difference in F2 height resulted in the first mountain intersection that used to look like this

with the incorrect data looking like this with the new F2 height data

References

Ionosonde Data

This was made possible with data collected by 

Reinisch, B. W., and I. A. Galkin, Global ionospheric radio observatory (GIRO), Earth, Planets, and Space, 63, 377-381, doi:10.5047/eps.2011.03.001, 2011.

• http://spase.info/SMWG/Observatory/GIRO

 POTA activation from Silverton in twenty-one minutes!

Project TouCans had one of its highest ever antenna placements.

I'm loving the, (very real), yet very sci-fi look of what's going on with the F2 skips from this rig at this location

Turns out, it's line of sight between mountains from here

QSO Map

Here's the map you can steer around in on your own! Remember, click play in the lower left hand corner, then move the time slider all the way to the left. You'll be able to see all the QSO paths and their F2 skip paths (based on Boulder, CO ionosonde data at the time of the QSO.) If you click play again, you'll be able to see how the QSOs played out over time.

Notes

Difference in Altitude

I'm still working through getting the F2 traces to routinely emit from the ground. This time, Google Maps said the elevation here was 2982.468 m, but Cesium is happier with 2947.468 m, co about 35 meters lower than expected. Even then, we're not on the ground

SQL Query

select

  tx_lng,

  tx_lat,

  rx_lng,

  rx_lat,

  rm_rnb_history_pres.timestamp,

  rm_rnb_history_pres.dB,

  rm_rnb_history_pres.Spotter,

  haversine(tx_lat, tx_lng, rx_lat, rx_lng) as total_path,

  gis_partial_path_lat(tx_lat, tx_lng, rx_lat, rx_lng, 200) as el_lat,

  gis_partial_path_lng(tx_lat, tx_lng, rx_lat, rx_lng, 200) as el_lng,

  id,

  strftime('%Y%m%d', timestamp) as date,

  strftime('%H%M', timestamp) as time,

  'US-4399' as park,

  'KD0FNR' as call,

  'BC840' as ionosonde,

  2947.468 as elev_tx

from

  rm_rnb_history_pres

where

  dB > 100

  and timestamp > '2024-05-29'

  and timestamp < '2024-05-30'

order by

  rm_rnb_history_pres.timestamp desc

SQL Query for RBN and QSOs

Due to a bug/oversight in the system, I have to run with tx location coordinates set in the query when I want to include RBN spots, so here's that query

select

  -107.7179358 as tx_lng,

  37.8227611 as tx_lat,

  rx_lng,

  rx_lat,

  rm_rnb_history_pres.timestamp,

  rm_rnb_history_pres.dB,

  rm_rnb_history_pres.Spotter,

  haversine(tx_lat, tx_lng, rx_lat, rx_lng) as total_path,

  gis_partial_path_lat(tx_lat, tx_lng, rx_lat, rx_lng, 200) as el_lat,

  gis_partial_path_lng(tx_lat, tx_lng, rx_lat, rx_lng, 200) as el_lng,

  id,

  strftime('%Y%m%d', timestamp) as date,

  strftime('%H%M', timestamp) as time,

  'US-4408' as park,

  'KD0FNR' as call,

  'BC840' as ionosonde,

  2947.468 as elev_tx

from

  rm_rnb_history_pres

where

  timestamp > '2024-05-29'

  and timestamp < '2024-05-30'

order by

  rm_rnb_history_pres.timestamp desc

References

Ionosonde Data

This was made possible with data collected by 

Reinisch, B. W., and I. A. Galkin, Global ionospheric radio observatory (GIRO), Earth, Planets, and Space, 63, 377-381, doi:10.5047/eps.2011.03.001, 2011.

• http://spase.info/SMWG/Observatory/GIRO

 Here's the query I'm using for Burr Trail

============================================

select

  tx_lng,

  tx_lat,

  rx_lng,

  rx_lat,

  rm_rnb_history_pres.timestamp,

  rm_rnb_history_pres.dB,

  rm_rnb_history_pres.Spotter,

  haversine(tx_lat, tx_lng, rx_lat, rx_lng) as total_path,

  gis_partial_path_lat(tx_lat, tx_lng, rx_lat, rx_lng, 200) as el_lat,

  gis_partial_path_lng(tx_lat, tx_lng, rx_lat, rx_lng, 200) as el_lng,

  id,

  strftime('%Y%m%d', timestamp) as date,

  strftime('%H%M', timestamp) as time,

  'US-4399' as park,

  'KD0FNR' as call,

  1770.829467773438 as elev_tx

from

  rm_rnb_history_pres

where

  dB > 100

  and timestamp > '2024-05-27'

  and timestamp < '2024-05-28'

order by

  rm_rnb_history_pres.timestamp desc

=======================================================

At some point I'll add an ionosonde field using this map for each QSO. For the Boulder, CO ionosonde, the query will look like

=========================================================

select

  tx_lng,

  tx_lat,

  rx_lng,

  rx_lat,

  rm_rnb_history_pres.timestamp,

  rm_rnb_history_pres.dB,

  rm_rnb_history_pres.Spotter,

  haversine(tx_lat, tx_lng, rx_lat, rx_lng) as total_path,

  gis_partial_path_lat(tx_lat, tx_lng, rx_lat, rx_lng, 200) as el_lat,

  gis_partial_path_lng(tx_lat, tx_lng, rx_lat, rx_lng, 200) as el_lng,

  id,

  strftime('%Y%m%d', timestamp) as date,

  strftime('%H%M', timestamp) as time,

  'US-4399' as park,

  'KD0FNR' as call,

  'BC840' as ionosonde,

  1770.829467773438 as elev_tx

from

  rm_rnb_history_pres

where

  dB > 100

  and timestamp > '2024-05-27'

  and timestamp < '2024-05-28'

order by

  rm_rnb_history_pres.timestamp desc

limit 1

====================================================================

The extra ionosonde field works!!! 

References

Ionosonde Data

 The F2 skip traces in Cesium have looked a bit odd:

It's because they're starting from sea level, not the altitude of the station.... I think... What follows are somewhat random development notes.

Relative to Ground: True, Alt: 0

Almost!!!

Relative to Ground: true, elevation: 1770.829467773438

I got the more accurate elevation from the elevation plugin using:

{{ tx_lat }},{{ tx_lng }}|{{ rx_lat }},{{ rx_lng }}

So, it seems like the correct altitude in this case should be 0. (Start the line on the ground.) But, if I put in zero for altitude, I get the result shown above

 KO6BTY and I attended office hours with Simon Willison yesterday.

Here's what you're seeing. There's an SQL query in our Datasette instance that grabs only the QSOs from our Cibola National Forest POTA back in March. That query resulted in 9 QSOs shown in the table. Our additional CZML (and now Cesium viewer) plugin creates a CZML map that is loaded into a Cesium Ion viewer at the bottom of the page.

I'm not releasing the code that loads up the viewer quite yet because I have to get the access token squirreled away and all that good stuff. Meanwhile the CZML plugin has been released for a few days now.

By the way, we need a way to pull adif files from POTA activations into Datasette. Keep an eye out :)

 I completed the first prototype of my CZML QSO mapping template for Datasette yesterday.

So far, I've implemented animation by using the interval property in CZML. Intervals can be attached to any (?) other tag it seems. I had to intuit what to do on a large degree based on the documentation.

{
    "id": "myObject",
    "someProperty": [
        {
            "interval": "2012-04-30T12:00:00Z/13:00:00Z",
            "number": 5
        },
        {
            "interval": "2012-04-30T13:00:00Z/14:00:00Z",
            "number": 6
        },
    ]
}

I used CZML polylines to display each QSO. Each polyline has a show property. I attached an interval to each QSO of one minute, like so:

.

    "id":"ea1ec",
    "name":"ea1ec",
    "polyline":{
      "positions":{
        "cartographicDegrees":[-106.5569121602622,32.371370471129424,0, -3.689354499999999,42.3504659,0]
      },
      "material":{
        "solidColor":{
          "color":{
            "rgba":[255, 0, 0, 255]
          }
        }
      },
      "show":[
          {
              "interval":"2024-03-14T23:29:00Z/2024-03-14T23:30:00Z",
              "boolean":true
          }
      ],
      
      "width":5,
      "clampToGround":true
    }
  }

The inference that the viewer (happily) made was that if the show property was true in the interval, then it must be false the rest of the time. (The default value of 'show' is true, so I was quite pleased with this implementation instead of the alternative where I might have had to define intervals for when I wanted the line turned off. This solution is far more intuitive to me.

I like several things about how this worked out with Cesium as opposed to other geospatial solutions available on the web. First, Cesium has animation available directly on the web as opposed to a desktop application. 

  {
    "id":"document",
    "name":"my first map",
    "version":"1.0",
    "clock":{
      "interval":"2024-03-14T23:28:00Z/2024-03-15T00:00:00Z",
      "currentTime":"2024-03-14T23:24:00Z",
      "multiplier":60,
      "range":"LOOP_STOP",
      "step":"SYSTEM_CLOCK_MULTIPLIER"
    }
  },
  {
    "id":"k6mdg",
    "name":"k6mdg",
    "polyline":{

The "clock" "interval" specifies the entire time available to the player. I need to modify my template a bit to make the beginning of the interval, (which is the time of the QSO at the moment), match the currentTime, (which is a few minutes earlier to provide a runway into the animation.) I suspect this may be what's causing me to have to click the play button twice to start the animation.

The final nice feature I'll point out today is that the Cesium Sandcastle makes it easy to play and experiment with both CZML and using JavaScript to control the viewer. You can even import CZML into Sandcastle sessions using the viewer's load method and statically hosted files. I used github as an easy platform to serve files from. (Keep in mind that new commits to files take about a minute to reach the raw page.)

On the downside, the documentation for CZML took me a while to get used to and required several mental leaps and experiments, some of which were incorrect. 

Oh! And it turns out you can share and embed slide shows. I'm not an expert at these yet, but they seem promising.

 A single path animation is up and running!

The animation can be seen here.

But wait! There's more! I now have a template that creates an entire animation:

Want to explore it on your own! Please do:

 I had a little time to play with a new mapping app over the weekend!

This one is from Cesium and in its native form uses a JSON derivative called CZML. CZML is similar to KML. Furthermore, while it won't animate kml for me (at least not yet), CZML looks like it will support timestamps and animation. So! Maybe there'll be a new plugin for the logging program this week.

Also! The resulting maps are shareable!

And perhaps can be shown in an iframe