Dont be put off or disheartened - all libraries have to evolve and develop capabilities over time, even the almost revered MCCI lib has a history! If it meets your needs locally and meets spec needs and isnt disruptive, great - neccessity is the mother of invention I’m told!..if as appears you are willing and able to adapt to others needs in other regions and LoRaWAN specification/regulator regimes and can do that with out disrupting other users then fantastic! And to recognise short commings and work to address them
That is what community contribution and development is all about…just don’t leave as a crippled version that causes problems ( TinyLoRa! et al). If told to step back and look at overview many may never get going in the 1st instance, as not every one will generate perfect instantiations and code on 1st release…as noted just be careful and test to make sure not causing problems for the back end or for the community at large - a seperate test environment may be useful in this situation?!
WRT ESP 32’s as noted elswhere on forum, whilst well supported by some libraries, these can be problematic - e.g. reseting after a deep sleep forcing a rejoin etc., but as you say if continuously powered may well be a good option…
@bnnorman I am using your repo try and send Atals Scientific sensor data to TTN. When I use your test.py code it works and sends the hello message.
Any ideas as to why I get a problem when I integrated into my code, I can take a sensor reading but the message does not get sent and the output shows below:
Hi @bnnorman have you installed on Bullseye yet? I have tried but I cannot install the required python3-crypto and python3-gps libraries as both complain about having no installation candidate.
Bullseye, yes, at least a month or two ago. Crypto is a problem as it was dropped from bullseye because of security issues but in my use case it didn’t matter to me, so I downloaded crypto (unsupported) from github and used that.
Now, whilst racking my brain/googling to remember what I did. I notice python3-cryptography exists. I haven’t tried using that instead (I don’t know if the API is the same). I might try that and update the readme (or you could try it for me). The original installation notes were from the original compute-nodes repository. There’s also cryptodome - so many choices!
One other thing, try installing pycrypto with pip. Not tried myself but the API looks to be the same. Changing the API will require changes to files in the LoRaWAN folder.
Hmm, I saw that error ages ago. Its in the original source ( ie not my code). It says mode is not in the lookup table/ dict. I would add a print statement just before line 221 to print both mode and MODE.lookup to find out if mode is invalid or MODE.lookup has been initialised. I’ m not at my desktop at the moment. Its feet up time for me.
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.
If it meets your needs locally and meets spec needs and isnt disruptive, great - neccessity is the mother of invention I’m told!..if as appears you are willing and able to adapt to others needs in other regions and LoRaWAN specification/regulator regimes and can do that with out disrupting other users then fantastic! 
TinyLoRa! et al). If told to step back and look at overview many may never get going in the 1st instance, as not every one will generate perfect instantiations and code on 1st release…as noted just be careful and test to make sure not causing problems for the back end or for the community at large - a seperate test environment may be useful in this situation?!