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());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.
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.
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.
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.
That’s correct…
And set the FPort to the configured command port (which is by default 2 if my memory serves well)
For RSSI = 100 you enter 01 64 (for 0x01 0x64) in console downlink field, change FPort to 2, then press send.
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:
Thank you!
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.
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.
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)
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.
@Verkehrsrot Is there anyway to prevent the Oled display from burning-in. e.g. screensaver that switches of the display after time-out?
Screensaver is already implemented, can be switched by remote command, look in the readme.md in rcommand table
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?
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?
@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.
yes, i think it can be done like that by using a Ticker.h counter. Can you open issue for this?
