(ANT_AUTO) antenna mode information

Firmware
1

Looking for a bit of help on STARTUP(WiFi.selectAntenna(ANT_AUTO)) it seems the best option, but are there disadvantages?

2

I don’t know about the current state but there were some issues with it in the early days that first connect took longer than necessary due to the antenna selection.

So if you know what antenna you will use, being explicit would be better IMHO.

2 Likes
3

Hi @andyg

The previous default was ANT_AUTO and it did cause problems in soft AP setup mode; the current default is to use the built-in chip antenna.

I think @ScruffR is right on point when he says that your best bet is to know what antenna you intend to use and set that explicitly.

3 Likes
4

Hi @ScruffR,

Good Afternoon,

I was wondering if you could shed some light on reliability of ANT_AUTO versus ANT_EXTERNAL.

We have 0.6.3 Particle Device OS on our firmware and wanted to upgrade some of our users with external WiFi antenna.

In the past 2018 Oct - 2019 Aug when we had tried to work with Ant_Auto (using 0.6.3) but constantly ran into connection issues during Pairing/AP mode.

Recently, on the same firmware with 0.6.3 ant_Auto seems to be able to establish connection and works as expected.

We are wondering if we are missing something? In what situations, would Ant_auto be able to not connect, and better than ant_external, when an external antenna is present.

Thanks

5

0.6.3 it quite ancient by now, is there any particular reason why you cannot move on to 1.4.4?

6

Hi @ScruffR

We tried to upgrade to 1.4.4, and constantly run into red SOS lights, of either 13 or 10, depending upon what code we comment out and its active development. We’ll know more about 1.4.4 in next 2 weeks.

In regards to the ant_auto versus ant_external, I would like to explain how we tested and concluded the unreliability of ant_auto.

We put external antenna on 4 units and tested them with ant_auto and 3 of them showed increase in RSSI values but the 4th one didn’t. When we changed the ant_auto to ant_external then we started to see the increase in RSSI values on the 4th unit as well. Our developers posted on the forums and learned that ant_auto is not reliable as ant_external.

I am trying to find out if this is still the case, and what scenarios might cause ant_auto to not work in some situations?

7

What libraries are you using in your project?
There were some safety checks added that rendered some operations "illegal" under some circumstances and hence some libraries had to be updated and maybe your own code may need to be adapted too.

Most of these changes have to do with class constructors and interrupts to avoid memory leaks.

ANT_AUTO was definetly less reliable in 0.6.3 than it is now.

8

As ScruffR said, the historical reason for using ANT_INTERNAL is that ANT_AUTO wasn’t reliable in SoftAP mode, as you discovered. There was a big upgrade in the WICED stack in 0.7.0. If there was a change to the reliability of this feature, it probably would have occurred there.

The most common reasons for SOS on 1.2.x and later are:

  • Calling unsafe functions from global object constructors: https://docs.particle.io/reference/device-os/firmware/xenon/#global-object-constructors

  • Calling non-interrupt safe functions from an ISR. This was previously allowed, but had the side effect of randomly crashing, sometimes in the future when doing something unrelated. Now, the SOS occurs immediately. Some non-interrupt safe functions are not particularly obvious. For example, sprintf using the %f formatting specifier.

Note that the unsafe practices may be in a library, so it may be necessary to update library dependencies as well.

2 Likes