Regarding the issue of echopype processing narrowband data from two frequency transducers of the EK80 mini

[zzq0430]

Hello, I am a Master's student currently conducting research on the topic of fishery resource assessment. I would like to ask for your assistance with the following issue:

My transducer is an EK80 mini, featuring two transducers with frequencies of 120 kHz and 200 kHz, both utilizing CW narrowband pulses transmitted sequentially.

When I use echopype to parse and calculate my .raw files, specifically when calling the compute_Sv function, I find that data for only one channel is present, and the data for the other channel is missing.

I have been unable to solve this problem and am seeking guidance from the developers. I would be extremely grateful if you could provide a solution.

Attached is my raw data file, please check it.Thank you!
EK80.zip

[LOCEANlloydizard]

Hi @zzq0430,

Thanks a lot for pointing this out!

I’ve had a look at your file, and I think the cause of the error is exactly what you mentioned: the CW narrowband pulses are transmitted sequentially. Because of this ping alternation, several metadata fields are NaN every other ping.
For instance, if we do:

import echopype as ep
import numpy as np

raw_file = "./data/buoy03-D20251128-T073409.raw"
ed = ep.open_raw(raw_file=raw_file, sonar_model="EK80", use_swap=True)
beam = ed["Sonar/Beam_group1"]
tp = beam["transmit_type"]
print("unique transmit_type:", np.unique(tp.values))

we obtain:

unique transmit_type: ['CW' 'nan'].

In the current code, if not all transmit_type == "CW", this is interpreted as “there must be BB pings”. In your case, that’s triggered just because of the nan values from the ping-alternating pattern, even though everything is actually CW.

I work on a small fix and will open a PR so we can discuss whether it’s the right approach with @leewujung, but in the meantime you can apply the following local change if you want to get things working right now.

In calibrate_ek.py, look for the static method _get_chan_dict, and replace it with:

    @staticmethod
    def _get_chan_dict(beam: xr.Dataset) -> Dict:
        """
        Build dict to select BB and CW channels from complex samples where data
        from both waveform modes may co-exist.
        """
        transmit_type = beam["transmit_type"]

        # treat string "nan" as missing 
        transmit_type_clean = transmit_type.where(
            transmit_type.notnull() & (transmit_type != "nan")
        )

        valid = transmit_type_clean.dropna(dim="ping_time", how="all")

        # compute all_cw only on the cleaned variable
        all_cw = bool((valid == "CW").where(valid.notnull(), True).all())

        if not all_cw:
            first_ping_transmit_type = (
                transmit_type_clean.isel(ping_time=0).drop_vars("ping_time")
            ).compute()
            return {
                # For BB: Keep only non-CW channels (LFM or FMD) based on transmit_type
                "BB": first_ping_transmit_type.where(
                    first_ping_transmit_type != "CW", drop=True
                ).channel,  # noqa
                # For CW: Keep only CW channels based on transmit_type
                "CW": first_ping_transmit_type.where(
                    first_ping_transmit_type == "CW", drop=True
                ).channel,  # noqa
            }
        else:
            # All channels are CW
            return {"BB": None, "CW": beam.channel}

With this change, both 120 and 200 kHz channels are correctly treated as CW, and you can calibrate and plot the data without issues.

You should be good to go while we work on a proper fix in echopype itself. Cheers!

[LOCEANlloydizard]

Ref: #1578

[zzq0430]

Thank you so much for the incredibly detailed and helpful explanation! This makes perfect sense and confirms what I suspected.I will apply the local fix you provided to resolve my current issue.Really appreciate you looking into this so quickly and providing a working solution. I'll keep an eye out for the official PR and fix.

[LOCEANlloydizard]

Those points are actually addressed in #1508, so I’m closing this discussion now :) Don’t hesitate to ping us if you run into anything else! Cheers!