开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. BITX20
  2. Topics

sBitx v3 - problem with nonstandard callsigns

 

I've been using my sBitx v3 for one and a half months and am pretty happy with it. However, I noticed strange behavior.
When I try to start QSO with a station that uses nonstandard callsign (e.g., longer than usual or prefixed or suffixed with something), its callsign is displayed as <...>. The same "<...>" is output to the log. This form seems to be used even in responses, so the recipient does not accept them, and the QSO gets broken.
Up to now, I'm simply limiting my QSOs to the stations with standard callsigns.?
However, spring and summer approach, and I hope to use my site v3 in SOTA and POTA activities or use it during my holidays abroad.
In those cases, my callsign will need to be suffixed (e.g., with "/P") or prefixed (e.g., with "OE/" when in ?sterreich).
Is my sBitx v3 going to handle that situation properly, or I won't be able to make any QSO?
How can I fix that issue?
?
73,
Wojtek SP5DAA
?
?
 

开云体育

Yep it’s a known problem with ft8_lib. ?I was trying to hack on that a few months ago:??
It wasn’t complete enough to work yet; so I guess I should get back to it soon, or maybe someone else will.

But I see the issue got another patch, so I can test that soon: ?https://github.com/kgoba/ft8_lib/issues/44

I will have the same problem, wanting to use either the sbitx or zbitx when traveling, so I’d also like to have it fixed in time for summer.

You can use wsjt-x rather than the built-in FT8 mode in the meantime, if you don’t want to help with the changes.

On Mar 7, 2025, at 02:38, WZab - SP5DAA via groups.io <wzab01@...> wrote:

I've been using my sBitx v3 for one and a half months and am pretty happy with it. However, I noticed strange behavior.
When I try to start QSO with a station that uses nonstandard callsign (e.g., longer than usual or prefixed or suffixed with something), its callsign is displayed as <...>. The same "<...>" is output to the log. This form seems to be used even in responses, so the recipient does not accept them, and the QSO gets broken.
Up to now, I'm simply limiting my QSOs to the stations with standard callsigns.?
However, spring and summer approach, and I hope to use my site v3 in SOTA and POTA activities or use it during my holidays abroad.
In those cases, my callsign will need to be suffixed (e.g., with "/P") or prefixed (e.g., with "OE/" when in ?sterreich).
Is my sBitx v3 going to handle that situation properly, or I won't be able to make any QSO?
How can I fix that issue?
?
73,
Wojtek SP5DAA
 



This problem is due to the ft8 library used in the sBitx software. This was already brought up by Shawn, K7IHZ, in this thread:
?
You can migrate to the 64bit version from JJ and team, and to use WSJTX/JTDX application for FT8 and use the screen scaler tool in the toolbox to resize the screen to fit the 7inch display.

Hope this helps
?
73,
Ragav
 

I use WSJT-X on the sBitx. The screen scaler leaves me with text that is too small to read and you can't see the bottom of the WSJT-X window unless you use the X-Large setting.
Fortunately the screen resizer scrolling window still works perfectly with WSJT-X.
--
73
??? Bob? KD8CGH
 

开云体育



On Mar 7, 2025, at 07:28, Shawn Rutledge K7IHZ / LB2JK <social@...> wrote:

But I see the issue got another patch, so I can test that soon: ?

I just tried gdyuldin’s fork: ? It looks promising: I can receive longer callsigns, can send with a suffix (LB2JK/QRP), and on pskreporter I can see that my packets get received successfully (at least sending my callsign with a suffix seems ok). ?But so far I didn’t get a successful QSO with a prefixed or suffixed callsign. ?

I just had to retune the dipole after trying that and seeing somewhat high SWR; not sure why the resonant frequency went up from where it was in the recent past, so had to add a couple cm to both ends by making some quick-connect “extensions” that I can plug on when necessary:

dipole-extensions.jpg

Got SWR down to 1.2 on 20m now, and that makes a difference in transmit power too: it goes up to about 15W max, instead of only 11 or 12. ?I’m not quite sure how to tell when I’m overdriving audio; the built-in FT8 mode generates a yellow “scope trace” that goes outside the pane (so it looks flat on top and wavy on the bottom), and if I have resized the window, then it leaves “droppings” after the transmission is done. I guess it’s supposed to be ok, since that’s how it shipped (and I still don’t understand where is that setting: the volume on some particular ALSA device or what. ?Can’t continue with trying pat until I figure out how to control ardop's crazy-large audio output. ?With that modem, the waveform gets so big that it just about fills the window.)

Anyway: I got some QSOs with normal callsigns (to prove the library isn’t totally broken). ?But just now I was monitoring FT8 with a nearby kiwisdr (since I don’t have a second rig to monitor my own transmissions), and I saw

LB2J <OH2NP/60> +14

The last letter of my callsign is truncated, while I was trying to call another callsign with a suffix (60th anniversary of a Finnish club apparently). So maybe there is at least one bug in that fork; on the other hand, guess which library the kiwisdr software is using? ?;-) ?yep, ft8_lib… so I can’t necessarily trust a kiwi to decode such callsigns anyway. ?(Or is there another fork for that? I do see some suffixed callsigns in the kiwi's log. ?How did they do that?) ?So I should probably be testing encoding and decoding wav files, instead of transmitting with a bad callsign. ?Or when the zbitx gets here, if Farhan releases the software right away, I can recompile it with the alternate ft8_lib, and use dummy loads, which ought to radiate enough for local testing, without getting out far.?

So there is hope, it just needs more work.

Screenshots:

prefix-suffix-attempt1.png

prefix-suffix-attempt2.png
 

Hi Shawn,
Those who seek will find. I looked into the linked website and Georgy published his modifications two months ago.
For coders, this can be a call to attention for modifications, since sbitx is also based on kgoba coding.
Please write about your experiences so that someone on JJ discord will pay attention to the topic.
--
Gyula HA3HZ
 

Yes, that’s what I was testing today, and just wrote about.

On Mar 7, 2025, at 16:39, HA3HZ <gyula@...> wrote:

Hi Shawn,
Those who seek will find. I looked into the linked website and Georgy published his modifications two months ago.
For coders, this can be a call to attention for modifications, since sbitx is also based on kgoba coding.
Please write about your experiences so that someone on JJ discord will pay attention to the topic.
 

On Fri, Mar 7, 2025 at 05:14 PM, Shawn Rutledge K7IHZ / LB2JK wrote:
Yes, that’s what I was testing today, and just wrote about.
Sorry, I think I worded it wrong. I ask that you write about your experiences with this complex callsign problem on the Discord JJ page and that there is a solution to fix the problem, because you found the github page where it is described.
When I first experienced this problem, I searched a lot to see how others were doing it. Since I couldn't find anything other than using an external program, I'm keeping quiet because that's how it works. If a coder sees the solution, they'll probably incorporate it into the code they're currently using. I think that if more people speak up on this topic, then change will happen.
--
Gyula HA3HZ
 

I have cloned and added my suffixed callsigns to the test: OE/SP5DAA, DE/SP5DAA, SP5DAA/2, SP5DAA/P (in ft8_lib/test/test.c)
Only SP5DAA/P is encoded and decoded correctly. Three others fail.
?
Below is one of the test cases:
Encoded [YL3JG] [DE/SP5DAA] [KO26]
Decoded [YL3JG] [<DE/SP5DAA>] [KO26]
FAIL: Condition '0 == strcmp(call_de, call_de_tx)' failed!
Encoded [YL3JG] [OE/SP5DAA] [KO26]
Decoded [YL3JG] [<OE/SP5DAA>] [KO26]
FAIL: Condition '0 == strcmp(call_de, call_de_tx)' failed!
Encoded [YL3JG] [SP5DAA/P] [KO26]
Decoded [YL3JG] [SP5DAA/P] [KO26]
Test OK
Encoded [YL3JG] [SP5DAA/2] [KO26]
Decoded [YL3JG] [<SP5DAA/2>] [KO26]
FAIL: Condition '0 == strcmp(call_de, call_de_tx)' failed!
?
?
Another case:
Encoded [DE/SP5DAA] [YL3JG] [KO26]
Decoded [<DE/SP5DAA>] [YL3JG] [KO26]
FAIL: Condition '0 == strcmp(call_to, call_to_tx)' failed!
Encoded [DE/SP5DAA] [W1A] [KO26]
Decoded [<DE/SP5DAA>] [W1A] [KO26]
FAIL: Condition '0 == strcmp(call_to, call_to_tx)' failed!
Encoded [DE/SP5DAA] [W1A/R] [KO26]
Decoded [<DE/SP5DAA>] [W1A/R] [KO26]
FAIL: Condition '0 == strcmp(call_to, call_to_tx)' failed!
Encoded [DE/SP5DAA] [W5AB] [KO26]
So it seems that this fix still does not remove the problem, especially for those travelling abroad.
?
73,
Wojtek

1 - 9 of 9