Of course, it should use gr-satellites and gnuradio. I meant to automate the entire process from .wav to .jpeg with gr
I can provide needed information
1 Like
That should not be hard at all then, biggest issue is sorting the frames, picking the best ones, and distinguishing between different images.
I looked at the format published on the website (https://download.geoscan.aero/site-files/Amateur%20radio%20telemetry%20protocol.pdf), but there does not seem to be a mention of the counter or how it is formatted.You can see what I mean with the highlighted Lucky-7 counter in my previous post, every single packet has a simple binary counter that can be read out straight as an integer
1 Like
Yes, this should be possible with gr_satellites.
Here an example:
gr_satellites 53385 --rawint16 <PCM Wav file> --samp_rate 48000 --iq --use_agc --kiss_out <file.kss>
~/kng/geoscan-tools/process_frames.py -k <file.kss> -o <file>
2 Likes
Also, just for confirmation the âstructure of AX.25 telemetryâ is not related to jpeg transmission, right? That has its own format
one obs to image would only work if it catches every frame, even loosing a few in the beginning messes the picture up pretty bad. Iâm aggregatning a few obs from the same transmission and demodulating them all and using all the data for one image.
Yes. Image transmitted in its own format
I got the script working, one command from wav IQ to jpeg, only relying on gr_satellites and some basic python libraries. Not a very elegant solution but seems to work, I will publish it once I get more data to test it with, hoping for image and X-band transmission this weekend 
2 Likes
If youâre trying to remove the KISS framing: donât just remove the C0 00 ⊠C0 part! You need to deframe this correctly, otherwise there will be errors in the image.
Is there a way to contact you so I can ask a few questions about the jpeg format without cluttering the forum?
1 Like
[regarding the integration of image transmissions into SatNOGS]
[SatNOGS architecture recap, section can be skipped]
SatNOGS is built around the following steps:
- On the station, the satnogs-client demodulates data live upon reception, stores this data in one or multiple âframesâ (files), (optionally) using the awesome custom gr-satellites integration.
IQ â frames - From station to network, the client uploads those âframesâ to SatNOGS network, for a specific âObservationâ
- In the SatNOGS Network the uploaded frames get stored in association to their Observation and internally forwarded to SatNOGS DB
- Finally, in SatNOGS DB, all frames from multiple SatNOGS Observations and the SiDS upload become available as a single resource (via the SatNOGS DB API)
- e.g. Show telemetry visualization via SatNOGS Dashboards
frames â NicePlotsâą
[hi!]
A script designed to take advantage of having access to receptions by multiple station through SatNOGS should use the SatNOGS DB API as input.
frames â Images
To be resilient it should be able to handle duplicated frames (e.g. by de-duplicating them) due to reception by more than one station, and to handle frames from multiple images due to re
Note that while the frames get a timestamp upon reception, de-duplication based on them is very unreliable if not impossible for most of the frames currently (the same frame received by two stations might get a timestamp many many seconds apart). Better station software might improve the timestamps, but I would recommend for protocols which are targeted towards amateur networks to find a method of frame de-duplication which does not rely solely on timestamps.
[regarding 
]
For historical reasons the decoding of weather satellites happens on the station, and final images get uploaded to Observations. Decoded Weather Satellite Imagery was one of the first data results in the beginning of SatNOGS. It was built this way but any new Image Decoder Script should take advantage of the network effect by using the SatNOGS DB API, as does @SA2KNGâs db_search.py in their geoscan-tools.
1 Like
New schedule
7/12/2022 09:30:30 (two transmissions)
7/12/2022 15:45:00 (two transmissions)
should be a photo of New Zealand
3 Likes
1 Like
Here is what I got:
Iâm not sure what caused the error, it looks like I received every packet. But looking at the raw binary data Iâm seeing a few packets with strange repeating data (I havenât seen that yet with jpeg). Maybe camera buffer issue?
3 Likes
Awesome picture.
Hmm⊠Iâll try to figure out this issue. Can you try to delete this repeating data by hand?
Removing by hand only results in missing block at the end of the image. Maybe it is not related to the color issue and I did just miss a couple packets without noticing. It could not be an issue but seeing as it doesnât look like jpeg data at all maybe it is worth investigating, just in case maybe the camera or whatever encodes/modulates the jpeg got stuck at a repeating buffer. This is what it looks like in the resulting jpeg file framed as 128 bits;
Appeared in both transmissions (first and repeated). Here is the raw binary file: SwissTransfer.com - Envoi sécurisé et gratuit de gros fichiers
2 Likes
Looks like this is inside an image. I need time to figure out whether these bites appeared on shooting image or on writing. Thank you!
2 Likes
To explore how the data from this JPEG image gets decoded there is this nice article âUnraveling the JPEGâ.
All interactive examples in this article will use the corrupted image from above when provided with the URL to this image, so this link will load the article with the corrupted image of the earth. Screenshot of one of the examples:
Maybe with a bit of knowledge of the JPEG protocol (gained through the article 
) one might be able to manually fix the image using the interactive examples. I just gave it a quick try bit didnât succeed.
Credit:
The article is written by Omar Shehata and open source.
1 Like
Would it be possible to test the X-band carrier again tomorrow? During the orbit of UTC 9:02-9:08 or 10:35-10:41?
We want to test our X-band carrier again, but we still have some thing to figure out. It will be possible later this week.
1 Like