inSSIDer native GPX format

[i_do_dew]

Are there any plans to support inSSIDer's GMX format? If you export to NS1 from the app, it only gives you the APs from the last five minutes according to their forums, and there isn't a way to open/load the data file in the application after you capture it so that you can convert it to the KML if the app crashes which it does around 1000-1200 scanned AP's.

as a seperate question, does Wigle log AP's in the 5.8 GHZ band if the data is there from the card and the scanner
?

EDIT: Thx for the spell check, not sure if the subject change will take or not.

Last edited by i_do_dew on Tue Sep 28, 2010 1:34 am, edited 1 time in total.

[uhtu]

we record anything that gets logged by stumbler software.
we don't "have plans" in the sense of "we've never heard of it", but if you want to send us a sample, we can have a look.

[i_do_dew]

Ever the optimist, I had already done so prior to asking the question.

The file ID's are

_Insider_2010-0722010-7-2_17-22-59.gpx (I'm not sure how much actual data is in this fole since it is much smaller than the others.)

_Insider_2010-0712010-7-2_19-5-25.gpx
_Insider_2010-0702010-7-2_16-43-33.gpx

idd

[uhtu]

we need transids (the leftmost column on the "uploads" page)

[i_do_dew]

oh sorry, my bad.

This is ordered from largest to smallest.

20100827-00114
20100827-00115
20100827-00116

[Notaclue12]

It's actaully the GPX format, and a it's really simple XML data container.
Here is an example file with one point and comments

Code: Select all

<?xml version="1.0"?> <gpx> <wpt lat="12.345678" lon="-123.456789"> //The waypoint with Lat and Lon <ele>600.65</ele> //Elevation <time>2010-09-02T18:38:24.0Z</time> //Time in format: YYYY-MM-DDTHH:MM:SS.mZ <geoidheight>34.5</geoidheight> //Height above geoid <name>SSID [00:11:22:33:44:55]</name> //Name SSID and MAC address <cmt>82.22872896</cmt> //Speed in km/h <desc>SSID [00:11:22:33:44:55] RSSI: -67 dB Quality: 55% Channel 11 Speed (kph): 82.22872896 9/2/2010 6:38:24 PM</desc> //Description <fix>3d</fix> //Fix type <sat>5</sat> //Number of satellites visible <hdop>12.6</hdop> //HDOP <vdop>3.2</vdop> //VDOP <pdop>5.8</pdop> //PDOP <extensions> //AP data <MAC>00:11:22:33:44:55</MAC> //MAC address <SSID>SSID</SSID> //SSID <RSSI>-67</RSSI> //RSSI <ChannelID>11</ChannelID> //Channel <privacy>WPA-CCMP</privacy> //Security level <signalQuality>55</signalQuality> //Signal quality <networkType>Infrastructure</networkType> //Network Type <rates>1/2/5.5/6/9/11/12/18/24/36/48/54</rates> //Slash-delimited list of supported rates (including 802.11n rates if supported) </extensions> </wpt> </gpx>

The description really isn't used very much anywhere, so you can probably ignore it while parsing.

I work on inSSIDer, and wrote the new GPX I/O classes for inSSIDer 2.0. If you have any questions I can (try?) to answer them.

[i_do_dew]

It's actaully the GPX format, and a it's really simple XML data container.
Here is an example file with one point and comments

The description really isn't used very much anywhere, so you can probably ignore it while parsing.

I work on inSSIDer, and wrote the new GPX I/O classes for inSSIDer 2.0. If you have any questions I can (try?) to answer them.

Actually you do need the the description field(s). most of the of the other information is redundant to that. The description field carries the useful information about signal strength used for triangulation and location. My personal gripe about the data format is the amount of duplicate data. What is the purpose of having a description field within an XML container when the whole idea of XML is that each data point gets its own field, not one for Lat&Lon for instance. The idea is that the person displaying the data can decide which data to display/use. The files created with inSSIDer are hugely inefficient, and my guess is that is part of the problem which causes the app to become unstable after scanning only 1000 APs -- memory mismanagement when working with a large source that you are parsing and writing at the same time.

I don't know that it isn't, but appending the data to the file should be done before being passed to the display of the data function. If it had a war-driving mode you could force off the display of everything except the detected APs list.