LoRa constructor does not set power_mode

[campbellsinclair]

• System configuration:
  • Pycom board: LoPy1.0r (with deep sleep shield DS v1.0)
  • Firmware version: (sysname='LoPy', nodename='LoPy', release='1.17.5.b6', version='v1.8.6-849-56d00234 on 2018-05-18', machine='LoPy with ESP32', lorawan='1.0.2')
  • 5V power supply
  • LoRa antenna connected.
  • Use a USB to UART adaptor to interface with the LoPy.
  • pycom.heartbeat_on_boot(False)
  • main.py is:

print('Hello')

• Exact steps to cause this issue:
  • Reset the LoPy using the hardware push-button.
  • Connect to the LoPy using UART and Visual Studio Code
  • Invoke the following commands using the micropython interpreter:

from network import LoRa

lora = LoRa(mode=LoRa.LORA,
            region=LoRa.AU915,
            frequency=925500000,
            tx_power=5,
            bandwidth=LoRa.BW_500KHZ,
            sf=7,
            preamble=8,
            coding_rate=LoRa.CODING_4_5,
            tx_iq=False,
            rx_iq=False,
            public=False,
            power_mode=LoRa.SLEEP,
            )

• • With a multimeter connected in series with the 5V power supply, observe that the current is approximately 103 mA.
  • Invoke the following command:

lora.power_mode(LoRa.SLEEP)

• • Observe that the current is approximately 93 mA.

[campbellsinclair]

My guess is that during initialisation for the LoRa class, power_mode is set but then another command is called which changes power_mode.

[campbellsinclair]

I've found a similar issue. This issue is for the command lora.power_mode(LoRa.TX_ONLY). Note that this is not initialisation.

When the power_mode is TX_ONLY, I expect the radio to go to sleep when it is not transmitting. This is true after executing that command. But once you send something, the power mode appears to be LoRa.ALWAYS_ON.

This time I turned off WiFi to get more stable power readings:

from network import WLAN

wlan = WLAN(mode=WLAN.STA)
wlan.deinit()

• With the LoRa radio power_mode set to SLEEP, I measure 36.2 mA draw on a 5V power supply.
• With power_mode set to ALWAYS_ON, I measure 44.8 mA.
• With power_mode set to TX_ONLY, I measure 36.2 mA after executing the command (the same as sleep mode, as expected). But after sending some data I measure 44.8 mA (the same as ALWAYS_ON mode, which is unexpected).
• FYI, the current consumption while data is being transmitted is 64.0 mA.

[campbellsinclair]

Another issue: with bandwidth=BW_125KHZ and sf=12, it appears that the radio does not successfully send any data (because my other LoPy does not receive the data -- assumption: the error is with the transmitting LoPy).

If I continuously transmit data, the current is 60 mA for approximately 7 seconds. It then drops to 43 mA (which is the same as power_mode=ALWAYS_ON), even while attempting to transmit data.

[robert-hh]

Cannot confirm. I have sent & received data at SF12BW125 with two xxPy devices.

[campbellsinclair]

@robert-hh Try setting the coding rate to CODING_4_8 and send data which is 156 bytes or greater. It will send the first time, but if I send again it doesn't work.

Note that the LoPy v1 uses the SX1272 instead of the SX1276.

[robert-hh]

There is a maximum airtime, depending on the transmission parameters. At SF12BW125 (DR=0), this is 51 (or 59) bytes. Setting the coding rate to 4/8 will reduce that further. So what were you test parameters?

[nevercast]

Where is the maximum airtime defined, @robert-hh ? Do we have a millisecond hard limit for that?

Edit: As a developer using LoRa on the LoPy I would not want to miss information about hard limits with a high Spread Factor, and this information could easily be buried in this issue, the name of which is entirely unrelated. @campbellsinclair Do you mind creating another issue separate from this one regarding your SF12BW125-C48 with >155 bytes problem? It would serve people like myself better when I search for issues.

[nevercast]

The state machine certainly needs checking. The modem does not go to sleep when power_mode is set on the LoRa constructor. Can I help in any way? Some code to reproduce this issue?