Hello Gerhard (and Glen), It's possible design a modem waveform to handle this channel.
Some form or PSK to fit in 2700 Hz, but it could be single carrier as multipath and freq selective fading is not an issue for a satellite channel. The high symbol rate would allow fast phase tracking. I'm guessing the phase noise would cause frequency spreading and random movements in the phase, a bit like the Doppler spread on HF channels. If we have a fast enough phase tracking we can handle that. The OFDM modem Steve and I have developed could be modified to work on this channel, if anyone is interested in working on it. Or they may be other single carrier PSK modems out there (e.g. in GNU radio). Cheers, David On 15/05/19 07:37, [email protected] wrote: > Hi, yes, I know about the main focus of mode 2020. I just want to > promote this mode also for satellite, as it really will be a high > quality audio mode and other DV modes are not allowed there because of > the bandwith limit of 2700 Hz. > > More tests will follow. But the problem not is Doppler shift, because > QO-100 a stationary satellite over Africa with very slow drift around a > fixed point. > The problem rather is the thermal drift and jitter in local oszillators > used for mixing microwave to "normal " frequencies. > > Those mixers operate with fundamental crystals at around 25 to 40 MHz > and so each drift or jitter is multiplied by a hugh figure. > But this is not a problem only for DV, just for every digital mode. > LNBs on 10 GHz are therefore stabilized by OCXOs or GPSDO, and same has > to be done on the TX side, although it is not as difficult as it is only > 2,4 GHz. I have worked several stations in G, DL and PA in mode 1600 > using the LimeSDR, only having a TCXO. Using other hardware (LimeSDR > mini or Adalm Pluto on TX side or LNB with PLL or even TCXO on RX side) > I have recognized, that Jitter of LO is quite a problem. Jitter could be > around 20-50 Hz and that is makeing narrow band decoding impossible. > > Anyway, it is a very interesting an new field to investigate. > > Regards > > Gerhard OE3GBB > > > > > Am 14.05.2019 21:36, schrieb David Rowe: > >> Hi Gerhard, >> >> Well done :-) The first 2020 signals in Europe (and space)! >> >> 2020 is designed for HF channels with SNRs > 10dB with slow fading, the >> sort of channel where SSB is an easy copy. So it won't go as low as >> 700D. On non-fading channels (like a satellite or UHF line of site) it >> will go down to 3dB SNR with no errors. >> >> The main focus of this project is the new, Neural Net codec. >> >> The demodulator in 2020, like 700D, has a rather narrow frequency offset >> acquisition range of +/- 20Hz. As you have found, will make getting sync >> on a microwave or satellite channel difficult. >> >> While it can track changing frequency offsets, it might not be able to >> track something as fast as satellite Doppler. >> >> -/- >> >> This week I've fixed some problems with the Windows build, so will test >> that this weekend and take a look at the sync bug next. >> >> Cheers, >> David >> >> On 14/05/19 22:07, [email protected] <mailto:[email protected]> wrote: >>> Hi David, >>> >>> Big success! >>> >>> Freedv-gui-brad-2020 is running on Ubunti 18.04 on my new I5-8xxx. I am >>> having SNR 20 in mode 2020 in closed loop and on 20m to the websdr in PA >>> and G above S7 I got full decoding. Just QSB below S7 is kind of a >>> problem. Also tuning is not as easy as in the other modes. So I first >>> had to tune to mode 1600 and than switch to 2020. The audio was >>> connected by simple cables between the Linux and the PC running HPSDR. >>> >>> Made also a first try for satellite work: >>> >>> First I was using a LimeSDR-USB for transmitting on 2,4 GHz using >>> SDR-Console. I recognized a problem in the transmission chain as there >>> were interuptions in the audio in both modes 1600 and 2020. Never had >>> that before, but changed recently to the new Version 3.0.9 of >>> SDR-Console. Have to check again with earlier version. >>> >>> I than changed to DATV-Express hardware and software for SSB. No >>> dropouts, good decoding on 2,4 GHz in mode 1600, but very difficult to >>> get the right tuning in mode 2020. But got SNR 16 in closed RF-loop >>> within the shack. I think at that frequencies the signal jitter and >>> thermal drift is quite serious. Will go on with TX to the satellite and >>> receive by WEBSDR with GPSDO control. >>> >>> First part of tests over satellite no finished. DATV-Express-Card is >>> drifting to much and with LimeSDR I burned my preamplifier. So I fired >>> up my 70cm to 13cm converters. First one was from DX-patrol. This one is >>> also drifting too much and would need a change in hardware with external >>> reference. The other one is from SG-Labs. His one is quite stable, just >>> some jitter is to hear in CW. This one is having the possiblility for >>> having an external reference. Will now hook up the audio from freedv to >>> the FT-897 and go on with my tests. >>> >>> I think it would be helpfull to have pilot tones in mode 2020, same as >>> in mode 1600, to scope with those unstabilities on microwave. A few >>> Hertz more in bandwith would not be any problem at this frequencies. >>> >>> Audio quality was PERFECT!! >>> >>> Thank you for your work. If I can help with further test, please let me >>> know. I am ready for skeds on shortwave now. >>> >>> Regards >>> >>> Gerhard OE3GBB >>> >>> >>> >>> >>> Am 12.05.2019 13:10, schrieb David Rowe: >>> >>> Hi Gerhard, >>> >>> Those sorts of messages to the Linux console are quite normal, >>> just some >>> debug stuff the sound card library prints out. >>> >>> Cheers, >>> David >>> >>> On 12/05/19 18:06, [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> wrote: >>> >>> Hi David, >>> >>> After installing freedv-gui-brad-2020 I wanted to configure a >>> second >>> sound card. But I get following message: >>> >>> oe3gbb@oe3gbb:~/freedv-gui-brad-2020$ ./build_linux/src/freedv >>> Server listening at 0.0.0.0:45116 >>> pos 1 1 >>> EXCHANGE_DATA_IN: >>> g_nSoundCards: 2 >>> g_soundCard1InDeviceName: HDA Intel PCH: ALC892 Analog (hw:0,0) >>> g_soundCard1OutDeviceName: HDA Intel PCH: ALC892 Analog (hw:0,0) >>> g_soundCard1SampleRate: 44100 >>> g_soundCard2InDeviceName: Logitech USB Headset: Audio (hw:1,0) >>> g_soundCard2OutDeviceName: Logitech USB Headset: Audio (hw:1,0) >>> g_soundCard2SampleRate: 44100 >>> rxInAudioDeviceName: HDA Intel PCH: ALC892 Analog (hw:0,0) >>> rxOutAudioDeviceName: Logitech USB Headset: Audio (hw:1,0) >>> txInAudioDeviceName: Logitech USB Headset: Audio (hw:1,0) >>> txOutAudioDeviceName: HDA Intel PCH: ALC892 Analog (hw:0,0) >>> freedv_get_n_speech_samples(g_pfreedv): 2880 >>> freedv_get_speech_sample_rate(g_pfreedv): 16000 >>> ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM >>> cards.pcm.rear >>> ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM >>> cards.pcm.center_lfe >>> ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM >>> cards.pcm.side >>> ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching >>> channel map >>> ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching >>> channel map >>> ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching >>> channel map >>> ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching >>> channel map >>> fifoSize_ms: 440 infifo1/outfilo1: 19404 infifo2/outfilo2: 19404 >>> rxFifoSizeSamples: 3290 >>> >>> I tried with two different USB headsets, result both the same. >>> These are >>> relatively old. Could that be the reason? >>> >>> Regards >>> >>> Gerhard OE3GBB >>> >>> >>> >>> >>> Am 12.05.2019 08:08, schrieb David Rowe: >>> >>> Hello, >>> >>> There's been steady progress on FreeDV 2020 lately: >>> >>> http://www.rowetel.com/?p=6747 >>> >>> This weekend, a few of us around Adelaide had 2020 QSOs to >>> get a feel >>> for the "user factors". There are a few bugs with sync and >>> the Windows >>> build left to work through. Speech quality is very good. >>> >>> In other news, a team of Hams have been working on the >>> software >>> engineering on Codec 2, in particular FreeDV 2020 and stm32: >>> >>> http://www.rowetel.com/?p=6725 >>> >>> Cheers, >>> David >>> >>> >>> _______________________________________________ >>> Freetel-codec2 mailing list >>> [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> <mailto:[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freetel-codec2 mailing list >>> [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> >>> >>> >>> _______________________________________________ >>> Freetel-codec2 mailing list >>> [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freetel-codec2 mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> >> >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
