Closed f6bvp closed 4 years ago
The af_carrier and deviation are not correct. See Swiatowid.yml for reference.
Thanks Daniel for the reference about af_carrier and deviation for AFSK 1200 satellites. My recording may be of bad SNR quality for I don't get any frame decoded. I will try with another later. By the way I noticed that the satellite-recording/swiatowid.wav is lacking any AX25 frame audio. I recommand a good Satnog recorded path : swiatowid-satnogs_2154702_2020-05-04T23-17-10 I edited the wav file using Audacity in order to remove most of noise sequence. I could send it to you if you want. I used this one with Swiatowid.yml and it worked. Regards, Bernard
I recommand a good Satnog recorded path : swiatowid-satnogs_2154702_2020-05-04T23-17-10 I edited the wav file using Audacity in order to remove most of noise sequence. I could send it to you if you want. I used this one with Swiatowid.yml and it worked.
Thanks! My recommendation for easier integration is that you crop a section of a few seconds with one or two packets, make it WAV mono 48kHz and submit it on a pull request to satellite-recordings.
I am not familiar with git pull although I did use it a few years ago while debugging AX25/ROSE Linux modules. Please find links toward recordings for AO-27 (EYESAT-1, NORAD 22825) ftp://f6bvp@ftpperso.free.fr/enregistrements/AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav Also included a link for excellent swiatowid.wav ftp://f6bvp@ftpperso.free.fr/enregistrements/swiatowid.wav
Regards, Bernard
Despite using what I think are the good settings for AO-27 telemetry, i.e. modulation: AFSK baudrate: 1200 af_carrier: 1700 deviation: 500 framing: AX.25 gr_satellites does not dump any telemetry. How is it possible to debug the process ?
Bernard
By the way, I added alternative_names :+1: name: AO-27 for convenience : alternative_names:
Please find links toward recordings for AO-27 (EYESAT-1, NORAD 22825) ftp://f6bvp@ftpperso.free.fr/enregistrements/AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav
I'm getting "login incorrect" in this FTP:
$ LANG=C wget ftp://f6bvp@ftpperso.free.fr/enregistrements/AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav
--2020-05-19 17:33:28-- ftp://f6bvp@ftpperso.free.fr/enregistrements/AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav
=> 'AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav'
Resolving ftpperso.free.fr... 212.27.63.3
Connecting to ftpperso.free.fr|212.27.63.3|:21... connected.
Logging in as f6bvp ...
Login incorrect.
gr_satellites does not dump any telemetry. How is it possible to debug the process ?
Debugging this often requires knowledge of the decoding process and gr-satellite's internals. The --dump_path
parameter can be of help. Are you certain that the signal in the recording is fine (you could try decoding with direwolf, for example)?
Sorry, my fault !
http://f6bvp.free.fr/enregistrements/AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav
http://f6bvp.free.fr/enregistrements/swiatowid.wav
Le 19/05/2020 à 17:35, Daniel Estévez a écrit :
Please find links toward recordings for AO-27 (EYESAT-1, NORAD 22825) ftp://f6bvp@ftpperso.free.fr/enregistrements/AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav
I'm getting "login incorrect" in this FTP:
|$ LANG=C wget ftp://f6bvp@ftpperso.free.fr/enregistrements/AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav --2020-05-19 17:33:28-- ftp://f6bvp@ftpperso.free.fr/enregistrements/AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav => 'AO-27-EYESAT-1-satnogs_2148223_2020-05-04T22-16-21.wav' Resolving ftpperso.free.fr... 212.27.63.3 Connecting to ftpperso.free.fr|212.27.63.3|:21... connected. Logging in as f6bvp ... Login incorrect. |
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/daniestevez/gr-satellites/issues/98#issuecomment-630902126, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLUALKP27BMRGMUUNV4H53RSKRMFANCNFSM4NEFY6SA.
Actually --dump_path parameter with AO-27 wav file gave me three large files with bytes I looked at using hexdump. clock_recovery_err.f32 clock_recovery_T_avg.f32 clock_recovery_out.f32 I don't know what to do else. I will try using Direwolf.
FYI, I have also been trying to learn how to decode using the new method with a known-good AO-27 audio file (decodes properly w/ Direwolf using the "MODEM 1200 1220:2100" directive). As with F6BVP's testing, I have not been able to get any output from the new gr-satellites.
Well, it seems that the baudrate of this old bird is no longer accurate. Looking at @f6bvp's recording, it decodes several packets fine if I set the baudrate to 1240 instead of 1200. No wonders that gr-satellites has problems trying to cope with that large difference.
Direwolf has a much better and more complex AFSK decoder than gr-satellites (it actually tries 3 different algorithms in parallel, and corrects single bit errors), so it is also not surprising that Direwolf can work even without knowing the correct baudrate.
I also succeeded in decoding the audio file using Direwolf.
Here is first frame :
Thanks Daniel for suggesting direwolf and finding the AO-27 clock issue.
Le 19/05/2020 à 18:24, Daniel Estévez a écrit :
Well, it seems that the baudrate of this old bird is no longer accurate. Looking at @f6bvp https://github.com/f6bvp's recording, it decodes several packets fine if I set the baudrate to 1240 instead of
- No wonders that gr-satellites has problems trying to cope with that large difference.
Direwolf has a much better and more complex AFSK decoder than gr-satellites (it actually tries 3 different algorithms in parallel, and corrects single bit errors), so it is also not surprising that Direwolf can work even without knowing the correct baudrate.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/daniestevez/gr-satellites/issues/98#issuecomment-630929950, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLUALMHIK5MHZZLNSKR4ODRSKXC5ANCNFSM4NEFY6SA.
The recordings for the Światowid AX.25 packet and AO-27 are now in satellite-recordings and I have added the SatYAML file for AO-27 to the master branch.
You can close this when you think it's appropriate.
Specifying -clk_bw 0.14 improved decoding. This time three frames !
gr_satellites python/satyaml/AO-27.yml --wavfile ~/Téléchargements/2020-05-11--AO27--1k2-data--audio.wav --samp_rate 48000 --hexdump --clk_bw 0.14
Yes. Tweaking the clock bandwidth and clock limit can improve decoding, but it's not easy to find a value that works best for all situations, so I'm not too keen on changing the defaults without lots of measurements on different satellites.
Anyone knows how to decode AO-27 data? The closest info I found is here: https://www.pe0sat.vgnet.nl/satellite/amateur-radio-satellites/ao-27/
But "channel" doesn't makes sense to me.
i haven't looked at the telemetry format, and I don't know if there are any documents. Perhaps Mike DK3WN can help. Can the frames we have decoded here be interpreted correctly by Mike's software?
Negative ref. the legacy DK3WN decoder - apparently the telemetry format has changed with the reprogramming of the satellite
I'm closing this, since the issue was a "question issue" and it's being more than a month without further comments. Please feel free to reopen if you want to discuss again.
Hi Daniel, I obtained AO27 wav file from Scott Chapman tweet https://twitter.com/scott23192/status/1259978315991076865 From above I learned that AFSK frequencies were 1220 - 2100 Hz
I thus created the following AO-27.yml
name: AO-27 norad: 22825 data: &tlm Telemetry: telemetry: ax25 transmitters: 1k2 AFSK downlink: frequency: 436.795e+6 modulation: AFSK baudrate: 1200 af_carrier: 2100 deviation: -1200 framing: AX.25 data:
However I did not obtain any frame decoded from : gr_satellites python/satyaml/AO-73.yml --telemetry_output ao-27.txt --wavfile ~/Bureau/AO27-2020-05-11--1k2-data--audio.wav --samp_rate 48000
Is deviation the only wrong parameter ?
73 de Bernard, f6bvp