Ipad losing connection to PAW

[captchaos]

I am not sure if anyone else has experienced this. I am running the latest PAW and SAD on an Ipad mini 4. After a random time SD reports is has lost connection and hence position. Initially I thought this was a power issue as I was using the recommended cig socket charger and wondered if it worked loose. However I had the same with a suitable power bank.

SD worked find with no problems when using Location Services. The PAW appears to keep working fine based upon audio alerts. I am wondering if it is something to do with the Wifi conection?

Any thoughts,clues, etc very welcome.

PS Well done to the team on the OGN tie up. Saw some of this as I headed north at the weekend.

[Admin]

When the disconnect occurs, is your iPad still connected to PilotAware Hotspot ?
(are there other WiFi Hotspots in range that it tries to connect ?)

When reconnected to the PilotAware WiFi hotspot, can you go to the Web Home page and look at the uptime field in the table. This will tell you if PilotAware performed a reboot (usually due to power)

By recommended power, I presume you mean you are using Anker supplies ?

Location Services is unrelated to the issue you are describing, as Location Services are internal to the iPad

Thx
Lee

[captchaos]

Unfortunately as I was flying solo I couldn't check if the hot spot was still available. There was not other Wifi hotspot. When it happens again I will check those two points you suggested checking.

Yes I am using the Anker power products.

I only mentioned using Location services as I used that to get reliable nav.

[MaxMangia]

I too have the same problem. I run PAW with SD, with Anker power bank.
I run also an iPhone with Radar screen. When SD loose connection, the iPhone continue to run properly. Next flight I'll check if when SD loose the PAW connection, the wi-fi hotspot is on.

[JonBoy]

Capt C, I have had the identical issue many times.  Works ok then drops it's connection/ loses position randomly.  To the extent that lately if I'm on a trip where I want to use SD properly I just use the iPad's internal GPS (location services) and don't bother with the PaW because it's not reliable enough. 
Incidentally I did notice once that following a disconnection, the PaW hotspot was not showing on the iPad's wifi page - and the only way to get the hotspot back visible was to reboot the PaW.
My power is a Charge2.

[Admin]

Capt C, I have had the identical issue many times.  Works ok then drops it's connection/ loses position randomly.  To the extent that lately if I'm on a trip where I want to use SD properly I just use the iPad's internal GPS (location services) and don't bother with the PaW because it's not reliable enough. 
Incidentally I did notice once that following a disconnection, the PaW hotspot was not showing on the iPad's wifi page - and the only way to get the hotspot back visible was to reboot the PaW.
My power is a Charge2.

Hi JonBoy

This is just not right at all, and should not behave in this manner.
If the hotspot disappears completely this sounds like a wifi dongle issue.
We have seen a small number of WiFi dongles, which for some reason (manufacturing bug)
draw a huge current when put into Access Point mode, this can 'brown out' the power causing the
WiFi dongle hardware to get into a lockup state. I wonder if this is what we are seeing here.

Is this a PilotAware Classic or a home build ?

Which Software version of PilotAware is this running ?

Thx
Lee

[Admin]

Hi jonBoy,

Just looked up your email and this is a PilotAware Classic.
I would like to try swapping the WiFi dongle to see if this is indeed a culprit, I will ask Dave Styles to contact you

Thx
Lee

[MaxMangia]

I did some test to try to understand at what level the problem is (IPAs, SD e Classic).
When SD loose GPS signal the hotspot is on, so it seems no Wi-Fi dongle problem.
If I try to reconnect SD, some times it reconnect at the first temptative, others I have to try several times. So it's seems a GPS dongle trouble.
Ha e you any suggestions on how to solve the problems? It's boring to loose the GPS signal while flying

[Admin]

I did some test to try to understand at what level the problem is (IPAs, SD e Classic).
When SD loose GPS signal the hotspot is on, so it seems no Wi-Fi dongle problem.
If I try to reconnect SD, some times it reconnect at the first temptative, others I have to try several times. So it's seems a GPS dongle trouble.
Ha e you any suggestions on how to solve the problems? It's boring to loose the GPS signal while flying

There are 2 messages produced by SkyDemon

1. lost connection to GPS
This is a WiFi connectivity / TCP Socket issue, and not an issue with the GPS device itself

2. searching for satellites
This is a GPS issue, because the GPS has not achieved a lock

an easy test, unplug the GPS from PilotAware and you will get message (2)

If your iPad is in range of 'known networks' it will drop and reconnect depending upon the strongest signal.
So if you are near your home wifi, you may se the ipad drop the connection to PilotAware, connect to Home, then reconnect to PilotAware

The only way to get around this, is to tell iPad to forget your home network, this will stop t connecting to other networks

I think the best solution between PilotAware and SD, is to use UDP rather than TCP, this is more tolerent to an individual lost packet.
TCP (in the SD implementation) just gives up and stops working.
I have been speaking to Tim at SkyDemon, and he is going to investigate using a UDP connection as a replacement to TCP

Thx
Lee

[JCurtis]

I think the best solution between PilotAware and SD, is to use UDP rather than TCP, this is more tolerent to an individual lost packet.
TCP (in the SD implementation) just gives up and stops working.
I have been speaking to Tim at SkyDemon, and he is going to investigate using a UDP connection as a replacement to TCP

Thx
Lee

I'd prefer TCP over UDP. 
With UDP PAW just blindly transmits to an address and port, with no idea if they are received or not.  At least with TCP the network layer will know that data has gone missing and can re-transmit.  With UDP there is no assurance, its fire and forget.

If a UDP packet is lost the network layer won't know, unless the receiver can tell the sender that something expected didn't arrive.
If a TCP packet doesn't arrive or is corrupt, the sender won't get the ACK back, so know it didn't arrive and can re-transmit. 

This is all, normally, handled within the network stack, so it should be possible for PAW to display the network stats to see if there are large numbers of re-transmissions going on (i.e. SD is not sending ACKs).  Naturally a large number of failures may close a connection, but to KNOW that is a good thing and easy to trap and report.

[Admin]

Hi Jeremy

No disagreement with what you are saying.

Althought it seems the consensus are all moving to UDP.
The Uavionix devices all use GDL90 over UDP, although I think this is because they use the espressif esp8266 devices, and the TCPIP stack on those devices is notoriously bad - hence UDP by necessity I think.

What I would probably have preferred is that when SkyDemon loses its TCP connection, it simply attempts a reconnection, but at the moment it requires a user intervention, which is painful to say the least when busy flying a plane.

I notice the XCsoar devices all perform a reconnect over TCP if the connection is lost, and I am pretty sure RunwayHD and EasyVFR do that as well.

I will not be taking away the TCP option, basically I will be adding a UDP broadcast to any listening servers on the subnet.
So you can choose your connection
2000/TCP server running on PilotAware
2000/UDP client broadcasting to listening servers on the subnet

Thx
Lee

[JCurtis]

TCP re-connect is ideal, and throw an error if this happens x times, although that can hide problems leading to missed data (and potentially alerts)

Although if you are doing a UDP subnet broadcast can I ask you include a heartbeat packet people can listen out for?  With that, and they have to add the code to use the UDP anyway, it can be used to alert if a number of heartbeats are missed and so identify there is a problem, rather then deduce it from a lack of anything else.

Essentially listen for heartbeat, so know it's running and it's from a PAW, so start to process the data.

[Admin]

Hi Jeremy

Does a heartbeat contain any special data ?

The reason I ask, is that a traffic packet goes once a second periodically, so if something hasn't been received for lets say 2 seconds - there is an issue, and if the server has implemented a timeout - this is easy to detect.

Thx
Lee

[JCurtis]

Does it send empty traffic data, i.e. if the ADSB isn't connected and nothing is received?

A heartbeat can contain what ever you want, but I think it would be good to send.  It splits not receiving any data from the device not being on/reachable.  So if the device stops sending the heartbeat something serious is going on, but a lack of any other data could mean there is nothing to send or the system is still working on it.

Naturally the heartbeat could also contain an ID to say it's a PAW, just publish the packet details.  The minimum Ethernet packet length is 64 bytes, so plenty of room after the basic header data to include a Hello World ID for the end device to identify who it is listening to, or even determine if several different things are transmitting by associating the ID with the sender IP address.

It doesn't really matter if the receivers don't use it, but no reason for you not to transmit it, to identify a PAW UDP broadcast transmission to anyone listening in on the network segment.  If they do decide to use it, they can identify who is sending the broadcast and so what services to expect and what to flag up to the end user if it's missing after a while.

Naturally if it was in a NEMA style format it would be easy to parse for at the remote end.

[JCurtis]

I think it might be part of of the NMEA 4.10 anyway...

Code: [Select]

This sentence is intended to be used to indicate that equipment is operating normally, or for supervision of a
connection between two units.

$--HBT,x.x,a,x*hh<CR><LF>

Field 1 HBT
Field 2 x.x = repeat interval
Field 3 a = equipment status
Field 4 x Sequential sequence identifier