CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: andyroo on 15 / August / 2011, 17:34:00
-
Hi CHDK folks!
I'm still pretty new to CHDK, but I find myself in the position where I think I need to do a custom build - or get one of the amazing developers on here interested in supporting my cause...
I found some code by Dave Hansen, who wrote eyefi-config, to be able to both configure and query the log from an Eye-Fi card on *nix systems, including CHDK (http://git.sr71.net/cgi-bin/gitweb.cgi?p=eyefi-config.git;a=summary (http://git.sr71.net/cgi-bin/gitweb.cgi?p=eyefi-config.git;a=summary)).
He even did a CHDK port - sort of http://dave-hansen.blogspot.com/2008/07/eye-fi-config-release-004.html (http://dave-hansen.blogspot.com/2008/07/eye-fi-config-release-004.html) but it doesn't really sound finished. He says You need to move files between my project and CHDK and splice them in and recompile.
But there isn't clear information on how to expose his code in CHDK, and I'm really rusty, having only amateurly programmed (mostly scripted) since some pascal and basic years ago. I don't really understand how I could splice this code into CHDK and expose it to scripting.
Would I need to add Lua support for the functions in Dave's code if I want to use it in Lua scripts? And if I want an "Eye-Fi menu" in CHDK, I imagine I would need to edit the CHDK main menu to add an Eye-Fi menu (probably first run his function to test if there's an eye-fi card) then make an Eye-Fi submenu that links to his functions to configure and display card settings
It seems like Dave's code is the place to start to add full-fledged Eye-Fi support to CHDK. The part that I really want is to be able to query the upload status of files, so that once they're uploaded, I can delete them within a CHDK script. If I can get the Eyefi-config functionality into Lua, I can parse the logs to get that info, but, more importantly, one of the Eye-Fi founders said that If you can get this to work inside CHDK, then I'd be willing to share with you a few things ... to "ask" the Eye-Fi Card what the upload status of an individual file is, instead of going to hackish method of interpreting log messages (which, ironically, recently changed).
My initial thought was that I need to bite the bullet, install the Windows GUI for trunk building by whim, figure out how to splice in the Eyefi-config code, then figure out how to expose it in CHDK - probably adding both a menu interface for the functions and scripting functionality.
My second thought was, "Wow. That's a lot"
And my third thought was to ask for help/advice. Like "Where do I even start?" And that's why I posted this. Also because deep down I hope somebody way better at this than me will look at the code and go, "cool! that's gonna be easy!" :D
Thank you all you developers for doing amazing work on CHDK. Especially helpful for me have been reyalp and philmoz, and now I think whim. Oh and PhyrePhoX and waterwingz .. yeah. there are lots of great folks here. Thanks again.
-
Don't the Eye-Fi cards already have an option to automatically delete old files after they've been uploaded?
Phil.
-
Don't the Eye-Fi cards already have an option to automatically delete old files after they've been uploaded?
The EyeFi cards kind of have that option (Endless Memory), but (1) it ONLY works if the card is formatted in FAT32, and (2) it deletes the file over a series of several power cycles. Also (3) I don't think the Eye-Fi card can see other partitions. When you install CHDK on a small FAT16 partition and swap to a larger FAT32 partition on boot, the Eye-Fi card can't find any files to upload.
I think Berend said on the Eye-Fi forums that the files aren't fully deleted for around 4-5 power cycles. And it doesn't work so well if it has more than a few (~50?) files to delete because it has to do it in the short window where it does stuff before the camera accesses the filesystem. And from the sounds of it, "it will never will work on FAT16 filesystems". So that would be pretty cool if CHDK could overcome that limitation on older cameras by acting as the intermediary between Eye-Fi and the camera's OS.
Anyway, I thought that enabling "native" Endless Memory was impossible until I read your post about getting CHDK to boot on FAT32 on the IXUS 310 and funnel's post confirming it on the SX220 (http://chdk.setepontos.com/index.php?topic=6645.0 (http://chdk.setepontos.com/index.php?topic=6645.0)). I read that thread and got so excited I opened a new tab and bought an SX230 HS (crosses fingers) and another Eye-Fi card right there. (guess maybe I'll be the tester for the SX230). With that solution, I should be able to get a camera up and running that does an endless timelapse without EyeFi-Config built into CHDK. I guess I'm still out of luck for the SX30 and A720 though - Until CHDK and Eye-Fi can talk to each other.
BUT
IF we can get that EyeFi-config code incorporated into CHDK, then we should be able to query the card to find out whether an image has been uploaded, and delete it via script, making endless memory another added CHDK function for those older cameras.
AND - an Eye-Fi menu would make it so you could do so many things right from the camera:
-turn on ad-hoc mode to connect to an iphone or android phone
-turn off antenna to save battery
-fetch/set endless storage setting
-connect to a new secure or public network without taking your card out of the camera
-and more!
-
I took a quick look at the code you linked to - it appears that you communicate with the eye-fi by reading and writing specific files on the card. Implementing this in CHDK should not be too hard; but would require a card for testing (for some reason they aren't readily available where I live).
Since most recent cameras also have some eye-fi support in the firmware, there may be firmware functions you could use to do some of the work required. It's possible that Canon has included a code library supplied by eye-fi into the camera firmware, so if you can find the right functions it might make it easier (and would mean less code added into CHDK).
Phil.
-
Since most recent cameras also have some eye-fi support in the firmware, there may be firmware functions you could use to do some of the work required. It's possible that Canon has included a code library supplied by eye-fi into the camera firmware, so if you can find the right functions it might make it easier (and would mean less code added into CHDK).
It would be easier but would also leave most of the installed base of Canon camera's ported to CHDK behind. Still, take what you can get I guess.
-
It would be easier but would also leave most of the installed base of Canon camera's ported to CHDK behind. Still, take what you can get I guess.
Do the eye-fi cards work on old cameras with no built-in support in the firmware?
If there are usable firmware functions in newer cameras the code can always be pulled out and copied into CHDK for older cameras. All speculation of course until someone with an eye-fi card does some experimenting :)
Phil.
-
All speculation of course until someone with an eye-fi card does some experimenting :)
Yup. And given that I'm still trying to find time to experiment with a simple switch and battery to figure out the USB remote code, it won't be me putting up my hand to volunteer to take this on.
-
Yup. And given that I'm still trying to find time to experiment with a simple switch and battery to figure out the USB remote code, it won't be me putting up my hand to volunteer to take this on.
Personally, I think this would be easier than deciphering the USB remote code in CHDK :D
-
Do the eye-fi cards work on old cameras with no built-in support in the firmware?
the eye-do cards work in any camera but they won't do endless memory on FAT16 cards.
But part of the beauty of the eye-fi cards is that their operation is invisible to cameras that aren't eye-fi aware.
Adding support to chdk for those cards would add functionality that I haven't seen in any camera.and it looked like the code to do it it's pretty small?
-
Dave posted this address for his chdk stuff..sounds like he hadn't revisited it for a while. The dates are around the same time as the github code.
http://sr71.net/~dave/projects/eyefi/chdk/ (http://sr71.net/~dave/projects/eyefi/chdk/)
-
Has anyone kept up with this, I wanted to compile this for the g12 and am not getting it right.
I have uploaded it to github https://github.com/arne182/chdk-eyefi
It compiles but I have not gotten the menu system to work. Can anyone help?
-
Well, I just got a couple of older Eye-Fi cards cheap to put in my stereo camera, so I guess this is my new project :)
-
Okay, the original chdk patch from Dave Hansen is pretty incomplete, so even if it was ported to the latest trunk it wouldn't do much that was useful.
That said, the main work in talking to the card is already done. Really all that's left is UI integration, which I'll probably do mostly from scratch rather than rely on Dave's code.
Time to roll my sleeves up and dig in.
-
Which stereo camera do you have ?
-
A couple of A460's. :)
-
Well, I've got some basic information coming back from my eyefi card now. I've had to do a fair amount of refactoring and cleanup of eyefi-config so that it would play nice with an embedded environment, and it's beginning to bear fruit.
It was almost harder to get a screenshot of the results!
-
I've attached an initial patch for eye-fi support against 1509. There's an OPT_EYEFI option to toggle support in the build.
At the moment it only adds an entry to the Misc menu allowing you to display the card info, names of configured access points, and currently detected APs. I'm gonna need a virtual keyboard before I can support configuring new APs!
Next I'll probably add support for changing the simple settings, such as transfer mode, and enabling/disabling the wifi. Also will start looking into delaying auto-poweroff while an upload is in progress. Delete-on-upload will be implemented if I can get the appropriate API information.
Note: I don't yet check if the current card is an Eye-Fi yet, so don't try the menu options on a standard card! (although the worst that will happen is it might hang waiting for a response.)
-
I'm gonna need a virtual keyboard before I can support configuring new APs!
A text box is in development look here: http://chdk.setepontos.com/index.php?topic=7272 (http://chdk.setepontos.com/index.php?topic=7272)
-
I know, I've been waiting for that to get into trunk :)
-
Okay, the original chdk patch from Dave Hansen is pretty incomplete, so even if it was ported to the latest trunk it wouldn't do much that was useful.
That said, the main work in talking to the card is already done. Really all that's left is UI integration, which I'll probably do mostly from scratch rather than rely on Dave's code.
Time to roll my sleeves up and dig in.
Can I be of any assistance in this. I would also really like to get this working.
-
I've attached an initial patch for eye-fi support against 1509. There's an OPT_EYEFI option to toggle support in the build.
At the moment it only adds an entry to the Misc menu allowing you to display the card info, names of configured access points, and currently detected APs. I'm gonna need a virtual keyboard before I can support configuring new APs!
Next I'll probably add support for changing the simple settings, such as transfer mode, and enabling/disabling the wifi. Also will start looking into delaying auto-poweroff while an upload is in progress. Delete-on-upload will be implemented if I can get the appropriate API information.
Note: I don't yet check if the current card is an Eye-Fi yet, so don't try the menu options on a standard card! (although the worst that will happen is it might hang waiting for a response.)
I have tried the patch and am missing the eyefi-config.h file in the lib\eyefi folder. Can you supply that file still?
-
My patch doesn't use a file called "eyefi-config.h". Are you patching a clean tree?
-
My patch doesn't use a file called "eyefi-config.h". Are you patching a clean tree?
Used a clean tree (r1509), applied patch.
It complained about lib/eyefi not exisiting.
Copied files from patch directoy to tree.
In lib/eyefi/sha1.c and lib/eyefi/md5.c
#include "eyefi-config.h"
is used and therefore won't compile.
Can you tell me what I did wrong?
-
Oh, I see what happened - my development directory has a bit of cruft (including an old eyefi-config.h) left in it, so I didn't notice that there still was a reference to the old file. Thanks for the catch.
In any case, I'm fairly sure the sha1 and md5 files aren't actually used yet, so you might get away with just removing them.
-
Oh, I see what happened - my development directory has a bit of cruft (including an old eyefi-config.h) left in it, so I didn't notice that there still was a reference to the old file. Thanks for the catch.
In any case, I'm fairly sure the sha1 and md5 files aren't actually used yet, so you might get away with just removing them.
I removed them and now I have this error.
../lib/eyefi/libeyefi.a(eyefi.o): In function `make_network_key':
eyefi.c:(.text+0x274): undefined reference to `pbkdf2_sha1'
../lib/eyefi/libeyefi.a(eyefi.o): In function `fetch_card_key':
eyefi.c:(.text+0x6c0): undefined reference to `memmove'
../lib/eyefi/libeyefi.a(eyefi.o): In function `fetch_card_firmware_info':
eyefi.c:(.text+0x6f8): undefined reference to `memmove'
../lib/eyefi/libeyefi.a(eyefi.o): In function `fetch_card_mac_address':
eyefi.c:(.text+0x728): undefined reference to `memmove'
collect2: ld returned 1 exit status
So SHA1 is definitely used but what is memmove?
Do you still have your working copy and can you upload the whole copy to a file share site?
-
Thing is, that version still doesn't actually do anything particularly useful. So it's not really worth spending much time trying to build it until I release a version that actually does something...
-
Thing is, that version still doesn't actually do anything particularly useful. So it's not really worth spending much time trying to build it until I release a version that actually does something...
The point is to help you to get it to work. If you upload it to github then everybody can contribute to making this feature work. Just want to lend a helping hand.
-
Also one interesting feature that would be nice to have is the ability to delete the uploaded photos.
Endless memory only works when you power cycle. But if we can know what files are uploaded and be able to delete them. It would be very nice!
What do you think?
-
There is already a fair amount of work done on that feature; an Eye-fi engineer kindly gave me the details on how to query the card for whether a particular file is uploaded or not.
In any case, sorry I've been too busy to get much work done on this of late - but I just got a TX1 (finally!) so I'm motivated to get back into it.
-
Are there any updates or newer topics regarding this? I just bought an Eye-Fi so I'd love for CHDK to be able to use it to its fullest potential.
-
Would like to get back into programming the CHDK Eyefi part. Just have not had the time at the moment. The additions to CHDK would not be that much. Being able to see the MAC and maybe adding Wifi access points (The problem has always been input, IE Keyboard emulation).
-
Not that I wouldn't love to be able to manage access points directly through CHDK, but if it would help speed up integration with CHDK, then I think that it's a feature that's not quite as important anymore now that smartphones are so common. I can easily transfer the files onto my smartphone using the Eye-Fi app and then use my smartphone to connect to whatever access point/service I want.
-
I implemented a minimal Eyefi functionality in CHDK. I'm able to scan for networks, add and delete them on my G15.
I would be glad to release my code but have no idea how to do it. Anybody wanting to lose some time to explain me?
The code needs some refinements and, needless to say, translations for the string that are now hardcoded in english.
---
P.S. Actually if you transfer to your phone you will lose the upload to your PC and (I think) the georeferentiation of the pictures.
-
I would be glad to release my code but have no idea how to do it. Anybody wanting to lose some time to explain me?
Ideally, you would create and post a patch file against the source tree. How you create that depends on what O/S you are using and how you got your source tree in the first place. So I'll need those details to help you any farther.
Alternatively, if you only modified one or two source files, you can simple zip them up and post here. I'll create a patch file for you from that.
-
Thanks for your quick reply. I started from trunk3117 (release 1.3.0).
Working on Windows. I'm afraid I modified 4-5 files and added 5.... probably better to produce the patch myself. Is something like diff from Cygwin useful?
Here is a screenshot listing available networks detected by the Eyefi card
(https://dl.dropboxusercontent.com/sh/0iaxj5i4h3zkfci/XoQQl7vWo7/CHDK_Eyefi_screenshot.jpg?token_hash=AAGYocZd06WJ1PsFU-wTB3o8yVNaG84Px_YINhS2q1Af2Q)
-
Is something like diff from Cygwin useful?
Probably. Post it and I can take a look.
But be warned that the path from there to eventual inclusion in the svn trunk is a long and sometimes painful one.
-
Is something like diff from Cygwin useful?
Probably. Post it and I can take a look.
But be warned that the path from there to eventual inclusion in the svn trunk is a long and sometimes painful one.
Purely co-incidental, but I was just reading this (http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/)...
As someone who regularly goes through this particular pain barrier, it makes interesting reading.
Item 4 is a particular bug bear of mine, some people still think that you should be able to follow their code entirely without comments, and if you can't thats because you are not a smart as them.
-
Here is the ZIP with the files I modified and added. Part of the code is adapted from the work of Dave Hansen ([email protected]), released under GPL version 2 license.
Actually I only used the SHA1 encrypting routines, although all my code relies on his reverse engineering of the Eyefi protocol.
-
I implemented a minimal Eyefi functionality in CHDK. I'm able to scan for networks, add and delete them on my G15.
Code looks clean - nice job at first glance.
As I don't have an eyefi card, can you tell me what the code does that you can't do with just the generic eyefi card installed in your camera?
-
The standard Canon support for the Eyefi card is limited to telling you the card's status (connecting, uploading, disconnected) and the upload status of the pictures.
If you want to register on a wireless network you need a PC and the Eyefi's software (or a replacement: Dave wrote a config command line utility in C, I wrote another in C#).
My implementation permits you to list the wireless networks (SSIDs) visible from the Eyefi's, and specify a password for connecting.
It allows also to list the networks configured on the card in order to delete any of them.
More functionalities could be added, but this two are what you really need when you're on the road
-
The standard Canon support for the Eyefi card is limited to telling you the card's status (connecting, uploading, disconnected) and the upload status of the pictures. If you want to register on a wireless network you need a PC and the Eyefi's software (or a replacement: Dave wrote a config command line utility in C, I wrote another in C#).
My implementation permits you to list the wireless networks (SSIDs) visible from the Eyefi's, and specify a password for connecting. It allows also to list the networks configured on the card in order to delete any of them.
Sorry for being obtuse but what does "register on a wireless network" mean? I assume that means letting your set the SSID the camera uses and the WEP / WPA key password stuff? Then what happens - how do you get pictures off your camera and onto a wireless device ( phone / tablet / laptop ). I expect this would be obvious if I actually had a eyefi card - time to order one I guess.
Also, if you are going to do more CHDK development, you probably want to look at the svn tools. Tortoise SNV is really nice for Windows development - there are also Linux command line and GUI tools available.
I took the liberty of converting your files to an svn compatible patch file that can be applied against the current trunk, tested it as much as I could without actually having a card, and attached it here. Removed some DOS line endings in a couple of files, cleaned up a couple of small spacing things, and moved your new menu item to the Miscellaneous Stuff menu from the root menu (sorry).
Its up to reyalp/philmoz but it looks clean enough to me to be added to 1.3.0. Prior to any svn commit philmoz might have some thought on putting the code into an flt module - especially the md5 / sha1 stuff.
-
Yes, i mean specifying an SSID and WPA or WEP key (and yes, you definitely need to buy one ;) ).
I normally use svn command line, but it seemed impossible to make it coexist with the chdk shell, sorry.
The Eyefi card uploads pictures to a central server, which georeferentiates them (if possible). The so called Eyefi helper sits in your tray bar waiting to get them down to your pc. If you mark a picture as "read only" it gets downloaded first, and possibly to Flickr or Facebook or another dozen of sites according to how you configured your card.
I approve/appreciate your modifications. How will I know that the patch has been added to the code repository?
-
Yes, i mean specifying an SSID and WPA or WEP key (and yes, you definitely need to buy one ;) ).
Nice!
So if you have wifi cards in a couple of cameras all active at the same time, how are they named on the network?
I normally use svn command line, but it seemed impossible to make it coexist with the chdk shell, sorry.
No problem. But if you decide to setup an local svn copy on your PC, you can use the CHDK_Shell build environment to compile it. Either start CHDK_Shell normally and use the command prompt button to take you to a DOS box, or just start with a DOS box and run something like this (substitute your camera name and f/w version of course) :
gmake PLATFORM=g10 PLATFORMSUB=102a firzipsubcompleteThe only other trick if you don't use the CHKD-Shell command prompt box is to set the environment correctly - you can do that by first using CHDK-Shell, going to the command prompt and looking at how it sets things up.
The Eyefi card uploads pictures to a central server, which georeferentiates them (if possible). The so called Eyefi helper sits in your tray bar waiting to get them down to your pc. If you mark a picture as "read only" it gets downloaded first, and possibly to Flickr or Facebook or another dozen of sites according to how you configured your card.
Very cool. Might be interesting for all the multi-camera "bullet time" projects too although I suspect speed is an issue.
I approve/appreciate your modifications. How will I know that the patch has been added to the code repository?
I took another look and it will definitely need to be converted to modules. I'm not going to worry about that just yet though.
Normally completed patch files are posted here :
http://chdk.setepontos.com/index.php?topic=650.0 (http://chdk.setepontos.com/index.php?topic=650.0)
and one of the dev's will usually post if / when it's been accepted. It's recommended that significant patches be discussed in a thread first (which is what we are doing).
Actual updates get listed here
http://chdk.setepontos.com/index.php?board=41.0 (http://chdk.setepontos.com/index.php?board=41.0)
but usually that's only after a period of "discussion" ( a.k.a. arguements and swearing :) ) Frankly, that thread is a bit painful to follow.
-
So if you have wifi cards in a couple of cameras all active at the same time, how are they named on the network?
I think "Eyefi-serial#", but that's not something you should care; eyefi cards are meant to work in a fully automated way, they're not meant to act as tiny networked computers.
There are a couple of similar cards you might be interested to. In particular the Transcend, that has recently been fully hacked (http://hackaday.com/2013/09/19/advanced-transcend-wifi-sd-hacking-custom-kernels-x-and-firefox/ (http://hackaday.com/2013/09/19/advanced-transcend-wifi-sd-hacking-custom-kernels-x-and-firefox/))
-
I think "Eyefi-serial#", but that's not something you should care; eyefi cards are meant to work in a fully automated way, they're not meant to act as tiny networked computers.
If you are doing stereo or "bullet time" multicamera rigs, the camera position (and thus the name) matters when you are wading through hundreds of shots afterwards. I assume there is something in the uploaded filename (or EXIF info) that would let you sort that out?
There are a couple of similar cards you might be interested to. In particular the Transcend, that has recently been fully hacked (http://hackaday.com/2013/09/19/advanced-transcend-wifi-sd-hacking-custom-kernels-x-and-firefox/ (http://hackaday.com/2013/09/19/advanced-transcend-wifi-sd-hacking-custom-kernels-x-and-firefox/))
Saw that when it came out - very nice hack! Do you expect them all to work with your CHDK mod? I thought there were at least two generations of eyefi cards - does it matter which you use?
-
If you are doing stereo or "bullet time" multicamera rigs, the camera position (and thus the name) matters when you are wading through hundreds of shots afterwards. I assume there is something in the uploaded filename (or EXIF info) that would let you sort that out?
I must check, but I think it's possible to configure the card to put a custom tag. More on this later. You would almost surely be able to configure each card to upload to a different directory on the target PC.
Saw that when it came out - very nice hack! Do you expect them all to work with your CHDK mod? I thought there were at least two generations of eyefi cards - does it matter which you use?
No my (er... Dave's) hack is very specific to Eyefi cards. But I think it is not version specific. I'll have to check on my old Eyefi if I can get it to work (the plastic case is broken...)
-
But I think it is not version specific. I'll have to check on my old Eyefi if I can get it to work (the plastic case is broken...)
If this is going to end up in the main release then knowing which cards it supports will be important. I tried to find a web page that lists all the models - current and old - but did not have any success. Have you seen anything?
-
If this is going to end up in the main release then knowing which cards it supports will be important. I tried to find a web page that lists all the models - current and old - but did not have any success. Have you seen anything?
No, it seems like they only like to list the current models. In any case only a user with a certain model can say if it actually works or not...
-
More functionalities could be added, but this two are what you really need when you're on the road
Here is some functionality that I think would be very useful. I mentioned this in a different thread, but this seems to be the main eye-fi thread so I will repeat it here.
For many Powershots Canon turns off wifi when taking a photo. This is a pain in direct mode since it delays the photo transfer: your PC needs to reconnect to the wifi each photo. The photo transfer is already slowed by other delays the eye-fi card imposes -- perhaps to try to prevent the interruption of a transfer in progress.
It would be great to fix this problem. Any ideas? One possibility might be to fool Canon into thinking that the card is disabled when it is not.
-
For many Powershots Canon turns off wifi when taking a photo.
I think it would help (those who plan to look into the code) if you could name exact camera models with (and without) this issue.
-
Here is the eye-fi compatibility page. http://support.eye.fi/cameras/#canon (http://support.eye.fi/cameras/#canon)
The issue exists for the G12, G1X, SX150, Elph300, SX30, SX40, but not the G15 or SX50. I think it exists for older Powershots that recognize the card, but not the newest ones. Much older ones that do not recognize the card work fine.
For many Powershots Canon turns off wifi when taking a photo.
I think it would help (those who plan to look into the code) if you could name exact camera models with (and without) this issue.
-
For many Powershots Canon turns off wifi when taking a photo.
It sounds like Canon is deliberately turning off the wifi power to the EyeFi card when it takes a picture. It's possible that there's not enough power available to power both at the same time. But I guess you never know until you try it, if it's possible.
-
For many Powershots Canon turns off wifi when taking a photo.
Did you check the Eyefi's log files to see if it reboots (power off than on) or receives "weird" commands from the camera?
-
Did you check the Eyefi's log files to see if it reboots (power off than on) or receives "weird" commands from the camera?
How do I do that?
It sounds like Canon is deliberately turning off the wifi power to the EyeFi card when it takes a picture. It's possible that there's not enough power available to power both at the same time. But I guess you never know until you try it, if it's possible.
I agree that it is deliberate, but it is unnecessary as can be seen by the fact that older and newer cameras work fine without turning it off. I think it was due to an overabundance of caution on Canon's part plus they didn't realize the problems it would cause.
-
The Eyefi helper application sitting in the tray bar has a context menu that allows you to save the card's log; obviously enabled only if the card is inserted in the PC's SD slot (or USB reader)
-
I did a comparison between my old A720 and my SX150. The eye-fi worked far better in the A720. It started wifi almost immediately after I took my first picture. Kept it on as I continued to take pictures, and transferred the images quickly.
In the SX150 it was a huge pain. Slow to start the wifi after I took my first picture and then it disconnected after I took each subsequent picture. Sometimes it simply refused to turn back on the wifi. The log is confusing because so much is going on, but this appeared in the SX150 and not in the A720:
[02:24] AP Active - stopping AP
[02:24] AP Idle
[02:24] AP stopped
[02:24] Disconnected from WLAN (reason = 3).
[02:24] WLAN disabled by camera
[02:24] Connection dropped (previous state is 5)
[02:30] Starting scan of media directories...
[02:30] Done scanning for new media (detected 97 MB in all media). Uploads pending.
[02:30] Done scanning for all photos. Uploads pending.
[03:00] WLAN enabled by camera
I think Eye-fi and Canon totally screwed this up. Perhaps bad communication between the two engineering teams. I know how this can happen. Possibly Canon realized that they had wifi cameras in the works and had really no incentive to do a good job with a different company.
At any rate I would love to get the A720 behavior with my G1X.
Jon
-
For the problem on cameras that "support" eye-fi in the canon firmware, I suspect adding eye-fi control code to CHDK isn't going to help. You would have CHDK and the canon firmware issuing different commands, which isn't likely to end well.
(edit: this is also general concern with adding eye-fi control code to cameras that have canon firmware support)
A more workable approach is likely to hook the canon code. It looks like there is a task dedicated to eyefi control, can be found by "EyeFiComControl.c" and a call to createtask (looking at sx160 dump). This code eventually access the eye-fi control files.
Possibly this could be hooked to ignore certain messages, or perhaps the messages are sent by a task we already hook like captseq.
A possible reason Canon might do this is concern about RFI issues. Or perhaps performance impacts if both the camera and eyefi are talking to storage?
-
I found a function that checks for an uppercase "EYEFI" string.
sx150 100a:
sub_ffa70630:
ffa70630: e92d4010 push {r4, lr}
ffa70634: e3a02005 mov r2, #5
ffa70638: e28f1fe6 add r1, pc, #920 ; ffa709d8: (46455945) *"EYEFI"
ffa7063c: ebf68e8f bl strncmp
ffa70640: e2700001 rsbs r0, r0, #1
ffa70644: 33a00000 movcc r0, #0
ffa70648: e8bd8010 pop {r4, pc}
sub_ff9170c8: ; 8 refs
ff9170c8: e92d401c push {r2, r3, r4, lr}
ff9170cc: e59f0480 ldr r0, =0xa5940
ff9170d0: e5d01006 ldrb r1, [r0, #6]
ff9170d4: e3510000 cmp r1, #0
ff9170d8: 15d00001 ldrbne r0, [r0, #1]
ff9170dc: 1a00000d bne loc_ff917118
ff9170e0: e1a0000d mov r0, sp
ff9170e4: eb0152f9 bl sub_ff96bcd0 ; retrieve some card(?) related data
ff9170e8: e3500000 cmp r0, #0
ff9170ec: 1a000008 bne loc_ff917114
ff9170f0: e1a0000d mov r0, sp
ff9170f4: eb05654d bl sub_ffa70630 ; check for EYEFI in the previously retrieved data
ff9170f8: e3500000 cmp r0, #0
ff9170fc: 0a000004 beq loc_ff917114
ff917100: e59f0450 ldr r0, =0x10c2
ff917104: ebfe11c2 bl IsControlEventActive_FW
ff917108: e3500000 cmp r0, #0
ff91710c: 13a00001 movne r0, #1
ff917110: 1a000000 bne loc_ff917118
loc_ff917114: ; 2 refs
ff917114: e3a00000 mov r0, #0
loc_ff917118: ; 2 refs
ff917118: e8bd801c pop {r2, r3, r4, pc}
sub_ff9170c8 is the only function that calls the string checker routine, it could be the card type detector. One could peek (and poke if brave enough) around 0xa5940, maybe the detection can be sabotaged...
By poking I mean specifically the bytes at 0xa5941 and 0xa5946, as the above routine expects.
This will obviously only work if the data around 0xa5940 is not refreshed continuously. Even if it "works", the result may not be useful at all, since the firmware may have already detected the card in the boot process.
-
this is also general concern with adding eye-fi control code to cameras that have canon firmware support
I think you're right, although in practice I did not experience any conflict while playing with my eye-fi chdk code.
I thought of a possible solution which could really help with the SX150 woes.
I guess that the standard SX150 menus let you disable the WLAN in the EyeFi. After that the camera would not probably care about turning it off and on again when you take a picture. If we just added a command to force it on again in the CHDK menus, we could trick Canon's firmware to stop bothering the card.
The only problem is I don't actually know how to turn on/off the WLAN in the Eyefi. But it shouldn't be that hard to reverse engineer it. Let me know what you think of my reasoning.
EDIT - Dave Hansen's code includes turning on/off the WLAN, so this is not a problem; if you want I can add this possibility to my code
-
I agree that your solution might work. Please do put it into your Eyefi code.
Jon
I guess that the standard SX150 menus let you disable the WLAN in the EyeFi. After that the camera would not probably care about turning it off and on again when you take a picture. If we just added a command to force it on again in the CHDK menus, we could trick Canon's firmware to stop bothering the card.
The only problem is I don't actually know how to turn on/off the WLAN in the Eyefi. But it shouldn't be that hard to reverse engineer it. Let me know what you think of my reasoning.
EDIT - Dave Hansen's code includes turning on/off the WLAN, so this is not a problem; if you want I can add this possibility to my code
-
I agree that your solution might work. Please do put it into your Eyefi code
Do you want me to post the .BIN for the SX150IS or a source patch file?
-
Hi buttim,
fastest way would be to post the .bin. I am not very skilled at applying patches.
Jon
Do you want me to post the .BIN for the SX150IS or a source patch file?
-
fastest way would be to post the .bin. I am not very skilled at applying patches.
Do you want me to post the .BIN for the SX150IS or a source patch file?
.BIN coming...
-
Some initial testing.
1. It sees the available and configured networks
2. If I click on a configured network it allows me to remove it, but if I decline to remove it still says it has removed it.
3. I need numbers and lowercase to connect to available networks.
4. Forcing the wlan on or off seems to have no effect. The Canon direct mode behavior is still the same.
If I disable the card in the Canon menu turning on wlan in the CHDK menu has no effect.
Jon
-
1. It sees the available and configured networks
Good!
2. If I click on a configured network it allows me to remove it, but if I decline to remove it still says it has removed it.
Very strange; I will check it
3. I need numbers and lowercase to connect to available networks.
The input box is a standard feature of CHDK; you can change character pressing the shoot button at half position, delete by zoomin out
4. Forcing the wlan on or off seems to have no effect. The Canon direct mode behavior is still the same
I'm experimenting myself and yes this doesn't really seem to work; I'll let you know; may be an untested functionality by Dave or a trivial bug by myself
-
I corrected a couple of mistakes. Now the wlan enable should work.
Updated binaries for the SX150is attached.
EDIT - I uploaded a better version (I just refactored the code for internationalization)
-
Success!
When I disable the card in the Canon menu and enable the wlan in CHDK the card works beautifully to transfer in direct mode. Transfers are quick.
Last night I figured out the text input and used CHDK to connect to a network. Just after I got a success message the camera shut down. This happened twice.
Today with your new build I entered the same password, but it gave a wrong password message.
When I disabled a network (that I had setup using the eyefi center code on my laptop) the Canon menu no longer saw it, but the card still sees it and transfers to it.
Good Work! This makes the card functional for many Powershots.
Jon
-
Maybe I'm somehow interfering with the camera dialogue to the eyefi, so the camera rebooted because of an unexpected situation; If you want to play safe you'd better turn off wlan with the camera's menus, then force it on and do whatever you want.
Keep trying and reporting strange behaviors, please
-
Hi,
I tried turning it off in Canon menu. CHDK was able to see the available networks, but I still got a wrong password message when I tried to connect. I think I am entering the right password because I tried the old code again and it connected. It did not shut down this time so the shutdown might be a random thing. Of course in the old code I needed to use the Canon menu to turn the wlan on. The Canon menu does not see the new connection, but the eye-fi card uses it to transfer images.
If you want to play safe you'd better turn off wlan with the camera's menus, then force it on and do whatever you want.
-
I corrected a couple of mistakes. Now the wlan enable should work.
Updated binaries for the SX150is attached.
EDIT - I uploaded a better version (I just refactored the code for internationalization)
Are you "up" to doing a patch file now or would you prefer to post the code and have me do it again?
-
CHDK was able to see the available networks, but I still got a wrong password message when I tried to connect.
Damn, I made another mistake. The network testing code was wrong.
I can't see why the Canon software doesn't see the network though.
Try with this version, it should be ok now.
Are you "up" to doing a patch file now or would you prefer to post the code and have me do it again?
I attached a patch file, but please check if it makes sense. The diff refers to version 3118
-
I attached a patch file, but please check if it makes sense. The diff refers to version 3118
Your patch file only includes changes to existing CHDK files. New files you added are missing - eyefi.c, eyefi.h, eyefi_config.h etc
-
Another upgrade, the bugs were not still solved. This time I did much more testing at last.
Still not able to produce a correct patch file, sorry. Working on it
-
Another upgrade, the bugs were not still solved. This time I did much more testing at last.
Still not able to produce a correct patch file, sorry. Working on it
If you are using svn to get your source, you need to do an svn add filename for each of the new files you have created prior to producing a patch file.
-
Currently not using svn but the CHDK shell. It has an option for producing a patch but the result was wrong as you remarked.
If I try to use command line diff (diff -rBN trunk3118 trunk3118eyefi) I get tons of outpt relative to generated files. I tried to get a clean source directory using gmake clean but got some errors:
>> Cleaning in tools
>> Cleaning in tools/elf2flt
>> Cleaning in modules
>> Cleaning in modules/../lib/lua
>> Cleaning in modules/../lib/ubasic
>> Cleaning in modules/../lib/armutil
>> Cleaning in modules/../lib/math
>> Cleaning in modules/../lib/lang
>> Cleaning in modules/../lib/font
>> Cleaning in modules/../lib/core
>> Cleaning in CHDK
>> Cleaning in platform/
c:\chdk\gcc\bin\gmake.exe[1]: *** No rule to make target `clean'. Stop.
gmake: *** [clean-recursive] Error 1
-
Currently not using svn but the CHDK shell. It has an option for producing a patch but the result was wrong as you remarked.
Like I mentioned earlier, at some point CHDK-Shell is more trouble than its worth (and its worth a lot when you are building your own versions of CHDK as a newbie!).
http://chdk.setepontos.com/index.php?topic=6753.msg105556#msg105556 (http://chdk.setepontos.com/index.php?topic=6753.msg105556#msg105556)
I think I switched to svn from CHDK-Shell diff for the exact reasons you are discovering.
-
My try at producing a patch file with SVN. Hope it works...
-
Hi,
This version works to connect to a network. Still does not show in Canon menu, but the card knows it is connected and transfers images. If I delete the network (and turn on wlan, seems to be necessary even though it was turned on) the card will establish its own wlan which I can connect to.
One issue: the connect to network menu item starts up with a garbage password that has to be deleted.
All in all it is working very well. Good job.
Jon
Another upgrade, the bugs were not still solved. This time I did much more testing at last.
-
Still does not show in Canon menu, but the card knows it is connected and transfers images.
What do you mean by "Canon menu"?
One issue: the connect to network menu item starts up with a garbage password that has to be deleted.
True. Corrected
-
Canon has a menu that allows you to enable or disable the card and to view connections and status (transferring or not). There is no way to connect to a new network in the Canon menu.
I can remove a network using CHDK and Canon will see that it has been removed when the camera is next turned on. Canon will not see a network immediately that I have added with CHDK, but the card will transfer images using it and after a while Canon will see it.
Jon
Still does not show in Canon menu, but the card knows it is connected and transfers images.
What do you mean by "Canon menu"?
One issue: the connect to network menu item starts up with a garbage password that has to be deleted.
True. Corrected
-
I will give a look to the user manual of your camera. I have a G15 which actually supports EyeFi cards. But i just can see if it's connected or not (and to which SSID) enable and disable it. And which pictures have already been uploaded. I am not able to list the configured networks.
Remember that with cameras like yours (and mine) which support Eyefi it's better to disable the card while forcing ther Wlan on with the CHDK menu. This in order to eliminate interference between Canon's firmware and CHDK while talking to the card.
-
I think your G15 and my SX150 have the same Canon menu. I must have given you the wrong impression.
I will give a look to the user manual of your camera. I have a G15 which actually supports EyeFi cards. But i just can see if it's connected or not (and to which SSID) enable and disable it. And which pictures have already been uploaded. I am not able to list the configured networks.
Remember that with cameras like yours (and mine) which support Eyefi it's better to disable the card while forcing ther Wlan on with the CHDK menu. This in order to eliminate interference between Canon's firmware and CHDK while talking to the card.
-
Hi Buttim,
Could you post your eyefi code that was not included in the diffs you posted earlier. I'd like to compile for a couple other cameras I have.
Jon
-
Could you post your eyefi code that was not included in the diffs you posted earlier. I'd like to compile for a couple other cameras I have.
The last one I posted (29 sptember, 18:25:37) is ok and contains all the new files:
core/eyefi.c
core/eyefi.h
core/eyefi-config.h
core/sha1.c
core/md5.c
-
You are right. Sorry I was thinking about an older version.
Jon
The last one I posted (29 sptember, 18:25:37) is ok and contains all the new files:
core/eyefi.c
core/eyefi.h
core/eyefi-config.h
core/sha1.c
core/md5.c