Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

wsjtx: unvendor hamlib #266355

Merged
merged 2 commits into from
Nov 9, 2023
Merged

wsjtx: unvendor hamlib #266355

merged 2 commits into from
Nov 9, 2023

Conversation

mattmelling
Copy link
Contributor

Description of changes

Switch to building from upstream repo rather than "super" tarball containing a hamlib distribution.

During investigation of #265747, #265897, learned from wstjx-devel mailing list that there is no longer a need to build wsjtx using the vendored hamlib, and a number of other distributions are building against their native hamlib packages. This change simplifies the build for wsjtx.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 23.11 Release Notes (or backporting 23.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

lasandell
lasandell approved these changes Nov 9, 2023
View reviewed changes
Copy link
Contributor

@lasandell lasandell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, straightforward and tested alright.

@Mindavi Mindavi merged commit 8e81cc9 into NixOS:master Nov 9, 2023
27 of 28 checks passed
@dotemup
Copy link
Contributor

dotemup commented Nov 9, 2023 •
edited

@mattmelling Tested today, failed on split mode with FLRig

Hamlib error: Content-length: 168

<?xml version="1.0"?>
<methodResponse><params><param>
	<value><array><data><value></value><value></value></data></array></value>
</param></params></methodResponse>

xml_parse2: value returned=''
xml_parse2: xml='<methodResponse><params><param>
	<value><array><data><value></value><value></value></data></array></value>
</param></params></methodResponse>
'
flrig_transaction: no value returned
    4:flrig.c(600):flrig_transaction returning(8) 
   3:flrig.c(1701):flrig_get_mode returning(8) 
  2:flrig.c(2018):flrig_set_split_freq_mode returning(8) 
 1:rig_set_split_freq_mode: elapsed=818ms
 1:rig.c(4843):rig_set_split_freq_mode returning(8) 
Protocol error
Protocol error
 while setting split TX frequency and mode

Timestamp: 2023-11-09T23:53:01.866Z ```

@Mindavi
Copy link
Contributor

Mindavi commented Nov 10, 2023

Sorry about merging so eagerly, figured it was good. Do you want a revert or what are next steps?

@mattmelling
Copy link
Contributor Author

Sorry about merging so eagerly, figured it was good. Do you want a revert or what are next steps?

I don't think this is a regression for WSJTX generally; currently using it in the same configuration as @dotemup with flrig split mode and it works with my rig.

This PR came about while working on other issues around hamlib which I am working through.

Just my 2c, if others agree that this should be reverted then I'm happy to shelve and come back to it later.

@dotemup
Copy link
Contributor

dotemup commented Nov 10, 2023 •
edited

Hmm, I wonder what would cause the issue I'm getting then? You're using the nixpkgs flrig correct @mattmelling? It's very peculiar.

I could probably go up to R&L tomorrow and see if I can try on a 7300 (if that's what you're using, you had mentioned it before) to see if I get the same issue with a different rig in FLRig.

FWIW this is my basic configuration.nix. Is there something different you're using?

# Edit this configuration file to define what should be installed on
# your system.  Help is available in the configuration.nix(5) man page
# and in the NixOS manual (accessible by running ‘nixos-help’).

{ config, options, pkgs, ... }:

let 
  local-pkgs = import /home/myuseraccount/code/nixpkgs {
    config.allowInsecurePredicate = name: true;
	config.allowUnfree = true;
  };
in


{
  imports =
    [
      # Include the results of the hardware scan.
      ./hardware-configuration.nix
    ];

  # Bootloader.
  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  networking.hostName = "nixos"; # Define your hostname.
  # networking.wireless.enable = true;  # Enables wireless support via wpa_supplicant.

  # Configure network proxy if necessary
  # networking.proxy.default = "http://user:password@proxy:port/";
  # networking.proxy.noProxy = "127.0.0.1,localhost,internal.domain";

  # Enable networking
  networking.networkmanager.enable = true;

  # Set your time zone.
  time.timeZone = "America/New_York";

  # Select internationalisation properties.
  i18n.defaultLocale = "en_US.UTF-8";

  i18n.extraLocaleSettings = {
    LC_ADDRESS = "en_US.UTF-8";
    LC_IDENTIFICATION = "en_US.UTF-8";
    LC_MEASUREMENT = "en_US.UTF-8";
    LC_MONETARY = "en_US.UTF-8";
    LC_NAME = "en_US.UTF-8";
    LC_NUMERIC = "en_US.UTF-8";
    LC_PAPER = "en_US.UTF-8";
    LC_TELEPHONE = "en_US.UTF-8";
    LC_TIME = "en_US.UTF-8";
  };

  # Enable the X11 windowing system.
  services.xserver.enable = true;

  # Enable the Desktop Environment.
  # services.xserver.displayManager.gdm.enable = true;
  # services.xserver.desktopManager.gnome.enable = true;
  services.xserver.displayManager.sddm.enable = true;
  services.xserver.desktopManager.plasma5.enable = true;

  # Configure keymap in X11
  services.xserver = {
    layout = "us";
    xkbVariant = "";
  };

  # Enable CUPS to print documents.
  services.printing.enable = true;

  # Enable sound with pipewire.
  sound.enable = true;
  hardware.pulseaudio.enable = false;
  security.rtkit.enable = true;
  services.pipewire = {
    enable = true;
    alsa.enable = true;
    alsa.support32Bit = true;
    pulse.enable = true;
    # If you want to use JACK applications, uncomment this
    #jack.enable = true;

    # use the example session manager (no others are packaged yet so this is enabled by default,
    # no need to redefine it in your config for now)
    #media-session.enable = true;
  };

  # Enable touchpad support (enabled default in most desktopManager).
  # services.xserver.libinput.enable = true;

  # Define a user account. Don't forget to set a password with ‘passwd’.
  users.users.myuseraccount = {
    isNormalUser = true;
    description = "My Name";
    extraGroups = [ "networkmanager" "wheel" "dialout" ];
    packages = with pkgs; [
      # put user specific packages here
    ];
  };

  # Enable automatic login for the user.
  services.xserver.displayManager.autoLogin.enable = true;
  services.xserver.displayManager.autoLogin.user = "myuseraccount";

  # Workaround for GNOME autologin: https://github.com/NixOS/nixpkgs/issues/103746#issuecomment-945091229
  systemd.services."getty@tty1".enable = false;
  systemd.services."autovt@tty1".enable = false;

  # Allow unfree packages
  nixpkgs.config.allowUnfree = true;

  # List packages installed in system profile. To search, run:
  # $ nix search wget
  environment.systemPackages = with local-pkgs; [
    firefox
    wget
    git
    flrig
    fldigi
    wsjtx
    gridtracker
    tqsl
    pat
    js8call
    qsstv
    vscode
    sdrpp
    direwolf
    nixpkgs-fmt
    vscode
    gh
    gpsd
    chrony
    # yaac #installed manually for now as haven't sorted out build from source completely.
  ];



# Enable dconf (gsettings)
programs.dconf.enable = true;

# Allow openssl 1.1.1u for TQSL
nixpkgs.config.permittedInsecurePackages = [
"openssl-1.1.1u"
];

# Setup udev rules
services.udev.extraRules = ''
    SUBSYSTEM=="tty", GROUP="dialout", MODE="0660", ATTRS{product}=="CP2102N USB to UART Bridge Controller", SYMLINK+="digirig"
    SUBSYSTEM=="tty", GROUP="dialout", MODE="0660", ATTRS{product}=="u-blox 7 - GPS/GNSS Receiver", SYMLINK+="gps"
'';

# Setup GPSD rules
services.gpsd = {
  enable = true;
  nowait = true;
  devices = [ "/dev/gps" ];
};

# Setup chrony
services.chrony = {
  enable = true;
  servers = ["pool.ntp.org"];
  extraFlags = ["-r" "-s"];
  extraConfig = ''
    makestep 1 3
    refclock SHM 0 offset 0.5 delay 0.2 refid NMEA
  '';
};

# Some programs need SUID wrappers, can be configured further or are
# started in user sessions.
# programs.mtr.enable = true;
# programs.gnupg.agent = {
#   enable = true;
#   enableSSHSupport = true;
# };

# List services that you want to enable:

# Enable the OpenSSH daemon.
# services.openssh.enable = true;

# Open ports in the firewall.
# networking.firewall.allowedTCPPorts = [ 5900 ];
# networking.firewall.allowedUDPPorts = [ ... ];
# Or disable the firewall altogether.
# networking.firewall.enable = false;

# This value determines the NixOS release from which the default
# settings for stateful data, like file locations and database versions
# on your system were taken. It‘s perfectly fine and recommended to leave
# this value at the release version of the first install of this system.
# Before changing this value read the documentation for this option
# (e.g. man configuration.nix or on https://nixos.org/nixos/options.html).
system.stateVersion = "23.05"; # Did you read the comment?

}

@dotemup
Copy link
Contributor

dotemup commented Nov 10, 2023 •
edited

I tried a number of things to try and resolve but still not quite working, even tested the rc1 and rc2 of 2.7.0 same issues when building from git source.

Tried adding cmake flags like the fedora spec does for their packaging but no change. Could it be an issue with the hardening of gcc in the stdenv, I know I get a ton of warnings for a lot of the c and fortran code during the build.

Reverted back to my old generation where the build came from the superbuild tarball and back to working. Strange stuff.

@mattmelling
Copy link
Contributor Author

I'm using wsjtx built from this PR's branch, with flrig 2.0.04 from nixpkgs trunk.

I don't think it is an issue with your system configuration. It looks as if flrig isn't returning anything when asked by hamlib what mode a particular VFO is in. Either it is a bug in hamlib or the version update exposes a bug in flrig.

flrig has some options to enable traces which might show what is going on when hamlib makes this particular request.

I've spent most of the evening here playing with the js8call/hamlib code to figure out where the delays are coming from, which is also related to querying the rig state when operating flrig in split mode on my IC7300.

This doesn't occur with hamlib rigctld, so my suspicion is that it is related to how hamlib is interacting with flrig, and likely that you are running in to something similar, the major difference being the rig.

@dotemup
Copy link
Contributor

dotemup commented Nov 11, 2023 •
edited

Alright so I did a very deep dive last night looking into the xml responses in trace and comparing to the source for hamlib 4.5.5 to see how the flrig transactions were being carried out. Something weird happening when it tries to start checking for features.

Also started hacking on the hamlib_4 package to build it from source instead the tarball to see if there was anything weird going on there before trying to build wsjtx. I thought there could be an issue with rigmem xml support when building hamlib.
https://github.com/Hamlib/Hamlib/blob/6351d5deacd5b2ba37c307fe6430965fa86573f4/configure.ac#L451-L465

Here's the wsjtx error returned again.
wsjtx-error.txt

Here's a dump of the flrig trace.
xml-trace.txt

When the transaction starts Hamlib queries rig to see if it has these rig features.
https://github.com/Hamlib/Hamlib/blob/6351d5deacd5b2ba37c307fe6430965fa86573f4/rigs/dummy/flrig.c#L875-L903

I'm not sure where those are defined as the 817/818 code it doesn't have those bwA bwB calls to check bandwidth on the vfo but only a few rigs do, the 7300 doesn't seem to have them directly either. So I'm not sure how those get worked out...
https://github.com/Hamlib/Hamlib/blob/master/rigs/yaesu/ft817.c#L442-L597

I think the issue in the xml trace is here:

rig.get_bwA call returns a valid response with NONE, so flrig thinks we have that feature, which isn't really true.

06:00:46.801 : readRequest:
 <?xml version="1.0"?>
<?clientid="hamlib(9444)"?>
<methodCall><methodName>rig.get_bwA</methodName>
</methodCall>
06:00:46.801 : writeResponse:
 HTTP/1.1 200 OK
Server: XMLRPC++ 0.8
Content-Type: text/xml
Content-length: 172
 
<?xml version="1.0"?>
<methodResponse><params><param>
	<value><array><data><value>NONE</value><value></value></data></array></value>
</param></params></methodResponse>

Then tries to do the rig.set_bwA which faults so it should know we don't have that feature.

06:00:46.659 : readRequest:
 <?xml version="1.0"?>
<?clientid="hamlib(9444)"?>
<methodCall><methodName>rig.set_bwA</methodName>
</methodCall>
06:00:46.659 : writeResponse:
 HTTP/1.1 200 OK
Server: XMLRPC++ 0.8
Content-Type: text/xml
Content-length: 263
 
<?xml version="1.0"?>
<methodResponse><fault>
	<value><struct><member><name>faultCode</name><value><i4>-1</i4></value></member><member><name>faultString</name><value>rig.set_bwA: unknown method name</value></member></struct></value>
</fault></methodResponse>

But the flrig.c for bandwidth says, oh you have get_bwA you should have get_bwB. Which we don't have it.
https://github.com/Hamlib/Hamlib/blob/6351d5deacd5b2ba37c307fe6430965fa86573f4/rigs/dummy/flrig.c#L1685-L1704

Because of that when it calls get_bwB there's no data in the xml. It doesn't return NONE like the get_bwA does. So it tries it 4 times and then throws an error in wsjtx.

06:00:46.809 : readRequest:
 <?xml version="1.0"?>
<?clientid="hamlib(9444)"?>
<methodCall><methodName>rig.get_bwB</methodName>
</methodCall>
06:00:46.809 : writeResponse:
 HTTP/1.1 200 OK
Server: XMLRPC++ 0.8
Content-Type: text/xml
Content-length: 168
 
<?xml version="1.0"?>
<methodResponse><params><param>
	<value><array><data><value></value><value></value></data></array></value>
</param></params></methodResponse>

I switch from true split to fake it and things started working... But kind of frustrating and dumb because I do have split, just not any bandwidth control.

@mattmelling
Copy link
Contributor Author

That is very interesting, hadn't got that far in to it myself.

Span up a Fedora 39 VM earlier and the issue isn't there, however one thing I noted was that distro has flrig 2.0.03 rather than 2.0.04.

Might be worth posting about this to the hamlib-devel and fldigi-devel lists as it is clearly an issue in how those packages are talking to each other.

@dotemup
Copy link
Contributor

dotemup commented Nov 11, 2023 •
edited

Also I just set js8call with your hacked package for hamlib_4 support and it works the same as wsjtx so using fake it for now solves my problem. So the issue isn't with wsjtx or js8call rather within hamlib flrig.c.

Super dumb, I've always used true split.

@dotemup
Copy link
Contributor

dotemup commented Nov 11, 2023

Posted to hamlib-developers awaiting moderation approval on fldigi-devel @ lists.sourceforge.net for both. Let's see what anyone else thinks.

@mdblack98 mdblack98 mentioned this pull request Nov 13, 2023
Closed
@mdblack98
Copy link

Try the latest Hamlib -- I put in a patch that should fix this.
https://github.com/Hamlib/Hamlib

@dotemup
Copy link
Contributor

dotemup commented Nov 13, 2023 •
edited

I do have a branch to build from source updated in my repo somewhere. Can fetchgit pull latest git source I've only used tags for ref. Is there another way to just pull down the latest in the main/master branch?

@mdblack98 thanks for following up on this for me :)

@mdblack98
Copy link

mdblack98 commented Nov 13, 2023 via email

@Mindavi
Copy link
Contributor

Mindavi commented Nov 13, 2023 •
edited

fetchgit can also take a git hash, see e.g. hydra_unstable.

https://noogle.dev/?selected=%22builtins.fetchGit%22&term=%22fetchgit+%22

@dotemup
Copy link
Contributor

dotemup commented Nov 13, 2023 •
edited

I don't know what fetchgit is.... I just use plain ol' git....

It's a nix specific thing, no worries :)

fetchgit can also take a git hash, see e.g. hydra_unstable.

Thanks @Mindavi I'll try that in my hacked branch.

@dotemup
Copy link
Contributor

dotemup commented Nov 14, 2023 •
edited

Unfortunately it looks like it has similar behavior. In wsjtx it goes orange/red faster and with more delay while it's making decisions though. Same error message as before.

Built from hamlib from latest source including the most recent commit via this nix hack, I've been trying variations of building from source with different flags/libs before trying this latest git fetch so its a bit wild in there with extra things:

@relrod Once we get this sorted can we do something similar instead of using a tarball?

{ lib
, stdenv
, fetchgit
, autoconf
, automake
, libtool
, pkg-config
, swig
, perl
, python3
, ncurses
, tcl
, libxml2
, gd
, libusb1
, readline
, boost
, perlPackages
, xmlSupport ? true
, pythonBindings ? true
, tclBindings ? true
, perlBindings ? true
}:

stdenv.mkDerivation rec {
  pname = "hamlib";
  version = "4.5.5";

  src = fetchgit {
    url = "https://github.com/${pname}/${pname}.git";
    rev = "394cb4cbcf53971ac5f5e2ede0b0c488be989528";
    sha256 = "sha256-ZqbhkjNfeOTW7JgaTqv+C4gJ0icmnMDHfVyl4fqXeGg=";
  };

  preConfigure = ''
    ./bootstrap
  '';

  nativeBuildInputs = [
    autoconf
    automake
    libtool
    pkg-config
    swig
  ] ++ lib.optionals perlBindings [ perl ]
    ++ lib.optionals tclBindings [ tcl ]
    ++ lib.optionals perlBindings [ python3 ];  

  buildInputs = [
    readline
    ncurses
    gd
    libusb1
    boost
  ] ++ lib.optionals perlBindings [ perl perlPackages.ExtUtilsMakeMaker ]
    ++ lib.optionals tclBindings [ tcl ]
    ++ lib.optionals pythonBindings [ python3 ]
    ++ lib.optionals xmlSupport [ libxml2 ];
    

  configureFlags = lib.optionals perlBindings [ "--with-perl-binding" ]
    ++ lib.optionals tclBindings [ "--with-tcl-binding" "--with-tcl=${tcl}/lib/" ]
    ++ lib.optionals pythonBindings [ "--with-python-binding" ]
    ++ lib.optionals xmlSupport [ "--with-xml-support"];

  meta = with lib; {
    description = "Runtime library to control radio transceivers and receivers";
    longDescription = ''
    Hamlib provides a standardized programming interface that applications
    can use to send the appropriate commands to a radio.

    Also included in the package is a simple radio control program 'rigctl',
    which lets one control a radio transceiver or receiver, either from
    command line interface or in a text-oriented interactive interface.
    '';
    license = with licenses; [ gpl2Plus lgpl2Plus ];
    homepage = "https://hamlib.sourceforge.net";
    maintainers = with maintainers; [ relrod ];
    platforms = with platforms; unix;
  };
}

Once I had the hacked hamlib4 package from the latest I rebuilt wsjtx and launched from /result/bin

Here's the trace from flrig:
trace-xml-latest.txt

Error from wsjtx, the stack trace line callouts are different so it's for sure using the latest code. But essentially the same result.

Hamlib error: Content-length: 168

<?xml version="1.0"?>
<methodResponse><params><param>
	<value><array><data><value></value><value></value></data></array></value>
</param></params></methodResponse>

xml_parse2: value returned=''
xml_parse2: xml='<methodResponse><params><param>
	<value><array><data><value></value><value></value></data></array></value>
</param></params></methodResponse>
'
flrig_transaction: no value returned
     6:flrig.c(604):flrig_transaction returning(8) 
    5:flrig.c(1760):flrig_get_mode returning(8) 
   4:flrig.c(2080):flrig_set_split_freq_mode returning(8) 
  3:rig_set_split_freq_mode: elapsed=715ms
  3:rig.c(5131):rig_set_split_freq_mode returning(8) 
Protocol error
Protocol error
 while setting split TX frequency and mode

Timestamp: 2023-11-14T01:06:30.842Z

@mdblack98
Copy link

mdblack98 commented Nov 14, 2023 via email

@dotemup
Copy link
Contributor

dotemup commented Nov 14, 2023 •
edited

@mdblack98 Latest worked somewhat, just feels a little slow on TX. Starts maybe 2-2.5s into the 15s cycle. I'll capture a wsjtx debug shortly and follow up.

Something interesting is the split frequency tries to set with an offset 1000hz like normal, but then on switch changes back to center. Then sticks to the 1000hz offset. Not sure if that's 100% working as expected. For example on 2m where I'm testing it usually shows, 144.174 / 144.175 when working in the top half of the sideband. 144.174 / 144.173 when working in the lower half of the sideband.

Perhaps part of this is the 2s delay.

It feels like it's trying to fake it while using split. Change the current VFO frequency as well as changing VFO.

Pulled at this commit Hamlib/Hamlib@d868f1a

  src = fetchgit {
    url = "https://github.com/${pname}/${pname}.git";
    rev = "d868f1a545a753f1b8b1c47b30ae0383b3ff4483";
    sha256 = "sha256-rce0pQ1M8loLtkaD7SGOLjIo2ZhUuTk2Y9K2+AI1XR8=";
  };

@dotemup
Copy link
Contributor

dotemup commented Nov 14, 2023 •
edited

Here's the wsjtx_rigctl debug from my test
WSJT-X_RigControl.log

Actions taken:

  • Launched wsjtx built with hamlib from latest commit referenced above.
  • Re-selected 2m to ensure correct setting sent to cat control / rig (flrig - ft-818)
  • FL Rig showed expected settings (144.174 / 144.175 / DIG)
  • Waited for new cycle to enable TX in off cycle (TX started at ~2s/15s)
  • Allowed TX to complete one additional round (TX started at ~2s/15s)
  • Halted TX
  • Closed WSJTX

Here's some screenshots with the timing in above steps.

Reselecting 2m before starting any TX.
Screenshot_20231114_184050

First TX Cycle
Screenshot_20231114_184122

Second TX Cycle
Screenshot_20231114_184145

I also just tried a few more attempts to try and track down the issue with the split switching/setting frequency and it's inconsistent behavior. So I'm not sure exactly what's happening, sometimes it's on the right VFO but wrong frequency, sometimes it's on the wrong VFO and right frequency, sometimes both wrong... Very strange.

@mdblack98
Copy link

mdblack98 commented Nov 15, 2023 via email

@dotemup
Copy link
Contributor

dotemup commented Nov 15, 2023

@mdblack98 Thanks, I'll try the latest here in a few hours at lunch and i'll try directly in wsjtx too.

Will that bug fix correct the offset frequency issue described?

Will post results here as soon as I can.

@dotemup
Copy link
Contributor

dotemup commented Nov 15, 2023 •
edited

I set the rig in wsjtx from yesterday's build to ft818 instead of flrig works okay but still has some odd behavior when setting the offset frequency, looks like it cycles twice before setting the correct frequency offset. Doesn't seem to be changing vfo, just swapping the frequency but much harder to tell without FLRIG.

I rebuilt hamlib to the latest commit, then rebuilt wsjtx using the latest lib, failed to open wsjtx at first but then got in and switched to FLRIG. That also seems to work okay now less delay than before which is acceptable and similar to that when I set the rig directly in wsjtx. TX frequency also seems to be getting set correctly as well. However now it's not split, VFO doesn't change, just the frequency changing on VFO_A.

Here's the wsjtx debug from FLRIG
FLRIG-WSJT-X_RigControl.log

Then tried to revert to setting the rig in WSJTX to FT818 when built from the latest hamlib commits and I now get seg faults. FLRIG works, Direct Rig doesn't. Not sure what's happening there.

@dotemup
Copy link
Contributor

dotemup commented Dec 5, 2023

@mdblack98 any chance of a minor version to hamlib so we can target in our package? Fetching master isn't really ideal for packaging. I know you're busy and lots of activity in hamlib just not sure how far our 4.6 is or if there's a chance we could get a 4.5.6 out first?

Thanks!

@mdblack98
Copy link

Is the current version of Hamlib working OK on both FLRig and direct connect?

@dotemup
Copy link
Contributor

dotemup commented Dec 5, 2023

Yes current release working as expected. Had to re-evaluate proper split as it was working improperly for so long by switching A/B previously instead of just using B frequency when split is enabled properly.

Haven't had any issues since the weird segfault issues on one of the builds when switching between direct and with flrig.

All tested and working in latest for FT818 for direct and with flrig.

@mdblack98
Copy link

mdblack98 commented Dec 8, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lasandell lasandell lasandell approved these changes

@numinit numinit Awaiting requested review from numinit

Assignees
No one assigned
Labels
10.rebuild-darwin: 1-10 10.rebuild-darwin: 1 10.rebuild-linux: 1-10 11.by: package-maintainer 12.approvals: 1 12.approved-by: package-maintainer
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
6 participants
@mattmelling @dotemup @Mindavi @mdblack98 @lasandell @delroth