Articles, notes and random thoughts on Software Development and Technology
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 :
Only worked about 20 mins or so and picked up Denmark and Croatia for the log.
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:
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.
A few years back I built an AngularJS webapp for visualizing JT65/JT9 spots over a period of time, logged as you run the WSJT-X app to decode FT8 signals you receive at your station. At the time I had it deployed on RedHat’s OpenShift, running in a couple of ‘gears’: one for JBoss hosting a REST API backend, a queue and MDB for processing uploaded spots, and one for a MongoDB database to store the collected spot info. Unfortunately the ‘bronze’ basic plan which was an incredible good deal for hosting apps at the time (at around $1 a month if I remember right) was discontinued, and the replacement plans were multiple times the cost, so I discontinued the app and didn’t redeploy it again after that.
At some point thought I was planning on taking another look at deploying it elsewhere, and if I’m going to pick it up again, I might as well take a look at refreshing the architecture. Here’s what the original v1 deployment looked like:
For personal projects I typically build them using some api or technology I want to get more familiar with. I remember at the time I had a need to refresh myself on JAX-WS SOAP based webservices, so the client that is monitoring the WSJT-X log file and uploading to the serverside for processing is a generated JAX-WS client to a webservice deployed in front of a queue; it receives the messages sent from the client and adds them to the queue for processing. If I had to refresh this part there’s no real need for this to be as heavy as JAX-WS and could be simpler with a simple REST api, so that’s probably how I’ll update that part.
I’m interested in something like Apache Kafka can be used to process high volumes of incoming data, so this might be a good refresh for the serverside queue and MDB.
I remember putting a lot of time into building my animated map display of received spots in the AngularJS app. This was back in 2015 I think, so this could probably do with a refresh to at least the latest/current Angular version, which would be a considerable rewrite I think. I’ll take a look.
Anyway, I haven’t run any part of this even locally in development for years, so that will be my first steps, get it up and running, and then start incrementally updating some of the parts.
This project is related to my recent experiments with getting WSJT-X and a SDRPlay RSP2 running on a Raspberry Pi, as a low cost FT8 monitoring station, so now that part is up and running, time to work on the software side again.