Is it possible to reduce RF transmiting power on ESP32 to such a low level ...

[djixon]

.... that it becomes "visible to the other side" at range below 10cm or so? I need such a behavior in design, so I am curious is it possible to do that from code (by switching antena pin to non existing antena or so)?

I tried API function

esp_err_t esp_wifi_set_max_tx_power(int8_t power);

by sending lowest allowed value of 8 but it doesnt help .... device is still visible over 10 meters range even at smallest acceptable value.

Are there other possible software solutions?

[chegewara]

I know its hardware, not software solution, but maybe if you try devkit with IPEX antenna which is not connected.

[djixon]

Well, I understand that, but following behavior is required:

1. When "other side" detects ESP device is in close range (below 10 cm) it initiates a wifi connection with such a device
2. Then it sends a command which would bring back the RF power to normal level
3. Then they exchange what they have with normal signal strength (with possible increasing distance range)
4. Once they finish, "other side" sends a command to bring that RF level back down (making device "invisible" on ranges above 10 cm)
5. Then it sends a Disconnect (which would probably happen automatically once RF power is decreased back if distance is increased)

I know, I can use NFC solution, where wifi on ESP32 would be turned off all the time and once NFC detect near field presence, it then triggers a signal on ESP32 which then can turn the WiFi (or BLE) on (that is desired bahavior, but it requires additional hardware). Similar would be also possible with RF TAG reader on ESP device and RF tag on "other side", and once ESP detects RF tag it then turn ON wifi, allowing "other side" to establish connection .....

But I am curious is the same (or similar behavior, because you can not have completelly turned wifi off and expecting an "other side" establish a connection) behavior is possible without using external electronic parts and only code running on ESP32 keeping wifi at lowest possible level until some other device in close range (below 10cm), detects presence of this almost "invisible" ESP device, establishes connection, increases RF power, they do exchange what they have, and bring back ESP device into almost "invisible" state and disconnect. That would be a real emulation of what NFC is mainly used for and would be possible if code running on ESP device can reduce RF transmiting power to such a low level.

[chegewara]

How about using HAL and small magnets?
This solution does not require additional hardware, but im not sure hal is still enabled in API.
It also is not the safest option, but you still have wifi password protected.

[djixon]

That sounds cool, but If a magnet is on ESP side with turned off WIFI, once it approaches to "other side" with a HAL, how is that "other side" is going to activate wifi on ESP?
However, if a magnet is at "other side" and HAL sensor on ESP, then any magnet arround ESP can trigger a WIFI on ESP (but is not cappable to connect) and not only the magnet of "other side".

So if a magnet at "other side" would be replaced by some coil capable to generate some sequence (changing magnetic field) and ESP side with HAL detector captures such a sequence when coils are close enough, and accept such sequence as a valid, then yes... but in that case some IR detector at ESP side and some IR diode at "other side" can also do the job probably even simpler over IR communication.

Some of those two would probably be integrrated in design, however I still can not believe that such a trivial thing as reducing RF power at almost zero level is not implemented in ESP.

I still didn't check this function

esp_err_t esp_wifi_set_ant_gpio(const wifi_ant_gpio_config_t *config);

Is it possible to tweak the antena pin configuration and having wifi turned ON but redirect RF output to some dummy pin?

[ESP_Sprite]

Maybe a better idea is to check the RSSI of the packets you receive... There's various APIs for that, but worst case you can enable sniffer mode; that sends the RSSI together with the received packet. If the RSSI is ridiculously high, you can be reasonably sure that the device is close.

[djixon]

@ESP_Sprite: At first, thanks for the idea, I like it very much.

However, I am not sure how are those RSSI available before connection is established are truthfull due to auto "reshaping" of antena circuits? Because, here is all about that, which device (among the others) to proclaim as the closest one, and then establish connection with it. Let me try to "visualise" your idea and design requirements together to see if I understand it well.

Suppose, lets say, 100 ESP IoT devices are in the same room, all running the same piece of code and all with activated WIFI and all set up as SoftAPs. A distance among any two devices is not less than, lets say, 1m. The "other side", in this case is, let's say your mobile phone with activated wifi too. So, theoretically, if the list of networks (or BLE devices) your phone sees, is filtered by a name (suppose each ESP device has the same name but, they have different factory MAC addresses, however, that name filtering is required to eliminate other networks (or BLE devices) not belonging to those ESP crowd, like neighbors routers, smart TVs etc).
So the list contains only ESP devices and if it is sorted by RSSI strength and refreshed everytime your phone change physical position (or at some fixed time interval), then the device at the top of that list right after refresh, should be the closest one at that moment. So if you move your phone to, lets say below 10cm range, to some IoT device in the room, its RSSI should be strongest among all the others. So far so good.

In such a scenario, is it possible a following non-wanted situation: Since every ESP device is powered by its own battery, some of them are possibly charged more while some others, are at lets say 10% of baterry charging level and so on. Is it possible that any of devices (which is not closest to the phone) over-reaches RSSI strength of phisically closest device? (due to what ever reason, inperfection of antena on the PCB or difference in battery charging level, or due to implemented AUTO mode of anttena switching mechanisms inside ESP, or due to interference with other signals etc. Also, there is some limited amount of channels by wifi standard. So how at all, 100 devices with activated wifi deal with that? Will some have to be temporary silent if they share channels with some other devices etc? Will that impact the RSSI list on the phone?...) I am asking all of that, just to be sure that your idea can fit in all those possible circumstances and if such unwanted situation is possible, how to "fight" against that? I mean, is there a way to recognize such situation and deal against it?

Also, would it be possible to make the RSSI informations available among ESP devices themselves all the time? Since they are configured as SoftAPs and they are not wifi connected to each other? If that is not the case, would RSSI be available among ESP devices if they are configured as both STA and softAP? I am asking all that because, if each device would have its own RSSI list, then phone could do following to resolve possible miss-closenest-detection before it makes final "decision" what is the closest one device:
1. It could temporary connect to lets say top 3 devices on its list (one after another) and asks for their RSSI lists
2. Compare those 3 given lists with its own list and make some triangulation calc
3. calculate what is the closest device
4. establish connection with that closest, do exchange data, mark that device as processed in its internal list, and close the connection
5. jump to step 1

Job done
_______________________________________________________________________________________
From the RSSI aspect, I see two possible different configurations (which, I guess, both might work):
Config1:
All ESP devices are configured as SoftAPs (or dual SoftAP + STA if that is neccessary for them to receive RSSI), telephone is in that case in STA mode and it choses to which device to connect as previously explained.

Config2:
All ESP devices are configured as stations (STA mode), while phone is in AP mode. In such a config, a decision about connection would be at ESP side, once it detects some predetermined network name (name of AP of your phone) is above some predetermined RSSI treshold limit, it then tries to establish a connection until it get connected, then device and the phone exchange data, device get proccesed mark, after which it disconnects and stops trying to connect for some predetermined time. At phone side, AP could be configured to accept only single connection at a time, which should provide a proper serialization. Concept of "guarantee to be closest" in this config could be similar as in previous example, but this time at ESP side and could look like this:

1. DEVICE: "Hello the phone, your RSSI signal is above predetermined threshold level so I decided to connect, however there is possibility some other ESP device is even closer than me so do not take this established connection as granted, but give me the RSSI list of lets say 5 top ESP devices from your RSSI list."
2. Then device checks if it's MAC exists at position 1 on gotten RSSI list from the phone and if so then phone confirmed it is the really the closest (connection is validated, data exchanged, device got processed mark, dissconect and wait some predetrmined amount of time ), however, if its MAC address is not at the 1st position on the phone RSSI list then it "knows" it is not the closest one and should disconnect and wait for some short time until the next try.
Of course, program running on the phone also can blacklist all devices except the top on his RSSI list, denaying any connection but that from the top device, even reducing the number of those miss-tries. I guess, the whole algorithm could be fine-tuned upon some real tests are made.

In my initial idea, about reduction of RF power to extremely low level, the concept of "serialization" of the "crowd" is much easier if all wifi(s) are almost invisible above 10 cm range, because in that case there is no dilema which device is the closest one (simply there could be no device in range of 10cm and that is perfectly ok, also, by such a concept there is not even possible that some device could be "miss-detected" as device in range because its range is physically cut) and "air" is not "poluted" with interference of the "crowd" signals, also such a state of extremelly reduced RF power saves a battery, however, if it is not achievable on ESP by default, then making what is achievable, even at the cost of battery life and other side effects, is worth of try, esspecially if it can solve the "closest device problem" without involving new hardware components in design.

In both configs, the goal is the same: establishing connection in between the phone and device in 10cm range, exchange data, close the connection and wait until another device comes into 10cm range and so on.

@ESP-Sprite: Can you say some words, PROS and CONS of each setup in more details, how would each setup could be advanced in terms of reducing possible miss-guess about closest device, how both configs impact on battery life in each device, how would DHCP on the phone in config2 deal with arrival of a new MAC addresses all the time, do you see some other possible problems in those setups?

[chegewara]

In your case i would just make softAP ssid based on MAC address, so every device would have different SSID and RFID sticker on it or even better with QR code.
Sure, its not best solution if you have 100 devices, but you can easy write app on smartphone which can read RFID or QR code and connect that device.


PS you can establish wifi conection by SSID or by BSSID (MAC), so you can use this solution and to have all devices with the same SSID

Another "crazy" idea, to follow your thinking with 10cm distance, is to put every device in mini Faraday's cage, which can let some signal pass, just weakened

[djixon]

@chegewara,
I agree, in terms of safety, that RFID tag would provide the safest error free concept. The solution with QR codes requires: Generation of QR codes and printing stickers (which can be damaged over time or sensitive to humidity conditions) also introduce a problem of not enough light or too many light, requires camera and light source at "other side" for their recognitions ....

In previous post I gave the phone just as an example for easier understanding and distinguishing what is "ESP device of the crowd" and what is "the other side". But in general, by design, that "other side" should also be an ESP IoT device, but running different code than ESP devices belonging to crowd. In that terms, simplification of design of "Validator ESP device(s)" and "Crowd ESP devices" is a desire. RFID tag at "crowd devices" and RFIDTAG reader at "validator devices" is in that term more preferable options in comparation to Camera and QR codes, which beside proper lighting conditions also requires proper orientation of "Validator device" and "Crowd device" to establish communication which in some circumstances becomes a very hard constraint.

However, ESP-Sprite's idea about using RSSI strength (if it is implementable) closer fits to initial idea about reducing RF power, because it doesn't require any additional parts while RFID TAGS have to be programed differentialy for each crowd device which is an extra effort and extra part, increasing production costs and time, also "validator devices" require RFTAG reader which is an extra cost. However, that sounds as the best idea if the concept with RSSI strength fails due to any of a reason.

Do you have any experience with posible problems using RSSI strengths in such a crowdy environment, and what else could possibly go wrong in detection of closest device by some of previously mentioned configs? Could some "Mesh configuration" of the crowd be even preferable way to handle desired task?

I also hope, that some from Esspressif, sees those real requirements comming from "the field" to us (developers) from the real people ready to invest their money and make their ideas true. If that, switchable by code, to "almost zero power RF strength" is not hard to implement in chip hardware, allowing a device to be "invisible" over 10cm range, then it could possibly find its place on some future ESP chips with RF implemented. Sure, that is just a "plastic" explanation of requirement. Maybe, at hardware level, it can be completely independant (from wifi or BT) RF module with its own small antena, allowing only that 10cm range of detection. Once detection is "established", software then can turn ON wifi or BLE depending on requirements of design. Not only it is useful (to reduce power and safe battery life, because on those designs involwing crowd, real wifi (or BLE) is required only in the fraction of second or so, alowing RF module which is real power consumer, to be turned off most of the time) but it is also necessery in some concepts similar to this, where only close range (below 10cm) detection is a must, otherwise the whole bunch of concepts with designs involving "crowd" becomes extremelly hard to handle mainly due to "signal mess of the crowd" presented in "the air".

[chegewara]

It all depends what is the area on which all the devices will be placed.
100+ wifi APs its a lot and if you dont implement it really good all will be stick to the same channel.
It is hell a lot of noise and RSSI wont be reliable most likely. If you add people with bluetooth devices around (just guessing) it may be hard.
Not saying its not possible, but you have to test it.

I am playing with ble mesh now, few esp32 laying next to each other and most of the time RSSI is -8dbm, but from time to time with no reason RSSI drops down to -78.