¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Linuxham
  2. Messages
Expanded Topics Messages Polls
Date
Re: fldigi fights with frequency changes from radio or API

 

OK.? AFICR, no other software other than the Flsuite was mentioned originally.

Could you list *All* the software you wish to use together, and details of the OS running it all.

Especially version numbers, for all software items you wish to run together.

That will help a lot.

I know nothing to little about Apple Mac's and their software, but I do know others on this list do know that stuff.

All the best.

Dave G0WBX.
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

I don't think my first reply worked, sorry if this is a duplicate.
?
Originally I was using whatever version came pre installed on DragonOS, 1.4.something. last night I installed 2.0.04 and I had the same issue on both versions.
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

That's what I'm trying to get to. I want to get the radio communicating with flrig, and then I will communicate through flrig to each other program.
?
To my knowledge the radio will not power on over CAT, there is a latching button on the radio that is pressed to turn it on and off.
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

WSJT-X uses hamlib and one of the "radios" is flrig. I use flrig as a concentrator. WSJT-X, FLdigi and my logger all connect to my rigs through flrig. Phil

Does the Yaesu have the capability of being powered on using the CAT interface?

Phil GM3ZZA



On 15 November 2024, at 19:25, "Riley Gossling, KF0QMQ via groups.io" <rjayg1979@...> wrote:


Yes, I believe WSJT-X uses Hamlib.
?
Getting flrig to work is what I'm trying to do. I cannot get it to communicate with my radio.
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

Yes, I believe WSJT-X uses Hamlib.
?
Getting flrig to work is what I'm trying to do. I cannot get it to communicate with my radio.
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

Doesn¡¯t WSJT- X uses hamlib? Will Flrig work?
Ray
W8LYJ
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

I don't recall the different orders of operations I've tried, I will have to go back and try a more methodical approach.
?
I have not tried interfacing flrig with wstj-x, I am first trying to get flrig working with my radio.
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

Riley

I use flrig with an FT857. and I find connecting a tad finicky.?

Have you tried to start flrig, then the FT747?

FT747 on and then?flrig?started? then ft747 off/on?

For me it seems like different?methods work at different?times.?

I keep?my Ubuntu PC up 24/7 for months, once I do connect I keep the rig on for a long time and it stays connected.

Have you tried FLrig with WSJTX? That is start FLrig, start wsjtx and set rig as flrig.?

It's worked for me , I dont recall if connection?is finicky.?

Thanks Dan KC2STA











On Fri, Nov 15, 2024 at 10:58?AM Riley Gossling, KF0QMQ via <rjayg1979=[email protected]> wrote:

Thanks for the reply. I am a part of that group and have no issues communicating with the radio through the digirig using JS8Call or WSJT-X?



--
Dan Ziolkowski KC2STA
SKCC #4290T
Ubuntu LINUX
Re: fldigi fights with frequency changes from radio or API

 

On 15/11/2024 17:47, Arek M., SP2AM via groups.io wrote:

Anyway disabling "Tune to Rx Spot" and the problem went away.
That was too fast. No - it doesn't make it go away.

Added:

diff --git a/src/logbook/maclogger.cxx b/src/logbook/maclogger.cxx
index 1947a21b..087a3654 100644
--- a/src/logbook/maclogger.cxx
+++ b/src/logbook/maclogger.cxx
@@ -125,6 +125,8 @@ void maclogger_set_qsy()
unsigned long long hz = mclg_rxhz;
if (hz <= 0 || !progdefaults.maclogger_spot_rx) hz = mclg_txhz;
if (hz <= 0) return;
+ printf("progdefaults.maclogger_spot_rx %d\n", progdefaults.maclogger_spot_rx);
+ printf("mclg_txhz = %llu, maclogger_set_qsy: %llu\n", mclg_txhz, hz);
sendFreq(hz);
wf->rfcarrier(hz);
wf->movetocenter();

changing freq on radio and:

progdefaults.maclogger_spot_rx 0
mclg_txhz = 7245000, maclogger_set_qsy: 7245000
progdefaults.maclogger_spot_rx 0
mclg_txhz = 7247280, maclogger_set_qsy: 7247280
progdefaults.maclogger_spot_rx 0
mclg_txhz = 7249560, maclogger_set_qsy: 7249560
progdefaults.maclogger_spot_rx 0
mclg_txhz = 7254380, maclogger_set_qsy: 7254380
progdefaults.maclogger_spot_rx 0
mclg_txhz = 7254380, maclogger_set_qsy: 7254380
progdefaults.maclogger_spot_rx 0
mclg_txhz = 7255740, maclogger_set_qsy: 7255740
progdefaults.maclogger_spot_rx 0
mclg_txhz = 7256960, maclogger_set_qsy: 7256960


so it does sendFreq(hz) every short time. Just hz it has is sometimes old value (radio already has been set to new freq) which makes it tell flrig to go back to old freq.

Shouldn't it just do

maclogger_set_qsy() {
...
if (!progdefaults.maclogger_spot_rx)
return;

?

--
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )
Re: fldigi fights with frequency changes from radio or API

 

On 15/11/2024 17:13, Arek M., SP2AM via groups.io wrote:
If WITH FlRig and FlDigi running, and you change the frequency (or mode) at Flrig, does FlDigi follow those changes.
When changing frequency on flrig then fldigi tries to follow but with the same "revert" problem, sometimes, as when changing frequency on radio.
Tracked it down.

Frequency was being changed in maclogger_set_qsy().

I had "Tune to Rx Spot" turned on and fldigi reacted on:

[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]
[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]
[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]
[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]
[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]
[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]
[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]
[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]
[Radio Report:RxMHz:7.07968, TxMHz:7.07968, Band:40M, Mode:LSB, Power:100]

These look like a kind of "current status report" and not "spot" for me.

Anyway disabling "Tune to Rx Spot" and the problem went away.

--
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )
Re: fldigi fights with frequency changes from radio or API

 

On 15/11/2024 11:23, Dave, G?WBX via groups.io wrote:
Hi.
If you run Flrig alone, does Flrig "follow" what you do at the radio?
Yes. Flrig alone and:

- flrig frequency display follows frequency changes made at radio
- same for the other way - frequency changes made at flrig are applied to radio correctly
- changes made via flrig xmlrpc api are applied to radio correctly

flrig works reliably for me.

If it does, then something is wrong in how FlDigi, interacts with Flrig.
Fldigi should "follow" any changes at FlRig.
Ok, so I didn't miss any special option.


If WITH FlRig and FlDigi running, and you change the frequency (or mode) at Flrig, does FlDigi follow those changes.
When changing frequency on flrig then fldigi tries to follow but with the same "revert" problem, sometimes, as when changing frequency on radio.

I assume the radio follows FlRig.
Yes.

Debug log with rig i/o, server and client on:


- fldigi started with freq 14078100 being on its display
- (mouse) clicked *fldigi* third freq digit from right ("1") down, it changed frequency to 14078000, good, flrig follows, radio follows
- now started clicking fourth digit down on *flrig*
- one click -> fldigi went to 14077000
- second click -> fldigi went to 14076000
- and then fldigi went back itself to 14077000

Regards.
Dave G0WBX.

--
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )
Re: Linux Recommendation - Work is a RHEL/Windows Shop

 

¿ªÔÆÌåÓý

Joel,

any version of Linux is a good version of GNU/Linux, at least in someone's opinion. If your works is using RHEL, then Fedora has a lot in common. For the Broadcom drivers, you could also try liberating/borrowing/otherwise acquiring a USB-to-Ethernet adapter and using a good old wired network connection for the initial installation.

As an alternative, Ubuntu is more liberal with hardware drivers, and others have reported success, see .

HTH, 73, Robin, G8DQX

On 13/11/2024 10:16, Joel Black - W4JBB via groups.io wrote:

Based on the fact that work is a RHEL/Windows shop, I'm thinking I want to install Fedora Workstation on one of my old MacBook Airs - a 2015 model. While we are moving to on-prem containerization and it's coming fast, we are not there yet. Based on this, is my thinking sound in wanting to install Fedora Workstation or does the version of Linux matter if I just want to learn the CLI and scripting and building systems?

I don't know if it matters but I am taking a familiarization course on K8s.
?
I am currently playing around and live booting Fedora but I'm having a hard time with the Broadcom WIFI drivers on the MBA - I'm in a catch-22 situation in that I need a network connection to download drivers for a network connection. Does one download the drivers and "sneaker-net" them over to the MBA or do I just buy a to install the drivers and then stick the dongle in a drawer to save for later?
?
Regards,
Joel - W4JBB
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

Thanks for the reply. I am a part of that group and have no issues communicating with the radio through the digirig using JS8Call or WSJT-X?
Re: DigiRig, flrig, and a Yaesu FT-747GX

 

make sure you are a member?of "DIALOUT" group in Linuxkc?

Thanks Dan KC2STA


On Fri, Nov 15, 2024 at 8:43?AM Riley Gossling, KF0QMQ via <rjayg1979=[email protected]> wrote:

I have a Yaesu FT-747GX that I am able to successfully use CAT control with through JS8Call and WSJT-X through a DigiRig mobile.
?
I am trying to get it working with flrig, but am not having any luck. I choose my radio from the dropdown, set the correct serial port, and always get the "Transceiver not responding" message when I click "init," even when I launch flrig before anything else after turning the computer on.
?
Has anyone had any luck with this setup? Not sure if it's related, but I cannot get rig control with CubicSDR to work either.



--
Dan Ziolkowski KC2STA
SKCC #4290T
Ubuntu LINUX
DigiRig, flrig, and a Yaesu FT-747GX

 

I have a Yaesu FT-747GX that I am able to successfully use CAT control with through JS8Call and WSJT-X through a DigiRig mobile.
?
I am trying to get it working with flrig, but am not having any luck. I choose my radio from the dropdown, set the correct serial port, and always get the "Transceiver not responding" message when I click "init," even when I launch flrig before anything else after turning the computer on.
?
Has anyone had any luck with this setup? Not sure if it's related, but I cannot get rig control with CubicSDR to work either.
Re: fldigi fights with frequency changes from radio or API

 

¿ªÔÆÌåÓý

Hi.

If you run Flrig alone, does Flrig "follow" what you do at the radio?

If not, you need to find out why.? (Flrig settings, or Radio issue.)


If it does, then something is wrong in how FlDigi, interacts with Flrig.

Fldigi should "follow" any changes at FlRig.? If WITH FlRig and FlDigi running, and you change the frequency (or mode) at Flrig, does FlDigi follow those changes.? I assume the radio follows FlRig.


Regards.

Dave G0WBX.
fldigi fights with frequency changes from radio or API

 

Hello.

I'm new to flrig/fldigi, so this is probably something obvious but wasn't able to track it down.

fldigi 4.2.06 (also tried 4.2.06.05) on macbook pro m3 (macos sequoia), connected fo flrig 2.0.05. flrig drives FT-710.

As soon as I start fldigi it starts fighting with my changes to frequency and band made on the radio or via flrig xmlrpc API.

Like I'm changing frequency with radio knob and frequency gets reverted. Same for bands - changing band on radio and it gets switched back to previous. Same for frequency changes made with flrig API - these also get "reverted". If I keep changing frequency, despite reverts, eventually I'm able to get wanted frequency.

When I exit fldigi problem stops happening.

AFC is off for testing, RxID is off.

What else I should turn off?

I would like to be able to see frequency in fldigi (so polling should stay), change freq from fldigi by mouse clicks, use its AFC feature etc but also to be able to operate frequencies/bands from radio directly or via flrig xmlrpc API.

Thanks,
--
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )
Re: Question about fldigi submode logging / testing feedback on fldigi 4.2.06

 

¿ªÔÆÌåÓý

Thank you Gary.? Perhaps it is time for me to fultill the Apple Developer requirements.

David

On 11/13/24 15:23, Gary Rogers, KO3F via groups.io wrote:

Dave, I took the liberty of using my Apple Developer ID to re-sign Fldigi-4.2.06.05.dmg, sending it through the Apple notarization tool and stapling the approval to the app. This should permit MacOS 15 users to open and run the app without all the extra steps. Its in my dropbox here:



I¡¯m happy to help with signing and notarizing Fldigi apps for Mac going forward, if desired.


On Nov 13, 2024, at 3:38?PM, Barry, PC1K via groups.io <barry@...> wrote:

Thanks Phil,

Helpful background info, much appreciated!

73 de PC1K

On 13-11-2024 21:14, Philip Rose, GM3ZZA via??wrote:

I joined the ADIF community after the introduction of SUBMODE, version 3 I think. But from some of the discussion, I understand it was an attempt to get a handle on the growing proliferation of new modes. MODE was an attempt at being limited to modulation technique, and SUBMODE defining the coding.?

So modes like LSB became MODE=SSB, SUBMODE=LSB. And the digital modes similarly. At the time MODE=LSB became deprecated, and allowed to be imported from files created? by unmaintained legacy apps, but all apps being developed should export it as MODE=SSB, SUBMODE=LSB.?

With the new HELL modes, unfortunately there is no legacy mode to deprecate.?

The Mode change is still occasionally raises its head in the ADIF discussion forum. Most users want to see a single QSO field 'Mode'. And to that extent all SUBMODE values are unique as a 'recommended ' enumeration list. Any app can maintain a single field in its internal database as long as it gets exported as two fields.

It's a can of worms. For my logging app I accept both strict and deprecated values for the mode. And export strict.?

73 Phil GM3ZZA



On 13 November 2024, at 17:35, "Barry, PC1K via?"?<barry@...>?wrote:

Unfortunately just lost my Apple silicon mac last week.

>?but this change was forced upon us by the current ADIF

I know, because I started the discussion, my aim was to make logging more consistent. Before the change I have seen a FSKH105 QSO logged as HELL, FSKH105 and FSKHELL, this causes confirmations not to happen. In addition LoTW refuses to log FSKH105 (sometimes) as it is not ADIF compliant. This is being worked on in the next ADIF release.

When I look at the ADIF specification, it does not say one can use a submode in the mode field, this is how fldigi implemented it before, and funny enough is also what??does:

Exports as follows:

QRZLogbook download for pc1k
??? Date: Wed Nov 13 17:22:32 2024
??? Bookid: 354929
??? Records: 1
??? <ADIF_VER:5>3.1.1
????<PROGRAMID:10>QRZLogbook
????<PROGRAMVERSION:3>2.0
??? <eoh>
<time_on:4>1721
<my_lon:11>E004 12.400
<eqsl_qsl_sent:1>N
<app_qrzlog_status:1>N
...
<my_lat:11>N052 03.700
<cqz:2>14
<qso_date:8>20241113
<cont:2>EU
<freq:7>7.07498
<tx_pwr:2>20
<lotw_qsl_rcvd:1>N
<mode:7>FSKHELL?????? <- it is not ADIF compliant
<qsl_rcvd:1>N
<app_qrzlog_logid:10>1177766696
<dxcc:3>263
...
<band_rx:3>40m
<eor>


I wonder why submode was added to the ADIF standard??

A good fix for fldigi IMHO would be to also have submode in the logbook.adi and preferably in the UI. So I can still know if a QSO was made in FELD HELL or FSKHELL, because these modes have different characteristics. I don't need the submode to reflect in?, even though that would be nice. This we did not discuss before implementing the change in fldigi 4.2.06.


Maybe I made everything worse by starting the discussion, if the submode field is not implemented in many applications. In any case thanks for your help, fldigi is great!

73 de PC1K



On 13-11-2024 17:12, Dave, W1HKJ wrote:
I will look again at the code, but this change was forced upon us by the current ADIF specification.

David

On 11/12/24 22:08, Barry, PC1K via??wrote:
Hello,?

Today I got around to testing fldigi 4.2.06, specifically:?



With this patch, when I log a QSO in FSKH105, fldigi logs HELL in the mode field, which is correct.?

However the submode field, is not in logbook.adi, nor do I see it anywhere else in the UI. This means that all Hell contacts will be logged as HELL regardless of submode. Is there a way to configure fldigi so that it stores the submode to logbook.adi and preferably show the submode in the UI??

Thanks, Barry?











Re: Question about fldigi submode logging / testing feedback on fldigi 4.2.06

 

¿ªÔÆÌåÓý

Dave, I took the liberty of using my Apple Developer ID to re-sign Fldigi-4.2.06.05.dmg, sending it through the Apple notarization tool and stapling the approval to the app. This should permit MacOS 15 users to open and run the app without all the extra steps. Its in my dropbox here:



I¡¯m happy to help with signing and notarizing Fldigi apps for Mac going forward, if desired.


On Nov 13, 2024, at 3:38?PM, Barry, PC1K via groups.io <barry@...> wrote:

Thanks Phil,

Helpful background info, much appreciated!

73 de PC1K

On 13-11-2024 21:14, Philip Rose, GM3ZZA via??wrote:

I joined the ADIF community after the introduction of SUBMODE, version 3 I think. But from some of the discussion, I understand it was an attempt to get a handle on the growing proliferation of new modes. MODE was an attempt at being limited to modulation technique, and SUBMODE defining the coding.?

So modes like LSB became MODE=SSB, SUBMODE=LSB. And the digital modes similarly. At the time MODE=LSB became deprecated, and allowed to be imported from files created? by unmaintained legacy apps, but all apps being developed should export it as MODE=SSB, SUBMODE=LSB.?

With the new HELL modes, unfortunately there is no legacy mode to deprecate.?

The Mode change is still occasionally raises its head in the ADIF discussion forum. Most users want to see a single QSO field 'Mode'. And to that extent all SUBMODE values are unique as a 'recommended ' enumeration list. Any app can maintain a single field in its internal database as long as it gets exported as two fields.

It's a can of worms. For my logging app I accept both strict and deprecated values for the mode. And export strict.?

73 Phil GM3ZZA



On 13 November 2024, at 17:35, "Barry, PC1K via?"?<barry@...>?wrote:


Unfortunately just lost my Apple silicon mac last week.

>?but this change was forced upon us by the current ADIF

I know, because I started the discussion, my aim was to make logging more consistent. Before the change I have seen a FSKH105 QSO logged as HELL, FSKH105 and FSKHELL, this causes confirmations not to happen. In addition LoTW refuses to log FSKH105 (sometimes) as it is not ADIF compliant. This is being worked on in the next ADIF release.

When I look at the ADIF specification, it does not say one can use a submode in the mode field, this is how fldigi implemented it before, and funny enough is also what??does:

Exports as follows:

QRZLogbook download for pc1k
??? Date: Wed Nov 13 17:22:32 2024
??? Bookid: 354929
??? Records: 1
??? <ADIF_VER:5>3.1.1
????<PROGRAMID:10>QRZLogbook
????<PROGRAMVERSION:3>2.0
??? <eoh>
<time_on:4>1721
<my_lon:11>E004 12.400
<eqsl_qsl_sent:1>N
<app_qrzlog_status:1>N
...
<my_lat:11>N052 03.700
<cqz:2>14
<qso_date:8>20241113
<cont:2>EU
<freq:7>7.07498
<tx_pwr:2>20
<lotw_qsl_rcvd:1>N
<mode:7>FSKHELL?????? <- it is not ADIF compliant
<qsl_rcvd:1>N
<app_qrzlog_logid:10>1177766696
<dxcc:3>263
...
<band_rx:3>40m
<eor>


I wonder why submode was added to the ADIF standard??

A good fix for fldigi IMHO would be to also have submode in the logbook.adi and preferably in the UI. So I can still know if a QSO was made in FELD HELL or FSKHELL, because these modes have different characteristics. I don't need the submode to reflect in?, even though that would be nice. This we did not discuss before implementing the change in fldigi 4.2.06.


Maybe I made everything worse by starting the discussion, if the submode field is not implemented in many applications. In any case thanks for your help, fldigi is great!

73 de PC1K



On 13-11-2024 17:12, Dave, W1HKJ wrote:
I will look again at the code, but this change was forced upon us by the current ADIF specification.

David

On 11/12/24 22:08, Barry, PC1K via??wrote:
Hello,?

Today I got around to testing fldigi 4.2.06, specifically:?



With this patch, when I log a QSO in FSKH105, fldigi logs HELL in the mode field, which is correct.?

However the submode field, is not in logbook.adi, nor do I see it anywhere else in the UI. This means that all Hell contacts will be logged as HELL regardless of submode. Is there a way to configure fldigi so that it stores the submode to logbook.adi and preferably show the submode in the UI??

Thanks, Barry?










Re: Question about fldigi submode logging / testing feedback on fldigi 4.2.06

 

¿ªÔÆÌåÓý

Thanks Phil,

Helpful background info, much appreciated!

73 de PC1K

On 13-11-2024 21:14, Philip Rose, GM3ZZA via groups.io wrote:

I joined the ADIF community after the introduction of SUBMODE, version 3 I think. But from some of the discussion, I understand it was an attempt to get a handle on the growing proliferation of new modes. MODE was an attempt at being limited to modulation technique, and SUBMODE defining the coding.

So modes like LSB became MODE=SSB, SUBMODE=LSB. And the digital modes similarly. At the time MODE=LSB became deprecated, and allowed to be imported from files created? by unmaintained legacy apps, but all apps being developed should export it as MODE=SSB, SUBMODE=LSB.

With the new HELL modes, unfortunately there is no legacy mode to deprecate.

The Mode change is still occasionally raises its head in the ADIF discussion forum. Most users want to see a single QSO field 'Mode'. And to that extent all SUBMODE values are unique as a 'recommended ' enumeration list. Any app can maintain a single field in its internal database as long as it gets exported as two fields.

It's a can of worms. For my logging app I accept both strict and deprecated values for the mode. And export strict.

73 Phil GM3ZZA



On 13 November 2024, at 17:35, "Barry, PC1K via groups.io" <barry@...> wrote:

Unfortunately just lost my Apple silicon mac last week.

> but this change was forced upon us by the current ADIF

I know, because I started the discussion, my aim was to make logging more consistent. Before the change I have seen a FSKH105 QSO logged as HELL, FSKH105 and FSKHELL, this causes confirmations not to happen. In addition LoTW refuses to log FSKH105 (sometimes) as it is not ADIF compliant. This is being worked on in the next ADIF release.

When I look at the ADIF specification, it does not say one can use a submode in the mode field, this is how fldigi implemented it before, and funny enough is also what does:

Exports as follows:

QRZLogbook download for pc1k
??? Date: Wed Nov 13 17:22:32 2024
??? Bookid: 354929
??? Records: 1
??? <ADIF_VER:5>3.1.1
??? <PROGRAMID:10>QRZLogbook
??? <PROGRAMVERSION:3>2.0
??? <eoh>
<time_on:4>1721
<my_lon:11>E004 12.400
<eqsl_qsl_sent:1>N
<app_qrzlog_status:1>N
...
<my_lat:11>N052 03.700
<cqz:2>14
<qso_date:8>20241113
<cont:2>EU
<freq:7>7.07498
<tx_pwr:2>20
<lotw_qsl_rcvd:1>N
<mode:7>FSKHELL?????? <- it is not ADIF compliant
<qsl_rcvd:1>N
<app_qrzlog_logid:10>1177766696
<dxcc:3>263
...
<band_rx:3>40m
<eor>


I wonder why submode was added to the ADIF standard??

A good fix for fldigi IMHO would be to also have submode in the logbook.adi and preferably in the UI. So I can still know if a QSO was made in FELD HELL or FSKHELL, because these modes have different characteristics. I don't need the submode to reflect in , even though that would be nice. This we did not discuss before implementing the change in fldigi 4.2.06.


Maybe I made everything worse by starting the discussion, if the submode field is not implemented in many applications. In any case thanks for your help, fldigi is great!

73 de PC1K



On 13-11-2024 17:12, Dave, W1HKJ wrote:
I will look again at the code, but this change was forced upon us by the current ADIF specification.

David

On 11/12/24 22:08, Barry, PC1K via wrote:
Hello,

Today I got around to testing fldigi 4.2.06, specifically:



With this patch, when I log a QSO in FSKH105, fldigi logs HELL in the mode field, which is correct.

However the submode field, is not in logbook.adi, nor do I see it anywhere else in the UI. This means that all Hell contacts will be logged as HELL regardless of submode. Is there a way to configure fldigi so that it stores the submode to logbook.adi and preferably show the submode in the UI?

Thanks, Barry









841 - 860 of 54090