Query - Identification in packet format

[darksidelemm]

Hi! This is an awesome project, and I'm looking forward to seeing where it goes! It looks like an interesting move forwards from using SSDV on high-altitude balloons ( e.g. SSDV over Wenet: https://github.com/projecthorus/wenet ) and on HF ( https://github.com/darksidelemm/hfssdv ).

I'll probably be giving it a go over HF using freedvtnc ( https://github.com/xssfox/freedv-tnc ) at some point soonish (your support for KISS-TCP should make this super easy!). However using freedv-tnc there isn't much going on in the way of identification on the channel - we're not using AX.25 framing, just pushing packets through. The same is true when transmitting imagery via Wenet, it's just SSDV packets pushed over a FSK+LDPC link. We rely on the callsign field in SSDV to meet our identification requirements.

Looking at the PDP spec ( https://maqifrnswa.github.io/PCSI/spec.html ) I see the packets only contain an image ID. So - I'm wondering if a small callsign identifier could be included in the packet format, in a similar way to how SSDV does things? This would also allow easier automated reconstruction of imagery from multiple receivers for display on a webpage (e.g. http://ssdv.habhub.org/ ), which would not be possible with the current packet format, unless additional framing overhead was introduced.

Again, this is awesome work!

73 Mark VK5QI

[fsphil]

At a minimum it could be just a simple wrapper around the PDP packet when it's not being used with AX.25, so you're not adding unnecessary overhead. All it would really need is a format identifier, callsign, PDP data, and ideally a checksum.

This is a really fascinating project, I'm looking forward to seeing it in action.

[maqifrnswa]

That's an excellent point! SSDV just uses 4 bytes for the callsign (base40 encoding), so it's not that expensive - but it is a bit of overhead. I also like the idea of coming up with a simple framing protocol like @fsphil described around the PDP payloads. I'll play around with both options and check back here later. Right now the GUI program just sends AX.25 frames over KISS, but you can hack it to just skip all the ax.25 framing stuff.

[maqifrnswa]

This is an interesting theoretical question. Breaking it down:

• Every payload must contain all the relevant information to fully reconstruct an image. An image identifier is required information to reconstruct an image. Right now, the only image identification in the payload is an ID number, which is the bare minimum.
• Framing (theoretically) should be independent of the payload
• The current implementation uses info from the datagram framing to do additional image identification.

I think a solution can be as follows:

• Describe PDP as a "pseudorandom datagram payload" that contains the minimal information to reconstruct a single image
• The PDP is wrapped in a frame that contains the "session" information. An imaging session is identified by the sender callsign since a single sender can transmit multiple images simultaneously.

The spec can describe PDP (for a single image), but allow for any other way of transmitting session information as appropriate. For example:

• AX.25 frames (just drop the PDP in the payload)
• APRS compatible frames (we should avoid using VHF APRS frequencies, but you can use APRS hardware/software on other frequencies if you prepend "{{V" to the PDP and place it in the payload)
• new framing inspired by SSDV as @fsphil described: [one or more octets of 0x7e] + [ 0x56 for packet type, ascii "V") ] + [4-byte base-40 encoded callsign] +[PDP, 256 bytes max so it's the same as AX.25 payload] + [CRC-CCITT] + [one or more octets of 0x7e]. This way you can still use KISS TNC hardware to do the CRC and flags for you.

Those protocols can be implemented in the reference software. What do you think?