Casual FT8 afternoon operation: 20m with just 6w

Spent a few minutes Saturday afternoon doing some casual FT8 on 20m, using my FTX-1 on internal battery (so just 6w output), with a SuperAntenna temporarily setup in the garden. Still fascinates me how far you can get with just a few watts. Here’s where I was being heard on pskreporter.info :

Screenshot

Only worked about 20 mins or so and picked up Denmark and Croatia for the log.

Working JA Stations on FT8 – late evening 20m

While sitting at my radio desk and checking in on my RCARCS weekly 2m net, I fired up my HF radio and noticed at 7:30pm on 20m it sounded like there was a bunch of JT8 signals, so started up WSJT-X to take a look:

First up I noticed call sign 8J3ZNJ which is an unusual prefix I haven’t seen before, turns out this is a 50th Anniversary special event station for a Japanese ham radio club,

Calling CQ a couple of times I then picked up contacts with 3 other Japan stations. Not bad for some casual spur of the moment FT8 operation!

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.