How to add Dragino Lora/gps HAT to V3

Sadly no - further forward. As you can see the join-request got through via another gateway but the message back was not received after waiting 15 seconds . My gateway thinks it sent the packets (10) up but the info on the device live data doesn’t tell me which gateway picked it up. That would have been useful.

The test assumed a response would happen in RX1 at join freq and SF. How long should it wait before switching to RX2? I have read that RX1 delay should be no more than 5 seconds with a 1 second window before listening on RX2 but I also read a join could take upto 15 seconds. Arghh!

image

image

image

  1. Gateway details are available once you click on the message in the device view. A window with a large json structure should open containing an overload of details.

  2. Please read the LoRaWAN specification and regional parameters, there is a lot of information in them. For join RX1 is 5 seconds. Not 4, not 6 and certainly not 15. RX2 is RX1 plus one second. After that no more data will arrive at the end device for a join request so 15 seconds does not make sense.

  3. Assumption make an ass… You need to be sure what happens for debugging.

  4. LoRaWAN time slots are extremely timing critical. A RPi isn’t a great choice for a real time embedded system with the default Linux versions. To make sure you have a chance of receiving data open RX1 early and close it a bit beyond the normal window.

BTW, make sure to use a fully LoRaWAN compliant gateway when developing, single channel abominations make life a lot more difficult and will cause issues for other users as well.

Yeah, I get that a lot - trouble is on the forum you can’t stand next to them although, UK travel restrictions be damned, I’m tempted for some cases to go and fix it that way!

For Joins, Rx1 is 5 seconds - so you only need to wait 6.5 seconds to know. Don’t confuse this 5 seconds with the other 5 seconds I’ll mention in a second.

Rather like in your gateway console where you clicked on the line and got the event details, you will get the same for the device log - scroll down in that box and it will show you the gateway info.

You don’t, it’s meant to be baked in to the code - if nothing arrives after 5 seconds, wait 1 second and listen again.

Depends on the context of what was being written - I could just as easily say it takes 10 minutes if the device has to try a few times.

Ideally you need to get to a point where your gateway is showing it is transmitting the Join Accept before moving on to the Pi problem.

Can you look at the device log and see which gateways it is being heard by.

Do you have another device you can put on to v3?

v3 is far more compliant so more relaxed implementations of a LoRaWAN MAC are going to struggle to talk to the NS.

And then there is the info Jac has mentioned regarding timings.

1 - I don’t get that with join request

{
  "name": "js.join.accept",
  "time": "2021-07-15T07:11:50.514650673Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "test-01",
        "application_ids": {
          "application_id": "bnn-dragino-test"
        }
      }
    },
    {
      "device_ids": {
        "device_id": "test-01",
        "application_ids": {
          "application_id": "bnn-dragino-test"
        },
        "dev_eui": "29510000A0710000",
        "join_eui": "43762049A040C5E7",
        "dev_addr": "260B57B9"
      }
    }
  ],
  "correlation_ids": [
    "rpc:/ttn.lorawan.v3.NsJs/HandleJoin:01FAMG3R7C7HVYE22QX5KPYRYD"
  ],
  "origin": "ip-10-100-5-178.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01FAMG3R7JMXNYWGWKXHVK6T1W"

2 Thanks, that was the timing I was working with. The dragino code listens immediately after transmission is complete.

  1. Correct, but I have tried every which way…or it feels like that.

4 I agree but the Pi was chosen because of a lot of other stuff it needs to do including message scheduling, aggregating data to reduce traffic and more (LOL). As I said. It works ok in V2 In the main the use case just transmits periodically whilst keeping to the 1% duty cycle and Fair Use policy.

That’s not the Join Request which is what you need to find.

If your gateway isn’t hearing it, just concentrate on that in the first instance.

For how long - does it stop before the transmission arrives?

Given the relaxed nature of v2, that may well be the case. But we don’t have v2 anymore, so you need to make your device more compliant.

Thank you. I have a ‘pax counter’ based on TTGO which was originally working on V2.

I copied the keys to V3 and deleted the device from V2 - it shows a join-accept in V3 but the device is indicating ‘join wait’ which suggests it hasn’t gotten the Ok from upstairs. I didn’t originate the code it was a curiosity thing.

Again I don’t see an obvious gateway id in the JSON.

{
  "name": "js.join.accept",
  "time": "2021-07-15T08:56:44.808391808Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "brian-sensor",
        "application_ids": {
          "application_id": "bnn-pax-counter"
        }
      }
    },
    {
      "device_ids": {
        "device_id": "brian-sensor",
        "application_ids": {
          "application_id": "bnn-pax-counter"
        },
        "dev_eui": "0000000000000003",
        "join_eui": "70B3D57ED001DD19",
        "dev_addr": "260BADEB"
      }
    }
  ],
  "correlation_ids": [
    "rpc:/ttn.lorawan.v3.NsJs/HandleJoin:01FAMP3V02VM5ZFZAVZY766607"
  ],
  "origin": "ip-10-100-5-178.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01FAMP3V088947FJB66Q64NP4T"
}

I can change the keys on my RasPi to make another device. I think it’ll take a lot longer for me to delve back into arduino to produce a new device that way but I can see the benefit

I said this last time:

Please please please look for a Join Request and not a Join Accept

Can’t see that being of much use, we don’t even know if the Python is receiving.

You probably need to check ‘verbose stream’ to see the join request. This is the accept.

Which all will interfere with the real time nature required for LoRaWAN. If you need a RPi a safer solution would be to use a module like RN2483 which embeds the LoRaWAN stack and can be driven using a uart using ASCII commands.

Including OTAA joins?

Sorry, I mis-understood. The wording here ‘Accept join-request’ under ‘Type’

image

suggested to me that the join was accepted and that was the line supposedly providing the gateway info.

Now, if that just means ‘tried to join’ but ‘not accepted’ that would be a different matter.I understand TTN ignores dodgy messages for security reasons.

I can see how frustrating this is for us both and I do sincerely apologise. I know you guys work with this stuff all day long.

I’ll take a look at the RN2483 device.

I’ll go quiet now whilst I try to build an Arduino device.

It is, but you kept saying you couldn’t see which gateway was picking it up and I kept saying that you needed to look at the Join Request line.

Which you haven’t done, so we still don’t know if your gateway is working.

It does say “Join Accept”, it does not say “Join Accept to be transmitted by gateway, details enclosed”

You look on the gateway console to see the transmission.

If you look at the Join Request, it will tell you which gateways heard the request.

So until we know if your gateway is participating in all of this, building a new device may be pointless.

But you could try ABP …

The join is accepted, however this is a response message, not the request. Have you used the ‘verbose stream’ tick box top right of the traffic window? Checking it will display a lot more information relevant when debugging, including the request packet with gateway information.

My BAD and massive appologies for mis-understanding. Previously, all I ever saw were the Accept join-request messages. - I’m pretty sure that when I tried the verbose tickbox after the attempted join I didn’t get any more detail but now, having ticked the box before attempting a join, I get all sorts of detail. I could be wrong, of course, my head is spinning.

My apologies.

“forwarder_gateway_id”: “hcc-lora-004”, - this is the humber bridge gateway (still on V2) 11km away not my kickstarter in the next room. Perhaps my kickstarter was lying to me about forwarding packets

I got this info too.
“rssi”: -114,
“channel_rssi”: -114,
“snr”: -14.5,

A number of messages are slightly lower than this at rssi -117 and snr -9.25.

Should be ok for reception of the downlink join-accept I would have thought but I’m not seeing it.

The log tells me a JOIN-ACCEPT was scheduled for downlink transmission at RX1 delay:5

The console for my Kickstarter shows no traffic at all so I guess that needs looking at. I’d like to cure that first to eliminate signal strength. Perhaps I’ll try rebooting the kickstarter to see what I can find out.

No problem, the details can be overwhelming.

What SF are those packets? Because at lower SFs your node might not hear the reply. Getting your own gateway running correctly is a good step to a controlled environment where you can access logs of all important components.

Thank you for your patience. The join-request packets seem to get through at SF8,9 or 10 but not 7. So I think distance is an issue.

I agree regarding my own gateway - I’m trying to re-activate it again.

I’ve plugged in a long ethernet cable to get rid of any WiFi flakyness if any (though it never was a problem before). Currently It is stuck on Broker Connection: False at the moment as shown below.

image

The ‘config correct: false’ line looks suspicious to me. Can’t verify at the moment but I would expect that to require a ‘true’ value.

I have done the re-activation tango and my kickstarter gw has ‘connected’ again.

image

Still, it shows packets up (When I fired up my TTGO pax counter) but none down.The pax counter display told me it was waiting for a join.

The TTN V3 console shows no traffic at all - I left this console view open since , as you can see, 07:27 this morning whilst I went and did something more rewarding - playing golf.

image

I also put an FTDI on the gw debug port and have several hours of recorded debug messages. 99% of which are just stack status messages - and they show the stack isn’t being consumed by anything.

There are a lot of these:-

LGMD:Rejected packet (0x11)

which , I guess, may be non-compliant transmissions from somewhere (not me I was on that golf course) LOL

There’s a thread about this on the forum dating back to April 22nd but it remains unresolved.

Also this - but it hasn’t appeared in the gateway console even with verbose checked

LGMD:LORA: Accepted packet

MQTT: Sending UPLINK OK

There are some of these

MQTT: Sending status packet
MQTT: Sending status succeeded: 885 <- incrementing number.

Is it possible to get more info out of the debugging on the kickstarter gw?

Something fundamentally wrong here I think.

My RPi+ Dragino HAT based end-node is seen by the V2 gateway on the Humber Bridge and Live data shows up in the V3 verbose log. The Live data shows the join was accepted and a JOIN_ACCEPT was queued for sending back but I received nothing at my end. RSSI was -111 at one point so within the RFM95 spec. hence I would expect to receive something, if transmitted, but no rx_done interrupt was generated.

I also added logging to all the interrupts PayloadCrcError, CadDone etc - not a dicky bird.

I cranked the TxPower down to 1db - my kickstarter gateway saw the transmission (info page Packets Up increasing) but it wasn’t picked up by any other gateways in the area. That was intended to force the packets down to come via my gw, but they didn’t.

My Kickstarter gw (bnn-ttn-1) still tells me, via the info page, that it is sending packets up but nothing appears in the V3 console live data. And it shows no packets down at all. Can you tell if the gw is actually subscribing and not just publishing?

I built an LMIC-node using a Heltec Lora 32 V2 (and a V1) for comparison but still no join - though my Kickstarter incremented its Packets Up at each join attempt. However, there was no traffic in the V3 console for it (keys were double checked).

It would be useful to know which gateway the return message was supposed to go to for sending on to me.

If anyone has any other suggestions of things to try I’m all ears. Thanks for reading.

Buy a TTIG and an Adafruit Feather M0 + RFM95 - we can debug them!

So, we’ve exhausted all other possibilities like server log files?

I’m not about to part with approx £100 for extra hardware I can ill afford on my lowly pension. The Heltec is just another Arduino MCU so I don’t see the point in buying a Feather. The TTIG - well, the local community has something like 30 kickstarter gw, many as yet undeployed, which they will want/hope to use.

I guess I’ll try to install the things stack on a Pi4 as a local server and see if I can identify the problem with the Kickstarter packet forwarding. It’s a shame, my kickstarter has been, till V3, rock solid. I know others have gotten theirs to work.

Nope, you could have a day out in Bolton