RamSat mission progress

[K4KDR]

Thanks a million for the great Python decoder & sample TXT file of raw decodes, Ian!

Of course everyone please remember that the RamSat Team’s recommendations are the best and preferred way to extract these images from the RamSat download packets.

But for anyone not as familiar with Python, I wanted to share my approach to parsing RamSat image packets to produce the resulting JPG file.

I’m sure my script will give a good laugh to those more experienced, so please be kind. I just wanted to share it for anyone who might want a slightly different view of how the received packets can be assembled & converted to the end-result JPG file.

The .SH script file (attached) contains comments that explain how to use it and what the various parts of the command line actually do.

NOTE! Depending on how you capture your RamSat decodes, the ‘cut’ count MUST be modified to fit your situation. For example, my direwolf decodes needed 47 characters cut off the front of each line, where the RamSat Team’s sample file needed 9 characters cut from each line. Edit this .SH file to suit your situation!!

I hope this is useful or interesting to someone. Thanks again for the sample .TXT file so that I could verify that my script actually worked!

-Scott, K4KDR

** (after saving the attached ‘ramsat-image-decode.sh-txt’ file, please rename & remove the ‘.txt’ and make executable on your system)

ramsat-image-decode.sh.txt (1.8 KB)

[pethornton]

Great success today with our second image! We got all but three packets, and thanks to @K4KDR we were able to fill those in from a single overpass. This image was taken seconds after the first (above), using a different camera, and the combination of rotation of RamSat and slight difference in mounting of the cameras means in this second image we can see more of the deep field, including the curvature of the Earth. This camera is also equipped with a lens that lacks the normal IR-cut filter, so land area between the clouds is standing out much brighter, since this is an area with dense crops and forest which are quite reflective in near IR wavelengths. The view is to the NW, looking at the southern end of Lake Superior (one of the Great Lakes) as the large dark region toward the upper right part of the image.

[DL4PD]

Scott,
could you please provide what dire wolf outputs? I would like to have a look at it and compare with the data that Ian provided.

[DL4PD]

Looks like we could display a bit more on our dashboards if you could provide some details on the T### packets. There’s also the possibility to display command responses in a “Log” panel.

Is that something you could provide, Peter?

[K4KDR]

Glad to help!

First, please let me say that two things are required to produce an image. #1, you need a capture that starts at the exact beginning of a file & ends at the exact end of a file. #2, you need to have ALL of the packets (in the correct order) with none missing.

Of course, neither of these things will happen ‘live’ in a single capture ( by one station alone ) unless you are extremely lucky!

So, before using my script (or any tool) to convert the decoded packets to a JPG image file, it’s essential to find the beginning bytes ( FFD8FFE0 ) & end bytes ( FFD9 ) of the file, then use the index numbers ( RS: 0, RS: 1, etc. ) within each packet to verify whether or not you’re missing any.

I did this by hand, but of course someone with programming skills could automate the process.

So, to finally answer your question, here is a portion of my direwolf decode that happens to contain the first packet of a RamSat JPG image file:

[2021-08-20 18:29:47] CQ audio level = 36(+30/-29)   [NONE]   _:||||||_
[2021-08-20 18:29:47] [0.4] CQ>W4SKH:RS:    0 FFD8FFE000104A46494600010101000000000000FFDB0043000C08090B09080C0B0A0B0E0D0C0E121E1412111112251A1C161E2C262E2D2B262A293036453B30334134292A3C523D41474A4D4E4D2F3A555B544B5A454C4D4AFFDB0043010D0E0E121012231414234A322A324A4A4A4A4A4A4A4A4A4A4A4A
[2021-08-20 18:29:47] ------
[2021-08-20 18:29:47] U frame UI: p/f=0, No layer 3 protocol implemented., length = 265
[2021-08-20 18:29:47]  dest    W4SKH   0 c/r=0 res=3 last=0
[2021-08-20 18:29:47]  source  CQ      0 c/r=1 res=3 last=1
[2021-08-20 18:29:47]   000:  ae 68 a6 96 90 40 60 86 a2 40 40 40 40 e1 03 f0  .h...@`..@@@@...
[2021-08-20 18:29:47]   010:  52 53 3a 20 20 20 20 30 20 46 46 44 38 46 46 45  RS:    0 FFD8FFE
[2021-08-20 18:29:47]   020:  30 30 30 31 30 34 41 34 36 34 39 34 36 30 30 30  000104A464946000
[2021-08-20 18:29:47]   030:  31 30 31 30 31 30 30 30 30 30 30 30 30 30 30 30  1010100000000000
[2021-08-20 18:29:47]   040:  30 46 46 44 42 30 30 34 33 30 30 30 43 30 38 30  0FFDB0043000C080
[2021-08-20 18:29:47]   050:  39 30 42 30 39 30 38 30 43 30 42 30 41 30 42 30  90B09080C0B0A0B0
[2021-08-20 18:29:47]   060:  45 30 44 30 43 30 45 31 32 31 45 31 34 31 32 31  E0D0C0E121E14121
[2021-08-20 18:29:47]   070:  31 31 31 31 32 32 35 31 41 31 43 31 36 31 45 32  11112251A1C161E2
[2021-08-20 18:29:47]   080:  43 32 36 32 45 32 44 32 42 32 36 32 41 32 39 33  C262E2D2B262A293
[2021-08-20 18:29:47]   090:  30 33 36 34 35 33 42 33 30 33 33 34 31 33 34 32  036453B303341342
[2021-08-20 18:29:47]   0a0:  39 32 41 33 43 35 32 33 44 34 31 34 37 34 41 34  92A3C523D41474A4
[2021-08-20 18:29:47]   0b0:  44 34 45 34 44 32 46 33 41 35 35 35 42 35 34 34  D4E4D2F3A555B544
[2021-08-20 18:29:47]   0c0:  42 35 41 34 35 34 43 34 44 34 41 46 46 44 42 30  B5A454C4D4AFFDB0
[2021-08-20 18:29:47]   0d0:  30 34 33 30 31 30 44 30 45 30 45 31 32 31 30 31  043010D0E0E12101
[2021-08-20 18:29:47]   0e0:  32 32 33 31 34 31 34 32 33 34 41 33 32 32 41 33  2231414234A322A3
[2021-08-20 18:29:47]   0f0:  32 34 41 34 41 34 41 34 41 34 41 34 41 34 41 34  24A4A4A4A4A4A4A4
[2021-08-20 18:29:47]   100:  41 34 41 34 41 34 41 34 41                       A4A4A4A4A
[2021-08-20 18:29:47] ------

… and the other packets decode as they arrive.

Then, either by hand or with programming skills, we use our friends “grep” & “cut” to produce the useful part of each packet - still including each packet’s index number:

RS:    0 FFD8FFE000104A46494600010101000000000000FFDB0043000C08090B09080C0B0A0B0E0D0C0E121E1412111112251A1C161E2C262E2D2B262A293036453B30334134292A3C523D41474A4D4E4D2F3A555B544B5A454C4D4AFFDB0043010D0E0E121012231414234A322A324A4A4A4A4A4A4A4A4A4A4A4A
RS:    1 4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4A4AFFC4001F0000010501010101010100000000000000000102030405060708090A0BFFC400B5100002010303020403050504040000017D01020300041105122131410613516107227114328191A1082342B1C1
RS:    2 1552D1F02433627282090A161718191A25262728292A3435363738393A434445464748494A535455565758595A636465666768696A737475767778797A838485868788898A92939495969798999AA2A3A4A5A6A7A8A9AAB2B3B4B5B6B7B8B9BAC2C3C4C5C6C7C8C9CAD2D3D4D5D6D7D8D9DAE1E2E3E4E5E6
RS:    4 35363738393A434445464748494A535455565758595A636465666768696A737475767778797A82838485868788898A92939495969798999AA2A3A4A5A6A7A8A9AAB2B3B4B5B6B7B8B9BAC2C3C4C5C6C7C8C9CAD2D3D4D5D6D7D8D9DAE2E3E4E5E6E7E8E9EAF2F3F4F5F6F7F8F9FAFFC000110804B0064003

… and now it’s easy to see, for example, that packet #3 is missing. That will have to be obtained from another station’s download.

But once we DO have all the packets, using the method of your choice, we cut off the first 9 characters of each line, remove the ‘line-feed’ from the end of each line, & concatenate all the lines together into a single ASCII file. The result is converted to HEX and given a name that ends in .JPG.

And that’s it - we have gone from raw download packets to a complete image on the screen.

Patrick, I realize that YOU did not need all this explanation. It is my hope that my comments here might be useful or interesting to someone not as familiar with the magic of how to get from 500+ ASCII packets to a properly formatted JPG image file.

Best regards,

-Scott, K4KDR

[DL4PD]

I see, you’ve extracted everything from the console output! Great achievement!

Thanks for your explanations!

[pethornton]

Yes, I can provide both an explanation of the T### packets, and also a complete list of possible command responses. I’ll put that together as a word document and upload in this thread. Briefly, The T0## packets hold stored telemetry data for “Level 0”, which for now is simply our battery voltage stored every minute. T1## packets are our stored “Level 1” telemetry data, which after the T1## part are formatted exactly as a regular one-minute live telemetry beacon. These are currently being stored every two minutes, and we’re trying to keep up with downlinking them from storage on good overpasses at the RamSat ground station. The T2## packets are our “Level 2” stored telemetry, which are stored every two minutes, and contain details from the attitude determination and control algorithms. As you have seen, every command we send generates some kind of diagnostic response, followed in some cases by relevant data. It would be great to have a log that tabulates the number of times different command responses are recorded, or something like that. Will provide all the details soon.

[DL4PD]

Alright, I’ll implement something and we can see.

What’s interesting is this observation SatNOGS Network - Observation 4610266, where it looks like the satellite responses unexpected. There are a lot of RSBeac: and T2xx frames in less than a second. Is that something to worry about?

[pethornton]

That behavior is expected. The RSBeac: packets should be spaced about once per minute, but sometimes two will appear close together after a long command response. The T2XX frames are coming in response to a command to retrieve stored telemetry, and they come about 2 to 4 per second. We request them by sector as stored on our serial flash memory, and each sector contains 256 records. So once a “retrieve sector” command arrives, RamSat starts sending records from that sector as fast as it can.

[pethornton]

It has been almost a month since our last update, and for much of that time RamSat’s orbit has not been conducive to imaging work from our classroom ground station. In the meantime we are collecting stored telemetry and preparing for next imaging steps. Last night we completed downlinking an image captured on 23 August. As seen below, the camera was facing the sun and all we got was a lot of flare. The orbit is improving now for daytime passes. Last night we started running an autonomous image capture routine, exercising this in orbit for the first time. We provide a geographic bounding box and a few other constraints, then RamSat continuously checks its location, tests if the scene is sunlit, and if the cameras are facing the Earth. If so, images are captured on each camera, and then a 90-minute rest period is imposed so we don’t shoot many pictures of the same scene. We can query on future overpasses to see if images have been captured and begin new downloads. Image size continues to be our best metric of quality, and we are hoping for some big images, indicating lots of spatial detail. SatNOGS dashboard telemetry and our own stored telemetry downlinks show the whole system remains healthy.

[pethornton]

The RamSat team captured more imagery during a favorable overpass on 23 September 2021 at approximately 21:49 UTC. Skies across our region were clear, and we got lucky with good downward pointing attitude. The pictures below show the visible and visible+NIR camera views captured just a few seconds apart. Some image correction has been done to remove effects of atmospheric haze and some artifacts of the optics. Full-resolution images are copied individually below that. Also included is a google earth view, showing the approximate location of the visible image, with some labeling for reference. The developed area at the top of the image is Atlanta, Georgia. We are still working on getting imagery over Gatlinburg, TN, which is the main target for our mission, but the latest imagery is our best effort so far at capturing a vegetated area with clear skies and a good viewing geometry. Enjoy! And thanks, as always, to the SatNOGS community for the ongoing help in capturing and visualizing our telemetry data.

[N9CQQ-EN52]

Thanks so much for sharing this. I’ve been running my downlink station for just over a year now. I’ve often wondered if the data i’ve been gathering is ever getting to those that can use it. I was thrilled to see that it is!

Thanks again,
Bill N9CQQ

[pethornton]

Hi Bill - we have gotten tremendous value out of the work done by SatNOGs observers. We check the dashboard and the DB several times a day. While we are able to downlink stored telemetry, we can’t downlink fast enough to get it all. So the real-time beacon records are very helpful for filling in our understanding of system health and behavior. And best of all, the students are enthralled by the idea that their satellite is an object of interest for people all around the world, who are actively helping them gather and display data. This spirit of generosity has really opened their eyes to the possibilities of a cooperative world. Thank you!

[LW2DTZ]

Your station @N9CQQ-EN52 is very useful for me to receive the DIY-1, if you could activate the decoder and direct the datas to the DIY-1 dashboard it would be great. Thank you for having your station active.

73 Gustavo, LW2DTZ

[pethornton]

It has been a while since our last update. The RamSat orbit has been unfavorable for daytime imaging over our target geography in the Smoky Mountains of East Tennessee. We have been working on retrieving continuous streams of stored telemetry data, which has been successful. Now the orbit is good again for imaging, and we hope to show some new results from that soon. In the meantime we are also doing what we can to arrest the satellite’s tumble. It is now tumbling at its slowest rate since deployment - about 11 minutes for a full rotation. The plot below shows SatNOGS dashboard data from December 7, with current from the solar panels on the top plot, and sun sensor data on the bottom plot. Some crude annotation is included to help see the evidence for a slow tumble. All systems are still healthy and operating smoothly after nearly 6 months in orbit. Thanks to all in the amazing SatNOGS community!

[pethornton]

Another update from RamSat mission control… The plot above shows steady loss in orbital altitude, with a 3-4 month variation due to orbital precession. We’re hoping to have another few months before de-orbit to keep working our mission. We have captured about 60 images, stored onboard, and are in the process of downlinking as many as we can. Our workhorse ground station was offline for over a month with rotator hardware failure, but is back up again. Observers over eastern North America will see image packet activity.
We hope to see increased temperatures in the telemetry data before RamSat’s demise, and any SatNOGS telemetry observations will be greatly appreciated over the coming months.
Our team is starting to think about another mission, and if we pursue that, we want it to be as useful as possible for the SatNOGS community. I’m going to open a separate thread to get your thoughts and discussion on what that might mean.

[fieldsde]

Congrats to the RAMsat team! This is a very successful project and a wonderful inspiration for the students.

[fieldsde]

Very successful! Thanks also for keeping up with documenting the project!

[pethornton]

This past weekend we had a chance to run an “easter egg” function in our flight code, that transmitted a Thank You message from RamSat intended for our project sponsors. The screen capture here shows the results. If we had known when we were developing the flight software how important SatNOGS would be to our success, we would certainly have included a shout out to this awesome community. Next best thing is to share our output, and our special thanks to you here.

[pethornton]

We have also been able to downlink several new images, posting them here for your viewing pleasure. We’re still working to get imagery over our target region of Gatlinburg, Tennessee, USA.