# Wifi/BLE Paxcounter Project with ESP32 boards

**URL:** <https://www.thethingsnetwork.org/forum/t/wifi-ble-paxcounter-project-with-esp32-boards/13175>\
**Category:** End Devices (Nodes)\
**Created:** [March 18, 2018, 5:02pm UTC](https://www.thethingsnetwork.org/forum/t/wifi-ble-paxcounter-project-with-esp32-boards/13175 "2018-03-18T17:02:09Z")\
**Posts on this page:** 1\
**Showing post:** 404

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [June 8, 2019, 4:35pm UTC](https://www.thethingsnetwork.org/forum/t/wifi-ble-paxcounter-project-with-esp32-boards/13175/404 "2019-06-08T16:35:34Z")

</div>

> [@Amedee](#):
>
> I was expecting to see a packet counter roll-over at 64K, but is still counts up…

As an aside, if you really expected the counter to rollover:

> [@After resetting frame counters, payload is shown on gateway traffic but not in application](https://www.thethingsnetwork.org/forum/t/after-resetting-frame-counters-payload-is-shown-on-gateway-traffic-but-not-in-application/19331/12):
>
> In LoRaWAN 1.0.x, the value of `FCnt` only holds the 16 least-significant bits (LSB) of the actual frame counter. But for a 32 bits frame counter still all 32 bits are used when calculating the MIC. So, the server needs to guess or try the other 16 bits when validating the MIC. The server can use its own internal counters for a best guess. And due to the maximum allowed gap between the last known value and current value, the server needs to try, **and [will try](https://github.com/TheThingsNetwork/ttn/blob/master/utils/fcnt/fcnt.go#L16)**, only one additional value for the MSB.

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/wifi-ble-paxcounter-project-with-esp32-boards/13175)._