Make sure in the logs that it is a high-speed hub, as USB 2.0 doesn't give a clue of what actual speed is used.
Topic: ar9331's usb stability issue - [SOLVED]
The content of this topic has been archived between 23 Mar 2017 and 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
Page 7 of 13
The kernel reports everything I connect as "...new high-speed USB device number...", so I think all the hubs and devices are 2.0. I am getting just over 100Mbits pulling data off a flash key with/without hub, so that pretty much cancels any 1.1 possibilities right ?
Hello. I found this tread via google, my tasks aren't exactly as yours, but I have high speed scope, logic analyzer, spectrum analyzer, so I can start looking at the USB signal, to find out when it gets in troubles. The main problem is, that I'm running the stock firmware and want to keep it's functionality, as 3G connection sharing wifi hotspot, so if yours OpenWRT provides that, I will flash and check. The main interest and keyword why I've found this tread is usability of USB hub. Is it possible to hook an usb hub and two devices in it? I'd like to have 3G modem and usb hdd connected, so I can use my hdd as NAS. The power won't be an issue - I can mod power supply to required levels.
USB hub can solve this problem. Is there anybody can solve this problem in the linux kernel and usb driver?
FYI, USB power output voltage of WR703N is very susceptible to AR9331 Wi-Fi operation.
Below are oscilloscope's snapshot images of USB voltage showing example of typical router's usage:
- powered by original AC adapter ;
- (only) passive budget USB 2.0 hub is connected to the router ;
Wi-fi is ON, no traffic, beacons only:
Wi-fi is ON, lot of traffic:
Wi-fi is OFF:
A lot of USB devices require +4.75V ... +5.25V voltage range for their operation.
Some other USB devices declare that 5V +- 10% is sufficient ( 4.5V ... 5.5V).
Spikes of 0.3V in magnitude shown above are too high for reliable operation!.
When USB power becomes lower than necessary OpenWRT system may suffer from numerous "USB disconnect"s.
Powered USB Hub with sufficient electrical capacity will help:
- to keep medium voltage applied to USB devices close to 5V ;
- to dump spikes and variations of voltage caused by dynamic variations of electrical load;
(Last edited by xkremator on 20 Jul 2013, 15:30)
Will using an adapter with higher current help?
alphasparc wrote:
Will using an adapter with higher current help?
May, or may not. Quality of adapters does vary.
As an example, I've measured the voltage of WR703N connected to 12V->5V car adapter rated for 2A - spikes are the same.
Soldering a capacitance of few hundreds of uF to 5V power lines typically does help.
Another issue we should worry about - the voltage for USB socket of WR703N is taken out from internal LDO,
which is likely rated not more than 500mA. This is because WR703N is originally specified to be connected with
not more than a USB 3G modem.
Some of you may already noticed that older models of 3G modems drain a lot of curent and also susceptible
to frequent disconnects when attached to WR703N.
So if we want to attach several USB devices to the router, we should use self-powered USB hub,
and it is preferable that internal electrical design of the hub can withstand to all of the noise generated by
attached devices over the 5V power lines.
(Last edited by xkremator on 21 Jul 2013, 12:37)
Yeah, USB power and corresponding decoupling on the TL-WR703N is pretty weak: adding a few hundreds µF capacitor across the USB power may help:
See this thread: https://forum.openwrt.org/viewtopic.php … 06#p155706
But unfortunately, this is not the only issue:(
Even with a large capacitor like above, there is still a USB long-term stability issue with the AR9331 (occurring from as fast as a few minutes up to one hour) which also applies to some other AR9331-based devices (so this is not a TL-WR703N problem per se), that only occurs when WiFi is turned on: the USB just hangs (NOT a disconnect!), and this happens only with full speed devices connected directly to the router, like an Arduino board.
It doesn't happen using a high-speed device or when the full-speed device is attached through a high-speed hub, even a passive one, so this is not a weak power supply problem.
It is not due to a high USB traffic: the Arduino board only spits a counter every second using a CDC-ACM pseudo TTY.
The USB bus does not hang either when you only use isochronous traffic, like for audio or video streaming; there may be some glitches, but they may well get unnoticed.
Apparently, this problem may be due to WiFi RF spurious emissions causing problems to the USB clock PLL within the chip itself.
This is the reason why I changed all my projects to use boards based on the RT5350 SoC rather than on the AR9331 whenever I need a reliable USB operation.
However, the AR9331 is still a better option when USB is not used, with only 1/3 (0.5 W vs. 1.5 W) of the power requirement running WiFi @ 18 dBm.
hmm, so what you are saying, Squonk, is that no amount of hacking will fix the issue as it is all happening within the chip?
robthebrew wrote:
hmm, so what you are saying, Squonk, is that no amount of hacking will fix the issue as it is all happening within the chip?
In my opinion (I may be wrong!), the only possibility left is if there are some magic registers in the wireless peripheral/baseband to lower/shift the WiFi RF spurious emissions and preventing it from bugging the USB, or some other registers in the USB host peripheral to lower the USB clock PLL sensitivity to RF spurious...
Maybe in QCA's openhal project on Github, see my post #146?
i make a test for the wr703,seems just 78 second is over.so it may the power supply problem...
http://see.sl088.com/id/4a9
(Last edited by slboat on 25 Jul 2013, 11:07)
and i try direct connect the R113(give supply from usb),still no luck,only about 1minuter
it seems with out the ldo(3.3v-5v),it dead fast,so the ldo maybe is try to fix the problem?but still not so good.
in the org firmware,the 3g dongle is work okay more than hours and hours.
be use a hub(the chip is FE2.1),it work very long time
survive for time second: 973
survive for time second: 974
survive for time second: 975
survive for time second: 976
survive for time second: 977
survive for time second: 978
survive for time second: 979
survive for time second: 980
survive for time second: 981
> survive for time second: 982more than 8000 second
survive for time second: 7977
survive for time second: 7978
survive for time second: 7979
survive for time second: 7980
survive for time second: 7981
survive for time second: 7982
survive for time second: 7983
survive for time second: 7984
survive for time second: 7985
survive for time second: 7986
survive for time second: 7987
survive for time second: 7988
survive for time second: 7989
survive for time second: 7990
survive for time second: 7991
survive for time second: 7992
survive for time second: 7993
survive for time second: 7994
survive for time second: 7995
survive for time second: 7996
survive for time second: 7997
survive for time second: 7998
survive for time second: 7999
survive for time second: 8000
survive for time second: 8001
survive for time second: 8002
survive for time second: 8003
survive for time second: 8004
survive for time second: 8005
survive for time second: 8006
survive for time second: 8007
survive for time second: 8008
survive for time second: 8009
survive for time second: 8010
survive for time second: 8011(Last edited by slboat on 25 Jul 2013, 14:32)
slboat wrote:
in the org firmware,the 3g dongle is work okay more than hours and hours.
Yes, but is the 3G dongle full-speed or high-speed in the logs?
The problem only happens when doing non-isochronous full-speed transfers, everything is fine if doing isochronous or high-speed transfers.
There may also be a patch in the original firmware just like the ones in QCA's openhal project on Github that may correct the problem, I don't know.
i use a hub and now can put them on the wall 
guess that's just the way usb and wr703.
i have a thought that may be problem is only for the CDC/ACM driver,not the usb1.1
i found a wired thing,the wr703 v1.6 is use a cpu called[ar9331-al3A],and the v1.1 is use[ar9331-al1A],and some other change is now have a f1 element.
now i test the v1.6 see how is the usb problem going.
here is some diffrent betwen two board
the v1.1 test survive 1088 second,now is test the V1.6 version,for now is more than 600 second.
(Last edited by slboat on 27 Jul 2013, 05:03)
the first test on new pcb V1.6 survive more than 3000 second,and stop because the wifi,not show the usb disconnect)
survive for time second: 2917
survive for time second: 2918
survive for time second: 2919
survive for time second: 2920
survive for time second: 2921
survive for time second: 2922
survive for time second: 2923
survive for time second: 2924
survive for time second: 2925
[ 4832.500000] ath: phy0: Failed to stop TX DMA, queues=0x001!
[ 4833.310000] wlan0: authenticate with 24:3c:64:14:11:1e
[ 4833.350000] wlan0: send auth to 24:3c:64:14:11:1e (try 1/3)
[ 4833.350000] wlan0: authenticated
[ 4833.360000] wlan0: associate with 24:3c:64:14:11:1e (try 1/3)
[ 4833.550000] wlan0: RX AssocResp from 24:3c:64:14:11:1e (capab=0x431 status=0 aid=3)
[ 4833.560000] wlan0: associatedi think the F1 is for the usb,base on spounk's sch.
the F1 look close
now i going to test again,and this time use lan to conect for test(last is use ttl)
and i found the change is not V1.6,is the sn change,after 136198,it's come with the change
stably more than one hours
survive for time second: 4021
survive for time second: 4022
survive for time second: 4023
survive for time second: 4024
survive for time second: 4025
survive for time second: 4026
survive for time second: 4027
survive for time second: 4028
survive for time second: 4029
survive for time second: 4030
survive for time second: 4031
survive for time second: 4032
survive for time second: 4033
survive for time second: 4034
survive for time second: 4035
survive for time second: 4036
survive for time second: 4037
survive for time second: 4038
survive for time second: 4039i now going to get 2 arduino uno board,start 3 route(with pcb change) same time test
(Last edited by slboat on 27 Jul 2013, 07:05)
in the v1.1version wr703n:
and i found wifi client mode can work more than 2500 second,as wifi server mode,mostly cant survive for 1minute.
root@OpenWrt_SLboat_Mod_V1:/etc/config# wifi on
[12790.230000] wlan0: deauthenticating from 94:0c:6d:d4:b1:be by local choice (reason=3)
Configuration file: /var/run/hostapd-phy0.conf
[12791.430000] device wlan0 entered promiscuous mode
Using interface wlan0 with hwaddr 14:cf:92:87:07:a8 and ssid "OpenWrt SLboat Mod 1"
[12791.570000] br-lan: port 2(wlan0) entered forwarding state
[12791.570000] br-lan: port 2(wlan0) entered forwarding state
[12793.570000] br-lan: port 2(wlan0) entered forwarding state
root@OpenWrt_SLboat_Mod_V1:/etc/config# microcom -D/dev/ttyACM0
Ú
**********Help***********
x - exit microcom
b - send break
l - log on
s - start script
t - set terminal
q - quit help
*************************
Command: úÀh–zBšù
******Set terminal ******
p - set speed
m - no CR/NL mapping
n - no flow control
h - hardware flow control
s - software flow control
q - quit help
*************************
******Set speed *********
a - 1200
b - 2400
c - 4800
d - 9600
e - 19200
f - 38400
g - 57600
h - 115200
i - 230400
j - 460800
q - quit help
*************************
Command: Help done!
survive for time second: 7
survive for time second: 8
survive for time second: 9
survive for time second: 10
survive for time second: 11
# <- dead heretry again
[12973.790000] usb 1-1: USB disconnect, device number 13
root@OpenWrt_SLboat_Mod_V1:/etc/config# [12974.460000] usb 1-1: new full-speed USB device number 14 using ehci-platform
[12974.620000] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
root@OpenWrt_SLboat_Mod_V1:/etc/config#
root@OpenWrt_SLboat_Mod_V1:/etc/config# microcom -D/dev/ttyACM0
úÁHÚ®-
ðhä
**********Help***********
x - exit microcom
b - send break
l - log on
s - start script
t - set terminal
q - quit help
*************************
Command:
******Set terminal ******
p - set speed
m - no CR/NL mapping
n - no flow control
h - hardware flow control
s - software flow control
q - quit help
*************************
Command: úUÚUâ
******Set speed *********
a - 1200
b - 2400
c - 4800
d - 9600
e - 19200
f - 38400
g - 57600
h - 115200
i - 230400
j - 460800
q - quit help
*************************
Command: ÚUÚDÿHelp done!
survive for time second: 2
survive for time second: 3
survive for time second: 4
survive for time second: 5
survive for time second: 6
survive for time second: 7
survive for time second: 8
survive for time second: 9
survive for time second: 10
survive for time second: 11
survive for time second: 12
survive for time second: 13
survive for time second: 14
survive for time second: 15
survive for time second: 16
survive for time second: 17
survive for time second: 18
survive for time second: 19
survive for time second: 20
survive for time second: 21
survive for time second: 22
survive for time second: 23
survive for time second: 24
survive for time second: 25
survive for time second: 26
survive for time second: 27
survive for time second: 28
survive for time second: 29
survive for time second: 30
survive for time second: 31
survive for time second: 32
survive for time second: 33
survive for time second: 34
survive for time second: 35
survive for time second: 36
survive for time second: 37
survive for time second: 38
survive for time second: 39
survive for time second: 40
survive for time second: 41
# <- dead herein the v1.6 pcb change version,even start as wifi server,it can work just fine
root@OpenWrt_SLboat_Mod_V1:/etc/config# microcom -D/dev/ttyACM0
ñØ
**********Help***********
x - exit microcom
b - send break
l - log on
s - start script
t - set terminal
q - quit help
*************************
Command:
******Set terminal ******
p - set speed
m - no CR/NL mapping
n - no flow control
h - hardware flow control
s - software flow control
q - quit help
*************************
Command: »È(&á¬@¡È
******Set speed *********
a - 1200
b - 2400
c - 4800
d - 9600
e - 19200
f - 38400
g - 57600
h - 115200
i - 230400
j - 460800
q - quit help
*************************
Command: Help done!
survive for time second: 0
survive for time second: 1
survive for time second: 2
survive for time second: 3
survive for time second: 4
survive for time second: 5
survive for time second: 6
survive for time second: 7
survive for time second: 8
survive for time second: 9
survive for time second: 10
survive for time second: 11
survive for time second: 12
survive for time second: 13
survive for time second: 14
survive for time second: 15
survive for time second: 16
survive for time second: 17
survive for time second: 18
survive for time second: 19
survive for time second: 20
survive for time second: 21
survive for time second: 22
survive for time second: 23
survive for time second: 24
survive for time second: 25
survive for time second: 26
survive for time second: 27
survive for time second: 28
survive for time second: 29
survive for time second: 30
survive for time second: 31
survive for time second: 32
survive for time second: 33
survive for time second: 34
survive for time second: 35
survive for time second: 36
survive for time second: 37
survive for time second: 38
survive for time second: 39
survive for time second: 40
survive for time second: 41
survive for time second: 42
survive for time second: 43
survive for time second: 44
survive for time second: 45
survive for time second: 46
survive for time second: 47
survive for time second: 48
survive for time second: 49
survive for time second: 50
survive for time second: 51
survive for time second: 52
survive for time second: 53
survive for time second: 54
....
survive for time second: 154
survive for time second: 155
survive for time second: 156
survive for time second: 157
survive for time second: 158
survive for time second: 159
survive for time second: 160
survive for time second: 161
survive for time second: 162
....
survive for time second: 1390
survive for time second: 1391
survive for time second: 1392
survive for time second: 1393
survive for time second: 1394
survive for time second: 1395
survive for time second: 1396
survive for time second: 1397
survive for time second: 1398
survive for time second: 1399
survive for time second: 1400
# still working...so,i think the problem is cause by the wifi kind stuff,and maybe related the chip,and the v1.6pcb change,the tp-link is start take care this,dont why,that's pretty wired,if can have more information about the AR9331-AL3A and AR9331-AL1A's diffrent,that's maybe can help.
another thought is the usb2.0 device maybe have better electrical performance design,so it's not easy be influence.
and in the same time,the [v1.6] has survive more than 600 second,the[v1.1] test with arduino mega,still less than 1 minute.
*************************
Command: Help done!
survive for time second: 2
survive for time second: 3
survive for time second: 4
survive for time second: 5
survive for time second: 6
survive for time second: 7
survive for time second: 8
survive for time second: 9
survive for time second: 10
survive for time second: 11
survive for time second: 12
survive for time second: 13
survive for time second: 14
survive for time second: 15
survive for time second: 16
survive for time second: 17 # v1.1 dead herenext i wana try is test other [v1.6 pcb change]wr703n,seem if same,and test some others[v1.1]see how is going,and i wana to remove one [v1.6]'s F1,see how is going.
(Last edited by slboat on 27 Jul 2013, 11:08)
Thank you for all your tests, Sen!
F1 looks like a common mode choke: this is used as en EMI protection to remove common mode (i.e. between the 2 wires) spurious emissions.
I don't know how this can be related to our problem, but who knows?
The AR9331-AL3A vs. AR9331-AL1A may be what makes things work: Atheros may have corrected a hardware bug within the chip with this new version.
What I suggest is to remove the F1 choke on one 1.6 PCB and replace it with a solder bridge or 0R shunt resistors, and see what happens: if this still works ok, then this may well be the new chip revision that makes thing work...
Otherwise, the PCB rev. is still 1.1, so the change is only a BOM change.
Squonk wrote:
Thank you for all your tests, Sen!
F1 looks like a common mode choke: this is used as en EMI protection to remove common mode (i.e. between the 2 wires) spurious emissions.
I don't know how this can be related to our problem, but who knows?
The AR9331-AL3A vs. AR9331-AL1A may be what makes things work: Atheros may have corrected a hardware bug within the chip with this new version.
What I suggest is to remove the F1 choke on one 1.6 PCB and replace it with a solder bridge or 0R shunt resistors, and see what happens: if this still works ok, then this may well be the new chip revision that makes thing work...
Otherwise, the PCB rev. is still 1.1, so the change is only a BOM change.
i still test on 3 v1.1 route,seems one just be fine(more than 3000 second),so in the v1.1,there just some chance will happen to this,and if you like,i wana send you one new pcb change wr703,so you may can have some test on you self.
im test on those route for now:
this one cant survire more than 60second
(Last edited by slboat on 27 Jul 2013, 15:12)
v1.1 4 routes test results:
M038 WR703N V1.1(PCB V1.1)
[USB-ACM:Arduino UNO]测试生存时间超过100秒未死，然后中断看起来很稳固 - [Short Time Pass > 100s]
[USB-ACM:Arduino UNO]测试超过237秒未死，哇喔 - [Short Time Pass > 237s]
[USB-ACM:Arduino UNO]测试超过108秒未死，接着超过25205秒，最终死亡于57083秒（15小时） - [Long Long Time Pass > 15hrs][Still < 57083s]
M044 WR703N V1.1(PCB V1.1)
[USB-FTDI:Arduino Mega]测试生存时间不到14秒，很快的死掉 - [Short Time Faild = 14s]
[USB-FTDI:Arduino Mega]测试33秒，依然死掉 - [Short Time Faild = 33s]
[USB-FTDI:Arduino Mega]测试未26秒死亡时间 - [Short Time Faild = 26s]
M048 WR703N V1.1(PCB V1.1)
[USB-ACM:Arduino UNO]超过760秒 - [Short Time Pass >760s]
[USB-FTDI:Arduino Mega]测试3626秒死亡 - [Long Time Faild = 3626s]
[USB-FTDI:Arduino Mega]测试345秒死亡 - [Long Time Faild = 345s]
[USB-FTDI:Arduino Mega]测试2967秒死亡 - [Long Time Faild = 2967s]
M040 WR703N V1.1(PCB V1.1)
[USB-FTDI:Arduino Mega]测试1262秒死亡 - [Long Time Faild = 1262s]
[USB-FTDI:Arduino Mega]测试1363秒死亡 - [Long Time Faild = 1363s]
[USB-FTDI:Arduino Mega]测试1466秒死亡 - [Long Time Faild = 1466s]here is v1.6(pcb change)'s test
测试V1.6（PCB改变后的）设备
M046 WR703N V1.6(PCB ADD F1) S/N:137073
[USB-FTDI:Arduino Mega]超过1066秒，意外掉电 [Short Time Pass > 1066s]
[USB-FTDI:Arduino Mega]超过28691秒 [Short Time Pass > 28691s]
M036 WR703N V1.6(PCB ADD F1) S/N:137073
[USB-FTDI:Arduino Mega]超过300秒 [Short Time Pass > 300s]
[USB-FTDI:Arduino Mega]839秒死 [Long Time Faild = 839s]
[USB-FTDI:Arduino Mega]1458秒死 [Long Time Faild = 1458s]
[USB-FTDI:Arduino Mega]1021秒死 [Long Time Faild = 1021s]
[USB-FTDI:Arduino Mega]798秒死 [Long Time Faild = 798s]
M045 WR703N V1.6(PCB ADD F1) S/N:136198
[USB-FTDI:Arduino Mega]76秒死，可能有供电问题 [Short Time Faild = 76s]
[USB-FTDI:Arduino Mega]77秒死，应该不是供电问题 [Short Time Faild = 77s]
[USB-FTDI:Arduino Mega]73秒死 [Short Time Faild = 73s]
[USB-FTDI:Arduino Mega]86秒死 [Short Time Faild = 86s]
[USB-FTDI:Arduino Mega]18秒死 [Short Time Faild = 18s]
[USB-FTDI:Arduino Mega]5秒死 [Short Time Faild = 5s]
[USB-FTDI:Arduino Mega]138秒死，一个奇怪的事情是，RX看起来也不点亮了，难道Arduino也有意外？ [Short Time Faild = 138s]
M047 WR703N V1.6(PCB ADD F1) S/N:137073
[USB-FTDI:Arduino Mega]超过2175秒 [Short Time Pass > 2175s]
[USB-FTDI:Arduino Mega]1671秒死亡 [Short Time Pass > 1671s]so it not always luck,it still have the problem.
(Last edited by slboat on 28 Jul 2013, 12:58)
1. I am a newbe.
2. Found this discussion via google. I would like to use the MR3020 as a bridge between USB serial and Wifi.
Which version of WRT should I Flash to get that functionality ?
Will that latest version of WRT be able to connect to my office Wifi and a PL2303 USB-serial converter out of the box ?
Are there any web sites that help explain the steps necessary to accomplish these tasks ?
I do understand that I need a USB 2.0 HUB.
Thank You
donhamilton,
Virtually any version of openWrt will do, but probably the best and most stable version for you would be Attitude Adjustment 12.9 -- http://downloads.openwrt.org/attitude_adjustment/
There are a number of ways to use openWrt and the WR703N (with "high speed" hub as reported in dmesg--not just a hub labeled or sold as "USB 2") to get data from a serial device to a web-enabled device.
My favorite method is to set up the 703n as a wireless client with a script (in /etc/rc.local) to use netcat (nc) to submit the data to my "collector" device, which accumulates and process data from different openWrt-connected serial devices.
Here is a sample /etc/config/wireless file
config wifi-device radio0
option type mac80211
option channel 11
option macaddr 14:e6:e4:e1:f4:3a
option hwmode 11ng
option htmode HT20
list ht_capab SHORT-GI-20
list ht_capab SHORT-GI-40
list ht_capab RX-STBC1
list ht_capab DSSS_CCK-40
# REMOVE THIS LINE TO ENABLE WIFI:
# option disabled 1
config wifi-iface
option device radio0
option network wireless
option mode sta
option ssid someSSID
option encryption psk
option key someKeyDon't just copy this--your macaddr will be unique, and you'll need the appropriate channel for your network (and of course your own ssid and key).
Here is a copy of my /etc/rc.local which runs a script which I put in /etc/config/log.sh (in that directory so it would be preserved over sysupgrades):
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
/etc/config/log.sh &
echo "rebooted $(date +%y%m%d%H%M%S)" >> /home/user0/boot.txt
exit 0Here is /etc/config/log.sh
#!/bin/sh
stty -F /dev/ttyUSB0 2400 clocal cread cs8 -cstopb -parenb -crtscts
cat /dev/ttyUSB0 2>/dev/null | while read v1 v2 v3 v4; do
echo "$v1 $v2 $v3 $v4 $(date +%y%m%d%H%M%S)" >> /home/user0/Rx01.txt
echo "$v1 $v2 $v3 $v4 $(date +%y%m%d%H%M%S)" | nc 192.168.1.70 8086 &
sleep 1s ; kill `pidof nc`
doneThis logs the serial input locally, and sends it with "nc" to a netcat listener on 192.168.1.70, port 8086.
(Last edited by lizby on 19 Aug 2013, 15:20)
@lizby
Ohboy !
I will repeat, I am a newbe.
"Virtually any version of openWrt will do," the link you sent has 26 sub-directories.
None say "WR703N", so which directory has the binary for the WR703N ?
Or can I use any one of them ?
Don--sorry.
First flash: http://downloads.openwrt.org/attitude_a … actory.bin
Subsequent flashes if needed: http://downloads.openwrt.org/attitude_a … pgrade.bin
You want to use squashfs images (which, among other things, provide "failsafe" recovery with telnet)--"factory" first because you are replacing the factory firmware (what comes on the device); then if later flashes are needed (you shouldn't need them because Attitude Adjustment is stable), you use the "sysupgrade" version.
(Last edited by lizby on 19 Aug 2013, 15:27)
Hi folks,
Another noob here.
Do I understand it correctly that you guys are trying to stabilize the voltage to the usb part of the chip by adding extra wires? And that the current trails haven't yet solved the issue?
@slboat, what usb hub are you using in post #164?
I'm going to try to switch off the WiFi when good usb connection is critical, but I hope you guys can find a better solution.
Page 7 of 13