How to connect with specific BSSID or sort AP with same SSID by signal strength

Official Hardware Nano Family Nano 33 IoT
1

I hope this somewhat fits the theme here (long post).

I'm trying to wrap my head around an issue with roaming between multiple access points under one SSID using the Arduino 33 IoT (with the Nina WiFi based on ESP).

I have several Ubiquiti Unifi APs covering the location. I have control over the network and can make adjustments as needed. There are two usage scenarios for my SAMD Arduinos:

a) They are stationary panels that send information to a server over WiFi.
b) They are portable and are carried across the location. They receive messages over WiFi.

I understand that the firmware used for Arduino NINA is using WIFI_FAST_SCAN instead of WIFI_ALL_CHANNEL_SCAN (ESP IDF).

In case A), the devices will connect to the first SSID of a given name they find. This could be one AP quite far away, across several walls, with minimal signal quality. Rather than the access point about 5 meters away, in plain sight, with optimal signal strength. As a result, we observe poor connection quality with many disconnects, even for stationary devices.

I would be somewhat fine with that behavior when moving across the location. I’d expect it to reconnect to the strongest AP nearby, then do so again when finding a stronger AP or losing connection after some time. But Arduino handles this differently (probably for faster single AP SSID scenarios).

Espressif states in their docs:

"Please note that the first scanned channel may not be channel 1, because the Wi-Fi driver optimizes the scanning sequence.

It is a possible situation that there are multiple APs that match the target AP info, e.g., two APs with the SSID of 'ap' are scanned. In this case, if the scan is WIFI_FAST_SCAN, then only the first scanned 'ap' will be found. If the scan is WIFI_ALL_CHANNEL_SCAN, both 'ap' will be found, and the station will connect to the 'ap' according to the configured strategy. Refer to Station Basic Configuration."

Thus, I couldn't even mitigate this issue by adjusting the AP channels to optimize network performance. But this shouldn't be considered an ideal solution anyway.

Since scenario A) (stationary) doesn’t work reliably, there is little hope I can achieve solid performance for scenario B) (mobile and roaming). It doesn't have to be 802.11r roaming. I'd be fine managing it manually, and 1-2-3 seconds of disconnection would be acceptable, though not ideal. What we’re seeing is a frequent loss of connection, and reconnecting doesn't improve things.

My workaround would be to use the BSSID obtained from a manual network scan and connect to that specific BSSID (sorted by RSSI). But as far as I understand, the NINA library on Arduino doesn't support BSSID with WiFi.begin().

If I were using a direct ESP setup, I think I could do this.

So the only potential solution (to keep hardware) would be to update the NINA firmware to use WIFI_ALL_CHANNEL_SCAN with the WIFI_CONNECT_AP_BY_SIGNAL configuration. But at the moment, this is beyond me. I want to keep the Arduino 33 Iot if possible. However, I lack the capabilities to build new firmware for the NINA chip that includes the configuration I think I need.

My first question: Is this the current state, or are there readily available firmware versions I could flash that support a different scanning approach?

My second question: Is there a WiFi library for SAMD architecture Arduino that uses WiFi NINA with support for selecting BSSID when connecting to a given SSID?

If that isn't feasible I'd probably switch to ESP, as first tests indicate, they could do what I need.

And it's a pitty ... since it's just some configuration flags (more or less) ... as far as I understand .. and I have 20 of them sitting on my shelf ready to go (or not).

I understand that it's not just changing some flags for a suitable release. And that there are considerable design decisions behind this, but how could I go about this?

2

Hi @nhbn. The Arduino developers are tracking this problem of the firmware on the "NINA" Wi-Fi radio modules connecting to a lower quality AP when multiple APs use the same SSID here:

If you have a GitHub account, you can subscribe to that thread to get notifications of any new developments related to this subject:

screenshot of Subscribe button

:exclamation: Please only comment on the GitHub issue thread if you have new technical information that will assist with the resolution. General discussion and support requests are always welcome here on the Arduino Forum.

There are no official firmware versions with a fix for this problem. Maybe you can find an unofficial community created firmware with such a change (I'm not aware of one, but it is possible).

3

Hi @ptillisch,

thank you for the prompt reply. Do you have any insights on priority or timeline of this issue?

If it's another year or two ... it's a deal breaker for me and I'd be looking elsewhere.

Thank you.

4

I don't have any insights beyond what you see in the issue I linked.

Note that the problem was reported three years ago and there hasn't been any response or action from Arduino. So I wouldn't hold your breath for a resolution in the near future.

5

Its a big issue I have been living with this ever since they Brough out the IOT 33 the code needs rewriting I believe the only current solution is to move to ethernet or ESP32 which I understand makes the right routines available. I tried to talk to the developers but they were incredibly rude and threatened to report me. Arduino is great but there are issues which have never ben resolved it does not help they will not acknowledge or discuss them.

I invested 100's of pounds but there were are I have also achieved so much. My solution is to create a dedicated SSID for one room where I use the Arduinos and only have the SSID on that asccess point.

6

Just a guess but maybe the new Nano Matter might just solve this. But it is only a guess.

see this page:-

7

By "talk", you mean creating four duplicate issues:

when you knew very well (because you had already commented there) that we already had dedicated issues tracking this deficiency:

When you create duplicate issues, you waste resources that could instead be put towards productive work that would benefit the entire Arduino community. That is counterproductive and irresponsible behavior.

The deficiency is acknowledged by the presence of the issues in the relevant trackers.

There is plenty of discussion already. Arduino's GitHub repositories are a place for productive technical work. It is essential to keep all activity in the repositories very tightly focused on that work so that the developers can work efficiently. When we start seeing counterproductive behavior in the repositories, we are forced to close the discussions even though we would much prefer to leave them open to allow productive contributions. So making unproductive comments on the GitHub issues harms the entire Arduino community.

Arduino's GitHub repositories are not an appropriate place for redundant conversations. If you want to have unstructured discussions, the forum is the appropriate place for that.

8

ptillischArduino Team

when did I first raise the issue.
Has there been any movement on the issue
If people don't listen customers make noise
I also spoke to the support team they referred me to the GitHub team

I think this topic reflects how Arduino deals with difficult problems
Do you think asking kindly how things are going is counter productive

Please enlighten us all how is a solution going to this issue

9

Referring to the remaining issue on git hub

still no-one is assigned to it and as far as I can see nothing has been done to remedy this since 2021. By the way I did not create that's issue. Perhaps this is why people like my self are frustrated. Since I was requested I have stopped creating topics on the issue I have stopped asking Arduino support about the issue.

I would be grateful if you could out line what progress has been made in resolving this issue since 2021. Thank you

10

by way of exploration I tried to connect using the BSSID but as mentioned this function is not available. As mentioned using an ESP32 based unit it would be.

  1. /src
    bool connect(const char *ssid, const char *passphrase = NULL, int32_t channel = 0, const uint8_t *bssid = NULL, bool connect = true);

Thank you for propping me to look at this again and find a solution.
Its a shame the Arduino ESP does not use the esp for WIFI!!!

Its hard o move from Arduino as I use them for so long but if the developers don't see this as a reasonable priority in the internet world where Multiple access points are so comment
WE have to make hard decisions. Whatever the team suggests I don't feel I have been totally unreasonable in my communication even though I found I was like a tennis ball between Arduino support and the team behind the library.

11

It's interesting that my remarks align with Russell’s observations on the timeline.

I actually agree with him to some extent. This issue poses a significant challenge for users like me, who are semi-knowledgeable in these matters. While I could invest time in learning to build custom firmware for the NINA module, this seems excessive given how common multi-AP setups (WiFi) are today.

For now, I’ve moved to the ESP32, as the ESP8266 also had limitations in this area. It would be great if Arduino could address this to make the platform more accessible for scenarios like these.

I’d really love to keep using these otherwise versatile boards for many future projects, but this limitation is a significant drawback. It’s surprising that this doesn’t seem to be a bigger issue for more users.

12

Did you mention to them that the deficiency was already tracked by an issue in the GitHub repository?

If you did, they definitely should not have instructed you to open a duplicate issue.

When you do that in the GitHub issue trackers, yes it is absolutely counterproductive.

Duplicate issues fragment the information about the subject matter. For a project to be efficiently managed, t is essential that each deficiency, defect, and feature request be tracked by one issue, which contains all known technical information on the subject. When you create duplicate issues, it fragments the tracking of that item.

Dozens of people are subscribed to these and the hundreds of other Arduino repositories so that they can collaborate on these free open source software projects. We get a notification for every issue that is opened and comment made on every one of the tens of thousands of issues and pull request threads. We must carefully monitor the activity in the repositories in order to effectively collaborate. So pointless issues and comments result in either people spending significant amounts of their time sifting through unnecessary notifications, or else unsubscribing from the repositories that are the source of those notifications.

It might seem like a single person creating few duplicate issues is not that big of a deal, but we have hundreds of projects, used by many many thousands of community members. If each of behaved irresponsibly as you did, it would absolutely destroy these important resources.

It is irrelevant who created the issue.

Thanks! I hope you will also be more careful to be factual when describing Arduino's response to you from here on.

I'm not involved in the management and development of these projects so I am not able to provide that information.

My responsibility is the maintenance and moderation of the issue trackers, so I can only provide facts on that subject.

13

You are missing the point

No one is allocated to the issue
Its not been touched for 4 years

Its an Arduino problem that the core team need to fix

14

No, I am not missing the point. I understand very well that there is a deficiency in the "NINA" firmware and in the WiFiNINA library in regards to environments where multiple access points use the same SSID. I also understand you are frustrated by the existence of this deficiency and the lack of action by Arduino to resolve it.

But you decided to also misrepresent the facts regarding your behavior in the issue tracker and how I dealt with that behavior in this thread, and so I must address that. It is you who has shifted the conversation away from the technical deficiency and to the subject of responsible behavior in the public issue trackers of free open source software projects, and the effective maintenance of those trackers.

15

I disagree the topic of this post is " [How to connect with specific BSSID or sort AP with same SSID by signal strength]. You Brought up the issue of the Arduino team not happy with my behaviour 4 years ago. The fact that it is over 4 years ago and I stopped posting in those relevant channels says some thing. The fact that the issue still remains says some thing else.

I still make the valid point In my opinion the Arduino Nano Iot 33 is not suitable for a modern business envioroment so if you plan to use it in an application in such a common environment its probably not wise and you are better off using some thing else such as a genuine ESP 32.

If you continue to bring up my behaviour from over 4 years which has changed, a fact you don't mention. I will make a formal complaint to Aruduino

Thank you

16

It is you who brought it up, as can be seen by anyone who takes a minute to review this thread:

17

I have seen the pull request by @wasteofpaint. Great find/move!

I have a question regarding this change that you guys can maybe help me with.
Didn't want to post this in the github.

When using WIFI_ALL_CHANNEL_SCAN will it be using the sort_method WIFI_CONNECT_AP_BY_SIGNAL as default or WIFI_CONNECT_AP_BY_SECURITY in the NINA firmware? I think these are the sort_method options, and I think the first would be the one to go.

Thanks and best regards.

18

I also suffer from this issue: I have several access points and my Arduino boards always connect to an access point with a very weak signal instead of connecting to a close by access point. I had this problem for several years and I do not understand that this issue is not solved. My personal opinion: This is not very professional.

I solved the issue by creating a separate VLAN that is only available on the access point that is close to my board. Now my three Arduino boards all connect to this access point.

Although this solution works, I still think that this issue must be resolved; either by always selecting the access point with the best signal, or by giving the possibility to connect to a specified BSSID.

19

May I point out that this topic was opened more than a year ago and that the underlying issue has existed long before that.

At this point I think the root cause, the impact, and the available workarounds have been described in sufficient detail in this thread. Could we please get some official feedback from the core / library maintainers?

For example:

  • Is this behaviour considered a bug or “works as designed”? (probably as designed, but why?)
  • Are there any plans to change it?
  • Are there any recommended strategies to mitigate this besides the workarounds already discussed here?

From a practical point of view:

For legacy projects (and occasionally new ones) we still use the Arduino ecosystem (AVR boards like Uno / Nano / Mega as well as some of the newer SAMD boards). However, reliable roaming in multi-AP environments is essential for us, and this specific limitation has been a dealbreaker in several projects. As a result, we moved most new designs over to the ESP32 ecosystem.

I have always been a strong advocate for Arduino.

If this issue was properly addressed, we would seriously consider the Arduino platform again for more WiFi-based projects in the future.

Right now, though, the current behaviour unfortunately makes the Arduino platform feel deprecated for our kind of WiFi applications.

I am sure many other users’ WiFi projects in this community are affected by the same limitations as well.

Best Regards
@nhbn

20

Hi all,

Before this thread auto-closes soon, I would like to gently revive it. Not to reopen the technical discussion already covered above, but to ask the maintainers for a brief status update.

The questions from the previous posts are still open. I fully understand that a fix (from my perspective) may not be on the roadmap. Even a clear "this won't be addressed" would be helpful and appreciated.

Maybe there are new concepts in the making that would address this. In that case a short hint would be helpful, both for me and for anyone landing here from a search later.

Thanks for any input.