Welcom to the TTN forum.
Unfortunatly the LG02 is not supported for TTN LoRaWAN, its mentioned on Dragino’s page for the product;
For Private LoRa Protocol, Not recommend for LoRaWAN use.
Hi, thanks for the reply.
Would you know to say if I can use the Radioenge with Raspberry PI 3 for LORAWAN?
I would not know, sorry.
If no-one else answers, try contacting the manufacturer of the device.
Regardless the unsupported dual-channel forwarder, and assuming you’re seeing this in TTN Console: you’re seeing a downlink frequency of the EU868 region. So, I’d guess that you’ve selected the wrong frequency plan in the gateway’s configuration in TTN Console, which does not match the actual US915 you’re using.
Also, this EU868 frequency is only used for RX2, which is only used for slow data rates (high spreading factor SF and long time-on-air). So, it also seems you’re doing uplinks with a high SF. That should not be needed in your case. But when you stop using the Dragino LG02 then using such high SF might help reaching other TTN community gateways.
Ok, thanks.
I configured the gateway Radioenge and now the communication with the TTN server is working fine, either with OTTA and ABP.
@arjanvanb I am having exactly the same problem with a Dragino LPS8 for the AU-band. The LoRa device sends the downlink in the 917 MHz range channels, and the downlink information is received correctly in the TTN console. but the gateway answers on 868.525 MHz, being the EU RX2 frequency. Or at least, I think the gateway doesn’t even transmit this message because it is not suited for the 868 MHz band, but the TTN backend shows that it selects this frequency.
In the console, the frequency plan for this gateway is defined as Australia 915MHz, so everything seems fine. Do you (or anyone else) have a clue why the TTN server persists in sending a message in RX2 on 869.525 MHz?
This sounds like a bug or at least missing sanity check in the TTN servers.
Regardless if a gateway has been mis-entered in the platform, the server arguably shouldn’t command a downlink in an entirely different bandplan than the uplink, really it should flag it as somehow invalid though AFAIK there is no public server log that would indicate errors so ignoring would be the likely proper outcome.
I wonder if you’re seeing a “catchall” case for the application of EU868 fixed-frequency RX2 settings triggering when something about the uplink is unexpected. Is the gateway pointed at the correct TTN router for its region?
(Course timestamps don’t seem to fit RX2 though - granted they are rounded. Do proper RX2 downlinks show an overview delay rounded to one second instead of the actual 2 seconds?)
1 Like
That doesn’t support SF11 or SF12 for uplinks. So, while I agree TTN should not use EU868 frequencies, I also think that the device is to blame for using an invalid data rate.
For what I have seen: yes. (But I’ve only investigated Join Accepts, which for RX1 show 4 seconds instead of 5, and for RX2 show 5 rather than 6. Of course, one is seeing the time at which TTN delegates the downlink to the gateway.)
1 Like
@cslorabox Yes, the gateway points to thethings.meshed.com.au
I hadn’t even noticed the timestamp thing. I checked the detailed timestamps and indeed it is only 1 second. But then I checked one of my ‘regular’ EU868 devices and that also shows only 1 second difference in timestamps for an RX2-reply
Sounds like it really is an overly broad “default” case applying the EU868 RX2 settings when nothing else “fits” the details of the uplink, that would be the “bug” portion.
And that would be the sanity check one
So correcting that is the immediate end-user solution both with and without fixing the server issues. Or not, because using SF12 actually is in accordance with the LoRaWAN spec.
Probably. Just went and looked and normal RX1 traffic in a similar view shows a truncated delay of 0 whole seconds. Sorry for the distraction, I probably should have just looked first…
2 Likes
This seems to be a very messy situation. SF12 actually is legitimate for AU915 under any currently active LoRaWAN spec, apparently in the very earliest version it was not (perhaps inspired by US915 which must operate under packet duration rules where even the LoRaWAN headers alone wouldn’t fit beyond SF10)
This thread seems to discuss the situation:
Though I can’t say after reading that it’s very clear what would work on TTN.
The incompatibility isn’t necessarily as simple as avoiding SF12 and SF11, in ADR MAC commands the data rates would be numbered ordinally they should count from DR0=SF12BW125 but if one end thinks DR0=SF10BW125…
In theory all of this should be handled by correctly registering the node as LoRaWAN v 1.0.2 or later vs v 1.0.0, but the thread above seems to suggest the servers can’t implement such a distinction?
2 Likes
And what did you select for the gateway’s router? I’d guess that eu would also support non-EU868 frequency plans, but maybe not.
(Aside: the V2 network is bridged through V3, somehow, so maybe some components fail in whatever translations are happening there.)
1 Like
@arjanvanb I also have messages on SF9 and SF10 showing exactly the same result.
BTW, SF11 and SF12 not being supported: is that a TTN-specific thing? Because the LoraWan standard says:
Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying from DR0 to DR5, using coding rate 4/5, starting at 915.2 MHz and incrementing linearly 777 by 200 kHz to 927.8 MHz
I know TTN supports only 8 channels out of those 64, but I wasn’t aware that also a subset of data rates was supported. And although not supported: messages sent in SF11 or SF12 do get processed normally.
As router, I selected thethings.meshed.com.au
@arjanvanb @cslorabox The problem is solved. I reset the Dragino to factory settings and then I put in the whole configuration from start again, and now I see the replies are coming in on the proper frequency 923.3 MHz.
I tried to deduct what could have been the problem and the only thing I could think of was that the gateway was communicating with the EU server although it showed ‘meshed-router’ in the config page. So I manually changed it to ttn-router-eu and indeed the problem was back! Changed it again to meshed-router and everything works fine…
1 Like
Just for future reference, from Slack, emphasis mine:
Fernando Barreto 2020-05-13 10:11 PM
Hi, here in Brazil (AU915) I was using the ttn-router-brazil handler some time ago and worked ok with nodes programmed with LMIC library. It is the correct handler for my region. However, since four weeks ago it doesn’t work anymore for OTAA. I suspect it is because the Join Accept was transmited at RX2 and the nodes never receive the Join Accept (here I tried to change the LMIC_setClockError without success). I changed the handler (gateway configuration and TTN console) to ttn-router-eu and it worked OK with Join Accept at RX1, and the nodes complete OTAA process. Now, since some days ago, ttn-router-eu is always sending a downlink with EU863 RX frequency and nodes aren’t working anymore.
I changed to us-west handler, and OTAA doesn’t work either.
That’s a lot of trial and error, so I’m not sure if “since some days ago” started out of the blue.
I have the same behavior on my Sandbox Electronics LoRaGo gateway. Will try the suggestion @rharte mentioned using meshed-router.
I had the same issue. Switching to the US router helped. When I used the EU router, I always got downlinks on 869.525.
Hi friends, new here. I sign in here to solve a question i have. I buy a Helium Hnt hotspot miner (Nebra) us915, but my country (argentina) Is au915! Works anyway?, don’t works?, i can setup to make it works? I Will tanks any help
Hi,
This is The Things Network forum which is for discussions on TTN.
Helium is an alternative network which is NOT TTN so NOT up for discussion here.
I suggest you ask on the Helium forum &/or Pi-Supply.