Camera crashes - page 4 - Hotwire! Hardware Mods, Accessories and Insights - CHDK Forum  

Camera crashes

  • 39 Replies
  • 14930 Views
Re: Camera crashes
« Reply #30 on: 04 / April / 2014, 09:39:49 »
Advertisements
Just a thought, but presumably these cranes run on three phase and have sliding power contacts running on taught wires or bus bars.
These frequently spark due to poor maintenance and dust build up. You get lots of spikes on the earth in the vicinity of this equipment (most likely including the Beam). Perhaps the beam needs a decent earth cable back to the supply to nail things down a bit.
Seen this sort of problem cause false trippings on rcd devices countless times. And literally had to get earth jumpers installed throughout a unit because of interference to IT equipment including freezing some years ago.
I know equipment these days is pretty immune, but we arent talking about new cameras here and i'm not sure the immunity standard of a camera would be that good anyway.

Also dont mount too close to any steelwork, take care of battery / cable position too, try to keep everything a couple of inches clear.
Prob non of the above but these are all things i have seen in the past

Re: Camera crashes
« Reply #31 on: 04 / April / 2014, 16:40:14 »
Can't really tell from the picture how the external supply is configured.  If that little wire I see exiting to the left of the camera in the photo is the 3.4V feed to the camera, then running that any length in the environment describe above is sure to cause issues.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: Camera crashes
« Reply #32 on: 05 / April / 2014, 07:56:00 »
I would use a 12 to 24v supply to the camera location, and the use a step down reggy to 3.15v close to the camera.
Always tightly twist your DC cables as this helps to limit noise.

reccomend a LM2596 dc-dc buck convertor as the reggy. I have used these to supply full dslr for a long time with no probs.

Running the 12 to 24v supply as AC to the camera location may also help reduce noise (just remember to rectify with full wave. ( the LM2596 are good for about 35v input).

Lastly watch your cable volt drop, i am assuming you may have a decent run here so you should be using a heavy gauge wire right up to the reggy,

suggest 24/0.2 wire to reggy then 7/0.2 to the camera max 300mm.

Re: Camera crashes
« Reply #33 on: 05 / April / 2014, 08:27:13 »
Forgot to add.
you should also use a "ferrite", just behind the power plug irrespective as to whether you are using an ac adapter or external batteries in a noisy environment.
There are generally two types one is a ring and requires you to loop your cable through it a couple of times, the other clips on in 2 halves.
Typical good quality usb leads always have the,
The white original cannon usb cables have them and the older ones can be unclipped from the cable with a knife tip if you want to get your hands on one for test purposes.


*

Offline JvdP

  • ***
  • 174
Re: Camera crashes
« Reply #34 on: 05 / April / 2014, 18:49:07 »
It's possible a CHDK bug could appear only under certain shooting conditions (lighting, focus, camera chosen exposure settings, chdk override/script exposure settings). Some pattern might emerge if you logged what the script is doing.
Mmmh, that sounds interesting. It sounds unlikely to me but since I have relatively little experience with CHDK I suppose it is possible the camera is crashing because of some pattern. The script logs the shots and some simple data but I'm not sure what you want to have logged in order to find out more?

The ROMLOGs you've posted are all in a task that CHDK doesn't hook, but memory corruption or other problems caused by CHDK code could trigger that. Looking at what specific checks in the Canon firmware trigger the asserts might provide some clues.
I have no idea what you mean, could you emphasise?

EMI might not be out of the question if there is a strong enough source nearby. Maybe it needs an AFDB?
Finally got use for my Tin Foil Hat! No but seriously, maybe I can try to make something that can shield the camera to test.

_______________


I just thought I'd share my thoughts on trying to trouble shoot this.

If you can run the camera with a "do nothing but shoot" script, as suggested above and sill see the issue, it is probably an environmental or hardware issue.

If the camera and "do nothing" script is then run in a different location, away from the potential trouble sources, and it still crashes, it may be a hardware problem.

If you have access to a 2nd camera that runs CHDK try that in the original location. This would help eliminate the hardware as the source. You can pick up an Ixus 40,50,60, 70 or similar which will run CHDK for a few bucks on ebay to test this theory.
I like your analytical exclusion method approach ;-) I'm pretty sure it's not script dependant since the exact same equipment works fine in other locations.

Buying a second camera has certainly come to mind. This was really my last resort solution though.

_______________


Just a thought, but presumably these cranes run on three phase and have sliding power contacts running on taught wires or bus bars.
These frequently spark due to poor maintenance and dust build up. You get lots of spikes on the earth in the vicinity of this equipment (most likely including the Beam). Perhaps the beam needs a decent earth cable back to the supply to nail things down a bit.
Seen this sort of problem cause false trippings on rcd devices countless times. And literally had to get earth jumpers installed throughout a unit because of interference to IT equipment including freezing some years ago.
I know equipment these days is pretty immune, but we arent talking about new cameras here and i'm not sure the immunity standard of a camera would be that good anyway.

Also dont mount too close to any steelwork, take care of battery / cable position too, try to keep everything a couple of inches clear.
Prob non of the above but these are all things i have seen in the past
Yes, they run on three phase but no, there are (as far as I can see) no sliding power contacts but rather cables that follow the trolley (taut wires?). I therefore am not sure how electricity enters the steel construction, but with so many high power devices around I don't exclude it.

I placed another camera on another side, but also close to one of the beams and it started to show the same problem! There is definitely something "spooky" about that area...

_______________


Can't really tell from the picture how the external supply is configured.  If that little wire I see exiting to the left of the camera in the photo is the 3.4V feed to the camera, then running that any length in the environment describe above is sure to cause issues.
The external supply is simply a ACK-DC90 clone from eBay. I have 4 of them and all of them work "flawlessly" unless I mount them in that "spooky" location.

Moreover, I have tested a LiPo battery which has previously worked perfectly but the camera crashed within 30 minutes. This LiPo battery has a very short cable length to the camera.

_______________


I would use a 12 to 24v supply to the camera location, and the use a step down reggy to 3.15v close to the camera.
Always tightly twist your DC cables as this helps to limit noise.

reccomend a LM2596 dc-dc buck convertor as the reggy. I have used these to supply full dslr for a long time with no probs.

Running the 12 to 24v supply as AC to the camera location may also help reduce noise (just remember to rectify with full wave. ( the LM2596 are good for about 35v input).

Lastly watch your cable volt drop, i am assuming you may have a decent run here so you should be using a heavy gauge wire right up to the reggy,

suggest 24/0.2 wire to reggy then 7/0.2 to the camera max 300mm.
I actually have some LM2596's lying around. However, I think the power supplies I have are fine, there's nothing wrong with them.

Forgot to add.
you should also use a "ferrite", just behind the power plug irrespective as to whether you are using an ac adapter or external batteries in a noisy environment.
There are generally two types one is a ring and requires you to loop your cable through it a couple of times, the other clips on in 2 halves.
Typical good quality usb leads always have the,
The white original cannon usb cables have them and the older ones can be unclipped from the cable with a knife tip if you want to get your hands on one for test purposes.
That's a good idea! Will try that. It doesn't protect against any interference that radiates straight to the camera. Perhaps I should build a shield around the camera? Tin foil should do...
« Last Edit: 05 / April / 2014, 19:01:47 by JvdP »

*

Offline ahull

  • *****
  • 634
Re: Camera crashes
« Reply #35 on: 05 / April / 2014, 20:21:42 »
Does the crane driver use a "walkie talkie"? Many years back I came across a similar weird problem with a very expensive computer system that would crash for no reason more so in the evenings and a lunch time. The cause was a VHF transmitter operated by a taxi firm nearby, presumably it was busier at lunchtimes and in the evening, and thus more likely to interfere with our customer's equipment. In light of this experience, shielding sounds like a good idea.

I also heard a story about an "electric wall". Some one was sent to investigate a poor picture from a CCV camera on a bracket at the top of a wall in a local factory. As they scaled the wall on an aluminium  ladder, they discovered if you touched the wall on the way up to the camera you would get a shock, the shock got more severe the higher up you went. One brave soul went up with his mult-meter and a pair of heavy duty rigger gloves, measuring the voltage between the wall and the ladder as he went.

As he neared the camera, the meter was registering pretty close to 240V AC. Poor earthing and a transformer fault meant that mains voltage was being delivered to the wall which acted as a giant potentiometer from the camera to earth.

... just be careful out there, something might bite you.  ;)

*

Offline reyalp

  • ******
  • 14080
Re: Camera crashes
« Reply #36 on: 06 / April / 2014, 21:16:45 »
It's possible a CHDK bug could appear only under certain shooting conditions (lighting, focus, camera chosen exposure settings, chdk override/script exposure settings). Some pattern might emerge if you logged what the script is doing.
Mmmh, that sounds interesting. It sounds unlikely to me but since I have relatively little experience with CHDK I suppose it is possible the camera is crashing because of some pattern. The script logs the shots and some simple data but I'm not sure what you want to have logged in order to find out more?
The idea here is: CHDK corrupts some piece of memory. That piece of memory is only relevant to some particular code path in the canon firmware, for example (totally made up, not your specific situation) it happens to be a variable that is only used when the ND filter is in, so you only crash when there is enough light to require the ND filter.

Quote
The ROMLOGs you've posted are all in a task that CHDK doesn't hook, but memory corruption or other problems caused by CHDK code could trigger that. Looking at what specific checks in the Canon firmware trigger the asserts might provide some clues.
I have no idea what you mean, could you emphasise?
The Assert blah blah in the ROMLOG points to a particular part of the Canon firmware. The assert is a check for some condition that the Canon firmware developers think should never happen. Looking at the disassembly of the ROM code where the asserts happen may shed light on what is happening. For example, it could be something really simple, like checking for an out of memory error.

I looked at your romlogs a bit.
All but the last one are all the same assert: SsCreateJpeg.c Line 1519

This is around FF0A5808 in ixus240 101a (I think your romlog may be from 102a, but it doesn't really matter in this case) Unfortunately, it's not really obvious what it's checking.

The other one is at: SsCreateJpeg.c Line 917 which around FF0A64E8 and also not really obvious.

I noticed that the ones you've posted are around the same time of day:
Occured Time  2014:03:04 13:45:21
Occured Time  2014:03:07 13:42:31
Occured Time  2014:03:10 14:29:01
Occured Time  2014:03:12 13:11:51
Occured Time  2014:03:12 14:05:43

Depending on how long you are running for, this might be totally insignificant, but if you are running for a full day it seems a bit suspicious.  Does someone usually fire up an arc welder between 13:00 and 14:30 ? :haha

 
Don't forget what the H stands for.

*

Offline ahull

  • *****
  • 634
Re: Camera crashes
« Reply #37 on: 07 / April / 2014, 16:11:13 »
Alternatively does the camera *start* (power on, or reboot) at the same time every day, and thus once it has taken a certain number of images, or been running for a certain number of hours/minutes, crash, at almost the same time every day?
« Last Edit: 07 / April / 2014, 16:12:45 by ahull »


Re: Camera crashes
« Reply #38 on: 17 / May / 2014, 06:59:34 »
You may some relevance to your crashing problem in the general help and assistance using chdk stable releases :- A800 stops as if power unplugged when running ultimate intervalometer.

 

Re: Camera crashes
« Reply #39 on: 17 / May / 2014, 07:15:17 »
You may some relevance to your crashing problem in the general help and assistance using chdk stable releases :- A800 stops as if power unplugged when running ultimate intervalometer.
link > A800 Stops as if power unplugged with Ultimate Intervalometer
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics