Wifi/BLE Paxcounter Project with ESP32 boards

Hello guys, managed to connect the PAX counter this is awesome.
Some questions:

  • should I set the frame counter to 16 or 32 bits?
  • should I check reset frame counter flag?

Cheers.

I would recommend to use 32 bits. By default the PAX counter is using OTAA, thereof switching off frame counter check is not required.

Correct. Even more: it’s not so much a choice. This project uses the MCCI LMIC library, and that uses 32 bits counters. For any LoRaWAN device, the settings on the device and in TTN Console must match.

2 Likes

Hi,
I have a TTGO T3_V1.6 module and installed the latest Paxcounter on it following the given instructions.

But I have some questions for which I wasn´t able to find any answers so far.
Hopefully you can help me here.

  1. The pages shown on the OLED-display of my module look totally different to all the pictures shown here. Are the pictures just outdated or is there something wrong with my installation? At least some of the pages shown match the description of the addded features in v1.9.6 - a page with a QR code and the text DEVEUI and I can see on one page a tiny curvy line that could be the pax curve diagram.

  2. There are 3 LEDs on the module. Blue, red and green. What do they indicate? Blue and red are glowing permanently when the module has power, green is blinking very fast.

  3. It looks like I dont have a LoraWAN gateway in range. On one page I see a message “JOIN_WAIT” all the time. Is there a way to transfer the pax data via USB to a connected PC instead of using LoraWAN?

  4. I have a SD card installed but the written file only contains date, time and number of pax counts. Is there a way to continuesly write the encrypted addresses of all the devices found?

Thanks in advance

Best regards

Tim

  1. pics in readme.md are outdated. you’re welcome to make a PR to updatr pics

  2. blue: power, red: gps fix, green: paxcounter, see readme.md. Green fast flashing means no join yet

  3. not yet, but you could easyly build this on your own based on mqttclient.cpp in current version (which works on Eth, not uart)

  4. intentionally not, because we don’t want to persistently store personal data.

2 Likes

Hi there,
thanks for the great paxcounter project!
I´m working on a wildlife | human recreation project in Austria and would like to use
paxcounter to measure human recreation in the forest. My heltec and ttgo nodes are running solar powered. I would like to use the LoraWAN 1.0.3 timesync protocol but can´t get it to run.
In the paxcounter.conf the TIME_SYNC_LORAWAN is set to 1. What else do I have to do?
Thanks for your help!

Greetings from Austria,
Robin

You either need a Lorawan server / provider, which / who supports DevTimeReq (TTNv2 unfortunately doesn’t), OR you install an own time server on application level. Both modes are supported by paxcounter, study the readme.md for details.

1 Like

Released v2.0.1 today.

New features (selected):

  • Covid-19 exposure notification system device counter
  • Timesync using MAC DevTimeReq
1 Like

I have updated my Paxcounters to the new release.
As some of those also use the TTNMapper integration, i had to modify the Port Filter to port 1 and not port 4 as set before.

Propably a change in the paxcounter.conf has changed this to the old behavior.
#define GPSPORT 1 // gps - set to 1 to send combined GPS+COUNTERPORT payload
In Readme.md is Port 4 for TTNMapper intergration still mentioned.

You’re right, thanks for the hint. I changed the gps port default back from 1 to 4.
(Please use issue tracker in github to report issues, thanks!)

Hey so I have just stumbled across this fantastic project, well done!

I have had a read through almost this entire thread and answered most of my queries, one thing i am wondering is how appropriate it would be for this use case:

I want to track people on a bicycle moving through an area to get a rough indication of volume, given that some of these bicycles will be moving through the zone relatively quickly what would be the best settings for this, or is this simply not going to be practical? the other challenge i face is most (likely all) of these are remote with no power and some will even have limited sunlight for any decent solar - what would be the best unit to purchase as a proof of concept that could have a large-ish USB power bank attached and what kind of run times may i expect, weeks, months?

Thanks in advance!

Power consumption is around 1Watt.

For detecting moving objects BLE sniffing works better than WIFI sniffing. ESP32 has only 1 radio channel, BLE using 3 and WIFI 13 channels for signalling. Thus we need to cycle channels.

Thanks! Will give it a whirl, only one way to find out if it’s going to work, have got two units so might do some side-by-side comparisons with different settings/wireless protocols see what it finds.

I have the latest build running on my Heltec. Covid stats are showing here in Amsterdam.
Behind BLTH:xx it shows (CWA:x)
Very interesting! Is the CWA number also present in the LORA payload?
signal-2020-10-22-103830

Edit: It looks like that it is the data that I see on Port 10.
image

1 Like

Intresting date Format (00.xxx 1970!
I still struggle with the 01.01.1970 Problem on my T-Beams v1.1
As written down in Issue 639 this should be solved.

Indeed. I decided to stop worrying because I will upload it via nodered to a grafana so the timestamp will be there anyway.

This bug should have been fixed a few days ago.

Covid exposure notification Counter data is handled as user sensor#1, thus is delivered on port10.

1 Like

I noticed that and linked the issue id in my post.
My T-Beams are a bit diffrent as they use an ublox M8N GPS Chip (at least they are labeled as M8N).
With a plain serial monitor i observed not ZDA messages only GGA messages from the module.

With u-center i managed to enable the output of ZDA Data on UART1.

ubx_cfg_n8m

Furthermore the gpsread.cpp needed to be edited to GNZDA insted of GPZDA

TinyGPSPlus gps;
TinyGPSCustom gpstime(gps, “GNZDA”, 1); // field 1 = UTC time (hhmmss.ss)
TinyGPSCustom gpsday(gps, “GNZDA”, 2); // field 2 = day (01…31)
TinyGPSCustom gpsmonth(gps, “GNZDA”, 3); // field 3 = month (01…12)
TinyGPSCustom gpsyear(gps, “GNZDA”, 4); // field 4 = year (4-digit)

But propably this output is also dependeant of the GPS module NMEA sentence configuration.

I will verify this with some other T-Beams and open an issue on Github

What we still miss in paxcounter is a GPS chipset detection and configuration function. It is prepared already in gpsread.cpp, but without code yet.

I selected ZDA for timesync, because with certain GPS chips ZDA has deterministic delay on serial interface, thus it’s more precise. I am still struggling with realtime precision of the time sync routine. If you can help here, this would be highly welcome.

1 Like