Zipit Group Page
This page contains information concerning the Zip-It re-purposing for Sensor Networks. Thanks to student 135, we also have a domain - http://zipiteers.info. Our next meeting is:
Saturday, May 1, ???, B1C MLH
Tie together components and test!
All of us
Discuss end-of-semester project document (../Zipit Group/ZPSProjectSummary)
All of us
- Current Task
- Team Members
- Project Info
- Past Meetings
1. Current Task
- Student 2: finishing touches on locator and recorder
- Student 14: working on recorder and locator
- Student 30: best ways to display location results
- Student 35: working on recorder and locator
- Student 135: locator
- Student 578: working on recorder and locator
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
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:
Your ZipIt Z2
- A Linux computer with an internet connection (to download the packages below) and gparted installed
- A microSD card
Information on how to flash the ZipIt can be found here from Hunter Davis. They are repeated below:
Head over to http://sourceforge.net/projects/openzipit and downloaded the autoflasher
Download Aliosa27's new kernel image and files here
Grab the latest mouse emu from here - NOTE: I don't remember doing this for our project, so I'm thinking it's probably an extra that is not completely necessary - group members, delete this line if I'm wrong!
- Format your microSD as a FAT partition (you won't need more than 100 MB)
- Extract the autoflasher to the FAT partition
- Extract the kernel + files you downloaded from Aliosa27, putting them in a directory you will remember
- From the extracted files, copy the ./boot/zImage-2.6.29 file to your microSD card, renaming it to kernel.bin
Put the microSD card into your ZipIt, boot it, and do nothing - it will flash your ZipIt and turn off when it's done
This will also make a copy of your original kernel and wifi firmware, copy them off the microSD somewhere safe - ANOTHER NOTE: I also don't think we did anything with the wifi firmware, they seemed to be built in to what we had. Saving the original kernel is important, though.
- Format the microSD into 2 new partitions, ext2 (or ext3, don't think it matters) (the majority of the card) and swap (just a little space - around 256 MB will do)
Rename and copy the wifi firmware back to the Z2 as described here - YET ANOTHER NOTE: I don't think we did this, either. Again, the wifi seemed to be working OK without it.
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.
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.
- First, set the soldering iron to about 519 degrees Fahrenheit
- Next, carefully select four lengths of wire. We had four colors - black, red, green, and yellow. Strip of a short piece of insulation for each wire, dip the wire in flux, and tin it with some solder.
Carefully connect the wires to the appropriate ZipIt ports. The black wire should go to ground, the red wire to voltage, and we chose the green wire for transmit, and the yellow wire for receive.
- Next, attach the wires to the appropriate places on the serial connector/level shifting board. Remember that the transmit from the !Zipit (green) is actually the receive on the serial port.
Connect the ZipIt to the computer with a serial cable. On our particular PC, it was /dev/ttyS0
- Install minicom, if you do not already have it. It is on CD1 of the Slackware distro - reference your Linux install experiences for this.
- Start minicom with the command:
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.
Now, restart the ZipIt by pressing reset, and then power. While it is attempting to boot, press a key in the minicom window. This will stop the normal boot process.
- at the blob prompt, type the command:
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.
- After the transfer, enter the command:
This will write the kernel to memory. Once you are done, you are free to reset your ZipIt!
Upon restart, it will probably complain about no flash memory. To get around this, we formated a microSD card with 1.7GB of ext3, and the remainder as swap, and extracted the kernel files to it (again, this is given in the ZipIt install instructions). Put this card in the ZipIt, reboot, and magically, it should now load Linux! The extracted kernel even contains X-Windows!
Celebrate the victory of rescuing your bricked 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:
Plug in the ZipIt.
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).
Delete the three .bin files that are not kernel.bin. REPEAT: DO NOT DELETE KERNEL.BIN.
Unmount the install memory card, and place it in the ZipIt.
Use a paper clip to reset the ZipIt, and power it on.
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.
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
- 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:
- Initial mapping and signal strength data gathering.
- Data structures and storage: databases vs yaml style files vs entirely in ram.
- Displaying maps and UI.
- Networking between zipits.
- Setting up a development environment.
Flashed the remaining ZipIt's
- 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:
Student 2: work on how to display maps with a nice user interface (unapproved, but will probably also work on how to share data between ZipIts)
- Student 14: also on storing data from iwlist, deducing location
- Student 30: mapping (displaying maps, zooming, panning, creating custom maps if need be) and locating relevant GIS literature (maintain citations and pdfs, write abstracts, communicate relevant information)
- Student 35: working on how to take the stored data and use it to make a prediction
- Student 135: building a development environment, set up how we are going to store the wireless signal info
- Student 578: taking data from iwlist and saving it (coordinating data format with 135)
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.1. Web Resources
Scratchbox is a toolkit for developing embedded software. This page has information on how to configure it for ZipIt development.
Hak5 segment on the ZipIt
Hack A Day article with many useful links
An installation process from HunterDavis.com
Experiences like running links browser, etc, on the ZipIt.
a blog with some possible tips and tricks
Yahoo group - has some information, but mixed with obsolete Zipit version 1 platform.
Ad-Hoc Networking Script - A little shell script I threw together for getting ad-hoc networking up. ESSID: ZipIt Wifi, key=1234567890. Take a look at my !ZipIt Page for details. Run with sh adhoc. If you have problems make sure the script has execute permissions.
Getting Started with Open Embedded and the Z2 - a nice introductory page, as the title suggests
Zipit ARM Toolchain - a page about building a toolchain specifically for the ZipIt - perhaps more useful than the next two links!
A little how-to on cross compiling - probably better ones out there
5.2. Expansion Port
There may be documentation on this:
Zip-It Expansion Connector(login required) - a description of the pinouts on the ZipIt connector - perhaps we could use 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.
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.
News about another Marvell platform (Marvell makes several of the chips that power the Zipit).