JS8x - The Next Generation

[jsherer]

Hey folks,

I announced this in the JS8Call groups.io today. I know a lot of y'all participated in the original testing of JS8Call (FT8Call!) and I'd love if any of y'all would like to help out, too:

Hi folks 👋,

It's been a long time coming, but I'm happy to say that I'm wrapping up research and development on a new digital mode based on what I've learned with JS8 over the years. This new mode is showing to have 3 dB (!) advantage over JS8 during simulation and local tests.

The proof, however, is in the ionosphere. So, I'd love to get a couple of folks together to do some on-air testing in a few weeks. My plan would be to hop on a zoom call and run some experiments live.

A couple of highlights:

• The mode is based on streaming frames of binary payloads from 64 to 256 bits, so the encoding is flexible at the moment.
• The mode has streaming synchronization, so no clock or timing accuracy is required.
• The mode implements a flexible bandwidth and baud choice, similar to configurability like VARA/Olivia/Contestia for adapting to real (and marginal) HF conditions.
• The mode is still frequency shift keying, so we keep detection and decodability through fading and multipath conditions.
• The mode uses modern techniques in forward error correction while also greatly reducing the number of false decodes.
• The mode does not use any of the code from WSJTX or FT8, so we no longer have to worry about the GPL license restrictions.
• And, the mode is cross-platform from one codebase, works on Windows, Linux, Mac, iOS, Android, and Web (yes, you can even load it from a web browser)

I'm in the process of writing a paper on this and want to get some real world signals on the air. If you're a developer or just interested in being an active tester, sign up here: https://forms.gle/4CzC3cKC4UpConYX6

Best,
Jordan / KN4CRD

PS. Here's a first look of it running in a browser from my iPad:

[Chris-AC9KH]

Sounds interesting. Unfortunately, summer is a bad time for people to be available for testing anything like this. As we get further into late fall/early winter here the North Woods, and things slow down, I'd be interested in taking a look at it.

[Beiri22]

I’m curious about the longer-term direction for JS8x. Is the idea for JS8x to remain a fully separate mode/application alongside JS8Call, or could you also imagine it eventually being integrated into JS8Call as an additional/new modem mode if it proves itself in real-world testing? I think that could be especially interesting from a community perspective: rather than splitting activity between two separate ecosystems, JS8x could potentially complement JS8Call. Of course it is probably far too early for any firm plans — I’m mainly curious whether such an integration is technically or conceptually something you already have in mind.

[jsherer]

Good question. It's a little early to make definitive plans, but my goal is for js8x to be flexible enough (i.e., a library/sdk) to be easily integrated into JS8Call (or other applications, including a web app!, for that matter).

I have a local branch that demonstrates it is possible with this repo. My only hurdle will be ensuring the GPL-licensed code interacts well with the non-GPL-licensed code.

More to come in Sept.

[Chris-AC9KH]

If you compile a single binary that merges GPL code and non-GPL code into a single executable, the GPL views the entire binary as a derivative work. To legally distribute the binary, the non-GPL feature's source code must be released under a GPL-compatible license.

The GPL is overly restrictive in this regard. The way around it is to re-license JS8Call under 3-clause BSD. However, that can present some hurdles. You must contact every single person who has ever contributed code to the repository and get them to agree in writing to the license change. If certain contributors refuse or cannot be reached, you must completely remove their code and rewrite those specific features from scratch before changing the license.

While there is no WSJT-x code left in JS8Call-improved, it has all been re-written from scratch, it would still require agreement of anyone who has contributed code to JS8Call-improved.

The biggest advantage of the 3-clause BSD license is that it removes legal friction for commercial developers. It opens up more avenues, like being able to develop JS8Call and distribute it for devices like the Apple iPad. While I have JS8Call running here on both my iPad Air 5 and iPad A16, the GPL license is primary reason I have not proceeded with further development for iPadOS. If it was licensed 3-clause BSD then I can go to the commercial Qt license, build a proprietary version of it for iPad and distribute on the Apple app store. For a library or SDK, a BSD license allows it to be used in any software ecosystem, whereas GPL restricts its usage exclusively to other GPL software.

The GPL is primarily a linux ecosystem thing. However, the primary userbase of JS8Call is not linux. While the GPL may look like a good idea on the surface for an open-source application it is not the best, or only, licensing option for cross-platform applications.