Correct.
WiFi.begin(“trueiss”) → SDK crashes/reboots after emitting:
RTL8721D[Driver]: set ssid [trueriss]
as in original posting. reducing the signal level by either walking far away or shorting antenna with finger makes it work ok.
Note: After the RTL8721D[Driver] gets to this message (while maintaining attenuation):
RTL8721D[Driver]: start auth to xx:xx…
I can take my finger off or walk close to the AP again and connection remains established.
Maybe some high mixer intermodulation products in the front end causing adjacent channel interference?
Using V3.1.1. Was there a change effecting wifi in V3.1.2?
thank you.
So how to rebuild lib_arduino.a ?
I am trying to debug the strong wifi ap problem so need to recompile .arduino15/packages/realtek/hardware/AmebaD/3.1.1/system/component/common/api/wifi/*.c
files.
Compiling archive libraries are mostly handled by the Realtek team, as it involves intrenal SDK and multiple steps that could be too complex for users.
However, if you are interested in building lib yourself, you are welcome to take a look at the Realtek Standard SDK (open source version), despite some differences with the internal version in terms of source code, the building processes are identical
I was able to reproduce the high rssi AP problem using the standard SDK build
(GitHub - ambiot/ambd_sdk: Release SDK for AmebaD No ardunio layer) using CONFIG_EXAMPLE_WLAN_SCENARIO (setting in platform_opts.h) and exercising scenario_5() in example_wlan_scenario.c. OPEN WiFi ap connect. The system reboots in wifi_connect() in wifi_conf.c while waiting for rtw_down_timeout_sema(). Line:
“if(rtw_down_timeout_sema( &join_result->join_sema, RTW_JOIN_TIMEOUT ) == RTW_FALSE)”
Here it appears to be waiting for “RTL8721D[Driver]:” to respond. The source code for this driver is NOT in the SDK so I am hoping a fix from Realtek will come.
As before, attenuating the signal either with finger touching antenna or placing unit in partial faraday cage alleviates the problem.
Also, fwiw, different batches of rtl8720dn modules with exactly the same fw behave differently.
Further testing with BW16 modules with default/shipped unmodified firmware also exhibit this issue when connecting to nearby open (no password) wifi AP. Using ATPN=xyz at “#” prompt on the LOG UART results in below. Sometimes its a Hard Fault, sometimes the prompt stops reacting with repeating “fw cmd fifo full”, sometimes just reboots. FWIW the AP I am connecting to causes no problems for any other devices (ESP… or otherwise) and is an OpenWRT device. Any help here would be appreciated.
Note that yours produces
“Attempting to connect to WPA SSID: amebarocks”
Mine does not.
The problem is with open (no encryption) hotspots.
How do you get yours to show “WPA” for an open hotspot?
I would be happy for any workaround.
My posting was for OPEN non-encrypted no wpa hotspots. I also notice the problem is more pronounced for 2.4ghz APs, eg what you see most in public places.
I am sure this can be fixed in the Realtek WiFi library if I had source (lib_wlan.a ?)
If I attenuate the signal, it all works. So should be no difference.
For unencrypted, open APs and hotspots (ie, captive portal) in the public scenario work the same with dhcp ip address assignment. Irrespective of that, there should be no difference between an attenuated signal or not - right? So why would the attenuated one work? Have you tried with an open, unencrypted 2.4ghz ssid sitting next to the B+T BW16? It will take a couple tries but either crashes, becomes nonresponsive, reboots or faults for me. Updated lib_wlan.a anyone?
Thank you
Hi @lamb
I tried again with what you said-- open network with no security, 2.4GHz, higher than -20 RSSI, using RTL8720DN, and still the connection is very strong… here is the log
Here is the example code, I didn’t change anything, 100% stock example code
/*
This example connects to an unencrypted Wifi network.
Then it prints the MAC address of the Wifi shield,
the IP address obtained, and other network details.
Circuit:
* WiFi shield attached
created 13 July 2010
by dlf (Metodo2 srl)
modified 31 May 2012
by Tom Igoe
*/
#include <WiFi.h>
char ssid[] = "yourNetwork"; // the name of your network
int status = WL_IDLE_STATUS; // the Wifi radio's status
void setup() {
//Initialize serial and wait for port to open:
Serial.begin(115200);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
// check for the presence of the shield:
if (WiFi.status() == WL_NO_SHIELD) {
Serial.println("WiFi shield not present");
// don't continue:
while (true);
}
// attempt to connect to Wifi network:
while (status != WL_CONNECTED) {
Serial.print("Attempting to connect to open SSID: ");
Serial.println(ssid);
status = WiFi.begin(ssid);
// wait 10 seconds for connection:
delay(10000);
}
// you're connected now, so print out the data:
Serial.println();
Serial.print("You're connected to the network");
printCurrentNet();
printWifiData();
}
void loop() {
// check the network connection once every 10 seconds:
delay(10000);
printCurrentNet();
}
void printWifiData() {
// print your WiFi shield's IP address:
IPAddress ip = WiFi.localIP();
Serial.print("IP Address: ");
Serial.println(ip);
Serial.println(ip);
// print your MAC address:
byte mac[6];
WiFi.macAddress(mac);
Serial.print("MAC address: ");
Serial.print(mac[0], HEX);
Serial.print(":");
Serial.print(mac[1], HEX);
Serial.print(":");
Serial.print(mac[2], HEX);
Serial.print(":");
Serial.print(mac[3], HEX);
Serial.print(":");
Serial.print(mac[4], HEX);
Serial.print(":");
Serial.println(mac[5], HEX);
// print your subnet mask:
IPAddress subnet = WiFi.subnetMask();
Serial.print("NetMask: ");
Serial.println(subnet);
// print your gateway address:
IPAddress gateway = WiFi.gatewayIP();
Serial.print("Gateway: ");
Serial.println(gateway);
}
void printCurrentNet() {
// print the SSID of the network you're attached to:
Serial.print("SSID: ");
Serial.println(WiFi.SSID());
// print the MAC address of the router you're attached to:
byte bssid[6];
WiFi.BSSID(bssid);
Serial.print("BSSID: ");
Serial.print(bssid[5], HEX);
Serial.print(":");
Serial.print(bssid[4], HEX);
Serial.print(":");
Serial.print(bssid[3], HEX);
Serial.print(":");
Serial.print(bssid[2], HEX);
Serial.print(":");
Serial.print(bssid[1], HEX);
Serial.print(":");
Serial.println(bssid[0], HEX);
// print the received signal strength:
long rssi = WiFi.RSSI();
Serial.print("signal strength (RSSI):");
Serial.println(rssi);
// print the encryption type:
byte encryption = WiFi.encryptionType();
Serial.print("Encryption Type:");
Serial.println(encryption, HEX);
}
Thank you so much for this effort!
I have seen some variance between hardware. First batch from Digikey, second from seeed. I will report back as soon as I have tried your code.
=== cut paste and compiled your example. first try - still issues ===
Will recreate a fresh Arduino AmebaD environment on another machine and try again to make sure the problem is not my build environment.
— reset, ie, pul EN pin low for a second. EN pin is normally held high w/ 10K resistor –
— vcc bypassed directly to BW16 metal shield with 0.1+10uf SMD caps —
– LOG UART output – #calibration_ok:[2:19:11]
interface 0 is initialized
interface 1 is initialized
Initializing WIFI …
WIFI initialized
Attempting to connect to open SSID: xxpass
RTL8721D[Driver]: set ssid [xxpass]
— REBOOTS HERE — #calibration_ok:[2:19:11]
interface 0 is initialized
interface 1 is initialized
…repeat
— tried different open access point - same behavior — #calibration_ok:[2:19:11]
interface 0 is initialized
interface 1 is initialized
Initializing WIFI …
WIFI initialized
Attempting to connect to open SSID: trueriss
RTL8721D[Driver]: set ssid [trueriss]
– REBOOTS HERE – #calibration_ok:[2:19:11]
interface 0 is initialized
interface 1 is initialized
Initializing WIFI …
WIFI initialized
Attempting to connect to open SSID: trueriss
RTL8721D[Driver]: set ssid [trueriss]
– I PUT MY FINGER OVER ANTENNA HERE WHICH MAKES IT WORK–
RTL8721D[Driver]: start auth to bc:30:7d:92:8e:c6
RTL8721D[Driver]: auth alg = 0
RTL8721D[Driver]:
OnAuthClient:algthm = 0, seq = 2, status = 0, sae_msg_len = 0
RTL8721D[Driver]: auth success, start assoc
RTL8721D[Driver]: association success(res=1)
Interface 0 IP address : 192.168.13.190
You’re connected to the networkSSID: trueriss
BSSID: C6:8E:92:7D:30:BC
signal strength (RSSI):-20
Encryption Type:0
IP Address: 192.168.13.190
192.168.13.190
MAC address: 94:C9:60:1B:EB:B1
NetMask: 255.255.255.0
Gateway: 192.168.13.1
SSID: trueriss
BSSID: C6:8E:92:7D:30:BC
signal strength (RSSI):-20
Encryption Type:0
Same issue with fresh environment (fresh Ubuntu 20.04.3, Arduino 1.8.19, AmebaD Ardunio 3.12). See below. Going to program a few more BW16s to do same test.
#calibration_ok:[2:19:11]
interface 0 is initialized
interface 1 is initialized
Initializing WIFI …
WIFI initialized
20220217 My test to SSID:trueriss (–> I added this)
Attempting to connect to open SSID: trueriss
RTL8721D[Driver]: set ssid [trueriss]
---- REBOOTS HERE — #calibration_ok:[2:19:11]
interface 0 is initialized
interface 1 is initialized
Initializing WIFI …
WIFI initialized
20220217 My test to SSID:trueriss
Attempting to connect to open SSID: trueriss
RTL8721D[Driver]: set ssid [trueriss]
– REBOOTS HERE ----
This log shown here indicated that the AP you connect to is not a open-security AP already, as open AP does not requires the auth step
I dunno what is happending here, but my best guess is still the issue with the hardware, maybe you can wait a while and try out the second batch and see how it goes. At least from my end, BW16 seems working fine under this working scenario
Definitely open AP. I control it and open to all devices i have tested. If the "start auth " message is not supposed to be emitted, this may indicate a firmware problem with lib_wlan.a.
I am plotting current usage of the device and noticed the failed attempts draw a peak of 400ma+ whereas if I put my finger on the antenna and it succeeds, the peak draw is 200ma.
I shall post oscilloscope plots of current draw but this indicates the firmware is doing something extraordinary while connecting to an open/noencryption AP with high signal levels. My guess is that, as you suggested, there is some poor interaction between hardware and software that may be causing this extraordinary behavior.
This is very odd and indeed abnormal, even BW16 is also using the ARM Cortex-M arch, power consumption should be very low even when connecting to the AP, around 80mA and standby at 20mA
WiFi_Scenario5.zip.xml (413.1 KB)
This file has recently compiled images using the GitHub SDK, running the WiFi scenario 5 example. It attempts to connect to a open WiFi network with “Test_ap” as the SSID.
Can you download the file, remove the .xml extension, unzip, and upload the images using ImageTool and test it out?
I have tested on my BW16 connecting to my phone hotspot resting on the table next to it, with RSSI around -16, and have had no issues.
Similarly, you previously stated that you could recreate the issue with the GitHub SDK. Can you download the latest files from GitHub, compile and verify that the issue still exists, and upload the image files in the same way for me to test?
I think testing the same images can help isolate the source of the error.