fsphil / ssdv Goto Github PK

Hello,
I am utilizing this ssdv library for a project with an Arduino Arducam 5mp mini. I am using a wide fisheye lens which captures part of the lens housing as a result - for my application, I would like to make the packet transmission as efficient as possible and think I could optimize by cropping the image down or otherwise eliminating packets which mostly contain these regions.

Is there any way at any point in the encoding process to identify which region of the image a given packet "represents" (even if not exact)? The image is already in JPEG format and there is not enough memory on the Arduino for a JPEG->Raw->JPEG processing where I crop the image in the intermediate.

Thank you

I mean it will be really great if we can pip live stream of data directly into the ssdv decoder. E.g. if say I am sending SSDV sans-FEC on AFSK1200 wrapped with ax 25. Then ly decode chani could be
rtl_fm | multimon-ng -a AFSK1200 | SSDV - d output.jpeg.
Even better if some terminal based image viewer like FEH could be integrated in the chain somehow although that is far fetched.
We are taking inspiration some of your master piece code that resides in Hadie repo, for generating ssdv frames in our upcoming satellite. Would be great if some simple chain as above could be achievable.

Hi, first of all, let me say that this is really cool project, I love the idea of sending digital images through RTTY.

That being said, while attempting to add support for SSDV in RadioLib, I ran into some issues. I compiled SSDV on a Ubuntu VM, and started playing around with encoding different files. To verify my implementation of the encoding chain in RadioLib, I encoded the same file (a very small jpeg, only 32x32 pixels) using the compiled ssdv from this repository in both FEC and no-FEC mode, and to my surprise, both generated only two packets. I would expect the image with FEC to be longer than that, since every packet contains 32 bytes of FEC. Is this the correct behavior?

The no-FEC data generated by my implementation were the same as what the ssdv binary outputs, so I tried to transmit that and decode in fldigi to verify at least that. However, even though fldigi decodes the RTTY and prints it to the terminal, the SSDV RX window does nothing, never even printing the callsign. I can see what should be the callsign bytes in the terminal (at leat the prinatble bits), so I think fldigi is decoding correctly, but I don't know if I'm just using it wrong. Is there a way a debug the transfer in fldigi?

I'm not sure if this repo is still maintained, just thought I'd ask. Thanks!

use a getopt version in windows
use a unistd.h in windows
compile on vs2015
test.zip

Hi,
Why is there two (type == SSDV_TYPE_INVALID) in ssdv_dec_is_packet(uint8_t *packet, int *errors)?

Is the (type == SSDV_TYPE_INVALID) in Line 1455 correct?