Improvement - Configurable grace period between boot and wifi scan

[wprzyb]

Hello. I am slowly making my car tracking assembly, and during so, i stumbled upon a silly problem - before car access point starts, TTGO already did his wifi scanning, and it didn't see the network, that i need him to connect to.

Since i don't want to cut myself out of possibility of connection to ttgo via wifi if for example i take accesspoint out of the car for maintenance or it break, or something - i don't want to set the mode flag hard to client, i thought, that it would be a nice to have a configurable grace period before wifi scan.

[gariac]

I am reviewing existing issues before doing a post. Anyway this grace period is a good idea.

[gariac]

Perhaps not exactly what you are looking for, but I notice using the rev 0,9.3 that the last reading is displayed. The problem with the previous rev is when hunting a radiosonde on the ground, you would be driving along, get a hit, look for a place to pull over and the data was gone. The new rev just leaves the last good data. So perhaps you don;t need this grace period.

[dl9rdz]

There is small change to mode 1 (client only) and also an additional similar mode 4 (client only, but without scan, supporting hidden networks):

If you press a button during the initial network scan, you can change to AP mode temporarily. So you can easily set it hard to client mode, but still (assuming you have at least one button accessible - most setups do) be able to enter AP mode if needed.

[gariac]

I don't see a mode 4 listed. I am using 0.9.3. I don't recall the previous rev I was using so unfortunately I will just call it the old rev.

Things are a bit better in rev 0.9.3 versus the previous rev. I will attempt to describe the problem.

When I am chasing a live radiosonde, I put my phone in host mode then turn on the ttgo. The TTGO goes into client mode 3. I only scan one frequency.

Let's say I find the radiosonde signal then lose it. Using the old rev , the last good demod would be tossed from the phone. Using rev 0.9.3, the phone hold the last good demod. The idea is I may not be able to screen shot the last demod using the old rev because I am on the road. Besides it being dangerous to mess with your phone while driving, it is illegal in my state. With rev 0.9.3, the last demod is on the phone. I can pull off the road and save it.

If you tell me which rev has mode 4, I can test it.

[dl9rdz]

The verison devel20240107 has the enhance WiFi modes, its not yet in the master version.

You can put mode 4 in the config. The config form (text in the web form) still needs to be updated (will do so in the next version), but still the functionality is there already. But for the given use case I suggest using mode 1 (instead of 3). But this is more relevant for the OP regarding connection between TTGO and phone.

Seeing the last good demod is a rather different issue. There should not have been any changes, and (as long as you do not reboot the TTGO) the data should still be there. But I am also considering doing enhancments there.

[gariac]

I loaded the development firmware. I selected mode 4 and it seems to work well with the phone being the hotspot.

Two scenarios were tested. First I parked the TTGO on the common frequency for the local airport. That is, there was only one frequency to scan. The sonde launch is at 3AM so I didn't watch it live. In the morning after the sonde flight was over, I could see the last demod. That is good. I was a bit surprised when I opened the browser and it went to the QRG page. But switching to the data page I could see the last good demod.

The second test was done during daylight hours where I could watch the phone. I plugged in all known frequencies for the local airport so that there was something to scan. I scanned three frequencies. It found the sonde. When it lost tracking, the TTGO would start scanning again. The last demod was not lost since there was nothing to demod to change it. I would say if you want to improve something, I would display the data with the last good demod at the top. It appears like the data display changes to the current sampled frequency. Otherwise the data is not lost.

Since I am using a board not on the list, I have included the output from the burn. I removed most of the MAC for who knows what but everything else is there. The part is a T3 V1.6.1 FCC ID 2ASYE-T3-V1-6-1. This is the board with the TF (SD) slot.

`
esptool.py --chip esp32 --port /dev/ttyACM0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x1000 devel20240107-B17-full.bin
esptool.py v3.3.2
Serial port /dev/ttyACM0
Connecting.....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e8:
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00001000 to 0x003fffff...
Compressed 4190208 bytes to 713804...
Wrote 4190208 bytes (713804 compressed) at 0x00001000 in 19.4 seconds (effective 1731.3 kbit/s)...
Hash of data verified.

`

[wprzyb]

Perhaps not exactly what you are looking for, but I notice using the rev 0,9.3 that the last reading is displayed. The problem with the previous rev is when hunting a radiosonde on the ground, you would be driving along, get a hit, look for a place to pull over and the data was gone. The new rev just leaves the last good data. So perhaps you don;t need this grace period.

My case is that i have my TTGO stationary mounted in my car, so it can provide data to sondehub/radiosondy.info when i am driving somewhere - no matter if i am chasing or no, so i wanted to connect to my car mAP no matter what, but considering its boot up time (since both accesspoint and ttgo are powered from car ignition). I have second TTGO for taking it with me, so i won't be messing around with cabling in a trunk :D