Problem Set 2

From MoDe

Table of contents

Questions

Zahoor and my group have been experiencing a similar problem with our GPS receivers. Using RFCOMM on channel 1 (or whatever channel happens to be available), we can sometimes get data from the GPS receiver. However, after a time, connections fail, usually with the error:

bluetooth.BluetoothError: (11, 'Resource temporarily unavailable')

and then we have no idea how to bring it back online. We try all kinds of voodoo resetting various things and are never sure how or when it decides to start working again.

Is anyone familiar with this error and can help us make our connections more reliably?

--Corey (mailto:coreymcc@mit.edu)

I just updated the Bluetooth Problems page. I hope it helps. Also if anyone else has seen other problems and found fixes please do add! Getting bluetooth to work can be pretty frustrating. Hopefully the bluetooth-up.sh (http://web.mit.edu/jasperln/web_scripts/download/bluetooth-up.sh) script helps ease some of the pain.
--jasperln (mailto:jasperln@mit.edu)

Does anyone know how to do HTTP posts? The instructions for the server say to send an HTTP post, but it seems the iPaqs don't have any of the required python libraries to do that. Does anyone have a comprehensive list of packages and dependencies, or instructions for how to get the required things? It would be nice if it were on the feed, but it doesn't seem to be(?).

--djwendel (mailto:djwendel@mit.edu)

Response: Thanks to Evelyn and Corey for helping me find how to do this. From http://www.boddie.org.uk/python/HTML.html :

// Search the Vaults of Parnassus for "XMLForms".
// First, encode the data.
data = urllib.urlencode({"find" : "XMLForms", "findtype" : "t"})

// Now get that file-like object again, remembering to mention the data.
f = urllib.urlopen("http://www.vex.net/parnassus/apyllo.py", data)

// Read the results back.
s = f.read()
s.close()

/*The above example passed data to the server as an HTTP POST request. Fortunately, the Vaults of Parnassus is happy about such requests, but this is not always the case with Web services. We can instead choose to use a different kind of request, however:*/

// We have the encoded data. Now get the file-like object...
f = urllib.urlopen("http://www.vex.net/parnassus/apyllo.py?" + data)

Yes, I would either use httplib for more control or urllib for a slightly higher-level interface. Both of these are in the python-netclient package. You probably also want python-zlib for decompressing request results from the server.
--jasperln (mailto:jasperln@mit.edu)

Don't use urlencode for XML data sent via POST. Also, it seems that you can't set the Content-type with urllib, so you might have to use httplib.
--Corey (mailto:coreymcc@mit.edu)

urllib is somewhat overkill for this task. Here's a simple way to do an http post using httplib: -- Ning (mailto:nsong@mit.edu)

   h = httplib.HTTPConnection(host, port)
   h.putrequest('POST', "/script.cgi")
   h.putheader('Content-Type', content_type)
   h.putheader('Content-Length', str(len(body)))
   h.endheaders()
   h.send(body)
   response = h.getresponse()
   response.read()

NOTE: This example doesn't seem to work on the ipaq because the python installation is missing the stringprep.py module. Unfortunately, I haven't been able to locate which package contains this module (if anyone does find the right package, please let me know - otherwise, I will probably file a bug report). So for the moment, I've set up an ipkg containing the module in our feed. You can install it via "ipkg install python-stringprep" from the 6.883 feed, and then the above example should work. Note that http.HTTP is considered legacy code, and is there mainly for backwards compatability. You should stick with the more recent HTTPConnection, which has a lot more features and options.

HTTPConnection doesn't seem to be working for us... instead we used HTTP, and then had to use:

   h.getreply()
   response = h.getfile()

--djwendel (mailto:djwendel@mit.edu)

I agree HTTPConnection should be the easiest. It seems to work except that python fails when trying to autogenerate and fill in the "Host:" header. Probably the same or related problem to what Ning pointed out above. If you manually fill in the host header things may just work.
--jasperln (mailto:jasperln@mit.edu)

Jasper's method worked for me. you can also do it all in one line with something like:

  h.request('POST', '/upload.php', body, header)

--zephyrus (mailto:zephyrus@mit.edu)

[edit]

Servers

Note: 172.18.*.* addresses are only accessible from within NUS as they are private addresses assigned by IANA. NUS does not have the luxury of provide public IP addresses for every student. More Information (http://www.duxcw.com/faq/network/privip.htm) (khcheng)

*Currently Available* Address: 220.255.80.43 Port: 1919

My server sends my fake location in the Position_Record XML format. The fake location information is obtained using one of five faking strategies (randomly selected).

These strategies make use of past location information that can be either my own or from a randomly selected friend.

- Edmond

*Currently Available* Address: 172.18.176.191 Port: 7000 My server sends my fake location in the Position_Record XML format. It randomly choses between 3 faking strategies

Strategy 1 - reports the location at which I was 24 hrs back
Strategy 2 - obtains the locations of friends (using a friend's list) from the server and then randomly returns a location from among those locations
Strategy 3 - gets the list of available servers by contacting the publisher server and then randomly contacts one of the alive servers and reports the location obtained from that server (Sort of a chain. X contacts me for location info, so me gets location info from Z and passes it to X and X thinks its from me

If the chosen strategy fails for some reason the server retries with a another random strategy with a maximum of 6 retries. Aid me in making my strategies better by posting your server information on the publisher server.

Publisher Server: Address: 172.18.176.191 Port: 6500

To publish: send "100: <name> <server:port> <likely_time>" To delete: send "200: <name>" To query : send "300:"

Others can also make use of the server list to devise better faking strategies!

-Zahoor Zafrulla (mailto:zahoor.zafrulla@nus.edu.sg)

*Down* Address: 172.18.176.126 Port: 6700 This server sends my GPSlocation in the prescribed XML format upon connection. I could be relayin fake or actual GPS data. So figure out if I am strolling along the corridor or walking on ocean waters with my ipaq n gps receiver :) - -Satish (mailto:cvsatish@nus.edu.sg)

*Unavailable Today* Address: 172.18.176.119 Port: 5757

My server sends my fake location in the Position_Record XML format. The fake location information is obtained using averaging between friend's location and my location.

- Rudi

*Currently Available* Address: 202.156.40.131 Port: 2999 (My server sends my location in the Position_Record XML format. It randomly returns either real or fake positions:P) - Huang Xin (mailto:huang@nus.edu.sg)

*Currently Available* Address: 172.18.181.97 Port: 600 (Sends a my reasonable faked position) -Khue Nguyen (mailto:g0502259@nus.edu.sg)

*Currently Not Available* Address: 172.18.76.39 Port: 500 (Sends a my reasonable faked position and sometime my real position from GPS, detail is my text file) -Khue Nguyen (mailto:g0502259@nus.edu.sg)

Available Servers (http://scripts.mit.edu/~jasperln/servers-up.py) This is my triplet server tracker/proxy from pset1 but actually it can track any type of server so thought I should post it here as well. Tracker may be even more useful for this pset since iPaqs may lose/regain net and change IPs often as we walk around with them. I may move the tracker off iPaq63 and onto a new home when I need to start moving the iPaq around but for now I'll just leave it up. When I push that change and when I add new features proxy.py (http://web.mit.edu/jasperln/web_scripts/download/proxy.py) should automatically let you know to upgrade.
See here for instructions on how to register your server.
--jasperln (mailto:jasperln@mit.edu)

*Not Currently Available* Address: 18.240.5.160 Port: 5678 or 8765 (My server sends my location in the Position_Record XML format. One of the ports is fake and one is real :P) - Vikki Chou (mailto:vikki@mit.edu)

*Not Currently Available* Address: ipaq-60.no-ip.org Port: 3535 (My server returns my current fake location in the Position_Record XML format.) - Jennifer Lin (mailto:jwlin@mit.edu)

*Not Currently Available* Address: ipaq-62.no-ip.org Port: 78956 (Sends an XML position record. This might not be our true location!) - Shannon and Jon

*Not Currently Available* Address: ipaq-55.no-ip.org Port: 3158 (Sends an XML position record - 50% true if I'm in real mode, otherwise 100% false) -Daniel (mailto:djwendel@mit.edu)

Check Availability (http://scripts.mit.edu/~jasperln/servers-up.py) Address: ipaq-55.no-ip.org Port: 1030 (Sends an XML position record - could be fake) -Corey (mailto:coreymcc@mit.edu)

*Currently Available* Address: ipaq-61.no-ip.org Port: 87678 (Sends an XML position record - Is this my true location? Ah! The quantum state :-D) -Omair (mailto:omair@mit.edu)

*Currently Available* Address: ipaq-64.no-ip.org Port: 9876 (Sends an XML position record - you figure it out.) -Ricky (mailto:rickdn@mit.edu)

*Currently Available* Address: ipaq-55.no-ip.org Port: 5757 (Sends spoofed position data) -Evelyn (mailto:evhan55@mit.edu)

Check Availability (http://scripts.mit.edu/~jasperln/servers-up.py) Address: jasperln.no-ip.org:2004 (usually but check tracker for latest info)
Sends XML position record. Reading updates every 5 secs (each point is averaged). If cannot take reading (like if indoors) then latest fix returned instead. --jasperln (mailto:jasperln@mit.edu)

[edit]

6.883 Official Server

The server to which you can upload your gps data for Pset 2 can be found at http://ozone.csail.mit.edu/upload.php. If you're interested in the source code, it can be found here (http://ozone.csail.mit.edu/upload.phps). The comments in the source code describe the expected input and output of the script, and is also reproduced below. As you can see, the script itself is fairly simple and somewhat cheesy. If you think the code sucks, please write a better version and submit it for extra credit. You're free to use my code however you wish.

If you encounter errors while uploading/querying and you believe it to be the server's fault, please let me know so I can fix them asap. Note that I have not tested the script extensively, so I expect a few errors to pop up. Also, if you even dare to think about trying to hack my server, I will hunt you down and fail you!!!!

Upload Script Description:

GPS data is stored in a mysql backend. The table is structured as follows:

+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | varchar(50) | YES  |     | NULL    |       |
| time  | varchar(50) | YES  |     | NULL    |       |
| place | varchar(50) | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+

The script expects a client to send data via an HTTP Post, with content type "text/xml", and body containing an XML string. If inserting data, the string looks something like this:

<?xml version="1.0"?>
<Position_Record>
   <ID>(s,a,n)</ID> <!-- Be careful of blank spaces in the tuple - as in there should be none -->
   <TIME>in python time.time() format</TIME>
   <PLACE>(latitude,longitude,altitude)</PLACE> <!-- These are your GPS coordinates, such as (1232N,2322W,234M)-->
</Position_Record>

In addition, if you want to upload a bunch of records (batch insert), use the following format:

<?xml version="1.0"?>
<Records>
   <Position_Record>
      ...
   </Position_Record>
   <Position_Record>
     ...
   </Position_Record>
    ...
</Records>

If requesting data, use something like this:

<?xml version="1.0"?>
<Request_Record>
   <ID>(*,*,*)</ID>     <!-- This gets all records!-->
</Request_Record>

or:

<?xml version="1.0"?>
<Request_Record>
   <ID>(s,a,n)</ID>     <!-- Request 1 or multiple matching tuples -->
   <ID>...</ID>
   ...
</Request_Record>

The output of the request will be a gzipped XML String of the form (use python's zlib module to decompress the string):

<?xml version="1.0"?>
<Records>
   <Position_Record>
      <ID>...</ID>
      <TIME>...</TIME>
      <PLACE>...</PLACE>
   </Position_Record>
   <Position_Record>
       ...
       ...
   </Position_Record>
       ...
</Records>

The script will spit out error messages when appropriate.

Ning Song (mailto:nsong@csail.mit.edu) 24 Feb 2006

Spring 2006 Class

[edit]

GPS Precision

I did some preliminary benchmarking of the precision of the GPS receivers issued in class on the MIT side. These are the small black ones based on the NEMERIX GPS Module. The points were measured on my balcony with a decent view of the sky but the quality of the fix varied a bit. When I get a chance and the bravery to stand out in the cold I'll try to get readings over a longer period of time and over a more easily discernible landmark to be able to estimate the inherit bias of my receiver of which it does appear to have some but it's hard to judge. These readings are from a minute consecutive time period. I took more readings but I benchmarked on the period with the lowest HDOP values.

Average Satellites: 3
Average HDOP: 2.505
Latitude Variance: 1.446424 meters
Longitude Variance: 2.003927 meters

Distribution of readings in degrees and meters (origin is the final averaged location):

Also to estimate the benefit of averaging several consecutive readings, I plotted the error of the estimated location to the final averaged location for each added data point. The first several points appear to either be lucky or the satellites moved to a slightly less favorable configuration afterwards. It's not until 40 secs do we get to submeter precision but perhaps the readings converge faster with more satellites. This does not take into account the inherit bias of the receiver so even after 40 secs the estimated location may be off but this shows the limits of averaging consecutive points for increased precision.

--jasperln (mailto:jasperln@mit.edu)

Retrieved from "http://org.csail.mit.edu/mode/index.php/Problem_Set_2"

Problem Set 2

From MoDe

Questions

Servers

6.883 Official Server

GPS Precision

Views

Personal tools

Navigation

Search

Toolbox