Wonderful part and sdk. Already using it to replace ESP.
However when connecting to APs with RSSI > -20, the system reboots. I am using arduino environment. Here is LOG UART output:
#calibration_ok:[2:19:11]
interface 0 is initialized
interface 1 is initialized
Initializing WIFI …
WIFI initialized
WiFIMAC:94:c9:60:1b:eb:b1
trueriss -20
xxpass -29
xfinitywifi -69
xfinitywifi -72
xfinitywifi -84
Found 23 APs
Attempting to connect to SSID:trueriss
RTL8721D[Driver]: set ssid [trueriss] #calibration_ok:[2:19:11]
interface 0 is initialized
interface 1 is initialized
when connecting to AP with RSSI > -20, meaning -1 to -19 (this is super high tho), then the WiFi will be unstable and attempt to connect to APs with weaker signal strength, right?
and also, what is the Arduino package version? the latest one is V3.1.2
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
