Heltec Cubecell: downlink messages of unknown origin

niehaus · September 12, 2020, 9:54pm

I got a Heltec Cubecell board to use it as a ttnmapper together with my mobile phone.

I took the the example code “LoraWAN” for the Heltec Cubecell board and modified it so it sends a null message (appDataSize = 0;). LORAWAN_NETMODE is set to OTAA, LORAWAN_UPLINKMODE is set to UNCONFIRMED, ADR is off since the node is intended to move around. Region is EU868

When I start the node the uplink works as expected. But every uplink (“payload not provided”, as intended, airtime about 42 ms) is followed by a downlink transmission, airtime slightly above 700 ms. Payload is 907 times the letter “B”.

Serial monitor says repeetedly: “unconfirmed uplink sending …”

Hmm.

This is not what I expected but as a newbie I have no idea where this behavior might come from.

Any hints what I might do?

(ttnmapper works with this setup but I do not want to create that much downlink activity wherever it comes from …)

Thank you!

arjanvanb · September 13, 2020, 10:00am

Where are you seeing that? I assume only in the serial monitor, but not in TTN Console?

That is far above the LoRaWAN limit of 235 bytes for the total packet size (in best conditions for EU868). And as far as I know that 235 bytes is based on LoRa limits. So, this cannot be a downlink originating from TTN. As it’s not originating from TTN, your device should also not be able to validate and decrypt it, so the LoRaWAN stack on your device should not have bothered your application code with that.

So either the LoRaWAN stack on your device is doing something wrong, or your own code is erroneously thinking it got a downlink. For the latter you’re probably just seeing the random contents of some memory location. (Hexadecimal 0x42, not to be interpreted as the letter B.) So, time to show the code!

niehaus · September 13, 2020, 10:40am

Sorry for not mentioning this: I see this in the TTN console: I see my gateways traffic (and the airtime) and in the allication/devices section i see the traffic (no payload in uplink and weird payload in downlink).

I see this downlink message as a response to an uplink message in the TTN console.

My application code does ot exist yet At the moment I “need” just an empty uplink for tthmapper.org

I can show the code later (I am not on my development computer right now) but the problem might be somewhere else.

Thanks!

kersing · September 13, 2020, 11:27am

What port is the downlink directed to?

What SF is your uplink?

arjanvanb · September 13, 2020, 1:18pm

Screenshot or it didn’t happen.

Also, please click the uplink and downlink to see if there’s anything in the metadata and trace. And please provide the full LoRaWAN payloads (as text) of both uplink and downlink, as received by the gateway.

niehaus · September 14, 2020, 7:04am

Uplink (Application):

{
  "time": "2020-09-14T06:55:09.613336144Z",
  "frequency": 867.9,
  "modulation": "LORA",
  "data_rate": "SF7BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "gtw_id": "eui-3235313219003a00",
      "timestamp": 1948256518,
      "time": "2020-09-14T06:55:09.583777Z",
      "channel": 7,
      "rssi": -64,
      "snr": 8.5
    },
    {
      "gtw_id": "eui-a84041ffff1ea684",
      "timestamp": 1837111292,
      "time": "2020-09-14T06:55:59.541935Z",
      "channel": 7,
      "rssi": -124,
      "snr": -4.5,
      "latitude": 52.36004,
      "longitude": 10.43419,
      "altitude": 95
    }
  ]
}

Downlink (Gateway):

{
  "gw_id": "eui-3235313219003a00",
  "payload": "oDJfASYACQABcaYgPBz/5PJdzTpw2lwSUg9xLkZf/Nu61u8tTT/NRwl/JKxk5rvfjwNeTZxhqp98WnA9ypEW38YLVutZGuzIZfoMAT571FjO1y5/3rcocnPQs+R9WWZ/OHFgUXQXpICbPitiJDqecQFhTiXW1RI3/fcrPaaMKgaCgeRachLAPKIbiwhpIcIQc9pcbVeN180Ky3k4SekPTD9d3YkjBAjNPyg76lDWNNinLOoFa13ks9vVx/13WqxV9boIbXcGMpETjWx4JzJWoOIP2Ws7CMYdlQeAA8IyZEPaG3XCPNe1fUNje8EvBbH4YFCJf0ktILERNaQOKMI7tIW8sEsiyTvjdz1++tDaXtdGtDxhFiTentyrYXoH1t1rG1juMuDRzCNNxcDWQMlWT+E/1Z+1h2Ke1HfYq7j2eEUH/maSYTFoe35TV8GH1+gw/8DcnQIbjhOL/s11rioCi0aotPwAS1+vq51zH4Uh8PAtvDc2d+Sxq+K+T0lyWVOfpPJQedPOvN38grimx7sTzI+BM/DVoJktlCe2LqC8WGiUY7rNstNj3Ady9vmlh6gxqc4Zes8ioeVtDPlz0b3Uc/IprQtRV1cbc8nlEiHMtClCOA==",
  "f_cnt": 9,
  "lora": {
    "spreading_factor": 7,
    "bandwidth": 125,
    "air_time": 706816000
  },
  "coding_rate": "4/5",
  "timestamp": "2020-09-14T06:54:07.947Z",
  "dev_addr": "26015F32",
  "frequency": 868100000
}

Uplink (Gateway):

{
  "gw_id": "eui-3235313219003a00",
  "payload": "QDJfASYAJABx8QOV",
  "f_cnt": 36,
  "lora": {
    "spreading_factor": 7,
    "bandwidth": 125,
    "air_time": 41216000
  },
  "coding_rate": "4/5",
  "timestamp": "2020-09-14T07:01:07.180Z",
  "rssi": -65,
  "snr": 9,
  "dev_addr": "26015F32",
  "frequency": 868300000
}

niehaus · September 14, 2020, 7:05am

Port 1

SF7, Bandwidth 125.

niehaus · September 14, 2020, 7:08am

This is the Downlink (Copy and paste from Application data)

BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

arjanvanb · September 14, 2020, 8:30am

Wow!

First, not related to your problem:

It’s actually 466 times the byte 10111011, which is decimal 187, or when displayed in hexadecimal is 0xBB. See Working with Bytes. Still then, 466 very much exceeds the maximum of 235 bytes (in best conditions, and if the region’s legal requirements allow for that) as well.

Also, since it’s a confirmed downlink: if the device does not acknowledge receiving it, TTN will repeat it after the next uplink, and so on. We would need the full LoRaWAN packet from the uplink from the gateway to see if it’s trying to acknowledge it ~~,but I’m afraid not, as the downlink counter is not being incremented~~. (Also, I think the screenshot would have shown some “ack” then, like it shows “confirmed”.) I’d guess that the gateway will just refuse to send this erroneous downlink.

I think you did not see the downlink being reported in the device as well?
Did you ever schedule a downlink yourself? Do you think you may have entered that 0xBBBBBB yourself? (If not, we need to report this elsewhere, so important to know.) Anything in your application that schedules downlinks?

To solve it, I assume you can replace the faulty downlink with another: go into your device’s Overview, scroll down to Downlink and make sure to select “replace” and not enable “Confirmed”. Just enter some dummy value (remember: it’s hexadecimal in that input).

bluejedi · September 14, 2020, 8:44am

Aside, be aware of the following: IIRC uplink confirmations are enabled by default in the CubeCell software / BSP which is very bad.

Confirmed uplinks should be enabled only when absolutely required and after careful consideration (due to severe restrictions on max number of downlink messages per day).

I have not checked recently and hopefully Heltec has already fixed this issue by now (but I would not be surprised if the issue is still present).

If the issue is still present then confirmation of uplinks should be explicitly manually disabled in the configuration.

BSP is short for board support package. This is the Arduino framework/IDE support for a certain board and is usually part of the Arduino Core for a certain microcontroller family.

niehaus · September 14, 2020, 11:01pm

Thank you! This was indeed the problem

and this was the solution.

After yo made me able to understand the problem I was thinking about gateways enforcing the duty cycle limit or the fair use limit. What I observed could easily be used as an Denial-of-Service-Attack on an gateways ability to transmit messages by consuming its airtime with pointless traffic.

Maybe time to implement some kind of TTL (time to live?). Not very sure about it …

I think, my device is too dumb do recognize an downlink - probably it is just discarded. (to be honest, its not the device which is dumb but probably its owner but this is another story …

Yes, I might have been playing with downlink messages some time ago without fully understanding its implications …

Yes, once you have chosen the Heltec Cubecell Board in the Arduino IDE you have several menus where you have many choices concerning the setup of several LoraWAN parameters. Confirmed uplinks are default (but I was quite sure I deactivated this feature before compling).

Anyways, I don’t like these menus with that much, i would prefer to set the options in the source code. Being new to anything arduino-related and programming related this is not trivial for me but at least for some parameters it should not be too difficult …

Thank you very much, guys!