Date   
Flrig and IC-7300 crashes on PBT - solved

GW4XCA-Bob
 

I was just about to ask for help with flrig crashing every time I touched the PBT sliders for my IC-7300.

But then I noticed a very recent update (1.3.51) and that fixed it.

So this user says many thanks for your hard work and I've posted this in case it helps other 7300 users.

Re: fldigi 4.1.14 posted at

Timothy S Kraus
 

Thank you Dave. Will try it soon.

Kraus/KC4ZGP

Re: fldigi 4.1.14 posted at

Dave
 

All of the NBEMS programs including fldigi run on Linux, Unix, OS-X and Windows.  There are two derived Android applications, AndFlmsg and Tivor.  The programs can be downloaded from http://www.w1hkj.com.

David

On 7/26/20 3:32 PM, Timothy S Kraus wrote:
Hi Dave,

I have this old Android Matricom g-Box thingy. It works. I'm surprised. 

Will the latest and greatest 4..1.14 work on it or are all the FL-Digi you offer Windows only?

Been spending the last three hours on Olivia 8-500. JS8 ain't got nuttin' on her.

Thank you.

Kraus/KC4ZGP

Re: ARC custom forms update: Daily Shelter Report

n6medjim@...
 

Mr. Porter -- Expressed out of continuing frustration with misconceptions over many years. I apologize if I ruffled any feathers in the non-Red Cross ham community.

Re: ARC custom forms update: Daily Shelter Report

Barry Porter
 

After Action is better off if the feedback from one Partner Agency does not
target the other Partner Agency with ...."<the other organization> really
needs to get past thinking that they would be <doing this>" It's not good
form, does nothing to improve the situation and would be re-stated differently
by the facilitator. Easy peasy.

Re: ARC custom forms update: Daily Shelter Report

n6medjim@...
 
Edited

The Red Cross has gone to a phone app for reporting shelter demographics et al. The information will be directly communicated to and entered in the Nat'l Shelter System for reporting. The app stores the demographic data (which is NOT via a form in the app) on the phone if cell phone service is lacking.Until roll-out is complete and possibly even after in extreme circumstances, the form (a paper copy of which is in shelter kits) would be filled out by a shelter manager or supervisor. Currently some in-house Field Remote Operations Support Team (FROST) collect the data from shelter managers. Ham radio operators might expect a call relayed from a FROST member to advise the shelter manager to bring the data to the radio operator position in XX minutes, then wait for a call-back. When called back, the shelter manager would give the data directly to the FROST member.

I had many discussions with the folks in the know about whether or not to include the Shelter Report in the list of flmsg forms. The hard reality is that only in rare circumstance might it be used. (This form was included in those available in Winlink was at the behest of an individual who was fired from Red Cross. I offer no further comment on that.)

What is operative here: ARES or other ham operators should not think that they would be directly using any of the Red Cross Custom forms. The entire purpose and intent of creating the flmsg Red Cross Custom HTML forms is so that radio operators could have them in their tool kit. This would make them available for Red Cross personnel to fill out on the radio operator's computer, themselves lacking availability to the forms.

Further, the limited forms in the flmsg Red Cross library, replicated directly from those in our in-house disaster document library, are those for priority or urgent messages that must be forwarded to a Disaster Operations Center, regardless the status of the public telecom network.

ARES really needs to get past thinking that they would be filling out Red Cross forms. This is the job of the Red Cross personnel responsible for the information to be moved. There remains too high a risk of transcription error to have an radio operator to populate a form with information scribbled out by someone else.

It must be noted that some of the forms would be populated with personal private information and would need to be encrypted. Thus they should not/would not be moved over ham circuits. If available, these could be moved, encrypted, over a SHARES HF circuit.

A final note: for disaster communications exercises involving the Red Cross, ARES would be well advised to confer with Red Cross personnel who have been deployed on disasters and are in the know regarding what message traffic might be passed, i.e., what real traffic might be! For anyone involved in the recent May 30 exercise, passing a Disaster Requisition 6409 across country was unrealistic. The path for a matériel request is from the service site (e.g., a shelter or a DOC) to Logistics (already in the DOC), then handed off to the Logs folks in either the local warehouse or to a central warehouse.

BTW: the "Request for Volunteers" form Dave Freese included in his announcement list was an error. The form is not a Red Cross form. I have asked him to delete it from the list. (Perhaps it is used by another agency.)

Best regards All --
Jim Piper, RN, N6MED
530-401-4838

Re: ARC custom forms update: Daily Shelter Report

Larry Levesque
 

Thank you as well Dave.

And I would be really interested in hearing of any instances of the ARC using this in their daily operations.


Larry Levesque
KA1VGM
Cheshire County EC
NHARES


On Sat, Jul 25, 2020 at 6:17 PM John Warren Walker <johnw4jww@...> wrote:
Thank you and Dave for bringing this subject to all of us who will be using the forms on the ARES/ARC project August 8, 2020.

We have been needing this for a long time.  Again - THANKS!
J. Warren Walker  NE4T
4563 Highway 60
Pendergrass, GA.  30567
706-654-6347
AEC Training Hall County, GA
ADEC NE GA ARES/MAT
VEC Hall Co. WESCARS Testing
John 20:31 KJV


--
Larry Levesque
KA1VGM
Cheshire County EC
NHARES

Re: fldigi 4.1.14 posted at

Timothy S Kraus
 

Hi Dave,

I have this old Android Matricom g-Box thingy. It works. I'm surprised. 

Will the latest and greatest 4..1.14 work on it or are all the FL-Digi you offer Windows only?

Been spending the last three hours on Olivia 8-500. JS8 ain't got nuttin' on her.

Thank you.

Kraus/KC4ZGP

Re: ARC custom forms update: Daily Shelter Report

John Warren Walker
 

Thank you and Dave for bringing this subject to all of us who will be using the forms on the ARES/ARC project August 8, 2020.

We have been needing this for a long time.  Again - THANKS!
J. Warren Walker  NE4T
4563 Highway 60
Pendergrass, GA.  30567
706-654-6347
AEC Training Hall County, GA
ADEC NE GA ARES/MAT
VEC Hall Co. WESCARS Testing
John 20:31 KJV

ARC custom forms update: Daily Shelter Report

Dave
 

Need some help with FLDIGI

Dale Tibodeau
 

To preface this email I had FLDIGI working fine on my iMac using Catalina OS and the audio was going through RigBlaster Advantage … FLDIGI was linked to MacLoggerDX rig control

 

I did some new configurations with my WSTJx adding DX Suite Commander rig control etc. with my Yaesu FTdx101mp and got it working perfectly … took my RigBlaster Advantage out of the config and now just using the USB cable between my rig and computer

 

When I went back to FLDIGI after the above config change it would boot but I previously configured it with a PTT.app in the autostart and an error would pop up “Folder not found /Applications/FLDIGI PTT. APP/MacOS”

 

My only option was to hit close and FLDIGI would go away … I tried deleting FLDIGI applications and downloading it fresh again and installing it fresh but continue to get the same problem.

 

Any hints on how to get past this so hopefully I can reinstall FLDIGI to working status again ?

 

Not sure what created the conflict as I had it working before the WSJTx config changes I mentioned above  … some specifics of my current hardware/software set-up are:

 

1.       Running WSJTx with DX Commander as rig control and now using USB Codec for sound instead of through Rigblaster Advantage

2.       Running MacLoggerDX which uses DX Commander Suite for rig control between it and WSJTx

3.       Running 27 inch iMac with Catalina OS

4.       Rig is Yaesu FTdx101MP only using USB cable for WSJTx at current … took my Rigblaster Advantage out of the config

 

Question: Wondering if I can just use USB cable between rig and iMac for FLDIGI as well now … any help in config settings for this would be appreciated

 

Thanks in advance !  N5HT - Dale

 

Dale L. Tibodeau, D.Eng, P.E.

Professor of Practice & Director Bauer Supply Chain Forum

University of Houston

C.T. Bauer School of Business

Department of Decision & Information Science - Supply Chain Management

Office: 275D Melcher Building

Phone: 713-743-4691

Cell: 713-502-5118

Email: dtibodeau@...


 

Re: flmsg and Cyrillic in UTF-8 - possible bug #flmsg

Dave
 

Thanks you, either way of sending the attachment is OK.

David

On 7/16/20 8:47 AM, rn3aoh.g@... wrote:
On Thu, Jul 16, 2020 at 06:00 AM, Dave wrote:

Can you please send me a copy of the orignal radiogram .m2s file.  Send to w1hkj at bellsouth dot net.

I did attach one to my first message, although that was an i2s, but I don't see any particular difference internally. Here's an m2s. This was created with AndFlmsg and fished out of NBEMS.files before sending.

Unless you mean for me to to send it directly to you bypassing the mailing list?

Re: flmsg and Cyrillic in UTF-8 - possible bug #flmsg

rn3aoh.g@...
 

On Thu, Jul 16, 2020 at 06:00 AM, Dave wrote:

Can you please send me a copy of the orignal radiogram .m2s file.  Send to w1hkj at bellsouth dot net.

I did attach one to my first message, although that was an i2s, but I don't see any particular difference internally. Here's an m2s. This was created with AndFlmsg and fished out of NBEMS.files before sending.

Unless you mean for me to to send it directly to you bypassing the mailing list?

Re: flmsg and Cyrillic in UTF-8 - possible bug #flmsg

Dave
 

You are testing areas of both flmsg, fldigi, and AndFlmsg for which the developers did not specifically design.  Can you please send me a copy of the orignal radiogram .m2s file.  Send to w1hkj at bellsouth dot net.

David, W1HKJ

On 7/14/20 8:57 AM, rn3aoh.g@... wrote:
I finally found out about AndFlmsg, and decided to try it out, but since one of my major concerns would be sending messages in Cyrillic, that, naturally, was one of the things I tried first. The results were rather perplexing.

For the purposes of this experiment, I am sending messages from AndFlmsg (1.3.9) to Fldigi (4.1.01) + Flmsg (4.0.16) on Linux using just the phone speaker and the PC microphone.

The first problem I encountered is that Flmsg on Linux would not display Cyrillic at all, even though the rest of the system has no problems with it whatsoever. This was eventually solved by running it with LANG=ru_RU.UTF-8 (I prefer my user interface in English and thus don't run with this set globally) -- I don't really understand why that worked, but I think this particular problem is somewhere in how FLTK works with X fonts and is probably beyond fixing easily. There might be a more elegant workaround, but I've yet to dig it out.

The second problem, however, was much more severe: I tried to send a radiogram (radiogram.html) from AndFlmsg to PC, and naturally, I tried to put Cyrillic in it. See attached source.i2s for the file taken directly from my Android phone.

  1. If fields contain Cyrillic in UTF-8, the message will never checksum. In fact, the checksums seem to be random, even when the raw wrapped message is completely intact and Fldigi prints the entire thing verbatim (with Cyrillic characters) in the output window. If I set DATA EXCHANGE > Force Compression on TX in AndFlmsg, no complaints about checksums are received, because the transmission becomes base64 (or base128) and no UTF-8 characters actually get transmitted. The output seen in Fldigi's decoding window matches the source file in that case as well.
  2. Once a compressed message gets unwrapped and into Flmsg, weirder things start happening: Chunks of words that contain UTF-8 characters go missing, even though no complaints about checksums were received. (It's definitely not a transmission error, because if it was, fields that go after the missing characters would get damaged while decompressing as well) See attached result.i2s. Notably, it's not characters missing, but rather, individual bytes that are part of the two-byte UTF-8 character, so I see dangling bytes here and there. Nothing of the sort seems to happen with the picture.html form, which is not hardcoded, which makes me suspect the problem is somewhere in handling the hardcoded forms on the PC side.
Is this a known issue? Is this a Linux-specific issue or a general Flmsg bug? (I don't have a Windows machine available to test this on Windows.)

For that matter, is this meant to be supported at all?

Re: flmsg and Cyrillic in UTF-8 - possible bug #flmsg

rn3aoh.g@...
 

On Wed, Jul 15, 2020 at 10:15 PM, John (vk2eta) wrote:

I don't think that Flmsg is UTF-8 ready although Fldigi does process the UTF-8 characters correctly. 
Flmsg manual does not tell you if it's UTF-8 safe or not.

Despite that, most NBEMS documentation I've found so far makes sure to tell you to enable UTF-8 characters in MT63 configuration in Fldigi, which is why I asked if it's supposed to work in the first place. The default forms are fairly ARRL-centric, so it wouldn't surprise me if nobody envisioned actually using non-Latin languages or tested the program with them.

On Android to Android exchanges, I have only tested French UTF-8 characters, not Cyrillic. If you have the opportunity could you please test that as well. 
I just tried this, and had no problem at all sending Cyrillic between two Android devices, whether compressed or not, it just works. Which doesn't surprise me, since as long as you got UTF-8 correct, you got more or less all of it correct, with the potential exception of right-to-left languages.

Re: flmsg and Cyrillic in UTF-8 - possible bug #flmsg

John (vk2eta)
 

Hello Eugene,

I don't think that Flmsg is UTF-8 ready although Fldigi does process the UTF-8 characters correctly. 

Maybe Flmsg developers may confirm this.  

On Android I updated the AndFlmsg app to support UTF-8 so the checksum issues you see mean that the two systems do not process the data stream the same way.

On Android to Android exchanges, I have only tested French UTF-8 characters, not Cyrillic. If you have the opportunity could you please test that as well. 

Happy to share ideas with the Flmsg developers and adapt the Android app to make the two applications capable of exchanging UTF-8 strings. 

Cheers,

John (VK2ETA)

flmsg and Cyrillic in UTF-8 - possible bug #flmsg

rn3aoh.g@...
 

I finally found out about AndFlmsg, and decided to try it out, but since one of my major concerns would be sending messages in Cyrillic, that, naturally, was one of the things I tried first. The results were rather perplexing.

For the purposes of this experiment, I am sending messages from AndFlmsg (1.3.9) to Fldigi (4.1.01) + Flmsg (4.0.16) on Linux using just the phone speaker and the PC microphone.

The first problem I encountered is that Flmsg on Linux would not display Cyrillic at all, even though the rest of the system has no problems with it whatsoever. This was eventually solved by running it with LANG=ru_RU.UTF-8 (I prefer my user interface in English and thus don't run with this set globally) -- I don't really understand why that worked, but I think this particular problem is somewhere in how FLTK works with X fonts and is probably beyond fixing easily. There might be a more elegant workaround, but I've yet to dig it out.

The second problem, however, was much more severe: I tried to send a radiogram (radiogram.html) from AndFlmsg to PC, and naturally, I tried to put Cyrillic in it. See attached source.i2s for the file taken directly from my Android phone.

  1. If fields contain Cyrillic in UTF-8, the message will never checksum. In fact, the checksums seem to be random, even when the raw wrapped message is completely intact and Fldigi prints the entire thing verbatim (with Cyrillic characters) in the output window. If I set DATA EXCHANGE > Force Compression on TX in AndFlmsg, no complaints about checksums are received, because the transmission becomes base64 (or base128) and no UTF-8 characters actually get transmitted. The output seen in Fldigi's decoding window matches the source file in that case as well.
  2. Once a compressed message gets unwrapped and into Flmsg, weirder things start happening: Chunks of words that contain UTF-8 characters go missing, even though no complaints about checksums were received. (It's definitely not a transmission error, because if it was, fields that go after the missing characters would get damaged while decompressing as well) See attached result.i2s. Notably, it's not characters missing, but rather, individual bytes that are part of the two-byte UTF-8 character, so I see dangling bytes here and there. Nothing of the sort seems to happen with the picture.html form, which is not hardcoded, which makes me suspect the problem is somewhere in handling the hardcoded forms on the PC side.
Is this a known issue? Is this a Linux-specific issue or a general Flmsg bug? (I don't have a Windows machine available to test this on Windows.)

For that matter, is this meant to be supported at all?

FLDIGI improvement suggestions

billk1ct@...
 

Dave -

   I have a couple of suggestions for FLDIGI:

1.  Rename the PSK mode selection to BPSK.  BPSK  are the only choices under this heading.  This has some confusion to our ARES net where NEWB's cant find BPSK bucause the choices available are PSK, QPSK, and 8PSK.

2.  For NAVTEX/SITOR request that the center frequency be autoset to 1700 Hz as this is the USCG standard for these emissions.  I note that recently WEFAX centered on 1900 Hz to conform to the USCG standard and recommend that 1700 Hz be the set point for NAVTEX/SITOR.  


   Thanks for all of the great work developing FLDIGI to become the premier digital communications application that it is!

                                                                                73, Bill K!CT

fldigi 4.1.14 posted at

Dave
 

http://www.w1hkj.com/files/fldigi/

and Source Forge.

Version 4.1.14 Windows binary is static linked to hamlib-4.0~git library.  Many thanks to developers, maintainers and testers who contributed to this release.

Version 4.1.14 * Maintenance release

  fonts
    * modify start up font enumeration
      - sort system fonts with qsort
      - enumerate fixed fonts
      - add fixed/all selector to font selector
      - use static class members []
        . instantiated and initialized on first instance
        . deleted when all instances deleted
    * change FreqControl width sizing to one based on widest
      numeral for selected font.
    * debug statements to assist in resolving Arch Linux startup
      hangs. To test with debug active
      - uncomment FBDEBUG in Font_Browser.cxx
      - uncomment FCDEBUG in FreqControl.cxx

  Navigator
    * Fix missing initialization code for Windows OS

  hamlib
    * changes driven by hamlib 4.0

  Build scripts
    * remove -lregex from mingw cross compile scripts

  localtime_r
    * add timeops.h to n3fjp_logger.cxx

  Freq Analysis
    * Add Rx RIT control
      - apply as linear correction to observed frequency
    * Disable rxppm corrections when frequency analysis modem
      is active

  Field Day Logger
    * Fix reconnect to server when changing bands/modes

  flarq update
    * Replace text widgets with fl_input2 and F_Edit widgets.  Adds
      UTF-8 character handling.
    * Add restoration of beacon after cessation of ARQ exchanges
    * Modify fldigi to correctly display UTF-8 characters during
      both transmit and reception of flarq text

  Navtex
    * Fix crash in navtex code
      - When neither the alpha nor rep character are valid, the navtex code
        tries to average both characters and see whether that results in a
        valid character.
      - Unfortunately, it uses the value of the character rather than its
        position in the array as an array offset, and can crash in this
        location.
      - Fix that by using the position like the code was meant to do.
      - Found with Valgrind.
    * remove the NOSIGNAL state.
      - Since the SYNC code is quite picky nowadays, requiring
        several valid characters in a 1 second interval before
        switching to READ_DATA mode, the NOSIGNAL state is just
        not useful any more, and it can be removed.
    * make early/prompt/late detector able to lock onto more signals
      - When the early/prompt/late detector was totally out of phase,
        it sometimes totally failed to lock onto signals.
      - Fix by making the detectors jump the entire distance between
        them if the prompt detector is at a lower average than both
        the early and late detectors, and limit that to one jump by
        copying over the average values.

  Sound Record
    * Insure that audio recordings have .wav extension

  Freq Control
    * change to use unsigned long to represent the frequency value
      maximum value increased to 4294967295 (2^32-1)

  MinGW64
    * build MinGW 64bit without requiring -fpermissive.

  Cabrillo logs
    * correct Cabrillo report MODE entry

  sound.cxx warning
    * fix compile warning on indentation

  SNDFILE
    * change SNDFILE to a required library

  FSK HELL
    * invert video reversal on HELL 80
    * rename FSK_HELL -> FSKH245
      - enable RsID encode/decode for FSKH245
    * set default filter bandwidth for each mode

  Store/Recall
    * Change Store/Recall menu items to mode_info[].name vice
      mode_info[].sname
      - sname strings for Contestia and Olivia contained '/'
        causing an item selection failure.
        . fltk widget interprets the '/' as a submenu item
      - bug has been lurking for many versions

  wefax
    * Change bandwidth selections

  Rx Monitor
    * Add test for existence of filter in monitor playback
      - prevents segmentation fault with start up conditions:
        . Rx Monitor enabled
        . Rx Filter enabled
        . Audio alerts disabled

73, David, W1HKJ

Re: ICS message stick

Larry Levesque
 

I understand what you are asking here.
There are already some ICS "Custom" forms available.
And I can understand why you would want to use the Custom version versus the built in version.
The custom version looks identical to the actual printed / PDF ICS forms.
And makes it easier for served agencies to use them to enter the data for hams to pass it.

There are already some non-standard ones in the Files section of this IO group:

https://groups.io/g/nbems/files/Custom_flmsg_forms/ICS%20Forms

If anyone else has any they have created that you would be willing to share, could you please upload them there?

I also like the Custom forms much better than the built in ones.
Set flmsg to no use expert dialog (simple interface).
Now you have an easy to use tool for served agencies and new hams alike to be able to use a pre-defined set of forms to fill and view through a web browser.

This is such a useful option and many may have not realized its potential in that configuration.

Thanks again Dave and all programmers for the awesome suite of programs!

On Fri, Jul 10, 2020 at 04:00:22PM +0000, Craig Lundborg wrote:
Our ARES group would like to create a USB stick that will be much like the RedCross USB but using Regular ICS forms... Does this already exist?

--
Larry Levesque
KA1VGM