Date   
Re: FLAMP New feature idea - maybe

AD5XJ, KEN
 

You are not always near a D-Rats repeater nor do you always have 2-meters in the network of stations.

Re: FLAMP New feature idea - maybe

Al Massaro
 

Conceptually similar to D-RATS messages. Just Sayin.
AL M
KF5SMH

FLAMP New feature idea - maybe

AD5XJ, KEN
 

From time to time it would be nice to have the ability to put FLAMP into what I call "postoffice mode".
It would operate something like this:
    A single station would be the "postmaster" with FLAMP in this mode. It may operate attended or unattended.
    Any station with a need to send messages to the "postmaster" for all stations or to a single station can put their FLAMP in the same mode and indicate if the destination is another
    station or for "postmaster" to broadcast to all stations.
    FLAMP in "postmaster" mode would save the message sent in a special folder and periodically check for messages.
    If messages are in the send-all folder, they should be broadcast at the pre-configured interval until removed. If any in the send-one folder then sent to the recipient when that
    station is acknowledged or forwarded to destination if Internet bound.
   The prerequisite is that all stations would have to be on the version of FLAMP that supports it and know to put FLAMP in "postal" mode to function that way and a "postmaster"
   would need Internet access to be most effective.

The justification for this feature is to allow ad-hoc operation of a group of stations that can pass messages peer-to-peer in any mode of choosing and provide localized message store and forward over the wide area where WinLINK or PACKET is not accessible. This is sort of like PSKMail but within the FLDIGI/NBEMS software suite and in a limited user group.

There are a number of conceptual questions yet to be answered but I think this could be useful to groups like ARES and SATERN. I think it is worthy of discussion within this group. Or you can email me directly with questions.

  

Re: fldigi 4.1.01 release

Greg Siemasz <gregsiemasz@...>
 

Dave,
I deleted all fldigi files on computer so I could get a "new install" and I got the control back of changing frequencies in Freg box. They matched every time. However, I did some cleaning in Registry too. Now the Waterfall is black and If turn up rec on SignaLink I start to see some blue but nothing like before. I even upped the below that controls rec up to 90 and I never had it up higher than 72. I have another sound card from Ten-Tec and it did the same thing also. So I don't think it's either sound interface. I ran Windows sfc /scannow to see if there were any files that need repair but it reported files were ok. I don't have another computer to check if fldigi would work on it. I even did a reset on my Ten-Tec and nothing changed. Also disable/enabled driver to see if that would help and it didn't change. Do you have any suggestions?
Greg
W8VIJ

Re: fldigi / flmsg Normal operation or bug??

Ron
 

Hi Al and welcome to the wonderful world of NBEMS.

There is a setting in Fldigi that will change the way Flmsg behaves.  On the Fldigi main screen click Configure, Miscellaneous, NBEMS.  In the center of the window look for "Transfer direct to executing flmsg".  If that is checked then all of your received Flmsg will appear as a list and you can view each one at a time.  If you open a blank Flmsg before the messages are sent then all of the received Flmsg will be in the list.  If you uncheck this selection then each received Flmsg will open.

I don't like the list because if you don't receive an Flmsg because of an error you won't know this and won't know if you didn't receive it until you go look for it.  I want to know immediately if there is an error with the receive so I can ask for a resend.  Some people like the list because if they only have one monitor the Flmsg will open on top of each other and will clutter up the screen.  I have 2 large monitors and as the messages come in I can stack them so I can see everything.

73, Ron NY3J

On 3/11/19 1:16 PM, Al Womelsdorf via Groups.Io wrote:
For starters, I am new to this, so keep that in mind.

When I receive a wrap message (typically msk mode), the message arrives just fine, and if it is the first message since starting fldigi, it will automatically open flmsg to display the message. Any subsequent messages will not be shown in flmsg, but the second message will automatically open another window showing "received messages" (or something like that), and all subsequent messages will be listed there. Also, all messages are saved to disk, so there is no issue there. The question is: Is this the expected behavior? I can easily click and view any of these messages if I wish, but because the first message received is NOT listed, it makes it a big deal to go back to that one. Should this window open on the first message, and then list all messages?

I am running on Fedore 28, and all 4 main parts of fldigi are build locally from the alpha source directory (fldigi 4.1.02.10, flmsg 4.0.8.04, etc.)

73's
Al   kd2pnr


fldigi / flmsg Normal operation or bug??

Al Womelsdorf
 

For starters, I am new to this, so keep that in mind.

When I receive a wrap message (typically msk mode), the message arrives just fine, and if it is the first message since starting fldigi, it will automatically open flmsg to display the message. Any subsequent messages will not be shown in flmsg, but the second message will automatically open another window showing "received messages" (or something like that), and all subsequent messages will be listed there. Also, all messages are saved to disk, so there is no issue there. The question is: Is this the expected behavior? I can easily click and view any of these messages if I wish, but because the first message received is NOT listed, it makes it a big deal to go back to that one. Should this window open on the first message, and then list all messages?

I am running on Fedore 28, and all 4 main parts of fldigi are build locally from the alpha source directory (fldigi 4.1.02.10, flmsg 4.0.8.04, etc.)

73's
Al   kd2pnr

GLITCH - Help #2

Ralph Alden Brigham
 

Hello and Greetings,

I have started having a problem with FLDigi recently - after I receive an
FLmsg or FLwrap file my program starts reading an .xml file into the
reception box and starts transmitting said. It also seems that I have FLMSG
running Twice! I close one and then find another session running - when I
close that one the the display of the .xml file stops

Currently running Win10 Home
FLDigi 4.1.00

Current versions of Flmsg and FLwrap installed and behaving.

What have I mucked up?

People in Huntsville AL are stumped - HELP!!

-- ***** ---
Ralph Brigham KG4CSQ -- EM64RQ2OOQ
W5YI VE 33080; ARRL VE
ARRL #1000033463
ARES/RACES SKYWARN
(931) 906-9277
-- ****

Re: fldigi 4.1.01 release

Greg Siemasz <gregsiemasz@...>
 

Dave,
I have uninstalled the program and cleaned out registry and since you claim it is a local problem I am beginning to think it is not compatible with windows 10 which is constantly changing through upgrades.
It is beyond my control and have decided to remove it from computer for now.
I have never used a rig control and did frequency changes manually and as I explained, Flq always changed with respect to the "main" frequency and when I closed program and opened it again, it never defaulted back to 40 meters. It use to open on the frequency that I closed the program on. If it was 14.070, it would open back up on 14.070. If closed on 21.070 then it would open up on 21.070 not on 7.070 like it is doing now. Something is wrong.
Greg


On Fri, Mar 8, 2019 at 2:23 PM Greg Siemasz via Groups.Io <gregsiemasz=gmail.com@groups.io> wrote:
Dave,
I am not using any rig control.
I change the main frequency through the icon open list that looks like a little book next to the enter the call button. If I change that the frequency stays on 40m. If I close the program, it defaults to 40m
image.png
The Frq never changes and I never had this problem before.
image.png
Frq is stuck in 40m.
It never did that before. The frq always changed when I changed the frequency through open list icon.
Greg

On Thu, Mar 7, 2019 at 6:28 PM Dave <w1hkj@...> wrote:
Your bug report is very local Greg.  I've tested on Linux, Windows and OS X sans rig control.  Change the frequency selection (using the top/bottom digit left click), close fldigi, restart and the last entered vfo value is displayed.  Works as it always has.

I have a feeling you might be using keyboard entry for the frequency entry.  If you are, then you must press the Enter key for the new frequency value to be a saved as a valid value.  The Enter key will also insure that the log control for frequency is based on the new entry.  Your screen shots show otherwise.

David

Re: fldigi 4.1.01 release

Greg Siemasz <gregsiemasz@...>
 

Dave,
I am not using any rig control.
I change the main frequency through the icon open list that looks like a little book next to the enter the call button. If I change that the frequency stays on 40m. If I close the program, it defaults to 40m
image.png
The Frq never changes and I never had this problem before.
image.png
Frq is stuck in 40m.
It never did that before. The frq always changed when I changed the frequency through open list icon.
Greg


On Thu, Mar 7, 2019 at 6:28 PM Dave <w1hkj@...> wrote:
Your bug report is very local Greg.  I've tested on Linux, Windows and OS X sans rig control.  Change the frequency selection (using the top/bottom digit left click), close fldigi, restart and the last entered vfo value is displayed.  Works as it always has.

I have a feeling you might be using keyboard entry for the frequency entry.  If you are, then you must press the Enter key for the new frequency value to be a saved as a valid value.  The Enter key will also insure that the log control for frequency is based on the new entry.  Your screen shots show otherwise.

David

Re: fldigi 4.1.01 release

Dave
 

Your bug report is very local Greg.  I've tested on Linux, Windows and OS X sans rig control.  Change the frequency selection (using the top/bottom digit left click), close fldigi, restart and the last entered vfo value is displayed.  Works as it always has.

I have a feeling you might be using keyboard entry for the frequency entry.  If you are, then you must press the Enter key for the new frequency value to be a saved as a valid value.  The Enter key will also insure that the log control for frequency is based on the new entry.  Your screen shots show otherwise.

David

Matched pair alpha test suite

Dave
 

Please download and test this set of fldigi/flamp files if you have been experiencing lost blocks when transmitting large flamp files.  WN3LIF, WT, my intrepid tester and I have labored for the past two weeks to resolve this issue and this is the result.  We cannot make it break, but welcome any problem reports (and kudos as well).  The fix required changes in both flamp and fldigi.

Please note this configuration panel change in flamp

The "Tx Duration Mins" was limited to 1 minute intervals.  That has change to 0.05 minor and 1.0 major increments.  0.05 minutes ==> 3 minute.  The selection is enumerated in the control to the right labeled "mm:ss".

The flamp script parser has been changed to also work with fractional minutes; M.mm where mm is factors of 0.05.

73, David, W1HKJ


Re: fldigi 4.1.01 release

Greg Siemasz <gregsiemasz@...>
 

Dave,
Would you please let me know when you have a fix for the problems I reported.
I take it will be new version of software.
I would surly appreciate it.
Thank you.Greg

Re: fldigi 4.1.01 release

Greg Siemasz <gregsiemasz@...>
 

Marty,
No rig control no boxes checked in any of the three.
Greg

Re: fldigi 4.1.01 release

Marty Hartwell
 

Hi

I just briefly tried this on my issue of Fldigi 4.1.0.1 and don't see this action with no rig connected

or configured in rig control. What I have in the large frequency window on the left in blue matches

what is the the smaller window on the right labeled Freq with the difference in the frequency + or -

the amount in the waterfall window as expected.

My first question is do you have any check marks in any of the three rig control methods "Flrig,

RigCat, or Hamlib". In my case I usually use Flrig and had a check mark in that tab, but nothing else,

as expected, in the other two tabs. If there is a check mark in one of those tabs then Fldigi may be

expecting to see a connection on the serial port.

Other then that I have no other ideas.

Good Luck.

Marty kd8bj

On 2/28/19 1:20 PM, Greg Siemasz wrote:
Below are a couple of pic of my computer screen that explain what I am seeing in Fldigi 4.1.00
After I close the program with it on 14.070 it should load the next time but it doesn't. It opens on 7.070 instead.
This is done manually and not by any rig control.
I hope this helps.


Re: FLDIGI 4.1.0.0 LoTW mode field not exporting causing an error

Dave
 



You might expect to see something like the above if you are running a recent alpha version.  Not sure why you did not.

Note this is on a Mac.

David

Re: fldigi 4.1.01 release

Greg Siemasz <gregsiemasz@...>
 

Below are a couple of pic of my computer screen that explain what I am seeing in Fldigi 4.1.00
After I close the program with it on 14.070 it should load the next time but it doesn't. It opens on 7.070 instead.
This is done manually and not by any rig control.
I hope this helps.


Minor glitch

Ralph Alden Brigham
 

Hello and Greetings,

I have started having a problem with FLDigi recently - after I receive an
FLmsg or FLwrap file my program starts reading an .xml file into the
reception box and starts transmitting said.

Currently running Win10 Home
FLDigi 4.1.00

Current versions of Flmsg and FLwrap installed and behaving.

What have I mucked up?

-- ***** ---
Ralph Brigham KG4CSQ -- EM64RQ2OOQ
W5YI VE 33080; ARRL VE
ARRL #1000033463
ARES/RACES SKYWARN
(931) 906-9277
-- ****

Re: FLDIGI 4.1.0.0 LoTW mode field not exporting causing an error

Marty Hartwell
 

Hi

To be sure,  since there is not such version as 4.1.00, I would have assumed that same thing.

I personally don't want the alpha releases for daily use, if I am experiencing the issue it is correcting

then I will download, compile and use to see if it corrects the issue. Then when it is released as a full

full release then replace the alpha and retest and use.

Now since moving to the new condo and it is winter I will be operating mostly QRV from my car at a picnic

table.

I expect the original op was not to familiar with software version standards.


Marty kd8bj

On 2/28/19 9:59 AM, Bill Hamel wrote:
Hi David,

I’m not sure if the box you are showing pops up when you check for updates, if it is, what I’m seeing on a Mac is different.



If 4.1.0.1 is not supposed to be considered "the latest version" I’ll keep that in mind for future versions that are in the x of 4.1.0.x versioning.

Returning the message in the box you displayed would make more sense here.

I guess I got confused when I saw ver 4.1.00 which I thought meant 4.1.0.0

Thanks,
-bh k3tfm



On Feb 28, 2019, at 10:15 AM, Dave <@w1hkj <mailto:@w1hkj>> wrote:

Your statement is not true Bill.

<apjeacjpiapdeefk.png>

4.1.0.0 was and is an alpha version and it's numbering will always be in sync with the final distribution, ie:

4.1.0.1
4.1.0.2
4.1.0.n ===> results in a distribution of 4.1.0.

As an alpha user you have the responsibility to monitor either linuxham@groups.io, or nbems@groups.io, or winfldigi@groups.io for announcements regarding new distributions, or personally check Source Forge (or the w1hkj.com <http://w1hkj.com> site) for physical evidence of a new distribution.

The groups.io <http://groups.io> announcements always delineate what bugs have been fixed or changes implemented.

73, David, W1HKJ

On 2/28/19 8:54 AM, Bill Hamel wrote:
Not realizing that the Help -> “Check for updates” doesn’t actually check for updates since it kept tell me that no updates are available.

I manually found a v4.1.01 that says it fixes this problem in the release notes. I’ve installed it an it appears to be working now.

Thanks
-bh k3tfm

On Feb 27, 2019, at 9:34 PM, Bill Hamel <bill@... <mailto:bill@...>> wrote:

Good evening.

---
Fldigi 4.1.0.0
MAC OS High Sierra 10.13.6
Tsql: 2.4.3


When I try to use Fldigi to automatically update LoTW I get an error that says that the mode is missing, In this case PSK31

To help diagnose I unchecked the box that says “Quiet mode [-q], do not open tqsl dialog in Logbook->LoTW

Condition 1
==========
When I finish a QSO and write the log a box pops up that reports

—-------------------<SNIP>------------------------
Signing using Callsign K3TFM, DXCC Entity UNITED STATES OF AMERICA

Error: Invalid contact - QSO does not specify a mode on line 4
CALL: K5****
FREQ: 7.07269
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0206

Warning: Signing cancelled
No records to upload
---------------------</SNIP>————————————

Condition 2
===========
When I use Fldigi to try a LoTW batch by doing Logbook->LoTW->Export
I make sure I select the LoTW button so it checks the relevant fields
(Note that I also will check the “Mode” box and try it that way also since when clicking the “LoTW” button it does not check the mode box)
I then select “SEND” and the following log entries occur in the log file

Note actual calls masked with “*"
—-------------------<SNIP>------------------------
Wed Feb 27 20:41:28 2019 tqsl_getNumBand
Wed Feb 27 20:41:28 2019 check_tqsl_error: rval=1
Wed Feb 27 20:41:28 2019 check_tqsl_error: msg=Invalid contact - QSO does not specify a mode
Error: Invalid contact - QSO does not specify a mode on line 6
CALL: KG5***
FREQ: 7.07254
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0059

Wed Feb 27 20:41:28 2019 tqsl_getNumBand
Wed Feb 27 20:41:28 2019 check_tqsl_error: rval=1
Wed Feb 27 20:41:28 2019 check_tqsl_error: msg=Invalid contact - QSO does not specify a mode
Error: Invalid contact - QSO does not specify a mode on line 7
CALL: AA5***
FREQ: 7.07232
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0113

Wed Feb 27 20:41:28 2019 MyFrame::UploadLogFile: Log converted, status = 9, numrecs=0
---------------------</SNIP>————————————

Condition 3
--------------------
I can get it to work if I do the following

In FLDigi Logbook->ADIF->Export

Check the same boxes that I do above using the LoTW methods above

Export the adif

From within Tsql do a “Sign a log and upload it automatically to LoTW”

And my log is successfully uploaded to LoTW including the Mode information

Any insight greatly appreciated.

Thanks,
Bill K3TFM






Re: FLDIGI 4.1.0.0 LoTW mode field not exporting causing an error

Bill Hamel
 

Hi David,

I’m not sure if the box you are showing pops up when you check for updates, if it is, what I’m seeing on a Mac is different.



If 4.1.0.1 is not supposed to be considered "the latest version" I’ll keep that in mind for future versions that are in the x of 4.1.0.x versioning.

Returning the message in the box you displayed would make more sense here.

I guess I got confused when I saw ver 4.1.00 which I thought meant 4.1.0.0

Thanks,
-bh k3tfm



On Feb 28, 2019, at 10:15 AM, Dave <w1hkj@...> wrote:

Your statement is not true Bill.

<apjeacjpiapdeefk.png>

4.1.0.0 was and is an alpha version and it's numbering will always be in sync with the final distribution, ie:

4.1.0.1
4.1.0.2
4.1.0.n ===> results in a distribution of 4.1.0.

As an alpha user you have the responsibility to monitor either linuxham@groups.io, or nbems@groups.io, or winfldigi@groups.io for announcements regarding new distributions, or personally check Source Forge (or the w1hkj.com site) for physical evidence of a new distribution.

The groups.io announcements always delineate what bugs have been fixed or changes implemented.

73, David, W1HKJ

On 2/28/19 8:54 AM, Bill Hamel wrote:
Not realizing that the Help -> “Check for updates” doesn’t actually check for updates since it kept tell me that no updates are available.

I manually found a v4.1.01 that says it fixes this problem in the release notes. I’ve installed it an it appears to be working now.

Thanks
-bh k3tfm

On Feb 27, 2019, at 9:34 PM, Bill Hamel <bill@...> wrote:

Good evening.

---
Fldigi 4.1.0.0
MAC OS High Sierra 10.13.6
Tsql: 2.4.3

When I try to use Fldigi to automatically update LoTW I get an error that says that the mode is missing, In this case PSK31

To help diagnose I unchecked the box that says “Quiet mode [-q], do not open tqsl dialog in Logbook->LoTW

Condition 1 
==========
When I finish a QSO and write the log a box pops up that reports 

—-------------------<SNIP>------------------------
Signing using Callsign K3TFM, DXCC Entity UNITED STATES OF AMERICA

Error: Invalid contact - QSO does not specify a mode on line 4
CALL: K5****
FREQ: 7.07269
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0206

Warning: Signing cancelled
No records to upload
---------------------</SNIP>————————————

Condition 2 
===========
When I use Fldigi to try a LoTW batch by doing Logbook->LoTW->Export
I make sure I select the LoTW button so it checks the relevant fields
(Note that I also will check the “Mode” box and try it that way also since when clicking the “LoTW” button it does not check the mode box)
I then select “SEND” and the following log entries occur in the log file

Note actual calls masked with “*"
—-------------------<SNIP>------------------------
Wed Feb 27 20:41:28 2019 tqsl_getNumBand
Wed Feb 27 20:41:28 2019 check_tqsl_error: rval=1
Wed Feb 27 20:41:28 2019 check_tqsl_error: msg=Invalid contact - QSO does not specify a mode
Error: Invalid contact - QSO does not specify a mode on line 6
CALL: KG5***
FREQ: 7.07254
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0059

Wed Feb 27 20:41:28 2019 tqsl_getNumBand
Wed Feb 27 20:41:28 2019 check_tqsl_error: rval=1
Wed Feb 27 20:41:28 2019 check_tqsl_error: msg=Invalid contact - QSO does not specify a mode
Error: Invalid contact - QSO does not specify a mode on line 7
CALL: AA5***
FREQ: 7.07232
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0113

Wed Feb 27 20:41:28 2019 MyFrame::UploadLogFile: Log converted, status = 9, numrecs=0
---------------------</SNIP>————————————

Condition 3 
--------------------
I can get it to work if I do the following

In FLDigi Logbook->ADIF->Export 

Check the same boxes that I do above using the LoTW methods above

Export the adif

From within Tsql do a “Sign a log and upload it automatically to LoTW”

And my log is successfully uploaded to LoTW including the Mode information

Any insight greatly appreciated.

Thanks,
Bill K3TFM










Re: FLDIGI 4.1.0.0 LoTW mode field not exporting causing an error

Dave
 

Your statement is not true Bill.



4.1.0.0 was and is an alpha version and it's numbering will always be in sync with the final distribution, ie:

4.1.0.1
4.1.0.2
4.1.0.n ===> results in a distribution of 4.1.0.

As an alpha user you have the responsibility to monitor either linuxham@groups.io, or nbems@groups.io, or winfldigi@groups.io for announcements regarding new distributions, or personally check Source Forge (or the w1hkj.com site) for physical evidence of a new distribution.

The groups.io announcements always delineate what bugs have been fixed or changes implemented.

73, David, W1HKJ

On 2/28/19 8:54 AM, Bill Hamel wrote:
Not realizing that the Help -> “Check for updates” doesn’t actually check for updates since it kept tell me that no updates are available.

I manually found a v4.1.01 that says it fixes this problem in the release notes. I’ve installed it an it appears to be working now.

Thanks
-bh k3tfm

On Feb 27, 2019, at 9:34 PM, Bill Hamel <bill@...> wrote:

Good evening.

---
Fldigi 4.1.0.0
MAC OS High Sierra 10.13.6
Tsql: 2.4.3

When I try to use Fldigi to automatically update LoTW I get an error that says that the mode is missing, In this case PSK31

To help diagnose I unchecked the box that says “Quiet mode [-q], do not open tqsl dialog in Logbook->LoTW

Condition 1 
==========
When I finish a QSO and write the log a box pops up that reports 

—-------------------<SNIP>------------------------
Signing using Callsign K3TFM, DXCC Entity UNITED STATES OF AMERICA

Error: Invalid contact - QSO does not specify a mode on line 4
CALL: K5****
FREQ: 7.07269
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0206

Warning: Signing cancelled
No records to upload
---------------------</SNIP>————————————

Condition 2 
===========
When I use Fldigi to try a LoTW batch by doing Logbook->LoTW->Export
I make sure I select the LoTW button so it checks the relevant fields
(Note that I also will check the “Mode” box and try it that way also since when clicking the “LoTW” button it does not check the mode box)
I then select “SEND” and the following log entries occur in the log file

Note actual calls masked with “*"
—-------------------<SNIP>------------------------
Wed Feb 27 20:41:28 2019 tqsl_getNumBand
Wed Feb 27 20:41:28 2019 check_tqsl_error: rval=1
Wed Feb 27 20:41:28 2019 check_tqsl_error: msg=Invalid contact - QSO does not specify a mode
Error: Invalid contact - QSO does not specify a mode on line 6
CALL: KG5***
FREQ: 7.07254
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0059

Wed Feb 27 20:41:28 2019 tqsl_getNumBand
Wed Feb 27 20:41:28 2019 check_tqsl_error: rval=1
Wed Feb 27 20:41:28 2019 check_tqsl_error: msg=Invalid contact - QSO does not specify a mode
Error: Invalid contact - QSO does not specify a mode on line 7
CALL: AA5***
FREQ: 7.07232
QSO_DATE: 20190228
BAND: 40m
TIME_ON: 0113

Wed Feb 27 20:41:28 2019 MyFrame::UploadLogFile: Log converted, status = 9, numrecs=0
---------------------</SNIP>————————————

Condition 3 
--------------------
I can get it to work if I do the following

In FLDigi Logbook->ADIF->Export 

Check the same boxes that I do above using the LoTW methods above

Export the adif

From within Tsql do a “Sign a log and upload it automatically to LoTW”

And my log is successfully uploaded to LoTW including the Mode information

Any insight greatly appreciated.

Thanks,
Bill K3TFM