The modes are listed in constants.py. It looks like the code is being asked to set a mode not in the MODE list in that file. I’d like to know what that mode is because the two mode changes at the start succeed. Does it happen all the time? Odd it worked ok before. Did you rebuild Buster or just put the working Buster SD back in?
Looking at LoRa.py line 854 I think op_mode_bkup is None. It is a copy of self.mode which is initialised to None although it should have been over-written by the two mode changes SLEEP and FSK_STANDBY. As a quick workaround I suggest you change line 854 in LoRa.py to this.
if op_mode_bkup is not None:
self.set_mode(op_mode_bkup)
If that works I’ll change the repo but I still don’t know why it is happening.
@bnnorman that didnt make any difference. This is the change I made:
# put back the saved parameters
#self.set_mode(op_mode_bkup)
if op_mode_bkup is not None:
self.set_mode(op_mode_bkup)
self.set_register(REG.LORA.PA_CONFIG, pa_config_bkup)
self.set_freq(freq_bkup)
But I still received this error:
pi@unit002:~/dragino-1 $ sudo ./test.py
Mode ← SLEEP
Mode ← FSK_STDBY
Traceback (most recent call last):
File “./test.py”, line 20, in
D = Dragino(“dragino.toml”, logging_level=logLevel)
File “/home/pi/dragino-1/dragino/dragino.py”, line 85, in init
super(Dragino, self).init() # LoRa init
File “/home/pi/dragino-1/dragino/SX127x/LoRa.py”, line 100, in init
self.rx_chain_calibration(calibration_freq)
File “/home/pi/dragino-1/dragino/SX127x/LoRa.py”, line 856, in rx_chain_calibration
self.set_mode(op_mode_bkup)
File “/home/pi/dragino-1/dragino/SX127x/LoRa.py”, line 221, in set_mode
sys.stderr.write(“Mode ← %s\n” % MODE.lookup[mode])
KeyError: 0
pi@unit002:~/dragino-1 $
I trust your indentation was correct (none shown on the paste)
Ok, that tells me that ‘mode’ is not valid, I expected it to be None - so what value is it?
I have modified LoRa.py and added a try-except in set_mode(). It should now print a message telling us what the invalid value of ‘mode’ being requested is and ignore the error (since it’s a request to set an invalid mode). But I don’t know what is causing it since I only saw that error a couple of times a long time ago and can’t debug until it re-appears.
Please download the update from github , try it and let me know what is printed this time. Note, since the error should not now now crash the code it should continue and,hopefully, work.
Yes the indentation was correct. I still get an error:
pi@unit002:~/dragino-1 $ sudo ./test.py
Mode ← SLEEP
Mode ← FSK_STDBY
set_mode KeyError error mode requested was 0
Mode ← SLEEP
Traceback (most recent call last):
File “./test.py”, line 20, in
D = Dragino(“dragino.toml”, logging_level=logLevel)
File “/home/pi/dragino-1/dragino/dragino.py”, line 122, in init
assert self.get_agc_auto_on() == 1
AssertionError
pi@unit002:~/dragino-1 $
The log file shows:2022-05-07 08:27:50,078 - init - 78 - INFO - init starting
2022-05-07 08:27:50,511 - setCacheDefaults - 413 - INFO - Setting default MAC values using user config values
2022-05-07 08:27:50,511 - getFrequencyPlan - 342 - INFO - loading frequency plan
2022-05-07 08:27:50,516 - getFrequencyPlan - 345 - INFO - Frequency Plan is EU_863_870_TTN
2022-05-07 08:27:50,516 - getFrequencyPlan - 354 - INFO - Frequency Plan loaded ok
2022-05-07 08:27:50,516 - setCacheDefaults - 479 - INFO - MAC default settings finished
2022-05-07 08:27:50,516 - init - 104 - DEBUG - Setting self.cache[fCntUp] to 0
2022-05-07 08:27:50,517 - init - 104 - DEBUG - Setting self.cache[fCntDn] to 0
2022-05-07 08:27:50,517 - init - 104 - DEBUG - Setting self.cache[rx1_delay] to 5
2022-05-07 08:27:50,517 - init - 104 - DEBUG - Setting self.cache[rx2_delay] to 1
2022-05-07 08:27:50,517 - init - 104 - DEBUG - Setting self.cache[rx1_DR] to 3
2022-05-07 08:27:50,517 - init - 104 - DEBUG - Setting self.cache[rx2_DR] to 3
2022-05-07 08:27:50,517 - init - 108 - INFO - missing TTN section key rx1_freq_fixed ignored
2022-05-07 08:27:50,517 - init - 108 - INFO - missing TTN section key rx1_frequency ignored
2022-05-07 08:27:50,517 - init - 104 - DEBUG - Setting self.cache[rx2_frequency] to 869.525
2022-05-07 08:27:50,518 - init - 108 - INFO - missing TTN section key duty_cycle ignored
2022-05-07 08:27:50,518 - init - 104 - DEBUG - Setting self.cache[data_rate] to 3
2022-05-07 08:27:50,518 - init - 116 - DEBUG - Setting self.cache[devaddr] to [0, 0, 0, 0]
2022-05-07 08:27:50,518 - init - 116 - DEBUG - Setting self.cache[deveui] to [228, 95, 1, 255, 255, 134, 124, 64]
2022-05-07 08:27:50,518 - init - 119 - INFO - Missing OTAA TTN key nwkskey ignored
2022-05-07 08:27:50,518 - init - 119 - INFO - Missing OTAA TTN key appskey ignored
2022-05-07 08:27:50,518 - init - 116 - DEBUG - Setting self.cache[appeui] to [0, 0, 0, 0, 0, 0, 0, 0]
2022-05-07 08:27:50,519 - init - 116 - DEBUG - Setting self.cache[appkey] to [238, 56, 238, 131, 116, 102, 149, 88, 244, 3, 222, 236, 27, 201, 252, 179]
2022-05-07 08:27:50,519 - loadCache - 524 - INFO - Loading MAC settings
2022-05-07 08:27:50,519 - loadCache - 542 - INFO - cached settings load failed Expecting value: line 1 column 602 (char 601). Saving current defaults
2022-05-07 08:27:50,519 - saveCache - 489 - INFO - Saving MAC settings
2022-05-07 08:27:50,520 - saveCache - 495 - INFO - Saving MAC settings failed Object of type bytearray is not JSON serializable.
2022-05-07 08:27:50,521 - saveCache - 489 - INFO - Saving MAC settings
2022-05-07 08:27:50,522 - saveCache - 495 - INFO - Saving MAC settings failed Object of type bytearray is not JSON serializable.
2022-05-07 08:27:50,522 - init - 141 - INFO - init done
2022-05-07 08:27:50,522 - init - 96 - WARNING - Not enabling GPS (see enableGPS param)
Please please please use the </> tool on the toolbar, not only will it show the indentation but it will also put the long logs in to a scrolling box - please see guidelines
1 Like
Ok so it was trying to set an invalid mode 0 and not None. So now we have to find out why.
I think the code in rx_chain_calibration is trying to set the invalid mode from op_mode_bkup but that should be SLEEP. So could you add the following line after 840 in LoRa.py
sys.stderr.write(f"backups op_mode_bkup {op_mode_bkup} pa_config_bkup {pa_config_bkup} \n")
I have included pa_config_bkup to save time, in case I need the info.
If need be I’ll add a trace output to find out where it is getting clobbered but I must say that if your system worked before then something must have changed to cause this grief…
No still got errors. I am going back to basics and rebuilding the sd card as something is obviously wrong.
My feelings too.
What was the reported value of op_mode_bkup?
I am getting this error after I have installed Buster and GitHub - computenodes/dragino: LoRaWAN implementation in python.
I am installing a previous version of buster to see if this still happens
pi@unit002:~/LoRaWAN $ ./test.py
Mode <- SLEEP
Mode <- FSK_STDBY
Traceback (most recent call last):
File "./test.py", line 19, in <module>
D = Dragino("dragino.ini", logging_level=logLevel)
File "/home/pi/LoRaWAN/dragino/dragino.py", line 56, in __init__
super(Dragino, self).__init__(logging_level < logging.INFO)
File "/home/pi/LoRaWAN/dragino/SX127x/LoRa.py", line 100, in __init__
self.rx_chain_calibration(calibration_freq)
File "/home/pi/LoRaWAN/dragino/SX127x/LoRa.py", line 854, in rx_chain_calibration
self.set_mode(op_mode_bkup)
File "/home/pi/LoRaWAN/dragino/SX127x/LoRa.py", line 221, in set_mode
sys.stderr.write("Mode <- %s\n" % MODE.lookup[mode])
KeyError: 0
pi@unit002:~/LoRaWAN $
I am at a loss. I have reinstalled Buster and installed the software as instructed. However in running the test.py I get the following returned:
pi@unit002:~/dragino-1 $ sudo python3 ./test.py
Mode <- SLEEP
backups op_mode_bkup 0 pa_config_bkup 0
Mode <- FSK_STDBY
set_mode KeyError error mode requested was 0
Mode <- SLEEP
Traceback (most recent call last):
File "./test.py", line 20, in <module>
D = Dragino("dragino.toml", logging_level=logLevel)
File "/home/pi/dragino-1/dragino/dragino.py", line 122, in __init__
assert self.get_agc_auto_on() == 1
AssertionError
pi@unit002:~/dragino-1 $
The change you wanted made to LoRa.py is as follows:
# backup some registers
op_mode_bkup = self.get_mode()
pa_config_bkup = self.get_register(REG.LORA.PA_CONFIG)
freq_bkup = self.get_freq()
sys.stderr.write(f"backups op_mode_bkup {op_mode_bkup} pa_config_bkup {pa_config_bkup} \n")
If you follow the code it starts with dragino.py
**dragino.py**
1 BOARD.setup in board_config.py is called to setup GPIO
2 init in LoRa.py is called using super(Dragino, self).__init__()
**LoRa.py**
3 sets mode to SLEEP (as seen on the terminal)
4 creates a back up of the SX1276 registers
5 calls rx_chain_calibration
5a creates a backup of the current mode (op_mode_bkup) and pa_config and frequency
5b sets mode to FSK_STDBY (as seen on the terminal)
5c does some LO/HI frequency stuff
5c calls set_mode using the op_ mode_bkup
and there it crashes in set_mode() because the value of op_mode_bkup is zero - not a valid value.
op_mode_bkup is obtained from get_mode() which does an SPI xfer of the sx1276’s mode register.
I think the answer to the problem is in get_mode(), I think the SPI transfer has returned zero.
Have you forgotten to enable SPI on the pi?
Look at the readme installation section item 6
That’s awkward.
I have added a check in (my dragino-1 repo) to LoRa.py to check the mode returned from the modem is not zero. If it is the code will now exit with a message and not try to carry on.
One other possibility here is that the chip select pin isn’t driving the NSS pin on the sx1276 (bad connection). This could account for the problem still being there whatever you do.
You could write a simple python test to toggle that pin (GPIO 02). Have you tried re-seating the dragino HAT?
yes I get your new error message.
pi@unit002:~/dragino-1 $ sudo python3 test.py
Mode <- SLEEP
Unable to set modem mode. Have you enabled SPI as per the readme installation section?
pi@unit002:~/dragino-1 $
Yes I have reset the dragino, checked the pins, and checked spi setup and all looks OK.
Writing a python test is beyond me as I am only good at following instructions 
HOW did you check the continuity between the Pi GPIO pins and the Dragino pins?
This should toggle the CS pin High then low with 1 second delay between.
import RPi.GPIO as GPIO
import time
GPIO.setwarnings (False)
GPIO.setmode(GPIO.BCM)
PIN = 2
GPIO.setup(PIN,GPIO.OUT)
while True:
GPIO.output(PIN,True)
time.sleep(1)
GPIO.output(PIN,False)
time.sleep(1)
You should see that changing the level on the NSS pin. If you don’t have a meter you could , if you have them, use an LED in series with a 300 ohm resistor to check for activity.
You could also monitor pin 10 (MOSI), 9 (MISO) and 11 (SCLK).
I only checked the pyshical pin connection by eye. I dont have any tools to monitor the pins but I will have a search and see what I can learn!!
I have also changed my Pi 4 but still no good, I think I will purchase another dragino.
@mauriceatkinson - if you can, check the version of the dragino lora/gps hat. On the board there is often a version / revision number. As v1.0 differs significantly to the V1.4’s
To the extent, you need to physically install connections between pins on V1.0 thru 1.2/1.3 (need to check) but they are pre-done on the V1.4 boards.
Those links are for DIO signals required by LMIC.
I think we have established that he has an SPI problem because the code attempts to set the sx1276 mode but an immediate read back returns zero. In rx_chain_calibration() this causes the code to attempt to set an invalid mode which causes an exception.
However, @mauriceatkinson did say it was previously working on Buster. The problem,apparently, only appeared after trying to get it working on Bullseye. I have it working on Bullseye having switched from Buster several months ago.
@bnnorman I have received the new dragino board and back up and running again on Buster. Thanks for your assistance
So, hardware fault - unlucky. However, I would attempt to find out if it’s just the connectors since they are most likely to fail. Visual inspection isn’t always enough.
1 Like