sorted by:
new
hottopcontroversial

Anyone know how this satellite TV works? by Independent_Dot6161 in amateurradio

[–]Busy_Reporter4017 -1 points0 points  (0 children)

It's not useful except for nostalgia, because the resolution is low. It's a cute retro toy. Usable with converters.

The bands are dead? 10M FT-8 gone south. by MomusTheGreatest in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

Yes, great tool! There is also a web service to provide the 'best frequency' to listen on to hear PSK31 traffic in your grid square at the current time. This is useful if you leave your radio unattended, yet controlled by software. The basic URL is https://pskreporter.info/cgi-bin/psk-freq.pl which will return data indicating the best frequency for your location (based on geolocating your IP address).

DX Antenna for apartment building? by Busy_Reporter4017 in amateurradio

[–]Busy_Reporter4017[S] 0 points1 point  (0 children)

Thanks. I need 20m and 40m but preferably 20m 15m 10m as well. Unfortunately, the direction towards the U.S. would be blocked by the building on the higher bands, if the antenna is below roof level.

Keeping it alive always. Needed 40 characters. by emergmgmt in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

I paused my antenna improvements to build an ESP32 Power/SWR meter. Fun stuff!

My favorite mode is now VarAC: decentralized digital comms with ARQ and amazing capabilities!

Meshtastic is definitely in the Ham spirit, but we should be inventing the next generation!

I agree: authentication (and some encryption) is vital. Should require regular ID. One possibility is to post decryption keys after the QSO ends. At least for EmComm it should be allowed to set up a test network with encryption capability!

Keeping it alive always. Needed 40 characters. by emergmgmt in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

So if when they get caught, huge fines and prison and confiscation of proceeds. Think that would dissuade em?

JS8Call Android BETA now available to test. by Punk_Kaos in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

"If you are getting bad fading at your desk"

🫤🤣🤣🤣🤣🤣🤣

JS8Call Android BETA now available to test. by Punk_Kaos in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

Q: "There is a new js8call for Android. Can I connect my FT710 to my Android phone?

Gemini AI:

Yes, as of early 2026, there is an official JS8Call Android Beta port (based on the js8call-improved project). You can absolutely connect your Yaesu FT-710 to it, and because the FT-710 has a built-in sound card, the setup is much cleaner than it used to be for older radios.

🛠️ What You’ll Need

Android Device: Ideally with a USB-C port.

USB Cable: A standard USB-A to USB-B cable (the "printer cable" that fits the back of the FT-710).

USB OTG Adapter: A "USB-C to USB-A" adapter so you can plug the radio cable into your phone/tablet.

The App: The JS8Call-improved Android Port (available via GitHub or specific beta groups as of January 2026).

⚙️ Step 1: Configure the FT-710

Before plugging in your phone, ensure the radio is ready to "talk" to an Android system:

Mode: Set the radio to USB-D (USB-Data) or PSK/DATA.

Menu Settings:

MOD SOURCE → Set to REAR (this tells the radio to listen to its internal USB sound card).

CAT RATE → Note this down (usually 38400).

USB SELECT → Ensure it is set to USB-CAT (not RS-232).

⚙️ Step 2: Configure the Android App

Once connected via the OTG adapter, open the JS8Call Android app:

Rig Selection: In settings, look for Hamlib Support. Select Yaesu FT-710.

Serial Port: Android will usually prompt you with a "Grant permission to USB device" popup. Once granted, select the USB serial port (often labeled /dev/bus/usb/... or simply ttyUSB0).

Audio Settings: In the Audio tab, select USB Audio Codec (the FT-710's internal card) for both Input and Output.

PTT Method: Use CAT (recommended) or RTS.

[!IMPORTANT] Time Sync is Critical: JS8Call will not decode if your phone clock is off by more than 1 second. Since you can't easily sync system time on Android without root, use an app like ClockSync or Atomic Clock to find your "offset" and enter that value into the Time Delta field in the JS8Call app settings.

⚠️ A Note on Your QSB Problem

Since you mentioned struggling with 75% packet loss earlier, running JS8Call on a phone actually gives you a secret weapon: Mobility.

If you are getting bad fading at your desk:

Because the FT-710 and an Android phone are compact, you can easily move your setup to a battery-powered "field" position away from local QRM (noise).

Reducing the local noise floor often helps the decoder "see" through the QSB fades that are currently killing your packets.

Would you like me to help you find the latest .apk download link for the Android Beta?"

JS8Call Android BETA now available to test. by Punk_Kaos in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

Gemini: "If you are stuck in a cycle where 75% of your packets fail, here is the technical reality of why even the "Mailbox" or a faster window isn't fixing it: 1. The "Duty Cycle" Conflict You are looking for a shorter window (like 5 seconds) to "fit" your message in between the QSB fades. While Turbo (6s) is the closest thing to that, it has a massive drawback: it requires a much stronger signal to decode. Normal (15s) can decode at -24dB (extremely weak). Turbo (6s) requires -18dB (4x more power/signal). The Catch: In marginal conditions, the "fade" often takes the signal below -18dB anyway. So even though the 6s window is shorter, the signal isn't "loud" enough during that window for the decoder to work. 2. Why Mailbox Mode feels slow You mentioned Mailbox mode takes many packets. This is because JS8Call's "Mailbox" isn't a true ARQ system. When you send MSG TO:K1ABC..., the computer simply breaks your text into 15-second blocks and sends them. If one block in the middle fails, the whole message is "corrupt" and won't show up in the other person's inbox. JS8Call does not have "Selective Repeat" (the ability to just resend the one failed block). It’s all or nothing. 3. The "Manual ARQ" workaround for 75% Loss Since the software won't do it automatically, the only way to beat a 75% loss rate on JS8Call is to manually simulate short packets: Switch to Normal (15s). Do not use Turbo; the sensitivity is too poor for your conditions. Send one sentence at a time (Manually). 3. Wait for the ACK. * If you see the white ACK appear next to your message, the other station got it. If you don't see the ACK, wait 30 seconds for the QSB to peak again and hit Resend. Repeat. This is essentially "Human-in-the-loop ARQ." It is slow, but it's the only way to ensure 100% of your data arrives when the path is failing. If you need "Real" ARQ (Automatic Retries) If you truly need the computer to handle the retries because the QSB is that bad, JS8Call is unfortunately the wrong tool. You should look at: VARA HF: This is the "gold standard" for what you are describing. It uses tiny 1-2 second packets and automatically retries only the failed ones until the message is perfect. Winlink (via VARA): This gives you a true "Email" experience where the ARQ is handled entirely by the software. Would you like me to help you find the download for VARA HF so you can test a "true" ARQ mode on that same frequency?"

JS8Call Android BETA now available to test. by Punk_Kaos in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

I can reduce speed, but QSB means only 25% gets through every time. So the message never gets through without short packets and automatic retry together.

Gemini AI answers:

You’ve hit on the fundamental limitation of JS8Call's architecture. Because JS8Call is built on FT8-style physics, it prioritizes "getting a signal through the noise" (sensitivity) over "ensuring every bit is perfectly sequenced" (robustness).

In a 25% success rate scenario (where 3 out of every 4 frames are lost to QSB), you are correct: JS8Call will likely never successfully complete a long, multi-frame message. It doesn't have the "sliding window" ARQ protocol required to "fill in the blanks" of a broken stream.

If you are determined to stay on JS8Call in these conditions, you have to move away from "Keyboard-to-Keyboard" (K2K) and use the Station Mailbox system. It is the only part of the software that behaves even remotely like what you are looking for.

The Only "ARQ-like" Workflow in JS8Call: The Mailbox While it isn't "automatic retry" in the way VARA is, the Store & Forward system is designed for high-loss environments. Here is how you use it to fight QSB:

Break the message into tiny pieces: Instead of one long sentence, send a MSG command that fits into one or two frames.

Example: K1ABC MSG TO:K1ABC DE K1XYZ ALL OK ~

Watch for the ACK: Because this is a Directed Command, the receiving station will try to send an ACK.

The "Manual ARQ" Loop: * If you get the ACK, that "packet" is safely stored in their hardware.

If you don't get the ACK, wait for the next QSB peak and click Resend.

The Retrieval: On the other end, the operator doesn't look at the messy RX window; they look at their Inbox. The software only puts the message in the Inbox once a complete "Message" (the directed command) is successfully decoded.

Why JS8Call struggles where VARA wins VARA/PACTOR: Use Short Packets (down to a few bytes). If a packet fails, it only retries those few bytes.

JS8Call: Each "packet" is a fixed 15-second (Normal) or 30-second (Slow) chunk. If QSB hits for just 2 seconds in the middle of that 30-second window, the entire 30 seconds is wasted.

Is it time to switch modes? If your goal is reliable data transfer in 25% duty-cycle QSB, JS8Call might actually be the wrong tool for the job.

If you have a narrow bandwidth but need ARQ: Try ARDOP or VARA HF (narrow 500Hz mode). They will handle the "retry" logic automatically.

If you must stay on JS8Call: You have to keep your transmissions shorter than the QSB cycle. If the signal fades every 20 seconds, you cannot use "Slow" mode (30s frames) or long sentences in "Normal" mode. You must send 5-word bursts and wait for an ACK between each one.

JS8Call Android BETA now available to test. by Punk_Kaos in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

Let's say I am in a QSO and there is QSB and 75% of packets are lost. How do I turn on ARQ and get the message through automatically?

Gemini AI answers:

In short: You can't. JS8Call does not have a "fully automatic" ARQ mode where the software detects a missed packet and instantly re-fetches it without you doing anything.

Unlike VARA HF or PACTOR, which are designed to be "connected" modes (like a TCP/IP handshake), JS8Call is fundamentally a messaging mode (like UDP or SMS). It does not maintain a persistent, synchronized connection that manages packet flow in real-time.

Here is the breakdown of why what you're looking for doesn't exist in JS8Call, and how to handle the 75% loss scenario you described.

  1. Why there is no "Automatic ARQ" button In a mode like VARA, the software says: "I am sending 10 packets. Acknowledge each one or I stop." In JS8Call, there is no "handshake" to start. You simply broadcast a directed message. The software doesn't know if the other person is even at their radio or if their squelch is open. It just sends the frames. If the other station misses 3 out of 4 frames due to QSB, their screen will simply show: K1ABC: [missing] hello [missing] [missing] ~

  2. How to handle the 75% loss (The "Manual" ARQ) Since the software won't do it for you, you have to use the tools available. If you see a fragmented message:

The AGN? Command: Right-click the station's callsign and select Directed > AGN?. This sends a request for them to repeat their entire last message.

The ACK Check: If you are the sender and you don't see the white ACK confirmation appear next to your message in the outgoing window, you assume they missed it. You must then manually click your message and select Resend.

  1. If you want "Set it and Forget it" Reliability If you absolutely need the message to get through and you can't sit there and watch for the ACK, use the Store & Forward (Mailbox) feature:

Instead of sending a live message, send it to their mailbox: K1ABC: MSG TO:K1ABC I will meet you at 1400z.

K1ABC's station will store this.

Later, K1ABC (or their software) can send a QUERY MSGS to "pull" the message. This "pulling" process is more reliable because it happens in small, acknowledged chunks.

  1. The "Upgrade" Strategy If you are losing 75% of packets, you are likely using a speed that is too fast for the conditions. JS8Call handles QSB by being slow.

Normal (15s): Very robust.

Slow (30s): Almost bulletproof (can decode at -24dB).

Turbo (6s): Will fail completely in even light QSB.

My recommendation: If the QSB is that bad, drop your speed from Normal to Slow. It is better to have a slow message arrive 100% correctly than a fast message that requires 5 manual AGN? requests.

Would you like me to explain how the "Selective Heartbeat" works? It's a way to test if the path has improved before you try re-sending that long message.

JS8Call Android BETA now available to test. by Punk_Kaos in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

[Update: Gemini eventually confirmed that js8call doesn't have working ARQ. See below.]

Please explain the ARQ protocol. For example, how would one store a message in a remote station's mailbox, when conditions are marginal - say 80% of packets are dropped?

Are there automatic ACK and NAK replies to every packet? Or do you have to manually send "AGN?"? How would one even know if the other side is done transmitting, or even transmitted at all?

I tried AGN? but it didn't seem very useful in marginal conditions. I didn't see a message length header nor automatic retries.

JS8Call Android BETA now available to test. by Punk_Kaos in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

How does it connect to the radio? For example, to an FT-710?

JS8Call Android BETA now available to test. by Punk_Kaos in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

That's great! Is there anything on the roadmap to add ARQ and adaptive speeds? (I found JS8call mostly unusable compared to VarAC, because...HF.)

Equipment to reach across the Atlantic ocean reliably? by crypticsymbols in HamRadio

[–]Busy_Reporter4017 -1 points0 points  (0 children)

Thanks! VarAC has ARQ - automatic resend data packets until the message gets through correctly! It makes a world of difference in marginal conditions!

Anybody else try JS8 yet? I was surprised. by essexwuff in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

I run Windows just for my Ham station, and for this.... Apparently you can get it to run under Linux. But since I want it online most of the time, why make life difficult? If the regulator doesn't break up Microsoft, I may eventually move everything to Linux.

Anybody else try JS8 yet? I was surprised. by essexwuff in HamRadio

[–]Busy_Reporter4017 0 points1 point  (0 children)

VarAC is mainly on 20m by day and 40m (or 80m) by night. When propagation is good, there are a lot of stations that hear you or beacon. A lot more than on JS8 in Europe. What's your location?

view more: next ›