Wifi/BLE Paxcounter Project with ESP32 boards

#387

That’s correct…

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

#388

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

#389

Thanks.
It works. :slight_smile:

#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

1 Like
#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.

#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

#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)

1 Like
#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.

1 Like
#395

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

#396

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

#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?

#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?

#399

@Verkehrsrot First I would like to express my apreciation for the work in PAXCounter. It is a huge job to keep it maintained and receive and react on all responces from users. From experience I know what it takes. I feel sorry for always only pointing on things that are not as opimized as one would like. Therefore this intermezzo; Thank you. I hope we can continue to work on and with PAXcounter.

With respect to the logic on screen saver: I can think of a timed state that, when screen saver is enabled, will switch of the display after a preset time and switch it on, on events like a keypress or when data is sent. So the display state kan be: ON, SCREEN_SAVE, or OFF.

It might be possible to use the same variable for display on and off and add a third value for screensave:
0=off, 1=on, >1 is screensaver timeout in seconds.

Although I hve not fully examined the code, this seems initially an implementable solution.

2 Likes
#400

yes, i think it can be done like that by using a Ticker.h counter. Can you open issue for this?

#401

Done.

1 Like
#402

First of all: thanks for the great Paxcounter! It’s working like a charm.
I’m using the TTGO Lora32 V2.1 1.6 an wonder if anybody has a 3d-Model for a nice case. The two on Thingieverse are sort of flimsy or not fitting really. I’m not really good in SketchUp so I hope someone did this before and is willing to share his results.

1 Like
#403

I am disappointed…
I was expecting to see a packet counter roll-over at 64K, but is still counts up…

02

I am logging the packet count as the TTGO used to crash on a regular basis, and it allowed me to track how long it was operating before restarting.
I have updated the software a couple of months ago, and since then it is rock solid, not a single crash!

2 Likes
#404

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

1 Like
#405

I also operate some test devices which “endless” uptimes.
It seems all major bugs in the software were catched over the last months.
So we freeze it now :wink:

1 Like
#406

Paxcounter repository v1.7.7 is now PlatformIO 4.0 ready.

Note: There were some major changes to platformio.ini.
Target board is now specified in section [board], like

[board]
halfile = generic.h
1 Like