> If you include a 'try' number, how would everyone listening know what it > is to predict the transmit frequency? : > > Before grabbing a Tx offset, you know from the past cycles if it was free. > Not if they hop on every transmission, as I propose.
We were talking about slightly different bits of detail, I guess. You are picking freq offsets on every 15sec, and I was only hopping once every QSO. (sort of like ALE). Since FT8 is strictly short QSOs, it would be ok, just each QSO defines a bigger QSO frame as the "slot". But yea, I like the idea of jumping every packet slot -- and that part of the hopping of course needs predictability within the QSO. Outside the QSO, it relaxes somewhat. Picking hop on every Tx makes the slots of the analysis of multiple-access smaller. Yea, good. If everyone is following the hopping-per-slot, then this works nice. But hopping only per QSO boundary could posssibly work better when there is a mix of older versions of software -- since the current software follows the traditional radio convention of "monitor before you Tx", which effectively creates a short term distributed channel reservation from observing at least one half of the duplex exchange. > In the MACA (Multiple Access with Collision Avoidance) paper I wrote > *way* back in 1990, I argued that CSMA (carrier sense multiple access, Totally agree. In the context of this thread, I was only using the word CSMA/CA as a loose allusion to the entire family of "Collision Avoidance" techniques - they are all in a cluster, and any member of that cluster is a leap away from the current. > of somebody! Interference occurs at receivers, not transmitters. You > really want to know who's *listening* on a channel, not who is > transmitting. That you can do by monitoring all the QSOs in the "band" Indeed. It can be further improved by some cooperative reservation logic/feedback/gossip. But that would need protocol change .. so not in scope here. -- 73 de ka6q Shri ---Original Message--- > From: Phil Karn <k...@ka9q.net> > Date: Fri, 27 Aug 2021 15:09:43 -0700 > To: "H.Shrikumar KA6Q" <shri.w...@enablery.org>, > Phil Karn via wsjt-devel <wsjt-devel@lists.sourceforge.net> > Subject: Re: [wsjt-devel] Idea for "frequency hopping" FT8 to reduce > collisions > > > On 8/27/21 1:23 PM, H.Shrikumar KA6Q wrote: > > I've had such ideas also, so adding to this: > > > > Do the hashing only when starting a CQ, not in the midst of a QSO. > Why not change it in the middle of a QSO? Any transmission (CQ or > otherwise) can potentially collide with another, and since the software > already decodes every transmission within the "band" it doesn't matter > if the frequency changes with every transmission in a QSO. > > Make the hash return not a single value but actually a series > > eg. add a try number into the hash input making it a PRNG. > > It's already a series since the hash function is perturbed by the time > of day (to 15 second resolution). The important thing is that if you > know a callsign and the time of day, you will know where that callsign > will transmit (if it transmits) so you can avoid it. These slots will > also be uniformly randomly distributed across the 'band', and they will > change with each transmission to avoid repeated collisions between pairs > of stations. > > If you include a 'try' number, how would everyone listening know what it > is to predict the transmit frequency? > > > Before grabbing a Tx offset, you know from the past cycles if it was free. > Not if they hop on every transmission, as I propose. > > at least, to you it appeared free (modulo hidden station problem) > > if it was not free earlier, then check the next hash. > > In the MACA (Multiple Access with Collision Avoidance) paper I wrote > *way* back in 1990, I argued that CSMA (carrier sense multiple access, > i.e., listen before transmit) is fundamentally broken. Yes, we are all > supposed to do it, but a) many don't and b) even if we did, it wouldn't > work very well because of poor propagation. > > But more fundamentally, you shouldn't even care if you transmit on top > of somebody! Interference occurs at receivers, not transmitters. You > really want to know who's *listening* on a channel, not who is > transmitting. That you can do by monitoring all the QSOs in the "band" > and inferring from them who is likely to be transmitting where during > the next time slot. This has the advantage of protecting transmissions > from stations you might not hear at all. In principle it also lets you > transmit on top of someone when you wouldn't interfere with that > station's intended receiver, but in practice this can fail because of > non-reciprocal propagation (e.g., high noise levels at one station, or > big differences in transmitter power.) > > It's analogous to monitoring an ordinary analog QSO and hearing the > station turn it over to someone else. Even if the channel then goes > silent to you, you know you shouldn't transmit. This will NOT prevent > all interference, but it sure can help. > > > Thus it goes from plain aloha to slotted aloha to some CSMA/CA. > > so channel capacity goes up. > Yes, that's another point. One of the earliest results in multiple > access analysis was the benefit of slotting. The spectrum/band should be > divided into slots in both time and frequency so that if you do > interfere, you'll only interfere with one. FT8 is already slotted in > time but it should also be slotted in frequency. > > > > Small change, and should be interoperable with existing software. > > so it does not force a mandated upgrade upon everyone. > > Pseudorandom per-transmission frequency hopping and frequency slotting > are completely interoperable with existing software as the receivers > already listen everywhere. As more people adopt the new transmission > algorithms, the overall throughput should increase due to reduced > collisions. > > I've been thinking a long time about the possible use of true frequency > hopping on HF. You'd use m-ARY FSK as in the JT modes but hop on every > symbol rather than just every transmission. This has some intriguing > advantages, such as being able to use the FEC to handle some number of > collisions with other stations. Obviously this would not be compatible > with any of the JT modes so it's a separate topic. > > Phil > > > _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
