Wifi/BLE Paxcounter Project with ESP32 boards

sveinutne · July 19, 2018, 7:24am

Did not manage to connect to any gateway with the pre installed software. Installed V1.3.91 with my DevEUI and AppEUI.
Display came the right way and it connected in seconds from my home. 8 km to the closest gatway.
I see new data every 1-2 min, but I do not find the data or payload. Maybe I need some integrator?
Found it. Maybe two gateways got the signal.Nice

Metadata:
{
“time”: “2018-07-19T07:25:48.992818158Z”,
“frequency”: 868.3,
“modulation”: “LORA”,
“data_rate”: “SF9BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “trt-sluppen-loragw01”,
“timestamp”: 2040610164,
“time”: “2018-07-19T07:24:43Z”,
“channel”: 1,
“rssi”: -107,
“snr”: -4.5,
“rf_chain”: 1
},
{
“gtw_id”: “trt-olav-loragw01”,
“timestamp”: 1080798172,
“time”: “2018-07-19T07:25:05Z”,
“channel”: 1,
“rssi”: -111,
“snr”: -4.75,
“rf_chain”: 1
}
]
}

But where is the payload?
In the display I see in the last line:
Packet Queued

sveinutne · July 19, 2018, 8:30am

09:44:47 0 1 retry dev id:ttgofirst payload:03000100
09:44:37

Dev addr is changing for each message, and only one time did I get port and payload data?

Verkehrsrot · July 19, 2018, 6:05pm

If the dev addr changes for each message, your device contiously rejoins.
Check on serial console if the device is in a reset loop, but this should be cleary visible on the display, too.

If you do not see status “TX COMPLETE”, only status “PACKET QUEUED” on display, the device is not sending payload data, because it either reached duty cycle or the LoRa chip does not trigger the event, what is typically caused by missing or erraneous wiring of DIO1 pin of LoRa chip or wrong pin setting in the .h file.

sveinutne · July 20, 2018, 4:13am

It is working better today.
First it changes dev addr on every line with activation. Then it starts to send payload every 4 min. Then after 10 uplinks on port 1 it start to also to do downlink on port 0.
bilde

sveinutne · July 20, 2018, 4:57am

It is downloading on port 0, but I do not see a pattern, or what triggers the downlink?
bilde

sveinutne · July 20, 2018, 5:30am

When I lifted the TTGO up from the table, so the antenna is vertical, no payload is lost.
37397518_10160742687810217_2232075043234381824_n

sveinutne · July 20, 2018, 5:55am

Now there is a downlink after every uplink, and I see three different gatways gets the data. So moving the antenna up 30 cm and holding it vertical maks a great improvments in reach.

bilde

Verkehrsrot · July 20, 2018, 8:59pm

Payload send cycle 240secs (= 4 min.) is the default. You can change it in paxcounter.conf.

The packets on port 0 are network MAC commands, sent because ADR is enabled by default. You can disable it in paxcounter.conf.

Send cycle and adr mode can also be set by remote command on port 2.

Read the readme.me and paxcounter.conf!

pe1mew · July 21, 2018, 9:17am

We are currently building the camp site facilities for two big scout camps in the Netherlands and we are registering the restaurant occupancy using a PAX counter connected to the temporary TTN coverage on the camp-site

The onsite sensors and the pax counter can be followed live at Cayenne: https://cayenne.mydevices.com/shared/5b3b43e2e27e6d6ced85ab1c/project/85932766-0c1e-4a5d-b7de-2f7bfc9f0e80

Amedee · July 21, 2018, 10:04am

Default is no more default

github.com

cyberman54/ESP32-Paxcounter/blob/master/src/paxcounter.conf#L39


* -> Scan interval can be changed during runtime by remote comammand.
*/


// WiFi scan parameters
#define WIFI_CHANNEL_MIN                1       // start channel number where scan begings
#define	WIFI_CHANNEL_MAX                13      // total channel number to scan
#define WIFI_MY_COUNTRY                 "EU"    // select locale for Wifi RF settings
#define	WIFI_CHANNEL_SWITCH_INTERVAL    50      // [seconds/100] -> 0,5 sec.


// LoRa payload default parameters
#define PAYLOAD_ENCODER                 2       // select payload encoder: 1=Plain [default], 2=Packed, 3=CayenneLPP
#define SEND_SECS                       120     // payload send cycle [seconds/2] -> 240 sec.
#define MEM_LOW                         2048    // [Bytes] low memory threshold triggering a send cycle
#define RETRANSMIT_RCMD                 5       // [seconds] wait time before retransmitting rcommand results
#define PAYLOAD_BUFFER_SIZE             51      // maximum size of payload block per transmit
#define LORASFDEFAULT                   9       // 7 ... 12 SF, according to LoRaWAN specs
#define MAXLORARETRY                    500     // maximum count of TX retries if LoRa busy


// Ports on which the device sends and listenes on LoRaWAN and SPI
#define PAYLOADPORT                     1       // Port on which device sends counts
#define RCMDPORT                        2       // Port on which device listenes for remote commands

(Flashed a new device and counted quite a lot of people in my little lab )

Verkehrsrot · July 21, 2018, 11:05am

Great! How did you manage to get the pax count number in cayenne as “Custom” field?

Verkehrsrot · July 21, 2018, 11:10am

Oh, that was an unwanted breaking change, i will correct this.

pe1mew · July 22, 2018, 9:52am

I used analoginput for the pax value. sort of abuse but fits the purpose/

Verkehrsrot · July 22, 2018, 9:56am

Same do i.
Can’t believe that there is no uint16_t meter value in Cayenne… ?

Charles · July 22, 2018, 3:13pm

That’s funny, I already asked that feature (just counter data) on mydevice forum, in this post one year ago
And also when they claimed LPP 2.0 on this one 5 month ago (seems you asked too )
I love cayenne look and feel, but for professional business I can’t use it, they’re missing 2 mandatory features:

basic counter (yeah, of course, never used in industrial companies) and
the ability of multitenant account/data sharing, can’t tell my customers to give me their password to see wha’ts going on. This feature is awesome on TTN console

Kater · July 28, 2018, 10:50am

Hi, we are looking for a solution to count people passing by (i.e. cyclists and maybe also pedestrians). I tried the Paxcounter but it seems it is too slow to detect a reasonable percentage of people for a solid extrapolation.
13 WiFi channels are switched every ½ s which means 6.5 s for a complete scan – and an “attention span” of < 8% for each channel. I am pretty sure this does not suffice for a person passing by on a bike.
Anyone here with experience on this issue? Alternatives? One could think of a cluster of ESP boards (maybe ESP8266, not ESP32) to parallelize the scan, but of course this would consume much more energy. Ideas?

Verkehrsrot · July 28, 2018, 2:42pm

You can try using shorter scan times on wifi and bluetooth channels. The scan times are configurable in paxcounter.conf, so it is comfortable to test different settings for your setup. Maybe shorter scan times catch more pedestrians passing by.

Bluetooth scan is much faster than Wifi scan, since only 3 (instead of 13) channels need to be scanned to detect advertisings. So you may want to focus on Bluetooth, not Wifi, for your use case.

Paxcounter Software does Bluetooth and Wifi scanning in parallel.

pe1mew · July 28, 2018, 6:46pm

Just some intermediate results of our PAX counter deployment at #Roverway:

paulb · July 29, 2018, 6:25pm

I was just wondering about that. Since it is a combination of bluetooth and wifi and time present to be able to catch devices of which some may be radiating nothing. Some people may be counted double and others not at all which may even cancel out errors to some degree. Are there already any numbers or guestimates of the correlation with real-world attendance?

pe1mew · July 30, 2018, 6:14am

I just made a single scan in the restaurant and counted approximately 110 persons. This means that about 75% is counted or has a smartphone with Wi-Fi enabled.

Screenshot_20180730-080828_Cayenne

I ignore ble because at the time of counting only 3 ware counted