Just had a very odd experience with the antenna selector and looking for some ideas on how to debug.
We just had a unit that had the antenna selector set to WiFi.selectAntenna(ANT_INTERNAL) and got a very marginal connection (seems to fail a lot) to our AP at 15ft and an rssi of -73 Once the selector command WiFi.selectAntenna(ANT_EXTERNAL) was issued and without an external antenna connected we got a good connection at that 15FT distance (seems to work good).
For those with a lot of RF experience does this make any sense at all?
Is it possible to simply check continuity through the antenna switch? My thought here is that maybe the switch logic is backward Iām choosing external and getting internal.
What is odd is that this is what I am seeing on a Photon by itself in a breadboard with no circuit and no external antenna It is simply breathing cyan running tinker and seems to be selecting the external antenna when none is attached.
I tried to dig deeper in the code but it seems that the antenna selection is actually handled at the low level by WICED code.
Does that make sense?
Is it possible that I am misunderstanding the meaning of isolation and insertion loss in the RF world ?
I am taking insertion loss to mean connected and isolation to mean disconnected.
I had a look at the RF switch datasheet and the photon schematic and I think you are correct: when Vctl1 = 1 and Vctl2 = 0, the external antenna should be selected. I didnāt follow the program logic to see how the RF_SW_CTRLx_ANTy pins are set.
āInsertion lossā in the table in the datasheet means that the switch is connected but like a lot of RF things, there is still 0.5-0.8 dB of loss in this device when āOnā.
A couple of points:
I thought @mdma said that the Wiced firmware would choose the strongest antenna even when you give a preference. I am not 100% sure of this though.
Can you probe the Vctl pins on the device with a scope or similar to see which way it is set? You could then see if the user setting is applied and then changed based on RSSI.
Can you temporarily unsolder the chip antenna from the Photon so it has to use the uFL connector?
Using a scope to probe the switch control signals while the code calls WiFi.selectAntenna(ANT_INTERNAL) I see the following: (There is only a chip antenna present)
VCTL1 = 1 VCTL2 = 0
I am reading a RSSi of -72
Not sure if it is important but was surprised when I saw VCTL1 = 1, VCTL2 = 0 while in DEEP Sleep. I thought to both would probably be LOW to save power.
Now testing with WiFi.selectAntenna(ANT_EXTERNAL)
VCTL1 = 0 VCTL2 = 1
I am reading a RSSi of -49
Once back in deep sleep the Photon goes back to the state of VCTL1 = 1, VCTL2 = 0
I did not bother to test ANT_AUTO as I put up a thread a few days back suggesting it was making the wrong choice. In this case it would have choosen the -72 RSSI
So the theory is that DEEP sleep sets the antenna control port back to the āwrongā setting for you?
I guess that mean that either that system code has to get fixed or you have to reset the antenna to external when you wake up. I am sure you can read the antenna setting by reading the pin setting registers directly even if there is no API to read which antenna is selected.
So everything I am seeing makes me think that there was a mixup between pcb layout and firmware design. Based upon the odd results I got a few days back with ANT_AUTO I think there is a strong possibility for everyone that are not controlling the setting of the antenna. That they are getting connected to the lesser antenna 100% of the time.
I obviously can flip the logic short term for my purposes, but I would really like someone at Particle to prove me right or wrong soon.
Iāve not been following along closely, but I canāt build a test program using the web ide currently, it says:
> ../../../build/target/user/platform-6/libuser.a(antenna_test.o): In function `spark::WiFiClass::selectAntenna(WLanSelectAntenna_TypeDef)':
> /spark/compile_service/shared/workspace/6_hal_12_0/firmware-private/user/../wiring/inc/spark_wiring_wifi.h:168: undefined reference to `wlan_select_antenna'
> collect2: error: ld returned 1 exit status
Anyway, running with a dummy load connected to the u.FL jack does not degrade the signal, so even if the manual selection is reversed, the (default) auto selection seems to work (which youād expect or we would have heard a raft of āthese these things are deafā comments.)
Any tips on how to build using WiFi.selectAntenna() in the web ide most welcome.
@Andy I am building locally. I believe right now that is the only way to select the antenna.
Not sure how a dummy load is supposed to help answer the question. Please give more detail.
I am a bit concerned that your testing confuses the issue further.
If I am right and the antenna switch is set incorrectly most all users are seeing a huge degradation in range needlessly.
Suprisingly yesterday we had a unit set to EXTERNAL without an external antenna attached that communicated at 220ft from the AP.
I really need to unwind this issue. For us it is very important to know was the 220ft result achieved by actually connecting to the chip antenna properly via the EXTERNAL setting or was it some other RF voodoo issue.
My experience with the Core with u.FL and other receivers is that you don't get a connection without an antenna, even at very close range like 3 ft.. So your data of switching to external antenna and still connecting at 200+ ft. says to me that you were using the other antenna. How that was happening in the software is the question I would be asking.
I am sure @AndyW 's idea was to use a use a dummy load, which is a resistor that is designed not to have RF radiation when testing a transmitter, as a way to completely block the received and transmitted signal on the u.FL connector. You shouldn't just short it out since the Photon may try to transmit on that port. Using a dummy load, there should be no way for the Photon to connect on the external antenna port.
@bko Thatās a good explanation about the dummy load.
I have just been outside myself doing lots of testing this morning. Here is the problem we need to make some sense of the results I just got.
At 120ft without an external antenna but set to ANT_EXTERNAL I get good results sending data.
When set to to ANT_INTERNAL it will not send data (same physical mounting for each test I myself are 8+ft away when the Photon is trying to send)
At about 60FT line of site I was able to send some data when the ANT_INTERNAL was set.
What you say makes complete sense but it does not square well with the results I am getting.
PS. with the external setting I was able to get to about 145FT but that was about 20ft in the woods lots of leaves and branches at that point.
@bko, thanks for stepping in with the explanation of the dummy load.
@HardWater, Iāve been building the system from source locally for long time, but a lot has changed since I last built an application other than tinker locally, Iāll try that this weekend and report back.
To re-iterate, I think that the system works as advertised in auto mode (since itās just choosing based on signal strength); it is certainly possible that the sense of the manual selection is inverted, and weāll get the the bottom of it. It should be fixable by a simple redefinition of the ANT_INTERNAL/EXTERNAL values, if it indeed proves to be in error.
@AndyW This thread Auto Antenna selection Photon I put up a few days ago when I tested ANT_AUTO really seemed to indicate that the antenna with the more negative RSSI was chosen. I was recording the RSSI values in INTERNAL EXTERNAL & AUTO. As RSSI values change slightly every time you collect the data it adds a bit of haze, but I am sure what I saw.
OK - I understand. Iām sure we can get to the bottom of this and get to a point where everything is self-consistent and weāre getting the best possible performance.
@AndyW Just did another test with a different methodology. Using the smartphone app Wifi Analyzer I took readings of the RSSI at 120FT from the Photon and my AP they were about 8 FT apart (the Photon in softAP/Listening mode)
Test 1:
Photon set to WiFi.selectAntenna(ANT_EXTERNAL) no external antenna attached
RSSIs AP -68 Photon -74
Test 2:
Photon set to WiFi.selectAntenna(ANT_INTERNAL) no external antenna attached
RSSIs AP -68 Photon NOT Found
Test 3:
At 30ft but otherwise the same as Test 2 the Photon starts to show up in Wifi Analyzer.
Test 4:
Back at 120ft no external antenna attached
Code recompiled to remove manual antenna selection (so my antenna choice is probably what 99.9% of OP are using)
RSSIs AP -68 Photon -90
So either not selecting an antenna is a somewhat reduction is range or is the same as making the correct choice. Its hard to be 100% sure the change from -74 to -90 indicates that not selecting the antenna gives poor results.
The other thing I would point out is since this test is really only looking at the transmission side of 2 way communication it is hard to be sure these results hold true on the receive side.
So these findings again add some muddiness to this discussion, but I think it is a 100% confirmation that WiFi.selectAntenna(ANT_EXTERNAL) & WiFi.selectAntenna(ANT_INTERNAL) are backward
@HardWater The PĆ and P1 modules have a default output for the state of the RF control pins. That was designed to select the external antenna by default. Iām reading that you believe this is not the case. Let me dig into this and report back. Also to answer your question about checking which way the RF switch is selected, you cannot test that with a continuity meter, only high frequencies will pass through the RF switch. There are also DC blocking caps on all ports, but even if you measured the switch itself this would be true.
Sure - but we can read the schematic, data sheet and test the state of the control pin, which should be enough to determine exactly what the behaviour is and whether it matches the design goals.
I think it is also an important clue that as I understand it, @HardWater 's use-case involves waking up from deep sleep periodically and expecting to have the antenna selection maintained. So if waking from deep sleep always put the device back into AUTO antenna selection, that would explain some of what he saw.
As @AndyW says aboveāa quick check should prove out the control pin stuff, but when I looked at it, I didnāt check back to the layout to make sure the pins were routed as in schematic. That might be worth double checking.
@bko@bdub@Andyw No each time I wake up I chose the antenna that I have stored in eeprom before doing anything else.
Really I am probably only going to use ANT_INTERNAL or ANT_EXTERNAL (in the near term) as I have my configured antenna selection set in eeprom. So swapping the logic to get the correct antenna is not a problem.
The driving force for understanding how ANT_AUTO and or not making an antenna choice works is that it may go a long way to explain the rather inconsistent range testing results I have been getting over the past week prior to playing with antenna choice.
As for getting confirmation of the the backward nature of ANT_INTERNAL and ANT_EXTERNAL that tells me to stop looking. There is no RF voodoo going on only a mistake that is easily corrected. Just swap the logic and go with it.
If there is a problem with how ANT_AUTO and or not making an antenna choice works, and I think there is. It effects all other users. More than anything I am getting frustrated that I cannot get a clear answer from the Particle team about this. I mean lets face it this product is 99.99% about getting good wifi and this concern of mine is at the heart of it.
