matthijskooijman / arduino-lmic

:warning: This library is deprecated, see the README for alternatives.
705 stars 651 forks source link

US region configured Node still transmitting at 868 Mhz according to TTN Console #172

Open gpickney opened 6 years ago

gpickney commented 6 years ago

I have the Adafruit M0 LoRa feather, and I am very new to LoRa and LoRaWAN. I've cloned the latest master branch of this repo and made a few changes:

  1. In 'config.h' I've commented the line for EU and uncommented #define CFG_us915 1

  2. In 'hal/hal.cpp' I've changed static const SPISettings settings(10E6, MSBFIRST, SPI_MODE0); to static const SPISettings settings(8E6, MSBFIRST, SPI_MODE0);

  3. I've added the statement 'LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);' after 'LMIC_reset();' in the ttn-otaa example .ino file.

My Serial logs:

Starting
Packet queued
62700: EV_JOINING
1382184: EV_JOINED
1518755: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
5422012: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
9309227: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
13195803: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
17082377: EV_TXCOMPLETE (includes waiting for RX windows)

....repeating


My TTN Gateway logs Join Request

{
  "gw_id": "xxxxxxxxxxxxxxxxxx",
  "payload": "xxxxxxxxxxxxxxxxx",
  "dev_eui": "xxxxxxxxxxxxxxxxxxxx",
  "lora": {
    "spreading_factor": 8,
    "bandwidth": 125,
    "air_time": 113152000
  },
  "coding_rate": "4/5",
  "timestamp": "2018-05-02T04:40:41.235Z",
  "rssi": -127,
  "snr": -4.8,
  "app_eui": "xxxxxxxxxxxxxxxx",
  "frequency": 868100000
}

Join Accept

  "gw_id": "xxxxxxxxxxxxxxxxx",
  "payload": "xxxxxxxxxxxxxxxxx",
  "lora": {
    "spreading_factor": 12,
    "bandwidth": 500,
    "air_time": 288768000
  },
  "coding_rate": "4/5",
  "timestamp": "2018-05-02T04:40:46.231Z",
  "frequency": 923300000
}

Uplink

{
  "gw_id": "eui-xxxxxxxxxxxxx",
  "payload": "xxxxxxxxxxxxxxxxxx",
  "f_cnt": 1,
  "lora": {
    "spreading_factor": 8,
    "bandwidth": 125,
    "air_time": 113152000
  },
  "coding_rate": "4/5",
  "timestamp": "2018-05-02T04:41:49.851Z",
  "rssi": -126,
  "snr": -5.2,
  "dev_addr": "xxxxxxxxxxx",
  "frequency": 867500000
}

Downlink

{
  "gw_id": "eui-xxxxxxxxxxxxxxxx",
  "payload": "xxxxxxxxxxxxxxxxxxxx",
  "lora": {
    "spreading_factor": 12,
    "bandwidth": 500,x
    "air_time": 329728000
  },
  "coding_rate": "4/5",
  "timestamp": "2018-05-02T04:41:50.852Z",
  "dev_addr": "xxxxxxxxxx",
  "frequency": 923300000
}

TTN Device Logs On this particular run, I didn't get any device logs... but when I do they look something like this...

{
  "time": "2018-05-02T04:34:27.27684809Z",
  "frequency": 868.5,
  "modulation": "LORA",
  "data_rate": "SF10BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "gtw_id": "eui-xxxxxxxxxxxxxxxxx",
      "timestamp": 2337950924,
      "time": "2018-05-02T04:34:27.146451Z",
      "channel": 2,
      "rssi": -127,
      "snr": -4,
      "rf_chain": 1
    }
  ]
}

As you can see, the gateway indicates that the uplinks are 868 mhz and the downlinks are 915 mhz as shown above.

What gives? Does anyone have some insight for me on this issue? Am I reading the message logs incorrectly?

matthijskooijman commented 6 years ago

That sounds really weird, I would suspect some issue with TTN here. In particular, if your gateway is 915Mhz, it should not even detect packets on 868Mhz. Also, downlinks are supposed to be sent on the same frequency as the preceding uplink IIRC, at least for 868Mhz.

If you increase the logging level to most verbose level (3 IIRC, see config.h), I think LMIC should print the frequency it is planning to use to serial.

gpickney commented 6 years ago

Checked the more verbose logs for the node on the serial console which seem to indicate the correct frequency:


13227995: TXMODE, freq=907900000, len=23, SF=10, BW=125, CR=4/5, IH=0
13250987: irq: dio: 0x0 flags: 0x8
13251103: Scheduled job 0x20000968, cb 0x2f19 ASAP
13251263: Running job 0x20000968, cb 0x2f19, deadline 0
13251439: Scheduled job 0x20000968, cb 0x2b7d at 13560480
13560480: Running job 0x20000968, cb 0x2b7d, deadline 13560480

On snippets like this attempted join, which clearly states is in the ~900mhz range, the output on TTN console is:

{
  "time": "2018-05-03T04:46:22.049785276Z",
  "frequency": 867.7,
  "modulation": "LORA",
  "data_rate": "SF10BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "gtw_id": "eui-xxxxxxxxxxxxxxxxxx",
      "timestamp": 1132486828,
      "time": "2018-05-03T04:46:21.918571Z",
      "channel": 6,
      "rssi": -127,
      "snr": -8.5
    }
  ],
  "latitude": xxxxxxxxxxxx,
  "longitude": -xxxxxxxxxxxxx,
  "location_source": "registry"
}

I'm so confused. The metadata is generated by the lora module right, not somewhere in this example code? The only bright side, is after reinstalling/restarting all applications/gateways, I no longer receive these messages on the gateway.

Here's some more photos:

Gateway Configuration... gateway config png

Gateway Traffic... gateway logs

Device Traffic... application logs

matthijskooijman commented 6 years ago

It looks like there might be a bug in TTN, somehow generating incorrect metadata...

The metadata is generated by the lora module right, not somewhere in this example code?

The JSON metadata you get is generated by TTN, based on info it gets from the gateway(s), which is in turn based on the actual frequency and other settings used, which are determined by LMIC. The LoRa module, that is the SX1276 or similar, is fairly dumb and only does as instructed by LMIC.

The only bright side, is after reinstalling/restarting all applications/gateways, I no longer receive these messages on the gateway.

Not sure what you mean by this. The messages no longer appear in TTN? Or only through other gateways?

gpickney commented 6 years ago

Thanks for the info. Excuse my ignorance, as this is the first time I'm working with hardware instead of just software.

The only bright side, is after reinstalling/restarting all applications/gateways, I no longer receive these messages on the gateway.

I wrote this part of the last comment before I posted the picture of the Gateway Traffic. I actually did end up receiving the join requests from the node on my gateway as shown above... albeit on the wrong frequency. You can see that the app/dev euis match up for these requests on the gateway and device traffic logs. However, I only ever saw EV_JOIN_FAILED in my device's Serial logs. The Serial logs on my device also indicated a frequency of ~900 Mhz... not ~860

I'm using the Sandbox Electronics LoRaGo PORT, which is essentially the same hardware as the ic880a. I installed the ic880a software from ttn-zh/ic880a-gateway onto a Raspberry Pi 2 Model B. All went well with the installation and registration on TTN, which indicates its frequency plan is 915mhz.

matthijskooijman commented 6 years ago

All went well with the installation and registration on TTN, which indicates its frequency plan is 915mhz.

IIRC the frequency plan shown in TTN is just what you configured, and I think it is used to generate a gateway config for it (at least for the official TTN gateway hardware, possibly also for the classical forwarder if you download the config from TTN), but I do not think it reflects the packets received from the gateway at all.

ramasouto commented 5 years ago

I am experiencing the exact same issue. My Heltec LoRa module sends the join request to TTN, the metadata shows 867 Mhz (I have the config set for US) the response metadata is shown as 923 Mhz and I keep getting EV_JOIN_FAILED on the serial monitor.

screen shot 2018-11-19 at 2 25 30 am

Any ideas? Could it be wrong Metadata generated by TTN? If so, any ideas why I'm stuck on the EV_TXSTART & EV_JOIN_FAILED loop?

Thanks in advance! :)