How to upload is explained in this panel.
You can also upload data ussing JA3TDW ECTU software.
It is available in this web: JA3TDW/Fumio ASAI(AMSAT-NA) (eonet.ne.jp)
73 de David EA4SG
Although I appreciate Fumioās work, his uploader not (yet) takes the time of beacon reception into account.
If you upload CW data using ECTU, the data will get the timestamp from the upload time.
There is really no big deal using the curl command.
Once entered the callsign and coordinates, you have to just adjust the reception date and time and insert the beacon. Thatās all.
For those already using GNU Radio + gr-satellites, you can easily upload to SatNogs (WITH a corrected time-stamp) as described in the following post:
You are right Daniel. FumioĀ“s tool is OK but only if you upload the data as soon as you get it.
73s de David
The command
echo "...." > /dev/udp/127.0.0.1/9999
translates into ASCII-HEX as also Bob (N6RFM) showed us in his example A27AB81400 ā 41323741423831343030.
While this will upload to the database and lead to someones name on the left panel āMost Recent Observers (last 24h)ā, it however would be discarded by the decoder and not shown on the right panel "Data Frames Decoded - 30 Days " and understandably also not processed and shown on the dashboard.
The decoder needs the beacon as it is, in HEX.
Therefore, if you like to use Scottās way via GNU Radio please use the following command to keep the hex format of the beacon.
echo '636F736D6F30206A7331796F692030303030303020< beacon >' | xxd -r -p | nc -u -N 127.0.0.1 9999
While < beacon >
is a beacon like for example A27AB81400
or a27ab81400
.
Netcat (nc
) is also available for Windows, but for xxd
, I donāt know.
Thanks for the clarification!
Iāve been studying this to fully understandā¦
So when decoding a CW beacon, is it correct that we have to know in advance what part is ASCII and what part is being transmitted as HEX?
Of course in some cases we can just determine that visually, as with a call sign.
But when I see something like 000000, I would not know how to tell if that was a string of six zero ASCII characters or three bytes of 0x00 HEX.
I guess people wishing to upload CW decodes, then, would have to know the format of the entire beacon to upload it into SatNogs DB correctly?
Please look at the āHow to upload CW beaconsā panel.
The yellow part of the CW beacon always stays as it is.
You only have to update the pink (last) part of the beacon.
Donāt think of ASCII and HEX, just put your last beacon part as you receive it at the place where it belongs.
Many thanks!
That makes it very clear for this particular satellite; I guess I was thinking more āin generalā.
However, if that kind of guidance will be available for other sats as well, everyone should be able to format CW decodes correctly for the DB.
Great work - thanks!
Welcome.
Well, there has to be a decoder behind to handle manual uploads in such way.
It looks like that Iām the first one who builds decoders capable of that.
And on all my CW dashboards I put a panel explaining how to upload data.
By the way, my explanation refers only to my way of uploading.
If you use GNU Radio with echo "...." > ...
also the pink part will be translated into ASCII-HEX which makes it undecodable for the decoder.
Feel free to also upload to CO-65.
Hi Daniel
If Iām correct this is how I should enter my observation from today -
https://network.satnogs.org/observations/10299622/
2024-09-25T17:45:13 sakura js1ymy js1yni a57fbb6329a10808
curl --data ānoradID=60953&source=HS318=2024-09-25T17:45:13Z&frame=73616B757261206A7331796D79206A7331796E6920a57fbb6329a10808&locator=longLat&longitude=-1.35E&latitude=50.92Nā https://db.satnogs.org/api/telemetry/
I ran out of time, but was looking to see how to handle this type of beacon that we decode as ASCII but that needs to be converted to HEX for upload to SatNogs. No doubt it could be scripted out, but as you say, if the beginning of a particular satelliteās beacon is always the same, then it only takes a minute to copy/paste the entire upload together.
For anyone wanting to run with the idea of making it semi-automated, here is ONE way to get the required HEX from the ASCII portion of a beacon:
echo 'cosmo0 js1yoi 000000 ' | xxd -p | head -c -3
636f736d6f30206a7331796f692030303030303020
ā¦ then, just append the HEX portion of your decode and you have the entire string for upload by ācurlā, GNU Radio, or whatever tool you use for submissions to the SatNogs DB.
Again, this step is unnecessary for a given satellite if the beginning is always the same - Iām just thinking more generally for other, similar beacons.
You removed ā×tamp=ā. Thatās imporant!
And you have to replace the pink part, not just add yours.
And as Scott already repeated:
The yellow part of the CW beacon always stays as it is.
Thanks again, the timestamp was a copy and paste error of mine, and I now understand the yellow section stays the same as the dashboard is setup to recognize that ident/name
Thanks Daniel!!
Iām sorry, I didnāt recognize that you were talking about SAKURA.
Scott and I were talking about CosmoGirl-Sat.
It now ended up, that you uploaded data from SAKURA to the noradID
of CosmoGirl-Sat (60953) and so the data is displayed on the dashboard of the latter one which leads to for example āAntenna: not deployedā.
Next time I have to add a length check to the decoder.
The dashboard for SAKURA has not yet been completed as the decoder (also one of mine) had a little bug. However you hit the correct yellow part for it.
The only part you yet have to change is the noradID
to 60954 for SAKURA.
Once the dashboard has come online, which is this time done by one of the SAKURA team members, youāll see your data on it.
apologies, thatās my fault too, are you able to delete the data I have added. There should only be 3 uploads of data. when I was adding the data last night I did wonder why the example you showed only has 10 characters that needed to be change but the data for Sakura has 16. This answers that.
I will review my CosmoGirl-Sat. data tonight I have a lot of data to review there.
I tried to add a regular expression to the Grafana panel to discard values which are longer than the pink part but the decoder already discarded the rest of the beacon so all values have the correct length even if they are not valid (because from a different satelliteās beacon).
I donāt see an easy way not to show these three values, but will think about it.
I think the only way to remove them is to physically remove them from the database but how thatās done I donāt know, I would guess its written in the database language/code and not easy to remove