Date   
Yaesu FT-897D New In The Box

Dave
 

We do not usually post for sale items on this group, but Toney, K2MO, has a never used FT-897D for sale that would be a great buy for use on the digital modes.  The FT-897D is fully supported by fldigi and flrig.  I would snap this one up myself, but I already have more than one two three ... many rigs.

Dave

All:

I purchased a new unopened box Yaesu FT-897D from an estate sale. It came with the FP-30 A/C power supply and a Yaesu 300 Hz CW filter that was also unopened in the box. I tested the radio and it looks and functions like a new transceiver.

It's an all-mode HF, 50/144/430 MHz transceiver that comes with 60 meters and the TXCO from the factory. It can be used with internal batteries or the internal FP-30 A/C power supply that it came with.

I can provide pictures for those interested. My email address is: dxdx@...

Tony -K2MO

Re: FLAMP New feature idea - maybe

AD5XJ, KEN
 

Modes like FSQ and IFKP are fun and work great.
However, they are of little practical use in the concept discussed here. We need to leverage the fastest and most reliable mode FLDIGI can provide for conditions in order to handle high traffic situations. This is often the case in a disaster where there is a lot of ICS or H&W traffic that needs to be moved. Support organizations like The Salvation Army, or Red Cross may want to use this concept to move H&W messages out of the area quickly to a remote station that is online.

Once again the concept is to make NBEMS less reliant on other software and media and to leverage the strong aspects of FLAMP. Since NBEMS is available on almost all platforms including Raspberry Pi (Raspian) it is also economically more desirable than SCS modes or hardware TNC equipment.

ARIM is a good messaging program and works well on the Linux platform with LinBPQ but is not part of NBEMS and requires a modem like ARDOP or direwolf. The goal is to make a good fit in NBEMS and be independent of other software.

Re: FLAMP New feature idea - maybe

David Ranch
 


Hello Ken,

Interesting idea and I like the concept.  Since this isn't available today, I do have some alternative ideas for you.

For basic messaging, Fldigi's FSQ support can do most of what you ask as it does have the ability to store and retrieve messages.  It only uses a the IFKP mode, has a unique user interface, and doesn't use the power of the Flamp multicast transport but it does work well.  Digging a little deeper, you could use any packet programs that have messaging store/forward capability with Fldigi via Fldigi's KISS interface.  This also wouldn't leverage the Flamp multicast concept but it would give you a lot of powerful options.  The selection of the packet program would depend on the OS you're running be it Windows, Linux, Mac, etc.  Finally, similar to Fldigi's FSQ functionality is the ARiM program with the ARDOP v1 modem.

--David
KI6ZHD



On 03/30/2019 06:26 AM, AD5XJ, KEN wrote:

The point I would like to re-emphasize is that the concept  is intended for smaller groups of connecting stations that do not necessarily all have repeaters, Internet access, or WinLINK access. This happens quite often in emergency situations.

The concept is designed to allow NBEMS groups to still operate over a wide area without the need of expensive external TNC equipment.

The NBEMS suite has that capability with FLDIGI / FLMSG / FLAMP and a central connecting station with Internet access. The "postoffice" station could act as a temporary message relay station for all types of messages - not just Internet email. The message formatting capability is already built in to FLMSG so the receiver of the message is familiar with the format.

To do all this, added functionality has to exist to reduce the effort needed in message handling with large volume. This could be a separate module similar to FLAMP or part of FLAMP. It seems logical to fit into FLAMP since some messages may be used to broadcast, and others sent to specific stations who have reported for this duty, or forwarded to an email address using store and forward software methods.

I think the new feature would require routing tags in the message so the "postoffice" would know what to do with it.
Also, to limit traffic and abuse, the "postoffice" should have a registry of participating stations and only respond to those stations for routing functions.

The suggestion has been made that this is like PACKET used to be. That is true. But PACKET was for the most part VHF/UHF. To get this type of functionality on HF currently HF PACKET exists but very sparse. It leans more to widely separated nodes not always available (not to mention it is slower than VHF/UHF).

I know this concept is sort of - been there done that - kind of thing. The effort is to not only revive it but improve it for use in very flexible situations using any available mode over any available media path using NBEMS software only.


Re: WEFAX question

kd8ftr@...
 

Step 1 is calibration of the sound card. Use NIST signal and set fldigi to wwv let it run a while to verify a vertical line on the scope. 
Step 2 is adjusting the slant while receiving. This will compensate for the timing difference from processing. Once set your future receiptions will be correct



On Fri, Mar 29, 2019 at 2:35 PM, Mitch Smith
<m.smith64@...> 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.

--
Mitchell Smith
Chief Engineer
M/V Elizabeth Anne

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





Re: FLAMP New feature idea - maybe

Don Poaps
 

Ken

I have had my 3 windows pc disabled by windows up dates. Mic privacy on but no audio even when I’ve switched Signalink and cables. Looks like I have to learn how to load load fldigi and the suites into my Pi and get back on the air. 
Locally our incident commander showed an interest in sending a copy of the declaration of emergency to the reception Center. We use Winlink to communicate to our provincial and local EOC. 
May 12 there a massive Earthquake Exercise in the city of Vancouver BC and the Salvation Army is having a tabletop exercise as well. I heard that for an hour in the city  event there will be no phones. 

If I get a chance I’ll try use fldigi from our EOC in Abbotsford depending on how busy I get

Later

Don va7dgp 

On Sat, Mar 30, 2019 at 06:26 AD5XJ, KEN <ad5xj@...> wrote:

The point I would like to re-emphasize is that the concept  is intended for smaller groups of connecting stations that do not necessarily all have repeaters, Internet access, or WinLINK access. This happens quite often in emergency situations.

The concept is designed to allow NBEMS groups to still operate over a wide area without the need of expensive external TNC equipment.

The NBEMS suite has that capability with FLDIGI / FLMSG / FLAMP and a central connecting station with Internet access. The "postoffice" station could act as a temporary message relay station for all types of messages - not just Internet email. The message formatting capability is already built in to FLMSG so the receiver of the message is familiar with the format.

To do all this, added functionality has to exist to reduce the effort needed in message handling with large volume. This could be a separate module similar to FLAMP or part of FLAMP. It seems logical to fit into FLAMP since some messages may be used to broadcast, and others sent to specific stations who have reported for this duty, or forwarded to an email address using store and forward software methods.

I think the new feature would require routing tags in the message so the "postoffice" would know what to do with it.
Also, to limit traffic and abuse, the "postoffice" should have a registry of participating stations and only respond to those stations for routing functions.

The suggestion has been made that this is like PACKET used to be. That is true. But PACKET was for the most part VHF/UHF. To get this type of functionality on HF currently HF PACKET exists but very sparse. It leans more to widely separated nodes not always available (not to mention it is slower than VHF/UHF).

I know this concept is sort of - been there done that - kind of thing. The effort is to not only revive it but improve it for use in very flexible situations using any available mode over any available media path using NBEMS software only.

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


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



                    
  




 

Re: FLAMP New feature idea - maybe

AD5XJ, KEN
 

The point I would like to re-emphasize is that the concept  is intended for smaller groups of connecting stations that do not necessarily all have repeaters, Internet access, or WinLINK access. This happens quite often in emergency situations.

The concept is designed to allow NBEMS groups to still operate over a wide area without the need of expensive external TNC equipment.

The NBEMS suite has that capability with FLDIGI / FLMSG / FLAMP and a central connecting station with Internet access. The "postoffice" station could act as a temporary message relay station for all types of messages - not just Internet email. The message formatting capability is already built in to FLMSG so the receiver of the message is familiar with the format.

To do all this, added functionality has to exist to reduce the effort needed in message handling with large volume. This could be a separate module similar to FLAMP or part of FLAMP. It seems logical to fit into FLAMP since some messages may be used to broadcast, and others sent to specific stations who have reported for this duty, or forwarded to an email address using store and forward software methods.

I think the new feature would require routing tags in the message so the "postoffice" would know what to do with it.
Also, to limit traffic and abuse, the "postoffice" should have a registry of participating stations and only respond to those stations for routing functions.

The suggestion has been made that this is like PACKET used to be. That is true. But PACKET was for the most part VHF/UHF. To get this type of functionality on HF currently HF PACKET exists but very sparse. It leans more to widely separated nodes not always available (not to mention it is slower than VHF/UHF).

I know this concept is sort of - been there done that - kind of thing. The effort is to not only revive it but improve it for use in very flexible situations using any available mode over any available media path using NBEMS software only.

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.
>




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

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.

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: 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

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




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

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



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

W. T. Jones <wn3lif@...>
 

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

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

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
 

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: 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