micropython/lora, simple_rxtx.py how to tell modem_send and modem_receive work

[davefes]

Using a Hope Radio RFM96W on a STM32F411 BlackPill.

I modified the simple_rxtx.py example to give me the return value from modem_send() ... in order to try and fix a non-communications problem.

while True:
    print("Sending...")
    retval = modem.send(f"Hello world from MicroPython {counter}".encode())
    print (f'return value from modem.send = {retval}')

and I get:

Sending...
return value from modem.send = 9533976

the value changes each loop. Looking at sync_modem.py it appears that this value is the result of:
tx = self.poll_send()
Is that an expected return value? And does that tell me if the transmitter is working?

edit: that value changes by about 7000 each loop so it looks like the return value is maybe the time between loops.
edit: Also tried with reliable_delivery and get on the receiver:
Initializing... Main loop started Modem initialized and started receive...
and on the sender:
Sender initialized with ID 0x1fa New output_power 0/15 (delta 0) Sending 25 bytes etc
but no link. Will try on a pair of ESP32s.

Any suggestions appreciated.

[projectgus]

Hi @davefes,

Glad to hear you're working with lora driver, sorry to hear you've run into some issues. I haven't heard of anyone using the HopeRF modules with our driver yet, it'll be great if you can get them working!

Is that an expected return value?

The return value of modem.send() is the time.ticks_ms() timestamp of the time that the send completed, it's intended for protocols that have specific timing requirements.

And does that tell me if the transmitter is working?

This tells you that the modem thought it sent a packet. It doesn't mean the transmitter is necessarily working - there might be antenna output selections or RF switches that have to be set correctly, or the antenna might not be suitable for the transmit frequency, etc, etc.

One place to start, the SX1276 has three possible transmit power amplifiers, RFO_LF, RFO_HF and PA_BOOST and they are connected to different antenna pins. The default setting is RFO_LF or RFO_HF depending on frequency. If your antenna is connected to PA_BOOST, you need to set the "tx_ant": "PA_BOOST" in the lora_cfg dict.

I'm also not very familiar with HopeRF products but from what I understand the RFM96W is only unofficially SX1276 compatible, not guaranteed to work the same (although it uses SemTech silicon). I'm sure it can be made to work with the driver, but there might be some other RFM96W-specific setting that is not needed on the SemTech-branded chips.

Please let us know how you get on! If you're still stuck, please share the lora_cfg value and modem constructor you're using with the example.

[davefes]

PA_BOOST in lora_cfg did the trick. Great! I have some E77-400M22S EByte modules coming and would like to get micropython/lora working on them.

Thanks heaps.

[DuaneKaufman]

@davefes : I noted you said you have some E77-400M22S EByte modules coming. I am interested in the E77-900 parts, and I was wondering how hard it is to get Micropython into these devices? The hardware seems compelling......

[davefes]

@DuaneKaufman : I am stuck on getting some WeACT 8MB STM32F411 boards running. After that is sorted I will take a deep-breath then tackle these E77-400M22S. Yes, for a PV-powered sensor they look really attractive.

[davefes]

Thank you for getting back. The RFM96W is on the 433MHz band. The two units are beside each other with 50 Ohm dummy loads on the one antenna port. Actually, the chip is called RF96. The RFM96W-V2.0.pdf shows only one antenna connection. The datasheet also has the name SX1272D5_v0'8.book on it. The datasheet says that for this frequency RFO_LF or PA_LF is used. The module is sold for specific bands.

I am setting TX power to 0dBm in case there are antenna switching issues. I have been using Wei's LoRa implementation at:
https://github.com/Wei1234c/SX127x_driver_for_MicroPython_on_ESP8266/tree/master
but would like to use the reliable_delivery feature in your code. I have been work/hacking along with @rkompass on:
https://github.com/martynwheeler/u-lora
and the link works on that as well.

The third PA, connected to the PA_BOOST pin and can deliver up to +20 dBm via a dedicated matching network.

I wonder as there is no PA_BOOST pin showed as a connection on the module that the high-power PA is connected to the ant pin.

[robert-hh]

Retired and no spectrum analyser on my work-bench :(

@davefes That sounds familiar. I used a SDR receiver for Lora, like one of these: https://www.sdrplay.com/
They work pretty well, and for Windows there is even a Spectrum Analyzer Software, which mimics a spectrum analyzer. Only the range does not cover WiFi. There are other SDRs which go up to 6Ghz, but at lower sensitivity. see https://greatscottgadgets.com/hackrf/one/

[davefes]

Will investigate. I recently bought a NS1201SA as I missed my VNA, it is real handy being able to see how well antennas are tuned or not.

Which LoRa S/W implementation have you used?

[robert-hh]

I used the Pycom devices with LoRa support. Unfortunately, Pycom closed, but I have still some devices here. As TTN gateway I have a IC880a + RPi, which works fine. With coverage tests using a LoPy and this Gateway I got like 2500m receive distance at a reported RSSI of -124 dB (at SF12). The signals of this Lopy were however received by Gateways more than 8km apart, which had better antennas placed high above the ground. The RSSI values were always questionable, since by software on can set an offset. The SDR shows an noise floor of about -115dB at my desk, which seems reasonable.
I had as well set up a LoPy device as single channel TTN gateway, and that reported RSSI values down to -138dB. But being not calibrated, these are just numbers.

[davefes]

Thank you for some background comments. I am mainly interested in stand-alone links used for water tank monitoring and control links. For control links micropython/lora using reliable_delivery seems the best solution I have seen so far.

[DuaneKaufman]

Has anyone used a Nucleo STM32WL with a dedicated gateway (rather than P2P to a single-channel device)? I have a Dragino 8 channel gateway, and have successfully connected PyCom, ESP32Lora, and others and always been able to at least see packets come into the gateway through the logs, but with the Nucleo STM32WL, I do not get any errors, but I can't see anything at the gateway either.
I do not know how picky the gateway is regarding headers and CRCs, so maybe there is something about the Nucleo's packets that it refuses to log, or, my Nucleo isn't putting out anything.
Just wondering if anybody else has sent packets with this hardware and Micropython and hit a gateway.
I suppose I could use STMicro's CubeIDE and one of their examples, but I just detest that environment...

Thanks!
Duane

[projectgus]

@DuaneKaufman Do you mean a gateway for LoRa-WAN, or plain LoRa packets?

Can you share the code you're using to initialise the modem in MicroPython?

[DuaneKaufman]

Sure, I am using the simple_rxtx.py from the examples directory, with a filled-in get_modem function:

# MicroPython lora simple_rxtx example - synchronous API version
# MIT license; Copyright (c) 2023 Angus Gratton
import time
from machine import Pin, SPI
from lora import WL55SubGhzModem

# Initialize LORA
LORA_FREQ_KHZ = 903700
def get_modem():
    global LORA_FREQ_KHZ
    # The LoRa configuration will depend on your board and location, see
    # below under "Modem Configuration" for some possible examples.
    lora_cfg = { 'freq_khz'		:	LORA_FREQ_KHZ,
                #'tx_ant'		:	"LOW",   	# Could be "PA_BOOST" for high power
                #'output_power'	:	0,		# -17 to +14 (tx_ant LOW) -9 to +22 (tx_ant "PA_BOOST")
                 }
    return WL55SubGhzModem(lora_cfg)



def main():
    print("Initializing...")
    modem = get_modem()

    counter = 0
    while True:
        print("Sending...")
        modem.send(f"Hello world from MicroPython #{counter}".encode())

        print("Receiving...")
        rx = modem.recv(timeout_ms=5000)
        if rx:
            print(f"Received: {rx!r}")
        else:
            print("Timeout!")
        time.sleep(2)
        counter += 1


if __name__ == "__main__":
    main()

``
My gateway is one of these: https://www.dragino.com/products/lora-lorawan-gateway/item/171-lig16.html

and I have it configured for US915 United States 915Mhz (902928)
Frequency Sub Band 1: US915 , FSB1 (902.3903.7)

which listens on these channels:
FreqINFO:
Gateway Channels frequency

chan_multSF_0
Lora MAC, 125kHz, all SF, 902.3 MHz

chan_multSF_1
Lora MAC, 125kHz, all SF, 902.5 MHz

chan_multSF_2
Lora MAC, 125kHz, all SF, 902.7 MHz

chan_multSF_3
Lora MAC, 125kHz, all SF, 902.9 MHz

chan_multSF_4
Lora MAC, 125kHz, all SF, 903.1 MHz

chan_multSF_5
Lora MAC, 125kHz, all SF, 903.3 MHz

chan_multSF_6
Lora MAC, 125kHz, all SF, 903.5 MHz

chan_multSF_7
Lora MAC, 125kHz, all SF, 903.7 MHz

chan_Lora_std
Lora MAC, 500kHz, SF8, 903.0 MHz

chan_FSK

I really appreciate your help!

Sincerely,
Duane

[DuaneKaufman]

Oh, and @projectgus the gateway can do LoraWAN, and just plain Lora packets. In either case, it logs what it sees.

[projectgus]

Thanks @DuaneKaufman. I can't explain why this doesn't work, but I have a LoRa concentrator here that I've meaning to hook up. Will try and make some time to reproduce.

[DuaneKaufman]

Dear Angus, I appreciate your help - and I have more data. First, I have a couple of TTGO Lora32 boards that I put 1.21 MicroPython on, used mip to install lora-sync and lora-sx127x, and with a little fiddling (for version 1.0 of this board, one needs to pull pin 16 high to enable the OLED), got them to see one another using simple_rxtx.py HOWEVER, my Lora gateway still doesn't log this traffic, so it probably filters and doesn't log what it perceives a non-uplink traffic. I may try to form uplink-formatted messages to see if this is true. In any event, when I try simple_rxtx.py (on the same frequency) with the STM32WL and Micropython, I do not see anything on my TTGO Lora32 units, so for whatever reason, it doesn't seem to be transmitting anything they recognize (even though they can communicate with each other. Makes me believe the Micropython basic lora stuff is OK, but the STM32WL doesn't work. One question, I didn't mip lora-sync onto the STM32WL - do I need to? Early times, but I thought I would report. Duane

…

----- On Nov 28, 2023, at 4:43 PM, Angus Gratton ***@***.***> wrote:

Thanks [ https://github.com/DuaneKaufman | @DuaneKaufman ] . I can't explain why this doesn't work, but I have a LoRa concentrator here that I've meaning to hook up. Will try and make some time to reproduce. — Reply to this email directly, [ #12964 (reply in thread) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABK2PQBP5Y55KX6TSUCVRXTYGZSIZAVCNFSM6AAAAAA7JXAJ32VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMOJXHAZTC | unsubscribe ] . You are receiving this because you were mentioned. Message ID: < ***@***.*** >

[davefes]

@DuaneKaufman I saw a comment somewhere:

lora-sync
lora-stm32wl5

BTW, I have the E77-400M22S powered-up and Micropython appears to be loaded, but can not get REPL. I wonder if you have to do something special to get the STM32WL55 to run.

[projectgus]

HOWEVER, my Lora gateway still doesn't log this traffic, so it probably filters and doesn't log what it perceives a non-uplink traffic. I may try to form uplink-formatted messages to see if this is true.

Oh, of course! You may need to set the "syncword" in lora_cfg to match the value used by LoRaWAN:
https://github.com/projectgus/micropython-lib/blob/f816c968e081181f4ead241ab55d589bcda22bee/micropython/lora/README.md#syncword---sync-word

and/or set "invert_iq_tx": True:
https://github.com/projectgus/micropython-lib/blob/f816c968e081181f4ead241ab55d589bcda22bee/micropython/lora/README.md#invert_iq_txinvert_iq_rx---invert-iq

Without either or both of these, the radios may not demodulate the non-LoRaWAN packets correctly.

Makes me believe the Micropython basic lora stuff is OK, but the STM32WL doesn't work.

That is odd, I can't explain that. Will try to reproduce with your code when I have some time (may not be until next year unfortunately.)