change init to be consistent with set_lora_modem() doc

[taotien]

I've been trying to get the Adafruit LoRa Radio RFM95W to work for a while, and found this bit to be inconsistent with the documentation in the sx1276_7_8_9, and was what prevented the radio from working

[ceekdee]

• For the sx1276/7/8/9, the RadioKind reset() sets the Semtech chip in sleep mode to ensure that henceforth it is configured as a LoRa radio. All settings of state after that ensure LoRa mode is maintained:

impl LoRaMode {
/// Mode value, including LoRa flag
pub fn value(self) -> u8 {
(self as u8) | 0x80u8
}
}

• self.ensure_ready(RadioMode::Sleep).await?; does nothing for the sx1276/7/8/9 RadioKind;

• changing the API init() function affects all LoRa chips, not just the sx1276/7/8/9. Changes should be restricted to the RadioKind implementation.

It is not clear to me at this point that the current implementation is out of spec, nor why the RFM95W fails to initialize properly.

If it needs to be pushed into sleep twice to be properly initialized, consider a change to the sx1276/7/8/9 radio kind reset() function to do it there. Also, add a new board type for this board in mod_params.rs and only call the extra sleep() call for that board type.

[taotien]

The problem was that set_suspend was called after the reset, but before the set_lora_modem. Perhaps set_sleep should be set inside set_lora_modem in the sx126X impl? I don't have other chips to test this on, only these feathers.

I forgot ensure_ready doesn't do anything, although the init routine in the RadioHead Arduino library I based this change on does call a register read to check if sleep was properly entered.

    // Set sleep mode, so we can also set LORA mode:
    spiWrite(RH_RF95_REG_01_OP_MODE, RH_RF95_MODE_SLEEP | RH_RF95_LONG_RANGE_MODE);
    delay(10); // Wait for sleep mode to take over from say, CAD
    // Check we are in sleep mode, with LORA set
    if (spiRead(RH_RF95_REG_01_OP_MODE) != (RH_RF95_MODE_SLEEP | RH_RF95_LONG_RANGE_MODE))
    {
//	Serial.println(spiRead(RH_RF95_REG_01_OP_MODE), HEX);
	return false; // No device present?
    }

I'll add a board type once I figure out some of the other specifics, as I had to comment out set_oscillator to get it to work as well.

[ceekdee]

Thank you for working through the specifics for the Feather boards. It will be great to get that into lora-phy. The initial implementation was tested on an stm32l0.

One additional thing to note for sx1276/7/8/9 is that timeout detection in single read mode does not work. To do that requires setting up an extra DIO pin to await IRQ interrupts. Since I can't be sure the extra pin will be available across all sx1276/7/8/9 boards, I am testing polling for symbol timeout instead, which I believe will be a better solution across all kinds of Semtech chips and will better support LoRaWAN read windowing. This will be part of a version 2 release, since it requires slight API changes to accommodate polling.

Read continuous mode, where timeout is determined by the calling layer, does work in version 1.

[ceekdee]

As you run into additional issues with the Feather boards, I'd be glad to help brainstorm solutions here. I expect there will be unique properties across LoRa boards of a given kind, and hope that the architecture has enough flexibility to provide support. Where the architecture falls short, it will be enhanced.

Also, if you are interested, there is a group chat on LoRaWAN/LoRa for Rust, which often touches on lora-phy and LoRaWAN 1.0.4:

https://matrix.to/#/#public-lora-wan-rs:matrix.org

[ceekdee]

Please address an updated PR to lora-phy v2.0.0.

Update on 2023/8/26:

It's fine to create an updated PR against the v1.x branch instead. The version 1 release will be maintained for a while.