Thank a lot. I’try to start from there.
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
0x01 ? for rssi and
64 for 100) if I want to set the rssi limit to
P.S.: I posted this question with the wrong account earlier.
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.
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.
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?
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.
I am disappointed…
I was expecting to see a packet counter roll-over at 64K, but is still counts up…
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!
As an aside, if you really expected the counter to rollover: