Geoscan-Edelveis mission

This is not the case. IARU declined your coordination because there is a pecuniary interest.

Past coordinations are not a guide for future ones. Besides you have to look into the specifics and what those missions did (or not) for the amateur radio satellite service.

IARU has been clear that we could consider amateur frequency coordination if a university with a responsible radio amateur would submit a coordination request.
GEOSCAN 9600bd

1 Like

Ok so I managed to extract a jpeg from example files using my own python script, now moving on to tackling these!

I can confirm these aren’t JPEG files as they fail to decode on my own decoder as well.

Can you share your python script ?

Sure! Let me make a github for it. It’s very basic though.

1 Like

I agree… this does have several JPEG tags on here but it does not decode. I converted and ran many of the downloaded binary files through a massive database of hex file identifiers… while the image dumps could easily be identified as “JPEG Bitmap”, the mystery files yielded “Unknown data”… I wonder whether or not this is a format that the @geoscan team came up with… perhaps @K4KDR or @EA4GPZ have ideas? I’m stumped here! (FYI I used trid for the analysis.)

You’ve certainly got parts of (several) image files in those captures, but it appears that too many packets are missing to allow a valid image file to be assembled. That’s a huge down-side of the JPG file format.

Yes, I was thinking the same thing… way too many FFD8s present

I now made a python tool available

I’m not great with python, so please be kind :slight_smile:

1 Like

Thanks for sharing the python script.
Here some more data dumps.

1 Like

Great development!

I tried to decode this observation and after a replay it gave me the following GetKissPlus output: log file

When I try to decode the file, I get the following error:

Raw GEOSCAN mode?y
Input file:t.txt
Output file:t.jpg
Characters to remove (16 raw soundmodem, 47 for GetKISS+):47

Traceback (most recent call last):
  File "/source/git/radio-satellites/geoscan-tools/", line 44, in <module>
  File "/usr/lib/python3/dist-packages/PIL/", line 2284, in save
  File "/usr/lib/python3/dist-packages/PIL/", line 599, in _ensure_mutable
  File "/usr/lib/python3/dist-packages/PIL/", line 592, in _copy
  File "/usr/lib/python3/dist-packages/PIL/", line 276, in load
  File "/usr/lib/python3/dist-packages/PIL/", line 71, in raise_oserror
    raise OSError(message + " when reading image file")
OSError: broken data stream when reading image file

I run this command on Debian Linux and the python version is 3.10.7

Any idea what could be wrong?

1 Like

@pierros Thank you for answer!

Yes. IARU said that because we are company we by default have pecuniary interest. Which is certainly not a case. But we understand that and we sadly can’t do nothing with that. Rules are rules:)

Our supporting university with a responsible radio amateur submitted a coordination request. If you can, could you please, look into that:)

Thank you for using the script! :smile:

There are a few things wrong here that I didn’t document well enough.

First of all, I didn’t mention this in the readme, but raw geoscan mode should be turned off, since that is to be used with SoundModem log files :slight_smile:

Second, it appears that your version of PIL is either outdated or PIL doesn’t work on 3.10… I’m using 3.7 fine. Try running

pip install Pillow --upgrade

If that doesn’t work, try adding

from PIL import Image, ImageFile

to the beginning of the file (modify the PIL import at the beginning though).

I ran it through my system successfully, however since the signal fades rapidly my the end of the pass, the JPEG is corrupt and doesn’t contain FFD9 tags for example (JPEG end tags). I will implement functionality to write corrupt JPEG files later this afternoon. This does not require PIL.

Nice SNR on your station by the way!

Approximately in a month. We are still testing our systems.
The bandwidth of the x band signal is around 1 MHz. We will provide precise info prior to testing

1 Like

Great! I got used to x and l-band signals that I receive being 4MHz+ :grin:

Unfortunately, it seems like you don’t have enough information to recover a JPEG, even with writing images as raw… does it decode with Scott’s script? Perhaps a non-fixed yagi or a higher gain one would work better?

EDIT: I can confirm the write raw data feature works well, due to it writing images well on a different file with more packets.

Thanks, we have a start



Hurray! Great job! Thank you!
Maybe we can’t see much here but it a wonderful result!

So Scott’s script worked for you? Great that you got it to work!! :slight_smile: :slight_smile: