frustrating, all of my production boards have hot-glue to stop the bl cable coming off. When I tried to remove the hot-glue to reveal the pin, the cable came off 
Hi tridge,
Looks like that did the trick! WiFi is working again. It was indeed the lower pad (TP4). It had a weak pull-up on it, so I pulled it down with a jumper. The upper one (TP5) was already at 0V.
I might have left the jumper on for too long though. It seemed to reboot a whole bunch of times after flashing. Unfortunately, I didn’t keep a log of those printouts and my memory is quite volatile.
The firmware upgrade web page showed that the ArduPilot version was 2017-07-29 (3.6.0-dev 6fc59437) and the transmitter at 2017-07-24. I didn’t record the version of the Sonix board firmware before I bricked it, but presumably it had a similar version as well? Is this an expected firmware version?
I updated to the current latest (and also stable?) of 2017-10-14 dfd2d838 on the Sonix, 2017-10-14 (3.6.0-dev d84c8a4f of ArduPilot, and 2017-10-14 of transmitter.
I’ll see if I can reliably break it again in the next few days with the latest firmware and maybe with the other version. Thanks for the very prompt response.
These are the pins that I’ve poked so far:
I was planning on taking pictures of all the boards (with better lighting than my one above) and eventually annotating all the pins and submitting a PR to put them on the SkyViper doc page or similar.
thanks! glad its working.
that is quite old, the app was supposed to have guided you towards putting on a newer version of the firmware. Did it do that? Or did you not use the app?
thanks. The only thing I can think of now is if the string for SSID or password managed to break the parser in the sonix wifi lib, and that causes it to crash when starting wifi.
Do you know what wifi SSID and password you set?
that would be very welcome!
btw, if you want to poke around at the software level on the sonix, try telnet to tcp port 2017. Lots of stuff there.
Source code here:
the ArduPilot related stuff for that board is here:
From looking at the source e.g. here and here and the wiki, adding the file WIFI.TXT with ssid and password of an existing wifi network (each on separate line, no space) on the sd card can put the viper in wifi station mode (or as a wifi client, changing from default access point mode):
STATION_SSID=yourSSID
STATION_PASS=yourpassword
I’ve tried this but for some reason nothing seems to change. I would have thought that with a wifi router with an ip address of say 192.168.99.10, I should be able to ping the viper (and access web server) if it is configured in station mode with ip address of 192.168.99.1. Yet I still see its SSID advertised and can’t ping it unless I join its network.
Anyone know what I might be missing?
Hi OlivierB,
Try checking that the filesystem and your WIFI.TXT on the microSD is readable though the web interface. If not, try formatting the microSD through the web interface.
In my case, the microSD worked for bootloading, but not for anything else until the format. It showed up as 0 GB though the web interface. All the while, it was broadcasting it’s own SSID.
A good indicator of the filesystem being good seems to be that a SKYVIPER folder is created and the photo and video recording works (recording did not work for me before).
So far, I’ve had station mode connect successfully to my Android phone as a hotspot. When I try with two different 2.4 GHz access points, a Netgear Nighthawk R7000 and a Tenda AC15, association is successful, but DHCP hangs, so I’m looking into that.
Example serial console output:
…snip…
[fwupgr]sd_fwupgrade_task: sd_firmware_upgrade check…
sd hotplug chages [0, 1]
Checking for FC fw in flight_fw.abin
invalid FC FW size -1
Checking WIFI.TXT
Setting up for WiFi station SSID=‘MySSIDwasHere’ PASS=‘MyPasswordWasHere’
[rec] - chk_cardsize(108): SD (sz:14803 /free:14798 MB)
[rec] - chk_cardsize(110): Sched (used: 3 /available: 11100 MB)
[rec] - chk_cardsize(112): Picture (used: 0 /available: 1480 MB)
[rec] - rec_import_files(638): (Record) with num (1) res (2)
[rec] - rec_import_files(638): (Snapshot) with num (10) res (2)
[INFO]WiFiTask: WiFi Task Start…
[INFO]WiFiTask: EHCI Ready…
[INFO]MLME_ModeInit: DEV MAC ec:3d:fd:21:37:fc
[INFO]Set Wifi channel(1)
[INFO]WiFiTask: Wifi Initail OK…
[INFO]WiFi Station Mode Initial Started…
[INFO]Set Wifi channel(1)
[INFO]Set Wifi channel(4)
[INFO]Set Wifi channel(7)
[INFO]Set Wifi channel(10)
[INFO]Set Wifi channel(13)
[INFO]Set Wifi channel(3)
[INFO]Set Wifi channel(5)
[INFO]Set Wifi channel(9)
[INFO]Set Wifi channel(12)
[INFO]Set Wifi channel(2)
[INFO]Set Wifi channel(6)
[INFO]Set Wifi channel(8)
[INFO]Set Wifi channel(11)
[INFO]Set Wifi channel(11)
[INFO]ScanSmartConfigBeacon: Get Beacon Info Done! Auth(7), Enc(3), Channel(11)
[INFO]Set Wifi channel(11)
[INFO]ParseBeacon: Found matched SSID (MySSIDwasHere)
[WARN]MGMTENTRY_Add: Add Node failed: Exist Node
[INFO]ProbeRsp from C8-3A-35-58-C4-A1
[INFO]Auth to C8-3A-35-58-C4-A1
[INFO]Auth from C8-3A-35-58-C4-A1
[INFO]Assoc to C8-3A-35-58-C4-A1
[INFO]SendAssocReq: Using WPA2 - Authmode = 7, RSN len = 20
[INFO]Auth from C8-3A-35-58-C4-A1
[INFO]Auth from C8-3A-35-58-C4-A1
[INFO]Assoc from C8-3A-35-58-C4-A1
[INFO]RTMPCheckAssociation: Connected to AP = C8-3A-35-58-C4-A1, channel (11)
[INFO]AsicAddPairwiseKeyEntry: WCID 1 Alg=AES
[INFO]PeerPairMsg3Action: AuthMode(WPA2PSK) PairwiseCipher(AES) GroupCipher(AES)
[INFO]Start DHCP…ret = 0
If working, the viper will print its IP address after a few seconds. When not working, nothing is printed
we could add the IP as an option in WIFI.TXT, instead of using DHCP
I used dhcp as I though it would be easier for swarming to have the same microSD contents on every copter
Definitely, much easier with dhcp. But option would be nice too 
Yes, the app did prompt me to upgrade out-of-the-box. But I didn’t have a microSD card that day so I had declined.
The SSID was “Flying Fluffball” with a password of “Potato92!”, which doesn’t seem all that exotic. I could not break it again with either old or new firmware.
I encountered no issues factory resetting over and over again while interrupting it at various times. I suppose it was just a one-time glitch unless it somehow happens again and I better remember what actions lead to it.
Thanks Kevin. I don’t have it hardwired via USB right now so can’t see much. But will solder soon …
I upgraded from an old (8/26) version and after that the network disappeared, so now I know WIFI.TXT is read. Doubt it’s the SD card, when in access mode I can see the file system fine. But can never see WIFI.TXT since I have wifi connection only … It’s got to be something with dhcp, weird thing though is that it won’t access either a wifi router or my phone as hotspot. I also tried re-formatting and downloading from the web server, but no different. And could see WIFI.TXT just fine before rebooting.
Interesting that you have it working tethered to your phone but not your router. Definitely must have something to do with dhcp … Probably same with me, but can’t explain why it wouln’t work with my phone either. Console will hopefully tell!
When trying with one of the routers (Netgear Nighhawk), I had my computer listening in with Wireshark. I saw the viper broadcast DHCP DISCOVERs every few seconds, so that could be one way to check whether association was successful.
However, the router itself did not log that it received any DISCOVERs (and sent back OFFERs) like they did with my phone and other devices.
Problem solved, it was the SD card(s) … 4GB Sandisk no name, 16GB Sandisk no name, no go. 16GB Sandisk Extreme+, 32GB Sandisk Extreme+, works like a charm. What threw me off is that all work with access mode, upgrading, show photos, videos, etc … But the first two just won’t do station mode. Also I’ve had problems just formatting a card and adding WIFI.TXT station mode if not by the web interface.
In my case when it didn’t work sniffing didn’t help. I could not see anything, no ARP, DHCP, MAC address, no nothing from the Viper(s).
hmm, interesting, I wonder if there is a timing issue with the speed of mount of the microSD?
I’m actually surprised at the level of interest in station mode. Now that I know people are interested, I could look at a different method of setting it up.
The reason I used WIFI.TXT instead of just putting it in the video board NVRAM parameters is I needed to give some way to recover in case it didn’t work. As there is no button on the copter the obvious method was the microSD.
I could do something like have a setting in the NVRAM interface in the web page, but it only activates if it has been enabled in the web interface and the drone is booted while upside down. Would that be better?
Another possibility is to have a setup page for station mode in the web interface, and have a “test” button. That would enable station mode for N minutes (you’d choose for how long in the web UI). Then once you know its all OK you could make it permanent with another button.
Problem solved, it was the SD card(s) … 4GB Sandisk no name, 16GB Sandisk
no name, no go. 16GB Sandisk Extreme+, 32GB Sandisk Extreme+, works like a
charm. What threw me off is that all work with access mode, upgrading, show
photos, videos, etc … But the first two just won’t do station mode. Also
Wow! That’s some persistence, right there.
My guess is a race condition - some cards being faster to detect than
others.
Such a cool idea, that would be awesome! While station mode is necessary for multiple vehicles, being able to choose without downloading would be a great plus.
No button, no problem, we’ve got gravity! 
Sure looks like it. Right around mount time as Tridge is guessing.
Station mode is just awesome for multiple vehicles and full fledged GCS. Keep internet connection, plus with static DHCP leases on router just plug any of them on and here they are, no matter how many, and can be seen from anywhere. The Internet of flying things!
That would work too. But the gravity method I think is the best.
