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

#53579

开云体育

Thanks Phil,

Helpful background info, much appreciated!

73 de PC1K

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

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

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

#53578

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

Show quoted text

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

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

#53577

开云体育

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.

Joel - W4JBB

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

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

#53576

开云体育

Unfortunately just lost my Apple silicon mac last week.

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

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:

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:

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

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

#53575

开云体育

Same here on my M2 Mac mini. Dan

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

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

#53574

开云体育

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.

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

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

#53573

开云体育

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:

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

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

#53572

开云体育

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:

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

Re: Solution Found for Microphone Access Problem

#53571

开云体育

Sublime ?.? Thank you Lonnie.? I tried this on my M2 MacBook Air and it worked just as described.? The codesign will probably need to be repeated with each new fldigi install.

David

On 11/13/24 06:30, Lonnie Craven wrote:

Show quoted text

I thought you guys would want to know the solution I found to run Fldigi on my M4 Mac mini.

The following article describes the problem I was having and the solution.

Fldigi is now working well on my new M4 Mac mini.

73,

Lonnie, K4KZ

Linux Recommendation - Work is a RHEL/Windows Shop

#53570

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: fldigi would like to access the microphone loop

#53569

Just open your terminal and paste in the following code (change the specific version to your own, of course):

codesign --force --deep --sign - /Applications/fldigi-4.2.05.app

Be careful to keep all the dashes, even the single one after "sign".

Terminal will prompt for your password, then reply with "/Applications/fldigi-4.2.05.app: replacing existing signature"

Question about fldigi submode logging / testing feedback on fldigi 4.2.06

#53568

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: flrig as hamlib client

#53567

开云体育

Requires the UI, but it can run minimized.

On 11/12/24 17:56, Lonney K1LH via groups.io wrote:

Show quoted text

Hi Joel,

?

Good question, that I do not know the answer to :-) perhaps someone else can chime in?

?

- Lonney

?

On Tue, Nov 12, 2024 at 07:51 AM, Joel Vazquez, WE0DX wrote:

flrig does not run as a headless server, it requires the graphic interface, correct?

Re: flrig as hamlib client

#53566

Hi Joel,

Good question, that I do not know the answer to :-) perhaps someone else can chime in?

- Lonney

On Tue, Nov 12, 2024 at 07:51 AM, Joel Vazquez, WE0DX wrote:

Show quoted text

flrig does not run as a headless server, it requires the graphic interface, correct?

Re: loop back audio devices in linux

#53565

开云体育

Hello Michael,

The whole concept of rc.local has been deprecated in most Linux distributions though it's still possible with Raspberry Pi OS.? That said, it's not difficult to create a new Systemd unit to start whatever you what but It's not clear what is in your unit file but here is one example:

/etc/systemd/system/startup-email.service
--
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/startup-email-service.sh

[Install]
WantedBy=multi-user.target

[Unit]
Description=Startup Email
Wants=network-online.target
After=network-online.target
--

#To activate this new example systemd unit, you would run:
sudo systemctl enable startup-email.service

Since you're dealing with audio, do you know what command activates this audio listener?? I believe you will be required to run this systemd unit as a specific user and this seems to be covered here:

??

--David
KI6ZHD

On 11/12/2024 11:26 AM, OZ1MIC, Michael wrote:

Show quoted text

hi there

I am a noob a rpi/linux. But I managed to get the WFview ver 1.60 from repository on a rpi 4b running Bookworm. It is now running it as server on an IC-7300 and I have have a Win 10 PC running the Wfview ver.1.60 as client. Running like a charm with scope and audio transfer.

Now I want to have the fldigi running on the rpi linked to the Wfview server and I have followed the guide ?"loopback audio devices" from the user manal very thoroughly (having edited and /etc/systemd/system/rc-local.service).

?
But when running:?
sudo systemctl enable rc-local.service
I get the following :??
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
?
Possible reasons for having this kind of units are:
? A unit may be statically enabled by being symlinked from another unit's
? .wants/ or .requires/ directory.
? A unit's purpose may be to act as a helper for some other unit which has
? a requirement dependency on it.
? A unit may be started when needed via activation (socket, path, timer,
? D-Bus, udev, scripted systemctl call, ...).
? In case of template units, the unit is meant to be enabled with some
? instance name specified.

I can't see what I am doing wrong.? Any ideas out there ?

/Michael oz1mic

?