Changes between Version 2 and Version 3 of datavali

Timestamp:

Jun 23, 2011, 3:01:25 PM (13 years ago)

Author:

dennisw

Comment:

--

datavali

@@ -40 +40 @@
 53.1000, 5.1000
 }}}
-100 rows of missing coordinates. First of all, the impact of these missing values depend on the speed you traveled/measured with. If your first coordinate was at the NE point, and the last was at the SW point of Leiden, there is quite a large gap. (A side note: you should increase your measurements per time ratio if this would happen)
+100 rows of missing coordinates. First of all, the impact of these missing values depend on the speed you traveled/measured with. If your first coordinate was at the NE point, and the last was at the SW point of Leiden, there is quite a large gap. (A side note: you should increase your measurement intervals if this happens)
 For large gaps like these, it's hard to calculate an expected route. Even if within these missing values a random value would be measured (like a 10 missing/1 valid ratio), it might be wise to just ignore these values since it's hard to get a correct route on long distances.
 
@@ -46 +46 @@
 
 == Invalid signal strength ==
-You might encounter missing or invalid signal values. Let's assume the following is measured from the same accespoint. (right now, signal strength is '100 + signal_dbm')
+=== Detecting ===
+Again, the '0.000' and 'null'-like values won't be hard to spot. Besides that, it's hard to find 'valid but invalid' values. You might measure a 50% strength on exactly the same position for five continuous days, and a 25% on the sixth. This doesn't mean the 25% is invalid, since there are a lot of factors that can influence the strength you measure. Therefore it might be enough to just set a valid range, e.g. +35dBm/-100dBm, and go from there.
+
+=== Solutions ===
+Let's assume the following is measured from the same accespoint. (right now, signal strength is '100 + signal_dbm')
 {{{
 signal_dbm, strength %
@@ -62 +66 @@
 }}}
 The first and third value don't show a lot of difference, so it should be fairly safe to take the old second value, and use it for the new measurement.
+
+== Invalid SSID/BSSID ==
+=== Detecting ===
+Same thing with the 'null'-like values.
+
+=== Solutions ===
+Missing an SSID:
+Assuming people don't tinker with their BSSID, a missing SSID value can be easily solved if the BSSID is already in the database with an SSID. If the accespoint hasn't been measured before, and the SSID is missing in the measurement as well as in the database, a placeholder like 'unnamed' can be set. In case the SSID is measured later, the old one can simply be overwritten with the new one.
+
+Missing a BSSID:
+If we have an SSID, but no BSSID, we can't simply look for a similair SSID in the database and use that BSSID as a replacement since SSIDs aren't unique. What might work: check the coordinates. If you measured the SSID at 50.000/4.000, and there is a two day old entry in the database matching the SSID and measured around the same location, there's a fair change they match. In that case you can take the BSSID and use it for your freshly measured SSID.
+Otherwise it could help to set a placeholder BSSID (same idea as before).
+
+Missing both:
+When missing both, it's more of a question if you want to display unnamed accespoints on the map. Right now, only the Wireless Leiden node SSIDs are used. All other accespoint SSIDs and BSSIDs are just stored in the database for possible later use. It might be wise to just use placeholder names again, since it's wasteful to discard good measured data.