| Satellite | Notes |
|---|---|
| BRO 4 | Identified as OBJECT A (49066), here are the results of ikhnos on observation 4608583. |
| RADCUBE | Identified as OBJECT B (49067), here are the results of ikhnos on observation 4608535. |
| LEDSAT | Identified as OBJECT D (49069), here are the results of ikhnos on observation 4608735. |
3 Likes
Vlad, not related to that error 500, but please ensure you are using
The latest (0.09) 1KUNS demodulator: http://uz7.ho.ua/modem_beta/other-versions.zip
1 Like
It should be ok now.
1 Like
There is an issue related to the new satellite merging feature of DB & third party decoders for LEDSat using the old temporary NORAD ID which I describe in satnogs-db#478. Telemetry forwarders using the correct final NORAD ID are not affected.
Since the final identification of LEDSat with Object D/49069 in Vega VV19 - 2021-08-17 - #21 by fredy users of telemetry forwarders should update their configuration with the final NORAD ID of LEDSat (49069).
2 Likes
I have added a comment on the issue, for those that still send data to the temporary NORAD ID, these data will be merged in the next days.
2 Likes
Hello all,
Iβve noticed a problem with the LEDSAT decoder/database while downlinking some telemetry
It looks like all telemetry sent to the database has the time of reception attached to it instead of the time in the telemetry itself
So if we are downlinking telemetry from a few days ago, it all gets bunched up to the current time of reception
Take for example the data on grafana from 20210903T084143Z to 20210903T084350Z, it contains one point every second, but in that period we were downlinking data from 20210902T202000Z to 20210903T084100Z at one point every 60 seconds
The time associated with the telemetry should be the one contained in unix_ts_s, with the addition of unix_ts_ms/1000 if one wants millisecond accuracy
Is this fixable? Maybe not retroactively
1 Like
yes, by default telemetry frames are associated with the reception timestamp when stored in the satnogs-db. @DL4PD: Is it possible to use a field from the telemetry frame itself as timestamp for the entry in the InfluxDB?
If it is fixable it can be done retroactively as it is possible to flush all decoded frames (from InfluxDB) and re-run the decoder on all raw frames, as they are stored separately in SatNOGS DB.
That is only possible with a dedicated influxDB import.
1 Like