matthias-bs / lorae22 Goto Github PK

If this repo is still under active development, I'd like to contribute some changes I made to the code to get it going on a SB-Components Pico LoRa Expansion board under the control of a Pico µC.

1. The machine.UART class for the RP2040 port seems to lack an init method at the time of writing, you have to hand over all the parameters to the constructor already. No big deal

2. The canonical UART to use on the Pico would have id=0 , but the lib only supports "1" or "2" ? Why not support, say "U0" thru "U9"

I think I found some other bugs that are not related to the Pico and I would open separate issues/pull requests for them if anyone is interested, otherwise I'll just put them in my fork.

Apart from bugs I'd also suggest some new features, e.g. configurable TX-power. Picking the max power supported by the module by model designation might not work well in regions with restrictive regulations (e.g. tx power <= 25mW in most of Europe for the 868ish MHz band)...but again, that's another issue.

(THX for this great work btw, very useful indeed)

Hi,

the error:
pi@RPiZero:~/loraE22/examples $ python testRecvE22_P2P.py
Traceback (most recent call last):
File "/home/pi/loraE22/examples/testRecvE22_P2P.py", line 12, in
from loraE22 import ebyteE22
File "/home/pi/loraE22/examples/loraE22.py", line 114, in
from machine import Pin, UART
File "/home/pi/.local/lib/python3.9/site-packages/machine/init.py", line 1, in
from .timer import *
File "/home/pi/.local/lib/python3.9/site-packages/machine/timer.py", line 1, in
import ffilib
File "/home/pi/.local/lib/python3.9/site-packages/ffilib.py", line 2, in
import ffi
ModuleNotFoundError: No module named 'ffi'

environment:
pi@RPiZero:~/loraE22/examples $ hostnamectl
Static hostname: RPiZero
Icon name: computer
Machine ID: aad00e19021a4953b77b7adbc5d1f0e9
Boot ID: a3145e236d19460fa9ee5833c60034b4
Operating System: Raspbian GNU/Linux 11 (bullseye)
Kernel: Linux 6.1.21+
Architecture: arm

Thanks for making this library.

upps...my recent changes introduced a stupid typo ... see pull request

Sorry about that

I'm a bit puzzled by the signature and logic behind the recvMessage method:

It has mandatory arguments from_address and from_channel, but those are just compared to the configured address and channel and depending on the result, the E22 is either switched to fixed or transparent mode (if mode changed). However, if your E22 was set to channel X,in the current code, it doesn't work to use a channel other than X in the recvMessage method anyway because the method does NOT try to change the channel, even if it is different from the configured value. So calling e22.recvMessage(some_address,X+1) will actually still listen for messages on the initially configured channel X, not X+1.

So I wonder what was the intended use case in the first place. Is it a bug that the channel switching was left out?

But the from_address parameter is problematic as well: Contrary to the comment for this method, the from_address cannot actually restrict (by numerical address) who can sent messages to the E22 (other than enabling transparent mode and implicitly restricting sender_address==target_address, unless message was sent as broadcast). In fixed mode, it will receive messages from all stations on the same channel that sent fixed mode messages with the target address matching the address of the receiving E22. As I understand the specs of the E22, it is not possible to filter on, or even extract afterwards, the address of the sending station.

So in summary I think the signature and comment of this method is misleading and the the described functionality is just not possible to achieve. So one should probably change the signature altogether.

Would it make more sense perhaps to have a recvMessage(self) method that just checks for available messages in the buffer of the E22 and a separate method setChannel(self,channel) (there is already a "public" method to set the transmission mode).

In that case the signature of the sendMessage method could stay the same, perhaps changing the logic a bit to just ignore channel and address when called in transparent mode, so no longer trying to switch between modes based on comparison of target address and channel with configured values. to_address and to_channel could then also be optional (not needed in transparent mode).

Hello, this is not a bug in library itself, just a warning and maybe suggestion for enhancement (adding the check). The new V2.1 modules (PCB versions 10498-V1.1 and 10497-V1.0) delivered in December 2022 do not correctly set up speeds 0.3k and 1k2 and silently ignore the setting (they probably stay at the 2k4 speed). It seems the SX127x has been replaced by LLCC68 inside of them, which does not support spreading factors needed by these modes.

They can be identified by querying register 0x82 (C1 82 01), which returns 0x40 instead of 0x10 or 0x11 seen in previous versions

Older modules set to these speeds cannot communicate with the V2.1 ones on these speeds and vice versa.