Wifi/BLE Paxcounter Project with ESP32 boards


(Frasanc1) #378

I think that I have solved the problem. I was compiling with TTGOv21new, now I have change to TTGOTBEAM and It’s ok. The data on TTN have the correct values.
Now I have difference bettwen por 1 and 4, in port 4 the value of GPS is OK, but in port 4, no. I’ll do more tests of configurations.

Thanks a lot. The next step is to change the payload format and data to update.


(Verkehrsrot) #379

Paxcounter with new display for BME280/680 sensor values: pax, temp, hum, indoor air quality. Getting insights in pax versus air :mask:

IMG_20190408_200332


(Frasanc1) #380

For some tests, I would like to be able to print, in Debug mode, on the screen, the list of the hash of macs that are in the variable macs. I do not know exactly how to access this type of variables to be able to traverse and print each mac.

extern std :: set <uint16_t, std :: less <uint16_t>, Mallocator <uint16_t >> macs;

Can you give me some reference?


(Verkehrsrot) #381

This is already coded in macsniff.cpp, use debug level verbose to see.

// Log scan result
ESP_LOGV(TAG,
         "%s %s RSSI %ddBi -> MAC %s -> Hash %04X -> WiFi:%d  BLTH:%d -> "
         "%d Bytes left",
         added ? "new  " : "known",
         sniff_type == MAC_SNIFF_WIFI ? "WiFi" : "BLTH", rssi, buff,
         hashedmac, macs_wifi, macs_ble, getFreeRAM());

(Frasanc1) #382

Right, that option is what I can do now. What I try is to visualize at a certain moment the list of stored macs, that is, when I generate the payload, I would like Debug to be able to see a list of all the macs followed, since in the Debug it writes even when they are repeated indicating if they are new or already included.

What I would need is to show on the screen the list of the macs stored in the memory variable.


(Verkehrsrot) #383

Such kind of function was intentionally not integrated in the code due to privacy reasons.
Internally all collected MACs are stored in a container, until they are cleared after a scan cycle. Look at https://en.cppreference.com/w/cpp/container/set to see the options.


(Frasanc1) #384

Thank a lot. I’try to start from there.


(C Wempe) #386

This may be a silly question, because I am a beginner.

But how can I set the RSSI limit via downlink?

I guess I use the downlink form in the concole of my device.
image

I I read the README where it says:

0x01 set scan RSSI limit

1 ... 255 used for wifi and bluetooth scan radius (greater values increase scan radius, values 50...110 > make sense)

0 = RSSI limiter disabled [default]

Bat what does this mean.
What does the Payload look like?

Do I just send 0x0164 ( 0x01 ? for rssi and 64 for 100) if I want to set the rssi limit to 100 ?

Thanks

P.S.: I posted this question with the wrong account earlier.


(Amedee) #387

That’s correct…

And set the FPort to the configured command port (which is by default 2 if my memory serves well)


(Verkehrsrot) #388

For RSSI = 100 you enter 01 64 (for 0x01 0x64) in console downlink field, change FPort to 2, then press send.


(C Wempe) #389

Thanks.
It works. :slight_smile:


(Frasanc1) #390

Hello,
After the tests and to obtain a result close to what we already need, I am writing to tell you the project and some questions.
We will locate the device in the signals of a smart pedestrian crossing, to adjust the assembly the queries are:

  • Could the monitoring be activated when the pedestrian crossing is activated? (What ports could receive the on / off signal of the pedestrian crossing?)
  • Food: Taking into account that the food is similar to public lighting and therefore night, some idea of ​​mounting that allows night charging and daytime operation from the battery. I have been thinking about making a box with a powerbank that charges at night and during the day serves as a battery. The doubt, seeing the consumption is to know the capacity of the battery to cover the needs of the device. Any estimate to support about 16 hours? Any idea will be well received for testing. If you can indicate me some perfect concrete equipment.

Thank you!paso-de-cebra-inteligente


(Verkehrsrot) #391

Power: If you charge 6 hours per night a standard 18650 cell should do the job. You could use a TTGO T-Beam with integrated battery holder/charger for this.

You may check the power of the traffic sign. If the lightning is LED there could be some kind of power supply you may use. Otherwise use 5V USB charger.

Activation: if the goal is to save power this could best be done by using deep sleep mode, but this is not programmed yet. Most power consumption comes from Wifi stack. Take into account that if you load the Wifi stack in the moment when a pedestrian arrived, this could be too late, since starting the stack takes some seconds.

Also take in account that you probably also will count the pax in the waiting cars.


(Frasanc1) #392

Thank you very much for the reply.

Regarding food, it will be public lighting and we will not have problems, I will try to use a “power bank” of at least 20,000 maAh that may be enough.

Correct what you tell me about activating it with the activation of the pedestrian crossing, since the delay will be fundamental for a correct detection. What I would like to do, is to be able to receive the status of the pedestrian crossing and send the status in the Payload. What input port do you recommend to receive a binary On / Off value?

Another question I would like to ask for your experience:
More correct time for Wi-Fi scanning? I currently use 1 min.
More correct time for Bluetooth scanning? I use 1 min.

I comment so that the data is not so variable. I attached an image with two devices nearby, and where you see that there are moments (with detection period of 1 min) where detection is very variable.

I will be doing tests and I will tell you results.52


(Verkehrsrot) #393

For sensor data look in sensors.cpp, there are 3 user sensors already prepared, you just need to insert the function which returns the sensor value.

My findings was that Bluetooth scanning goes on cost of Wifi scanning, and gives no additional results, as long as you don’t want count cars (the often transmit bluetooth signals)


(Verkehrsrot) #394

Don’t modify the wifi timings in paxcounter.conf, since they were well tested in experiments.

A shorter time between switching the wifi channels speeds up the recognition of pax, but may result in less pax totals. If you need very fast recognition Bluetooth could be better because BT signals on only 3 channels (Wifi 13), so BT is faster. But there are usually far less BT than Wifi devices.


(Remko) #395

@Verkehrsrot Is there anyway to prevent the Oled display from burning-in. e.g. screensaver that switches of the display after time-out?


(Verkehrsrot) #396

Screensaver is already implemented, can be switched by remote command, look in the readme.md in rcommand table


(Remko) #397

Thanks for mentioning. I get confused because parameterisation is not consistent over config files and remote commands.

I can switch of the display. How do I switch on screensave?


(Verkehrsrot) #398

yes, there were some breaking changes during growth of the software, since lack of a roadmap. The screen can only be turned off. What would be your suggestion for logic of screen saver?