Camera Init, error when establishing camera event notification

[tohox]

Hi,

I often get an exception at line 413 of OlympusAir.py when creating a new instance of the OlympusAir class like so:

cam = OlympusAir()

At first I got this only while debugging if the previous script didn't close the connection properly. I assumed that port 65000 was left open for some reason preventing the next connection and power cycling the camera usually fixed this but now I seem to be getting the error systematically even after power cycling.

The first request.get(http://... /get_connectmode.cgi' seems to go through fine but the second one to /start_pushevent.cgi' fails with the following error message:
requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",))

Any ideas?

Thanks for your great port of the Olympus SDK!

P.S. If you are interested I was able to get the Bluetooh LE wakeup command working under Python.

[hblasins]

Hello,

I have to say that I have not come across the error you are describing. I do see a variety of communications issues between the camera and Raspberry Pi (I'm using this platform to control the camera), especially if all the sessions were not closed correctly. I can always create the camera object though. What OS are you using? Maybe the command to reuse sockets

self.eventSocket.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)

doesn't work on your os? Have you tried starting the camera with different sockets than the default pair (65000 and 65001)? Maybe there is a different application on your system that uses those sockets? (I should be doing a much better job at checking the availability of different sockets. Something on my To Do list).

You may want to use

cam = Camera()

rather than OlympusAir(). Shouldn't make any difference, but the OlumpusAir.py is a file I forgot to remove after a code cleanup.

Also, I'd be very interested in the Bluetooth code to wake the camera up. Perhaps you could create a pull request?

[tohox]

Henryk,

I am also developing on a RaspberryPi (model 3). I tried substituting the OlympusAir import for the Camera one and got the same error as before at the same request.get(http://...

I tried changing the TCP ports and strangely I still got the same error at the second request.get. So it feels like it might in fact be the camera which is the problem. I'm using the latest firmware version available according to the upgrade utility.

I've used self.eventSocket.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1) before on the RaspberryPi for other projects and it worked ok so I don't think this is the problem here.

The only fix when this happens appears to be to powercycle the camera and even then it will eventually lock up again after an undetermined number of connections. The script I'm developing takes one picture every 30 seconds for up to 16 hours per day. It is triggered by a cron job so there is a connection for every picture and the lockup can happen anytime after only a few pictures up to the 600th which is the most I was able to take without a connection problem.

I haven't gone through all your code but would it be possible to forego the event socket altogether or is it absolutely necessary for all the methods? I'm currently only using commInterface, startPreview, switchMode, setProperty, takePicture, waitOnCardWrite (I guess this one must require an event socket), getLatestFile, stopPreview, removeFileProtection, removeAllFiles and finally disconnect. If I can't forego the event socket then I'll try taking all the pictures from within the same script instance connecting only once at the beginning and get rid of the cron job.

My Bluetooth wake up code is really just a dirty hack at this point. I don't even know what exactly is being transmitted as I couldn't find any information in the OPC SDK. I sniffed the Bluetooth traffic between the Olympus Android app and the camera during the power up phase and managed to imitate the same sequence using gatttool. At first I tried using pygatt but wasn't able to imitate all the exchanges happening between the Android app and the camera so I reverted to doing os.system calls directly to gatttool. I start by enumerating the connected network interfaces and if wlan0 is not connected I send the gatttool sequence as shown bellow. You then have to monitor the wlan0 connection before proceeding to connect to the camera. Please note you'll have to replace the Bluetooth MAC address with your own:

if len(connected_ifaces) == 0 or 'wlan0' not in connected_ifaces:
    print 'No WiFi connexion available.'
    print 'Attempting to wake up camera...'
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --primary')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-desc')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0013 -n 0001')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0016 -n 0001')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0019 -n 0001')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0012 -n 0101090c01023132333435364400')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0015 -n 0202000000')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0012 -n 0102040f0101021300')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0015 -n 02030000000')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0012 -n 010304140101011700')
    os.system('gatttool -b 90:B6:86:XX:YY:ZZ --char-write-req --handle 0x0015 -n 02040000000')
    print('Bluetooth LE wakeup sent.')

It would also be possible to automate getting the camera's MAC address using hcitool lescan and parsing its output but I haven't done this yet.

[hblasins]

Hi,
apologies for my delayed response. I was away on holidays.

It seems that we want to use the code for a very similar application. I am also using the Raspberry Pi to control the Air to capture time-lapse images. You may be right that the error is on the camera side. I've seen the Air behave in bizarre ways, though not to the extent you describe. Could you let me know which firmware version you're using?

As far as the sockets go I don't think you need to open a socket for event signalling. This is something I used mostly to make sure that the camera was correctly responding to the commands I was sending. However, as far as I remember you certainly need to enable live preview (and perhaps open a socket in the process) before you can take a picture, even if you won't be using the preview at all.

[tohox]

Hi,

I mostly fixed my problem by letting the script run all day and opening the connection only once when the script starts instead of having a cron job run a new instance of the script every 30 seconds opening a new connection each time.

The camera still displays some strange behaviour occasionally but my script now works most of the time. I had to add mutiple try except statements in order to catch all the camera's weird moments, then close the connection gracefully and try again.

By the way, I believe I am currently using the latest firmware available for this camera which is 1.2

On the other hand the Bluetooth wakeup routine although promissing was abandonned as it wasn't very dependable. We ended up modifying our cameras running some wires in parallel with the power button and triggerring them through an SSR from the Rapsberry Pi's GPIO which is much more reliable.

I'm now faced with a different problem however. This morning the Raspberry Pi's SD card was found to be corrupt and I didn't have a backup image of it so I reinstalled from scratch and although I feel like everything is back as it was I am now getting the following error every time I try to create a new instance of the camera class:

("bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)",)

Again it is at the requests.get line that the problem occurs. At first I thought it might be the requests library which was outdated so I updated it but to no avail.

Any ideas?

Thanks,

UPDATE: So it turns out that eth0 was connected to a network using the same subnet as the camera and my script was in fact trying to talk with a virtual machine somewhere using the same IP address... Face-palm!

[hblasins]

I was just about to say that I am also using cron to run my scripts every 20 minutes or so, and have not experienced any of the problems you describe.

When you sorted out the subnet issue did it solve the 'bad handshake' error or the socket error?

How hard was it to hardwire the button to Pi's GPIO? Any change you could share a photo?

[tohox]

Henryk,

Yes, changing the subnet on the eth0 interface fixed my 'bad handshake' problem. The problem was compounded by the fact that the network device the script was finding at 192.168.0.10 did "by chance" have a running http server so it was first responding with a 301 (permanently moved) after which the requests.get seems to automatically try the same request again but this time through a secure httpS connection. Hence the SSL3 error I was getting.

The whole system will be run remotely through a wireless link which we are currently testing. The camera has been taking pictures 16 hours/day every 30 seconds for the last three days without a single hickup so far. I did have to increase eventTimeout in your Camera class from 2 to 5 as my script was occasionnaly raising exceptions otherwise.

The hardwiring to the GPIO was very easy. You can use a TLP222G with a 1K resistor on pin 1 connected to any IO pin of your choice, pin 2 of the photorelay goes to GND and pins 3 and 4 simply go in parallel with the switch.

The camera disassembly was a little more involved as you have to remove pretty much everything from the rear of the camera all the way to the sensor block in order to reach the switch assembly... Modifying the first camera took us a little under 2 hours as we were very cautious not to break/loose/forget anything. I'm sure modifying the second one won't take as long though.

We might use the first camera to make a timelapse of the modification of the second one. If we do, I'll make sure to send you the link!