Just a reminder. In UK we have a 1% duty cycle limit so if your transmission takes 0.01 seconds you have to wait a further 0.9 seconds before you transmit again. (Legal)
On TTN you have a max of 30s per day transmit time.
2 Likes
Heya Brian. Thanks for all your really great work so far getting the TTNv3 updates done.
I have been for some time [you might recall some of my attempts previously OTAA March 2021 attempts ] been trying to get this setup to work under AU915.
Where we have a semi-unique situation where as the TX and RX frequencies are different.
So I am at it again, I have forked your excellent work and tried to make the AU915 changes to mine, so that once successful I could send you a pull request.
Even with your current RX2 being a fixed freq and my modifications to make RX1 also fixed I can still not for the life of me see any RX downlink messages.
TTN is seeing the OTAA request fro the RAK7246 gateway-
TTN Application is also seeing the request -
And from what I can tell, the RX is being processed - when I see the reports on the gateway the counter for the TX increments.
So I am seeking your guidance please as to what else I can try to include in the code for the AU915 to be functional.
Always remember that the dragino.toml is an initial starting point and values can be modified by MAC commands and current values are cached in cache.json as per LoRaWAN spec (end device must store xyz).
Here in UK the RX1 frequency is the same as the transmit frequency - which is a random choice from the lora_freqs in dragino.toml - but the RX2 is fixed.
If you have joined TTN the evidence of the current state will be in cache.json. If the node is powered off cache.json is restored and a new join is not required.
Ok, if you joined TTN then there was a downlink from TTN to provide you with devaddr and session keys. Those will be in cache.json - further evidence of downlinks.
If you power up your node and it ALWAYS re-joins it indicates there is no devaddr in cache.json and that would indicate no downlink (JOIN_ACCEPT) was received.
Hope that helps
Where next? I assume you are using logging. if you have left the logging level at logging.DEBUG then you will have a heck of a lot of information in it -possibly too much to email to me. If you can place it on a google drive and message the link to me I’ll take a look.
Regards
Brian
Thanks for the prompt reply. Yeah I am aware you are in the position to have the shared RX / TX frequencies.
I have looked extensively at the cache.json file and I do not get any real sense for any of the attempts and adjustments that I have ever managed to complete the join for OTAA. I do not believe the request to change to the RX1 freq or even the RX2 freq is happening. I do have some logs, happy to share as much as you want. Ive sent a msg with contact details. Hope you get that and I can share some logs or even ssh access to have a play if it comes to that 
I really really am going to make me an RFM95 hat to take this for a spin.
If only so I can revel in the strange sentences in the code that start with # - don’t see many of these now-a-days!
But mostly so I can dig in to the details of the Russian dolls that is the structure of the LoRaWAN packet - using LoRaWAN MAC is one thing, knowing the MAC is another and I find reading different implementations helps such dense material sink in.
On your next update of the repro, couple of notes for you to consider some alterations to the readme:
TTN Fair use policy limits you to 10 downlinks per 24 hour period.
The consensus on the forum is that a downlink per fortnight is a good design, 10 a day per device in an area of deployment could actually result in a substantial number of lost uplinks as the gateway will be deaf to all & any uplinks whilst transmitting the downlink. The LinkCheck will also trigger a gateway transmission but I can see that it’s not automagically triggered in the firmware (regional parameters set a suggested count of uplinks before doing a LinkCheck but that’s deep in to the details).
I’ll figure out some weasel words for consideration later.
The TTN servers only send downlinks after an uplink - I assume that is so TTN doesn’t send messages to someone who isn’t listening.
It’s because that’s the LoRaWAN spec for Class A - when device sends an uplink it then listens on Rx1 & Rx2 windows for any incoming messages. It’s not unique to TTN.
As for the GPS issues, a perpetual issue with opening & closing ports & the like on the Pi, maybe it could be turned off by default so that people can get over the challenge of LoRaWAN before making things more complicated?
1 Like
Not sure it’s always required to open and close ports.
Gpsd does operate locally as a port but some of the python implementations for the gps read the nmea data directly from the serial stream and process the changes/data to calculate the long/lat/altitude and time information.
To add some more detail there are 8 uplink channels from the node to Gateway in FSB2, ie channels 8, 9, 10 … 14 and 15. If the network responds and the Gateway transmits it is on one of 8 downlink channels. The first downlink is selected if the uplink was on channel 8, the second downlink channel if the uplink was on channel 9 and so on.
The downlink channels are 923.3, 923.9, 924.5 and so on.
My post back 12 months ago was a little vague on this exact detail as it wasn’t the purpose of that post.
1 Like
GPS point noted . Will do that in next update
Tony, This sounds like my code needs changing to meet FSB2. Currently it expects RX1 freq to be the same frequency that was transmitted on - which I believe is true in UK (It is working for me after all).
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 …
2 Likes
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! 
1 Like
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?
1 Like
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.
1 Like
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.
1 Like
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…