{"id":2156,"date":"2017-06-22T15:47:08","date_gmt":"2017-06-22T15:47:08","guid":{"rendered":"http:\/\/www.daveakerman.com\/?p=2156"},"modified":"2017-06-22T15:47:08","modified_gmt":"2017-06-22T15:47:08","slug":"pi-in-the-sky-photography","status":"publish","type":"post","link":"http:\/\/www.daveakerman.com\/?p=2156","title":{"rendered":"Pi In The Sky Photography"},"content":{"rendered":"

I’ve had a few emails asking how to get camera images off of the PITS SD card, and have seen flights appear on the live image page with poorly configured image settings, so I’m going to cover both of these subjects in this article.<\/p>\n

Image Configuration<\/h1>\n

The image-taking is quite flexible, and the software comes pre-configured with options that are suitable for the majority of flights, but still you may wish to adjust the settings yourself.<\/p>\n

Image Taking<\/h2>\n

The camera is controlled by a script (~\/pits\/tracker\/camera) which runs a basic loop to take photos for the radio transmitter and also for permanent storage. \u00a0The script looks for an runs separate small scripts for the RTTY channel (the standard transmitter on the PITS board), for LoRa (if you have the LoRa add-on board) and for permanent storage but not transmission. \u00a0These small scripts are created by the main tracker program (~\/pits\/tracker\/tracker) according to settings in the configuration file (\/boot\/pisky.txt). \u00a0There is some basic information in the manual and online<\/a>\u00a0but I will \u00a0go into more depth here.<\/p>\n

The camera software uses a simple scheduler to take a photograph of a certain resolution every\u00a0n<\/em> seconds. \u00a0The resolution can be set separately for low or high altitudes – there’s no point in transmitting large images before the balloon is launched!<\/p>\n

There are several such schedules running independently, so you can separately control the rate of image taking for RTTY, LoRa etc. \u00a0This is useful because for example LoRa typically transmits data more quickly than RTTY does, so you might want there to be more frequent LoRa images than RTTY.<\/p>\n

Transmission<\/h2>\n

The next thing to remember is that although it’s possible to take a photograph every few seconds, it takes a\u00a0lot<\/strong> longer to transmit them. \u00a0The transmission time depends on various factors but the main one under your control is of course the image size in pixels; do not make the mistake of one team who used images so large that it didn’t have time to fully transmit even one image!<\/p>\n

Since it is possible to take images much more quickly than transmit them, the software is able to choose what it considers to be the “best” of recent images for transmission. \u00a0Suppose that it takes 5 minutes to transmit an image, and one us taken every 30 seconds; that gives the software 10 images to choose from. \u00a0The “algorithm” (if I can call it that) is to simply select the largest JPG file out of those images, and this works surprisingly well in selecting good images and not selecting poor ones (e.g. those pointing at the black sky above).<\/p>\n

Having selected a image to transmit, that image and all the ones it rejected are moved to a dated folder, so they aren’t later considered for transmission. \u00a0This means that (using the above example) the next image will be chosen from the next 10 photographs. \u00a0So, at any point, the transmitted image will only be a few minutes old.<\/p>\n

Since images are sent using the same radio transmitter(s) as telemetry, only one or the other can be sent at any one time on a particular transmitter. \u00a0So, the software interlaces image data and telemetry, which means that it will send a certain number of image packets, then a telemetry packet, and then repeat the cycle. \u00a0The ratio can be fairly high when the balloon is high – we don’t \u00a0need frequent telemetry updates at that time – but is forced to be 1:1 at lower altitudes (so we get frequent position updates as the balloon comes in to land).<\/p>\n

Configuration<\/h2>\n

High and Low<\/h3>\n

As I mentioned, the software can use different image sizes for low altitude and high altitude, with the changeover controlled by this line in the configuration file:<\/p>\n

high=2000<\/pre>\n
So, above 2000m the software uses settings for “high” images, and below that it uses those for “low” images. \u00a0The same changeover altitude is used for all image channels (RTTY, LoRa and “FULL” for SD card only) and each channel has separate settings for high and low image sizes.<\/p>\n
RTTY Images<\/h3>\n
You can set the image size for low or high images, plus how often images are taken, plus the ratio of image packets to telemetry packets (when above the “high” setting above):<\/p>\n
low_width=320\r\nlow_height=240\r\nhigh_width=640\r\nhigh_height=480\r\n\r\nimage_packets=4\r\n\r\nimage_period=60<\/pre>\n
When the tracker program starts and reads this file, it displays the following in response, explaining what the options do:<\/p>\n
RTTY Low image size 320 x 240 pixels\r\nRTTY High image size 640 x 480 pixels\r\nRTTY: 1 Telemetry packet every 4 image packets\r\nRTTY: 60 seconds between photographs<\/pre>\n
For typical 300 baud RTTY (the default speed for RTTY in PITS), this provides an image every few minutes, which is fine. \u00a0Images will be transmitted more often at high altitude because the black sky compresses very well, which helps. \u00a0I do not recommend using larger image sizes for RTTY. \u00a0Also,\u00a0do not<\/strong> transmit images at all if you are using 50 baud (set image_period=0 to disable images for RTTY).<\/p>\n
Full Size Images for SD Card Only<\/h3>\n
Since these images are not transmitted, they might as well be set to the full camera resolution when above the “high” setting:<\/p>\n
full_low_width=640\r\nfull_low_width=480\r\nfull_high_width=2592\r\nfull_low_width=1944\r\nfull_image_period=60<\/pre>\n
Which results in the following output:<\/p>\n
Full Low image size 640 x 480 pixels\r\nFull High image size 2592 x 1944 pixels\r\nFull size: 60 seconds between photographs<\/pre>\n
LoRa Images<\/h3>\n
For LoRa, remember to specify the LoRa channel (0 or 1, for CE0 or CE1, according to which position(s) are occupied on your LoRa board). \u00a0Settings are very similar to those for RTTY:<\/p>\n
LORA_low_width_0=320\r\nLORA_low_height_0=240\r\nLORA_high_width_0=640\r\nLORA_high_height_0=480\r\nLORA_image_packets_0=4\r\nLORA_image_period_0=60<\/pre>\n
LoRa transmissions should be set to mode 1 (see the LoRa section in the manual) as this is the best option for imaging. \u00a0The resulting speed is about 4 times that for 300 baud RTTY, so you will get more frequent updates, or you could increase the image sizes.<\/p>\n
LORA0 Low image size 320 x 240 pixels\r\nLORA0 High image size 640 x 480 pixels\r\nLORA0: 1 Telemetry packet every 4 image packets\r\nLORA0: 60 seconds between photographs<\/pre>\n
Other Settings<\/h3>\n
If you don’t want images at all, either simply remove the camera, or disable the software from using it with:<\/p>\n
camera=N<\/pre>\n
Assuming use of a Pi camera, the software uses the raspistill program to take photographs. \u00a0You can add parameters that are passed to raspistill, which is handy if for example the camera is upside-down (happens…). \u00a0To do this, first check the online raspistill documentation, and then add your parameters using “camera_settings” e.g.:<\/p>\n
camera_settings=-vf -hf<\/pre>\n
which does vertical and horizontal flips to rotate the image by 180 degrees.<\/p>\n
 <\/p>\n
Images From SD Card<\/h1>\n
So, you’ve flown your flight, recovered the payload, and want to get those images from the SD card onto another computer. \u00a0There are many methods:<\/p>\n