RYLR998: Probleme mit dem CRFOP-Kommando

[Heinrichs]

In meinem LoRa-Skript wird zur Initialisierung des LoRa-Moduls eine Funktion angegeben, die etwas gekürzt so aussieht:

Code: Alles auswählen

def lora_init(uart):    
    # Prüfe nach, ob LoRa-Modul antwortet...
    lora_address = '???'
    send_command(uart, 'AT')
    r = read_response(uart)
    print(r)
    if r == b'+OK\r\n': # Wenn r=OK, dann...
        # LoRa-Adresse ermitteln und anzeigen    
        send_command(uart, 'AT+ADDRESS?')
        lora_address = read_response(uart) # Rückgabewert ist vom Typ Bytes
        lora_address = str(lora_address, 'UTF-8') # umwandeln in Typ String
        lora_address = lora_address[9:]
        print('Eigene LORA-Adresse:', lora_address)
        print()
	
	send_command(uart, 'AT+CRFOP=14') # !!!
	print(read_response(uart)) # !!!

	send_command(uart, 'AT+BAND=868500000') # !!!
	print(read_response(uart)) # !!!
	
    return lora_address

Die mit !!! markierten Zeilen hatte ich bei der Endredaktion eingefügt für den Fall, dass die aktuelle Sendeleistung und die aktuelle Frequenz des LoRa-Moduls nicht mehr mit den im Kapitel 1 eingestellten Werten übereinstimmen sollten.

Ich hatte damals nicht mehr überprüft, ob alle Programme, die in den weiteren Kapiteln damit arbeiten, auch tadellos funktionieren. Nun habe ich feststellen müssen, dass es tatsächlich Probleme durch die Einstellung der Sendeleistung geben kann. Dieses Problem tritt auf, wenn nach der Initialisierung in einer Schleife per LoRa übermittelte Daten gelesen (und ausgegeben) werden sollen, etwa durch das folgende Hauptprogramm:

Code: Alles auswählen

# Importe
from time import sleep     
from machine import UART

# UART instanziieren
uart1 = UART(1, baudrate = 57600, tx = 12, rx = 13) 

lora_address = lora_init(uart1)
print('adr:', lora_address)

while True:
    print(read_response(uart1))

In diesem Fall werden nach dem Start des Programms die LoRa-Adresse des Empfänger-Moduls und NUR die erste der (von einem anderen LoRa-Modul) gesendeten Nachrichten angezeigt. Entfernt man das CRFOP-Kommando aus der lora_init-Funktion, läuft die Schleife tadellos. (Nebenbei bemerkt: Beim BAND-Kommando tritt ein solches Problem nicht auf.)

Untersuchungen mit einem Digital Analyzer zeigen, dass (mit dem CRFOP-Kommando) tatsächlich beim LoRa-Modul nach der ersten Nachricht keine TxD-Signale mehr vorliegen. Das Problem kann also nicht am Mikrocontroller liegen; das wurde auch durch Versuche bestätigt, bei denen der TTGO durch einen FTDI-Baustein (und HTerm) ersetzt wurde.

Ich vermutete nun, dass das CRFOP-Kommando den LoRa-Baustein so blockiert, dass er nur noch die erste empfangene Botschaft verarbeitet. Um diese Blockade zu beseitigen, fügte ich in der Schleife nach jedem print(read_response(uart1)) ein Reset-Kommando ein:

Code: Alles auswählen

    send_command(uart1, 'AT+RESET')
    print(read_response(uart1))
    print(read_response(uart1))

Durch die beiden letzten Zeilen werden die Quittungen b'+RESET\r\n' und b'+READY\r\n' vom LoRa-Modul aus dem Read-Puffer des Mikrocontrollers gelesen und ausgegeben. (Die Quittungen müssen nicht unbedingt auf dem Terminal ausgegeben werden.) Tatsächlich läuft die Schleife mit diesem Zusatz jetzt korrekt durch. Allerdings ist es nicht schön, wenn nach jeder empfangenen Nachricht ein Reset durchgeführt werden muss.

Das ist aber auch gar nicht nötig. Tatsächlich reicht es aus, wenn NACH dem CRFOP-Kommando direkt ein Reset durchgeführt wird. Dann funktioniert die Schleife ebenso!


In der aktuellen Version des Skripts und auch bei den zugehörigen Materialien habe ich die Einstellungen für CRFOP und BAND aus der Funktion lora_init (auch bei lora.py) entfernt! Wer mag, kann sie selbst einfügen; dabei bietet es sich auch an, die Einstellungen nur dann vornehmen zu lassen, wenn sie nicht "geeignet" sind.