Wifi/BLE Paxcounter Project with ESP32 boards

Symptom seems to be the same.
Loosening LMIC timing does not solve this.

There is a new experimental paxcounter version in branch ā€œss_oledā€ of repository.

Itā€™s based on a different OLED library, which gives more performance and graphics features. At first two new features were added:

  • DEVEUI is displayed as QR code while device starts (to easy capture it with a smartphone QR reader)
  • a pax count curve plotter (press device button to flip display pages)

Paxcounter v1.9.6 was released:

v1.9.6

Added features:

  • LORA DEVEUI is displayed as QR code while devices starts (for taking photo and resolve it)
  • display contrast lowered to reduce OLED degradation
  • added display page showing pax curve diagram
  • added blank display page (use as screen blanker)
  • full AXP192 power management support (use with T-Beam V10)

Maintenance fixes:

  • platformio esp32 v1.11.0 (ESP-IDF SDK v3.2.3)
  • Wifi/BT software coexist version 1.1.7
  • Arduino LMIC version 3.0.99.5
  • new OLED driver (smaller footprint & with graphics capability), replacing u8x8
  • fix TTN join RX2 settings (now SF9, was SF12)
  • enabled LMIC hardware interrupts for more precise timing
  • some smaller bug fixes
4 Likes

Is the case your design? Can you please share stl files because it looks awesome!

Thanks to a Pull Request a new feature / use case was added to paxcounter software: Opensensemap Integration.

See readme in paxcounter repo.

1 Like

See this demo mobile paxcounter node mobile counting pax density in opensensemap

1 Like

Firstly, well done on a great coding project, thank you for contributing it. It has been very inspiring as an example of what the Heltec can achieve.

We are looking at a similar project to [frasanc1 : Wifi/BLE Paxcounter Project with ESP32 boards ], and needing to minimise power use to match what a 30W solar panel produces on these dull winter days in England. We have a BH1750 light sensor on a TTGOv1 without OLED and I measure 120mA with wifi on and 48mA with wifi disabled (rcommand ā€œ0x17 0ā€) Looking at the current code I donā€™t see a ā€˜deep-sleepā€™ function. Am I missing it, or is there any progress on incorporating one?

Many Thanks, Mike

Look in reset.cpp, there you find a function enter_deepsleep() which you can use.

1 Like

Thank you for that tip. It does sleep and wake up on timer, then resumes sending, but I donā€™t see the data on the TTN console. I note that in reset.cpp there is a TBD of saving & restoring the settings before & after deep sleep. I see the need for this, but not sure of the way to find the data. Maybe some has already got a function for this.

Thatā€™s right, after wake up we need to re-set the parameters and counters for the LMIC stack. Look here, at the bottom, for an example how to code this.

1 Like

Another source look here

Thank you for that link, I had discovered it via your previous suggestion and have deep-sleep running and awakening with send working from that git example. My challenge is to incorporate their store and retrieve function into the PaxCounter as it relies on a different set of libraries, and some functions are named the same but with different purpose (eg, sensor loadState). Stripping out the surplus code without breaking the compile has beaten me so far.

I also found a set of functions, including NetSave and NetLoad in the MCCI library that PaxCounter is already using and wondered about using them.

I donā€™t want to burden you with my need to learn more about this, but it would be great to show how low PaxCounter can go on the power use front, and I feel I am very close now.

Could you please make a PR to paxcounter repo with your approach? I openend up the branch deepsleep, where you can push your code.

I think itā€™s important to stay at the master release of MCCI LMIC stack, because it is so far well maintained and is close to LoraWAN compliance certification by the maintainer. Thus, i donā€™t want to use a modified fork of LMIC for paxcounter.

1 Like

I agree that sticking with the master MCCI LMIC stack is important. The one I found hooks to NetSave within is https://github.com/mcci-catena/arduino-lorawan/blob/master/examples/simple_feather/simple_feather.ino but it needs the code to do the actual saving on our hardware. Iā€™m not clear yet how this arduino-lorawan lib varies from the arduino-lmic one we are using now.

My current code is very not suitable for a PR yet, I just added rcommand 0x05, and linked to the do_after_reset(DEEPSLEEP_RESET); in the existing reset.cpp. I will certainly post when it is as I have two custom sensors working well.

And please have in mind that on arduino-esp32 platform millis() is not advanced after wake up from deepsleep. This will cause LMIC problems. So we need to save millis() before going to sleep and advance it after wake up by using time diff from RTC.

That is where ngrazianoā€™s wake code gets a bit deep in the libs for OsDeltaTime which has dependencies on most of the joining etc libs. It works as a standalone example but Iā€™m struggling to bring the methods into PaxCounter. I prefer not to try adding PaxCounter to the deepsleep instead, as PaxCounter code is written to be more flexible across more hw platforms and clearer to understand imo.

The paxcounter code grew a long time with step by step enhancements, but i never had a clear roadmap for it. Thus, there sure is a refactoring missing. On the other hand it now seems to have reached a level where it runs pretty stable. I have a device which has an uptime of months and reached more than 100.000 packets.

Indeed, it is a great app and an amazing achievement. My desire for deepsleep is an edge case and if I had more experience of the ESP32 libraries and especially working with NVRAM then I would have avoided some of my cul-de-sacs in a coding sense. I am busy studying the examples deeper and hope to make a positive contribution soon rather than just asking silly questions. Thanks for the inspiration. - Mike

Some paxcounter news, regarding time synchronisation.

I reworked the timesync code last days, the result is:

  • a major bug fixed was fixed, which could have caused wrong time in some edge cases :slight_smile:
  • tested and finalized code for featuring the new LoraWAN 1.0.3 timesync protocol (using MAC command DevTimeReq/Ans)*
  • sanitized the code to improve readability and maintenance

*) DevTimeReq/Ans currently not supported by TTNv2 network servers

Current software is here.

Meanwhile paxcounter grew up to a multisensor - multitasking platform. Maybe itā€™s time for some refactoring, which brings the platform to the foreground, and the paxcounter application is just one use case for it. What do you think?

1 Like

Hi everyone, a beginner question.
is it possible to set the rssilimit without lorawan?
I want to change the Scan Radius to 1m.
I try to change the configmanager.cpp with no luck.
Thanks a lot.