Thursday, August 23, 2012
Works on Raspberry Pi
My Raspberry Pi arrived a few weeks ago. I'm happy to report that my eyefi-config program compiles and runs great on it when the Eye-Fi card is plugged in to a reader in one of the Pi's USB ports.
Tuesday, April 19, 2011
Direct Mode Support
The good news: I believe I have direct mode working. There are 3 new commands. Two of them are big 'O' integer commands: an ASCII 'O' followed by a command-number byte (like an ioctl()), an argument length byte, and then a single byte for the number being fed in to the command.
I'm going to hold off on actually releasing the software for a bit. I'm concerned about bricking other cards somehow.
- O[0x24]: DIRECT_WAIT_FOR_CONNECTION: Corresponds to "wait for XX seconds for a device to connect" slider in Eye-Fi center. The argument is a number of seconds. 0 means "direct mode off" and 0xff means "wait forever"
- O[0x25]: DIRECT_WAIT_AFTER_TRANSFER: Corresponds to "will stay on YY seconds after the last item is received" slider. Set to 60 when direct mode is off. 0xff means "wait forever"
- S: tells the card to "Start Direct Mode Network". This is useful for pairing, and corresponds to a button of the same name in the Eye-Fi Center GUI.
I'm going to hold off on actually releasing the software for a bit. I'm concerned about bricking other cards somehow.
Friday, April 15, 2011
"Mobile X2" Card with "Direct Uploads"
Eye-Fi released a new card model recently. They're calling it a "Mobile X2". From the spec comparison it looks like it is just an 8GB version of the existing 4GB Connect X2. That is, it's probably the exact same hardware as the Pro Card, but with tweaked firmware.
The cool thing about these new cards is that they don't need an existing WiFi network at all, even an Ad-Hoc one. They can evidently create their own network:
It sounds like you'll need a firmware update next week and probably also have to enable the direct mode somehow. I'll try that out as soon as they release the new firmware next week, and try to make sure I put support for it in eyefi-config.
The cool thing about these new cards is that they don't need an existing WiFi network at all, even an Ad-Hoc one. They can evidently create their own network:
The Eye-Fi X2 card will create its own Wi-Fi network and transfer to the free iPhone/iPad or Android appI'm actually a bit surprised they are doing this. I always figured that the Ad-Hoc support in the Pro card was one of its main selling points. This blows that away completely. I also hope Shutter Snitch gets support for the new mode, otherwise it's going to be a lot less useful going forward.
It sounds like you'll need a firmware update next week and probably also have to enable the direct mode somehow. I'll try that out as soon as they release the new firmware next week, and try to make sure I put support for it in eyefi-config.
Friday, March 25, 2011
New Release: 011
Someone was kind enough to send me a Pro X2 card, along with a plain X2. Before, I only had a 4GB "Wi-Fi" card. The new cards have some nice features, and this release adds support for a few of them, and few that I never got around to supporting before.
Go ahead and download the new release here, or view the changelog if you want more details.
- --transfer-mode: print or change card transfer mode or =help to list modes
- --wifi-radio fetch wifi radio state, or turn it on and off
- --endless: fetch or set endless storage trigger percentage
Go ahead and download the new release here, or view the changelog if you want more details.
Sunday, March 20, 2011
Transfer Mode Command
The Eye-Fi software has not run under WINE in quite a while. That was disappointing because it's how I first reverse-engineered the commands. But, I have a new and much simpler method now, and it's much less likely to break from future Eye-Fi software changes.
I've now added a --transfer-mode option. This "selective transfer" mode described here.
I haven't made a release yet, but this code is now available in the git tree.
I've now added a --transfer-mode option. This "selective transfer" mode described here.
- "Selective Share" is --transfer-mode=SELSHARE
- "Selective Transfer" is --transfer-mode=SELUPLOAD
- The default mode is automatic and it is specified with --transfer-mode=AUTO
I haven't made a release yet, but this code is now available in the git tree.
Wednesday, September 22, 2010
New Mailing List
Somebody requested it, so here it is. I also created a Google Code project for wiki space among other things.
| Homepage: | http://groups.google.com/group/eyefi-config-discuss | |
| Group email: | eyefi-config-discuss@googlegroups.com |
Thursday, August 12, 2010
New Commands for disabling WiFi
I've managed to find a few commands that my D90 camera sends to my card. I haven't quite made them suitable for public consumption yet, but I did commit a bit of the code to my git tree. Take a look in this commit if you're interested in learning more.
Thursday, February 4, 2010
New Card Models (Pro, 4GB, etc...)
I just wanted to let everybody know that my software still works with the 4GB cards. I have a 4GB "Home Video" card, and I was able to program it just fine with my software. It claims to have the same firmware version that my 2GB card has. I have not verified that the images are the same (or very similar).
I'm pretty sure that the 4GB cards are very different internally than the 2GB cards. I get ~6MB/sec write speeds, which is at least 3x what I got before.
I'm not sure about the 8GB Pro card. Is it just a 4GB card with more flash, or truly the 3rd-generation model? Does it share firmware with the 4GB cards? I also do not know how to program the Ad-hoc networks into it. I believe that Ad-hoc networks will need to have static IPs at least, and I have no idea how to program that into the card.
BTW, does anybody have the Eye-Fi manager working under WINE these days?
I'm pretty sure that the 4GB cards are very different internally than the 2GB cards. I get ~6MB/sec write speeds, which is at least 3x what I got before.
I'm not sure about the 8GB Pro card. Is it just a 4GB card with more flash, or truly the 3rd-generation model? Does it share firmware with the 4GB cards? I also do not know how to program the Ad-hoc networks into it. I believe that Ad-hoc networks will need to have static IPs at least, and I have no idea how to program that into the card.
BTW, does anybody have the Eye-Fi manager working under WINE these days?
Thursday, October 8, 2009
Eye-Fi releases source code
In March, Eye-Fi finally released source code for their copy of eCos and began complying with the GPL. Over in the message boards, Berend mentioned that nobody had ever asked for the source like that before. Citing the GPL in June 2008 in a private email I mentioned that "That's why I'm only asking for eCos itself". Oh, well. It's good to see that they're learning.
It's good to remember that this is just eCos and not the wireless driver or any of the custom Eye-Fi code that runs on the card. This is probably just what Eye-Fi got from Atheros after Atheros ported eCos to the AR6001. What this means practically is that we could probably build something to run on the card, but that the WiFi would not work. We'd have to either find some way to hack in bits of the original binaries, or find out how to operate the radio on our own.
On another front, I realized that each download of new binary firmware is unique. Even if you ask for the same firmware version and card MAC, you get a different image. The MAC or some other identifier must be recorded in the image because the card refuses to flash a new firmware unless it was downloaded with the correct MAC. Probably a "security" measure to help ensure that people do not flash the firmware for the higher end cards like the "Pro" on to the lower end cards.
It's good to remember that this is just eCos and not the wireless driver or any of the custom Eye-Fi code that runs on the card. This is probably just what Eye-Fi got from Atheros after Atheros ported eCos to the AR6001. What this means practically is that we could probably build something to run on the card, but that the WiFi would not work. We'd have to either find some way to hack in bits of the original binaries, or find out how to operate the radio on our own.
On another front, I realized that each download of new binary firmware is unique. Even if you ask for the same firmware version and card MAC, you get a different image. The MAC or some other identifier must be recorded in the image because the card refuses to flash a new firmware unless it was downloaded with the correct MAC. Probably a "security" measure to help ensure that people do not flash the firmware for the higher end cards like the "Pro" on to the lower end cards.
Tuesday, March 3, 2009
New Eye-Fi models with video
Holy cow! I have impeccable timing. Eye-Fi just announced their cards with video support. I wonder what the write speed is on these new suckers.
Monday, March 2, 2009
Eye-Fi Card Speed
My D90 can record 720p video. A ~145 MB video I took was about 1:27 long which comes out to a bitrate of about 1.67 MB/s. Eye-Fi has apparently announced that they're working on video support. Cool!
The problem is that it does not seem to work. I began recording a video, but it only lasted 20 seconds or so. So, I decided to investigate, as usual. I ran a simple little command-line program to test a bunch of card speeds.
I tried this procedure with 9 different SD cards and an el-cheapo multi card reader. which you can see below:
Unfortunately, the Eye-Fi card was the slowest by a large margin. This confirms what I suspected when the D90 cut off the video recording to the card after 20 seconds. The camera ran out of room in its own buffer since it could not write to the card fast enough. Dang.
The Eye-Fi is even slower than a 64MB MicroSD card that I got with my Garmin GPS, but have never used since it is so tiny. Of those 4GB SDHC cards, I'm pretty sure none of them were over $20; they're all super generic. The Sandisk cards were about $100 when I bought the first one over three years ago.
The problem is that it does not seem to work. I began recording a video, but it only lasted 20 seconds or so. So, I decided to investigate, as usual. I ran a simple little command-line program to test a bunch of card speeds.
DEV=/dev/sdc1; umount $DEV; mount $DEV sdcard/; sync; date; time dd if=/dev/zero of=sdcard/zeros.txt bs=1024 count=$((1<<17)) conv=fdatasync; date; sync; date; rm sdcard/zeros.txt; umount sdcard/
I tried this procedure with 9 different SD cards and an el-cheapo multi card reader. which you can see below:
| Eye-Fi | 64MB SD from Garmin GPS | 4GB SDHC Patriot |
| 2GB Crucial | 2GB Sandisk Ultra II | Newer 2GB Sandisk Ultra II |
| 4GB Kingston | 4GB SDHC "Polariod" PNY | 4GB SDHC Transcend |
The Eye-Fi is even slower than a 64MB MicroSD card that I got with my Garmin GPS, but have never used since it is so tiny. Of those 4GB SDHC cards, I'm pretty sure none of them were over $20; they're all super generic. The Sandisk cards were about $100 when I bought the first one over three years ago.
Friday, February 27, 2009
Eye-Fi and Nikon D90
The economic downturn is affecting everyone. To help stimulate the economy I feel strongly that each and every one of us needs to dig deep and do our part. So, I bought a D90.
I had read that the D90 (and the D60) would at least have some ability to detect Eye-Fi cards when inserted and do something with them. LarryG over on the Eye-Fi forums has a little more explanation of what happens:
However, this is still much ambiguity on the D90, especially on what impact turning off "Eye-Fi Upload" really has. The meter-off delay tuning is really useful and effectively allows the camera to have a completely smart timeout for powering off the card. On the camera's part this requires just being able to read the Eye-Fi card's status.
But, does "Eye-Fi Upload" actually disable the card's WiFi radio? Is that sufficient if I am, say, on an airplane where I can't use radios of any kind? Is the card's power consumption lower in this mode? The Eye-Fi card itself draws roughly as much power as the SLR itself, so will enabling this option double my battery life?
I had read that the D90 (and the D60) would at least have some ability to detect Eye-Fi cards when inserted and do something with them. LarryG over on the Eye-Fi forums has a little more explanation of what happens:
- In order to see the Eye-Fi Menu item in the D90, you will have to have an Eye-Fi Card inserted in the camera. The camera will then display the "Eye-Fi Upload" option in the Setup Menu between the "GPS" and "Firmware version" menu items.
- This new menu gives the user the option to enable or disable the Eye-Fi Card's ability to upload photos when inside the camera.
- In addition to the menu, the D90 will automatically provide power to the Eye-Fi Card when there are photo uploads pending or photos being uploaded. Once all uploads are completed, the camera reverts back to the user defined "Auto meter-off delay" power settings in the Custom Setting Menu.
However, this is still much ambiguity on the D90, especially on what impact turning off "Eye-Fi Upload" really has. The meter-off delay tuning is really useful and effectively allows the camera to have a completely smart timeout for powering off the card. On the camera's part this requires just being able to read the Eye-Fi card's status.
But, does "Eye-Fi Upload" actually disable the card's WiFi radio? Is that sufficient if I am, say, on an airplane where I can't use radios of any kind? Is the card's power consumption lower in this mode? The Eye-Fi card itself draws roughly as much power as the SLR itself, so will enabling this option double my battery life?
Wednesday, February 18, 2009
Ad-Hoc Networks
There have been a few questions about Ad-Hoc networks over time. They simply can't work as it stands. It is not a simple matter of adding the network to the card, or forcing it to be detected.
For one thing, the cards can not be configured to use a static IP address. So there at least needs to be a DHCP server out there on the network somewhere. If someone really, really needs to do this, I would simply suggest a portable and battery-powered access point such as this one.
For one thing, the cards can not be configured to use a static IP address. So there at least needs to be a DHCP server out there on the network somewhere. If someone really, really needs to do this, I would simply suggest a portable and battery-powered access point such as this one.
Tuesday, February 17, 2009
New Release: 008
Brad left a comment with a great bug report. As you can see in gitweb, I've fixed this. I was basically clobbering the password when I converted it from ASCII to a binary format because I forgot that it gets used twice. Oops.
http://sr71.net/projects/eyefi/eyefi-config-008.tar.gz
http://sr71.net/projects/eyefi/eyefi-config-008.tar.gz
Thursday, February 5, 2009
New Release: 007
I've removed the O_DIRECT usage since I got the #ifdefs wrong. Linus says that there's a better way to do it anyway. I've done that, and all appears to be well. This should also make what I did portable to other POSIX platforms. Have fun!
http://sr71.net/projects/eyefi/eyefi-config-007.tar.gz
http://sr71.net/projects/eyefi/eyefi-config-007.tar.gz
Wednesday, January 7, 2009
Working Standalone Server
I'll just point over to Jeff's blog post on the topic. This is a neat development. It should allow people to do things like keep their pictures private and not upload them at all to the Eye-Fi servers.
http://returnbooleantrue.blogspot.com/2009/01/eye-fi-standalone-server.html
This kind of thing could also make a really neat iPhone or Android app, now that Jeff has a proven algorithm. If you can get your phone and your Eye-Fi card on the same WiFi network, you could view things as they come out of your camera.
Anybody know of any tiny battery-powered 802.11 access points? I bet one of these plus one of these would be interesting. I'll have to test Jeff's program with an isolated wireless network and see what happens.
http://returnbooleantrue.blogspot.com/2009/01/eye-fi-standalone-server.html
This kind of thing could also make a really neat iPhone or Android app, now that Jeff has a proven algorithm. If you can get your phone and your Eye-Fi card on the same WiFi network, you could view things as they come out of your camera.
Anybody know of any tiny battery-powered 802.11 access points? I bet one of these plus one of these would be interesting. I'll have to test Jeff's program with an isolated wireless network and see what happens.
Thursday, December 25, 2008
Picasa Download Script
First of all, this is a mess. It uses a bunch of junk in 'daveperl', which is like my personal collection of perl idioms. Stuff like cat_file() that I use all the time and hate re-coding. I need to extricate this script from that stuff before it can really be useful to other people.
It used to use some Google Picasa perl library, but I grew really impatient with it. It's coded up in some really weird ways that do things like dynamically create perl objects and functions out of the XML that gets spit back from the Picasa API. It is pretty arcane stuff that I never did get working right mostly because it is a deal project.
The current stuff (I think) depends on the CPAN Picasa library and not the Google stuff any longer. But, there may be a dependency on the Google stuff in a place or two.
http://sr71.net/projects/picasa/
It basically goes and finds all the Picasa pictures, then sees if it has local copies. If not, it downloads them and sticks them in a directory. It caches things like the album modification time so it can speed things up not having to download the contents of *each* album during every execution. It uses filenames and exif timestamps to determine uniqueness. I don't do checksums because those change with picture rotation. If anyone finds this compelling or useful, let me know. I'll start trying to clean it up a bit so others might get some more use out of it.
It used to use some Google Picasa perl library, but I grew really impatient with it. It's coded up in some really weird ways that do things like dynamically create perl objects and functions out of the XML that gets spit back from the Picasa API. It is pretty arcane stuff that I never did get working right mostly because it is a deal project.
The current stuff (I think) depends on the CPAN Picasa library and not the Google stuff any longer. But, there may be a dependency on the Google stuff in a place or two.
http://sr71.net/projects/picasa/
It basically goes and finds all the Picasa pictures, then sees if it has local copies. If not, it downloads them and sticks them in a directory. It caches things like the album modification time so it can speed things up not having to download the contents of *each* album during every execution. It uses filenames and exif timestamps to determine uniqueness. I don't do checksums because those change with picture rotation. If anyone finds this compelling or useful, let me know. I'll start trying to clean it up a bit so others might get some more use out of it.
Friday, December 19, 2008
Freestanding Server
People have asked a few times if there is a freestanding server or some other program to which the Eye-Fi card can upload. No, not really.
Here's how the Eye-Fi card and service work, at least in the way that I have them set up. This differs for the Eye-Fi "Home" card, or if you don't have the "upload to Internet" (or whatever it is really called) enabled.
There were a few people working on a server to replace the Eye-Fi Manager. I have not heard about that effort in a while. There are some security mechisms built into the card to keep it from uploading to unauthorized software which make this hard to do. I don't think this is Eye-Fi being nasty or hating Linux or anything. It's a genuine security feature to keep the "bad guys" from tricking your card into sending all its pictures to the evil hackers. I would love to write a open replacement for this part of the Eye-Fi Manager, but I'm not sure how feasible that would be and still ensure that the "bad guys" don't do the same. I'd be more than willing to give it a shot if I had some idea how the card authentication worked.
What I do personally is that I trust Eye-Fi with my pictures. I let them go to Eye-Fi, then get uploaded to Picasa. I paid the $20/year or whatever it was to get 10GB of extra storage at Google. Then, I use the official Picasa API and some perl to download the pictures from Picasa back to my web server where I stick them in my own photo album. The downside to this is that I have to trust Google and Eye-Fi with my pictures along the way. The upside is that when I take a picture, it automatically gets backed up in three different places.
Here's how the Eye-Fi card and service work, at least in the way that I have them set up. This differs for the Eye-Fi "Home" card, or if you don't have the "upload to Internet" (or whatever it is really called) enabled.
- You take a picture, and dump it on your card
- Your card notices the picture gets on the network and looks for your PC. If it can't find your PC, it uploads directly to api.eye.fi (an Eye-Fi managed server on the internet)
- If it can find your PC running the Eye-Fi Manager, it uploads to your PC and lets the PC upload to Eye-Fi. The PC keeps a copy if you asked it to.
- The Eye-Fi server looks at your preferences and uploads pictures to Picasa, Flickr or whatever you want.
There were a few people working on a server to replace the Eye-Fi Manager. I have not heard about that effort in a while. There are some security mechisms built into the card to keep it from uploading to unauthorized software which make this hard to do. I don't think this is Eye-Fi being nasty or hating Linux or anything. It's a genuine security feature to keep the "bad guys" from tricking your card into sending all its pictures to the evil hackers. I would love to write a open replacement for this part of the Eye-Fi Manager, but I'm not sure how feasible that would be and still ensure that the "bad guys" don't do the same. I'd be more than willing to give it a shot if I had some idea how the card authentication worked.
What I do personally is that I trust Eye-Fi with my pictures. I let them go to Eye-Fi, then get uploaded to Picasa. I paid the $20/year or whatever it was to get 10GB of extra storage at Google. Then, I use the official Picasa API and some perl to download the pictures from Picasa back to my web server where I stick them in my own photo album. The downside to this is that I have to trust Google and Eye-Fi with my pictures along the way. The upside is that when I take a picture, it automatically gets backed up in three different places.
Thursday, December 18, 2008
Eye-Fi Config Release 006
Someone asked for this, so here you go!
This basically just adds WEP support. It only handles the WEP-128 keys specified as hex. This was not hard to add since the EyeFi card has most of the smarts to do the network type selection internally.
http://sr71.net/projects/eyefi/eyefi-config-006.tar.gz
I still need to figure out how to get the firmware updated without going into Windows. There' some experimental code in here, but it does not work.
This basically just adds WEP support. It only handles the WEP-128 keys specified as hex. This was not hard to add since the EyeFi card has most of the smarts to do the network type selection internally.
http://sr71.net/projects/eyefi/eyefi-config-006.tar.gz
I still need to figure out how to get the firmware updated without going into Windows. There' some experimental code in here, but it does not work.
Tuesday, November 25, 2008
Is the "Anniversary Edition" really SD or SDHC?
My "big" camera is a Nikon D50. It is a wonderful camera, but it is getting a bit dated and only takes regular SD cards, not SDHC. As I understand it, the SD specification is limited to 2GB, but the hardware can handle a full 4GB of addressing. The SD standards people artificially lowered the standard to 2GB either to move people to the SDHC standard faster or for some technical reason I don't yet understand. Are there technical issues with some devices and 4GB FAT16 partitions?
There is also evidently a requirement in the standard that SDHC cards be FAT32-formatted. Older cameras (like the D50) can't read this filesystem even if it were present on a small capacity card. The neat part of all of this is that some "4GB SDHC" cards are actually plain old SD cards electrically and just rebadged as SDHC since a 4GB card isn't allowed to have the 'SD' logo. What I'm saying here is all speculation on my part that I've pieced together from some very reliable web forums. :)
There have been some reports that, if you get one of these cards, simply formatting a 4GB FAT32 SDHC card as the older FAT16 will make it work in cameras like my D50. I really wonder if this new Anniversary Edition card is one of these special beasts. It would make sense for Eye-Fi to do this since "all" they'd have to do is replace the on board flash with a bigger chip and wouldn't have to change the card electrically to support true SDHC. For $79 shipped at Costco, I just may have to find out!
There is also evidently a requirement in the standard that SDHC cards be FAT32-formatted. Older cameras (like the D50) can't read this filesystem even if it were present on a small capacity card. The neat part of all of this is that some "4GB SDHC" cards are actually plain old SD cards electrically and just rebadged as SDHC since a 4GB card isn't allowed to have the 'SD' logo. What I'm saying here is all speculation on my part that I've pieced together from some very reliable web forums. :)
There have been some reports that, if you get one of these cards, simply formatting a 4GB FAT32 SDHC card as the older FAT16 will make it work in cameras like my D50. I really wonder if this new Anniversary Edition card is one of these special beasts. It would make sense for Eye-Fi to do this since "all" they'd have to do is replace the on board flash with a bigger chip and wouldn't have to change the card electrically to support true SDHC. For $79 shipped at Costco, I just may have to find out!
Subscribe to:
Posts (Atom)
