Re: [wsjt-devel] GFSK for FT8?
Hi Bill, . We should also take in account overlapping spectra as spreading information between symbols under GFSK will affect decoding of the overlapped signals mostly if we are using frequency criterion for candidate ranking and probably due to the inaccurate signal subtraction, assuming all signals on the band are GFSK modulated. Hopefully we can evaluate GFSK benefits/losses via simulation of the signals for overloaded band scenario. . 73, Igor UA3DJY >Date: Sun, 28 Apr 2019 16:10:16 +0100 >From: Bill Somerville < g4...@classdesign.com > >To: wsjt-devel@lists.sourceforge.net >Subject: Re: [wsjt-devel] GFSK for FT8? >Message-ID: < 0dd82369-a042-b1fd-0ae0-c5acc91eb...@classdesign.com > >Content-Type: text/plain; charset="utf-8"; Format="flowed" >... >Lastly, going back to your initial question. I was probably a bit over >zealous in saying there are only compatibility issues and no sensitivity >issues. For a single signal communication in the presence of noise >alone, using GFSK will reduce sensitivity compared with FSK due to >information being spread between symbols (inter-symbol interference or >ISI for short). The aim is to use an amount of frequency change >smoothing so that, on a busy channel, the overall interference between >signals is reduced, by limiting their bandwidths, such that net >sensitivity is increased. Choosing the exact amount of smoothing to >apply is a complex problem since it depends on the number of signals, >the distribution of signal strengths, the frequency distribution of >signals, as well as the distribution of time-synchronization accuracies. >All of these characteristics vary continuously during real world FT8/4 >communication on the Amateur bands, so all we can really do is carry out >empirical tests and try to pick an optimum filter bandwidth which gives >best results for the whole community. > >73 >Bill >G4WJS. > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] GFSK for FT8?
Hi Bill, . Many thanks for the detailed answer. Absolutely agree with you on the need to increase FT8 band capacity, we will try to implement FT8 GFSK support too when it is done in WSJT-X. . 73, Igor UA3DJY Re: [wsjt-devel] GFSK for FT8? From: Bill Somerville - 2019-04-27 13:37:57 On 27/04/2019 13:01, Игорь Ч via wsjt-devel wrote: > Hello Joe, > . > Is there any possible losses, e.g. sensitivity or compatibility, at > pushing FT8 in software towards GFSK modulation? > . > 73, > Igor UA3DJY Hi Igor, the simple answer is yes. But only related to compatibility, for example if we elect to use more smoothing of frequency shift discontinuities then a decoder designed to be optimal for that will loose sensitivity when decoding old style FSK signals. We have some choices if we switch to GFSK for FT8, some more practical than others. We can go all out for best GFSK performance by matching the decoder to the new GFSK shaped signal and accept a loss of sensitivity when decoding old style FSK signals, we can try and detect the signal shape and adjust dynamically, and so on. One important area is multi-pass multi-signal decoding with subtraction of previously decoded signals, subtraction is most effective if the synthesized signal facsimiles to be subtracted are generated in exactly the same way that the original transmitted signal was. I.e. it is not optimal to generate a GFSK facsimile of a decoded message for the purpose of subtraction if the original was actually an FSK signal. The approach we propose is to restrict the amount of smoothing applied to make a GFSK modulated signal to a relatively low amount and to perhaps apply an even smaller amount of smoothing to facsimile signals used for subtraction, so as to minimize the overall loss of sensitivity in a mixed FSK/GFSK environment. Obviously the intent is for all stations to move to GFSK modulation eventually as it has clear benefits despite the extra complexity of implementation, so any interim measures to limit sensitivity loss when decoding FSK modulated signals will be biased towards best performance for GFSK decoding. If we take that approach I assume the intention will be to move towards decoding purely optimized for GFSK modulation over time as users migrate. This in itself is not a compatibility issue, rather a quality of implementation issue. Fortunately the Gaussian function convoluted with a raw FSK signal to make GFSK is continuously variable so we can pick one that exactly suits our needs and vary it over releases as needed. The final choice of Gaussian smoothig functions for transmission and for signal subtraction has been made by doing empirical tests using multiple simulated FT8 signals and using sample data gathered on air. For example measuring how many potential decodes are lost decoding real-World FSK modulated signals using a decoder optimized for GFSK modulated signals. Fortunately for the levels of smoothing we propose this loss of sensitivity is relatively small as other effects like noise mixed with signals tend to dominate. For FT4 none of this applies as we are using GFSK modulation from the get go and it is simply a case of selecting the amount of smoothing that achieves the wanted signal bandwidth characteristics. Note also that using GFSK modulation has an impact on transmission when changing a message on the fly which is considerably more complex as the whole waveform must be pre-calculated whereas with FSK modulation only the input symbols need be changed as the synthesized signal is generated instantaneously on the fly. There are also implications for ramp up and down of the transmission boundaries since the GFSK filtering will naturally do this without extra implementation complications. What is important is that moving to GFSK modulation *will increase overall channel capacity* so we hope any temporary loss of sensitivity will be outweighed by more potential concurrent decodes per bandwidth slot. This should be an attribute that is welcomed by HF users when occupancy is often approaching capacity at peak traffic times and at other times there will be no loss of performance once GFSK modulation is 100% adopted. 73 Bill G4WJS. >Суббота, 27 апреля 2019, 15:01 +03:00 от Игорь Ч : > >Hello Joe, >. >Is there any possible losses, e.g. sensitivity or compatibility, at pushing >FT8 in software towards GFSK modulation? >. >73, >Igor UA3DJY > -- Игорь Ч ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] GFSK for FT8?
Hello Joe, . Is there any possible losses, e.g. sensitivity or compatibility, at pushing FT8 in software towards GFSK modulation? . 73, Igor UA3DJY ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] bug in 77-bit message packing
Hello Joe, . This behaviour is triggered by this code in the subroutine pack77_1: . if(index(w(1),'/P').ge.4 .or. index(w(2),'/P').ge.4) i3=2 !Type 2, with "/P" ... if(index(w(1),'/P').ge.4 .or. index(w(1),'/R').ge.4) ipa=1 if(index(w(2),'/P').ge.4 .or. index(w(2),'/R').ge.4) ipb=1 . Compоund сallsigns where base call starting from 'R' char are also affected by this bug. . 73 Igor UA3DJY >Суббота, 22 декабря 2018, 13:10 +03:00 от Игорь Ч : > >Hello Joe, >. >There is a bug in packjt77 module observed when first character of the base >call is 'P' in the compound callsign. >It can be seen in ft8apset.f90 code, where message with user's callsign >DU6/VA3AAA is packed as >'VA3AAA K9ABC RRR' and i3 equal to 1, while message with user's callsign >DU6/PA3AAA is packed as ' PA3AAA/P K9ABC RRR' and i3 equal to 2. >. >With minor change in user's callsign to DU/PA3AAA message packing working well >there: ' PA3AAA K9ABC RRR' with i3 equal to 1. >. >73 Igor UA3DJY -- Игорь Ч ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] bug in 77-bit message packing
Hello Joe, . There is a bug in packjt77 module observed when first character of the base call is 'P' in the compound callsign. It can be seen in ft8apset.f90 code, where message with user's callsign DU6/VA3AAA is packed as 'VA3AAA K9ABC RRR' and i3 equal to 1, while message with user's callsign DU6/PA3AAA is packed as ' PA3AAA/P K9ABC RRR' and i3 equal to 2. . With minor change in user's callsign to DU/PA3AAA message packing working well there: ' PA3AAA K9ABC RRR' with i3 equal to 1. . 73 Igor UA3DJY ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
Hello Laurie, . DX cluster usage is an Internet dependant DX-ing and contesting, it is accepted by community and organizers. . 73 Igor UA3DJY >Date: Mon, 10 Sep 2018 08:39:13 +1000 >From: "Laurie, VK3AMA" < _vk3a...@vkdxer.net > >To: wsjt-devel@lists.sourceforge.net >Subject: Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol >Message-ID: < cedeed7f-9422-3e2c-b286-a3abc1508...@vkdxer.net > >Content-Type: text/plain; charset=windows-1252; format=flowed > >IMO, it is very likely that an Internet dependant mode will not be >accepted for award purposes or by Contest organisers. > >de Laurie VK3AMA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
Hello Robin, . That is correct, it also can be considered as moving costs of power amplifiers and antenna systems to the server/software. At the moment we have approximately 65k FT8 users and there should be simple control layer protocol, costs may be similar to keeping pskreporter.info and hamspots.net at 24x7 operation. . 73 Igor UA3DJY >Date: Sun, 9 Sep 2018 01:32:20 +0100 >From: "G8DQX (WSJT developers on SF)" < wsjtde...@gape.me.uk > >To: wsjt-devel@lists.sourceforge.net >Subject: Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol >Message-ID: < cdad522e-acfc-16b7-53f2-766fbad16...@gape.me.uk > >Content-Type: text/plain; charset="utf-8"; Format="flowed" > >Igor, > >you forgot to mention that HLR & VLR technology is a *network* artefact, >generally to be found in mobile telecommunications networks. The >application to the Amateur Radio Service, where there are a large number >of stations but *no* over-arching network control is very unclear. > >For a public telecommunications network HLRs and VLRs, more accurately >their interfaces, are defined by standards developing organisations >(SDOs) such as 3GPP, paid for by network operators, and usually >developed by network manufacturers. These things are not cheap, and they >require continual maintenance and end-of-life replacement! > >What did you really have in mind? > >Robin, G8DQX > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
Hello Joe and all, . Most of questions raised on this subject can be solved via HLR/VLR database server usage, where visitor location register can match to the specific HF band where callsign, frequency, hash of the message being transmitted, protocol and code rate can be stored, callsign hash can be calculated from callsign in the VLR server. . Hash conflict of two or more callsigns on the same band can be solved as well via VLR connection using frequency window and other possible criteria. . Users who have not Internet connection can still operate FT8 via default coder/decoder with limited sensitivity to the current FT8 decoder value, while users who have connection to the VLR can get maximum performance via variable protocol and code rate. . Current implementation of the FT8 special messages(i3bit==1) does not allow to decode callsign from the hash if this callsign was not decoded in the previous message. Special messages are being used in MSHV software as effective way to increase QSO rate in the common FT8 bands, with extended FT8+ protocol the gap in software compatibility may increase and VLR server connection would let us to resolve such issues. . The best way to go forward is a sharing FT8+ flexibility to the Internet connection and limiting radio interface traffic to callsign and report transmission, the same QSO radio exchange protocol have been in use for a while in DXpeditions and contests where in CW callsign 'hash' can be recognized by human brain from multiple signals per frequency, speed and timing criteria. . 73 Igor UA3DJY ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
Hello Joe, . It was excellent example with the WSPR QSO, just thought we can get additional FT8 gain if some messages at QSO will be transmitted as 'hash hash' / 'call hash' / 'hash call' instead of callsigns. . Yes, there is a trade off between the sensitivity and protocol flexibility. Probably we can add more flexibility if some information will be passed over Internet, for instance free text messages and GRID, it will spare more bits toward sensitivity on the radio interface. . Other option is to pass some message's hash over Internet while transmitting this message via radio interface, it will also spare some bits toward sensitivity. . Proposed by Take JA5AEA variable code rate: we can pass information on the code rate over Internet at the QSO, hence appropriate decoder can be used per each message. The same approach can be implemented with the variable protocol where protocol details, for instance i3bit, can be broadcasted over Internet. . Leaving callsigns(hash) and report to the radio interface and combining radio interface messages and traffic over Internet in the FT8+ protocol we can marry JT65/JT9 sensitivity and FT8 rate of QSO. . I do not believe any new mode outside WSJT-X is a good idea, it would be more efficient to keep going in the common direction. . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X 2.0 possible new mode/protocol
Hello Joe and all, . We all have been missing JT65 mode sensitivity and proposed WSJT-X 2.0 new FT8 approach with 0.2 dB sensitivity penalty can make things even worse. . I would like to ask you to consider a new protocol where callsign hash would be used instead of the real callsign in all messages but CQ and incoming call, this way we can get back to -25..26dB SNR sensitivity although will get more limited with the free message length. . CQ message: 28 bit callsign1 + i5bit + 12 bit CRC = 45 bit incoming call: 10 bit call1 hash + 28 bit callsign2 + i5bit + 12bit CRC = 55 bit report message: 10 bit call2 hash + 10 bit call1 hash + i5bit + (10 bit call3 hash for DXpedition) + 6 bit report + 12 bit CRC = 43(53) bit roger+report message: 10 bit call1 hash + 10 bit call2 hash + 6 bit report+ i5bit + 12bit CRC = 43 bit 73 message: 10 bit call2 hash + 10 bit call1 hash + 15 bit GRID + i5bit + 12bit CRC = 55 bit RR73 message: 10 bit call1 hash + 10 bit call2 hash + 15 bit GRID + i5bit + 12bit CRC= 52 bit . Spare bits can be used for nonstandard(special) callsign transmission in CQ message. call1 hash could be omitted in the incoming call message if this message is originated by the nonstandard(special) callsign. . Probably we can optimize protocol even better while a main idea is to transmit a full callsign only once per each QSO and to transmit not more than one full callsign in the message. . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] gettinng out of indx() bounds in sync8.f90
Hello all, . Just a minor patch to prevent rare jt9 process crash in sync8.f90: . iz=ib-ia+1 call indexx(red(ia:ib),iz,indx) --- ibase=indx(nint(0.40*iz)) - 1 + ia +++ ibase=indx(max(1,nint(0.40*iz))) - 1 + ia ! max is workaround to prevent indx getting out of bounds . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Type 2 compound callsigns support
Hello all, . It is either lack of code or just bad example in the documentation: "QSOs involving Type 2 compound callsigns might look like either of the following sequences: CQ K1ABC/VE1 FN75" where country is not being recognized properly for this callsign in WSJT-X 1.9-rc3: . 102200 21 0.0 970 ~ CQ K1ABC/VE1 FN75 !U.S.A. . As it is up to local authorities to grant a licence, probably some extended support is required in the code to recognize country properly for type 2 compound callsigns. . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Audio input from RTP stream?
Hello Phil, . >Igor, the whole point of playing out silence is to maintain >synchronization. If, for example, the sampling rate is 48 kHz and your >RTP packets each contain 240 samples (5 milliseconds), then I would >replace a single missing packet with 240 samples of binary zeroes. Your >signal blanks for 5 ms, but synchronization is maintained when it >reappears. Most of the slower JT schemes wouldn't even notice. . We have been using correlation function to get in sync with the signal we are going to demodulate, where evaluated delta time (DT) of candidate signal shall match to the transmitted signal. Since we have been using FSK modulation high accuracy of derived DT will let us to get the best SNR of demodulated signal and will decrease number of errors prior passing demodulated codeword to the decoder. There are two level steps introduced in time domain if lost frames were replaced with zero values, this steps in level can be as high as 90 dB and always making horizontal spike line in the frequency domain, energy of this line depends on the step value. For instance, let's say we have got two signals being received in the same interval, where power of one signal is 40dB higher than other one's. We are getting one..two more wrong tones at demodulation for weaker signal for each silence insertion, these artificial noise 'tones' shifting peak of the correlation function bringing erroneous DT result. There are several options to manage this error: we can try to make smooth level transition in time domain between point A and point B where instead of the silence. Other option is to try reconstruct time domain signal between these points using previous/post frames as we know where there is the gap. . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Audio input from RTP stream?
Hello Phil, >I implemented RTP in about a page of C code, not counting all of the >UNIX/Linux system calls needed to set up multicast sockets. That's >actually the only hard part. With RTP I just check that the next packet >is in sequence, drop any old duplicates, and play out silence in place >of lost packets to maintain timing, which is much more important for >digital demodulators than for human speech. . Playing out silence in place of the lost packets is not a good idea: it will distrurb sychronization and will bring wrong Delta Time values to the weak signals at demodulation. I would suggest usage of some averaging instead of the silence. . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Multithreading FT8 decoder in WSJT-X and DX-pedition mode
Hello Joe and all, . Multithreading FT8 decoder in WSJT-X can provide workaround to the latency issues being observed at the DX-pedition mode tests. . Multithreading FT8 decoder is already implemented in JTDX and this approach might be taken from the latest JTDX source code. . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
