Search the Community
Showing results for tags 'wifi master extension 2.0'.
Hello, I am having some trouble with two stacks, both becoming unresponsive when connected via Wifi. Last week I received two Master Brick 3.1's and two WIFI Master Extension 2.0's plugged the extensions each on top of a Master Brick connected each stack via USB, and in Brickv: configured the extension configured and saved Wifi reset unplugged the stacks and powered them up with separate power supplies Immediately, both stacks had the same problem (when I boot up just 1 of the stacks): They boot up and connect to WLAN At this point, they behave normally: They respond to pings (response <15ms) They can be discovered and used in Brickv They can be discovered and used via Bindings After some time (between 5 seconds and 10 minutes, approx), the stacks stop responding: each of the three methods above just produces timeouts To get back online, I have to reset the Master Bricks or disconnect/reconnect power. The most extreme case is where a stack booted, I ping'ed it, I received 3 responses and then only timeouts. Other times, a stack works normally for up to 10 minutes, then hangs. I have also tried postponing first connection for 10 minutes after booting. First connection after 10 minutes also results in timeouts, so the stack "hangs" by itself (?). The WLAN is otherwise stable and fast; the router is an ASUS RT-AX86U. Things I have tried: Fixed IP vs DHCP assigned IP Different power supplies Reposition stack in relation to router Configure different Wifi standards (b/g/n) No Bricklets attached vs Bricklets attached Connect from a different host (MacOS vs Pi OS) Reboot Wifi router Repeat init/config of stack from start While trying to solve the problem, there were distractions: I discovered the Wifi status LED behaves oddly. This issue is thought to be unrelated. Discussed here. I discovered the Master Bricks return unexpected values for chip temperature. Also thought to be unrelated. Discussed here. One of the Master Bricks died; it appears stuck in bootloader mode. Solution still pending. Discussed here. This is the dialogue Brickv produces when a stack times out: This is what happens when I ping a stack right after it boots, and again 15 minutes later. No connection attempts in between: m1:~ ping 192.168.1.41 PING 192.168.1.41 (192.168.1.41): 56 data bytes 64 bytes from 192.168.1.41: icmp_seq=0 ttl=128 time=92.117 ms 64 bytes from 192.168.1.41: icmp_seq=1 ttl=128 time=9.247 ms 64 bytes from 192.168.1.41: icmp_seq=2 ttl=128 time=6.411 ms 64 bytes from 192.168.1.41: icmp_seq=3 ttl=128 time=4.392 ms 64 bytes from 192.168.1.41: icmp_seq=4 ttl=128 time=5.195 ms 64 bytes from 192.168.1.41: icmp_seq=5 ttl=128 time=6.888 ms ^C --- 192.168.1.41 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 4.392/20.708/92.117/31.971 ms m1:~ ping 192.168.1.41 PING 192.168.1.41 (192.168.1.41): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 ^C --- 192.168.1.41 ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss Let me know if you need more info.
Hello, I have a WIFI Master Extension 2.0 mounted on top of a Master Brick 3.1 As per the documentation I can control the green status LED of the WIFI Extension 2.0 with two methods: #enable_wifi2_status_led #disable_wifi2_status_led When I call the disable method, the led turns off, and #is_wifi2_status_led_enabled returns false, as expected. When I call the enable method, the led does not turn back on, but #is_wifi2_status_led_enabled returns true. Only when I reset the Master Brick does the green LED turn on again. Am I doing something wrong or is this a bug? (Edited to clarify #is_wifi2_status_led_enabled returns expected result)