-
Notifications
You must be signed in to change notification settings - Fork 54
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
receiving with interrupt callback not working #16
Comments
I think I have found the reason - it's in the method When the IRQ gets triggered, it's not necessarily that the full message has been received, hence It should be at least set a timeout loop to wait until the full message has come in and I don't understand why in the original code it will in some cases set the module back to single RX mode - if the user has decided to use the module in countinuous mode, it should stick to that mode. My modified asyncio version as following (need to use Peter Hinch's IRQ_EVENT primitives to handle the IRQ):
|
Hi, [Edit] From what I found behavior will be dependent on your board and on the configuration of the register Regdiomapping. This register maps which information is made available on which pin of the Lora transceiver. |
Would you pls be more specific? Did you mean the timing of IRQ being triggered versus the RX status? Regarding the Regdiomapping configuration, I think it's set in the method
According to the datasheet, writing |
Sorry, you are totally right. I read the datasheet to quickly and mixed up the packet mode (which can involves more complex cases to handle due to the FIFO being only 64B) with the LORA mode. What value do you have when you read the irq flags register ? |
It happened every time - I never managed to receive messages until I modified the code as shown above. The payload was 15 bytes long. I didn't print out the irq flags value, so I have no idea what it was. But according to the info you posted, the interrupt triggers when the payload is readily available (RxDone), no more waiting is needed. |
I read the datasheet again - the interrupt at DIO0 pin can occur in both Rx Single mode & Rx Continuous mode. In Rx Single mode, a Rx Timeout period should be set first, the LoRa module will wait for the preamble for that Rx Timeout period of time before triggers RxTimeout interruption and goes to standby mode. If the payload comes in before timeout, RxDone interruption will occur. But in the original code, I didn't see anywhere that Rx Timeout period can be set (RegSymbTimeout). |
There's a bit difference in the code here, in the comment it says the IRQ Flag should be 0x50, rather than 0x40 in this repo. |
So I printed the value of IRQ flag, it's 80 which was 0x50, or 0b01010000, which meant RxDone & ValidHeader per datasheet on page 111. The working code as following:
|
Strange, it worked for me on a TTGO Lora board V1. I agree with you regarding the rx single part in the code, I do not understand why it is here... 0x50 seems better but 0x40 should works fine too, worst case you get rubish data. I spent a lot of time strugling with the IQ config as the datasheed is not very clear regarding this part. (LORAWan is using reverse IQ so that gateway can not see packets from other gateways; same thing for nodes which can not see packet from each other). Would you share your asyncio version ? (I am very new to asyncio and I would be interested to learn it) |
0x40 only worked for me as shown in my 2nd post from the top. I only rewrote the interrupt part with asyncio in order to have it working with my other asyncio code base, as the interrupt may cause a racing condition. Below is the full driver for your reference (letter case also changed to comply with PEP)
|
@jbfuzier Is the invert IQ documented somewhere? I'd like to learn about it in case someday I will be using LoRaWan as well. Thanks. |
Thanks. Unfortunately I have not found much information regarding this invert IQ mecanism. Ultimately, the goal is to reduce useless load on the node & gateway by making sure nodes don't see messages from each other and gateway does not see messages from each other (which would be useless). To do that Gateways send messages with IQ inverted (which physically changes the phase of the signal), nodes must be expected IQ to be inverted in order to receive the messages. The datasheet is very misleading (not to say wrong) regarding the INVERTIQ register For example if you want to only have nodes that can all talk to each other (= do not invertIQ), you need to set the register to 0x01, otherwise nodes can not talk to each other. If you want to have a gateway/nodes scenario, register value need to be 0x41 on gateway and 0x00 on the nodes (or the other way around). To add lorawan I think the best course of action is to port a working arduino lib or a python lib to micropython. I am not using Lorawan (too complex for a private network IMHO), I just have a use case with several nodes and one receiver; I added on top a simple layer which do the encryption, integrity check and ack/retry. The issue is that encryption adds a lot of overhead to the payload 32bytes for AES128. |
Thanks for the explaination. My use case is similar to yours - multiple nodes & one receiver, TTN not involved. What hardware (LoRa module & microcontroller) do you use for the receiver? Same as the nodes? |
Hi @dukeduck1984 @jbfuzier I am using a customized board and I also faced the same issue. |
You need to change the So it should look like:
|
Hum.. ok, thank you @dukeduck1984 |
@dukeduck1984 I used a LA to monitor the DI0 pin and I figured out it is not changing level and I have another node continuously sending data. My |
@dukeduck1984 my issue was solved. |
@dukeduck1984 Thanks is advance. |
According to note [1] at the bottom of https://lora-developers.semtech.com/documentation/tech-papers-and-guides/channel-activity-detection-ensuring-your-lora-packets-are-sent/how-to-ensure-your-lora-packets-are-sent-properly/ the sx1276 should be able to receive lora packets without host mcu involvement. I'm trying use dio0 to wake an esp32 from deepsleep when the sx1276 receives a packet. It's working but when the esp32 wakes up I can't recover the packet with lora.read_payload() |
Would you tell me how you configured DIO0 to wake-up the ESP32? What happens after the ESP32 wakes-up? Can you tell where things stall? |
Let me put what I did in a proper program that you can easily run instead of the interactive nightmare I was developing with. That way I can also send you a copy of the while loop code benchmark code I was using previously with the much reduced sx1276 current. Might take me a day or so to put some lipstick on the pig. I'll also put it on https://github.com/orgs/micropython/discussions/11515 so our lora chats are all in one place. |
Good. I will take me some time to swap-over to his code on my test link. |
Hi,
I have set the
dio_0
pin number inconfig.py
and changed the code inexamples/LoRaReceiver.py
as following:But it didn't work - couldn't receive any data. It only worked with
while True
loop as shown in the original example.Did I miss something? Pls help!
It's an AI-Thinker Ra-02 LoRa module with ESP32. The MicroPython firmware is V1.13 stable.
I used the sx127x driver in the master branch, and the readme title is uPyLora.
The text was updated successfully, but these errors were encountered: