admin

Those specs are reasonable, but only because you want to process your images as well on that laptop. The only new term here is the NVMe drive. Just think of NVMe as the next generation of SSD drive. An NVMe drive is an SSD, but 3 to 5 times faster. It's the new thing. As for the i7, it's a safe bet. The recommended 16GB ram is also a good recommendation. I would not go below 16GB for a processing laptop. Regards,

It will accept in-camera TV values only, so AV-FLAT / PROGRAM are not valid arguments.

Well, this might already work after all. Looking at the API code it looks like there's an undocumented parameter called shutter. You need to use the shutter parameter instead of duration parameter. target:{name} duration:{duration in seconds, default is 1} shutter:{any camera valid shutter speed, default is BULB} iso:{100, 400, 800, 1600, default is 1600} quality:{jpg, raw, default is jpg} exposures:{number of images to take, default is 1} imagetype:{1=preview, 0=capture, default is 1} Examples: “takepicture target:M33 duration:300 iso:800” “takepicture duration:15 iso:1600” “takepicture duration:15” “takepicture shutter:1/100 iso:800” “takepicture quality:raw iso:1600” “takepicture target:M13 duration:300 iso:800 imagetype:0”

With the current API, it appears to be the case, yes. I was just looking and the code and there is support for shutter speeds in there, but it looks like it is just missing the mapping from the API supplied parameter to the actual valid TV shutter value. Might be a simple 10 minute fix. If this is the case I'll fix that for the next release for sure. Regards,

You are sending invalid parameters. As per the documentation these are the valid values for each parameters. target:{name} duration:{duration in seconds, default is 1} <<<=== you must send the duration in seconds, not TV shutter speeds iso:{100, 400, 800, 1600, default is 1600} quality:{jpg, raw, default is jpg} exposures:{number of images to take, default is 1} imagetype:{1=preview, 0=capture, default is 1} <<<=== you must send either 1 or 0, not FLAT. Sadly the current API only accept seconds for the duration, not TV shutter speeds specifically. You do bring up a good point however, perhaps TV shutter speeds should be added as a possibility. Internally, BYE has converted the errornous "1/100" TV shutter speed to 1 second and this may be why your flat is overexposed. Regards,

BackyardEOS and BackyardNIKON were designed with save to PC in mind; the save to card is optional and some model can't do it when the camera is tethered to a computer. For most Canon this is a non issue, but for most Nikon this appears to but more frequent. It's never been clear to me if this is a limitation of the SDK or not. The SDK is not documented and there is no support from Nikon so it makes it very difficult to fish features/options out of it. I hope this makes sense. The 4 second is normal to download the image.

Is Windows 10 64 bits and your VM 32 bits? That may be the issue. Your host W10 may have to recognize the camera before handing it off to the VM. If this is the case it will never work because the host W10 pc is 64 bits and can't even see the camera for what it is. Someone with more experience with VM and USB handoff may be able to give you more info; I'm just speculating.

You're using the wrong Canon SDK driver when connecting you camera to BYE. You need choose "Canon", not "Canon210" when connecting your camera. As per the instructions, Canon210 is for cameras that were generally built before 2008. This is not the case with the 1000D-XS.

Well, I may be mistaken... looks like I was using the 450D / XS as well for that video... but was pointing the camera at a 60D box.

There's another video presentation I made for the Raleigh Astronomy club in 2014, I used a 60D in that presentation. I suspect that is the one he is referring to.

I forgot the second part to your question. The BinaryRivers.BackyardEOS.Start is a process used to push some of the work under a separate process. This is optional. If is turned off by default so you must have turned it on in the past. Goto Settings -> Advance Settings and you can turn of the background process. The app will still work the same and in most cases users don't even see the difference.

The capture plan center is not a *live* representation, it's an all in plan and therefore it shows all possible value. The 60D is actually one of the worst camera for this because of (1) it has a B dial mode separate from the M dial mode and (2) most camera with a B and M dial mode allows to change the mode programatically even if the physical dial is set differently. Such is the case with the 40D, but NOT the 60D sadly. Because of item #2, on the 60D, you need to physically turn the knob on the camera. This is a physical limitation of the 60D.

For the 20D, if my memory serves me right, you need to install EOS Capture. This is what it was called back then. Once you install EOS Capture try to connect your 20D with it co confirm that it can at lease communicate with it.

I'm not sure about your D5500 and 5x specifically but it looks like it make not work according to the behavior you get. 4 seconds is normal. As for bulb versus time priority shooting, they should both work with the D5500. I'm still perplexed with the camera reporting a value of "1"for mirrorlock. I find this odd. Can you perform a camera factory reset to ensure all setting are at their default values and try again. I'm wondering if over time a setting was made that could be the cause of this. Regards,

Please provide your full version number when reporting issues. Lets deal with the timeout first. You have a download timeout error in your logs. Please verify that in-camera noise reduction is not turned on. If it is turn it off. You have mirror lock enabled, you need disable it. 2020-01-23 22:36:05,949 [Main] INFO - CameraPropertyChangedArgs fired: MirrorLock = '1' --- 2020-01-23 22:38:53,935 [CameraTakePictureOnMessageRecieved] ERROR - Image download timeout, process terminated after 59 seconds 2020-01-23 22:38:53,935 [CameraTakePictureOnMessageRecieved] ERROR - at BinaryRivers.Common.Model.CameraModelBase.WaitForImageToDownload(Single durationseconds, Boolean isbulb) at BinaryRivers.Common.Model.CameraModelBase.TakePicture(Single mirrorlockseconds, String progresstext) at BinaryRivers.Common.Model.CameraModelBase.<>c__DisplayClass79_0.<CameraTakePictureOnMessageRecieved>b__0(Object state) 2020-01-23 22:38:53,935 [CameraTakePictureOnMessageRecieved] INFO - Timespan 65.911 2020-01-23 22:38:53,945 [CameraTakePictureOnMessageRecieved] INFO - Imaging session cancelled 2020-01-23 22:38:53,950 [CameraTakePictureOnMessageRecieved] INFO - Image download timeout, process terminated after 59 seconds 2020-01-23 22:38:53,950 [CameraTakePictureOnMessageRecieved] ERROR - Image download timeout, process terminated after 59 seconds For 5x liveview, this do not work for some older Nikon camera. Regards,