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.
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.
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. The 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. These small scripts are created by the main tracker program (~/pits/tracker/tracker) according to settings in the configuration file (/boot/pisky.txt). There is some basic information in the manual and online but I will go into more depth here.
The camera software uses a simple scheduler to take a photograph of a certain resolution every n seconds. The resolution can be set separately for low or high altitudes – there’s no point in transmitting large images before the balloon is launched!
There are several such schedules running independently, so you can separately control the rate of image taking for RTTY, LoRa etc. This 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.
The next thing to remember is that although it’s possible to take a photograph every few seconds, it takes a lot longer to transmit them. The 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!
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. Suppose 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. The “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).
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. This means that (using the above example) the next image will be chosen from the next 10 photographs. So, at any point, the transmitted image will only be a few minutes old.
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. So, 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. The ratio can be fairly high when the balloon is high – we don’t need 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).
High and Low
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:
So, above 2000m the software uses settings for “high” images, and below that it uses those for “low” images. The 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.
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):
When the tracker program starts and reads this file, it displays the following in response, explaining what the options do:
RTTY Low image size 320 x 240 pixels
RTTY High image size 640 x 480 pixels
RTTY: 1 Telemetry packet every 4 image packets
RTTY: 60 seconds between photographs
For typical 300 baud RTTY (the default speed for RTTY in PITS), this provides an image every few minutes, which is fine. Images will be transmitted more often at high altitude because the black sky compresses very well, which helps. I do not recommend using larger image sizes for RTTY. Also, do not transmit images at all if you are using 50 baud (set image_period=0 to disable images for RTTY).
Full Size Images for SD Card Only
Since these images are not transmitted, they might as well be set to the full camera resolution when above the “high” setting:
Which results in the following output:
Full Low image size 640 x 480 pixels
Full High image size 2592 x 1944 pixels
Full size: 60 seconds between photographs
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). Settings are very similar to those for RTTY:
LoRa transmissions should be set to mode 1 (see the LoRa section in the manual) as this is the best option for imaging. The 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.
LORA0 Low image size 320 x 240 pixels
LORA0 High image size 640 x 480 pixels
LORA0: 1 Telemetry packet every 4 image packets
LORA0: 60 seconds between photographs
If you don’t want images at all, either simply remove the camera, or disable the software from using it with:
Assuming use of a Pi camera, the software uses the raspistill program to take photographs. You can add parameters that are passed to raspistill, which is handy if for example the camera is upside-down (happens…). To do this, first check the online raspistill documentation, and then add your parameters using “camera_settings” e.g.:
which does vertical and horizontal flips to rotate the image by 180 degrees.
Images From SD Card
So, you’ve flown your flight, recovered the payload, and want to get those images from the SD card onto another computer. There are many methods:
- If you have a PC or Pi running Linux, you can pop the SD card into a card reader, and access the files directly
- With a Windows PC, and a card reader, you can use SysInternals Linux Reader to access the files.
- If you connect the Pi to a network, you can use WinSCP to access files from a Windows PC on the same network.
- Or, also with the Pi on a network, you can install SAMBA on the Pi to share it’s files.
Here we will cover the WinSCP option.
First, install WinSCP from the official page. Start the program and you will see this initial screen; enter the IP address of the Pi (which it displays on the monitor at the end of the boot process) and the Pi user name (“pi”). Click Save to save the settings.
Then click Login and the program will connect to the Pi, requesting a password (even you entered one above!):
and then, again if this is the first time you’ve connected to the Pi, it will ask for confirmation:
Once connected, you will see a file manager window with the directory structure on the left, and any files on the right:
Now, select the images directory (home/pi/pits/tracker/images) and you will see the following directories:
- FULL – for the full-sized images
- LORA0 – for LoRa CE0 images
- LORA1 – for LoRa CE1 images
- RTTY – for RTTY images
Choose whichever you like, and you will then see dated directories within:
Open up whichever matches the date of your flight, and you will (hopefully!) see lots of image files:
You can drag individual files, multiple files or even entire directories to your hard drive or any other storage.