Archive for category Projects
Mapping wifi access points in Portland
I’ve been logging GPS data for about a year and a half. I use an app on my Windows Mobile phone to log the GPS data, and my phone has a wifi antenna that stays in the “off” position most of the time. I met with @donpdonp the other day and he introduced me to the geomena.org project. I realized it should be possible to log access points along with my existing GPS logging. It was easy to install Airomap on my phone, so now I can log wifi points too!
So far I’ve only made about a dozen trips with the wifi antenna on, but I’ve already logged 2200 unique mac addresses, and 427 open access points. And this is only on my normal route to and from work, I haven’t made any special wardriving trips yet. Here is a heatmap visualization of the access points I’ve logged so far.
This uses a custom tileserver I wrote to provide an additional data layer to the map. Hotter spots on the map correspond to more open access points in that area.
This is a version which shows each access point as a marker on the map so you can click on them.
Wifi Access Points in Portland. Red: encrypted, Blue: open
Most of the access points appear to be in the middle of the street, because most have been seen only one time by my logger, which was in the middle of the street. As the access points are seen repeatedly from other positions, the points will adjust to a more accurate position. You can already see this happening for a few points which appear in the middle of blocks or on streets through which I did not drive.
Again, these maps are still in their infancy, since I’ve only logged a few days worth of points on very narrow routes. But it’s amazing that I’ve already driven by 2200 access points just in the normal course of the day. I’m looking forward to continuing logging data and eventually importing it into the geomena database. It’s easy to see how quickly we could map out the entire city with just a couple people running loggers!
More tests with the Nike+iPod protocol
A lot of information about this device online is misleading. When I first heard about this, the site I was reading claimed the transmitter didn’t have a battery, and used the energy from the foot impact to power the burst transmission of the device’s ID. This is what got me excited about the device in the first place: that it was so simple.
Other places I’ve read say there is an accelerometer inside. While not entirely inaccurate, it is again slightly misleading. It does not have an accelerometer the same way a Wii controller does. It has a piezoelectric sensor. (See SparkFun’s Nike+iPod Dissection page)
I am not entirely confident that I know the capabilities of piezoelectric sensors, but if I am understanding correctly, they are primarily used to detect impact, and not smaller accelerations like the Wii controller does. What I am saying is that the sensor doesn’t know it is being dropped, it just knows that it hits the table.
Here is another data dump from the sensor. I tapped the sensor on the table two times every second. It’s two short taps followed by me waiting for the receiver to show it received a packet.
Reverse Engineering the Nike+iPod Protocol
I just got a Nike+iPod gadget thingy. It’s pretty cool, and stores all the running stats in xml files on the iPod, making for easy hacking of the running data. However, that’s not what I really want to do with it.
I got one of Sparkfun’s USB serial adapters for it, and can now get the raw data off of it. What I need to be able to detect is whether the sensor received an impact.
Before I bought this, I had heard that the sensor in the shoe transmits its ID every time the runner takes a step. However, after a little experimentation, I found this is not the case. Stepping on the sensor activates it, and once active, broadcasts some data chunks every 1 second. The dump below is from me dropping the sensor on the table, then letting it sit there until it stopped sending. You can see it took 13 seconds of just sitting there before it stopped sending data.
FF 55 1E 09 0D 0D 01 70 C5 07 30 A6 45 59 1F 91 DC 8E C4 FB 66 37 DB 010 9E 75 69 6F 99 08 C4 0A 95 BE
FF 55 1E 09 0D 0D 01 70 C5 07 30 A7 1C 94 06 1A 84 A8 010 9A 22 E8 F8 8B F9 67 44 0E 6B AB BB E0 C2 53
FF 55 1E 09 0D 0D 01 70 C5 07 30 A8 57 53 73 39 0F 14 DE 0E 3B 5C 38 73 22 72 23 AD 3A 49 C9 1A 4A EF
FF 55 1E 09 0D 0D 01 70 C5 07 30 AA 06 85 D1 B6 9F AB B7 20 3C B9 CD EF DA 6B E5 5D E8 86 A7 42 36 B0
FF 55 1E 09 0D 0D 01 70 C5 07 30 AB EF DC BC ED 7F FB 7E 9B 89 31 07 57 4B B5 B3 79 DA FC E2 4B 8F CA
FF 55 1E 09 0D 0D 01 70 C5 07 30 AC 78 B4 0B 79 76 3D 08 B8 F2 B8 C6 D5 B2 AB 13 C7 68 0E 6B E2 78 CC
FF 55 1E 09 0D 0D 01 70 C5 07 30 AD 2B 17 0E DA E4 E3 B2 AF 65 5B 90 1F D5 72 F7 85 89 A8 9F A6 FD AE
FF 55 1E 09 0D 0D 01 70 C5 07 30 AE A1 3E 49 7C 5E C4 4A 5B 29 0A 9A 9D A3 E5 D0 EE 66 D4 53 F9 010 F3
FF 55 1E 09 0D 0D 01 70 C5 07 30 AF AC CD 2A 92 46 79 E4 53 34 32 D1 6A F7 22 E8 6D C6 D1 9D CB 67 03
FF 55 1E 09 0D 0D 01 70 C5 07 30 A0 B3 69 55 76 07 76 11 CC 9D A8 AD 29 3B B9 87 A4 17 F1 F9 CB 06 65
FF 55 1E 09 0D 0D 01 70 C5 07 30 A1 23 53 40 C5 F5 22 50 BD 83 F1 5D 69 EC D0 4D 1C D0 DA 49 EA A9 2D
FF 55 1E 09 0D 0D 01 70 C5 07 30 A2 6F 27 1A 08 2A 93 81 B6 33 2F A0 6B BF B6 D1 4C 9B 0F 33 D1 16 41
(If you look closely, you’ll see some 010’s in there. That is obviously not a real hex byte, and has something to do with the VB program that Sparkfun put together. I can’t actually get the checksums to work out, otherwise I’d be able to tell what it should be.)
Here is what we know so far, compiled from here and here
FF 55 : Apple Accessory Protocol header
1E : length of packet data (from mode through data before checksum)
09 : mode for Nike+
0D 0D : command
01 : unknown (start of parameter)
70 C5 07 30 : my transmitter’s ID
A5 : appears to be a counter, always starts with A, counts from 0-F
next 21 bytes : unknown
79 : 8 bit additive checksum ((sum of all length/mode/command/parameter bytes) & 0xFF) Note: I can’t actually get this to calculate out correct on any of the rows. I must be doing something wrong.
Currently I don’t have enough information in order to be able to tell whether a packet contains a footstep or not, since it continues to transmit even after it stops getting footsteps.
Links:
http://www.ipodlinux.org/Apple_Accessory_Protocol
http://www.ipodlinux.org/forums/viewtopic.php?t=24578
http://www.rockbox.org/mail/archive/rockbox-dev-archive-2008-02/0005.shtml
http://www.cs.washington.edu/research/systems/privacy.html
http://en.wikipedia.org/wiki/Nike%2BiPod
http://www.apple.com/ipod/nike/
Caller ID Box
Update:
Everything looks like it should be working, and I even modified the answering_machine.c script a little bit. But for some reason, it appears as though the modem is just never receiving the ring signal. It may be because I am running it in a dual processor machine. I am going to reinstall linux in a single processor machine and try again.