search

TheThingsArchive / ttn

The Things Network Stack V2
https://www.thethingsnetwork.org
MIT License
461 stars 276 forks source link

Estimated airtime in TTN Console's gateway traffic and application/device data do not match #646

Closed avbentem closed 3 years ago

avbentem commented 7 years ago

This is a bug report for the console.

What do you want to do?

Get the correct estimated airtime of a packet in TTN Console.

What steps did you take?

Sent a 21 bytes packet (8 bytes application payload) on SF7. For this, the LoRaWAN air time calculation sheet at https://www.thethingsnetwork.org/forum/t/spreadsheet-for-lora-airtime-calculation/1190 shows 56.576 ms airtime. Also, the gateway's traffic page shows: "airtime (ms) = 56.6 ms".

(When repeating with 17 bytes total, being 4 bytes application payload, the sheet calculates 51.456 ms, and the gateway then shows 51.5 ms too.)

What went wrong or what is missing?

For 21 bytes, the application's and device's data pages show "Estimated Airtime = 51.456 ms" instead of 56.5 ms like the gateway does.

It seems 2 bytes too few are taken into account for the estimation? For 19 bytes, the calculation sheet indeed shows 51.456 ms.

(When repeating with 17 bytes, the application and device data show 46.336 ms, while the gateway shows 51.5 ms. Again: like 2 bytes fewer were used for the calculations, as for 15 bytes the sheet indeed shows 46.336.)

Do you have Screenshots?

Gateway:

image

Device:

image

...after scrolling down:

image

Airtime calculator:

image

What kind of OS/Browser/Gateway are you using? Which version?

Mac OS X, Chrome, single-channel test gateways.

What are the IDs and EUIs of your Device/Gateway? (if applicable)

What do your configuration files look like?

n/a

What do your log files look like?

n/a

Can you fix this yourself and submit a pull request?

Maybe, if you open source the code ;-)

romeovs commented 7 years ago

@jpmeijers Can you have a look why this is wrong?

johanstokking commented 7 years ago

Isn't this fixed @Ragnn @romeovs ?

romeovs commented 7 years ago

Not yet. I'll work on it soon. @Ragnn added the backend part, but the front-end needs to be updated to reflect that.

romeovs commented 6 years ago

This should be fixed by fe151b7f53. Can you confirm @avbentem?

htdvisser commented 6 years ago

@romeovs: This issue is still not resolved (as far as I can see on the PCN console).

Take as an example the office-app. Our sensor at HQ should show an airtime of 51.456. The gateway view shows the correct value, but the Data view doesn't.

Today I started with the implementation of #682, which adds the airtime to uplink (and downlink event) metadata. When deployed, that value can be displayed in the console.

romeovs commented 6 years ago

The estimated airtime shown in the console is calculated by the github.com/TheThingsNetwork/ttn/utils/toa package. Could it be that the parameters are interpreted wrongfully?

htdvisser commented 6 years ago

Both values are calculated by the console. One is correct, another isn't.

screen shot 2017-11-09 at 12 12 08
romeovs commented 6 years ago

Coule it be that the console gives the wrong parameters to the toa package? https://github.com/TheThingsIndustries/console/blob/master/server/api/events/app_subscription.go#L302-L305

Difference between PHY payload and application payload could be the cause? If so, how to get the PHY payload length?

htdvisser commented 6 years ago

Likely. In that case it can be resolved when https://github.com/TheThingsNetwork/ttn/commit/0f795e39c6f00b663f70212595de09cf4f2c92a4 is live

stevmei commented 6 years ago

Is this still unsolved? I'm seeing some differences and I think the application estimated airtime is wrong.

Sending 38 byte of app payload, resulting in 51 byte payload in the gateway overview:

grafik

In the application:

grafik

And this is calculated with the Semtech LoRa Model Calculator Tool:

grafik

kizniche commented 5 years ago

I recently had The Things Network stop the movement of all my data from my gateway to my apps due to going over the 30-second daily limit (not just the offending app/device, but all of my devices, even the ones not exceeding 30 seconds/day). This was due to using the app airtime estimate. Using the gateway airtime (which was significantly greater than the estimated airtime in the app), data began appearing in my apps again. I see reporting incorrect airtime (or calculation) as a significant bug.

Additionally, is it expected behavior for data from all apps to cease operating when one device exceeds the daily transmission limit?

htdvisser commented 5 years ago

Hi @kizniche, the 30-second daily limit is not enforced; we don't even have any code to do that, so I can with 100% certainty say that the lack of traffic was not caused by this.

kizniche commented 5 years ago

Thank you for the clarification. Perhaps it's just a coincidence they all stopped. I'll have to investigate further.