Date   
Problem With Flamp

Ron
 

Hi Dave and the group,

I'm having a problem with Flamp and I don't know how to troubleshoot it.  It's not consistent so I didn't want to bring it up but it's a big problem especially during a net.  Here's my set up.

I'm running Linux Mint 19.0 Cinnamon on a desktop dual processors lots of memory and hard drive.   Fldigi ver4.1.02.20 and Flamp 2.2.05.12.  I've been keeping up with the Alpha versions to see if things get better.

So here's a few of the problems I have.  It seems to happen during busy nets and 2 or more Flamp messages were received.  Last night I received 2 Flamp.  The 2nd one I needed a fill of 5 blocks which I received.  When I was asked to send my Flamp I pressed Xmit and nothing happened.  When I closed Flamp, it closed but I started to transmit the Flamp disrupting the net.  I had to close Fldigi to stop the transmission.

Another time I tried to send an Flamp and Flamp shutdown and I received a message that there's no connection between Fldigi and Flamp.

Multiple times Flamp wouldn't open.

I'm not sure about this but it seems like my Flamp problems started with the addition of the message you get when you open Flamp before Fldigi and you get the message "start Fldigi before Flamp".  I think that was Fldigi 4.1.01 and Flamp 2.2.04.

I've heard of problems also with Windows OS so I figured I would post to the NBEMS group to cover Linux and Windows.

73, Ron NY3J

Re: Problem With Flamp

Ron
 

Follow up.  So I just tried to send a Flamp file.  Now I really broke Flamp :-)  When I select Xmit, it looks like it will send it to Fldigi but Fldigi doesn't respond.  When I close Flamp the file starts to transmit.  I let it finish and start Flamp.  When I try to send another file it does the same thing.  I have renamed the Fldigi and Flamp pref files and that doesn't fix it.  I haven't re-installed anything yet.

73, Ron NY3J

On 3/22/19 7:45 AM, Ron via Groups.Io wrote:
Hi Dave and the group,

I'm having a problem with Flamp and I don't know how to troubleshoot it.  It's not consistent so I didn't want to bring it up but it's a big problem especially during a net.  Here's my set up.

I'm running Linux Mint 19.0 Cinnamon on a desktop dual processors lots of memory and hard drive.   Fldigi ver4.1.02.20 and Flamp 2.2.05.12.  I've been keeping up with the Alpha versions to see if things get better.

So here's a few of the problems I have.  It seems to happen during busy nets and 2 or more Flamp messages were received.  Last night I received 2 Flamp.  The 2nd one I needed a fill of 5 blocks which I received.  When I was asked to send my Flamp I pressed Xmit and nothing happened.  When I closed Flamp, it closed but I started to transmit the Flamp disrupting the net.  I had to close Fldigi to stop the transmission.

Another time I tried to send an Flamp and Flamp shutdown and I received a message that there's no connection between Fldigi and Flamp.

Multiple times Flamp wouldn't open.

I'm not sure about this but it seems like my Flamp problems started with the addition of the message you get when you open Flamp before Fldigi and you get the message "start Fldigi before Flamp".  I think that was Fldigi 4.1.01 and Flamp 2.2.04.

I've heard of problems also with Windows OS so I figured I would post to the NBEMS group to cover Linux and Windows.

73, Ron NY3J


Shortwave Radiogram, 22-24 March 2019

kd9xb
 

Shortwave Radiogram this weekend is in MFSK32, Thor 50x1, and MFSK64, with eight MFSK images.

http://swradiogram.net/post/183628089787/shortwave-radiogram-22-24-march-2019-not-worried

Kim
KD9XB

Re: FLAMP New feature idea - maybe

AD5XJ, KEN
 

BPQ32 is only on Windows. LinBPQ does work woth FLDIGI but would have to use ARIM or something for messages and still would not fill out the conceptual functions needed.

Re: FLAMP New feature idea - maybe

Don Poaps
 

Like Linbpq and BPQ32 will do the same thing. They use fldigi as an engine similar to what n1mm uses

The only difference of the two os is comport and /dev/ttyUSB0?

If I remember you could use fldigi to connect c callsign-7 to the 40 m using bpq 

Later

Don

On Fri, Mar 22, 2019 at 08:39 AD5XJ, KEN <ad5xj@...> wrote:
BPQ32 is only on Windows. LinBPQ does work woth FLDIGI but would have to use ARIM or something for messages and still would not fill out the conceptual functions needed.

--
Don Poaps
New Westminster, BC
VA7DGP DATA
VA7QU   VOICE


Winlink: va7qu@...
Subject://wl2k           



                    
  




 

Re: FLAMP New feature idea - maybe

AD5XJ, KEN
 

Yes functionally, BPQ32 and LinBPQ are both data directors.

The problem is what to do with the data (a message) after FLDIGI decodes and passes it to BPQ32. For mail that could be AirMail or ARIM for LinBPQ. But if you review my original post the purpose exceeds those simple functionality of most mail clients.

Additionally, the idea is to be self-contained so that there is no internal reliance on Internet mail or WinLINK. My initial concept was to use FLAMP to decode the message error free, get the "postoffice" token and perform the sort and store functions for "mail" or other type messages.

In WinLINK-Like terms, this is sort of like RMS Relay. Except it uses FLDIGI as the modem and not WinMOR or ARDOP. The Internet could be used for a email destination, but not for broadcast to the group and not for another ham on that frequency, possibly a group member.

Remember not all messages are email. Some may be reports (like ICDS-213or 214) or plaintext messages of any type destined for another station nearby.

Re: FLAMP New feature idea - maybe

Don Poaps
 

You create bulletin when you send a message to Linbpq. SB ad5xj-7

All who call connect to ad5xj-7 can either do RMS, or BBS where the bulletin is. I know you want to broadcast to reception centres. Here the reception Center uses tnc to log into Vancover va7eoc-11 where the radio Room is. The radio guys log into the bbs using network computer they post bulletin. Using fldigi could be done the same way. 

Later

73

Don


On Fri, Mar 22, 2019 at 10:39 AD5XJ, KEN <ad5xj@...> wrote:

Yes functionally, BPQ32 and LinBPQ are both data directors.

The problem is what to do with the data (a message) after FLDIGI decodes and passes it to BPQ32. For mail that could be AirMail or ARIM for LinBPQ. But if you review my original post the purpose exceeds those simple functionality of most mail clients.

Additionally, the idea is to be self-contained so that there is no internal reliance on Internet mail or WinLINK. My initial concept was to use FLAMP to decode the message error free, get the "postoffice" token and perform the sort and store functions for "mail" or other type messages.

In WinLINK-Like terms, this is sort of like RMS Relay. Except it uses FLDIGI as the modem and not WinMOR or ARDOP. The Internet could be used for a email destination, but not for broadcast to the group and not for another ham on that frequency, possibly a group member.

Remember not all messages are email. Some may be reports (like ICDS-213or 214) or plaintext messages of any type destined for another station nearby.

--
Don Poaps
New Westminster, BC
VA7DGP DATA
VA7QU   VOICE


Winlink: va7qu@...
Subject://wl2k           



                    
  




 

Re: Problem With Flamp

Dave
 

The latest fldigi alpha is .26

The latest flamp alpha is .12

These two play together correctly on Mint-18.3 / 32, Xfce desktop manager

No application lockups etc.

Suggest you use the posted alpha pair.

73, David, W1HKJ


Re: Problem With Flamp

Ron
 

Thanks Dave,

Installed and ready to roll.  I notice that there's about a 1.47 second delay in key up.  That looks like a good thing to make sure nothing is missed in the beginning.

I had to look closely at the callsign k2lbm.  I thought you were testing with a fellow IBMer :-)

73, Ron NY3J

On 3/22/19 2:01 PM, Dave wrote:
The latest fldigi alpha is .26

The latest flamp alpha is .12

These two play together correctly on Mint-18.3 / 32, Xfce desktop manager

No application lockups etc.

Suggest you use the posted alpha pair.

73, David, W1HKJ



Re: Problem With Flamp

Dave
 

My original call K2LBM in 1957 ... never been re-issued.

Dave

On 3/22/19 4:16 PM, Ron via Groups.Io wrote:
Thanks Dave,

Installed and ready to roll.  I notice that there's about a 1.47 second delay in key up.  That looks like a good thing to make sure nothing is missed in the beginning.

I had to look closely at the callsign k2lbm.  I thought you were testing with a fellow IBMer :-)

73, Ron NY3J

On 3/22/19 2:01 PM, Dave wrote:
The latest fldigi alpha is .26

The latest flamp alpha is .12

These two play together correctly on Mint-18.3 / 32, Xfce desktop manager

No application lockups etc.

Suggest you use the posted alpha pair.

73, David, W1HKJ




Re: Problem With Flamp

W. T. Jones
 

Hey Ron,

I seem to have the problem here. This is the event log for the fault.

Log Name:      Application
Source:        Application Error
Date:          3/22/2019 21:21:41
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      score1
Description:
Faulting application name: flamp.exe, version: 0.0.0.0, time stamp: 0x00000000
Faulting module name: flamp.exe, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x000e432b
Faulting process id: 0x1ffc
Faulting application start time: 0x01d4e116c50e3054
Faulting application path: C:\Program Files (x86)\flamp-2.2.05.12\flamp.exe
Faulting module path: C:\Program Files (x86)\flamp-2.2.05.12\flamp.exe
Report Id: fe7835ff-0846-4a95-af43-811a38344cf6
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-03-23T01:21:41.718479000Z" />
    <EventRecordID>6777</EventRecordID>
    <Channel>Application</Channel>
    <Computer>score1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>flamp.exe</Data>
    <Data>0.0.0.0</Data>
    <Data>00000000</Data>
    <Data>flamp.exe</Data>
    <Data>0.0.0.0</Data>
    <Data>00000000</Data>
    <Data>c0000005</Data>
    <Data>000e432b</Data>
    <Data>1ffc</Data>
    <Data>01d4e116c50e3054</Data>
    <Data>C:\Program Files (x86)\flamp-2.2.05.12\flamp.exe</Data>
    <Data>C:\Program Files (x86)\flamp-2.2.05.12\flamp.exe</Data>
    <Data>fe7835ff-0846-4a95-af43-811a38344cf6</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

Don't know if it helps or not.

Seems rather inconsistent though.
1. Start Fldigi and then Flamp. Click on the transmit tab and Flamp crashes.
2. Restart Flamp. Click on Transmit tab, load a file, click on xmit and no transmit on the rig (using flrig control).
Hit xmit again and it starts transmitting.
3. Shutdown fldigi and flamp. Restart both. Everything works as advertised.

The Windows Error Report file is attached.

--fldigi--
Just an added note. Fldigi hung. One time only. Here is the event log entry.

Log Name:      Application
Source:        Application Hang
Date:          3/22/2019 21:15:59
Event ID:      1002
Task Category: (101)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      score1
Description:
The program fldigi.exe version 4.1.0.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.
 Process ID: 1074
 Start Time: 01d4e11560b28adf
 Termination Time: 41
 Application Path: C:\Program Files (x86)\Fldigi-4.1.02.26\fldigi.exe
 Report Id: ea81754e-65b2-4673-8f12-3dd234f3ca20
 Faulting package full name:
 Faulting package-relative application ID:
 Hang type: Cross-thread

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Hang" />
    <EventID Qualifiers="0">1002</EventID>
    <Level>2</Level>
    <Task>101</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-03-23T01:15:59.797174500Z" />
    <EventRecordID>6776</EventRecordID>
    <Channel>Application</Channel>
    <Computer>score1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>fldigi.exe</Data>
    <Data>4.1.0.0</Data>
    <Data>1074</Data>
    <Data>01d4e11560b28adf</Data>
    <Data>41</Data>
    <Data>C:\Program Files (x86)\Fldigi-4.1.02.26\fldigi.exe</Data>
    <Data>ea81754e-65b2-4673-8f12-3dd234f3ca20</Data>
    <Data>
    </Data>
    <Data>
    </Data>
    <Data>Cross-thread</Data>
    <Binary>430072006F00730073002D0074006800720065006100640000000000</Binary>
  </EventData>
</Event>

Same code works fine on Ubuntu.

Dang Windows!

Dave, if there is any other data I can provide let me know!

Regards,

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


On Fri, Mar 22, 2019 at 6:50 PM Dave <w1hkj@...> wrote:
My original call K2LBM in 1957 ... never been re-issued.

Dave

On 3/22/19 4:16 PM, Ron via Groups.Io wrote:
Thanks Dave,

Installed and ready to roll.  I notice that there's about a 1.47 second delay in key up.  That looks like a good thing to make sure nothing is missed in the beginning.

I had to look closely at the callsign k2lbm.  I thought you were testing with a fellow IBMer :-)

73, Ron NY3J

On 3/22/19 2:01 PM, Dave wrote:
The latest fldigi alpha is .26

The latest flamp alpha is .12

These two play together correctly on Mint-18.3 / 32, Xfce desktop manager

No application lockups etc.

Suggest you use the posted alpha pair.

73, David, W1HKJ




Re: Problem With Flamp

Ron
 

Hi WT,

I've been giving Fldigi ver 4.1.02.26 and Flamp 2.2.05.12 a pretty good workout, both Windows and Mint and so far no failures.

73, Ron NY3J

On 3/22/19 9:36 PM, W. T. Jones wrote:
Hey Ron,

I seem to have the problem here. This is the event log for the fault.

Log Name:      Application
Source:        Application Error
Date:          3/22/2019 21:21:41
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      score1
Description:
Faulting application name: flamp.exe, version: 0.0.0.0, time stamp: 0x00000000
Faulting module name: flamp.exe, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x000e432b
Faulting process id: 0x1ffc
Faulting application start time: 0x01d4e116c50e3054
Faulting application path: C:\Program Files (x86)\flamp-2.2.05.12\flamp.exe
Faulting module path: C:\Program Files (x86)\flamp-2.2.05.12\flamp.exe
Report Id: fe7835ff-0846-4a95-af43-811a38344cf6
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-03-23T01:21:41.718479000Z" />
    <EventRecordID>6777</EventRecordID>
    <Channel>Application</Channel>
    <Computer>score1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>flamp.exe</Data>
    <Data>0.0.0.0</Data>
    <Data>00000000</Data>
    <Data>flamp.exe</Data>
    <Data>0.0.0.0</Data>
    <Data>00000000</Data>
    <Data>c0000005</Data>
    <Data>000e432b</Data>
    <Data>1ffc</Data>
    <Data>01d4e116c50e3054</Data>
    <Data>C:\Program Files (x86)\flamp-2.2.05.12\flamp.exe</Data>
    <Data>C:\Program Files (x86)\flamp-2.2.05.12\flamp.exe</Data>
    <Data>fe7835ff-0846-4a95-af43-811a38344cf6</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

Don't know if it helps or not.

Seems rather inconsistent though.
1. Start Fldigi and then Flamp. Click on the transmit tab and Flamp crashes.
2. Restart Flamp. Click on Transmit tab, load a file, click on xmit and no transmit on the rig (using flrig control).
Hit xmit again and it starts transmitting.
3. Shutdown fldigi and flamp. Restart both. Everything works as advertised.

The Windows Error Report file is attached.

--fldigi--
Just an added note. Fldigi hung. One time only. Here is the event log entry.

Log Name:      Application
Source:        Application Hang
Date:          3/22/2019 21:15:59
Event ID:      1002
Task Category: (101)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      score1
Description:
The program fldigi.exe version 4.1.0.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.
 Process ID: 1074
 Start Time: 01d4e11560b28adf
 Termination Time: 41
 Application Path: C:\Program Files (x86)\Fldigi-4.1.02.26\fldigi.exe
 Report Id: ea81754e-65b2-4673-8f12-3dd234f3ca20
 Faulting package full name:
 Faulting package-relative application ID:
 Hang type: Cross-thread

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Hang" />
    <EventID Qualifiers="0">1002</EventID>
    <Level>2</Level>
    <Task>101</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-03-23T01:15:59.797174500Z" />
    <EventRecordID>6776</EventRecordID>
    <Channel>Application</Channel>
    <Computer>score1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>fldigi.exe</Data>
    <Data>4.1.0.0</Data>
    <Data>1074</Data>
    <Data>01d4e11560b28adf</Data>
    <Data>41</Data>
    <Data>C:\Program Files (x86)\Fldigi-4.1.02.26\fldigi.exe</Data>
    <Data>ea81754e-65b2-4673-8f12-3dd234f3ca20</Data>
    <Data>
    </Data>
    <Data>
    </Data>
    <Data>Cross-thread</Data>
    <Binary>430072006F00730073002D0074006800720065006100640000000000</Binary>
  </EventData>
</Event>

Same code works fine on Ubuntu.

Dang Windows!

Dave, if there is any other data I can provide let me know!

Regards,

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


On Fri, Mar 22, 2019 at 6:50 PM Dave <w1hkj@...> wrote:
My original call K2LBM in 1957 ... never been re-issued.

Dave

On 3/22/19 4:16 PM, Ron via Groups.Io wrote:
Thanks Dave,

Installed and ready to roll.  I notice that there's about a 1.47 second delay in key up.  That looks like a good thing to make sure nothing is missed in the beginning.

I had to look closely at the callsign k2lbm.  I thought you were testing with a fellow IBMer :-)

73, Ron NY3J

On 3/22/19 2:01 PM, Dave wrote:
The latest fldigi alpha is .26

The latest flamp alpha is .12

These two play together correctly on Mint-18.3 / 32, Xfce desktop manager

No application lockups etc.

Suggest you use the posted alpha pair.

73, David, W1HKJ





Re: Problem With Flamp

Ron
 

GM Dave,

So with the new Fldigi ver 4.1.02.26 and Flamp 2.2.05.12 I close Flamp and try to close Fldigi and Fldigi fails to close so I have to kill it.

This morning on the NY NBEMS Net using Flmsg 4.0.8.04 Flmsg failed to send.  I closed Flmsg and Fldigi and restarted and Flmsg still failed.  I had to reboot and it worked.  The following is my netstat log.  The first one is when Flmsg failed.  The second one is after the reboot and Flmsg worked.  So I'm not sure if the new Flamp broke Flmsg but as usual it's intermittent.


ny3j@ny3j-Studio-XPS-435T-9000:~$ netstat -plnat | grep 73*
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.53:53           0.0.0.0:* LISTEN      -
tcp        0      0 127.0.0.1:631           0.0.0.0:* LISTEN      -
tcp        0      0 127.0.0.1:7322          0.0.0.0:* LISTEN      1778/fldigi
tcp        6      0 0.0.0.0:7362            0.0.0.0:* LISTEN      1778/fldigi
tcp      211      0 127.0.0.1:7362          127.0.0.1:44364 CLOSE_WAIT  -
tcp        0      0 127.0.0.1:7322          127.0.0.1:41194 CLOSE_WAIT  1778/fldigi
tcp        0      0 127.0.0.1:44437         127.0.0.1:43150 ESTABLISHED 3052/flmsg
tcp        0      0 127.0.0.1:43150         127.0.0.1:44437 ESTABLISHED 3052/flmsg
tcp      211      0 127.0.0.1:7362          127.0.0.1:44362 CLOSE_WAIT  -
tcp      204      0 127.0.0.1:7362          127.0.0.1:44358 CLOSE_WAIT  1778/fldigi
tcp      211      0 127.0.0.1:7362          127.0.0.1:44366 CLOSE_WAIT  -
tcp        1      0 127.0.0.1:7362          127.0.0.1:44170 CLOSE_WAIT  1778/fldigi
tcp      211      0 127.0.0.1:7362          127.0.0.1:44370 CLOSE_WAIT  -
tcp      211      0 127.0.0.1:7362          127.0.0.1:44368 CLOSE_WAIT  -
tcp        0      1 127.0.0.1:51258         127.0.0.1:7362 SYN_SENT    3052/flmsg
tcp      211      0 127.0.0.1:7362          127.0.0.1:44360 CLOSE_WAIT  -
tcp      207      0 127.0.0.1:7362          127.0.0.1:44174 CLOSE_WAIT  1778/fldigi
tcp      204      0 127.0.0.1:7362          127.0.0.1:44342 CLOSE_WAIT  1778/fldigi
ny3j@ny3j-Studio-XPS-435T-9000:~$
ny3j@ny3j-Studio-XPS-435T-9000:~$ netstat -plnat | grep 73*
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1734/flmsg         
tcp        0      0 0.0.0.0:8081            0.0.0.0:*               LISTEN      1791/flmsg         
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:7322          0.0.0.0:*               LISTEN      1626/fldigi        
tcp        0      0 0.0.0.0:7362            0.0.0.0:*               LISTEN      1626/fldigi        
tcp        0    206 127.0.0.1:7362          127.0.0.1:42334         ESTABLISHED 1626/fldigi        
tcp        0      0 127.0.0.1:55181         127.0.0.1:42464         ESTABLISHED 1791/flmsg         
tcp        0      0 127.0.0.1:42334         127.0.0.1:7362          ESTABLISHED 1791/flmsg         
tcp        0      0 127.0.0.1:42362         127.0.0.1:7362          ESTABLISHED 2604/flamp         
tcp        0      0 127.0.0.1:7322          127.0.0.1:49786         ESTABLISHED 1626/fldigi        
tcp        0      0 127.0.0.1:42366         127.0.0.1:7362          ESTABLISHED 2615/flmsg         
tcp        0      0 127.0.0.1:44639         127.0.0.1:41900         ESTABLISHED 1734/flmsg         
tcp        0      0 127.0.0.1:60753         127.0.0.1:37992         ESTABLISHED 2615/flmsg         
tcp        0      0 127.0.0.1:42328         127.0.0.1:7362          ESTABLISHED 1734/flmsg         
tcp        0      0 127.0.0.1:7362          127.0.0.1:42362         ESTABLISHED 1626/fldigi        
tcp        0    216 127.0.0.1:7362          127.0.0.1:42328         ESTABLISHED 1626/fldigi        
tcp        0    216 127.0.0.1:7362          127.0.0.1:42366         ESTABLISHED 1626/fldigi        
tcp        0      0 127.0.0.1:37992         127.0.0.1:60753         ESTABLISHED 2615/flmsg         
tcp        0      0 127.0.0.1:41900         127.0.0.1:44639         ESTABLISHED 1734/flmsg         
tcp        0      0 127.0.0.1:49786         127.0.0.1:7322          ESTABLISHED 2604/flamp         
tcp        0      0 127.0.0.1:42464         127.0.0.1:55181         ESTABLISHED 1791/flmsg         
ny3j@ny3j-Studio-XPS-435T-9000:~$

73, Ron NY3J

On 3/22/19 2:01 PM, Dave wrote:
The latest fldigi alpha is .26

The latest flamp alpha is .12

These two play together correctly on Mint-18.3 / 32, Xfce desktop manager

No application lockups etc.

Suggest you use the posted alpha pair.

73, David, W1HKJ



icom 7300

George
 

I have a new Icom 7300 and want to know how to set up for Psk 31
Can anyone help
73 George AA4GT

Re: Problem With Flamp

Dave
 

Ron,

The hang on close has been fixed.  Thanks for the report.

I've added you to my list of NBEMS testers and you should be receiving an email regarding the latest alpha versions of fldigi, flamp, flmsg and fllog. 

Email should arrive within the hour.

Dave

On 3/23/19 8:52 AM, Ron via Groups.Io wrote:
GM Dave,

So with the new Fldigi ver 4.1.02.26 and Flamp 2.2.05.12 I close Flamp and try to close Fldigi and Fldigi fails to close so I have to kill it.

This morning on the NY NBEMS Net using Flmsg 4.0.8.04 Flmsg failed to send.  I closed Flmsg and Fldigi and restarted and Flmsg still failed.  I had to reboot and it worked.  The following is my netstat log.  The first one is when Flmsg failed.  The second one is after the reboot and Flmsg worked.  So I'm not sure if the new Flamp broke Flmsg but as usual it's intermittent.


ny3j@ny3j-Studio-XPS-435T-9000:~$ netstat -plnat | grep 73*
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.53:53           0.0.0.0:* LISTEN      -
tcp        0      0 127.0.0.1:631           0.0.0.0:* LISTEN      -
tcp        0      0 127.0.0.1:7322          0.0.0.0:* LISTEN      1778/fldigi
tcp        6      0 0.0.0.0:7362            0.0.0.0:* LISTEN      1778/fldigi
tcp      211      0 127.0.0.1:7362          127.0.0.1:44364 CLOSE_WAIT  -
tcp        0      0 127.0.0.1:7322          127.0.0.1:41194 CLOSE_WAIT  1778/fldigi
tcp        0      0 127.0.0.1:44437         127.0.0.1:43150 ESTABLISHED 3052/flmsg
tcp        0      0 127.0.0.1:43150         127.0.0.1:44437 ESTABLISHED 3052/flmsg
tcp      211      0 127.0.0.1:7362          127.0.0.1:44362 CLOSE_WAIT  -
tcp      204      0 127.0.0.1:7362          127.0.0.1:44358 CLOSE_WAIT  1778/fldigi
tcp      211      0 127.0.0.1:7362          127.0.0.1:44366 CLOSE_WAIT  -
tcp        1      0 127.0.0.1:7362          127.0.0.1:44170 CLOSE_WAIT  1778/fldigi
tcp      211      0 127.0.0.1:7362          127.0.0.1:44370 CLOSE_WAIT  -
tcp      211      0 127.0.0.1:7362          127.0.0.1:44368 CLOSE_WAIT  -
tcp        0      1 127.0.0.1:51258         127.0.0.1:7362 SYN_SENT    3052/flmsg
tcp      211      0 127.0.0.1:7362          127.0.0.1:44360 CLOSE_WAIT  -
tcp      207      0 127.0.0.1:7362          127.0.0.1:44174 CLOSE_WAIT  1778/fldigi
tcp      204      0 127.0.0.1:7362          127.0.0.1:44342 CLOSE_WAIT  1778/fldigi
ny3j@ny3j-Studio-XPS-435T-9000:~$
ny3j@ny3j-Studio-XPS-435T-9000:~$ netstat -plnat | grep 73*
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1734/flmsg         
tcp        0      0 0.0.0.0:8081            0.0.0.0:*               LISTEN      1791/flmsg         
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:7322          0.0.0.0:*               LISTEN      1626/fldigi        
tcp        0      0 0.0.0.0:7362            0.0.0.0:*               LISTEN      1626/fldigi        
tcp        0    206 127.0.0.1:7362          127.0.0.1:42334         ESTABLISHED 1626/fldigi        
tcp        0      0 127.0.0.1:55181         127.0.0.1:42464         ESTABLISHED 1791/flmsg         
tcp        0      0 127.0.0.1:42334         127.0.0.1:7362          ESTABLISHED 1791/flmsg         
tcp        0      0 127.0.0.1:42362         127.0.0.1:7362          ESTABLISHED 2604/flamp         
tcp        0      0 127.0.0.1:7322          127.0.0.1:49786         ESTABLISHED 1626/fldigi        
tcp        0      0 127.0.0.1:42366         127.0.0.1:7362          ESTABLISHED 2615/flmsg         
tcp        0      0 127.0.0.1:44639         127.0.0.1:41900         ESTABLISHED 1734/flmsg         
tcp        0      0 127.0.0.1:60753         127.0.0.1:37992         ESTABLISHED 2615/flmsg         
tcp        0      0 127.0.0.1:42328         127.0.0.1:7362          ESTABLISHED 1734/flmsg         
tcp        0      0 127.0.0.1:7362          127.0.0.1:42362         ESTABLISHED 1626/fldigi        
tcp        0    216 127.0.0.1:7362          127.0.0.1:42328         ESTABLISHED 1626/fldigi        
tcp        0    216 127.0.0.1:7362          127.0.0.1:42366         ESTABLISHED 1626/fldigi        
tcp        0      0 127.0.0.1:37992         127.0.0.1:60753         ESTABLISHED 2615/flmsg         
tcp        0      0 127.0.0.1:41900         127.0.0.1:44639         ESTABLISHED 1734/flmsg         
tcp        0      0 127.0.0.1:49786         127.0.0.1:7322          ESTABLISHED 2604/flamp         
tcp        0      0 127.0.0.1:42464         127.0.0.1:55181         ESTABLISHED 1791/flmsg         
ny3j@ny3j-Studio-XPS-435T-9000:~$

73, Ron NY3J

On 3/22/19 2:01 PM, Dave wrote:
The latest fldigi alpha is .26

The latest flamp alpha is .12

These two play together correctly on Mint-18.3 / 32, Xfce desktop manager

No application lockups etc.

Suggest you use the posted alpha pair.

73, David, W1HKJ




Re: icom 7300

Gil Jones
 

Get fldigi, connect rig to computer and the internal sound card takes care of you. Decent instruction in the manual.


On Sat, Mar 23, 2019, 9:25 AM George <aa4gt@...> wrote:
I have a new Icom 7300 and want to know how to set up for Psk 31
Can anyone help
73 George AA4GT

WEFAX question

Mitch Smith
 

When I receive WEFAX images they are crooked. They have been this way thorough many versions of fldigi going back several years.

Slant and align are both set to 0. If I change either it just makes the images worse.

What am I doing wrong?

I'm attaching an example.

Thanks for any help you can offer.

--
Mitchell Smith
Chief Engineer
M/V Elizabeth Anne

--
Mitchell K Smith
Millstone Forge
5197 Millstone Rd
Monroeton, PA 18832
570-265-0673
KB3GKC

Re: WEFAX question

Dave
 

Align moves the image left and right.

Slant should correct for the distortion you show in your image. What version of fldigi are you running?

David

On 3/29/19 1:32 PM, Mitch Smith wrote:
When I receive WEFAX images they are crooked. They have been this way thorough many versions of fldigi going back several years.

Slant and align are both set to 0. If I change either it just makes the images worse.

What am I doing wrong?

I'm attaching an example.

Thanks for any help you can offer.

Re: WEFAX question

Mitch Smith
 

Currently running 4.0.18.
I'll try slant again as soon as I can. Maybe I was doing it wrong.

Thank you.

On 3/29/2019 14:41, Dave wrote:
Align moves the image left and right.
Slant should correct for the distortion you show in your image. What version of fldigi are you running?
David
On 3/29/19 1:32 PM, Mitch Smith wrote:
When I receive WEFAX images they are crooked. They have been this way thorough many versions of fldigi going back several years.

Slant and align are both set to 0. If I change either it just makes the images worse.

What am I doing wrong?

I'm attaching an example.

Thanks for any help you can offer.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: WEFAX question

Ed Gabbard
 


I think your just a tad off frequency the way it sounds. Try fine tuning it.

On Fri, Mar 29, 2019 at 1:41 PM, Dave
<w1hkj@...> wrote:
Align moves the image left and right.

Slant should correct for the distortion you show in your image. What
version of fldigi are you running?

David

On 3/29/19 1:32 PM, Mitch Smith wrote:
> When I receive WEFAX images they are crooked. They have been this way
> thorough many versions of fldigi going back several years.
>
> Slant and align are both set to 0. If I change either it just makes
> the images worse.
>
> What am I doing wrong?
>
> I'm attaching an example.
>
> Thanks for any help you can offer.
>