While writing my previous report, I had to keep track of when each of the images had been taken and when it was downloaded. This can be a bit tricky, since the images do not carry a timestamp. Here I describe the techniques that can bee used to identify and keep track of the images.
Keep in mind that the description of the DSLWP-B camera system that I give here is based on what I hear from Wei Mingchuan BG2BHC, so some points might be slightly incorrect or incomplete.
The camera on DSLWP-B has a buffer that can hold 16 images. This buffer works as a circular buffer, so when the camera takes an image, it overwrites the next position in the buffer. The positions in the buffer are identified with ids from 0 to 15.
One of the images in the buffer can be transferred to the UHF transmitter for its download. Usually, the B1 transmitter that operates at 436.4MHz is used to download images (DSLWP-B has another transmitter, called B0, which operates at 435.4MHz and usually transmits GMSK and JT4 telemetry). The id of the image (given by the position in the buffer, from 0 to 15) held by the transmitter is included in the cam_memory_id telemetry variable of the transmitter. When the image download starts, the image referred by cam_memory_id is downloaded.
The B1 transmitter is currently configured to take an image when it powers up. The image is taken, overwriting the next position in the circular buffer of the camera, and also transferred automatically to the B1 transmitter. However, the download has to be commanded manually. Instead of transmitting this image, a command can be sent to load another image from the buffer in the UHF transmitter.
The latest values of cam_memory_id for the B1 transmitter can be seen here. This allows us to keep track of which image is being transmitted currently.
Keeping track of when an image with a particular cam_memory_id was taken can be more tricky. If the UHF transmitter powers up and sends telemetry before another image is loaded by a manual command, the id of the new image can be seen in the telemetry. The problem is that sometimes an image is loaded manually before any telemetry is sent or that there are no receiving stations collecting the telemetry. In any case, each time the UHF transmitter powers up and takes an image, the id of the new image increments by one (eventually jumping from 15 back to 0), so this can help us keep track.
To check when the UHF transmitter has powered up, a very useful telemetry variable is runtime, which contains the time in seconds since the UHF transmitter has been powered. This variable can be plotted here. This allows us to calculate the time of power up when there are receiving listening to the telemetry. If no stations listen during the activation period, the image id can be deduced, but the time of boot up has to be taken from the schedules published by Wei.
Another data that can be useful is the SSDV image id. This cannot be seen in the online telemetry dashboard, but it is the first byte of the SSDV packets and it is also shown when the SSDV decoder is run (the output of the SSDV decoder running on the telemetry server can be seen here). I think that the SSDV id increments by one each time a new image is taking, and in contrast to the cam_memory_id, which only goes from 0 to 15, the SSDV goes from 0 to 255, so it doesn’t warp as often.
3 comments