Date   
Re: Custom FLMSG Red Cross form conforming to NTS standard

Steve Hansen
 

The text output of the flmsg Radiogram form is correctly formatted for transmission by voice, cw or digital. I use it routinely for injection into the Digital Traffic Network (DTN). The form itself is mainly meant for delivery since it explains the fields. It is not compatible within the traffic networks.

73, Steve KB1TCE

RRI DTN Maine/Winlink-RRI Liaison


On 1/26/2020 8:09 PM, Doug K7KY wrote:
We want to pass FLMSG RadioGram traffic to an NTS net, but NTS doesn't work with the FLMSG form.  We're hoping someone here has developed a custom FLMSG RadioGram form compatible with NTS. If so, we'd appreciate the opportunity to use your form.  Thanks in advance for your assistance or advice.  'http://orcadigitalnet.com'  Doug K7KY

Re: Custom FLMSG Red Cross form conforming to NTS standard

Larry Levesque
 

I am confused.
The FLMSG built-in form should have all of the info NTS is looking for.
If they don't work with the fldigi form, then what format are they expecting it in?

On Sun, Jan 26, 2020 at 05:09:09PM -0800, Doug K7KY wrote:
We want to pass FLMSG RadioGram traffic to an NTS net, but NTS doesn't work with the FLMSG form.  We're hoping someone here has developed a custom FLMSG RadioGram form compatible with NTS. If so, we'd appreciate the opportunity to use your form.  Thanks in advance for your assistance or advice.  'http://orcadigitalnet.com'  Doug K7KY


--
Larry Levesque
KA1VGM

Custom FLMSG Red Cross form conforming to NTS standard

Doug K7KY
 

We want to pass FLMSG RadioGram traffic to an NTS net, but NTS doesn't work with the FLMSG form.  We're hoping someone here has developed a custom FLMSG RadioGram form compatible with NTS. If so, we'd appreciate the opportunity to use your form.  Thanks in advance for your assistance or advice.  'http://orcadigitalnet.com'  Doug K7KY

Re: Macro Help

Larry Levesque
 

Here you go:

<MODEM:NULL>
<TX><!TUNE:01>
<RX>

On Sun, Jan 26, 2020 at 05:50:21PM -0500, Bruce Bohannon WA1YZN wrote:
Hello All, I am trying to make the TUNE macro work. Setting it up for a 5
second tune and then stop transmitting

MACRO,    <TX><TUNE:5>

What I get in the transmit screen is:

^!

The timer box starts running and doesn't stop until I hit the T/R button. Is
that the way it is supposed to work?

FLdigi ver4.1.09

Windows ten

Bruce WA1YZN



--
Larry Levesque
KA1VGM

Re: Macro Help

Larry Levesque
 


Tx needs an Rx to return to receive.

Tune:5. Tunes form5 seconds

Try tune:5 by itself


On Sun, Jan 26, 2020 at 5:50 PM Bruce Bohannon WA1YZN <ham.bo@...> wrote:
Hello All, I am trying to make the TUNE macro work. Setting it up for a
5 second tune and then stop transmitting

MACRO,    <TX><TUNE:5>

What I get in the transmit screen is:

^!

The timer box starts running and doesn't stop until I hit the T/R
button. Is that the way it is supposed to work?

FLdigi ver4.1.09

Windows ten

Bruce WA1YZN




--
Larry Levesque
KA1VGM
Cheshire County EC
NHARES

Macro Help

Bruce Bohannon WA1YZN
 

Hello All, I am trying to make the TUNE macro work. Setting it up for a 5 second tune and then stop transmitting

MACRO,    <TX><TUNE:5>

What I get in the transmit screen is:

^!

The timer box starts running and doesn't stop until I hit the T/R button. Is that the way it is supposed to work?

FLdigi ver4.1.09

Windows ten

Bruce WA1YZN

Re: Yaesu FT-950

Richard Rodriguez
 

I own a Yaesu 991a and had the exact same problem that was solved by matching menu items #64/65 to 1500. The comparable menu items for this radio appears to be #54\55. Give it a try. 

Re: Why Flrig?

Ralph Alden Brigham
 

Dave,

Situation 2 and general usage for other programs that use TCPIP
communications rather than comports.

Thank you.

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

Re: Why Flrig?

Dave
 

Please describe how you are trying to use flrig?  Some possibilites:

  1. Stand alone
  2. With fldigi on same computer
  3. With fldigi on a separate computer over LAN
  4. With fldigi ona  separate computer over WAN
  5. With a 3rd party software application

73, David, W1HKJ

On 1/23/20 6:40 AM, Ralph Alden Brigham wrote:
I just realized the problem - I do NOT know how to set up a TCPIP connection.  Please explain.

Re: Why Flrig?

Ralph Alden Brigham
 

I just realized the problem - I do NOT know how to set up a TCPIP connection.  Please explain.

Re: Yaesu FT-950

Gary Amato
 

Check in Fldigi that you are in USB if you are using Fldigi on FM and Fldigi is set for USB you will be 1500 hz high


On Tue, Jan 21, 2020 at 5:13 PM, Mark Dallner
<markdallner@...> wrote:
Here is a manual for the FT-950

Mark
AC9DE

On Jan 21, 2020, at 4:01 PM, Bruce Bohannon WA1YZN <ham.bo@...> wrote:

Hello All, I am looking for menu settings for a Yaesu FT-950. The radio was working on FLdigi until a couple of weeks ago. It now transmits off frequency by 1000-1500Hz. I am looking for the menu settings to help a fellow ham who is stumped as how to fix. He says it receives fine.

He uses a TigerTronic's USB Signal Link as the inerface.

Any help would be appreciated.

Bruce WA1YZN





Re: Yaesu FT-950

Mark Dallner
 

On Jan 21, 2020, at 4:01 PM, Bruce Bohannon WA1YZN <ham.bo@...> wrote:

Hello All, I am looking for menu settings for a Yaesu FT-950. The radio was working on FLdigi until a couple of weeks ago. It now transmits off frequency by 1000-1500Hz. I am looking for the menu settings to help a fellow ham who is stumped as how to fix. He says it receives fine.

He uses a TigerTronic's USB Signal Link as the inerface.

Any help would be appreciated.

Bruce WA1YZN





Yaesu FT-950

Bruce Bohannon WA1YZN
 

Hello All, I am looking for menu settings for a Yaesu FT-950. The radio was working on FLdigi until a couple of weeks ago. It now transmits off frequency by 1000-1500Hz. I am looking for the menu settings to help a fellow ham who is stumped as how to fix. He says it receives fine.

He uses a TigerTronic's USB Signal Link as the inerface.

Any help would be appreciated.

Bruce WA1YZN

Re: Conclusion of FSK testing

K3eui
 

W1HKJ

Dave

Wow..  thank you for all of the explanations.

Even if  FSK RTTY won't work well by keying the DTR line, I've learned so much from the past few emails about how the "system" works and thinks; toggling the DTR/RTS  pins with some imprecision.



CW
Since FLDIGI 4.1.09  I've successfully been using my Icom 7610 to do CW (rig in CW mode) keying via an USB-virtual serial port (DTR pin) and it works beautifully. The rig is in CW mode, and I can use the audio peak filter on the 7610 (only available in CW or RTTY mode). That is, keying the DTR line sounds great to me (monitor audio) at 20-25 wpm, my usual CW speed. And when I key the audio, with rig in SSB mode, CW also works just fine at 20-25 wpm  (Win 7 computer).


RTTY
When I operate   RTTY  via  AFSK, keying the sound card, rig in USB mode, everything always has been fine, regardless of where I key the audio in the FLDIGI Waterfall. The shift remains 170 Hz.  But I understand why staying above 1500 Hz on the WF with AFSK RTTY is likely to produce a cleaner RTTY signal since the 2nd and 3rd harmonic (3.0 kHz, 4.5 kHz) won't get thru. Since there are really very few RTTY QSO's any longer on the HF bands, I'm not going to fret over your conclusion to abandon the FSK choice to send RTTY.  AFSK works fine, for me. But when I call CQ with RTTY on 20m or 40m, I rarely get a response. Everyone is now on FT8/FT4  or  CW. Even PSK31 is rarely heard on HF.  I think I finally understand now why keying the audio (AFSK RTTY) with the audio codec's accuracy (sample rate) works just fine, but the rig is always in USB or LSB mode.


Once again, with much appreciation for what FLDIGI allows us to do, especially on the 80m EMCOM NBEMS nets.
The weekend NY, NJ, NH, and Pa NBEMS nets on 80 meters are all using THOR 22 for checkins now, and MFSK32 for traffic (flmsg).
The recent PaNBEMS net had over 70 checkins, from all over the mid-Atlantic, south to FLA, north to ME and west to Wisc.
THOR 22 is robust, fast, and very easy to decode even if the receiving station has mistuned by tens of Hz.

73 and TU

Barry Feierman  k3eui
Philadelphia region
PaNBEMS net manager 




On Jan 20, 2020, at 10:59 AM, Dave <w1hkj@...> wrote:

My efforts in 2020 are no better than they were in 2002 when I maintained gmfsk and started down the path of developing fldigi.  At least two persons on the list pointed out the difficulty of generating precisely  timed 22 msec baudot bits (mark/space intervals).  At 45.45 baud the on/off intervals are 22022 microseconds for the start and data bits, and 33033 microseconds for the 1.5 stop bit.  Generating precisely timed DTR or RTS states would be easy if there were no operating system or other programs / threads also running on the cpu.  In a modern operating system, including MS Windows, Unix, Linux and OS-X the operating system, system i/o drivers, and  user application must share the cpu and the i/o resources.  The operating system kernel provides the necessary context and core switching to keep all of the balls in the air.

Operating systems that try to be Posix compliant provide a system call that allows the various processes to generate timeouts with microsecond precision.  Note that precision and accuracy are not synonymous.  The system call is nanoseconds and the precision provided is in microseconds (no OS to my knowledge provides a sub microsecond precision).  Any call with fractional microsecond parameters are truncated to the microsecond.  The actual process invoked by the nanosecond call is to cause the operating system kernel to suspend the calling thread (application) for "at least" the specified number of microseconds.

The question is then "how accurate is the thread suspension".  Attached is a simple single thread (best of all worlds) test application that measures the nanosecond accuracy for 10, 15, 20, 25, 30, 35, 40, 45 and 50 millisecond parameters.  (you will need to compile the code).  The combined results for 1000 tests at each of the specified intervals is shown in this graph:

<lpoijdnmehkgkgog.png>

The mean error is + 158 microseconds.  The most likely is +167 microseconds.  The error is caused by the cpu being used by threads with the same or higher priority before being forced to relinquish the cpu by the OS kernel.  On a Unix/Linux system the priority of an application is assigned by it's "nice"ness value.  Nice applications do not hog the CPU.  It is possible to assign a lower value of niceness to an application all the way to causing the OS to fail.  Neither it nor any other process will have sufficient use of the CPU to keep the system up.  The physical power button may be the only resort if that happens.

The problem with doing that with fldigi is that all of it's threads are assigned an equal nicety.  fldigi can have as many as 30 concurrent threads of operation.  The OS kernel treats them all with equanimity.  The spread on the curve will be much greater for the same tests performed as a thread in fldigi.

The accuracy of timing DTR/RTS events is further complicated by the separation of hardware resources from application layer contexts.  The OS kernel insulates the hardware from all application layer requests for service.  The program may send the request to set or clear the DTR/RTS bit and the OS kernel/driver respond with "Got it".  The application then goes merrily on it's way assuming that all is well.  In the meantime the OS kernel/driver will actually change the state of the h/w when it is good and ready to do so ... no guarantees.  All would be OK if the delay between request and service were a fixed value.  If it is not then our uncertainty in timing is further increased (more spread in the graph).

The result of all of this is jitter in the DTR/RTS timing.  I have tested similar loops to the attached that toggle those signal lines.  The physical signal is then observed on an oscilloscope.  The 1/0 0/1 transistion jitter is very obvious.

All of this applies equally to when the DTR/RTS signal line is being used for CW or RTTY.  The human ear-mind computer can accommodate large variations in code timing.  Computer CW decoders are designed with timing uncertainty in mind.  We can live with crappy CW sent via DTR/RTS.  Both the machine and computer decoders for RTTY cannot tolerate this amount of timing jitter.

Bottom line:  without some computational miracle I see no path to generating FSK keyline output from fldigi.  You need a CW / FSK codec, or modem interface, such as Winkeyer, Mortty , nanoIO, US Navigator, etal.; or a simple converter the precise and accurate right channel on/off signal to a DTR/RTS keyline signal.  The simple converter diagram and it's use is included in the fldigi help documentation.

You may well ask how does fldigi generate the audio CW and TTY signal with both precision and accuracy.  The answer is that is does not.  The precision is generated by fldigi and the accuracy is provided by the audio codec generating a specific number of audio samples.  The audio codec timing is independent of the cpu load, or its clock operation.  The same process provides the frequency and timing accuracy needed for all of the digital modes.  An audio codec operating at 48000 samples per second can maintain timing accuracy to 21.833 microseconds ... no jitter.

73, David
W1HKJ


<sim.cxx>

Conclusion of FSK testing

Dave
 

My efforts in 2020 are no better than they were in 2002 when I maintained gmfsk and started down the path of developing fldigi.  At least two persons on the list pointed out the difficulty of generating precisely  timed 22 msec baudot bits (mark/space intervals).  At 45.45 baud the on/off intervals are 22022 microseconds for the start and data bits, and 33033 microseconds for the 1.5 stop bit.  Generating precisely timed DTR or RTS states would be easy if there were no operating system or other programs / threads also running on the cpu.  In a modern operating system, including MS Windows, Unix, Linux and OS-X the operating system, system i/o drivers, and  user application must share the cpu and the i/o resources.  The operating system kernel provides the necessary context and core switching to keep all of the balls in the air.

Operating systems that try to be Posix compliant provide a system call that allows the various processes to generate timeouts with microsecond precision.  Note that precision and accuracy are not synonymous.  The system call is nanoseconds and the precision provided is in microseconds (no OS to my knowledge provides a sub microsecond precision).  Any call with fractional microsecond parameters are truncated to the microsecond.  The actual process invoked by the nanosecond call is to cause the operating system kernel to suspend the calling thread (application) for "at least" the specified number of microseconds.

The question is then "how accurate is the thread suspension".  Attached is a simple single thread (best of all worlds) test application that measures the nanosecond accuracy for 10, 15, 20, 25, 30, 35, 40, 45 and 50 millisecond parameters.  (you will need to compile the code).  The combined results for 1000 tests at each of the specified intervals is shown in this graph:

The mean error is + 158 microseconds.  The most likely is +167 microseconds.  The error is caused by the cpu being used by threads with the same or higher priority before being forced to relinquish the cpu by the OS kernel.  On a Unix/Linux system the priority of an application is assigned by it's "nice"ness value.  Nice applications do not hog the CPU.  It is possible to assign a lower value of niceness to an application all the way to causing the OS to fail.  Neither it nor any other process will have sufficient use of the CPU to keep the system up.  The physical power button may be the only resort if that happens.

The problem with doing that with fldigi is that all of it's threads are assigned an equal nicety.  fldigi can have as many as 30 concurrent threads of operation.  The OS kernel treats them all with equanimity.  The spread on the curve will be much greater for the same tests performed as a thread in fldigi.

The accuracy of timing DTR/RTS events is further complicated by the separation of hardware resources from application layer contexts.  The OS kernel insulates the hardware from all application layer requests for service.  The program may send the request to set or clear the DTR/RTS bit and the OS kernel/driver respond with "Got it".  The application then goes merrily on it's way assuming that all is well.  In the meantime the OS kernel/driver will actually change the state of the h/w when it is good and ready to do so ... no guarantees.  All would be OK if the delay between request and service were a fixed value.  If it is not then our uncertainty in timing is further increased (more spread in the graph).

The result of all of this is jitter in the DTR/RTS timing.  I have tested similar loops to the attached that toggle those signal lines.  The physical signal is then observed on an oscilloscope.  The 1/0 0/1 transistion jitter is very obvious.

All of this applies equally to when the DTR/RTS signal line is being used for CW or RTTY.  The human ear-mind computer can accommodate large variations in code timing.  Computer CW decoders are designed with timing uncertainty in mind.  We can live with crappy CW sent via DTR/RTS.  Both the machine and computer decoders for RTTY cannot tolerate this amount of timing jitter.

Bottom line:  without some computational miracle I see no path to generating FSK keyline output from fldigi.  You need a CW / FSK codec, or modem interface, such as Winkeyer, Mortty , nanoIO, US Navigator, etal.; or a simple converter the precise and accurate right channel on/off signal to a DTR/RTS keyline signal.  The simple converter diagram and it's use is included in the fldigi help documentation.

You may well ask how does fldigi generate the audio CW and TTY signal with both precision and accuracy.  The answer is that is does not.  The precision is generated by fldigi and the accuracy is provided by the audio codec generating a specific number of audio samples.  The audio codec timing is independent of the cpu load, or its clock operation.  The same process provides the frequency and timing accuracy needed for all of the digital modes.  An audio codec operating at 48000 samples per second can maintain timing accuracy to 21.833 microseconds ... no jitter.

73, David
W1HKJ


Re: Fldigi receiving but wont key radio

Larry Levesque
 

And do you have Enable TX on Report checked in the flamp configuration tab?

On Sun, Jan 19, 2020 at 08:22:10PM -0500, Romeo Hotel One Two wrote:
Larry,


I checked and I am a member of the dialout group.



Thanks,

Rob



On 1/19/20 7:43 PM, Larry Levesque wrote:
Add yourself to DIALOUT group and log out and back in.


On Sun, Jan 19, 2020 at 12:06:49PM -0800, Romeo Hotel One Two wrote:
Ok, back around Thanksgiving I got the bright idea that I was going to replace the standard hard drive in my Panasonic CF-19 Toughbook with a 1TB SSD.  At the same time I upgraded Mint 18.something to Mint 19.3 as the OS.  Reloaded Fldigi, Flamp, Flmsg, Flrig, and flwrap among other things.

A few weeks ago I was participating in a net and when I tried to report needed block fills from Flamp, the software said it was transmitting but it wasn't keying the radio.  This is the first I have been back on the radio since the upgrade.  I've tried everything I could think of but I am coming up blank.

Can anyone help?  Luckily I have the old HD and can boot from it if I need to get on the air its just a pain in the tail and requires me to have extra equipment on hand.

Thanks,
Romeo Hotel-12



--
Larry Levesque | Senior Business Systems Analyst
Granite City Electric Supply, Co.
16 Rose Lane Keene, NH. 03431
Direct: 617-221-1551 Cell: 857-753-1407

Re: Fldigi receiving but wont key radio

Romeo Hotel One Two
 

Larry,


I checked and I am a member of the dialout group.



Thanks,

Rob

On 1/19/20 7:43 PM, Larry Levesque wrote:
Add yourself to DIALOUT group and log out and back in.


On Sun, Jan 19, 2020 at 12:06:49PM -0800, Romeo Hotel One Two wrote:
Ok, back around Thanksgiving I got the bright idea that I was going to replace the standard hard drive in my Panasonic CF-19 Toughbook with a 1TB SSD.  At the same time I upgraded Mint 18.something to Mint 19.3 as the OS.  Reloaded Fldigi, Flamp, Flmsg, Flrig, and flwrap among other things.

A few weeks ago I was participating in a net and when I tried to report needed block fills from Flamp, the software said it was transmitting but it wasn't keying the radio.  This is the first I have been back on the radio since the upgrade.  I've tried everything I could think of but I am coming up blank.

Can anyone help?  Luckily I have the old HD and can boot from it if I need to get on the air its just a pain in the tail and requires me to have extra equipment on hand.

Thanks,
Romeo Hotel-12


Re: Fldigi receiving but wont key radio

Larry Levesque
 

Add yourself to DIALOUT group and log out and back in.

On Sun, Jan 19, 2020 at 12:06:49PM -0800, Romeo Hotel One Two wrote:
Ok, back around Thanksgiving I got the bright idea that I was going to replace the standard hard drive in my Panasonic CF-19 Toughbook with a 1TB SSD.  At the same time I upgraded Mint 18.something to Mint 19.3 as the OS.  Reloaded Fldigi, Flamp, Flmsg, Flrig, and flwrap among other things.

A few weeks ago I was participating in a net and when I tried to report needed block fills from Flamp, the software said it was transmitting but it wasn't keying the radio.  This is the first I have been back on the radio since the upgrade.  I've tried everything I could think of but I am coming up blank.

Can anyone help?  Luckily I have the old HD and can boot from it if I need to get on the air its just a pain in the tail and requires me to have extra equipment on hand.

Thanks,
Romeo Hotel-12


--
Larry Levesque
KA1VGM

Fldigi receiving but wont key radio

Romeo Hotel One Two
 

Ok, back around Thanksgiving I got the bright idea that I was going to replace the standard hard drive in my Panasonic CF-19 Toughbook with a 1TB SSD.  At the same time I upgraded Mint 18.something to Mint 19.3 as the OS.  Reloaded Fldigi, Flamp, Flmsg, Flrig, and flwrap among other things.

A few weeks ago I was participating in a net and when I tried to report needed block fills from Flamp, the software said it was transmitting but it wasn't keying the radio.  This is the first I have been back on the radio since the upgrade.  I've tried everything I could think of but I am coming up blank. 

Can anyone help?  Luckily I have the old HD and can boot from it if I need to get on the air its just a pain in the tail and requires me to have extra equipment on hand.


Thanks,
Romeo Hotel-12

Re: Fldigi install errors

Keith Kaiser
 

I just tried that entry all I get is "Invalid operation build-deps".