[aprssig] Packet Compressed Sensing Imaging (PCSI)

[Scott Howard]

Hi Andrew,

On Mon, Jun 29, 2020 at 11:55 PM spam8mybrain <spam8mybrain at yahoo.com> wrote:
>
> Interesting concept. What is the packet transmit rate with your protocol? Can it coexist with other users on the channel by waiting between packets, or will it saturate the channel until the picture is sent?

You can set the packet rate to whatever you'd like in the software
(packet order and loss doesn't matter, so super-slow is fine). If you
have a dedicated channel, you can just spam away (like SSTV or SSDV
does). If you're sharing a channel (like APRS), you obviously must be
more considerate. The software is using your TNC's CSMA, so it should
sense channel usage and not hog bandwidth. I was thinking of doing
some kind of algorithm to adjust the persistence of the CSMA based on
the number of simultaneous users in the future. Imagine there are a
bunch of stations on a non-APRS frequency all sending their own images
to each other simultaneously (an "image net"). The software already is
set up to acquire all those images simultaneously, and you can switch
back and forth between them as they come in. Each client knows how
many other stations are present on the image net at the same time and
can adjust persistence for optimal transmission rate and channel
sharing. That's something impossible with SSTV, and something cool to
do. You also can imagine having an event where you want images
simultaneously from multiple locations, each with poor signals and low
power. You can create your own image net and see all of them at the
same time, regardless of fading or interference. If such an "image
net" is timely, tactical, and appropriate to do over APRS, you can
limit it to a specific digipeater so packets don't leak out of the
local area. (That's why "digipeaters" is blank by default in the
software. You should be smart and not just spam WIDE unless there's a
specific reason to). I live in a rural area, so APRS traffic is very
light (typically at <5% channel capacity). We've been testing PCSI by
just bouncing off of a single specific APRS digipeater without
affecting the network. That digipeater is also an igate, so we can
check up on it on aprs.fi even if no one else is listening at that
moment.

When using PCSI with APRS, you can set your TNC's persistence to be
very low. This should give "priority" to other traffic. You also can
reduce image size. You may not need to send a 320x240 (SSTV
resolution) image over APRS. You can even send messages similar to
Hellschreiber. A 16x160 "image" that just contains text can be sent in
10 packets or so. Now that I think of it, if you send 1 bit color
(B&W), you might actually be able to send the 16x160 "image" in a
single APRS packet... I haven't thought of that yet, but that could be
cool. We'd have to modify our packet specification a little bit to
allow for black and white (or even grayscale) images.

> Assuming the Father of APRS doesn't choke because of bandwidth consumption, I would be interested in building a parallel client for your protocol to try sending and receiving pictures.

My "fear" of using PCSI with APRS is the irresponsible usage of
bandwidth. There are good and bad use cases. Maybe a good use case is
to extend the "Automatic Picture Relay Network"
(http://www.aprs.org/aprn.html) to include PCSI "image nets." This way
you just send the info to APRS that an image net is happening on a
frequency, then people can switch over to that frequency to
participate. Unlike SSTV as originally used in APRN, PCSI uses AX.25
frames just like APRS, so the exact same software (e.g., YAAC) can be
used to participate in image nets as they do to manage APRS. You can
also think about a national image net service similar to the UK's SSDV
image aggregator (https://ssdv.habhub.org/) where everyone just
uploads the packets they receive to some server that reconstructs
them. In that case, individual clients don't even need to know how to
decode the packets, they just relay them. This way balloons or other
systems can send high quality images rapidly regardless of location
and without necessarily needing digipeating or APRS.

I'd be happy to help if anyone is interested in developing a different
client. The tricky part is the math behind compressed sensing if you
haven't seen it before, so we can help out with that. Maybe we can
just make a C library that takes whatever has been received and spits
out an image so anyone can incorporate it into software. Our next
steps is to get the python CLI fully working so people can
send/receive using a headless Raspberry Pi, and then it is to make an
Arduino transmission client so people can put them on real low-power
devices (e.g., hamshields on balloons).

Cheers,
Scott (KD9PDP)