Hi David
Today, dc6ny and I have made some experiments with 700c (around noon) and 800xa (before sunset) on 3690 kHz. We have done experiments with 700b in september 2015, where we found out, that 700b is much more stable at low SNR as compared to 1600. Our result at that time was, that 700b is much better than 1600, because of this. But SSB was not beaten. But today, with 700c, we had quite some problems to understand each other, even with SNR of around 10db (as looked up on the spectrum display, not accurate). After doing the 700c experiment we swiched back to SSB and had no problem of understanding each other even at quite a noisy band (I have some very bad local signals from trolley bus lines, which send the inverter signals very broadband into HF). It is clear, that our ear is trained to this kind of noisy SSB environment. The 800xa experiment was quite disturbed by a russian station which was on the same frequency. So, the signal was seen in the spectrum, but could not be decoded all time. What is also seen: when there is no 800xa signal on the channel, one nevertheless hears now and then artifacts. We hoped, that 800xa would be better than cohpsk, but we could not confirm this in our experiment (all these are qualitative remarks, no measurements). Unfortunately, we can not give a more positive report (we would be very happy to do so! We appreciate very much your great work on codec2 and the modulations). I have noticed a problem with the freeDV-api (SVN 3006, 8000S/s) in 700b and c modes: when there is no sync with a signal, the cpu cycles go up very much! I am using a 1GHz cpu, and so, I get timeouts when not in sync. When using 7500S/s (SVN2299 or removing the 8000S/s in SVN3006) directly by resampling with the linux standard library, I don't get these timeouts, but the cpu cycles go up as well, but not so much as with 8000S/s. Probably you have some idea, why this is so. The measured execution times for 800xa-reception are much lower under all conditions I have seen so far. I will further investigate on this problem. Greetings, Alfred, hb9epu On 07.02.2017 21:25, David Rowe wrote: > Hi Helmut, > > Lol you won't get stoned - I welcome all opinions. > > I share your goal of a digital mode that outperforms SSB at low SNR. > It's a tough goal, there are good reasons why SSB has been dominant for > 50 years. > > Could you please tell me more about your tests? In particular I'm > looking for feedback on 700C. A/B samples would be very useful, e.g off > air recordings of 700C followed by SSB over the same channel. > > My experience locally is 700C it's more robust than FreeDV 1600, but I > have had some situations where SSB worked when FreeDV 700C didn't. I > have also had some experiences of error free 700C when SSB was right > down in the noise. > > Walter, KW5H, and a team of Hams testing FreeDV 700C in the US have been > making contacts over paths as long as 2500km, and have consistentl > experiences of 700C working when SSB was unreadable. > > By piecing together our experiences (and especially samples) we can > improve FreeDV. For example if 700C doesn't work for you Helmut, but > does for Walter - lets explore the differences and find out why. > > Cheers, > > David > > On 08/02/17 02:03, Helmut wrote: >> Hi David and all, >> >> I think it’s up to Flex to correct their smart-sdr software to make freeDV >> mode 1600 available on the both sidebands depending on the particular band. >> That’s a standard DSP application. >> To stimulate Flex and others like John Melton and his pihpsdr to implement >> all modes of freeDV is a more critical action: We spent many hours and >> enthusiasm trying to evaluate objectively the different freeDV modes in the >> real world of our HF bands. No significant improvement concerning >> readability, resistance to low SNR, fading, Doppler and jamming could be >> observed. In our mind freeDV is currently a nice experimental platform, but >> no severe competition to SSB. To try to change this situation with >> measureable and necessary benefits should be the goal. To make digital voice >> e.g. reliably decodable when SSB fails would be great. Maybe the more >> effective approach is to keep and apply 2.700 kHz bandwidth but to increase >> redundancy. >> >> Ok, here I’m ready for stoning. >> >> 73, Helmut, DC6NY >> >> >> -----Ursprüngliche Nachricht----- >> Von: David Rowe [mailto:[email protected]] >> Gesendet: Dienstag, 7. Februar 2017 09:29 >> An: [email protected] >> Betreff: [Freetel-codec2] Flex and FreeDV >> >> It's been a while since Flex released their support for FreeDV. Walter >> K5WH, and I have contacted them recently and it turns out the API that >> it used to integrate FreeDV is open source and available here: >> >> https://github.com/n5ac/smartsdr-dsp >> >> I really can't stretch to cover this one, I'm already working on codecs, >> modems, and the FreeDV GUI program. >> >> Can some one else please step up and work on getting the Flex support >> for FreeDV up to date? Plenty of email support available from myself >> for the FreeDV side and the good people at Flex for their side of the API. >> >> Thanks, >> >> David >> >> On 04/02/17 13:14, David Rowe wrote: >>> Thanks Glen, food for thought.... >>> >>> On 04/02/17 11:02, glen english wrote: >>>> ham systems , that are SNR limited, not bit rate limited, will ALWAYS be >>>> a better bet with a constant envelope signal, compared to a linear >>>> signal (non constant amplitude signal) in terms of power output power >>>> amplifier UTILIZATION. Utilization is the key here..... >>>> >>>> for systems that need to push a large bit rate through a narrow channel, >>>> there is little option but a QUAM signal. >>>> >>>> There is no disadvantage of a constant envelope signal compared to a >>>> linar signal with regards to multipath protection, mitigation, dopplers >>>> etc PROVIDING THAT the signal chain is linear on receive. >>>> >>>> That is to say, after limiting a signal, information has been thrown >> away. >>>> So, not to get confused with a constant envelope signal with FM demod. >>>> results are poor compared to using a linear demod. >>>> ********** >>>> >>>> David, it is worth a look at GSM >>>> >>>> GSM has a training sequence each frame and deals with multipath (up to >>>> the training length) very well. multipath can improve the SNR. >>>> >>>> constant envelope, non linear TX, linear RX. >>>> >>>> >>>> g >>>> >>>> >>>> >>>> On 4/02/2017 10:37 AM, David Rowe wrote: >>>>> Thanks Steve, there was error in the >>>> >>>> >>>> >> ---------------------------------------------------------------------------- >> -- >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Freetel-codec2 mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>>> >>> >> ---------------------------------------------------------------------------- >> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Freetel-codec2 mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> >> ---------------------------------------------------------------------------- >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> >> >> --- >> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. >> https://www.avast.com/antivirus >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
