All posts by Kevin Campbell

Canon F-1

This represents a turning point for Canon: their first professional grade camera, introduced in March of 1971 along with a new lens mount – the FD range.

The F-1 established it’s pro-credentials by offering a huge range of interchangeable parts – viewfinders, focusing screens, winders, backs – and a range of flash accessories. Also notable was the 1/2000s top shutter speed

A number of interesting technical solutions are seen with the F-1, including TTL metering achieved by locating the meter cell at the side of the focusing screen, where light was directed to it by a small mirror. This allowed metering to be independent of the finder attached, much simplifying things.

One of the most curious accessories was the Servo EE finder, a bulky finder made even bulkier by the battery pack it needed, holding 8 AA cells. This finder incorporated a servo motor – hence the name and the need for all the batteries – which mechanically connected to the shutter speed dial in order to change speed based on metered light and selected aperture.

Canon Pellix

This is a definite odd-ball, and example of creativity attempting to solve an engineering problem: how do you capture light coming through the lens for metering purposes?

The Canon answer was to use a pellicle mirror; one which allows about 2/3rds of the light to pass through, and diverts the remaining 1/3rd to a light sensor. The mirror is fixed, and remains down during exposure. The CDS meter cell is moved into the path of the light by pushing the self timer towards the lens barrel, which also causes the aperture to stop down.

In order to keep light from the viewfinder from influencing metering, there’s even a blind that covers the eyepiece – operated by a ring around the rewind knob.

There are disadvantages to this approach, primarily that there’s about a 1/3rd stop loss in light transmission. To compensate for this the Pellix was supplied with a 55mm f1.2 lens – the museum sample has the FL50mm f1.4.

Advantages are several however:

  • Less vibration due the absence of mirror slap
  • Quieter operation
  • No viewfinder black-out during exposure, making tracking shots easier
  • The rear element of lenses can protrude further into the body, permitting a compact design

Olympus OM10

In 1972 Olympus introduced their OM line, and reset consumer expectations for the size and heft of a 35mm camera body. The various OM1/2 variants were very successful and so, in 1979, the OM10 was introduced at a more amateur friendly price point.

During the time when I studied photography at school – 1979-1981 – the OM10 was heavily advertised in the various photo rags of the time. Construction was a little less robust than the pro oriented single digit models (OM1 etc), but price was commensurately lower and it still accepted most of the OM line of accessories.

In standard configuration the OM10 is aperture priority only, much like the Pentax ME/MV, but a rather dinky little manual adaptor was offered – and which is fitted to this example. The manual adaptor allows the user to select the shutter speed when the primary dial is set to manual by way of a rather clumsy slide switch. It’s a very simple affair comprising of nothing more than a calibrated knob and a mini headphone jack. I strongly suspect it’s nothing more than a well calibrated variable resistance.

There are a couple of aspects of the OM line that are noteworthy, including the presence of depth of field preview built into the lens rather than the body. There’s a little tab on most OM lenses which sops down the aperture mechanism. While on the subject of OM lenses, it’s noteworthy that the aperture ring is at the front of the lens rather than at the rear – where almost every other maker put it. Personally I’m not a fan of this approach.

While smaller than the prevailing 35mm bodies when the OM line was launched in 1972, but the late ’70s Pentax had shown us what was possible with the ME line. The OM10 is bigger and feels crude by comparison – dials seem plasticky and finicky to operate compared to the ME derivatives.

The museum example seems to be in pretty decent working order – the battery is still operational, the shutter speed lights up in the viewfinder and the electronic self timer works. It even has the iconic Japanese Camera Inspection Institute quality control sticker intact 🙂

Pentax KM

Essentially an Spotmatic F, the KM is what many feel the K1000 should have been. Introduced alongside the KX in 1975 as it’s less expensive sibling, the KM still offered a self timer and depth of field preview – both features that were thought to be omissions from the K1000. Interestingly, the depth of field preview lacks the lock-out feature found on the KX.

The meter is a little less sensitive than that in the KX, and the film speed range a little smaller. There’s no aperture window in the viewfinder, but there is the ability to record either the number of exposure or the type of film using a small wheel under the rewind knob.

As with the KX the KM was offered in both chrome and black, though I’ve never seen either in anything but chrome. They weren’t made for more than 2 years, and so there are relatively few still around. This one was pretty dirty when received, but has cleaned up somewhat.

Pentax KX

1975 saw the introduction of the KX as the advanced-amateur model in the Pentax K series lineup, seen as one step up from the KM. As with all the K line, the body is essentially a bayonet mount development of the Spotmatic line, and physically very similar.

Metering is of the match needle variety, and the display shows both selected shutter speed and the speed required to achieve “correct” exposure. The pentaprism window looks out onto the aperture ring, so the selected value is also visible through the viewfinder.

As the advanced member of the lineup, the KX also offers mirror lockup, a self timer, depth of field preview (with a lock-out feature) and a switch for the light meter. It’s otherwise similar to the K1000 – the VW Beetle of film cameras – in that it’s pretty heavy, solid, and decidedly mechanical in use.

Pentax MV1

Surprisingly, given it’s decidedly amateur auto-only positioning, this MV1 was “rode hard and put away wet”. It’s one of the most used models in the museum, and was filthy when received. I’ve included it as an interesting reminder that even supposedly beginner friendly cameras can earn their keep through hard work.

Introduced in 1980, the MV1 is a little less basic than the MV it succeeded – it has a self timer for example, a memo holder, it can accept a data back and – as with this example – a winder. It’s still aperture priority only, with an electronic, focal plane metal shutter. It’s very clearly a member of the ME family, with the same almost implausibly compact body and featherlight controls.

It’s still very much a beginner friendly camera, and the shutter speed isn’t displayed in the finder. Interestingly there is exposure compensation, though it’s a little hidden beneath the rewind lever and requires good fingernails to operate.

Pentax MX

Introduced in 1977, and produced until 1985, the MX represented the flagship of Pentax’s 35mm line. Unlike the ME and derivatives, it features a mechanically timed, cloth shutter. It’s smaller and lighter than the KX, which it succeeded, but other than the overall body form factor it shared little with the ME range. Only light metering required a battery, for example, and there were no automatic metering modes offered.

As the “professional” model in their line, the MX offered interchangeable focusing screens, a choice of data backs, a bulk film back, and both a winder and a motor drive. There’s a small window built into the finder pentaprism which peeks out at the aperture ring, and lets the shooter see it through the finder. It’s a solidly built, well crafted piece of jewelry.

Yashicaflex A-II

I believe this to be an A-II model, first introduced in 1954.

The Twin Lens Reflex (TLR) had gained popularity between the wars due in large part to the German Rolleicord models, much loved by press photographers. They were relatively light and simple, compared to cumbersome plate cameras that had preceded them.

This TLR represents the first cameras to be made under the Yashica brand name, it having been established a few years after the end of WWII as part of Japan’s industrial recovery. After a few years of clock component manufacture, the nascent Yashica company turned it’s efforts to camera production.

In common with most TLR’s, this model has a “sports finder” mode, whereby the front part of the viewfinder folds down and the user can attempt to compose by peering through what amounts to rifle sights. There’s also a flip up magnifier to try and help with focusing. The composing lens is pretty dim, and the magnifier does help somewhat.

Pentax MG

Pentax introduced the MG in 1981, as the successor to the MV1 and in the line of simpler, automated, bodies going back through MV and ME of 1977.

The MG is aperture priority automatic, with no manual shutter speed other than the flash sync of 1/100th second. The metal focal plane shutter is electronically controlled – by and large photographers had overcome their initial hesitation about trusting electronics, and the increased accuracy and reliability of such a shutter was now well accepted.

Shutter speed is shown in the viewfinder, but the selected aperture is not. There’s a simple clockwork self-timer, and the hot shoe features an additional electrical contact for use with a dedicated Pentax flash unit.

Film loading is of the magic needle variety, and works well. The museum example is unique to me in that the protective film is still in place on the baseplate, and it was bought fitted with a genuine Pentax zoom – typically I find ebay cameras with some no-name zoom on them

Digital Photo Frame – DIY

If you’ve ever fancied a digital display frame, but perhaps wanted more than just a simple carousel of your pictures, or greater control over how the device behaves, then read on.

What we’ll build

A digital display board that showcases your photographs, with an overlaid calendar and weather forecast. For those of you into home automation, I’ll also cover how to turn the display on and off by integrating with Samsung SmartThings home hub – the basic approach could serve as a starting point for other integrations.

How we’ll do it

A Raspberry Pi zero w (about $26 with case and power supply) combined with a Dell 24″ monitor (about $120), and the Dakboard web digital display service.

Dakboard

The simplest way to get started is to follow this handy guide. This will help you get your Pi up and running, though I found that for the release of Raspbian current as of December 2019, I need to follow the alternative instructions for updating the autostart instructions :

/etc/xdg/lxsession/LXDE-pi/autostart

Automating the Pi display

We’re going to create a RESTful web service (API) that can be invoked with a simple URL to turn the display on and off, this is what our home automation will call. This will leverage Python3, Flask, and NGINX.

NGINX

This is a popular web server for the Pi, you could use apache but the tutorials I was following used nginx.

sudo apt-get install nginx

Python3

If your Raspbian install is fresh (you used noobs to get up and running) you probably don’t need to sudo apt-get update, but it might not include Python3, so let’s install that.

Log into your Pi (I use SSH from my Macbook)

sudo apt-get install python3-pip

UWSGI flask

This will install the flask API framework, which greatly simplifies the work required to create RESTful apis in python.

sudo pip3 install flask uwsgi
sudo pip3 install flask-restful

Python api program

You can clone from https://github.com/klcampbell6502/pirest.git or use the code as displayed there.

from flask import Flask
from flask_restful import Resource, Api
import os
 
app = Flask(__name__)
 
api = Api(app)

class ScreenOff(Resource):
    def get(self):
        os.system("vcgencmd display_power 0")
        return "off"
 
class ScreenOn(Resource):
    def get(self):
        os.system("vcgencmd display_power 1")
        return "on"

api.add_resource(ScreenOff,'/screen/off')
api.add_resource(ScreenOn,'/screen/on')

if __name__ == '__main__':
    app.run(host='0.0.0.0')

Testing

We should now be able to test the flask API using the debug environment:

uwsgi --socket 0.0.0.0:8000 --protocol=http -w api:app

and then invoke the URL:

http://yourpiaddress:8000/screen/off

You should see the single word “off” in your browser, and if you look in your ssh output you should see something like this:

*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 7822, cores: 1)
display_power=0
[pid: 7822|app: 0|req: 1/1] 192.168.86.24 () {32 vars in 644 bytes} [Wed Jan  1 12:16:54 2020] GET /screen/off => generated 6 bytes in 273 msecs (HTTP/1.1 200) 2 headers in 70 bytes (1 switches on core 0)
[pid: 7822|app: 0|req: 2/2] 192.168.86.24 () {32 vars in 574 bytes} [Wed Jan  1 12:16:55 2020] GET /favicon.ico => generated 233 bytes in 330 msecs (HTTP/1.1 404) 2 headers in 72 bytes (1 switches on core 0)

Oh, and your HDMI display is now off 🙂 Type ctrl-C in your ssh session to stop the uWSGI test server. To make things more robust we’re now going to integrate uWSGI with the nginx web server.

nginx integration

If you didn’t download the project from git then you’ll need to create a file uwsgi.ini in the directory containing your .py file:

[uwsgi]
chdir = /home/pi/Documents/pirest
module = api:app
master = true
processes = 1
threads = 2

uid = www-data
gid = www-data

socket = /tmp/pirest.sock
chmod-socket = 664
vacuum = true
die-on-term = true
touch-reload = /home/pi/Documents/pirest/api.py

This will provide the startup instructions for uwsgi when invoked from nginx.
Now we’ll get rid of the default nginx site

sudo rm /etc/nginx/sites-enabled/default

and now create a proxy file

sudo nano /etc/nginx/sites-available/pirest_proxy

containing the following:

server {
listen 80;
server_name localhost;
location / { try_files $uri @app; }
location @app {
include uwsgi_params;
uwsgi_pass unix:/tmp/pirest.sock;
}
}

Now we need to create a symbolic link to this file

sudo ln -s /etc/nginx/sites-available/pirest_proxy /etc/nginx/sites-enabled

then restart nginx

sudo systemctl restart nginx

Set uWSGI to run on boot

cd /etc/systemd/system
sudo nano uwsgi.service

and into this new file, paste the following:

[Unit]
Description=uWSGI Service
After=network.target

[Service]
User=pi
Group=www-data
WorkingDirectory=/home/pi/Documents/pirest
ExecStart=/usr/local/bin/uwsgi --ini /home/pi/Documents/pirest/uwsgi.ini
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$

[Install]
WantedBy=multi-user.target

restart the daemon so the new configuration is picked up:

sudo systemctl daemon-reload

and start the service we’ve just defined:

sudo systemctl start uwsgi.service

You can check the status of the running service like this:

sudo systemctl status uwsgi.service

you should see something like this:

? uwsgi.service - uWSGI Service
   Loaded: loaded (/etc/systemd/system/uwsgi.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-01-01 12:49:52 CST; 1min 3s ago

 Main PID: 8038 (uwsgi)
   Memory: 13.1M
   CGroup: /system.slice/uwsgi.service
           ??8038 /usr/local/bin/uwsgi --ini /home/pi/Documents/pirest/uwsgi.ini
           ??8044 /usr/local/bin/uwsgi --ini /home/pi/Documents/pirest/uwsgi.ini
Jan 01 12:49:55 piboard02 uwsgi[8038]: mapped 143936 bytes (140 KB) for 2 cores
Jan 01 12:49:55 piboard02 uwsgi[8038]: *** Operational MODE: threaded ***
Jan 01 12:50:07 piboard02 uwsgi[8038]: WSGI app 0 (mountpoint='') ready in 12 seconds on interpreter 0x16984f0 pid: 8038 (de
Jan 01 12:50:07 piboard02 uwsgi[8038]: *** uWSGI is running in multiple interpreter mode ***
Jan 01 12:50:07 piboard02 uwsgi[8038]: spawned uWSGI master process (pid: 8038)
Jan 01 12:50:07 piboard02 uwsgi[8038]: spawned uWSGI worker 1 (pid: 8044, cores: 2)
Jan 01 12:50:07 piboard02 uwsgi[8038]: display_power=0
Jan 01 12:50:07 piboard02 uwsgi[8038]: [pid: 8044|app: 0|req: 1/1] 192.168.86.24 () {42 vars in 767 bytes} [Wed Jan  1 12:50
Jan 01 12:50:15 piboard02 uwsgi[8038]: display_power=1
Jan 01 12:50:15 piboard02 uwsgi[8038]: [pid: 8044|app: 0|req: 2/2] 192.168.86.24 () {40 vars in 734 bytes} [Wed Jan  1 12:50
lines 1-19/19 (END)

You’ll see here that I tried the service on and off by entering this URL in my browser:

http://piboard02/screen/on

The final step is to ensure that this starts with every boot:

sudo systemctl enable uwsgi.service

and you’ll see something along these lines:

“Created symlink /etc/systemd/system/multi-user.target.wants/uwsgi.service /etc/systemd/system/uwsgi.service”

Reboot and test using the URL – give it time to boot, especially if using a pi zero as they’re pretty slow.

SmartThings Integration

Device Handler

OK, so you’ve got a pi running a display board, and you can turn the HDMI output on and off by opening a URL. Now to create a device handler for SmartThings that enables you to include this in automations, and of course control it from your SmartThings app.

Go grab the source over at my github repo. For now, I’m going to assume the reader knows how to create an account at the Samsung developer site https://graph.api.smartthings.com/

Go to My Device Handlers, and Create – From Code, then paste the code from Git. Or, you could just import my repo into your account. You’ll then need to publish it, choosing “just me” should be sufficient.

New Device

Using the IDE, create a new device:

 

Complete the new device screen – use your own values for Network ID (which must be unique), name, label, etc. I’ve used IP address for network ID, but what you use actually doesn’t matter.

When you get to the Type pulldown, scroll all the way down past the commercial handlers until you see the REST Switch device handler we just created. Location and Hub must be set to your SmartThings hub, you’ll typically only see a single choice in those pulldowns.

Click on the Edit link alongside Settings in the device display, and then enter the IP address and port 80 for your Pi. Your hub must be on the same network as your pi, as the hub itself will run the device handler code we just established.

After a couple of minutes the newly created device should appear in your app: