EspNow concepts

[chromebin]

I have a hard time understanding ESPNOW.

In principle it would be quite easy: select the same channel on *both* devices, transmit on one device on this channel, and receive on another device on this channel. ESPNOW (apparently) does 2 transmissions behind the scenes, one from the sender (data), one reply from the receiver (confirmation). The only complexity would seem to be the slave-list where ESPNOW driver saves info on the slave, like its channel. Also there needs to be a way to get slave addresses. Sofar so good.

However I have downloaded 2 "sketches", one is the master and one is the slave. The master sketch has a "channel" setting (in esp_now_peer_info_t which enters esp_now_add_peer()), the slave sketch doesn't. However, changing the channel doesn't interrupt the connection as expected (and I have no reason to suspect the setting is being ignored).

So that's a big question mark. How do the master and slave connect? What happens behind the scenes? Docs are very thin and talk to those that really know Wifi. Does something depend on Wifi transmissions/protocol and not ESPNOW (because both sketches use `WiFi.mode(WIFI_STA);`)??

Code: Select all

The slave has only this sequence:
   WiFi.mode(WIFI_STA);
   esp_now_init();
   esp_now_register_recv_cb(rx_callback);

The master uses this sequence:
   WiFi.mode(WIFI_STA);
   esp_now_init();
   esp_now_add_peer(...);			// channel set
   esp_now_register_send_cb(sent_callback);
   esp_now_send(...);

[chromebin]

And then there is also:
- the LMK/PMK stuff. How to deal with that appropriately? What happens in practice?
- when encrypting only 6 peers are possible, or can ESP_NOW_MAX_ENCRYPT_PEER_NUM be changed?

I have condensed the espnow reference example (and eliminated mallocs) to show its structure:
- 2 devices assign themselves a magic number
- they begin to broadcast their magic number
- when a device finds a lower magic number it begins to unicast to that device
- the device with the lowest magic upon receiving a unicast also switches to unicast => connection established
So device roles (master or slave) are derived from the magic number.

The espnow example probably clarifies the PMK stuff sufficiently (tests pending), but nevertheless comments are welcome, including on the channel confusion.

[chromebin]

My channel confusion probably has to do with broadcasts. This code comes from the initialization in the ESP NOW example, the initialization registers the broadcast, passing in the CONFIG_ESPNOW_CHANNEL:

Code: Select all

    memset(peer, 0, sizeof(esp_now_peer_info_t));
    peer->channel = CONFIG_ESPNOW_CHANNEL;
    peer->ifidx = ESPNOW_WIFI_IF;
    peer->encrypt = false;
    memcpy(peer->peer_addr, example_broadcast_mac, ESP_NOW_ETH_ALEN);
    ESP_ERROR_CHECK( esp_now_add_peer(peer) );

For now I had used only broadcasts. But whatever value I give CONFIG_ESPNOW_CHANNEL (I have to admit I only tried channel 12, vs the regular channel 1), I continue to get interference from devices on a supposedly different channel. So I understand they they are on the same channel and basically ignore CONFIG_ESPNOW_CHANNEL. Which might make sense.

If this is right, then the example is wrong by giving the wrong suggestion (which is that CONFIG_ESPNOW_CHANNEL matters where it really does not).
But if the example is correct, then where is my error? Why doesn't the channel change, or why do I still continue to receive packets from devices supposedly on another channel?

[chromebin]

To add to the ESPNOW concepts:

1. According to other posts on the forum and elsewhere, the ESPNOW follows a send and acknowledge model, and it isn't clear if it automatically retries (I hope not).

So:
- the result of a call would guarantee success
- failure naturally does not indicate failure, as the ack might be lost instead of the original transmission
- the call would delay until a confirmation or a timeout occurs
- exception: no reply expected to broadcasts I presume, so broadcasts would enable a raw packets interface, but the user will have to filter out messages himself. Private broadcasts (all members publish to a known MAC) would be great to have, and simple to implement.

Why not mention something so basic as an acknowledgement protocol in the docs??! Developers need to reason about their project, without info they can't. Specially as ESPNOW is marketed as sort of raw packets. It isn't.

2. Once ESPNOW is switched on, and using only ESPNOW, by default it opens an AP with "ESP-BADA55" type of SSID.

Again, the docs should mention this up front.

This was completely unexpected. ESPNOW is supposed to be similar to raw packets. Why invite devices to connect, or even attack?

Also a dozen devices all transmitting an SSID is definitely not cool, certainly not in our app.

Can I at least hide the SSID, or use station? Would this reduce the potential of problems?


Still haven't gotten other channels than channel 1 to work

Please add any info on ESPNOW if you have some.

[davdav]

Hello @chromebin,

regarding point 1. following link
https://docs.espressif.com/projects/esp ... p-now-data
tell that you need an "application layer" ackonwledge to be sure the transmission to a peer succeed. In my project I send data to a peer using

Code: Select all

esp_now_send

API and wait for a reply "ACK" from peer.

point2. I will check on my project because I don't see the AP ssid when espnow is turned on. I start wifi in STA+AP mode but I don't set

Code: Select all

wifi_config_t

".ap" section. I have tried to use in STA only mode and it works only if the devices are not connected to a router: maybe this interfere with the interface of esp32. I manage to use WIFI_IF_STA interface for router and WIFI_IF_AP interface for espnow communications.

point3. In my case, since devices are connected to a router, the channel is fixed to that one. However, if you call

Code: Select all

wifi_set_channel

function you can modify the operating channel. However if you choose channel 12 (for example) and your router is on channel 7 (for example) you will not connect to it.

[chromebin]

Thanks for the reply davdav, any experience shared is good. I had given up on expecting any.

Now you are also confused (like me), so sorry for the big post that follows:

> regarding point 1. link tell that you need an "application layer" ackonwledge to be sure the transmission to a peer succeed.
> In my project I send data to a peer using
> <Code>
> esp_now_send
> API and wait for a reply "ACK" from peer.

This is what's being said on your link:

Call esp_now_send() to send ESP-NOW data and esp_now_register_send_cb to register sending callback function. It will return ESP_NOW_SEND_SUCCESS in sending callback function if the data is received successfully **on MAC layer**. Otherwise, it will return ESP_NOW_SEND_FAIL

The critical part is the MAC-layer. This is either the local MAC layer, and trivia, or the remote MAC layer and implies an ACK. So odds are this concerns the destination device, which implies there are multiple transmissions. The text continues to support this thesis:

There are several reasons failing to send ESP-NOW data, for example, the destination device doesn’t exist, the channels of the devices are not the same, the action frame is lost when transmiting on the air, etc. It is not guaranteed that application layer can receive the data

There is virtually no failing if the result of the call concerns the local MAC layer, and it makes no sense to about the fact that radio messages may not arrive. If a ESPNOW send results in a single transmission it is obvious it may be lost. The text seems to make the point that the remote device responds automatically, meaning there is no application involved (a good thing).

But hey, just say that a single ESPNOW send call results in multiple frames on the air, and please be specific about the number of frames, as it probably is 2: the sender frame to which the receiver responds with an ACK frame. Just one ACK, arrives or doesn't, determining the result of the call.

BUT... it then the text goes on to put us on the wrong foot:

If necessary, send back ack data when receiving ESP-NOW data. If receiving ack data timeout happens, retransmit the ESP-NOW data

This doesn't make much sense, except when there is no ACK behind the scenes. Or else it is lawyers talk, intended to avoid assuming responsibility (silly lawyers).

There are several posts on the net of folks who have investigated the issue, and they find the remote device responds. Sorry couldn't find those posts, maybe it's just one guy posting in a few sites.

The (other undocumented) LMK/PMK story also hints at a protocol: encryption requires some sort of protocol.

The bottom line is that:
- if you understand ESPNOW to be raw messages (which is how ESPNOW was received), in need of an ACK, you'd be wrong
- Expressif wants to tells the competition about the protocol

The difference between an ACK and no ACK is critical for example in the case of giving all devices a single MAC, which would allow private broadcasts between them, an issue I explicitly touched on.

To summarize my understanding as it stands: ESPNOW sends a (non-broadcast) frame and the receiver replies (as quickly as possible) with an ACK (from its "MAC layer").

If so Expressif should say loud and clear:
- do NOT, as an application, send (empty) ACK frames
- something got lost going from chinese to english (and back)

It should be clear then that:
- broadcasts are single frame (send only) but get processed by all nearby devices
- private broadcasts (with all devices sharing a single MAC) result in a mess with one sender and multiple easily corrupted ACKs

(Expressif, ) please correct me if I'm wrong.

[davdav]

Hello @chromebin,

I'm just a esp32 user and I don't know exactly what is the underlying protocol/method Espressif uses for ESPnow. I followed and applied suggestions reported in docs.

In particular:

-when I send a message to a peer, I attach an identifier number to the message. The receiving peer can check if it is a repeated message. I also apply a CRC on the message content to be sure the received message is not corrupted (as done in example espnow).

-the receiving peer sends an ACK message to peer sender.

-if sender peer doesn't receive the ACK in specified timeout (in my case 500ms), it sends again the message

Maybe this is not the most optimized practice (in particular if the ACK is already done in "MAC-layer" as you infer) but for my application is sufficient and "robust".

Regarding encryption I just setup the PMK and LMK of the peers. I have tested with and without encryption: to me it seems transparent from application level.

[chromebin]

Good to know! Thanks @davdav.