"Successfully scheduled join accept for transmission" doesn't appear in console

End Devices (Nodes) LMIC
, ,
1

Hello everybody,

I am new to the Things Network. We have a problem in the following situation:

For our custom board we use an ATmega328PB as Lora node controller.
→ ATmega328PB
→ rmf95W module
→ library: mcci-catena/arduino-lmic
→ Platformio configuration:

build_flags =
	-std=gnu++17
	-D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
	-D CFG_eu868=1
	-D LMIC_LORAWAN_SPEC_VERSION=LMIC_LORAWAN_SPEC_VERSION_1_0_2
	-D CFG_sx1276_radio=1
	-D LMIC_USE_INTERRUPTS=1
	-D DISABLE_PING
	-D DISABLE_BEACONS
	;-D DISABLE_JOIN
	-D LMIC_PRINTF_TO=Serial1
	-D LMIC_DEBUG_LEVEL=1
	-D USE_IDEETRON_AES
	-D US_PER_OSTICK_EXPONENT=4
	-D LMIC_ENABLE_long_messages=0
	-D LMIC_ENABLE_DeviceTimeReq=0
	-D LMIC_FAILURE_TO=Serial1
	-I lib/arduino-lmic/project_config
	-I lib/arduino-lmic/src
	-fdata-sections
	-v
	-ffunction-sections
	-Wl,--gc-sections

→ the arduino-lmic library, specifically the HAL part, was tweaked so that it uses SP1 instead of SPI0 on the ATmega328PB.
→ We use the OTAA ttn example from the arduino-lmic github with the following tweaks:
void setup():

    os_init();
    Serial1.println("Setup success");

    // Reset the MAC state. Session and pending data transfers will be discarded.
    LMIC_reset();

    LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);
    LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);
    LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);

    //LMIC_setLinkCheckMode(0);
    LMIC_setDrTxpow(DR_SF7, 14);
    LMIC.dn2Dr = DR_SF9;

    // Start job (sending automatically starts OTAA too)
    do_send(&sendjob);

→ uses 79% of RAM. (acceptable for us)
→ Communication with the nrf95W seems to work without any issues.
→ The Problem Seems to be on the gateways side:

image
image1640×422 41.3 KB

After “Successfully processed join-request” there is no “Successfully scheduled join accept for transmission” which I saw in other screenshots on the internet.
I Assume the join-accept transmission wasn’t even scheduled and didn’t leave the gateway.
It seems the gateway is fine with my APPEUI, DEVEUI and APPKEY.
Tested with spec 1.0.2 and 1.0.3. Both experience the same problem.

→ Hence the problem must lie on the gateways side, right? My teacher has physical access to the gateway at our school. How can we fix that?

As I understand it has something to do with V2 vs V3 gateways, but I don’t understand exactly what.

Possible duplicate of No Schedule join-accept downlink after successfully processed join request!. Couldn’t however find an solution to this problem there.

Thank you in advance!

2

Nope. The gateway is just a dumb airwaves to tcp (and vice versa) converter. It does not do any processing of the requests.
If your teacher has access, ask him/her to share access to the gateway console with traffic. That allows for a lot easier debugging as you can see if the LNS instructs the gateway to transmit any replies.

3

That may be acceptable to you, but do you know what is acceptable for LMIC on an ATmega328?

4

Hello,

I will be able to provide the gateway logs tomorrow.

For now I got the json data for each console entry.
How to interpret it?

< Redacted >

5

Look around the forum, code & JSON are posted inline using the </> tool to format it.

The volunteers don’t really want to be downloading random files and then opening them up.

Have you read the docs to see what the information contains?

Can you summarise the actual problem without pointing the finger at any other objects that are most likely working correctly otherwise they’d be pointless - ie what’s on your own bench. Because the magic phrase to search for is derived from “Not xxxxx’ing the AAAAA”

And perhaps research the remaining RAM issue - or get a bigger MCU.

6

Our new design uses a mcu with more RAM. We still want to keep the current one tho.

Just tested dynamic RAM usage.
Shows around 400 bytes of free RAM consecutively.
Searched the lmic library for mallocs and news.
Couldn’t find any.

Conclusio: RAM usage should be okay.

We will try it with a faster crystal in our next design. Maybe it’s the clock frequency.

Screenshot from 2023-12-05 16-24-41

7

Alright,

I will reach back once I know more tomorrow.

8

On what basis? There are 10 sorts of memory, you’ve checked one of them.

Nope, not that either. Plenty of people have run LMIC on an ATmega328 for years using a Pro Mini at 8MHz.

You are investigating without articulating the fundamental problem. What is not happening that you can be definitive about rather than speculating about other hardware or systems.

Please format your logs, code & JSON using the </> tool as requested above.

9

how far is the node from the gateway

what is the rssi

10

Read from the top, the OP doesn’t have gateway console access …

11

can be answered with out access to gateway console

once op have access he can answer this

12

avr-size returns the following:

$ avr-size -C --mcu=atmega328p .pio/build/ATmega328PB/firmware.elf
AVR Memory Usage
----------------
Device: atmega328p

Program:   25814 bytes (78.8% Full)
(.text + .data + .bootloader)

Data:       1639 bytes (80.0% Full)
(.data + .bss + .noinit)

$ avr-size .pio/build/ATmega328PB/firmware.hex
   text    data     bss     dec     hex filename
      0   25814       0   25814    64d6 .pio/build/ATmega328PB/firmware.hex

There is enough FLASH and SRAM left.
What other sorts of memory should I consider?

Unfortunately I still don’t have access to the gateway.

However I can share my ttn console logs:

(logs in chronologically reversed order)

Successfully processed join request:

  {
    "name": "ns.up.join.process",
    "time": "2023-12-06T12:24:00.770148783Z",
    "identifiers": [
      {
        "device_ids": {
          "device_id": "eui-70b3d57ed00632b2",
          "application_ids": {
            "application_id": "rtls-test"
          },
          "dev_eui": "70B3D57ED00632B2",
          "join_eui": "E23FB917CE9F837E"
        }
      }
    ],
    "data": {
      "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
      "raw_payload": "AH6Dn84XuT/isjIG0H7Vs3AhG1gVUDI=",
      "payload": {
        "m_hdr": {},
        "mic": "WBVQMg==",
        "join_request_payload": {
          "join_eui": "E23FB917CE9F837E",
          "dev_eui": "70B3D57ED00632B2",
          "dev_nonce": "1B21"
        }
      },
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7,
            "coding_rate": "4/5"
          }
        },
        "frequency": "868300000",
        "timestamp": 3339768355,
        "time": "2023-12-06T12:24:00.534013Z"
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "tgmdragino",
            "eui": "A84041218E244150"
          },
          "time": "2023-12-06T12:24:00.534013Z",
          "timestamp": 3339768355,
          "rssi": -114,
          "channel_rssi": -114,
          "snr": 0.2,
          "location": {
            "latitude": 48.23655082230167,
            "longitude": 16.369894444942478,
            "altitude": 190,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "ChgKFgoKdGdtZHJhZ2lubxIIqEBBIY4kQVAQo6TDuAwaDAjgz8GrBhDBpr6MAiC4sdPNmcMK",
          "channel_index": 1,
          "received_at": "2023-12-06T12:24:00.563057473Z"
        }
      ],
      "received_at": "2023-12-06T12:24:00.564475457Z",
      "correlation_ids": [
        "gs:uplink:01HGZHBH9K2D9GCEE6FRM7SSC0"
      ],
      "device_channel_index": 1,
      "consumed_airtime": "0.061696s"
    },
    "correlation_ids": [
      "gs:uplink:01HGZHBH9K2D9GCEE6FRM7SSC0"
    ],
    "origin": "ip-10-100-6-248.eu-west-1.compute.internal",
    "context": {
      "tenant-id": "CgN0dG4="
    },
    "visibility": {
      "rights": [
        "RIGHT_APPLICATION_TRAFFIC_READ"
      ]
    },
    "unique_id": "01HGZHBHG2QMEAA44X99D8C7RK"
  }

Join-request to cluster-local Join Server succeeded

  {
    "name": "ns.up.join.cluster.success",
    "time": "2023-12-06T12:24:00.580952626Z",
    "identifiers": [
      {
        "device_ids": {
          "device_id": "eui-70b3d57ed00632b2",
          "application_ids": {
            "application_id": "rtls-test"
          },
          "dev_eui": "70B3D57ED00632B2",
          "join_eui": "E23FB917CE9F837E"
        }
      }
    ],
    "data": {
      "@type": "type.googleapis.com/ttn.lorawan.v3.JoinResponse",
      "raw_payload": "IMo54mYdg8phZPkBv5ROJbBCTGy94giSgquK+mHooODI",
      "session_keys": {
        "session_key_id": "AYw/FcU7Lyi0Gj98+fs9TA=="
      }
    },
    "correlation_ids": [
      "gs:uplink:01HGZHBH9K2D9GCEE6FRM7SSC0"
    ],
    "origin": "ip-10-100-6-248.eu-west-1.compute.internal",
    "context": {
      "tenant-id": "CgN0dG4="
    },
    "visibility": {
      "rights": [
        "RIGHT_APPLICATION_TRAFFIC_READ"
      ]
    },
    "unique_id": "01HGZHBHA4NV0CN9FSQX5E8Z1K"
  }

Join Accept

  {
    "name": "js.join.accept",
    "time": "2023-12-06T12:24:00.580584992Z",
    "identifiers": [
      {
        "device_ids": {
          "device_id": "eui-70b3d57ed00632b2",
          "application_ids": {
            "application_id": "rtls-test"
          },
          "dev_eui": "70B3D57ED00632B2",
          "join_eui": "E23FB917CE9F837E",
          "dev_addr": "260B435E"
        }
      }
    ],
    "origin": "ip-10-100-7-232.eu-west-1.compute.internal",
    "context": {
      "tenant-id": "CgN0dG4="
    },
    "visibility": {
      "rights": [
        "RIGHT_APPLICATION_TRAFFIC_READ"
      ]
    },
    "unique_id": "01HGZHBHA4CKD6TPS0TJEQCXAM"
  }

Send join-request to cluster-local Join Server

  {
    "name": "ns.up.join.cluster.attempt",
    "time": "2023-12-06T12:24:00.567025860Z",
    "identifiers": [
      {
        "device_ids": {
          "device_id": "eui-70b3d57ed00632b2",
          "application_ids": {
            "application_id": "rtls-test"
          },
          "dev_eui": "70B3D57ED00632B2",
          "join_eui": "E23FB917CE9F837E"
        }
      }
    ],
    "data": {
      "@type": "type.googleapis.com/ttn.lorawan.v3.JoinRequest",
      "raw_payload": "AH6Dn84XuT/isjIG0H7Vs3AhG1gVUDI=",
      "payload": {
        "m_hdr": {},
        "mic": "WBVQMg==",
        "join_request_payload": {
          "join_eui": "E23FB917CE9F837E",
          "dev_eui": "70B3D57ED00632B2",
          "dev_nonce": "1B21"
        }
      },
      "dev_addr": "260B435E",
      "selected_mac_version": "MAC_V1_0_3",
      "net_id": "000013",
      "downlink_settings": {
        "rx2_dr": 3
      },
      "rx_delay": 5,
      "cf_list": {
        "freq": [
          8671000,
          8673000,
          8675000,
          8677000,
          8679000
        ]
      },
      "correlation_ids": [
        "gs:uplink:01HGZHBH9K2D9GCEE6FRM7SSC0"
      ],
      "consumed_airtime": "0.061696s"
    },
    "correlation_ids": [
      "gs:uplink:01HGZHBH9K2D9GCEE6FRM7SSC0"
    ],
    "origin": "ip-10-100-6-248.eu-west-1.compute.internal",
    "context": {
      "tenant-id": "CgN0dG4="
    },
    "visibility": {
      "rights": [
        "RIGHT_APPLICATION_TRAFFIC_READ"
      ]
    },
    "unique_id": "01HGZHBH9QB2CMQ78BY8D8G30Q"
  }

Receive join-request

  {
    "name": "ns.up.join.receive",
    "time": "2023-12-06T12:24:00.566990750Z",
    "identifiers": [
      {
        "device_ids": {
          "device_id": "eui-70b3d57ed00632b2",
          "application_ids": {
            "application_id": "rtls-test"
          },
          "dev_eui": "70B3D57ED00632B2",
          "join_eui": "E23FB917CE9F837E"
        }
      }
    ],
    "data": {
      "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
      "raw_payload": "AH6Dn84XuT/isjIG0H7Vs3AhG1gVUDI=",
      "payload": {
        "m_hdr": {},
        "mic": "WBVQMg==",
        "join_request_payload": {
          "join_eui": "E23FB917CE9F837E",
          "dev_eui": "70B3D57ED00632B2",
          "dev_nonce": "1B21"
        }
      },
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7,
            "coding_rate": "4/5"
          }
        },
        "frequency": "868300000",
        "timestamp": 3339768355,
        "time": "2023-12-06T12:24:00.534013Z"
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "tgmdragino",
            "eui": "A84041218E244150"
          },
          "time": "2023-12-06T12:24:00.534013Z",
          "timestamp": 3339768355,
          "rssi": -114,
          "channel_rssi": -114,
          "snr": 0.2,
          "location": {
            "latitude": 48.23655082230167,
            "longitude": 16.369894444942478,
            "altitude": 190,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "ChgKFgoKdGdtZHJhZ2lubxIIqEBBIY4kQVAQo6TDuAwaDAjgz8GrBhDBpr6MAiC4sdPNmcMK",
          "channel_index": 1,
          "received_at": "2023-12-06T12:24:00.563057473Z"
        }
      ],
      "received_at": "2023-12-06T12:24:00.564475457Z",
      "correlation_ids": [
        "gs:uplink:01HGZHBH9K2D9GCEE6FRM7SSC0"
      ],
      "device_channel_index": 1,
      "consumed_airtime": "0.061696s"
    },
    "correlation_ids": [
      "gs:uplink:01HGZHBH9K2D9GCEE6FRM7SSC0"
    ],
    "origin": "ip-10-100-6-248.eu-west-1.compute.internal",
    "context": {
      "tenant-id": "CgN0dG4="
    },
    "visibility": {
      "rights": [
        "RIGHT_APPLICATION_TRAFFIC_READ"
      ]
    },
    "unique_id": "01HGZHBH9PEKVKSAXYNRX6Z3GH"
  },
  {
    "time": "2023-12-06T12:23:34.952Z",
    "name": "synthetic.status.cleared",
    "isError": false,
    "isSynthetic": true,
    "unique_id": "synthetic.1701865414952"
  }
]

When I compared my logs to those of other forum members I discovered, that in my logs, there is no “Successfully scheduled join accept for transmission” after “Successfully processed join request”.

I assume it is the join-accept response, that should be scheduled, if everything works correctly, right?

So either I am not sending the right data so the join-accept response can’t be scheduled or the issue lies somewhere else…

13

I do not have access to the gateway yet.

However:
Uplink RSSI can be extracted from the ttn console logs shown above.
I don’t receive any join-accept message so something is wrong with the receiver or there is no join-accept transmission at all. Thus I can’t provide a downlink RSSI value.

uplink rssi: -114dBm
uplink signal to noise ratio: 0.2

Both values seem pretty bad.

The distance to the gateway is around 40 meters.
It should be put into account, that we are in a building with pretty thick walls.

14

It could be, but what incentive is there for the volunteers to do your work for you?

Looks like something may be fermenting but you haven’t quite tried the magic formula suggested above.

If you are only 40m away from the gateway, that’s a pretty poor signal - what is your antenna?

15

Sorry for the inconvenience. I should’ve expressed myself in a better way.

We first tried a coil wire and then a proper lambda/2 antenna.

Both delivered the same result so we switched back to the coil wire.

I will try the magic formula. : D

16

My friend tried it with another gateway at another location.
Now the console log looks much better:

image
image1438×441 25.1 KB

It indeed seems that the gateway was at least a part of the problem.

So as I understand the gateway might be for an older version of the things stack.

And for this reason it doesn’t support any/some new devices?

Is there a way to create a device for the older version of the things stack.

But the best way would be to replace/upgrade the gateway at our school, right?

17

Still a supposition - please stop guessing.

No such thing.

As Jac said above, they are just dumb media convertors - if the electromagnetic radiation is LoRa shaped, it takes it, sticks it in a UDP packet and sends it up the line. They have no knowledge of how that EMR was created so can do nothing other than pass it on.

There are no older versions of TTS - just the current one - unless you chose to run your own older version, which you aren’t, so this is another dead end.

No. There is no data on what was going on with the school gateway and I have gateways that are 3 years old that migrated to v3 without any upgrade beyond the URL.

Your RSSI was pathetic on a device that is pathetic with a really pathetic antenna. The answer to the “Not xxxxx’ing the AAAAA” crossword puzzle is “Not receiving the Join Accept”.

Which, when you search for that magic phrase, comes up about once a week on average, but usually without quite so much Noise in the Signal from advanced guess work.

So I may as well tell you, but there are 10 sorts of memory - permanent (Flash & EEPROM) and static aka RAM - and for LMIC you will need about 800 bytes free for the stack which you no doubt know is allocated on a function call. You may get away with 750 bytes. But mostly not. Depends on nesting of calls for payload generation.

With care, you can use LMIC on an ATmega328, but it’s making a hard job harder. Using an ATmega4808 (48K Flash so room for your code and 6K RAM (3x more)) works like a charm.

To succeed as an engineer you have to look at all possibilities and not hyper-focus on something out of your control that is likely to be working otherwise it wouldn’t be running. And learn the fundamentals and what the current best practises are. Other wise you will be permanently struggling.

18

I think you seriously need to study lorawan before making any more assumptions. I’ve been working with lorawan and TTN for 7 years and I haven’t encountered one LoRaWAN gateway that works for older versions of the things stack and does not work with V3.
As author of software for gateways I see no technical reason why a LoRaWAN gateway that worked with previous versions of TTN would not work with the current version, except if it would be running the obsolete TTN packet forwarder which it isn’t because you see data arriving at TTN.

19

Alright.
Thank you for the profound explanation of things.

So basically from what I understand:
PROBLEM 1:
Okay, If it really wasn’t the gateway then it most likely is the potato antenna on our transceiver combined with the seemingly very RF unfriendly environment at our school. RSSI at my friends place is around -97 which is better.

PROBLEM 2:
I forgot to take the incrementations of the stack pointer by the size of the newly pushed local variables when calling functions into account. LMIC uses many nested function calls & pretty large functions which increase stack size. I assume this is difficult to track unless taking stack measurements directly inside of those functions. (Or have enough space, but then it isn’t a problem any more.)

In order to get it running on an ATmega328 either I would have to carefully edit the LMIC library or instead of the example code configure LMIC directly?
(We already ordered boards with better MCUs tho. We might as well just use the other mcu on our board which is an EFR32.)

Thank you for your time.
Lesson learned.

I would like to kindly inform you however that we students are people who enjoy direct communication. Thus we would highly appreciate if our questions were answered more directly, allowing both sides to use their time more efficiently.

Unless the wise enjoy to provide us with riddles on our path to expertise of course. : D

20

Thanks for the recommendation.

I will read the LoraWAN documentation and try to understand it as profoundly as it is possible, in the relatively short time-period I have, for it is a pretty interesting topic, I must say.

Thank you for your time.