PilotAware
British Forum => Technical Support => Topic started by: Colenso on November 23, 2017, 05:11:49 pm
-
New to PAW and having trouble with connection to Lenovo Tab3 7 and Sky Demon.
PAW works perfectly with my iPad and a friend’s Nexus tablet but on the Lenovo I get the message “Waiting for Device” every few seconds.
PAW is mounted just under the dash of my SkyRanger and I have used all the connections as recommended by PAW. i.e. Anker USB plug, original power lead and external GPS dongle from PAW shop.
I have also connected PAW to my Trig transponder using the correct lead and I have my position shown on the transponder.
Can anyone suggest a solution?
Searching through the forum I have found suggestions re altering the WiFi power output, the Wifi Mode, (B/G), and also selecting a Static address.
Before changing any of these could anyone point me in the right direction?
Thanks in advance.
-
Hi Can I just confirm the following
when you say it works perfectly with ipad and nexus, can I confirm this is in the same installation ?
ie, can you run the ipad side by side with the nexus, and see the ipad running fine, nexus having an issue
Also can you confirm that the nexus is able to get a good WiFi connection to PilotAware - try simply running the RADAR screen from the web interface.
Finally how are you connecting, are you using
- FLARM, or
- PilotAware
Thx
Lee
-
Lee,
The problem is with a Lenovo tablet - not the Nexus. Just did a search and found several others including Vic had similar problems with Lenovo Tabs when the 20170719 software was first introduced.
Colenso,
Can you confirm what PilotAware software version you are running and what Kernel your Raspberry Pi is running please (you can find this on the ‘PLATFORM’ line on the PilotAware Home Screen - by logging in to 192.168.1.1).
Regards
Peter
-
Thanks for the quick response.
iPad and Lenovo (Android V 6.0) are running off the same system and both getting good WiFi connection to PAW.
I’m on the latest software for PAW and connecting through SD using ‘PilotAware’ and ‘Live Data when Planning’.
I flew this morning and had the Lenovo and iPad connected. The iPad ran perfectly but the Lenovo kept showing ‘Waiting for Device’ every few seconds. I could not get a screen shot of this message in that it only appears on the screen for a second or two.
After I had landed I got another message on the Lenovo only. I’ve attached a screen shot of this and named it as ‘disposed’.
The rest of the screen shots were taken before take off and hopefully will provide all the information necessary.
Thanks for your help.
Three more attachments follow this post.
-
More screen shots.
-
Hi Colenso,
Thanks for the info and screenshots. Your PilotAware settings all look fine from the screenshots and you are certainly ‘seeing’ traffic Ok - at least on the iPad. You said earlier that PilotAware was also running fine with your friend’s Nexus tablet. Did that include showing traffic? If so, it looks very much like the issue may be peculiar to your Lenovo. Did you manage to see any traffic at all on it, or did the ‘waiting for device’ warnings prevent this?
I see that as per your OP, you have your PAW configured for ADSB-Out, but that shouldn’t be relevant.
I’m not sure of the exact meaning of the Android warning, though it does seem to indicate an issue with UDP connectivity - Lee will hopefully be able to help with that when he comes on. Have you tried running SD on the Lenovo via FLARM (TCP) Connectivity? You can run both devices at the same time each using different connectivity. Worth a try if you haven’t.
Hopefully Lee will come on soon and confirm.
Regards
Peter
-
Hi again Colenso,
Just re-reading the earleir posts and noticed one slight issue with your configuration, though it won't affect connectivity. As you are running a transponder, you MUST run Mode C/S Select in Mode C S + Filter (Beta) as the filter is needed to take out what are effectively Mode C responses to Altitude interrogations from your own Transponder.
Regards
Peter
-
Thanks for your help. I will change the settings re the Transponder and check if using Flarm gets rid of the Waiting for device message.
Traffic is shown on all devices and I was seeing traffic on both the iPad and Lenovo whilst flying yesterday. When the Waiting for device message appears I lose both 'my aircraft' and traffic on the Lenovo but they quickly reappear when connection is restored. The iPad works flawlessly which does seem to suggest that the problem is with the Lenovo.
Thanks once again.
-
I could only work in the hangar this morning but after changing to Flarm as a connection on SD, PAW on the Lenovo ran without once showing the 'Waiting for Device' message. I had it switched on for about 30 minutes. Hopefully this has now solved the problem. but will give it a full test when I next fly.
I also changed the configuration to Mode C S + Filter (Beta) as you advised.
Thank you very much for your help.
-
You are very welcome.
Looks like the Lenovo doesn’t like the ‘UDP’ connectivity, but is happy using the FLARM ‘TCP’ option. That’s what we all used until relatively recently, so should be fine. Let us know how it goes in the air. This will hopefully also be helpful to other Lenovo Tab Users reading this thread.
Best Regards
Peter
-
Glad to hear this is solved, but I cannot believe that this tablet does not support UDP
UDP is used by all streaming services for audio and video, so these would not work.
I suspect the issue could be with SkyDemon
A good test would be to use an application which runs a
'UDP Server'
and configure it to listen on port 2000
If it receives data from PilotAware, then we know connectivity is established.
Thx
Lee
-
On the assumption that PAW is just doing a UDP broadcast, then if there is a software firewall on the tablet unless SD registers to open the UDP port it will be blocked. With UDP broadcast you just open a port and await traffic to arrive, with TCP you connect to the remote end and any FW will see that and permit data to flow to/from the remote end.
Just a thought, all my Android tablet devices currently stacked in a safe place, and I can't remember where that is at the moment to check...
-
On the assumption that PAW is just doing a UDP broadcast, then if there is a software firewall on the tablet unless SD registers to open the UDP port it will be blocked. With UDP broadcast you just open a port and await traffic to arrive, with TCP you connect to the remote end and any FW will see that and permit data to flow to/from the remote end.
Just a thought, all my Android tablet devices currently stacked in a safe place, and I can't remember where that is at the moment to check...
Its close, but we are using unicast rather than broadcast.
So we monitor the connected devices and explicitly send UDP Packets to those connected.
So SD is effectively running a listening service, but as you say, if the port is blocked - that would be an issue
Thx
Lee
-
On the assumption that PAW is just doing a UDP broadcast, then if there is a software firewall on the tablet unless SD registers to open the UDP port it will be blocked. With UDP broadcast you just open a port and await traffic to arrive, with TCP you connect to the remote end and any FW will see that and permit data to flow to/from the remote end.
Just a thought, all my Android tablet devices currently stacked in a safe place, and I can't remember where that is at the moment to check...
Its close, but we are using unicast rather than broadcast.
So we monitor the connected devices and explicitly send UDP Packets to those connected.
So SD is effectively running a listening service, but as you say, if the port is blocked - that would be an issue
Thx
Lee
By connected do you mean a device that has an IP address or does it need to prompt for the unicast stream to begin? If the latter, then it *should* just work as the app opens it's listener port, but with Android who knows. It's possible a branded distribution from the likes of Lenovo may have additional software/apps/features enabled that need TLC.
Still not found where I have put my android devices, by office/lab is tiny so they must be VERY safe...
-
I still haven't had the chance to fly with the settings I've made but will report when I do.
I don't understand much of the recent posts but hopefully that makes no difference as long as it works!
Thanks once again for all the help.
-
Watching this thread with interest as I'm still having issues with my Lenovo Tab 3-8 and the latest PAW release. Not just in UDP where the disconnects are measured in seconds but less frequently in FLARM mode too. Strangely though, the last time I flew, my mate connected with his Lenovo Tab 3-7 and that was fine! Perhaps there's another app I am using that is doing strange things?
Every red dot in this plot corresponds with a disconnect of the UDP...
(http://i63.tinypic.com/2niceug.jpg)
Oddy, when I connect to PAW on the ground it is not as easy to replicate the problem!
I've even re-fired up my original Nexus 7 with a very stripped down Android build to try next time I fly to absolutely confirm it's not the PAW.
On the good side, we have recently upgraded the comms panel in the C172 with a PAR200A combined comms panel /8.33KHz transceiver which has bluetooth. Hanging a £10 bluetooth transmitter dongle into the audio socket of the PAW, pairing is flawless and the audio alerts are now wirelessly fed into the aircraft comms. :)
Just found an app for android called UDP sender / Receiver with which I'll have an experiment later today.
-
Vic, are you getting any messages flashing up on the SD screen?
-
Yes Ian, I get the "waiting for device", just like the original poster.
Following on, I've installed a handy little App UDP Terminal (https://play.google.com/store/apps/details?id=com.mightyit.gops.udpterminal&hl=en_GB) Which when connected to the PAW through WiFi allows me to see the UDP traffic.
I installed this on all three of my devices, Huawei P9 Phone, Original Nexus 7 2012 and the Lenovo Tab 8-3. When set to listen on UDP, on the Nexus and the Phone, there are regular blocks of messages, on the Lenovo it is missing out messages, sometimes for quite a few seconds. This is surely the 'problem' in action. The question is, why??
Watch this (rather awful and out of focus video, ) The Lenovo is in the middle https://youtu.be/6JUc7hQXELc clearly it's missing a lot of data! All 3 were connected to the PAW, I changed the wifi connection on the RH Nexus while the UDP app was running so it was titled another SSID
Can a mod please remove the 'solved' from this thread title!
-
Hi Vic
Great analysis!
From left to right, which is which ?
Also OS releases on each
Also I presume this is using UDP, can you do the same experiment on TCP ?
Thx
Lee
-
Hi Lee, from left to right..
Huawei P9, Android 7.0
Lenovo Tab 3 8, Android 6.0
Nexus 7 v1, Android 4.4.4 Cyanogenmod 11.0
I'll try repeating with TCP over the weekend and report back.
-
Hi Lee,
I now have a Lenovo Tab 3 7" and can confirm Vic's experience. I ran the UDP terminal alongside the iPhone running SD and the 'Waiting Device' message popped up several times at the same time on the iPhone as the data stream in UDP terminal paused on the Tab 3. So this is possibly the issue that I have been chasing my kit.
I have also discovered that if you change the PAW network setting to 802.11B, rather than the 802.11G default the messages reduce as do the pauses in data in the UDP terminal. It does not stop the issue. Oddly it looks as if it passes more traffic as well, but that may be a coincidence.
So in summary: I have experienced the issue on
iPhone 5
iPad mini first generation
iPhone 8
Lenovo Tab 3
I get the error messages on SkyDemon and Eazy VFR Basic and see the data pauses or gaps in a UDP port monitor.
We have replaced my entire PAW for known good and used different recommended Anker 12V-USB Power, Anker 10,000mAh and EC Technology 22,400mAh power banks.
This issue has only recently started for me, I suspect when I wiped my SD card and reimaged rather than upgrading using USB. I used to have 802.11B selected from the early days as it gave me the most reliable connection. When wiped, it will have defaulted to 802.11G. Of course, this may be a red herring? It could also be that this hides rather than eliminates the issue.
I was beginning to worry that I was the only one reporting this issue I suspect this is also the same symptoms as reported by Darren. and his co-owner.
-
Just to confirm that I do also get disconnects in FLARM (TCP) mode, tho far less frequent.
And, like above this has only manifested since the Pi kernel 4 update.
-
Hi Ian, Vic,
Please post the following information you are using for these tests
1. PilotAware Version
2. RPI OS Version
3. Wifi Mode B/G
4. WiFi Channel
5. WiFi Power
Also if you know what channel your home router is using, that would be useful
thx
Lee
-
Will do this evening
-
1. PilotAware Version 20170721
2. RPI OS Version Model B Pi2, Kernel=4.4.34
3. Wifi Mode B/G Both B and G
4. WiFi Channel 1
5. WiFi Power 1mW and 10mW
Home router is using Channel 1, not that it can see that WiFi network away from home.
I'll PM you further details
-
1. PilotAware Version 20170721
2. RPI OS Version Model B Pi2, Kernel=4.9.35-v7+
3. WiFi Mode B (G seems to make no difference to me)
4. WiFi Channel 9
4. WiFi Power ..Tried all!
5. Home Wifi on Channel 1
-
Curiouser and curiouser! (Said Peter)
It would be interesting to hear any update from Colenso on his experience since changing his Lenovo to FLARM/TCP. Don’t worry about the Technical complications, Colenso, just an experiential update would be useful to add to the pot.
Regards
Peter
-
UPDATE
I've managed a couple of flights in recent days. On both occasions I've had both the Lenovo and the iPad connected to PAW. The Lenovo is connected using FLARM and the iPad connected using PILOTAWARE. On the first flight the Lenovo lost the connection between SD and PAW but reconnected within a minute or so. The iPad kept the connection for the whole flight.
On the second flight I noticed no loss of connection on either machine but on examining the log of this flight on both machines I notice what appears to be a loss of connection but at different times. I'm assuming that the red dots on the time line signify a loss of connection. Please correct me if I'm wrong. I've attached two screenshots to show this.
Do you think that the problem is now resolved?
Thanks and best wishes for the New Year.
-
Colenso,
Do you have a phone or other device that is connected to 3G Data during the flight?
-
Hi and thanks for the quick response.
I carry an iPhone 6 in my jacket which presumably is connected to either 3G or 4G.
Will this affect PAW?
-
It's not 100% proven yet. But indications are that the iPhones are jamming the PAW signals to the other devices. The issue is intermittent so is taking me a while to prove 100%.
Try setting the iPhone to Airplane Mode. If you need to use it for the PAW, just turn on Wi-Fi after setting Airplane Mode. I would do this on your iPad as well.
Let me know if that does make a difference?
Cheers
Ian
-
I can eliminate Iphones as being the cause of the problem as far as I am concerned as we do not have such a device in the house! :-X
-
Do you have any phone with you in flight?
-
Not one that isn't in airplane mode.
For me this has only manifested in the latest release of pilotaware software.
-
OK, perhaps that is not the issue in your case. Still working on other possibilities.
-
Was the latest release of the PilotAware software the one which put in some routing thingie?
-
UPDATE
Flew for 1 hour today. I had both the Lenovo and iPad connected to PAW. Lenovo using FLARM, iPad using Pilotaware. My iPhone was switched to Flight mode. Both tablets running SD.
On Climb out the Lenovo disconnected, (with accompanying screen message), and I only managed to reconnect it about 10 minutes later. Thereafter it worked fine and I had no 'connection lost' messages on the screen. The iPad appeared to work fine and displayed no connection messages on the screen throughout the flight. (or at least I didn't notice any!).
On examining the virtual radar log on both tablets there are however several times when connection was lost. I attach screen shots of both tablets. Any advice or help would be appreciated and as usual thanks for the assistance so far.
-
I decided to leave the Lenovo on the ground when I flew yesterday and had no problems whatsoever using an iPad and a friends ASUS tablet. Both had no disconnection problems at all and PAW performed flawlessly.
I have now abandoned using the Lenovo.
Thanks to all who responded to my post.
-
You could always experiment with the Lenovo, trying various Wifi settings or Wifi connection apps and so on to see if there's any way around the problem. It might help other Lenovo users.
It might end up helping others with Wifi connection problems.
-
I have been using a Lenovo Tab7 since just before Christmas for testing and have had no issues with it. Mine is the cheapest model without 3G. Aparts from screen size I cannot imagine there is much difference between the the Tab7 and Tab10.
-
Unfortunately I've now sold the Lenovo so cannot carry out any more tests to resolve the problem.
Just for interest the model I had was:
Lenovo Tab3 7, model number: TB3-730F 2GB + 16GB.
The mini iPad is working fine and I'm grateful to all who tried to help me with this problem.
-
Mine is a TB-7304F Tab 1G + 16G, no connection issues with it and SD/PAW Perhaps you had a duff tablet?
At least you sorted now.
-
Mine still plays up (Tab 3-8) :( I'm going to do a full factory reset at some point and see if that resolves it. So back to the 2012 Nexus 7 for now which is rock solid.
I've read on a forum also if you don't register it with Lenovo when you first set it up (I didn't) you don't get full functionality which probably explains lack of auto screen brightness and internal GPS without fiddling about! Maybe it messes with WiFi trying to prioritise something else?
I notice though, that there are several threads on here with 'Pilotaware' mode WIFi disconnect issues that could all be connected with the latest release?
-
Fixed it!!
After loads more diagnotsics including the latest firmware update, buying a new WiFi Dongle and messing around with Wireless settings I focussed my attention on the fact it MUST be the tablet at fault (Mine is a TAB3 8/TB3-850F), something was clearly getting in the way of the data stream coming into the tablet.
I noticed, hidden amongst the list of system apps, was Macafee, (my most loathed of antivirus/firewall packages). Running at this level it couldn't be stopped or uninstalled or any settings changed.
So, taking the bit between my teeth, I boot unlocked and rooted the tablet following the instructions HERE (https://forum.xda-developers.com/android/general/guide-lenovo-tab3-8-tb3-850f-t3559786) for anyone who may care to try them in the future. Anyone attempting this, it's not for the faint hearted if you haven't done such before, will completely wipe and reset your device to factory settings also and you run the risk of bricking the device altogether if you don't follow the steps correctly or do it on a tablet that isn't exactly the same.
The result was that I was now able to uninstall Macafee. Finally, the disconnections have gone away completely. I have had my tablet running with Skydemon connected flawlessley to the Pilotaware for four hours now and the moving of ADSB targets is noticeably MUCH smoother than it was before.
I cannot be 100% certain that removing Macafee or the Rooting is the actual cause of the fix as I was too keen to see if I could get rid of the piece of #### that I forgot to do any testing before! I highly suspect some form of software firewall was being too aggressive getting in the way of both UDP and TCP traffic.
-
Hi Vic
Whoaa, a serious Android power user - well done
Just to check did you mis type the following ?
...The result was that I was unable to uninstall Macafee....
did you mean to say
...The result was that I was able to uninstall Macafee....
I have to say I am much relieved this was un-related to PilotAware, if your findings prove to be the case
Thx
Lee
-
Well Done Vic, a brave man ::) !
Glad you seem to have got to the bottom of the problem. Thankfully not a road I've had to go down..... so far, though I have a son who just rooted a Kindle Fire he bought for my Grandson, so he (my son) could put his preferred stuff on instead of being bullied by Amazon.
Hope they're not reading this :-\
All the best
Peter
-
Thanks Lee, I have now corrected my post. Yes i was very convinced it was not the PAW at fault when I replaced the WiFi dongle.
Vic
-
Flew today with it (to OGN equipped Turweston. They saw me coming well over 10Nm out!)
The tablets PAW link was flawless no breaks both there and back! ;D
-
When you say they saw me......... was this the guys in the tower? Did they have a PAW
-
Yes, sorry Keith, an OGN uplink has been recently installed atop their very high tower!
-
Yes. Turweston a brilliant location sponsored by the LAA (Nice chaps join now) and we will be reinstalling their PilotAware Ground Radar Station next week after improving the system.
With this anyone, club or individual who has an OGN-R station at their Club will get real time RADAR information and see PilotAware, FLARM, ADSB, Mode C and Mode S aircraft (the last 2 delayed by 4-5 seconds) within up to 30Km radius of their site. At last a real time (and near real time) RADAR system at your club for not a lot of money. As someone recently said we now have better information than RAF Benson!
If anyone wants more information drop me a PM
Keith
-
As an update to this issue, the connection problem with my Lenovo Tab 3-8 returned after some 3 or 4 flights.
About to bin the Tablet and revert to my old Google Nexus 7, I did one last internet search.
One suggestion was to create another user for the tablet, making it dual login. This I did, but it's an account I have never used since.
The disconecction problem has NEVER returned in over 6 months flying. Heaven knows why this fixed it but it just shows never to discount the ridiculous with modern IT!
-
Just wondered if anyone has found a solution to this problem for the 7" Lenovo Tab 3. Unfortunately, it doesn't give the option to add another User, so can't try that potential solution.
The dropout occurs very occasionally for me, so more of an annoyance than a problem. I have attached a couple of screenshots from my recent flight back to Gamston from Tatenhill. The first shows the dropout on the Tab occurring a couple of times. My Tab is using PAW as the source. The second shows a complete log from the same flight, from my Android phone, but this is using Skyview GPS as the source.
As I said, more of an annoyance than a problem (hitting Go-Fly usually reconnects until the next drop-out).
-
Bob, the Tab 3-7 should have a multi user or a kids mode https://www.youtube.com/watch?v=bF9hCh-hRt8
Maybe try adding a fictitious 'kid' :D
-
Vic, Thanks for the suggestion, but it appears my Tab 3 (Lenovo TB3-710F Android 5.0.1) doesn't have this feature, and searching the forums, it looks like it isn't upgradeable either :(
One interesting thing to come out of my search for an upgrade was the request from someone else for an upgrade to fix their problem of the Wi-Fi dropping out now & then. Maybe this is what is causing the problem I am experiencing.
-
Sounds like your problem is a little different then Bob. Mine would literally disconnect briefly every 20 seconds or less for the whole flight until I sorted it.
Something you could try if you haven't already is to do with the Wifi setup. In settings, from the WLAN screen hit the menu selector (three dots) and go into the Advanced menu.
In there is a setting "Notify whenever a public network is available" Make sure this is switched off. Again too clever for its own good this setting is normally allowing the WiFi to do other stuff and is possibly picking up the odd WiFi public network even at height to ask you if you'd wish to connect, by which time it's gone! Worth a try
-
I have a nifty little App called wi-fi prioritised which allows me to choose my wi-fi source, so I should theoretically be "tied" to PAW, but I've made the change you suggested, as you say, worth a try !
-
I also use wifi prioritizer.
It has stopped my Samsung tablet trying to connect to every Tom Dick and Harry Hotspot as I'm taxiing to the hold.