What would everyone suggest as far as hardware to start using JS8Call/FT8?
I think I have just enough room for a 40m inverted V (a dipole might be a little tricky since I don’t have trees in the yard).
I don’t have any transceiver yet, so completely open on that front!
Thanks!
Do you really want to run JS8call? JS8Call and the Fundamental Problem with EmComm in Amateur Radio: Why I stopped using JS8 and why I think you should too.
I sure do! I’m an engineer and fascinated by digital modes. I wasn’t really interested in message forwarding anyway, so this gives me an even better excuse to turn it off.
Just because there are bad actors using a thing doesn’t mean that everyone using it is bad (you can use automobiles as an example).
I think (open) digital modes are a great way to push the envelope and innovate in ham radio. Check out FreeDV or M17 for positive examples! I’m just here for the fun of the hobby :)
Can you spell it out a bit? I read through the linked sources (that I had access to) and couldn’t determine a clear link between the software’s developer and J6/OathKeepers/Redoubt movement other than the mode is used by those fringe elements. The “Supports” link is just to the JS8 user manual and the other links don’t have clear ties to Jordan or JS8. Admittedly, I’m not a member of the js8call groups.io group, so I wasn’t able to read through that source to see if a tie was more clearly established.
I’m all for not supporting those who are trying move the US to christofascism, but avoiding the most popular free-form digital chat mode because of an alleged link is a stretch. It would be nice to have an “allow list” for who you’re willing to accept messages for, or allowed recipients, but to me, the protocol is still plenty useful without having message forwarding enabled.
That manual is written by Jordan, but the key point is not the manual, it’s the software and protocol.
JS8Call has a few bits it can devote to “special” group calls that save a lot of bandwidth, and saving bandwidth improves how much you can send in a single cycle, improving both communication speed AND fidelity. But there are only a few of them because they are limited by the protocol design, so Jordan necessarily has to be selective. He chose to devote one of those to a group with christofascist and insurrection ties. That is an implied endorsement, or special assistance rendered to that group that turns off a LOT of hams. It’s quite literally baked in to the software. If that doesn’t bother you, fine, but I hope you can see why many of us would rather just stay clear of something like that.
The relaying is also a problem. Though most people don’t automatically relay, it’s worth being aware that if you turn that feature on, you could be carrying water for AMRRON. It could also be illegal at a point. Without the network features of JS8Call, it doesn’t actually bring a while lot of fancy features beyond existing digimodes.
Thank you very much for taking the time to respond and explain a bit more to connect the dots for me. I didn’t notice the built-in @AMRRON group name nestled in the rest of the special purpose groups. I definitely don’t appreciate their inclusion, since it is tacit approval of the group, as you alluded to.
Yeah, the FCC document definitely made the potential to leave relaying enabled iffy. I really wish I was a better coder, or I’d fork the code, remove the @AMRRON group and pop up a prompt of whether to allow a relayed message, or only allow to/from trusted parties.
Thanks for elaborating! Is there a greater discussion on this topic somewhere?
I also wanted to add that I will probably never relay communications unless it’s for a friend. I’ll run fully encrypted Tor middle nodes (I like to promote privacy), but anything else is like running a Tor exit node… I’d never touch that without going through a corporate entity and having a lawyer on retainer.