Zipit Group Page


Saturday, May 1, ???, B1C MLH

Agenda

Item

Interested Students

Tie together components and test!

All of us

Discuss end-of-semester project document (../Zipit Group/ZPSProjectSummary)

All of us

1. Current Task

2. Team Members

The ZipIt team is composed of:

3. Project Info

NOTE FROM PROF HERMAN: /LabZipitWiFi

A note for Zipiteers - we have set up networking on the serial-port-ed ZipIt. It's IP address is 192.168.42.199.

3.1. The Hardware

As the page title would suggest, we are working on re-purposing a ZipIt for some sensor network-related task. For information on the hardware, check the hardware webpage on Zipit Forge.

3.2. Installing Linux

These instructions will fill out with more detail and some pictures as soon as we get Linux installed. Until then, for those following along at home, the required setup artifacts are below. You will need:

Information on how to flash the ZipIt can be found here from Hunter Davis. They are repeated below:

3.3. The Project Goal

Our project goal is to use WiFi signals received on the ZipIt to determine the ZipIt's location. This involves many components, such as making a compact but nice GUI for inputting data and displaying locations, reading in WiFi signals, storing them in a nice format, retrieving them quickly, and using this data to guess the location.

4. Past Meetings

4.1. Thursday, February 25, 2010

Today, we learned how to brick a ZipIt. It was discovered that we had made a mistake in extracting the kernel, so at least we know now how to proceed. Besides that, we exchanged contact information by e-mail - if you did not receive this e-mail, let a group member know. We also discussed our plan for reflashing. One way is to build a serial cable to re-flash using Max3233e for level shifting, which can be read about on the Zipit2 System Serial Port page.

Student 135 had enough forethought to bring a camera, so we took several pictures of our experience - including the brick with a brick. Click the pictures for a larger version.

Flashing the ZipIt][: :]Flashing the ZipIt]

4.2. Tuesday, March 2, 2010

Today, we rescued our bricked ZipIt! It was quite a tricky process, but with some help, we had it working. Initially, we tried using a USB port, but unfortunately, the ZipIt would not power off with the USB chip, making resetting impossible. We then connected the serial adapter, and this approach worked. Below is a brief summary of the steps.

which will bring up a configuration screen. Select Serial Port Configuration, set the device to /dev/ttyS0, set the bit rate to 115200, 8 data bits, no parity, 1 stop bit, and no flow control, either hardware or software.

Once this command is entered, it should say it is waiting to receive the kernel. When using minicom, press Ctrl-Z, then S (for send), select Xmodem, then browse through the directories to find the kernel file you have extracted from the ZipIt materials posted above. Upon selecting this, it should transfer to the ZipIt.

This will write the kernel to memory. Once you are done, you are free to reset your ZipIt!

4.3. Thursday, March 4, 2010

Today we verified that in fact we had a system for flashing the ZipIts. We placed the original kernel back on the ZipIt, then used our prepared memory card for flashing. We then moved this process to an "original" ZipIt with success. We can flash the remaining ZipIts by following these steps:

  1. Plug in the ZipIt.

  2. Take the Install Memory Card and mount it in your OS of choice (if you don't know which one is the install card, ask another group member).

  3. Delete the three .bin files that are not kernel.bin. REPEAT: DO NOT DELETE KERNEL.BIN.

  4. Unmount the install memory card, and place it in the ZipIt.

  5. Use a paper clip to reset the ZipIt, and power it on.

  6. DO NOTHING once powered up - the ZipIt will write the kernel and power off once it is finished. Just be patient, but do not remove the power, and do not press any buttons.

  7. After it powers off, remove the memory card. You should now be able to boot the ZipIt, and see a "kernel panic" message about not being able to mount the necessary file system. From this point on, you are done flashing, and can follow the instructions given earlier.

4.4. Tuesday, March 9th, 2010

  1. Discussed the wireless positing system from a high level perspective, covered a basic project outline (to be added here later) and the beginnings of task assignment for individual members. Issues discussed included:
    1. Initial mapping and signal strength data gathering.
    2. Data structures and storage: databases vs yaml style files vs entirely in ram.
    3. Displaying maps and UI.
    4. Networking between zipits.
    5. Setting up a development environment.
  2. Flashed the remaining ZipIt's

  3. Formatted and transfered Aliosa27's userland to all the remaining 2GB SD cards. Default username: root, default password: [none]

4.5. Thursday, March 11th, 2010

Today we discussed our project goal and how to divide work for now. We decided our project description is to use received Wifi signal strengths to show the user their location. We discussed the first step of project work division. So far, it seems the division is:

4.6. Tuesday, March 23rd, 2010

Today we discussed a few ways to implement our positioning system. We are thinking now of using a fingerprinting technique, since trying to judge distance from wireless signal strength is very difficult and error prone. Fingerprinting reduces the problem basically to one of matching, which we believe we can do. There are several things we'll need to keep in mind, such as smoothing/filtering the wireless signals over time, both when taking the measurements for building the map, and when reading signals to guess the position. We can also use the prior predicted location to make sure user's positions don't "jump" around. Right now, we have a better idea of how to proceed, and hopefully in our next meeting (Thursday), we come up with a decent draft of our technique/system.

4.7. Tuesday, March 30th, 2010

Today, we discussed some interfaces to use for the mapping software. We decided the mapping software would call the recorder module from the command line, giving it a string identifier as a command line argument. The recorder module is then in charge of saving any information, all of it associated with the given identifier. When the mapping module is in locate mode, it calls the locator module with no command line arguments, and this module should look at the network signals visible, make a prediction (or two or three), and put the identifiers associated with these locations (first stored with the recorder module) and save to a file.

There are still a lot of things to do - this is the mapping interface, but I think the interfaces with the recorder and locator, as well as the sharing of map data (which we will do whenever the locator or recorder module is called), is all open. We also need to set the names of the programs for recording and locating. However, good progress was made today!

Hopefully, we will get a picture of the diagram soon!

4.8. Thursday, April 1, 2010

Today, we saw the virtual machine with Scratchbox. As an important note for those C programmers - when you compile with GCC, use the -static flag to statically compile your program. This means your program does not depend on the existence of other C libraries on your ZipIt. This way, we don't have to recompile everything!

We also ran in to a problem with compiling programs for the ZipIt. For both student 135's simple program, and the graphics test program, a segmentation fault occurred. We will investigate why this is happening. For some parts of the project that do not compile, hopefully this isn't an issue. For the graphics part, we can always look into getting a working version from somebody else and making changes.

4.9. Other meetings...

Obviously there were other meetings - every Tuesday and Thursday. However, taking notes was pretty painstaking, so each individual student has been tracking stuff on their blog.

5. Resources

5.1. Web Resources

5.2. Expansion Port

There may be documentation on this:

It appears that the connector is the same as for a Dell Axim 51v (and there are plenty of cheap USB cables for this on the market). Problem is, at least according to a Yahoo Zipit group message, the pins are not compatible: such a cable could well fry the Zipit. Could such a cable be dismantled and hacked into correct pins, or otherwise repurposed for us? This depends on whether the shielding would cooperate and also whether the Axim 51v indeed gives us access to all the pins (no reason why it would have to do that). It seems that the processor on this Zipit is the same as what the Dell Axim 51v runs.

An alternative, more laborious and requiring very steady hands and perhaps patient soldering/tools, would be to order an actual connector. From what I could see, the Hirose ST40X-36S-CV(80) is what we would want; see Digikey part number H11462-ND (link) which shows pictures. Looks like this would give access to all the pins, and possibly some ribbon cable could be soldered on to these pins. BUT, first it might be nice to confirm that this is the correct cable before ordering some. Another mention of connectors with part numbers is given in a pointer from the ZipItRescue page.

5.3. JTAG

Hopefully, we will never need this. If somehow the kernel loader (blob) were lost, we might need to use JTAG, in which case this link might be useful.

5.4. Base maps

The ZPS relies on a base map to visualize locations for a user. We found that the easiest way to make a map of the interior of a building was to start with a floorplan (from facilities management) and digitize (or trace) the appropriate features. This was carried out using ArcGIS software, but could also be performed in Adobe Illustrator which is available to all students through the Virtual Desktop. Once the basic features are in place, additional landmarks, symbols and text can be added to help orient a user.

5.5. Experimental accuracy testing

To determine the accuracy of our positioning system, we simply counted the number of times the system "correctly" positioned the user at randomly selected locations in the study area (the first floor of Maclean Hall). Random locations were generated using ArcGIS software. The study area was digitized as a polygon, a value (in this case 11) was associated with the polygon and it was represented as a "dot density map". Each time a dot density map is generated, the 11 dots are positioned randomly within the polygon. Because our system snaps the user to the closest pre-established reference point, Thiessen polygons (http://en.wikipedia.org/wiki/Voronoi_diagram) were overlaid on the study area to determine which reference point was closest. This technique is appropriate for hallways and other open spaces. For a reference point in a classroom, all points within the walls of the classroom are taken to be closest to that reference point. ArcGIS software was used to create these polygons.

5.6. Related?

News about another Marvell platform (Marvell makes several of the chips that power the Zipit).

Zipit Group (last edited 2014-05-25 18:15:49 by localhost)