Date   
Macro Parser flowchart?

Doug K7KY
 

Hello FLDIGI Moderators...  I'm hoping to find a Macro Parser flowchart.  Dave explained the Parser to me years ago, but I've lost the post and didn't fully understand it all at the time. My macros are working OK, but when Dave revised one of my macros, I realized I didn't understand how the Parser prioritizes commands. If there's a Parser execution flowchart, I'd love to have a copy.  Thanks, Doug K7KY

Re: FLDIGI not shifting modes from flmsg

Bill Turner, wb4alm
 

This may be a dumb suggestion, but verify that your usb sound cards are sampling at 48000.

/s/ Bill Turner, wb4alm


On 2/26/20 12:23 PM, John KC4LZN wrote:
I did check the signal input as well as what the output was and may lay the issue to the cheap USB soundcards I am using to interface the two Pi's. I will test again over the air when I can get them lined up with two transceivers with legitimate interfaces that have better sound cards 

When I did initially check, because I aired on the side of caution when I set the audio up on these. The transmit sound (speaker) was set well too low and adjusted where the sound was just below the two grey lines but the same results were received. 

I'll do some more testing and looking into digging into the audio side again and see if there was something I overlooked. 

Thanks for the tips on the waterfall settings and audio adjustments. I'm sure OTA testing will prove to be very good.

73
John




On Wed, Feb 26, 2020 at 11:15 AM Dave <w1hkj@...> wrote:

Make sure  you are not overdriving the Rx unit.  Try sending a TUNE signal and looking at the SIG view of (WF/FFT/SIG).  The peak-to-peak value of the signal should not exceed the uper and lower grey lines.

Test the RsID performance just using the fldigi programs without flmsg (one less failure point).  Make sure that TxID is and RxID is enabled on all of the modes you will be testing.  From the IDs/RsID configuration dialog, select "Receive modes" and "Transmit modes"; check every mode that you want to both TX and RX the RsID signal.  To test RsID simply select the Tx mode and press the T/R button on fldigi.

David

On 2/26/20 9:34 AM, John KC4LZN wrote:
I've included a link to the video, quality isn't that great and my first feeble attempt to record my desktop. It is split screen showing two Raspberry Pi's desktops.

I've been testing back and forth, have two Raspberry Pi's 3 Model B, with fldigi and flmsg, trying to learn the ins and outs with these two programs. Both Pi's fldigi programs are set in RxID and TxID on. 

I started out with both fldigi's in Olivia 8/500 mode. Opened flmsg, created a test message and sent it in Olivia 8/500 from the drop down menu in flmsg. Receiving Pi got it, deciphered it with no issues. I then dropped the box down in flmsg and changed the mode to MT63-2KL and transmitted. The receiving Pi window shows it expanded to "see" that mode but in the text box, it said it was still in Olivia 8/500. I re-transmitted the message again with no changes and the receiving Pi correctly identified the mode and received the message with no errors.

Without going in the great detail about ALL of the settings, is there an area I need to look at in the settings to ensure that the RxID changes to the proper mode? 

Again, the link below to see the video. There is no audio. Hope it makes sense and will field questions best as I can.

https://youtu.be/j9uxG-rCO9U

73
John
KC4LZN

Re: FLDIGI not shifting modes from flmsg

John KC4LZN
 

I did check the signal input as well as what the output was and may lay the issue to the cheap USB soundcards I am using to interface the two Pi's. I will test again over the air when I can get them lined up with two transceivers with legitimate interfaces that have better sound cards 

When I did initially check, because I aired on the side of caution when I set the audio up on these. The transmit sound (speaker) was set well too low and adjusted where the sound was just below the two grey lines but the same results were received. 

I'll do some more testing and looking into digging into the audio side again and see if there was something I overlooked. 

Thanks for the tips on the waterfall settings and audio adjustments. I'm sure OTA testing will prove to be very good.

73
John




On Wed, Feb 26, 2020 at 11:15 AM Dave <w1hkj@...> wrote:

Make sure  you are not overdriving the Rx unit.  Try sending a TUNE signal and looking at the SIG view of (WF/FFT/SIG).  The peak-to-peak value of the signal should not exceed the uper and lower grey lines.

Test the RsID performance just using the fldigi programs without flmsg (one less failure point).  Make sure that TxID is and RxID is enabled on all of the modes you will be testing.  From the IDs/RsID configuration dialog, select "Receive modes" and "Transmit modes"; check every mode that you want to both TX and RX the RsID signal.  To test RsID simply select the Tx mode and press the T/R button on fldigi.

David

On 2/26/20 9:34 AM, John KC4LZN wrote:
I've included a link to the video, quality isn't that great and my first feeble attempt to record my desktop. It is split screen showing two Raspberry Pi's desktops.

I've been testing back and forth, have two Raspberry Pi's 3 Model B, with fldigi and flmsg, trying to learn the ins and outs with these two programs. Both Pi's fldigi programs are set in RxID and TxID on. 

I started out with both fldigi's in Olivia 8/500 mode. Opened flmsg, created a test message and sent it in Olivia 8/500 from the drop down menu in flmsg. Receiving Pi got it, deciphered it with no issues. I then dropped the box down in flmsg and changed the mode to MT63-2KL and transmitted. The receiving Pi window shows it expanded to "see" that mode but in the text box, it said it was still in Olivia 8/500. I re-transmitted the message again with no changes and the receiving Pi correctly identified the mode and received the message with no errors.

Without going in the great detail about ALL of the settings, is there an area I need to look at in the settings to ensure that the RxID changes to the proper mode? 

Again, the link below to see the video. There is no audio. Hope it makes sense and will field questions best as I can.

https://youtu.be/j9uxG-rCO9U

73
John
KC4LZN

Re: FLDIGI not shifting modes from flmsg

Dave
 

Make sure  you are not overdriving the Rx unit.  Try sending a TUNE signal and looking at the SIG view of (WF/FFT/SIG).  The peak-to-peak value of the signal should not exceed the uper and lower grey lines.

Test the RsID performance just using the fldigi programs without flmsg (one less failure point).  Make sure that TxID is and RxID is enabled on all of the modes you will be testing.  From the IDs/RsID configuration dialog, select "Receive modes" and "Transmit modes"; check every mode that you want to both TX and RX the RsID signal.  To test RsID simply select the Tx mode and press the T/R button on fldigi.

David

On 2/26/20 9:34 AM, John KC4LZN wrote:
I've included a link to the video, quality isn't that great and my first feeble attempt to record my desktop. It is split screen showing two Raspberry Pi's desktops.

I've been testing back and forth, have two Raspberry Pi's 3 Model B, with fldigi and flmsg, trying to learn the ins and outs with these two programs. Both Pi's fldigi programs are set in RxID and TxID on. 

I started out with both fldigi's in Olivia 8/500 mode. Opened flmsg, created a test message and sent it in Olivia 8/500 from the drop down menu in flmsg. Receiving Pi got it, deciphered it with no issues. I then dropped the box down in flmsg and changed the mode to MT63-2KL and transmitted. The receiving Pi window shows it expanded to "see" that mode but in the text box, it said it was still in Olivia 8/500. I re-transmitted the message again with no changes and the receiving Pi correctly identified the mode and received the message with no errors.

Without going in the great detail about ALL of the settings, is there an area I need to look at in the settings to ensure that the RxID changes to the proper mode? 

Again, the link below to see the video. There is no audio. Hope it makes sense and will field questions best as I can.

https://youtu.be/j9uxG-rCO9U

73
John
KC4LZN

FLDIGI not shifting modes from flmsg

John KC4LZN
 

I've included a link to the video, quality isn't that great and my first feeble attempt to record my desktop. It is split screen showing two Raspberry Pi's desktops.

I've been testing back and forth, have two Raspberry Pi's 3 Model B, with fldigi and flmsg, trying to learn the ins and outs with these two programs. Both Pi's fldigi programs are set in RxID and TxID on. 

I started out with both fldigi's in Olivia 8/500 mode. Opened flmsg, created a test message and sent it in Olivia 8/500 from the drop down menu in flmsg. Receiving Pi got it, deciphered it with no issues. I then dropped the box down in flmsg and changed the mode to MT63-2KL and transmitted. The receiving Pi window shows it expanded to "see" that mode but in the text box, it said it was still in Olivia 8/500. I re-transmitted the message again with no changes and the receiving Pi correctly identified the mode and received the message with no errors.

Without going in the great detail about ALL of the settings, is there an area I need to look at in the settings to ensure that the RxID changes to the proper mode? 

Again, the link below to see the video. There is no audio. Hope it makes sense and will field questions best as I can.

https://youtu.be/j9uxG-rCO9U

73
John
KC4LZN

Re: fldigi 4.1.09.20 posted

John KC4LZN
 

Dave,

Yes, it works now. Tried it both in using fldigi on a Raspberry Pi in sending out a CQ on Olivia 8/500 where the CQ message was received in full and sending a message with flmsg where the message was received with no errors. Thanks for the great work.

73
John

On Tue, Feb 25, 2020 at 8:17 PM Dave <w1hkj@...> wrote:

yes John.  let me know if it works correctly now.

dave

On 2/25/20 7:14 PM, John KC4LZN wrote:
Dave,

Noted the Olivia two tones in the notes...

Wonder if that was what I was experiencing when I was testing Olivia 8/500 with two raspberry Pi's where the end of the transmission was not completing?

I'll have to update the versions and test again if that is what the change for that was.

73
John 
KC4LZN

On Wed, Feb 19, 2020, 16:22 Dave <w1hkj@...> wrote:

at http://www.w1hkj.com/alpha/fldigi/

Alpha test version 4.1.09.20

  maclogger
    * correct interpretation of UDP frequency string
    * update transceiver frequency based on UDP frequency

  mkappbundle
    * modify 'version' to include patch level

  nanoIO
    * Correct TTY interface code

  start/stop transitions
    * add code to soften the start/stop transitions for all modems

  CW DTR-RTS
    * generate CW on selected DTR/RTS signal line
    * CW DTR/RTS signals generated concurrent with AF counterparts and within a separate thread.

  Olivia 2 tones
    * correct trailing edge cutoff of postamble tones

  Xmlrpc Xcvr
    * enable QSY when Xmlrpc client xcvr is connected

  mp3
    * simplify mp3 conversions
      - test for file access using fopen
      - use linear sample rate converter

  TUNE macro
   * Restore execution code for <TUNE
   * Retain delayed execution code for <!TUNE

  contestia cr
    * correct suppression of <CR> display

  serial port
    * insure that DTR and RTS are always disabled when closing port

  Check Version
    * correct version check logic

73, David
W1HKJ


Re: fldigi 4.1.09.20 posted

Dave
 

yes John.  let me know if it works correctly now.

dave

On 2/25/20 7:14 PM, John KC4LZN wrote:
Dave,

Noted the Olivia two tones in the notes...

Wonder if that was what I was experiencing when I was testing Olivia 8/500 with two raspberry Pi's where the end of the transmission was not completing?

I'll have to update the versions and test again if that is what the change for that was.

73
John 
KC4LZN

On Wed, Feb 19, 2020, 16:22 Dave <w1hkj@...> wrote:

at http://www.w1hkj.com/alpha/fldigi/

Alpha test version 4.1.09.20

  maclogger
    * correct interpretation of UDP frequency string
    * update transceiver frequency based on UDP frequency

  mkappbundle
    * modify 'version' to include patch level

  nanoIO
    * Correct TTY interface code

  start/stop transitions
    * add code to soften the start/stop transitions for all modems

  CW DTR-RTS
    * generate CW on selected DTR/RTS signal line
    * CW DTR/RTS signals generated concurrent with AF counterparts and within a separate thread.

  Olivia 2 tones
    * correct trailing edge cutoff of postamble tones

  Xmlrpc Xcvr
    * enable QSY when Xmlrpc client xcvr is connected

  mp3
    * simplify mp3 conversions
      - test for file access using fopen
      - use linear sample rate converter

  TUNE macro
   * Restore execution code for <TUNE
   * Retain delayed execution code for <!TUNE

  contestia cr
    * correct suppression of <CR> display

  serial port
    * insure that DTR and RTS are always disabled when closing port

  Check Version
    * correct version check logic

73, David
W1HKJ


Re: fldigi 4.1.09.20 posted

John KC4LZN
 

Dave,

Noted the Olivia two tones in the notes...

Wonder if that was what I was experiencing when I was testing Olivia 8/500 with two raspberry Pi's where the end of the transmission was not completing?

I'll have to update the versions and test again if that is what the change for that was.

73
John 
KC4LZN


On Wed, Feb 19, 2020, 16:22 Dave <w1hkj@...> wrote:

at http://www.w1hkj.com/alpha/fldigi/

Alpha test version 4.1.09.20

  maclogger
    * correct interpretation of UDP frequency string
    * update transceiver frequency based on UDP frequency

  mkappbundle
    * modify 'version' to include patch level

  nanoIO
    * Correct TTY interface code

  start/stop transitions
    * add code to soften the start/stop transitions for all modems

  CW DTR-RTS
    * generate CW on selected DTR/RTS signal line
    * CW DTR/RTS signals generated concurrent with AF counterparts and within a separate thread.

  Olivia 2 tones
    * correct trailing edge cutoff of postamble tones

  Xmlrpc Xcvr
    * enable QSY when Xmlrpc client xcvr is connected

  mp3
    * simplify mp3 conversions
      - test for file access using fopen
      - use linear sample rate converter

  TUNE macro
   * Restore execution code for <TUNE
   * Retain delayed execution code for <!TUNE

  contestia cr
    * correct suppression of <CR> display

  serial port
    * insure that DTR and RTS are always disabled when closing port

  Check Version
    * correct version check logic

73, David
W1HKJ


fldigi 4.1.09.20 posted

Dave
 

at http://www.w1hkj.com/alpha/fldigi/

Alpha test version 4.1.09.20

  maclogger
    * correct interpretation of UDP frequency string
    * update transceiver frequency based on UDP frequency

  mkappbundle
    * modify 'version' to include patch level

  nanoIO
    * Correct TTY interface code

  start/stop transitions
    * add code to soften the start/stop transitions for all modems

  CW DTR-RTS
    * generate CW on selected DTR/RTS signal line
    * CW DTR/RTS signals generated concurrent with AF counterparts and within a separate thread.

  Olivia 2 tones
    * correct trailing edge cutoff of postamble tones

  Xmlrpc Xcvr
    * enable QSY when Xmlrpc client xcvr is connected

  mp3
    * simplify mp3 conversions
      - test for file access using fopen
      - use linear sample rate converter

  TUNE macro
   * Restore execution code for <TUNE
   * Retain delayed execution code for <!TUNE

  contestia cr
    * correct suppression of <CR> display

  serial port
    * insure that DTR and RTS are always disabled when closing port

  Check Version
    * correct version check logic

73, David
W1HKJ


Version scheme

Dave
 

Explanation of version strings for all flxxxx applications posted at http://www.w1hkj.com

Version numbers consist of three or four numbers separated by dots. For example: 11.22.33, 11.22.33.44. These numbers have names.

  • 11 - major version
  • 22 - minor version
  • 33 - revision number, but it may also be referred to as a "point release" or "subminor version"
  • 44 - alpha release number

When you want to know if a version is newer than a different version you have to start reading from left to right:

  • If the major version is higher, your version is newer. If it is lower, your version is older. If it's the same, continue reading.
  • If the minor version is higher, your version is newer. If it is lower, your version is older. If it's the same, continue reading.
  • If the revision is higher, your version is newer. If it is lower, your version is older. If it's the same you have the same version.
  • alpha release numbers are consecutive and are based on the current major.minor.revison, but you might miss one since the alpha postings are transitory.  Some alpha releases are synchronized to other products, i.e. fldigi / flrig.

You should only use alpha postings if:

  1. you love living on the edge and are willing to help improve the software product,
  2. you need some new or corrected functionality only available in the alpha release,
  3. you are willing to accept the possibility of unintended features (software bugs), and
  4. you are willing to report and help to correct discovered software bugs.

Finally, I maintain lists of users who are willing to participate in software testing of one or more products.  Simply email me at the bellsouth address, requesting to be added to a specific alpha test list.  Let me know if you have some special skills or experience in quality assurance testing.

73, David
W1HKJ


flrig 1.3.49.08 posted

Dave
 

flrig 1.3.49.07 posted

Dave
 

Re: Linux Macro File Transfer

Ed W3NR
 

Seems like a lot of extra work when a simple copy/paste works.

Ed W3NR

Re: Linux Macro File Transfer

Ron
 

Lynn,

Use a thumb drive and copy the macros on the Windows PC C:\USERS\(your sign on)\fldigi.files\ to your Linux PC /home/(your sign on)/.fldigi/macros folder. The problem I've found is the Macros on the Linux machine show up with ^M as line endings. It will still work but it's confusing. There is a program called unix2dos that will change these line endings.

73, Ron NY3J

On 2/18/20 7:16 PM, Lynn DeHart wrote:
I am looking for a way to transfer my Windoes Macro file into a Raspberry Pi Fldigi sysstem. Any suggestions?

Re: Linux Macro File Transfer

Jon - K7RMZ
 

VNC has a file transfer feature that works great. Either Raspi-config or apt-get will get VNC installed on your pi.

Re: Linux Macro File Transfer

Ed W3NR
 

On 2/18/20 7:16 PM, Lynn DeHart wrote:
I am looking for a way to transfer my Windoes Macro file into a Raspberry Pi Fldigi sysstem. Any suggestions?
_._,_._,_

Be easy with a USB stick.

Ed W3NR

Linux Macro File Transfer

 

I am looking for a way to transfer my Windoes Macro file into a Raspberry Pi Fldigi sysstem. Any suggestions?

flrig-1.3.49.06 posted

Dave
 

At http://www.w1hkj.com/alpha/flrig/

Update to flrig documentation:

Date:   Tue Feb 18 10:23:48 2020 -0600

    Doc Update
   
      * add location and descriptions of configuration and data files

    mat file aging
   
      * add aging for freq-mode list files (.mat)

    KX3
   
      * Change default if_shift for digital modes to 1500

    Slider controls
   
      * bug fix - disallow UI slider changes when volume muted
      * bug fix - do not transfer data to xcvr on event FL_LEAVE
      * correct slider behavior using mouse wheel

    IC7100
   
      * add
        - ref adjust
        - calibrate table for power out

    mkappbundle
   
      * modified 'version' to include patch number

    User Command Buttons
   
      * Add SHIFT and CONTROL usage to all command buttons
        - allows user to assign on/off etc usage to a single
          command button.

    FTdx9000D
   
      * remap power i/o to 5...200 W
      * correct vfoB selection
      * corect width selection

    FTdx101MP
   
      * add FTdx101MP class based off of FTdx101D

    Yaesu tuner
   
      * change get/set tuner methods for these xcvrs
        - FT991, FT991A

    Commands
   
      * correct indexing error

73, David, W1HKJ

flrig test version 1.3.49.05

Dave
 

Posted at http://www.w1hkj.com/alpha/flrig/

Date:   Sat Feb 15 00:07:00 2020 -0600

  Slider controls
    * bug fix - disallow UI slider changes when volume muted
    * bug fix - do not transfer data to xcvr on event FL_LEAVE

  IC7100
    * add
      - ref adjust
      - calibrate table for power out

  mkappbundle
    * modified 'version' to include patch number

  User Command Buttons
    * Add SHIFT and CONTROL usage to all command buttons
      - allows user to assign on/off etc usage to a single command button.

  FTdx9000D
    * remap power i/o to 5...200 W
    * correct vfoB selection
    * corect width selection

  FTdx101MP
    * add FTdx101MP class based off of FTdx101D

  Yaesu tuner
    * change get/set tuner methods for these xcvrs
      - FT991, FT991A

  Commands
    * correct indexing error

73, David, W1HKJ


Re: Raspberry Pi based remote operation article in March 2020 QST

Dave
 

DONE

Dave

On 2/7/20 2:04 PM, Harry Bloomberg wrote:
I wrote a short article on remote operation using NoMachine, Fldigi/Flrig, and a Raspberry Pi that has been published in March QST.  I've attached a copy below.  Links to more detailed documentation may be found at http://www.w1hkj.com/W3YJ/ .

Thanks to Dave W1HKJ for the space on his ftp server and for all the fine work he's done with his team on the entire NBEMS suite.

It's been suggested that I also crosspost this to the winfldigi group.  I'm trying to cut down on the number of emails I receive and I do not belong to that list, could somebody please forward my article and link there?

73,
Harry Bloomberg W3YJ