3

I've recently become extremely interested in tiny "picoballoons" which can float around the world multiple times in some cases.

I was extremely surprised to find DL7AD's picoballoon, which has a camera and can transmit images with SSDV over APRS. Check it out here

I'm interested in different possible methods of transmitting these images. SSDV seems to work well as an encoding method, but the APRS VHF network is limited to 1200 baud AX.25. Even with low quality images it takes a few minutes to transmit a single image.

I've thought about the possibility of using 9600 baud raw AX.25 with SSDV on either 2m or 70cm. Would it be feasible to transmit a raw image file instead of using SSDV? I'm aware SSDV provides built in error correction.

My main question is if there are other, possibly faster, alternatives to APRS SSDV that have been used.

Vera Fodor
  • 41
  • 1
  • two aspects: SSDV is a pretty "stupid" format. It uses an ancient still image codec (namely, JPEG) to send images independently. Instead, it could use a modern moving picture coded (a video codec), eliminating most of the transmitted data volume by not transmitting things that were there in the previous frame but might have moved, darkened, … in the view of the camera (which, for a drifting high-altitude balloon should be most of the picture). Check out the data rates that would be sufficient for the same (or better) quality of picture sequences with x265, for example. – Marcus Müller Oct 09 '22 at 18:20
  • So, a first step in modernizing this approach is to not go with SSDV, but with a modern video codec, like h265, or at least one of the long-established MPEG4 HEVC versions – Marcus Müller Oct 09 '22 at 18:22
  • second: AX.25 is really the worst case packet format for wireless communications. Seriously, if you're not bound to use a system that already uses it, avoid it at all cost. It's never been meant for wireless comms (it comes from the wired frame relay data world), and it ignores comms theory from 1942 onwards. Seriously. If your system does not start by using AX.25, it's better off. Then, you could move the error correction from the data/representation layer (i.e., the video) into the link/physical layer, where it actually belongs. – Marcus Müller Oct 09 '22 at 18:24
  • is if there are other, possibly faster, alternatives to APRS SSDV that have been used. yeah, sure. Many a 60€ quadcopter does better video than SSDV at the same bit rate. But it doesn't do that under ham licensing, but as unlicensed 2.4 GHz transmitter. So, here's your demo. – Marcus Müller Oct 09 '22 at 18:28
  • So now that we know that there's better, cheap, readily available wireless systems that can transmit a few images a second to a few images per minute, the question is, what are the interoperability and individual link requirements that you want to fulfill? – Marcus Müller Oct 09 '22 at 18:29
  • Because the APRS network won't "do" raw AX.25 (even if it is built atop of AX.25), I don't think you're aiming for APRS compatibility. Right? So, what are you aiming for? What are the frame rates, resolutions, reaches, power budgets that you are aiming for? It's exceedingly hard to "press" out implementable specifications from non-engineers, but try to put hard minimum or maximum numbers to 1. min frame rate, 2. min picture resolution, 3. min transmission distance, 4. max power consumption. – Marcus Müller Oct 09 '22 at 18:31
  • (yes, you need to write down numbers when coming up with a system design. Avoid the fragment "as good as possible": that's always implied, you need to specify the absolute requirement that the system needs to do.) – Marcus Müller Oct 09 '22 at 18:34
  • @MarcusMüller Thank you for the response! I'm looking for still images to be taken maybe once an hour and transmitted either when they are taken or stored and transmitted later when over a specific point or over a specific location. The transmitter would be tens of thousands of feet up, and would likely use a 100mw-1watt vhf or uhf si brand transmitter chip. As low power draw as possible, so it would likely be based around an stm microcontroller. 1920x1080 or higher photos would be great. What other data transmission modes are available? What image encoding methods? – Vera Fodor Oct 09 '22 at 19:17
  • @MarcusMüller Likely wouldn't be through the APRS network for video. Ground stations for receiving – Vera Fodor Oct 09 '22 at 19:19
  • Awesome! Sadly, it's midnight here, I'll write something up tomorrow evening! Also, would be good to know about your power source :) – Marcus Müller Oct 09 '22 at 22:13
  • @MarcusMüller Depending on power requirements of a system like that, it could be anywhere from some tiny solar cells and supercapacitors, to a tiny lipo with solar charging circuitry. – Vera Fodor Oct 09 '22 at 23:48
  • I hate to burst your balloon, but I can't imagine such an effort being "pico". The earth-circling versions are truly pico, powered only by solar cells, and are only able to transmit tens-of milliwatts during daylight (no battery). Your effort adds a receiver and battery...no doubt the power budget will require considerably larger solar area. The pico version is a fairly minor aircraft safety hazard - yours is not minor. – glen_geek Oct 12 '22 at 20:16
  • @glen_geek check out this! https://github.com/DL7AD/pecanpico9 It’s definitely possible, but my question is if there are better protocols to transmit images. Like mentioned above SSDV really isn’t great. That project was also multiple years ago and the only one I’ve seen of it’s kind, so it would be cool to see what could be done with that technology today! – Vera Fodor Oct 14 '22 at 16:13
  • @MarcusMüller you really don't want to use a video codec with inter prediction over a lossy link from a balloon that drifts in and out of range of receivers; it means that most of what gets received will never be decoded to anything useful. AVIF and HEIC are basically intra-only versions of modern video codecs, and they offer a modest improvement over JPEG. – hobbs - KC2G Jun 04 '23 at 15:39
  • @hobbs-KC2G hm, I happen to know what they used for lossy, and slightly shaky, video downlinks during launches of rockets, and that doesn't agree with what you say! Of course you need channel coding, and massive interleaving, and in the case of large-scale fading as your balloon model, some ARQ model if possible, but you need that everywhere. And the "modest" improvements are typically a data rate rate reduction higher than a factor of 4 at the same perceptual quality in the lower-bitrate regime compared to JPEG… So, not fully on board with your statements. – Marcus Müller Jun 04 '23 at 16:11
  • @hobbs-KC2G what I 100% agree with is that "stream and forget" combined with anything that requires history is a terrible idea if you have no indication whether the link currently is likely to work. You'd often solve that by waiting for downlink opportunities as signaled by reception of e.g. beacons, or through repeating your message until your transmitter gets an ACK or OHGODSHUTTHEHELLUPPLEASE. – Marcus Müller Jun 04 '23 at 16:14

2 Answers2

1

SSDV is commonly transmitted over LoRa (250kHz, SF6, CR4:6, which is good for around 15kbit/s of payload bandwidth) or less commonly Wenet / Horus FSK, which requires more power but achieves a net bandwidth of around 90kbit/s.

Both of those modes have a wide occupied bandwidth compared to 1200 baud packet, and so in most places they're only allowed on the 70cm and higher bands.

hobbs - KC2G
  • 12,322
  • 16
  • 31
-1

Packet Compressed Sensing has been used. https://maqifrnswa.github.io/PCSI/

Pops73
  • 1