Hey All,
this is the first of many upcoming troubleshooting tools. Some of the issues with the Yun, we see over and over again. This first sketch will get some basic information. If you have an issue or you see someone in the forum, point them toward this sketch. As we gather facts for this, I'll add notes to the wiki part of github for this.
Here is the URL for the sketch. Feel free to make a pull request to make changes you would like to share in this sketch.
A note on operating the sketch: after you start the sketch it will take a second or two to start outputting information. It will get
time of day
list of APs
the wifi radio configuration
the default gateway (to the internet), if any
SAMPLE OUTPUT
======== 2015-06-07T19:11:21
Scanning for AP (Access Points) that are broadcasting.
ESSID:"ATT2U6u278"
ESSID:"ATT4FWBkmS"
ESSID:"Culinary Institute of America"
Getting Wifi configuration Information.
wlan0 IEEE 802.11bgn ESSID:"ATT4FWBkmS"
Mode:Managed Frequency:2.412 GHz Access Point: 94:62:69:D7:10:00
inet addr:192.168.1.193 Bcast:192.168.1.255 Mask:255.255.255.0
Link Quality=60/70 Signal level=-50 dBm
Gateway: 192.168.1.254
Did you take a look at /usr/bin/pretty-wifi-info.lua? There are a few additional fields it lists that may be helpful, such as encryption method and active time (helps to determine if the connection is going in and out.)
Did you take a look at /usr/bin/pretty-wifi-info.lua? There are a few additional fields it lists that may be helpful, such as encryption method and active time (helps to determine if the connection is going in and out.)
Okay. I looked at it. I can trim more information from everything. or add that script. Which sounds better?
Tough call... just calling the script is easier, incorporating the data into your existing code will give better looking output? How fussy are you about the way the output looks?
ShapeShifter:
Tough call... just calling the script is easier, incorporating the data into your existing code will give better looking output? How fussy are you about the way the output looks?
@ShapeShifter,
personally the only fussiness I have is to keep a consistent look; this so we can say something like, "On the top left, you'll see....."; other than that I'm fine. If you look at the code, I don't do much formatting. In most cases, I just cut an entire line - when I just need one piece of data -- like the IP assigned to the Yun.
Seems to me that the wifi on the Yun is a bit unreliable.
I have a sketch that posts data to a web site using the HTTPClient every minute, but after about 90 minutes it starts to fail.
I also logged some data to an SD card every 15 seconds or so and at about the same time as the failure the reported wifi signal strength from the pretty-wifi-info output drops to 0%. After this point every once in a while it jumps back to about 40% briefly (so I then get the data posted), then falls away again.
I'll have to find a way to dig deeper on what is happening here, but until I resolve this the Yun for this application is looking like a no go.
GrantA:
Seems to me that the wifi on the Yun is a bit unreliable.
I have a sketch that posts data to a web site using the HTTPClient every minute, but after about 90 minutes it starts to fail.
I also logged some data to an SD card every 15 seconds or so and at about the same time as the failure the reported wifi signal strength from the pretty-wifi-info output drops to 0%. After this point every once in a while it jumps back to about 40% briefly (so I then get the data posted), then falls away again.
I'll have to find a way to dig deeper on what is happening here, but until I resolve this the Yun for this application is looking like a no go.
@GrantA,
the purpose of this tool is to get us on the path to resolving this problem. The issue you are stating appears to be related to production run. Until we get some real data to shove into Qualcomm's face, it is only talk.
Jesse
What I don't understand is why you are going through the troubles of running a sketch, on the AVR side of the Yun, when all the networking, including WiFi, is handled on the Linux side?
PCWorxLA:
What I don't understand is why you are going through the troubles of running a sketch, on the AVR side of the Yun, when all the networking, including WiFi, is handled on the Linux side?
Ralf
@PCWorxLA
Sure. The biggest issue we have encountered while assisting people with their wifi is they are NOT familiar with Linux, wif, and networking.
People that have some knowledge of wifi, can usually read the FAQ, forums, or google to get a stackoverflow answer.
People that have some knowledge of network, can usually get by - once we point them to OpenWrt.
People that have some knowledge of Linux, usually just need hand holding.
People in the category with none of the above is the hardest. It usually takes at least two of us to get them going. That could be Angelo999, ShapeShifter, SonnyYu or myself. Occasionally someone chines in, and that is appreciated.
Given this, the easiest thing to do is have any person run that sketch. It solves several issues.
the time of day, let's us know that the clock is running correctly on the YUN, so they can do proper upgrades. There is a bug in the opkg
the list of APs let's us know if possibly they have a noisy network. Or better yet, if they can see the AP in their house.
Mode let's us know if the Yun is running in AP (master) mode or client (managed) mode
the IP let's us know how to ssh into the device, should it be needed.
The Gateway let's us know, if they are connect to the home AP and possible connected to the Internet.
If you have a suggestion for something to add, please let me know. Shapeshifter has suggested adding some things from /usr/bin/pretty-wifi-info.lua, which would include the SSID of the Yun.
To add to Jesse's comments: Yes, all of the things that this sketch can do, can be done over the Linux command line. But if the person knows absolutely nothing about Linux, or networking, we first have to describe how to SSH into Linux and log in, then describe the commands that need to be run.
But what if the networking problem that is being diagnosed prevents connecting with SSH? Or we don't know the Yun's address to be able to make that connection? Then the next step is to load the YunSerialTerminal sketch, open the serial monitor, and then once again describe the commands that need to be run.
Or, there's Jesse's solution, which I think is a very good one: Load his sketch, open the serial monitor, and copy/paste the output. Anybody who is using an Arduino should be able to accomplish that, even if they know absolutely nothing about Linux or using a command line.
Jesse's just trying to make it simple and foolproof. It may not be the most efficient way to get the information when looking at it from the point of view of the processing involved, but it's very efficient when looking from the point of view of posting instructions and what what the user needs to do.
Sorry, but I just think it's wasting resources in all the wrong places/directions.
Linux is not rocket science, someone should be able to access the shell on his/her Yun and download/edit/start a simply Python/Lua script.
At some point or another, they will have to deal with it anyway. Unless you are using a Yun "just as another Leonardo", people have to interact with the Linux side to use the Yun's special/distinguishing features.
And it seems IMHO that most problems that people have is to understand the concurrent nature or the Yun, with two different CPUs/program(ming) environments, and different resources directly/easily accessible on either side. And the WiFi functionality of the Yun is clearly a Linux side feature/function and that's where IMHO any troubleshooting should be done.
Going "down" to the AVR level, having to pass information from Linux to AVR, seems more like adding an additional tripwire for such inexperienced people rather than helping them...
I think at long last I have resolved my 'wifi issues'.
I ran some experiments last week by powering the Yun for an extended period from the PC USB power supply and logging data using the wifi connection.
The signal strength at this location was in the 60-80% range consistently.
I ran the sketch for several days without many issues. My conclusion after this was it is either the power supply of the signal strength causing me issues.
Next I used an old phone charger to power the Yun (right next to where the PC is) and this was problematic almost immediately. The power supply was rated at 5V 500mA. Swapped it for another rated at either 800mA or 1A, and it worked well for a day or so.
Last test was to run it in another location where the signal strength quite often drops below 30%. Using the more beefed up power supply it has now been running for several days. I've even updated the running sketch via wifi, and also remoted in with WinSCP and checked the log file on the SD card.
All going well. The log shows a few times when the HTTP server has not responded in time, or with an error message, but the number of errors is small and acceptable.
SO the message here is that the Yun wifi seems to be quite reliable when the power supply is up to the task. I don't know whether it is the voltage or the current from the original power supply I used, but now that I have seen it working as expected for about 5 days now it does show that a good power supply is essential in this situation.
My confidence in the Yun has been mostly restored now.
I can now add more functionality to the sketch and see how that goes.
Have had some type of failure so will have to wait until I get home from work to check the log to find out why.
However, it appears that the Arduino side still thinks it is going OK as this morning it was indicating that it was trying to send data every minute or so.
