lora-phy
lora-phy copied to clipboard
embassy-rs
Considering Serial Modules
Hi:
Have you ever considered de possibility to including support for serial LoRa devices such as E32-433T20DT. Y do understand there is already a crate for that. But to be honest i does not play nice with embassy, has full fledged async support and the implementation is missing many features I'll like it to have. If you wish I could contribute. I do understand that this is something out of the scope of what you are achieving right now with the SPI interfaces.
Still any interest ?
Wonderful idea!
Two initial points of focus:
- can we create a serial version of Interface https://github.com/ceekdee/lora/blob/main/src/interface.rs after re-naming the existing Interface to SpiInterface (that is, we would have SerialInterface and SpiInterface);
- can we implement the InterfaceVariant trait for the serial use case: https://github.com/ceekdee/lora/blob/main/src/mod_traits.rs#L7 If so, that should enable the LoRa physical layer API: https://github.com/ceekdee/lora/blob/main/src/lib.rs and sx1276_7_8_9 support: https://github.com/ceekdee/lora/tree/main/src/sx1276_7_8_9
Can you describe the LoRa physical layer features you need to satisfy your use case? I want to make sure the LoRa physical layer API is meeting the necessary range of needs to be useful.
Finally, if you are on the Embassy matrix/element chat, I can invite you to another LoRa/LoRaWAN chat if you’d like to contribute there.
Hi nice to have cached your interest. Here are my thought on your suggestions. Sorry for the late response I do this during my free time:
can we create a serial version of Interface: I'm cool with this as far as this concrete time implements a trait similar to InterfaceVariant just that some of the stuff over serial would be redundant.
can we implement the InterfaceVariant trait for the serial use case: Sure totally agree only tring to make sense on how to structure some generics with some PhantomData that allows the interface when is SERIAL and when is SPI
Usually this kind of modules are autonomous, which means the provider abstracts away many nuisances that you have to deal with SPI devices. Maybe they could be too high level compared to the others. The parameters at least for this E32-433T20DT unit are:
- Transmission Channel (From 410MHz up to 441Mhz)
- Address (from 0x00 to 0xFF) Addressing allows on the same transmission channel differentiate messages to different units. This as an internal mechanism of the unit
- Fixed or Transparent Transmission: Enable or disable de hardware decoding of the Address above.
- UART baudrate: (eg 115200)
- UART parity (eg: 8N1)
- LoRA Air data rate (bps)
- Wireless wake up time (ms) (Like modern NICs that have wake on LAN)
- IO Drive mode (push pull, or open collector)
- FEC switch
- Transmision Power (dBm)
Right now I'm pretty involved with this module on a project for some field telemetry units.
More details if case you want to dig deeper : https://www.ebyte.com/en/downpdf.aspx?id=660
Finally about the Matrix Chat sure thing, send me the chat room details because I can't find them on the readme. In advance I'm sorry about not being a highly active member, it will take some time to answer the chats, my work is time consuming.
If you join the Embassy chat:
https://matrix.to/#/#embassy-rs:matrix.org
you will then have a matrix.org account and I can then invite you to the LoRa/LoRaWAN chat group. Currently, the LoRa/LoRaWAN group is not public, while the Embassy one is.
If you already have a matrix.org account, let me know the account name and I will invite you. However, there is lots of good information on the Embassy chat.
@andres-hurtado-lopez:
My current thought is that the lora-phy crate does not provide useful benefit for the E32-433T20DT; however, if you see a possibility, please add a comment. Otherwise, consider closing the issue.
In any case, thank you for bringing this LoRa board to my attention. It helps me get a better handle on the range of LoRa systems in existence.