Pyboard D station interface: connection after power cycle unreliable
Tests used an SF6W with a WBUS-DIP28. Firmware is the 4th April release build.
MicroPython v1.10-258-g83f3c29d3-dirty on 2019-04-03
and mboot is updated. After each power down I waited 10s before reapplying power: this was sourced by a switched LiPo cell. No USB devices were connected. boot.py contained the correct country code only, and main.py was a one-liner importing the script below.
I also tested an SF2W with similar outcomes.
The tests were run in two locations. One was about 2.5 metres from the AP with an RSSI of -39dBm, the other in a room with RSSI of -58dBm. In the latter location ESP8266 and ESP32 devices connect with high reliability; the Pyboard D's can reconnect after a deliberate outage with 100% reliability in my testing. Results were as follows:
-39dBm location failure rate 3 out of 20 attempts.
-58dBm location failure rate 4 out of 5 attempts. Numerous tests with both Pyboard variants yielded a very low success rate.
The biggest problem is that if the initial connection fails, I have so far found no way to recover. Simply re-trying doesn't seem to work.
import pyb, network, time
red = pyb.LED(1)
green = pyb.LED(2)
green.on()
time.sleep(4) # Give things a chance to settle down
green.off()
s = network.WLAN(network.STA_IF)
s.active(True)
s.connect('redacted', 'REDACTED')
red.on()
time.sleep(0.2) # Brief red flash if already connected
while not s.isconnected():
time.sleep(1)
red.off()
green.on()
This was raised in the forum where @chuckbook failed to replicate this, but it is a very real issue here.
Pyboard D: uos.dupterm slows USB REPL character input
Tests used an SF6W with a WBUS-DIP28. Firmware is the 4th April release build and mboot is updated.
MicroPython v1.10-258-g83f3c29d3-dirty on 2019-04-03
An FTDI adaptor was connected to UART 1 via the WBUS-DIP28 with a miniterm.py session running. The USB FS interface was connected to a PC running rshell. main.py consisted of:
from machine import UART
import uos
uart = UART(1, 115200)
uos.dupterm(uart)
Everything worked as expected, but sometimes character input to rshell slowed to a crawl. Not much faster than 1cps. Characters were buffered: I could type a line but had to wait for the characters to be echoed back and the line executed. This behaviour was not consistent. After a power cycle it would either be in normal or slow mode. Once in a mode, it stayed that way.
[EDIT]
Revisiting this I can no longer replicate it despite using the same hardware and code. Yet it's been happening regularly all day. Any ideas what might be causing this?