Repository navigation
Replies: 10 comments
|
Incredible feedback and I appreciate the detail that went into this. I will get on these, these are all great. |
|
Two of these are done and shipped, and I owe you an apology for not coming back here to say so — both went out in 1.3.0 and you're credited by name in the release notes for them. Metric units. There's now a single Units setting under Settings ▸ Station: automatic from your system region, or metric/imperial by hand. It covers exactly the spots you listed — the station recall card, Memories, the repeater search and APRS weather — plus the roster distance column. Transmitted values stay native; only the display converts. DXCC and prefix filtering. Four pieces of it. The Countries menu gained an "Other country…" search over the full entity table, so it's no longer the common 18. There's a "Hide calls" control on Band Activity that takes callsigns or You're on 1.0.5, so none of that is in front of you yet. Worth upgrading. On the other two, straight answers rather than a maybe: Internationalisation is not planned for the next few releases. You're right that it's the real adoption barrier for a non-English operator, and you're right about the shape — first-run wizard, Settings, error messages first, with translation files the community can contribute to without touching code. It's the size of the job that's the problem, not the value of it. I'm not going to say "soon" and have you waiting on it. If it starts, I'll come back here, and I'll take you up on the French. FT2 isn't supported and isn't queued. Adding a mode is a decode chain, a TX chain, timing and a tier of its own, so it only makes sense if there are operators to work — right now there aren't many on it. If that changes, it gets revisited. Leaving this open — half of it is still live. 73 |
|
Taking these one at a time, and thank you for the care in the write-up — the specificity is what makes it actionable. Metric units — done. There is now a single Units setting: auto, metric or imperial. Auto follows your OS locale and only picks imperial for the three countries that use it, so a French install is metric without touching anything. The places you listed were exactly the ones still hard-coded, and they went in with it. Internationalisation. This is the honest one. You are right that it is the real barrier, and right that it is a large job on a codebase this size — every string is currently in the source. It is not something I can promise soon, and I would rather say that than put it on a roadmap and have it sit there for a year. If it happens, your phased order is the correct one: first-run wizard, then Settings, then error messages, because that is where a new operator actually gets stuck. I will come back to you on French rather than forget the offer. DXCC filtering and FT2 are separate asks and smaller than the above. Both worth doing; neither is in the next release. Leaving this open — it is the most useful single piece of feedback the project has had from outside the English-speaking side, and I would rather it stayed findable. 73 |
|
Hello, Thank you for these replies, and above all for what you did with them. I came to install the 1.3.0 you told me about. I landed on the releases page and found 1.6.0. You have been faster than me: I did not get the time to test 1.3.0 before 1.6.0 was already there. That is a problem I wish every project had. Units first. A single setting with automatic region detection is exactly the right answer, and it covers the four places I had listed. On a French install there is nothing left to touch. Filtering next. Search over the full DXCC table, hiding by callsign or prefix, the Pause switch, and above all a block list that survives a restart: that was my specific complaint, and it is fixed. Thank you also for the mention in the release notes, I was not expecting that at all. And then FT2. On the 15th you wrote that it was neither supported nor queued. On the 16th it is in 1.6.0. I read the dates twice. One word of caution on that, and not a complaint. There are currently two modes called FT2 that cannot decode each other: Decodium's, IU8LMC, which is the one you implemented and the one I had in mind when I made the request, and WSJT-X Improved's, DG2YCB, written independently. According to IU8LMC they differ in tone count, symbol timing, synchronisation and LDPC parameters. So the incompatibility is structural, not a matter of settings. In practice, I will have Nexus 1.6.0 on one side of my laptop and WSJT-X Improved 3.1.0 on the other: both will display FT2 and neither will hear the other. And since ADIF took only one FT2 in February, both log the same way, with nothing to say which implementation was on the far end. I have no solution to offer, and it plays out above Nexus anyway. I would simply rather you knew: if users report that they cannot decode a given station on FT2, the cause may well be there rather than in your code. On internationalisation, thank you for answering straight rather than keeping me waiting. A clear answer is worth more than a roadmap line that does not move for a year. My offer for French stands, with no expiry date: the day the mechanism exists, I am there. I am going portable next week and will finally have the time to put all of this through its paces properly, as F4MQS/P. I am looking forward to it. I will send you field feedback when I am back, on FT2 as well as on the rest. Congratulations again on the pace. Three of my four requests delivered in under a week is not common. 73, F4MQS — Niko |
|
Noted on the two FT2s, and thank you — that's the kind of thing better heard before the support reports arrive. Nexus's FT2 is Decodium's (IU8LMC): built from their modem sources, on their band plan, so a WSJT-X Improved station won't interdecode with us and I'll keep that in mind when someone says FT2 "doesn't hear". Have a good trip out portable — field reports as F4MQS/P very welcome. 73 |
|
Coming back to correct something I told you here. Twice in this thread I said translations were not planned for the next few releases. That was true when I said it and it is not true now — Nexus ships translated, and French is one of the languages in it. You were told to stop waiting, and you should not have been. Your offer to go through the French wording is still open as far as I am concerned, and I would genuinely like to take you up on it. A translation done by someone who actually operates in the language beats one that is merely correct. The strings live in the repo and I can point you straight at the French file if you want to read through it. The other three from your original list are all in as well — metric units, DXCC and prefix filtering, and FT2. Your warning about the FT2 forks not being able to decode each other while ADIF only has the one mode name is a good one, and I have kept it. It will be the first thing I reach for when somebody reports that FT2 will not hear them. 73 |
|
Coming back to close the loop on the i18n part of your list, since I corrected myself in this thread once already and owe you the follow-up. French is shipped. It went out in 1.9.0 alongside Spanish — the whole application, every screen, the same coverage German has, picked up automatically from your system language or selectable in Settings. When you first wrote I told you translations were not planned for the next few releases. That was wrong when I said it, and I corrected it later in this thread; this is the part where it actually arrived. Of the four things in your original write-up, metric units and the DXCC filtering shipped earlier, French is now done, and FT2 is the one still carrying the caveat I gave you about whose decoder it is. Thank you for the write-up. It was specific enough to act on line by line, which is rarer than it should be. 73 |
|
Closing the loop on the whole list, since parts of it have been waiting since August. The four you opened with are all shipped: metric units and the DXCC and prefix filtering in Of the three bugs further down your write-up, two are done and one is half done. The ClubLog retry hammering is fixed, in 1.3.0. It backs off now instead of pushing every couple The HRD queue is fixed, in 1.3.0. With HRD closed the contacts queue and go out when it comes The portable callsign warning is the half-done one. It exists — it spots F4MQS/P against an I'm keeping this open until those two have tickets of their own so they don't get buried in a |
|
Niko — you asked a month ago whether to split these up and I never answered. No, Two things from your write-up are still live. An upload that keeps failing is Both are now tracked: #290 for the silent drop and the missing catch-up, #291 for The rest landed: metric units and the DXCC filter in 1.3.0, FT2 in 1.6.0, French |
|
F4MQS, the last two from your list are done. Since 1.13.0 the portable-callsign check runs on every QRZ and eQSL upload and warns in the Connections log when a /P call goes to a base-call logbook, and since 1.14.0 any contact a service gives up on is named there. 1.15.0 adds the catch-up: saving your QRZ Logbook API key or your eQSL password re-queues every contact that service never took, the way ClubLog always has. That covers everything in your original post. 73 |
|
Hello
Thank you for clarifying that.
Due to some personal issues, I haven’t been able to carry out my tests on
my mobile and therefore provide you with feedback.
I can see that version updates are coming thick and fast, which shows that
the community is responsive – it’s a sign that the product is well-liked,
and I agree.
All that remains is for me to find the time to update and continue my tests
so I can provide you with feedback, but the end of the year is very busy at
work.
Even if I’m quiet, I’m keeping an eye on your project, which I really like.
73 from F4MQS
Translated with DeepL.com (free version)
Le dim. 27 sept. 2026 à 04:47, HamRadioTools ***@***.***> a
écrit :
… F4MQS, the last two from your list are done. Since 1.13.0 the
portable-callsign check runs on every QRZ and eQSL upload and warns in the
Connections log when a /P call goes to a base-call logbook, and since
1.14.0 any contact a service gives up on is named there. 1.15.0 adds the
catch-up: saving your QRZ Logbook API key or your eQSL password re-queues
every contact that service never took, the way ClubLog always has. That
covers everything in your original post. 73
—
Reply to this email directly, view it on GitHub
<#58?email_source=notifications&email_token=BX5TORURVJCTXVYVUXTMY6L5RB5VHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGIYDCNRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18620163>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BX5TORVCM7UWGWRNCAU7QLD5RB5VHAVCNFSNUABJKJSXA33TNF2G64TZHMYTGMBUGU2TANJWGE5UI2LTMN2XG43JN5XDWMJQGU4DONZYGOQXMAQ>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/BX5TORTTLU7HFHREPW3EV6T5RB5VHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGIYDCNRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM>
and Android
<https://github.com/notifications/mobile/android/BX5TORT2IWWDBIIDSFIJJID5RB5VHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGIYDCNRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Uh oh!
There was an error while loading. Please reload this page.
`Hello,
I have been running Nexus for a few days now (1.0.5, Windows 11, Yaesu FT-710 over Hamlib) and my first tests are positive. FT8 decoding is good, CAT is stable, and the idea of finally having everything in a single tool is what made me try it: today I juggle four or five programs to do what Nexus does in one window. Congratulations on the work, and on how honest the documentation is — it says plainly what works and what does not yet.
I log to HRD Logbook, which stays my master log and handles my uploads to LoTW, eQSL and QRZ. The HRD connector in 1.0.5 (QSO Forwarding on 2333) works perfectly here: the contact lands in HRD within a second. That is exactly the setup I was after.
Below are four requests, in my order of priority, followed by some field feedback.
1. Internationalisation (multi-language support)
This is my main request. Nexus is currently English-only, with every string hard-coded in the source. For a non-English-speaking operator, that is the real barrier to adoption — far more than any missing feature.
I would suggest standard translation files, for example .po / .mo (gettext), or any equivalent format that lets users contribute their language without touching the code. That is the model most amateur radio software uses, and it works: the community supplies translations for free as soon as the mechanism exists.
I volunteer for the French translation as soon as the infrastructure is in place.
I realise this is a large undertaking on a codebase this size. If a phased approach is more realistic, the priority screens would be the first-run wizard, Settings, and error messages — that is where the language barrier costs a new user the most.
2. Metric units (km, °C)
Nexus already shows the vast majority of distances in kilometres (Connect map, opening detector, Getting Out, APRS, satellites, spots), which is perfect. But a few places are still imperial:
mi)mi)A single global Units: metric / imperial setting would cover all of it, and since the app is already mostly in km, the current inconsistency is probably easier to fix than to keep. Ideally the default could follow the operating system locale.
3. Filtering by DXCC entity or prefix
There is currently no way to permanently hide certain callsigns. The decode filters are a fixed list (All / CQ / CQ+73 / To me / On RX / B4 / New), and Alt+double-click ignore only dims the row, on top of being lost at restart.
I would like to be able to exclude one or more DXCC entities, or a list of prefixes, from the display, persistently. There are many uses: focusing on one continent, hiding entities already confirmed on a band, cutting the noise from a very active area, or simply an operator's own preference.
JTDX offers this filtering and it is one of the reasons many operators stay there. Technically, Nexus already resolves the DXCC entity of every decode in order to show the country and the badges: the data is there, only the downstream filter is missing. An exclusion list persisted in Settings, with a quick toggle in the cockpit, would cover the need.
4. Additional modes, starting with FT2
Nexus already covers a lot of modes, which is remarkable. I would like to see FT2 added — the fast mode developed by IU8LMC: 3.8 s cycles, a complete QSO in around ten seconds, same codec as FT8 and FT4. It has been adopted as a certified submode in ADIF 3.1.7, other software is starting to decode it, and it shares most of the processing Nexus already carries.
More broadly, every additional mode serves the "one tool" promise that is Nexus's real strength. If other operators have mode requests, they could perhaps be gathered in a single discussion to set priorities.
Field feedback (found during my tests)
These three points are minor but easy to fix, and they cost me time.
ClubLog: retry loop, then no recovery. On my first QSO, the ClubLog application password was not yet stored. Nexus then attempted the upload about twenty times in a row, once every two seconds, with the same error each time. Exponential backoff would be preferable. More importantly, once the password was stored, no automatic retry happened: the QSO simply stayed un-uploaded with nothing to flag it. A "retry failed uploads" button, or a retry queue, would prevent contacts from being lost.
Portable callsigns and online connectors. I operate as F4MQS/P. QRZ rejected my QSO with an unhelpful message ("QRZ Internal Error: Unable to add QSO to database"), because a QRZ logbook serves exactly one callsign, suffix included — the /P variant needs its own logbook. eQSL works the same way. A warning in the UI when the callsign carries a suffix and auto-upload is enabled would save portable operators a lot of time. And if QRZ's raw error could be accompanied by a plain-language explanation, better still.
HRD connector: queue when HRD is closed. The push to HRD Logbook requires HRD to be running at the moment of the QSO. If HRD is closed, the contact never leaves and stays only in the local log, with no visible warning. Queueing QSOs and sending them on reconnect — or at minimum showing an HRD link status indicator in the cockpit — would avoid manual ADIF re-imports.
Thanks again for this software and for the pace at which you are developing it. I am continuing my tests portable and will report anything I find. If you would rather I split these into separate tickets, just say so and I will gladly do that.
73,
F4MQS — Niko
Reims, France
`
All reactions