Once positive ID is discerned, will the data records be merged? The RamSat team is meeting tonight to begin work on decoder and dashboard. We are so thankful for the satnogs community!
3 Likes
Yes any data will be merged after identification.
Let me know if I can be of any help!
1 Like
An update: the RamSat team is working on getting an uplink. Some of the very early satnogs reports from June 14 (deployment day) show that RamSat was responding to uplink packets from some station in western North America (not affiliated with the RamSat team). That is a little disconcerting, since we’re not sure who would have the uplink frequency, but also somewhat comforting since we know that the receiver end of the flight radio and the received-packet processing code onboard were working properly, at least on Day 1. We had solid 2-way comms during extensive ground testing, so unsure why we’re having trouble with the uplink now. If anyone has suggestions on this front for a rookie team, we’d be glad to hear it. We still have a few ideas that we’re testing, including longer transmit delay and changing the transmit level (both TNC settings).
RamSat is now identified as OBJECT SL(48850). More details can be found in https://archive.org/details/ikhnos-identification-48850
2 Likes
Hi @fredy could you help me understand what the two waterfall diagrams at the internet archive link are showing, and how that helps to identify RamSat as 48850? Thanks,
Peter
The red line shows the path that the signal should follow if it was OBJECT X… So the first one is for OBJECT SL and the second for OBJECT SM.
If you are familiar with running python you can check on your own to produce these images by using Alfredos-Panagiotis Damkalis / Ikhnos · GitLab by following the guide in README file.
Just to be clear this was one of the observations I tried. I’ve tried observations from stations on Australia, North America and Europe to make sure, as sometimes results are affected by the station location and the satellite orbit. All the results showed that RamSat is OBJECT SL.
1 Like
Thank you, very helpful explanation. I will pass this information along to my POC at 18SPCS.
1 Like
Thank you Patrick. I’m familiarizing myself with the documentation and will reach out to you soon.
-Ian Goethert
2 Likes
@fredy it looks like 18SPCS is going to switch their catalog to show RamSat as 48850, and SOAR as 48851. They are checking with the SOAR team to get their input. Would it be possible for you to do another comparison like what you did five days ago, as further support for the switch?
This is for RamSat from observation 4309130:
Object SL (48850):
Object SM (48851):
Also for making it more solid we have the identification of SOAR too:
SOAR is identified as OBJECT SM(48851). More details can be found in ikhnos-identification-48851.
2 Likes
I can confirm that 18SPCS is switching their catalog to have RamSat as 48850 and SOAR as 48851. Updates in their catalog may be complete today. Thanks for the help here in sorting out the two objects!
2 Likes
Following up: the catalog at space-tracker.org now reflects the updated names for object 48850 (RamSat) and 48851 (SOAR).
I know you may all be really busy in this LEOP phase; could you ping Ian Goethert for the decoder, please? I can finish it if he likes, just need a go!
Our team will meet tomorrow to review the decoder progress. I have a question. In the “starting with satnogs decoders” post, the example for an ax.25 frame includes fields for the ax.25 header information. When we retrieve observations via download, or when we get individual frames from an observation in the waterfall/data view, the ax.25 header content is not present (source and destination callsigns, etc). It appears that we are only seeing the payload part of the ax.25 frame. So when importing into the kaitai IDE, that header content is not present to be parsed. That seems ok to me, since we don’t want the header information anyway, but it makes me wonder if we are doing something wrong with retrieving the frames. Do you think you could take a look at one of the RamSat data frames (any one would be fine) and let us know if you are seeing the regular ax.25 header information? If so, could you give us instructions on how to retrieve the frames so we see that information, too?
2 Likes
@pethornton: I’ve just checked the latest frame in DB through this API call (remember that you need to login first!):
https://db.satnogs.org/api/telemetry/?satellite=48850
{
"norad_cat_id": 48850,
"transmitter": "",
"app_source": "sids",
"schema": "",
"decoded": "",
"frame": "AE68A69690406086A240404040E103F05253426561633A2C323032312D30372D30315431343A34393A30332E37315A2C3832372C202039382C312C203930302C202020322C202034382C313030382C202031342C203138322C203531362C202020382C203832382C203231392C3832372C202020332C3333332C202033352C3530332C202036342C202036302C202036322C202037312C2D3337342C203731382C202036332C203134322C202020362C202033352C203138342C203137352C202038362C203132332C202033332C202034352C2031343630332C202D323736382C2032373333382C303030302C2020202020302C2020202020302C20202030",
"observer": "K4KDR-FM17es",
"timestamp": "2021-07-01T14:50:49Z",
"version": "1.6.6",
"observation_id": null,
"station_id": null
},
This frame definitely has the AX.25 header included, the “magical” part is AE68A69690406086A240404040E103F0 - these are 16 AX.25 header bytes including ctl and pid (ctl=0x03, pid=0xf0).
The Kaitai IDE shows this as:
There you go: the AX.25 header is present!
Satnogs-decoders using the initial version of Ian with some slight modifications done by me decodes this frame to:
❯ decode_frame Ramsat ../sampledata/ramsat/k4kdr_01.bin
{
"dest_callsign": "W4SKH ",
"src_callsign": "CQ ",
"src_ssid": 0,
"dest_ssid": 0,
"ctl": 3,
"pid": 240,
"prefix": "RSBeac:",
"beacon_timestamp": "2021-07-01T14:49:03.71Z",
"message_type": 827,
"battery_voltage": 98,
"battery_is_charging": 1,
"voltage_feeding_bcr1_x": 900,
"current_bcr1_neg_x": 2,
"current_bcr1_pos_x": 48,
"voltage_feeding_bcr2_y": 1008,
"current_bcr1_neg_y": 14,
"current_bcr1_pos_y": 182,
"voltage_feeding_bcr3_z": 516,
"current_bcr1_neg_z": 8,
"bcr_output_voltage": 828,
"bcr_output_current": 219,
"battery_bus_voltage": 827,
"battery_bus_current": 3,
"low_v_bus_voltage": 333,
"low_v_bus_current": 35,
"high_v_bus_voltage": 503,
"high_v_bus_current": 64,
"temperature_eps": 60,
"temperature_battery_motherboard": 62,
"temperature_battery_daughterboard": 71,
"temperature_pos_x_array": -374,
"temperature_neg_x_array": 718,
"temperature_pos_y_array": 63,
"temperature_neg_y_array": 142,
"sunsensor_pos_xa": 6,
"sunsensor_pos_xb": 35,
"sunsensor_neg_xa": 184,
"sunsensor_neg_xb": 175,
"sunsensor_pos_ya": 86,
"sunsensor_pos_yb": 123,
"sunsensor_neg_ya": 33,
"sunsensor_net_yb": 45,
"imtq_cal_mag_x": 14603,
"imtq_cal_mag_y": -2768,
"imtq_cal_mag_z": 27338,
"antenna_deployment_status": 0,
"longitude": 0,
"latitude": 0,
"elevation": 0
}
❯
Everything looks as expected!
I’ve generated the binary file using this:
❯ echo "AE68A69690406086A240404040E103F05253426561633A2C323032312D30372D30315431343A34393A30332E37315A2C3832372C202039382C312C203930302C202020322C202034382C313030382C202031342C203138322C203531362C202020382C203832382C203231392C3832372C202020332C3333332C202033352C3530332C202036342C202036302C202036322C202037312C2D3337342C203731382C202036332C203134322C202020362C202033352C203138342C203137352C202038362C203132332C202033332C202034352C2031343630332C202D323736382C2032373333382C303030302C2020202020302C2020202020302C20202030" | xxd -r -p - > ../sampledata/ramsat/k4kdr_01.bin
If you’re ok I would push a new decoder into our infra and you can easily make changes later on - just to have a start (it looks pretty promising) and we could immediately start a dashboard!
hth,
Patrick
4 Likes
Wonderful, and “magical” indeed! I now understand that the callsigns are not showing up in the ascii interpretation of the data frames because of left bit shifting in the ax.25 header. Thank you for clarifying that, and for the completed decoder. All the field descriptions look good to me, with two exceptions: just after the beacon timestamp is a field labeled as “message_type”. That should be “battery_voltage”. The next field, currently labeled “battery_voltage” should be “battery_current_magnitude”. All other fields are correctly labeled. If you could make that change and push the decoder that would be fantastic.
2 Likes
Cool, cool!
I am going to merge the decoder that produces this:
❯ decode_frame Ramsat ../sampledata/ramsat/k4kdr_01.bin
{
"dest_callsign": "W4SKH ",
"src_callsign": "CQ ",
"src_ssid": 0,
"dest_ssid": 0,
"ctl": 3,
"pid": 240,
"prefix": "RSBeac:",
"beacon_timestamp": "2021-07-01T14:49:03.71Z",
"battery_voltage": 827,
"battery_current_magnitude": 98,
"battery_is_charging": 1,
"voltage_feeding_bcr1_x": 900,
"current_bcr1_neg_x": 2,
"current_bcr1_pos_x": 48,
"voltage_feeding_bcr2_y": 1008,
"current_bcr1_neg_y": 14,
"current_bcr1_pos_y": 182,
"voltage_feeding_bcr3_z": 516,
"current_bcr1_neg_z": 8,
"bcr_output_voltage": 828,
"bcr_output_current": 219,
"battery_bus_voltage": 827,
"battery_bus_current": 3,
"low_v_bus_voltage": 333,
"low_v_bus_current": 35,
"high_v_bus_voltage": 503,
"high_v_bus_current": 64,
"temperature_eps": 60,
"temperature_battery_motherboard": 62,
"temperature_battery_daughterboard": 71,
"temperature_pos_x_array": -374,
"temperature_neg_x_array": 718,
"temperature_pos_y_array": 63,
"temperature_neg_y_array": 142,
"sunsensor_pos_xa": 6,
"sunsensor_pos_xb": 35,
"sunsensor_neg_xa": 184,
"sunsensor_neg_xb": 175,
"sunsensor_pos_ya": 86,
"sunsensor_pos_yb": 123,
"sunsensor_neg_ya": 33,
"sunsensor_net_yb": 45,
"imtq_cal_mag_x": 14603,
"imtq_cal_mag_y": -2768,
"imtq_cal_mag_z": 27338,
"antenna_deployment_status": 0,
"longitude": 0,
"latitude": 0,
"elevation": 0
}
❯
3 Likes
Just uploading the Mission Patch to have it in the dashboard:
Edit: there we go: Grafana
Let me know who wants to have editor rights on it.
4 Likes
I just had a chance to check out the new dashboard - so awesome! Thank you. Please give edit rights to me and Ian Goethert for now.
3 Likes