I can have a go at AU915, having recently added it to the ST CubeMX LRWAN1 code base - not sure if it was ST or Semtech that hadn’t done it but it took a bit of poking.
Whilst the code base is radically different, the principals apply and I still have a small part of Australia setup in the office for testing - basically a gateway & a B-L072Z board glued to the ceiling so it’s the right way up …
There’s typically more than just channel frequencies/algorithms different between LoRaWAN regions. One would need to really read the regional parameters document and consider all of the differences including things like region specific MAC command meanings.
Actual LoRaWAN compliance is quite hard when you really look at ALL of the required details; AFAIK there are currently really only two public codebases which approach it - Semtech’s, and MCCI LMiC, and both of those are developed with the aid of a dedicated hardware LoRaWAN compliance test machine which can run all of the software-level protocol tests in an off-air cable-based RF environment.
Dont forget to turn the antenna upside down! 
If you are going to code for FSB2 then the more general case of coding for all FSB blocks (FSB1, FSB2, … FSB8) then the downlink channel is modulo 8 of the uplink. ie Channel 0 which is the first channel in FSB1, Channel 8 which is the first channel in FSB2, channel 16 which is the first channel in FSB3 … all respond on the first gateway downlink channel.
Then you move onto the second uplink channel in each block all respond on the second gateway downlink channel.
I appreciate the comment.
I planned to tackle it with three tables of frequencies for TX and RX1 like this
lora_join_freqs=[868.1,868.3,868.5]
lora_tx_freqs = [868.1,868.3,868.5,867.1,867.3,867.5,868.7,867.9]
lora_rx1_freqs=[868.1,868.3,868.5,867.1,867.3,867.5,868.7,867.9]
Which, I think, should work for the uk. Other frequency plans could use other frequencies. Is that not plausible?
Table driven regional settings are a thing, but softly softly, evolution for the win.
It is almost working in AUS. The dragino, currently, communicates up and down but the join fails in an area of the code which has never changed (so, yes, it must be outside that). I’m still doing time shifted debugging.
Sigh.
First, calling it “the Dragino” is utterly pointless, because the hardware has absolutely nothing to do with it. This is a software challenge, from start to finish.
As for the issue, you seem to be continuing to ignore that regional settings comprise far more than just frequencies.
Either you need to step back far enough to really appreciate the scope of the task in fully implementing LoRaWAN, or you need to abandon this incomplete software and switch to software that already actually works for your region.
Maybe but the code wasn’t written for any other purpose/hardware. It is a fork of computenodes/dragino which, in turn was based on GitHub - jeroennijhof/LoRaWAN: LoRaWAN implementation in python
How do arrive at that conclusion? The computenodes author stopped developing just as TTN moved from V2 to V3. I added MAC command handling (which wasn’t there). The data rates list and DR offset tables are handled by my version/extension of the computenodes code. I have been through LoRaWAN Spec 1.0.4 numerous times but only with UK in mind. Now, someone in AUS want to use the same device I have modified the code as required - The AUS device is now working. It has joined and received downlinks. The modifications work in the UK. so I believe the code is now more generic regarding frequency plan.
I started this investigation 2 years ago - it stalled due to covid lockdowns. I didn’t start working on this for the rest of the world it was an investigation into the plausibility of adding Lora to the local council road speed signs so that data could be uploaded without sending a bloke with a hand held device to download traffic information. The Pi was chosen because the sign has power on all the time.
I had thought of re-writing the python LoRaWAN side of things - it’s a bit like (as someone here said) Russian dolls.
I have been considering, due to Pi shortages, switching to using a couple of ESP32 (I have not checked availability) and have begun some coding for that. I would use LMIC-node on one and talk serial to the other which, in turn, manages the GPS and the SpeedSign (both serial devices). Or I could just use the RPi compute module which is supposedly designed for field use.
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…
Thanks jeff, I wasn’t put off.
I would love to know a source for CM4 modules with eMMC that can ship before September this year.
@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:
Connected EZO devices:
pH 99
Starting dragino connection to TTN
Mode ← SLEEP
Mode ← FSK_STDBY
Mode ← SLEEP
Mode ← FSK_STDBY
Mode ← SLEEP
I need to see your code please. And the log file.
@bnnorman
Hi I am using your code and have seen a couple of issues, do you want me to report them on your github page?
Yes please - I have just added an issues tab.
I have fixed the bug. Get a new copy of MAChandler.py from the repo or just edit lines 222 and 252 to
self.currentChannel=random.randint(0,len(self.cache[CHANNEL_TX_FREQS])-1)
note the -1.
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!