Revisiting my spotviz.info webapp: visualizing WSJT-X FT8 spots over time – part 5: MongoDB Aggregate Queries

Now I have my http://www.spotviz.info app up and running with some collected spot data for testing, one of the first things I want to enhance is the date range selection for visualization, and specifically, adding more data to the heatmap to help you pick a good date range with available data.

The heatmap display I originally added gives you a visual representation of which days have data to view, but it doesn’t help you pick a time range within that day where there’s data. Here’s what the heatmap looks like right now:

The darker the color the more data there is for that day. The problem as it is right now though is that say for one day you ran WSJT-X for 1 hour between 1pm and 2pm and received spots from 2000 stations. Without knowing that there’s only data between 1pm and 2pm, you could select a range of 9am to 6pm for playback, and you’d get nothing displayed on the map until it animated through the 1pm to 2pm block and then a gap of nothing again.

My first enhancement here is to show the earliest and latest signal received times for a given day, to help you pick a good range.

The original MongoDB query (which I discussed here) retrieves a count of spots per hour for a given day:

db.Spot.aggregate( [   
{$match: {spotter: "kk6dct"}},
{"$group": {
"_id": {
"$subtract": [
{ "$subtract": [ "$spotReceivedTimestamp", new Date("1970-01-01") ] },
{ "$mod": [ { "$subtract": [ "$spotReceivedTimestamp", new Date("1970-01-01") ] }, 1000 * 60 * 60 * 24 ] }
]
},
count:{$sum: 1 }
}
}
])

There’s only one calculated value returned in the results in this query, count, but in order get the earliest and latest spots per day, this is a simple as adding two more calculated values following the return of

count : { $sum : 1 }

so the last part of the query is now:

    count : { $sum : 1 },
    "firstSpot" : { "$min" : "$spotReceivedTimestamp" },
    "lastSpot" : { "$max" : "$spotReceivedTimestamp" },

Done!

Revisiting my spotviz.info webapp: visualizing WSJT-X FT8 spots over time – part 4: It’s back, it’s alive! http://www.spotviz.info

I still have some refactoring to do as I move the app to the cloud, but as the first starting point I have the original app up and running on WildFly on a VPS. It’s back up and live on the original domain, http://www.spotviz.info

The uploader has been updated to read current 2.x WSJT-X log files, but I haven’t uploaded the .jar to GitLab yet, but I’ll do that soon. I’ve some test log data uploaded under my callsign, KK6DCT.

More changes to come soon.

If you’re catching up, here’s my previous posts on getting the project up and running again:

Revisiting my spotviz.info webapp: visualizing WSJT-X FT8 spots over time – part 3: Successful deployment: visualizing 20m spots from 9am to 10pm

I’ve successfully deployed my SpotViz app on WildFly running locally and tested running a visualization playback of FT8 signals received during a whole day, from 9am to 10pm. It’s interesting to see the propagation move from my location on the US West coast out to the East coast, and then gradually move West during the day, following the sun, until the propagation dies out on 20m completely around 10pm.

Here’s a screen capture of the playback:

Next up, I’ll be setting this up hosted on a VPS somewhere, and start working on some of the bugs in the UI.

Deploying a Jersey based web app to WildFly 8 (part 1)

I’ve been resuscitating a personal Amateur Radio related project from a few years back that I previously had hosted on RedHat’s OpenShift. It was previously deployed on WildFly 8, so before I start making changes I want to get it deployed again locally on WildFly 8.

First up I got this error:

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ServiceLocator with qualifiers @Default at injection point [BackedAnnotatedField] @Inject private org.glassfish.jersey.internal.inject.ContextInjectionResolver.serviceLocator

This error appears to be pretty common. From the suggestions posted in reply to a similar post to WildFly forum here, the suggestion was to include Glassfish dependencies. I never had these included before, so not sure why I need these now, but these did the job:

<!-- kh added for error: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default -->
<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>17.0</version>
</dependency>

<!-- kh: added per: https://developer.jboss.org/thread/240847 -->
<dependency
  <groupId>org.glassfish.jersey.containers.glassfish</groupId>
  <artifactId>jersey-gf-cdi</artifactId>
  <version>2.14</version>
</dependency>

<dependency>
  <groupId>org.glassfish.jersey.containers</groupId>
  <artifactId>jersey-container-servlet</artifactId>
  <version>2.14</version>
</dependency>

The odd thing is if I deploy to WildFly 8.2 I don’t get this error or need these additional dependencies. Anyway, all set for now. I just tested deploying to 17.0.1 with no additional changes needed either.