Topics

fldigi 4.1.01 release

Dave
 

Download at www.w1hkj.com/files/fldigi/ :

or Source Forge.

Version 4.1.01 - Maintenance release

  CW h/w ptt
    allow disabling CAT ptt when using external CW keyer such as nanoIO.

  nanoIO
    Bug fix to CW interface

  NAVTEX abort
    remove abort() statements from navtext afc processing
    fix serious bug which allowed fft filters to be destroyed during
    signal processing

  WF only bug fix

  LotW
    Adif export missing <MODE:n> <SUBMODE:n>

  Pedantic warnings
    correct additional gcc warnings

  dup-check
    Add 'possible dup' to logic with corresponding possible dup color
      dup color to CALL controls
    Separate N3FJP duplicate query from response
      response time was a part of keyboard input processing

  ADIF submode
    Add submode support
      export both MODE and SUBMODE to external loggers iaw
      ADIF spec 3.04

  QRZ.com
    change interface to QRZ XML service version 1.33

  SV1GRB test report
    Corrections based on Haris' testing of 4.1.00
    Add "NONE" or "N/A" to State and County pick lists

  SD counties
    sort alphabetically


This release does not include changes needed to give https access to METAR data.

73, David, W1HKJ


David Weiss <dweiss.ssbn620@...>
 

WOW. A lot of fixes.

David Weiss
From my cell phone.

On Tue, Feb 19, 2019, 9:08 AM Dave <w1hkj@... wrote:
Download at www.w1hkj.com/files/fldigi/ :

or Source Forge.

Version 4.1.01 - Maintenance release

  CW h/w ptt
    allow disabling CAT ptt when using external CW keyer such as nanoIO.

  nanoIO
    Bug fix to CW interface

  NAVTEX abort
    remove abort() statements from navtext afc processing
    fix serious bug which allowed fft filters to be destroyed during
    signal processing

  WF only bug fix

  LotW
    Adif export missing <MODE:n> <SUBMODE:n>

  Pedantic warnings
    correct additional gcc warnings

  dup-check
    Add 'possible dup' to logic with corresponding possible dup color
      dup color to CALL controls
    Separate N3FJP duplicate query from response
      response time was a part of keyboard input processing

  ADIF submode
    Add submode support
      export both MODE and SUBMODE to external loggers iaw
      ADIF spec 3.04

  QRZ.com
    change interface to QRZ XML service version 1.33

  SV1GRB test report
    Corrections based on Haris' testing of 4.1.00
    Add "NONE" or "N/A" to State and County pick lists

  SD counties
    sort alphabetically


This release does not include changes needed to give https access to METAR data.

73, David, W1HKJ


Kenneth C Miller
 

Hi Dave,

I have had a problem with your last two versions while xmiting compressed files via FLamp.  I get about
seven lines of data sent and then get a extended line length followed by a skipping of several lines.
Going back to using version 4.01.00 no problems working with FLamp 2.2.04. 

Running Windows 8.1 on Toshiba laptop. 

73 de Ken, K7IFG


-----Original Message-----
From: Dave <w1hkj@...>
To: Kamal Mostafa <kamal@...>; Richard Shaw <hobbes1069@...>; Diane Bruce <db@...>; Walter Fey <walter.fey@...>; Richard <pa3gwh@...>
Sent: Tue, Feb 19, 2019 6:08 am
Subject: [nbems] fldigi 4.1.01 release

Download at www.w1hkj.com/files/fldigi/ :

or Source Forge.

Version 4.1.01 - Maintenance release

  CW h/w ptt
    allow disabling CAT ptt when using external CW keyer such as nanoIO.

  nanoIO
    Bug fix to CW interface

  NAVTEX abort
    remove abort() statements from navtext afc processing
    fix serious bug which allowed fft filters to be destroyed during
    signal processing

  WF only bug fix

  LotW
    Adif export missing <MODE:n> <SUBMODE:n>

  Pedantic warnings
    correct additional gcc warnings

  dup-check
    Add 'possible dup' to logic with corresponding possible dup color
      dup color to CALL controls
    Separate N3FJP duplicate query from response
      response time was a part of keyboard input processing

  ADIF submode
    Add submode support
      export both MODE and SUBMODE to external loggers iaw
      ADIF spec 3.04

  QRZ.com
    change interface to QRZ XML service version 1.33

  SV1GRB test report
    Corrections based on Haris' testing of 4.1.00
    Add "NONE" or "N/A" to State and County pick lists

  SD counties
    sort alphabetically


This release does not include changes needed to give https access to METAR data.

73, David, W1HKJ


Mike P.
 

Dave, I'm getting the same flamp problem. On a multi-file
transmission with at least two passes, the second pass on
the second file stops after a few lines. Happens on any
op-mode, compressed or non-compressed.

73

--- Mike Pompey, AE7XB
Port Orchard, Washington state


On 19 Feb 2019 at 21:49, Kenneth C Miller via Groups.Io wrote:


Hi Dave,

I have had a problem with your last two versions while xmiting compressed files via FLamp.  I get
about
seven lines of data sent and then get a extended line length followed by a skipping of several
lines.
Going back to using version 4.01.00 no problems working with FLamp 2.2.04. 

Running Windows 8.1 on Toshiba laptop. 

73 de Ken, K7IFG




Electronics usually don't work after the magic smoke is released.

Dave
 

Check the deadman timer



Dave

On 2/19/19 5:29 PM, Mike P. wrote:

Dave, I'm getting the same flamp problem. On a multi-file
transmission with at least two passes, the second pass on
the second file stops after a few lines.  Happens on any
op-mode, compressed or non-compressed.

73

--- Mike Pompey, AE7XB
    Port Orchard, Washington state


On 19 Feb 2019 at 21:49, Kenneth C Miller via Groups.Io wrote:

Hi Dave,

I have had a problem with your last two versions while xmiting compressed files via FLamp.� I get
about
seven lines of data sent and then get a extended line length followed by a skipping of several
lines.
Going back to using version 4.01.00 no problems working with FLamp 2.2.04.�

Running Windows 8.1 on Toshiba laptop.�

73 de Ken, K7IFG




Electronics usually don't work after the magic smoke is released.







Dave
 

I will test here running a multifile flamp transmission.

Dave

On 2/19/19 9:26 PM, Dave wrote:
Check the deadman timer



Dave

On 2/19/19 5:29 PM, Mike P. wrote:
Dave, I'm getting the same flamp problem. On a multi-file
transmission with at least two passes, the second pass on
the second file stops after a few lines.  Happens on any
op-mode, compressed or non-compressed.

73

--- Mike Pompey, AE7XB
    Port Orchard, Washington state


On 19 Feb 2019 at 21:49, Kenneth C Miller via Groups.Io wrote:

Hi Dave,

I have had a problem with your last two versions while xmiting compressed files via FLamp.� I get
about
seven lines of data sent and then get a extended line length followed by a skipping of several
lines.
Going back to using version 4.01.00 no problems working with FLamp 2.2.04.�

Running Windows 8.1 on Toshiba laptop.�

73 de Ken, K7IFG


Electronics usually don't work after the magic smoke is released.








W. T. Jones
 

There does seem to be something amiss here.

On the first transmission of an 8PSK1200F file the headers were completely missed.

The second transmission using 8PSK1000F skipped blocks as shown...

<DATA 138 2817>{37A1:102}cC3k4mUwOIPwEHyTCaqa8VdBK01hgc3E0DT4yx38kt70N4ciLl/aOM+DHCJfalrKS
56OXO/Dk8c6T+rAbTNVtw8Il627X9waj7
<DATA 138 1AE2>{37A1:156}DasLoKNXRqHRHSfZmQC+clxaLcDJ/Cjt5b6T1v9jOrssApmyV1ycvtGIQ/xNbwM0sZ
7FbqU6gM2FI7l/VQgMtYGRDtlTuzpduTE6Hw6vbKZBGNVZgXaYo7Q3vUqAVwcK

On the 3rd transmission it reached the first 3 minute break and did not continue.

This file was sent Sunday night with 4.1.00 without any problems.

Regards,

WT
Real heroes do not wear capes. They wear dog tags, turnout gear, and badges!


On Tue, Feb 19, 2019 at 10:31 PM Dave <w1hkj@...> wrote:
I will test here running a multifile flamp transmission.

Dave

On 2/19/19 9:26 PM, Dave wrote:
Check the deadman timer



Dave

On 2/19/19 5:29 PM, Mike P. wrote:
Dave, I'm getting the same flamp problem. On a multi-file
transmission with at least two passes, the second pass on
the second file stops after a few lines.  Happens on any
op-mode, compressed or non-compressed.

73

--- Mike Pompey, AE7XB
    Port Orchard, Washington state


On 19 Feb 2019 at 21:49, Kenneth C Miller via Groups.Io wrote:

Hi Dave,

I have had a problem with your last two versions while xmiting compressed files via FLamp.� I get
about
seven lines of data sent and then get a extended line length followed by a skipping of several
lines.
Going back to using version 4.01.00 no problems working with FLamp 2.2.04.�

Running Windows 8.1 on Toshiba laptop.�

73 de Ken, K7IFG
Electronics usually don't work after the magic smoke is released.








Dave
 

Just had our first 1 hour interval without rain and thunderstorms in the past 48 hours.  I tested flamp 2.2.04 and fldigi 4.1.01 with multiple file transfers.  Both running on Linux Mint 18.3 / 32 bit.
  • 8psk125
  • file 1 800 bytes
  • file 2 2000 bytes
Used the "Xmt All" button on the Transmit tab of flamp dialog.  No issues with timeouts etc.

I am going to need more information on your h/w and s/w setup.
  • Computer h/w and operation system (version)
  • Transceiver
  • Audio interface
  • flamp version
  • fldigi version
  • copy of fldigi configuration file (fldigi_def.xml)
  • copy of flamp configuration file (FLAMP.prefs)
  • copies of candidate files being transferred
Send info and files direct to w1hkj at bellsouth dot net.

Dave

On 2/19/19 5:29 PM, Mike P. wrote:

Dave, I'm getting the same flamp problem. On a multi-file
transmission with at least two passes, the second pass on
the second file stops after a few lines.  Happens on any
op-mode, compressed or non-compressed.

73

--- Mike Pompey, AE7XB
    Port Orchard, Washington state


On 19 Feb 2019 at 21:49, Kenneth C Miller via Groups.Io wrote:

Hi Dave,

I have had a problem with your last two versions while xmiting compressed files via FLamp.� I get
about
seven lines of data sent and then get a extended line length followed by a skipping of several
lines.
Going back to using version 4.01.00 no problems working with FLamp 2.2.04.�

Running Windows 8.1 on Toshiba laptop.�

73 de Ken, K7IFG




Electronics usually don't work after the magic smoke is released.







gregsiemasz@...
 

Thank you for letting me join the group.
I am having a couple of issues with this version.
1: WX no longer works .
2: When I change frequency from 40m to 20m the Frq box stays in 40m making it impossible to save QSO correctly and send accurate QSL's via the program.
I tried to change the Frq by putting cursor in that field but nothing happened.
3. I try to input County information and nothing happens there either. If I click on the County tab or Frq tab I can see this ^ at front left but can not input any info.
I am running windows 10 Home 1803 and have had no issues with previous versions of Fldigi.
Below is just an example pic I got on line and is not the current version. The Frq is the same as the frequency. I pulled this pic off the internet.
I have uninstalled and reinstalled this version and it still has the same issues
I am new to this group and was not sure how to make the example smaller in the word processor.
Thank you and your help would be greatly appreciated.
Greg

Ed W3NR
 

On 2/25/19 8:16 AM, gregsiemasz@... wrote:
Thank you for letting me join the group.
I am having a couple of issues with this version.
1: WX no longer works .
Being worked on.
2: When I change frequency from 40m to 20m the Frq box stays in 40m making it impossible to save QSO correctly and send accurate QSL's via the program.
I tried to change the Frq by putting cursor in that field but nothing happened.
What are you using for rig control ?
3. I try to input County information and nothing happens there either. If I click on the County tab or Frq tab I can see this ^ at front left but can not input any info.
I am running windows 10 Home 1803 and have had no issues with previous versions of Fldigi.
Use the drop down.
Below is just an example pic I got on line and is not the current version. The Frq is the same as the frequency. I pulled this pic off the internet.
I have uninstalled and reinstalled this version and it still has the same issues
I am new to this group and was not sure how to make the example smaller in the word processor.
Thank you and your help would be greatly appreciated.
Greg

_._,_._,_

Ed W3NR

gregsiemasz@...
 

Ed,
I am not using any rig control. I never got it to work with my Ten-Tec Jupiter.
I am connected to radio via SignalLink USB.
I just not that savvy to figure out how to make any of the rig controls to work with this radio.
I thought that if I right clicked on the drop down that appears and give you RST,QTH State and County it would input where it should go under County.
Greg

Ed W3NR
 

On 2/25/19 1:02 PM, gregsiemasz@... wrote:
Ed,
I am not using any rig control. I never got it to work with my Ten-Tec Jupiter.
I was the alpha tester when the jupiter was added to flrrig and it worked perfectly, so I don't know what problem you had.
I am connected to radio via SignalLink USB.
I just not that savvy to figure out how to make any of the rig controls to work with this radio.
Without rig control it must be done manually.
I thought that if I right clicked on the drop down that appears and give you RST,QTH State and County it would input where it should go under County.
Is this a state QSO party ?
Greg
_._,_._,_

Ed W3NR

Your call ?

gregsiemasz@...
 

Ed
I don’t know anything about flrrig. There was no information from Ten-Tec or anyone else. So would you like to help me with that? I have been doing it manually and it wasn’t a problem. I got use to it. New software has bugs and I take it will be fixed eventually. 
Ed I don’t understand some of your questions. Can you elaborate?

On Mon, Feb 25, 2019 at 2:14 PM Ed W3NR <autek@...> wrote:
On 2/25/19 1:02 PM, gregsiemasz@... wrote:
Ed,
I am not using any rig control. I never got it to work with my Ten-Tec Jupiter.
I was the alpha tester when the jupiter was added to flrrig and it worked perfectly, so I don't know what problem you had.
I am connected to radio via SignalLink USB.
I just not that savvy to figure out how to make any of the rig controls to work with this radio.
Without rig control it must be done manually.
I thought that if I right clicked on the drop down that appears and give you RST,QTH State and County it would input where it should go under County.
Is this a state QSO party ?
Greg

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.


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.


Greg Siemasz <gregsiemasz@...>
 

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

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

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

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

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