1. linuxham@groups.io
  2. Messages
   Date   
moderated Re: flnet 7.3.3.11 posted

Mark Gregory, AB9ZA <mgregory7605@...>
 

I have been playing with the Alpha releases of flnet on a desktop computer running Linux Mint Debian Edition 4.  I ran into several issues on the last few alpha versions, with 7.3.3.11 being the latest.  Not all of these issues happened every time, so it might be difficult to isolate.  I use the Call Sign Lookup feature a lot, so these are related to that.  All the following occurred on the latest alpha version (.11).

- When doing Call Sign Lookup, Alt+L does not always work.  Usually after using the mouse for the first two or three lookups, it may or may not start working.

- Occasionally after doing an update on a Lookup, clicking on the Update button closes the whole flnet program.

- This was noted before by someone else - If a Looked Up Call Sign has an email address, the email address will persist on to following lookups unless cleared manually.

- On 7.3.3.11, it closed unexpectedly for unknown reasons a couple times.

I use flnet regularly, and really appreciate all the time and effort put into this and the other fldigi suite software.  Thank you.

73

Mark Gregory / AB9ZA

On 12/28/20 8:33 PM, Dave, W1HKJ wrote:

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

Mon Dec 28 19:00:00 2020 -0500  alpha  7.3.3.11

  check-in-list
    * allow user to specifiy left/right justification of callsign field

  HamQTH queries
    * extract email
    * convert lat/lon to 6 place Maidenhead locator if lat/lon present in response

  Color coding
    * fix color coding for callin list entries

  Write Log
    * write log after every change to log-in list
    * add hours, minutes to file name

  Optimizer
    * fix compiler optimizer differences when mixing
      strings with returned char pointers.

  Callook lookup
    * Fix access and parsing of callook.info query
    * Fix locator to azimuth/distance display

  UI mods
    * Enable keypad Enter key for selecting call from pick list
    * Fix controlling order on edit dialog

  new fields
    * added COUNTRY, LOCATOR

  Distance Display
    * User configurable distance display, kilometers, nautical miles, statute miles.

  UI fixes
    * change all configuration items to progStatus
    * increase width of check-ins display lines
    * adjust UI widgets, position and size
    * change arrangement of fields in info panel
      - concatenate comment1, comment2 data fields
        separating each with a semicolon.
    * add user configurable justification, left/right for
      nickname field in check-in list

  autofiles

  mkappbundle
    * modify 'version' to include VERSION_PATCH

  Keyboard Shortcuts
    * Remove &menu items
    * Enable alt-F4 - cleanExit
    * on MacOS/OS-X enable cmd-Q - cleanExit

Version 7.3.3

73, David, W1HKJ
moderated Big Sur serial port naming

Dave, W1HKJ
 

I do not own a Mac capable of running Big Sur so I will need some assistance from those who do.  Big Sur uses built-in drivers for all hardware including USB plug in devices.  The OS driver for USB serial devices is generic and will only recognize those devices with manufacturers ID.  Custom chip sets will not be recognized.  Chalk this problem up to Apple for not providing an easy way for the driver to change it's behavior.  A simple configuration text file with device ID's would probably have sufficed.  Programmer ignorance, Apple hautiness, over zealous user protection?  Who knows, but you should be aware that your $5000 transceiver might not be accessible on Big Sur.

For those devices that are recognized, Big Sur further complicates matters by not using the naming standard on the previous 14 or more years of OS releases.  Again, anyone's guess as to the why.  Application programmers and users are left holding the bag.

Here is how you can help.  USB serial devices are plug and play.  The OS recognizes the h/w when it is either plugged in or powered up.  I can discover the device names for my IC7100 by turning the 12 volt power suppy OFF and then back ON.



Open a terminal window.
  1. Either unplug or remove power from the transceiver.
  2. execute the command "ls /dev >without.txt"  (sends line output from 'ls /dev' to the file 'without.txt'
  3. Either plug in or power up the transceiver
  4. execute the command "ls /dev >with.txt"
  5. use the program "diff" to display the difference in the two files.

The discovered devices should show up as above.

Please send me the two files with details regarding the transceiver or the USB serial device being discovered.

Send to w1hkj@...

You can manually enter the discovered device name in both the flrig and/or fldigi serial port entry control.  I recommend using the cu device name if there is both a cu and a tty device.  See this web page for more information.

Thanks.

73, David, W1HKJ
moderated Re: FLDIGI NO RTTY under Big Sur?

Cliff, AE5ZA
 

Ben,

I don’t have Big Sur, but I understand that it has all the drivers or at least the standard ones. For Icom rigs with builtin soundcards look for a port from the list with the number 210 in it. The ports have different names now, but the one I know people have found to work with Icoms has the number 210 in its name.

73,
Cliff, AE5ZA

On Dec 29, 2020, at 01:39, Benjamin, ON5BGO <on5bgo@...> wrote:

Hi Bill, HI to all,

I have upgraded to BigSur too on my MacBook Pro two weeks ago and since then i can’t use Fldigi / flrig anymore because no COM ports detected !
Do you install some usb-to-serial driver from somewhere else or let BigSur do the job ?
And which rig are you using with it ?

Thanks Bill

73, Ben

Le mardi 29 décembre 2020, Bill Turini, KA4GAV via groups.io <bill.turini=icloud.com@groups.io> a écrit :
I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

...

73’s

Bill
KA4GAV
moderated Re: FLDIGI NO RTTY under Big Sur?

Benjamin, ON5BGO
 

Hi Bill, HI to all,

I have upgraded to BigSur too on my MacBook Pro two weeks ago and since then i can’t use Fldigi / flrig anymore because no COM ports detected !
Do you install some usb-to-serial driver from somewhere else or let BigSur do the job ?
And which rig are you using with it ?

Thanks Bill

73, Ben


Le mardi 29 décembre 2020, Bill Turini, KA4GAV via groups.io <bill.turini=icloud.com@groups.io> a écrit :
I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

...

73’s

Bill
KA4GAV
moderated Re: Raspberry Pi compile of flrig and fldigi

Dave, W1HKJ
 

Be sure to follow the instructions on the fldigi wiki exactly, especially take note of Pi3/4 requirements:


Special Note for Pi3 & Pi4 users with 1 GB RAM

Compiling fldigi requires more than the default swap space. You may need to increase the swap space on the microSD card. Please follow the example instructions at Pi Swap Space and use the number 2048 instead of 1024 to give 2 GB of swap. Some users have needed the larger swap space.
You are now ready to build fldigi.

73, David, W1HKJ

On 12/28/20 10:08 PM, Doug Person, KJ0F wrote:

I've tried twice to compile the latest versions flrig and fldigi. They always fail with messages that don't say much. Are the instructions still valid? I followed them carefully twice. I'm using the latest RPI linux release "buster".

I'm trying to do this for a friend who wants to operate digital on the road. I'm way out of my league trying to compile in this environment. I see many warnings coming out, and then a series of errors and it all stops.

Anyone having success on RPI3?

Thanks -- Doug -- K0DXV
moderated Re: Raspberry Pi compile of flrig and fldigi

Cliff, AE5ZA
 

Doug,

The instructions on the fldigi wiki do work correctly if followed exactly. Be sure and read all the notes in line as they are important. I’ve done a bunch of installs lately, each one by the book. I’ve used the previous Buster and the latest Buster released a few weeks ago. Both work fine. Please copy and paste any error messages you get so we can see what’s the issues are.

If you have questions on any of the steps please ask for clarification.

73,
Cliff, AE5ZA

On Dec 28, 2020, at 22:08, Doug Person, KJ0F <doug@...> wrote:

I've tried twice to compile the latest versions flrig and fldigi. They always fail with messages that don't say much. Are the instructions still valid? I followed them carefully twice. I'm using the latest RPI linux release "buster".

I'm trying to do this for a friend who wants to operate digital on the road. I'm way out of my league trying to compile in this environment. I see many warnings coming out, and then a series of errors and it all stops.

Anyone having success on RPI3?

Thanks -- Doug -- K0DXV
moderated Re: Raspberry Pi compile of flrig and fldigi

Ed W3NR
 

On 12/28/20 11:08 PM, Doug Person, KJ0F wrote:

I've tried twice to compile the latest versions flrig and fldigi. They always fail with messages that don't say much. Are the instructions still valid? I followed them carefully twice. I'm using the latest RPI linux release "buster".

I'm trying to do this for a friend who wants to operate digital on the road. I'm way out of my league trying to compile in this environment. I see many warnings coming out, and then a series of errors and it all stops.

Anyone having success on RPI3?

Thanks -- Doug -- K0DXV

_._,_._,_
Without knowing what errors you are seeing it is really hard to help. How much RAM are you working with ?
Ed W3NR
moderated Raspberry Pi compile of flrig and fldigi

Doug Person, KJ0F <doug@...>
 

I've tried twice to compile the latest versions flrig and fldigi. They always fail with messages that don't say much. Are the instructions still valid? I followed them carefully twice. I'm using the latest RPI linux release "buster".

I'm trying to do this for a friend who wants to operate digital on the road. I'm way out of my league trying to compile in this environment. I see many warnings coming out, and then a series of errors and it all stops.

Anyone having success on RPI3?

Thanks -- Doug -- K0DXV
moderated Re: FLDIGI NO RTTY under Big Sur?

Adrian Fewster, VK4TUX
 

Ok, It is not that expensive, and if you ask them for a discount deal, they will usually accommodate.


The support plan provides future versions incl. Dos devices (comports) are now defined in the registry in each bottle.


NET support is excellent in crossover, used by many ham windows programs.




I use it in osx and linux, it's very stable and reliable.


On 29/12/20 12:25 pm, Steven Read wrote:

Thanks Adrian. I used to run Crossover on Linux but had not tried it on newer versions of MacOS because I had heard that anything WINE related quit working when Apple dropped 32-bit library support.

Steven Read - ab9ol - (em79jt) Dublin, IN

From: linuxham@groups.io <linuxham@groups.io> on behalf of Adrian Fewster, VK4TUX <vk4tux@...>
Sent: Monday, December 28, 2020 8:27 PM
To: linuxham@groups.io <linuxham@groups.io>
Subject: Re: [linuxham] FLDIGI NO RTTY under Big Sur?
 

I use crossover, works great up to Big Sur and free trial


https://www.codeweavers.com/crossover#compatibility


I use it to run HRD with other linux ham programs as a DDE CAT interface.





On 29/12/20 11:01 am, Steven Read wrote:
I run an older version of MacOS on my 2014 Mac mini because newer versions of MacOS do not support Wine (no 32-bit support.) My GUESS is that you might be running into a similar issue. As time is an issue, my suggestion is to install a recent version of Ubuntu on a stick & boot from the stick by holding down the Option key to select boot from the stick. I know this is not an ideal answer but you give a date of January 2nd which makes me think that this is time sensitive.

I know both Apple and Microsoft will hate me for telling you that it is possible to install Linux or Windows on an external drive, then boot from that drive. In my case I have a Seagate 4TB portable drive (fits in my shirt pocket when it is not in a protective case.) Understand that running any OS from a USB drive will be VERY SLOW.

Steven Read - ab9ol - (em79jt) Dublin, IN

From: linuxham@groups.io <linuxham@groups.io> on behalf of Bill Turini, KA4GAV via groups.io <bill.turini@...>
Sent: Monday, December 28, 2020 7:10 PM
To: linuxham@groups.io <linuxham@groups.io>
Subject: [linuxham] FLDIGI NO RTTY under Big Sur?
 
I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

The screen displays random characters, and they seem to be of the same randomness if I have the cursor on or off the signal.  The program behaves the same as it did before my OS upgrade, but it just doesn’t appear to be decoding the signal shown on the waterfall display.

And despite all the comments last week, I cannot find a REV key for RTTY.  I had thought that might be the problem, but since the program doesn’t decode on the signal or off, I think it’s something internal to the program.  And also, the lack of a REV key is a problem in the program.

Any comments/suggestions would be appreciated, and thanks for reading.

73’s

Bill
KA4GAV
moderated Re: FLDIGI NO RTTY under Big Sur?

Steven Read
 

Thanks Adrian. I used to run Crossover on Linux but had not tried it on newer versions of MacOS because I had heard that anything WINE related quit working when Apple dropped 32-bit library support.

Steven Read - ab9ol - (em79jt) Dublin, IN

From: linuxham@groups.io <linuxham@groups.io> on behalf of Adrian Fewster, VK4TUX <vk4tux@...>
Sent: Monday, December 28, 2020 8:27 PM
To: linuxham@groups.io <linuxham@groups.io>
Subject: Re: [linuxham] FLDIGI NO RTTY under Big Sur?
 

I use crossover, works great up to Big Sur and free trial


https://www.codeweavers.com/crossover#compatibility


I use it to run HRD with other linux ham programs as a DDE CAT interface.





On 29/12/20 11:01 am, Steven Read wrote:

I run an older version of MacOS on my 2014 Mac mini because newer versions of MacOS do not support Wine (no 32-bit support.) My GUESS is that you might be running into a similar issue. As time is an issue, my suggestion is to install a recent version of Ubuntu on a stick & boot from the stick by holding down the Option key to select boot from the stick. I know this is not an ideal answer but you give a date of January 2nd which makes me think that this is time sensitive.

I know both Apple and Microsoft will hate me for telling you that it is possible to install Linux or Windows on an external drive, then boot from that drive. In my case I have a Seagate 4TB portable drive (fits in my shirt pocket when it is not in a protective case.) Understand that running any OS from a USB drive will be VERY SLOW.

Steven Read - ab9ol - (em79jt) Dublin, IN

From: linuxham@groups.io <linuxham@groups.io> on behalf of Bill Turini, KA4GAV via groups.io <bill.turini@...>
Sent: Monday, December 28, 2020 7:10 PM
To: linuxham@groups.io <linuxham@groups.io>
Subject: [linuxham] FLDIGI NO RTTY under Big Sur?
 
I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

The screen displays random characters, and they seem to be of the same randomness if I have the cursor on or off the signal.  The program behaves the same as it did before my OS upgrade, but it just doesn’t appear to be decoding the signal shown on the waterfall display.

And despite all the comments last week, I cannot find a REV key for RTTY.  I had thought that might be the problem, but since the program doesn’t decode on the signal or off, I think it’s something internal to the program.  And also, the lack of a REV key is a problem in the program.

Any comments/suggestions would be appreciated, and thanks for reading.

73’s

Bill
KA4GAV
moderated flnet 7.3.3.11 posted

Dave, W1HKJ
 

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

Mon Dec 28 19:00:00 2020 -0500  alpha  7.3.3.11

  check-in-list
    * allow user to specifiy left/right justification of callsign field

  HamQTH queries
    * extract email
    * convert lat/lon to 6 place Maidenhead locator if lat/lon present in response

  Color coding
    * fix color coding for callin list entries

  Write Log
    * write log after every change to log-in list
    * add hours, minutes to file name

  Optimizer
    * fix compiler optimizer differences when mixing
      strings with returned char pointers.

  Callook lookup
    * Fix access and parsing of callook.info query
    * Fix locator to azimuth/distance display

  UI mods
    * Enable keypad Enter key for selecting call from pick list
    * Fix controlling order on edit dialog

  new fields
    * added COUNTRY, LOCATOR

  Distance Display
    * User configurable distance display, kilometers, nautical miles, statute miles.

  UI fixes
    * change all configuration items to progStatus
    * increase width of check-ins display lines
    * adjust UI widgets, position and size
    * change arrangement of fields in info panel
      - concatenate comment1, comment2 data fields
        separating each with a semicolon.
    * add user configurable justification, left/right for
      nickname field in check-in list

  autofiles

  mkappbundle
    * modify 'version' to include VERSION_PATCH

  Keyboard Shortcuts
    * Remove &menu items
    * Enable alt-F4 - cleanExit
    * on MacOS/OS-X enable cmd-Q - cleanExit

Version 7.3.3

73, David, W1HKJ
moderated Re: FLDIGI NO RTTY under Big Sur?

Adrian Fewster, VK4TUX
 

I use crossover, works great up to Big Sur and free trial


https://www.codeweavers.com/crossover#compatibility


I use it to run HRD with other linux ham programs as a DDE CAT interface.





On 29/12/20 11:01 am, Steven Read wrote:

I run an older version of MacOS on my 2014 Mac mini because newer versions of MacOS do not support Wine (no 32-bit support.) My GUESS is that you might be running into a similar issue. As time is an issue, my suggestion is to install a recent version of Ubuntu on a stick & boot from the stick by holding down the Option key to select boot from the stick. I know this is not an ideal answer but you give a date of January 2nd which makes me think that this is time sensitive.

I know both Apple and Microsoft will hate me for telling you that it is possible to install Linux or Windows on an external drive, then boot from that drive. In my case I have a Seagate 4TB portable drive (fits in my shirt pocket when it is not in a protective case.) Understand that running any OS from a USB drive will be VERY SLOW.

Steven Read - ab9ol - (em79jt) Dublin, IN

From: linuxham@groups.io <linuxham@groups.io> on behalf of Bill Turini, KA4GAV via groups.io <bill.turini@...>
Sent: Monday, December 28, 2020 7:10 PM
To: linuxham@groups.io <linuxham@groups.io>
Subject: [linuxham] FLDIGI NO RTTY under Big Sur?
 
I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

The screen displays random characters, and they seem to be of the same randomness if I have the cursor on or off the signal.  The program behaves the same as it did before my OS upgrade, but it just doesn’t appear to be decoding the signal shown on the waterfall display.

And despite all the comments last week, I cannot find a REV key for RTTY.  I had thought that might be the problem, but since the program doesn’t decode on the signal or off, I think it’s something internal to the program.  And also, the lack of a REV key is a problem in the program.

Any comments/suggestions would be appreciated, and thanks for reading.

73’s

Bill
KA4GAV
moderated Re: Fldigi Version 4.1.17 not controlling FT-187

Cliff, AE5ZA
 

Hi Marty,

I can’t help on 817 specific issues, but if flrig works RigCat should use the same connection parameters.

73,
Cliff, AE5ZA

On Dec 28, 2020, at 17:46, Marty Hartwell, KD8BJ <mhartwe@...> wrote:

Hi

I have just discovered that version 4.1.17 of Fldigi will not control the FT-817. I discovered this

on a RPi 4 but have built this fldigi version on my Xubuntu 18.4 laptop too.

Now here is the thing, I have also compiled a recent version of Flrig also as a test on both the

Rpi and the Xubuntu Laptop and been able to launch Flrig and connect to the Ft-817 and

then launch the Fldigi and have control that way, so all is not lost, but when I wan to use the

Rpi I would rather just use fldigi for digital modes where all is on the one screen, not a lot

or real estate on the pi with an 8" monitor or smaller. Then with the FT817 there isn't much

more that Flrig give in the way of control and with fldigi I have the log, frequency controls along

with others too.

Yes I have downloaded the xml file and have it in the rigs folder and am in the dialout group

but the only one that can keep it from working is the xml file, and I just downloaded the one

I am using from Dave's site, well the redirected source forge site.

Any ideas, I have also rechecked the rig menu options and I think they are correct.


Marty kd8bj
moderated Re: FLDIGI NO RTTY under Big Sur?

Dave, W1HKJ
 





On-line-help-reference.

The "Rv" button is only active for those modes to which it is applicable.  Some modes are sideband independent.

73, David, W1HKJ

On 12/28/20 6:10 PM, Bill Turini, KA4GAV via groups.io wrote:

I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

The screen displays random characters, and they seem to be of the same randomness if I have the cursor on or off the signal.  The program behaves the same as it did before my OS upgrade, but it just doesn’t appear to be decoding the signal shown on the waterfall display.

And despite all the comments last week, I cannot find a REV key for RTTY.  I had thought that might be the problem, but since the program doesn’t decode on the signal or off, I think it’s something internal to the program.  And also, the lack of a REV key is a problem in the program.

Any comments/suggestions would be appreciated, and thanks for reading.

73’s

Bill
KA4GAV
moderated Re: FLDIGI NO RTTY under Big Sur?

Steven Read
 

I run an older version of MacOS on my 2014 Mac mini because newer versions of MacOS do not support Wine (no 32-bit support.) My GUESS is that you might be running into a similar issue. As time is an issue, my suggestion is to install a recent version of Ubuntu on a stick & boot from the stick by holding down the Option key to select boot from the stick. I know this is not an ideal answer but you give a date of January 2nd which makes me think that this is time sensitive.

I know both Apple and Microsoft will hate me for telling you that it is possible to install Linux or Windows on an external drive, then boot from that drive. In my case I have a Seagate 4TB portable drive (fits in my shirt pocket when it is not in a protective case.) Understand that running any OS from a USB drive will be VERY SLOW.

Steven Read - ab9ol - (em79jt) Dublin, IN

From: linuxham@groups.io <linuxham@groups.io> on behalf of Bill Turini, KA4GAV via groups.io <bill.turini@...>
Sent: Monday, December 28, 2020 7:10 PM
To: linuxham@groups.io <linuxham@groups.io>
Subject: [linuxham] FLDIGI NO RTTY under Big Sur?
 
I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

The screen displays random characters, and they seem to be of the same randomness if I have the cursor on or off the signal.  The program behaves the same as it did before my OS upgrade, but it just doesn’t appear to be decoding the signal shown on the waterfall display.

And despite all the comments last week, I cannot find a REV key for RTTY.  I had thought that might be the problem, but since the program doesn’t decode on the signal or off, I think it’s something internal to the program.  And also, the lack of a REV key is a problem in the program.

Any comments/suggestions would be appreciated, and thanks for reading.

73’s

Bill
KA4GAV
moderated Re: FLDIGI NO RTTY under Big Sur?

Ed W3NR
 

On 12/28/20 7:10 PM, Bill Turini, KA4GAV via groups.io wrote:
I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

The screen displays random characters, and they seem to be of the same randomness if I have the cursor on or off the signal.  The program behaves the same as it did before my OS upgrade, but it just doesn’t appear to be decoding the signal shown on the waterfall display.

And despite all the comments last week, I cannot find a REV key for RTTY.  I had thought that might be the problem, but since the program doesn’t decode on the signal or off, I think it’s something internal to the program.  And also, the lack of a REV key is a problem in the program.

Any comments/suggestions would be appreciated, and thanks for reading.

73’s

Bill
KA4GAV


_._,_._,_

I can't comment on most of your post. But I have never found a use for the REV, only exception was when P5 was not only upside down, but also using 50 baud. That was pre-fldigi days.

Now unless it has changed, way back when Dave and Stelios came up with some miracle coding that fldigi would decode a RTTY signal whether it was up side down or right side up. But it's been several years now and still never in 20 years of RTTY contesting I have never ran into anyone upside down.

Ed W3NR
moderated FLDIGI NO RTTY under Big Sur?

Bill Turini, KA4GAV <bill.turini@...>
 

I recently upgraded my Mac (non M1) to Big Sur and now find that FLDIGI is now working, but not decoding RTTY, and as Jan 2 is rapidly approaching, I’m getting worried.  

I’m running FLDIGI 4.1.17.  on the latest Mac Mini (non M1) with Big Sur.  Everything appears to work on FLDIGI, waterfall, etc, but I get no decode of RTTY signals.  There not being many digital signals on the bands, and I only run RTTY as digital, I’ve been using W1AW transmissions to test with.  PSK31 works fine to decode.  MFSK16 last time I tried did not decode, and W1AW seems not to be transmitting it for their bulletins.  I have not tried the other modes.

The screen displays random characters, and they seem to be of the same randomness if I have the cursor on or off the signal.  The program behaves the same as it did before my OS upgrade, but it just doesn’t appear to be decoding the signal shown on the waterfall display.

And despite all the comments last week, I cannot find a REV key for RTTY.  I had thought that might be the problem, but since the program doesn’t decode on the signal or off, I think it’s something internal to the program.  And also, the lack of a REV key is a problem in the program.

Any comments/suggestions would be appreciated, and thanks for reading.

73’s

Bill
KA4GAV
moderated Fldigi Version 4.1.17 not controlling FT-187

Marty Hartwell, KD8BJ
 

Hi

I have just discovered that version 4.1.17 of Fldigi will not control the FT-817. I discovered this

on a RPi 4 but have built this fldigi version on my Xubuntu 18.4 laptop too.

Now here is the thing, I have also compiled a recent version of Flrig also as a test on both the

Rpi and the Xubuntu Laptop and been able to launch Flrig and connect to the Ft-817 and

then launch the Fldigi and have control that way, so all is not lost, but when I wan to use the

Rpi I would rather just use fldigi for digital modes where all is on the one screen, not a lot

or real estate on the pi with an 8" monitor or smaller. Then with the FT817 there isn't much

more that Flrig give in the way of control and with fldigi I have the log, frequency controls along

with others too.

Yes I have downloaded the xml file and have it in the rigs folder and am in the dialout group

but the only one that can keep it from working is the xml file, and I just downloaded the one

I am using from Dave's site, well the redirected source forge site.

Any ideas, I have also rechecked the rig menu options and I think they are correct.


Marty kd8bj
moderated Re: Icom PCR-1000 not working with latest Flrig.

Dave, GØWBX
 

Eyes painted on!...

The PCR-1000 is working, but the 'S' meter is not showing anything.

I'll dig into that tomorrow, it's half 10 at night here, I like my sleep!

73

Dave B G0WBX.


--
Created on and sent from a Unix like PC running and using free and open source software:
moderated Re: Icom PCR-1000 not working with latest Flrig.

Dave, GØWBX
 

Hi Dave.

OK, adding that include let it compile without error, and when run it outputs to the terminal:-

dave@dave-HP-Compaq-8200-Elite-USDT-PC:~/app-src/flrig-1.3.53.15$ ./src/flrig --config-dir ~/.flrig/pcr-1000
1
2
3       
4
5
6
7
8

But the radio did not power up.

I added a "4a" marker, in the If statement that checks for the H100 flag when the radio is first queried, thus:-

        if (replystr.rfind("H100") != std::string::npos) {
                std::cout << "4a" << std::endl;
                sendCommand(power_on_command,6);
                showresp(WARN, ASC, "Power ON", power_on_command , replystr);
                strace("Power ON", power_on_command);
        }

Sadly, that 4a flag was not shown. 

Ah Ha!    If the H100 flag is not seen send the power on command.   Hmmm...

I changed that funciton to:-

        if (replystr.rfind("H100") == std::string::npos) {      // from != to == and it now works.
                std::cout << "4a" << std::endl;
                sendCommand(power_on_command,6);
                showresp(WARN, ASC, "Power ON", power_on_command , replystr);
                strace("Power ON", power_on_command);
        }

And, now the 4a flag is seen, and the radio now powers up and is usable!

dave@dave-HP-Compaq-8200-Elite-USDT-PC:~/app-src/flrig-1.3.53.15$ ./src/flrig --config-dir ~/.flrig/pcr-1000
1
2
3
4
4a
5
6
7
8

The older version of Flrig (V 1.3.39) had this in its initialisation routine.

    if(replystr.rfind("H100")) {                                // implied ==   I thnk
        sendCommand(power_on_command,6);
        showresp(WARN, ASC, "Power ON", power_on_command , replystr);
    }

That would confirm that we need to trigger the power on command, when "H100" is seen when the radio is first "looked at".  And no, I don't know why I didn't spot that difference before.

I don't have access (at this time) to the PCR-1000 technical reference, but hey ho.  It works now in this current (alpha) version of Flrig.  Hopefully it may help the other guy?   (Jim W5ZIT)

For their info.  The serial port used here, is a generic older Prolific device, that has all the hardware handshake lines present, and I'm using Linux Mint 19.3 64 bit, on an Intel architecture PC, not a Pi.

I don't have the full details, but the serial cable used is wired to Icom's specifications from what I recall at least.

All the best Dave and listeners.

73

Dave B G0WBX.



-- 
Created on and sent from a Unix like PC running and using free and open source software:
6081 - 6100 of 49882