ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
esc to dismiss
Question about fldigi submode logging / testing feedback on fldigi 4.2.06
|
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
|
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
groups.io wrote:
toggle quoted message
Show quoted text
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
|
I need a few Mac users to test
install this version of fldigi:
on M1/2/4 systems.
You may need to right click on the installed app icon in
/Applications to force the first start.? The Mac will complain
that it cannot test the app for malicious software (read that as
I did not pay Apple their insurance premium).? You will also
have to allow microphone use, but only once.
David, W1HKJ
On 11/13/24 10:12, Dave, W1HKJ wrote:
toggle quoted message
Show quoted text
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
groups.io 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
|
I had to go to System Settings > Privacy and Security > Security and tell it to open anyway it complained once again but once I gave it my fingerprint it opened. Only had to click once on mike use.
I’m on a MacBook Pro with M2 chip.
toggle quoted message
Show quoted text
On Nov 13, 2024, at 11:59?AM, Dave, W1HKJ via groups.io <w1hkj@...> wrote:
I need a few Mac users to test
install this version of fldigi:
on M1/2/4 systems.
You may need to right click on the installed app icon in
/Applications to force the first start.? The Mac will complain
that it cannot test the app for malicious software (read that as
I did not pay Apple their insurance premium).? You will also
have to allow microphone use, but only once.
David, W1HKJ
On 11/13/24 10: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
groups.io 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
|
Same here on my M2 Mac mini. Dan
toggle quoted message
Show quoted text
On 13 Nov 2024, at 12:19, Gary Rogers, KO3F via groups.io wrote:
I had to go to System Settings > Privacy and Security > Security and tell it to open anyway it complained once again but once I gave it my fingerprint it opened. Only had to click once on mike use.
I’m on a MacBook Pro with M2 chip.
On Nov 13, 2024, at 11:59?AM, Dave, W1HKJ via groups.io <w1hkj@...> wrote:
I need a few Mac users to test install this version of fldigi:
on M1/2/4 systems.
You may need to right click on the installed app icon in /Applications to force the first start.? The Mac will complain that it cannot test the app for malicious software (read that as I did not pay Apple their insurance premium).? You will also have to allow microphone use, but only once.
David, W1HKJ
On 11/13/24 10: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 groups.io 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
|
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 QRZ.com 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
QRZ.com/LoTW, 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:
toggle quoted message
Show quoted text
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
groups.io 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
|
Dave,
Other than the normal “malicious software” warning, having to go into System Settings and telling it to run anyway, and getting just a single “Fldigi wants to use your microphone” prompt, I am able to run this just fine including subsequent program starts.
I’m on an M2 Max Mac Studio.
I cannot remember what makes it show up in Launchpad but .02 doesn’t show up in Launchpad either.
toggle quoted message
Show quoted text
On Nov 13, 2024, at 10:59?AM, Dave, W1HKJ via groups.io <w1hkj@...> wrote:
I need a few Mac users to test
install this version of fldigi:
on M1/2/4 systems.
You may need to right click on the installed app icon in
/Applications to force the first start.? The Mac will complain
that it cannot test the app for malicious software (read that as
I did not pay Apple their insurance premium).? You will also
have to allow microphone use, but only once.
David, W1HKJ
On 11/13/24 10: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
groups.io 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
|
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
|
Thanks Phil,
Helpful background info, much appreciated!
73 de PC1K
On 13-11-2024 21:14, Philip Rose,
GM3ZZA via groups.io wrote:
toggle quoted message
Show quoted text
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
|
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.
toggle quoted message
Show quoted text
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?
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:
toggle quoted message
Show quoted text
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?
Hi, Dave.
?
I tried but after receiving the “we couldn’t verify” message the only options I had were to cancel out or delete the app.? I think that there may be an issue with my Mac mini since I tried to open the previously
installed and working version that required hoop-jumping (4.2.05.15) using the work around, which was working a few weeks ago, ?but now I just get the Terminal opening and its expected message, but everything hangs after that.? I’m using an M1 Mini running
15.0.1
?
BTW, if you do decide to bite the bullet and enroll in the Developer program, I’m sure there will be many of us who will gladly chip in to cover the cost.
?
Hi, Gary.
?
I clicked on the zip file icon and that took me to your DropBox.? Are you sharing that file with just Dave or with the wider group?? Thanks.
?
Gary Rogers, WA4YMZ
?
?
Thank you Gary.? Perhaps it is time for me to fultill the Apple Developer requirements.
David
toggle quoted message
Show quoted text
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?
?
?
?
|
This is gonna be confusing :)
Gary, all are welcome to use the zip file. Just download, open the zip file and drag it to your applications folder and double click. It should open without additional steps.
toggle quoted message
Show quoted text
On Nov 16, 2024, at 10:09?PM, Gary WA4YMZ via groups.io <wa4ymz@...> wrote:
Hi, Dave. ? I tried but after receiving the “we couldn’t verify” message the only options I had were to cancel out or delete the app.? I think that there may be an issue with my Mac mini since I tried to open the previously installed and working version that required hoop-jumping (4.2.05.15) using the work around, which was working a few weeks ago, ?but now I just get the Terminal opening and its expected message, but everything hangs after that.? I’m using an M1 Mini running 15.0.1 ? BTW, if you do decide to bite the bullet and enroll in the Developer program, I’m sure there will be many of us who will gladly chip in to cover the cost. ? Hi, Gary. ? I clicked on the zip file icon and that took me to your DropBox.? Are you sharing that file with just Dave or with the wider group?? Thanks. ? Gary Rogers, WA4YMZ ? ? 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??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 ??<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?
?
?
?
|
Thanks, Gary.
?
I grabbed the zip file, decompressed it, moved it to the Applications folder, then launched it (FLRIG was already running).? It asked me if I was OK with it accessing the microphone and I said yes.? Within
minutes I was on 20M copying signals.? Since then I have shut down the program and FLRIG, power cycled the Mini, and brought it back up again with no issues, including not having to answer the microphone question.? Excellent!
?
Hi, Dave.
?
I’ve only been on with this version of fldigi but so far everything is looking great!? Note that I’m not a power user so I’ll defer to those who are more experienced, but for now all is great!? Thanks.
?
Gary, WA4YMZ
?
?
This is gonna be confusing :)
Gary, all are welcome to use the zip file. Just download, open the zip file and drag it to your applications folder and double click. It should open without additional steps.
toggle quoted message
Show quoted text
On Nov 16, 2024, at 10:09?PM, Gary WA4YMZ via groups.io <wa4ymz@...> wrote:
?
I tried but after receiving the “we couldn’t verify” message the only options I had were to cancel out or delete the app.? I think that there may be an issue with my Mac mini since I tried to open the previously
installed and working version that required hoop-jumping (4.2.05.15) using the work around, which was working a few weeks ago, ?but now I just get the Terminal opening and its expected message, but everything hangs after that.? I’m using an M1 Mini running
15.0.1
BTW, if you do decide to bite the bullet and enroll in the Developer program, I’m sure there will be many of us who will gladly chip in to cover the cost.
I clicked on the zip file icon and that took me to your DropBox.? Are you sharing that file with just Dave or with the wider group?? Thanks.
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??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??<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?
?
|
Not sure if this will go directly to you or the group so I separated it out.? If anyone else sees this, please feel free to deleted it immediately.? Or not.? You’re call.?
?
?
I’m used to name confusion.? About 30 years ago I was working in Order Fulfillment for a large commercial computer company based in Massachusetts. (I was in one of our NC facilities.) ?One day I started getting
emails asking me for specifics about a new project engineering was working on but, since my job responsibility had nothing to do with that function, I looked in the address book to see if I could figure out who the intended recipient was so I could forward
it to them.? It turns out that there was an engineer with the same name.? I forwarded the email to him (copying the original sender) and, over time as we continued to receive each other’s emails, we developed an online friendship.? The biggest surprise was
when we were discussing what we were going to do over the weekend and one of us, not sure who, mentioned doing some antenna work.? It was then when we realized we not only shared a name but also a hobby.
?
Eventually, he told me he was going to another company and the misrouted emails ceased.? A few years later that company bought my company, but by then he had retired so we never experienced getting each other’s
emails again.
?
Anyways, just a small anecdote about how, even in such a large community, we run up on people with whom we have similarities, even sharing a name.
?
Gary Rogers in North Carolina.
?
This is gonna be confusing :)
Gary, all are welcome to use the zip file. Just download, open the zip file and drag it to your applications folder and double click. It should open without additional steps.
toggle quoted message
Show quoted text
On Nov 16, 2024, at 10:09?PM, Gary WA4YMZ via groups.io <wa4ymz@...> wrote:
?
I tried but after receiving the “we couldn’t verify” message the only options I had were to cancel out or delete the app.? I think that there may be an issue with my Mac mini since I tried to open the previously
installed and working version that required hoop-jumping (4.2.05.15) using the work around, which was working a few weeks ago, ?but now I just get the Terminal opening and its expected message, but everything hangs after that.? I’m using an M1 Mini running
15.0.1
BTW, if you do decide to bite the bullet and enroll in the Developer program, I’m sure there will be many of us who will gladly chip in to cover the cost.
I clicked on the zip file icon and that took me to your DropBox.? Are you sharing that file with just Dave or with the wider group?? Thanks.
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??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??<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?
?
|
Circle back to the original topic, after giving it some thought.
If it is too much work to implement submodes in fldigi, I would prefer to revert to the old situation. It is better to log submode FSKH105 as mode. Compared to the current fix, which would log all different HELL modes as HELL.
With the old way, I can script myself out of it, currently:
sed -i 's/FSKH105/FSKHELL/g' /home/bar/.fldigi/logs/logbook.adif
Similar I could sed the mode and submode into the log.
The fix in 4.2.06 would mean manual work to modify the log. As there is no way to determine if a QSO was in Feld Hell or FSKH105.
Remember that FSKH105 is proposed to be added to ADIF, which would mean I do not have to use sed at all. Ignoring submode as mode, which I don't care about too much.
Anyways, my 2 cents.
toggle quoted message
Show quoted text
On 2024-11-17 18:13, Gary WA4YMZ via groups.io wrote: Thanks, Gary.
I grabbed the zip file, decompressed it, moved it to the Applications folder, then launched it (FLRIG was already running). It asked me if I was OK with it accessing the microphone and I said yes. Within minutes I was on 20M copying signals. Since then I have shut down the program and FLRIG, power cycled the Mini, and brought it back up again with no issues, including not having to answer the microphone question. Excellent!
Hi, Dave.
I’ve only been on with this version of fldigi but so far everything is looking great! Note that I’m not a power user so I’ll defer to those who are more experienced, but for now all is great! Thanks.
Gary, WA4YMZ
From: [email protected] <[email protected]> on behalf of Gary Rogers, KO3F via groups.io <cgaryrogers190@...>
Date: Sunday, November 17, 2024 at 4:43?AM
To: [email protected] <[email protected]>
Subject: Re: [linuxham] Question about fldigi submode logging / testing feedback on fldigi 4.2.06
This is gonna be confusing :)
Gary, all are welcome to use the zip file. Just download, open the zip file and drag it to your applications folder and double click. It should open without additional steps.
On Nov 16, 2024, at 10:09?PM, Gary WA4YMZ via groups.io <wa4ymz@...> wrote:
Hi, Dave.
I tried but after receiving the “we couldn’t verify” message the only options I had were to cancel out or delete the app. I think that there may be an issue with my Mac mini since I tried to open the previously installed and working version that required hoop-jumping (4.2.05.15) using the work around, which was working a few weeks ago, but now I just get the Terminal opening and its expected message, but everything hangs after that. I’m using an M1 Mini running 15.0.1
BTW, if you do decide to bite the bullet and enroll in the Developer program, I’m sure there will be many of us who will gladly chip in to cover the cost.
Hi, Gary.
I clicked on the zip file icon and that took me to your DropBox. Are you sharing that file with just Dave or with the wider group? Thanks.
Gary Rogers, WA4YMZ
From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Dave, W1HKJ via groups.io<><w1hkj@...<mailto:w1hkj@...>>
Date: Wednesday, November 13, 2024 at 5:31?PM
To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: Re: [linuxham] 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:
[cid:part1.hWVkIuxB.1KKZGwLO@...]
fldigi-4.2.06.05.zip<>
dropbox.com<>
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@...><mailto:barry@...>wrote:
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@...><mailto: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 QRZ.com<> does:
[cid:part1.NbzJrSKB.1BzNYTIt@...]
[cid:part2.OvrD5o3j.NKn6Hj8k@...]
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 QRZ.com/LoTW<>, 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 groups.io<> 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
|
Dave, W1HKJ
Joel Black - W4JBB
Philip Rose, GM3ZZA
Gary WA4YMZ