micropython/lora, modem.set_irq_callback()

[davefes]

In a previous distro I was using a callback, so attempted to migrate what I was familiar with to micropython/lora.

The documentation is excellent, but I am struggling to get this method to work.

In my main loop:

data = [0, 0]

print('Initialising modem ...')
modem = get_modem()

print("Main loop started")
receiver = Receiver(modem)

def main():
    global data

  # install the callback
    modem.set_irq_callback(my_rx_irq)

  # loop waiting for a received message/
    while(True):
        print (f'Received msg in main: {data[0]}\n')
        sleep(.1)

and my callback:

def my_rx_irq():
    global receiver
    global data

    while True:
        sender_id, data = receiver.recv(wait=True)

        if data:
            break

    data =  data.decode('utf-8')
    data = data.split(',')
    print (f'Received msg in IRQ: {data[0]}\n')
    sleep(.1)

I come up against the following error when the transmitter sends a message:

Initializing...
Main loop started
Modem initialized and started receive...
waiting for a received signal
waiting for a received signal
Traceback (most recent call last):
  File "lora/modem.py", line 247, in _radio_isr
  File "main.py", line 52, in my_rx_irq
AttributeError: 'Pin' object has no attribute 'recv'
waiting for a received signal
waiting for a received signal

line 52 sender_id, data = receiver.recv(wait=True) and line 247 I don't know what it is trying to tell me. Something didn't execute properly in _radio_isr()?

Do I need to call:

Application code is expected to call poll_send() or
poll_recv() as applicable in order to confirm the modem state.

... before proceeding?

I suspect there are other parameters I have to pass into my_rx_irq(), but what?

Thanks.

[jimmo]

@davefes the callback that you pass to set_irq_callback should take no arguments.

You may be getting confused by how AsyncModem uses this, but remember that in this case, with self.set_irq_callback(self._callback), self._callback is a bound method, hence the first argument will be self.

[jimmo]

So, my_rx_irq() is a bound method, correct?

No, that's a function invocation. Whenever you reference a method as an attribute on a class instance, that creates a bound method.

class X:
  def foo(self):
    ...

x = X()
y = x.foo  # this is a bound method
y()   # note the self argument is implicit

[jimmo]

Just just mpremote mip installed it 2 days ago.

Hrmm, looks like something wrong with the package server, I'll investigate.

[jimmo]

In the meantime, in your version, you have an extra pin argument that you can just ignore.

[jimmo]

@davefes The package server is fixed. If you mip install you should get the latest now.

[davefes]

Didn't want to play around i class Receiver as that is the original Reliable_delivery code example.

Using your first suggestion, ie `lambda' gives me:

waiting for a received signal
Traceback (most recent call last):
  File "lora/modem.py", line 247, in _radio_isr
TypeError: function takes 1 positional arguments but 2 were given

[davefes]

Thanks, will do that tomorrow and get back.

[davefes]

Actually, just did it and wahoo. Thanks heaps.

[davefes]

Using the callback at the top of the post. I can see that I get the correct message in the IRQ but the message is not reflected consistently in the main loop. I expect that the main loop should continue from where ever it was interrupted. Or is there something else I need to do?

Edit:

Using the reliable_delivery sender example at one end and the above script on the receiving end I get this sequence:

waiting for an IRQ in the main loop
Received msg in IRQ: Hello

Received msg in IRQ: Hello

Received msg in main: Hello

Received msg in IRQ: Hello

Received msg in IRQ: Hello

I expected to see waiting for an IRQ in the main loop for each Received msg in IRQ: Hello I have tweaked numerous timings in the application and the sequence does not change. I thought that it might be related to the number or retries, which was set to 4, but changing that doesn't affect the outcome.

The data is being past-around using a global variable.

Any suggestions?

[davefes]

Removing all the sleeps() seems to work better. Found some suggestions that using sleep(), maybe only on the ESP32, is not a good idea. Maybe, using a timer to flash an LED is more appropriate.

Current code:

from receiver import Receiver, get_modem
from sender import Sender, get_sensor_data
import machine
from machine import SPI, Pin
from lora_rd_settings import lora_cfg
from time import sleep, sleep_ms
import gc


gc.collect()

# during development on an ESP32
if machine.reset_cause() == machine.SOFT_RESET:
    print('you got a SOFT_RESET, so do a umachine.reset()')
    sleep_ms(10)
    machine.reset()

reset_RFM96W = Pin(4, Pin.OUT)
led = Pin(33, Pin.OUT)
led.off()


data = [0, 0]  # ever how many entries it has
sender_id = 0

print('you have 2 seconds to do a CTRL-C')
sleep(2)

# If the caller supplies a reset pin argument, reset the radio
reset_RFM96W.off()
sleep_ms(50)
reset_RFM96W.on()
sleep_ms(50)


print('Initialising modem ...')
modem = get_modem()

print("Main loop started")
receiver = Receiver(modem)


def my_rx_irq():
    global receiver
    global data

    sender_id, data = receiver.recv(wait=True)
 

def main():
    global modem
    global data


  # install the callback
    modem.set_irq_callback(lambda: my_rx_irq())

    while True:
        print(f'Received msg in main: {data}\n')
        print('waiting for an IRQ in the main loop')

Gives the following output (before the first IRQ the messages are happening at a great-rate)

waiting for an IRQ in the main loop
Received msg in main: [0, 0]

waiting for an IRQ in the main loop
Received msg in main: [0, 0]

waiting for an IRQ in the main loop
Received msg in main: [0, 0]

waiting for an IRQ in the main loop
Received msg in main: [0, 0]

waiting for an IRQ in the main loop
New device id 0x1fa
Received msg in main: bytearray(b'Hello')

waiting for an IRQ in the main loop
Received msg in main: bytearray(b'Hello')

waiting for an IRQ in the main loop
Received msg in main: bytearray(b'Hello')

Still I expected that between the 5 second sends that there would be 1000s of Waiting for an IRQ in the main loop messages.

Also, the only way to stop the program is by using a power-on reset.