All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Anomalies report
PostPosted: Thu Mar 16, 2017 9:37 am 
Offline
putinalilian - FlightAware user avatar

Joined: Tue Jan 03, 2017 8:02 am
Posts: 3
Today, on the site, I received these message:
Anomaly report for FlightFeeder # - site - i:
23% of UDP multilateration traffic sent by piaware is not reaching the FlightAware servers. This may indicate a network problem.

What does this message mean?

I have: FlightFeeder with wi-fi dongle. The modem works 24/24. I have no problems with the internet.


Top
 Profile  
 
 Post subject: Re: Anomalies report
PostPosted: Thu Mar 16, 2017 10:51 am 
Offline
FlightAware Staff
obj - FlightAware user avatar

Joined: Tue Sep 30, 2014 7:14 pm
Posts: 3676
It means there is a network problem or congestion somewhere between your FlightFeeder and the FlightAware servers.


Top
 Profile  
 
 Post subject: Re: Anomalies report
PostPosted: Thu Mar 16, 2017 11:00 am 
Offline
FlightAware Member
tdrane - FlightAware user avatar

Joined: Thu Jan 08, 2015 7:28 am
Posts: 119
Luke, there is a disturbance in the force.

A knowledge of the UDP (User Datagram Protocol) is helpful here.
https://en.wikipedia.org/wiki/User_Datagram_Protocol

As stated in the article, this is a protocol without handshaking so lost packets are not recovered. They are accounted for in that the packet contains a count. If the receiving site does not have a matching count then packets were lost.

Wireless Ethernet is much more susceptible to packet loss than wired. RF interference between your Flightfeeder and your Wireless Access Point can cause packet loss.

Recently I experienced UDP packet loss and thought my network wasn't the problem. I then discovered that the access point device that my RPI was connected to was dying a slow death. Once it bellied up, my connection to FlightAware improved when the RPI connected to a different access point.


Top
 Profile  
 
 Post subject: Re: Anomalies report
PostPosted: Sun Mar 19, 2017 12:28 am 
Offline
FlightAware Member
k6rtm - FlightAware user avatar

Joined: Tue Nov 18, 2014 10:18 pm
Posts: 426
Location: Silicon Valley
Tuning 802.11 systems is an art...

One trick you can try (if your Wi-Fi access point supports it), is to restrict channel bandwidth to 20 MHz, not the full 40 MHz that 11n wants to use.

An AP using a 40 MHz channel (such as for 11n) is combining 2 adjacent 20MHz channels. And to transmit on a 40 MHz channel, you need to have BOTH of those channels clear. If you just use a single 20 MHz channel, you've decreased the chances of activity/noise on an adjacent channel keeping you from transmitting.

This can make a big difference in noisy/crowded Wi-Fi environments! Particularly with our little beasties, which aren't big bandwidth hogs, that's the good news.

The bad news is that when things get crowded, UDP is the first thing to get dropped on the floor.

So stack the deck in your favour -- put your wireless Pi systems on a common 20 MHz wide channel. (If you can't run wired Ethernet.)

bob k6rtm


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: Google [Bot], kmire63e, luizcarlosribeiro, mtnbiker2005, orellana, PrashantBalhara and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to: