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.

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

Dismatching device coderate #51

Closed
sergorl opened this issue Oct 17, 2022 · 4 comments
Closed

Dismatching device coderate #51

sergorl opened this issue Oct 17, 2022 · 4 comments

Comments

@sergorl
Copy link

sergorl commented Oct 17, 2022

Dear @brocaar, I see in chirpstack v4 chirpstack/chirpstack/src/downlink/helpers.rs, here only chirpstack_api::gw::CodeRate::Cr45.into() is used for all devices despite their requested coderate:

pub fn set_tx_info_data_rate(
    tx_info: &mut chirpstack_api::gw::DownlinkTxInfo,
    dr: &DataRateModulation,
) -> Result<()> {
    match dr {
        DataRateModulation::Lora(v) => {
            tx_info.modulation = Some(gw::Modulation {
                parameters: Some(gw::modulation::Parameters::Lora(gw::LoraModulationInfo {
                    bandwidth: v.bandwidth,
                    spreading_factor: v.spreading_factor as u32,
                    code_rate: chirpstack_api::gw::CodeRate::Cr45.into(),
                    polarization_inversion: true,
                    code_rate_legacy: "".into(),
                })),
            });
        }
        DataRateModulation::Fsk(v) => {
            tx_info.modulation = Some(gw::Modulation {
                parameters: Some(gw::modulation::Parameters::Fsk(gw::FskModulationInfo {
                    datarate: v.bitrate,
                    frequency_deviation: v.bitrate / 2, // see: https://github.com/brocaar/chirpstack-gateway-bridge/issues/16
                })),
            });
        }
        DataRateModulation::LrFhss(_) => {
            return Err(anyhow!("LR-FHSS is not supported for downlink"));
        }
    }

    Ok(())
}

I believe that’s why I face this warning in my packet-forwarder:

chirpstack forum

and I believe that’s why I face infinite loop of Join Request from my device ISM2400.

P.S.: In my opinion this behaviour is wrong, since device may have different coderates - not only 4/5

@brocaar
Copy link
Contributor

brocaar commented Oct 19, 2022

Actually, excluding 2.4 GHz devices (which are not part of the LoRa Alliance specs), all devices should use 4/5 as coding rate when using LoRa modulation:

image

I will look into this for 2.4GHz, it might be different.

@brocaar
Copy link
Contributor

brocaar commented Nov 4, 2022

Update: If using the ChirpStack Gateway OS (which uses the Concentratord instead of the UDP packet-forwarder), the downlinks are working fine with coding-rate "4/5". I did notice that the 2.4 GHz UDP packet-forwarder only accepts "4/8LI" as downlink coding-rate (https://github.com/Lora-net/gateway_2g4_hal/blob/master/packet_forwarder/src/lora_pkt_fwd.c#L1686), however "4/5" is a valid coding-rate in the HAL (https://github.com/Lora-net/gateway_2g4_hal/blob/master/libloragw/inc/loragw_hal.h#L74).

Nothing in the ISM2400 proposal states that downlinks must use "4/8LI" as downlink coding-rate. I have asked Semtech if they can confirm the correct downlink coding-rate for ISM2400 and also if they could make this explicit in the ISM2400 document.

@brocaar
Copy link
Contributor

brocaar commented Nov 8, 2022

I just got the confirmation that 2.4 GHz must indeed use "4/8LI" as downlink coding-rate. This means that we need to add the LoRa coding-date to each region configuration (or DataRateModulation). I will look into this soon.

@brocaar brocaar closed this as completed in e2214f9 Nov 8, 2022
@brocaar
Copy link
Contributor

brocaar commented Nov 8, 2022

The above commit fixes this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants