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!

Overnight Navtex reception on 518 khz 3/24/21 – 3/25/21

After the success of getting my first couple of successful Navtex decodes a couple of days back, I left my PC, SDRPlay and YAND running overnight to see what I’d receive from different stations during the night.

Checking this morning, I got several messages from a number of different stations. Around midnight I was receiving from the Cambria station in Los Angeles. Over the following couple of hours I received transmissions from almost all the West coast stations.

Each message starts with ZCZC (referring to the Navtex page on Wikipedia here), then the next character (B1 field) is the station identifier. Stations are listed on the Station List page here, but there’s also a useful table in this doc covering all Maritime communications which is an interesting read:

This doc also has a map showing the location of each of the US and Canadian stations:

Here’s the messages I received overnight, from Cambria, Point Reyes, Astoria, and Tofino stations:

Cambria, Los Angeles – Station ID = Q

Astoria, OR, station ID = W :

Point Reyes / SF, station ID = C :

Tofino, Vancouver Island, Station ID = H :

This one is interesting, a warning re. a sub-surface scientific platform west of Vancouver Island:

Warning re. COVID-19 pandemic:

Astoria, OR, Station ID = W :

This one is interesting, Whidbey Island small arms safety warning:

Receiving Navtex on 518khz

First time receiving some Navtext on 518 khz.

03/25/21 06:51UTC using an SDRPlay with an MLA-30+ loop and decoded with YAND.

I’m assuming looking at the schedule this was from the Cambria station near LA. The Character ‘Q’ in the B1 data field seems to confirm that.

Revisiting my webapp: visualizing WSJT-X FT8 spots over time – part 6: Redesigning to take advantage of the Cloud

Following on from Part 1 and subsequent posts, I now have the app deployed locally on WildFly 17, up and running, and also redeployed to a small 1 cpu 1 GB VPS: . At this point I’m starting to think about how I’m going to redesign the system to take advantage of the cloud.

Here are my re-design and deployment goals:

  • monthly runtime costs since this is a hobby project should be low. Less that $5 a month is my goal
  • take advantage of AWS services as much as possible, but only where use of those services still meet my monthly cost goal
  • if there are AWS free tier options that make sense to take advantage of, favor these services if they help keep costs down

Here’s a refresher on my diagram showing how the project was previously structured and deployed:

As of September 2019, the original app is now redeployed as a monolithic single .war again to WildFly 17, running on a single VPS. MongoDB is also running on the same VPS. The web app is up at:

There’s many options for how I could redesign and rebuild parts of this to take advantage of the cloud. Here’s the various parts that could either be redesigned, and/or split into separate deployments:

  • WSJT-X log file parser and uploader client app (the only part that probably won’t change, other than being updated to support the latest WSJT-X log file format)
  • Front end webapp: AngularJS static website assets
  • JAX-WS endpoint for uploading spots for processing
  • MDB for processing the upload queue
  • HamQTH api webservice client for looking up callsign info
  • MongoDB for storing parsed spots, callsigns, locations
  • Rest API used by AngularJS frontend app for querying spot data

Here’s a number of options that I’m going to investigate:

Option 1: redeploy the whole .war unchanged as previously deployed to OpenShift back in 2015, to a VM somewhere in the cloud. Cheapest options would be to a VPS. AWS LightSail VPS options are still not as a cheap as VPS deals you can get elsewhere (check LowEndBox for deals), and AWS EC2 instances running 24×7 are more expensive (still cheap, but not as cheap as VPS deals)

Update September 2019: COMPLETE: original app is now deployed and up and running

Option 2: Using AWS services: If I split the app into individual parts I can incrementally take on one or more of these options:

  • Route 53 for DNS (September 2019: COMPLETE!)
  • Serve AngularJS static content from AWS S3 (next easiest change) (December 2019: COMPLETE!)
  • AWS API Gateway for log file upload endpoint and RestAPIs for data lookups
  • AWS Lambdas for handling uploads and RestAPIs
  • Rely on scaling on demand of Lambdas for handling upload and parsing requests, removing need for the queue
  • Refactor data store from MongoDB to DynamoDB

Option 3: Other variations:

  • Replace use of WildFly queue with AWS SQS
  • Replace queue approach with a streams processing approach, either AWS Kinesis or AWS MSK

More updates coming later.