Uplinks not showing up in application data when payload is not empty

1

Hi,

I’m currently having some issues getting data into my application as it stops showing up in the app console as soon as I start sending a payload with some bytes in it.

My program is a (lightly) modified version of the I-Cube-lrwan software v1.2.0

let me first explain the program, you can go ahead and ignore this part if you want to jump to the actual problem:

My nodes are joining in OTAA mode, and then start pinging the server with blank payload until they get a downlink containing a timestamp (the timestamp will obviously not be the real time but this is not required for the project I have in mind)
Once they do get the timestamps, the nodes then use it in order to send their uplinks during the night every 2 days (so basically maximum 3 unconfirmed uplinks every week). Of course during testing sessions, it sends the data every 30 seconds for me to check if everything is working as planned.
The nodes will be monitoring the fouling speed of ventilation shaft, hence the maximum 3 uplink/week.

Now to get to the problems i’m encountering right now, until the node receive the downlink, it sends blank payload (on Fport 0 instead of the port 04 asked but I suppose it’s normal behaviour when sending no payload? When sending something it shows up with the correct port) which are correctly displayed both in the gateway console data, and in the application data.

app_data

But when the actual payloads is sent, it appears that messages from the nodes are correctly forwarded by the gateway (as seen in the gateway data), but not in the application (app console does not show any data and the node status is not updated)

app_data

The data is sent on Fport 04 as shown in the LoRaWAN 1.0.x packet decoder, so i don’t think it’s an issue related to other people having issues with the i-cube-lrwan software and fport0 data…

Am I missing something obvious here?

I know there are some issues with my implementation so feel free to point me out if i made something really bad here :frowning:

Thanks in advance,

example of data received according to the gateway console:

Prior to downlink reception, forwarded to the app = 402A2E0126800100006287970A73
After downlink reception, not forwarded to app = 402A2E01268103000D0402F7F9C4A264

2

try to change the port number instead of 0

3

Already tried that, i’ve also tried to insert one 0xFF bytes in the void payloads and it just goes to no data forwarded to the app console, so far i’ve only successfully seen uplinks with no data in it (which i guess are considered as fport 0 because i’m normally sending everything on port 4)

Which means that as soon as i try to send any form of data, its stop to be forwarded to the app console even though it clearly appears inside the gateway console?

4

there are more topics at the moment about ’ data not showing up in application ’ mostly when using AU handler but you’re in France.
I don’t know… maybe @arjanvanb can point you in the right direction

what if you don’t send confirmed ?

5

Thanks for your help,

I’m currently not asking for confirmation by the server (un-confirmed uplinks), did you mean try with confirmed uplinks? I could try that !

I’ve spent some time wandering in the forum about these topics, but so far i’m still clueless about what is causing this issue…

But i’ve seen quite a few people getting problems with the I-Cube-Lrwan stack so I wonder if the problem is not burried inside the stack…

As a last resort i’ll try to port my program to other versions of this stack (currently 1.2.0), but since ST does not provide much info about changes from one version to another…

Edit: Asking for confirmed uplinks does not change the behaviour, as soon as there is something in the payload it stops getting shown in the app console

6

That includes FOpts = 0x0D, being a DeviceTimeReq which might be causing display issues. Use the MQTT Data API to see if you receive the data. Also:

Or do not ask for DeviceTimeReq, as you’ve implemented your own protocol for that anyhow. As for synchronising time, see also Time synchronisation of a Node - #28 by arjanvanb.

I’d say that’s an invalid packet, as it defines a payload of 0x62 and uses FPort 0. So, this payload should be a MAC command, but it’s undefined?

In the case of an empty payload, maybe FPort 0 is okay. But even then the specification is open for multiple interpretations, maybe expecting at least one MAC command:

If present, an FPort value of 0 indicates that the FRMPayload contains MAC commands only.

2 Likes
7

Sorry for not coming back to your hint before, I was in holidays :smiley: (by the way happy new year!)

It appears that FOpts = 0x0D was asked natively in the v1.2.0 stack of i-cube-lrwan, as shown here:

 /*!
 *  Select either Device_Time_req or Beacon_Time_Req following LoRaWAN version 
 *  - Device_Time_req   Available for V1.0.3 or later                          
 *  - Beacon_time_Req   Available for V1.0.2 and before                        
 */
#define USE_DEVICE_TIMING

defining this variable will compile the following code

#if defined( USE_DEVICE_TIMING )              
              LORA_DeviceTimeReq();
#else              
              LORA_BeaconTimeReq();
#endif

(this code can be found in the lora.c file)

I’m not so sure of what will change when asking for BeaconTime instead so i’ll be sure to check for any unexpected behaviour, however the problem asked in this topic now appear to be solved (as message are now correctly forwarded into the app!)

Thanks a lot to both of you, i’ll be sure to get back if any unexpected things happen during my tests, and i’ll also try to dig up why my empty payload comes with an undefined mac command…