bit stuffing in serial protocols

On Fri, 1 Apr 2016 20:30:26 -0700 (PDT), robert bristow-johnson
<rbj@audioimagination.com> wrote:

>On Friday, April 1, 2016 at 1:28:43 PM UTC-4, Eric Jacobsen wrote:
>> On Fri, 01 Apr 2016 19:45:18 +0300, Evgeny Filatov
>> <filatov.ev@mipt.ru> wrote:
>>=20
>> >On 01.04.2016 9:13, robert bristow-johnson wrote:
>> >
>> >(snip)
>> >
>> >> i've asked this before, but cannot find the post in our new, improved =
>Google Groups but i am still sorta obsessed with OQPSK thing because it see=
>ms beautifully natural to me.  i like engineering that is beautifully natur=
>al.
>> >
>> >(snip)
>> >
>> >> the IF quadrature vector is  i[n] + j*q[n]  and always transitions fro=
>m one quadrant to an adjacent quadrant during a single bit transition and n=
>ever to the opposite quadrant.  this is why i think Offset QPSK is so cool.=
>  it keeps the signal level up, like FM.
>> >
>> >Do you know a modulation more beautifully natural? Ternary PSK (TPSK).
>> >
>> >That's PSK with a constellation consisting of 3 possible states. The=20
>> >uncoded TPSK is superior to QPSK in terms of bit-error rate for the same=
>=20
>> >SNR (up to 0.75 dB gain without bandwidth expansion).
>> >
>> >Like in OQPSK, there are no transitions through zero in TPSK, but TPSK=
>=20
>> >does that without staggered bits. I've seen claims in the literature=20
>> >that TPSK is even more spectrally efficient than OQPSK.
>
>it's like an equilateral triangle constellation of symbols?
>
>> I'd never heard of that before.   Is that something you came up with?
>> Given that complexity is cheap these days, that might be something fun
>> to play with.
>
>i remember, when i was a student, talk of "multi-valued logic" and base-3 l=
>ogic was electrically simple with two MOSFETs connected between ground and =
>Vcc.  if both MOSFETs were "on", the output voltage would be halfway betwee=
>n Vcc and Gnd (or maybe it was both "off").  if one MOSFET was "on" and the=
> other "off, then the output voltage was either Vcc or Gnd.  3 symbols.
>
>must be an absolute copulating female canine to encode normal (binary) data=
> (the way God meant it to be) into such an abomination.  and back again.  s=
>orry Evgeny, my kinda "beautifully natural" is not a Rube Goldberg machine.
>
>base-4 multi-valued logic was supposed to be easier to convert to binary (i=
>t would be 2 bits per wire), but harder to do 4-level logic, electrically.
>
>all this was supposed to reduce pin count and the number of PCB-traces.  i =
>have never in my life seen any of this multi-valued logic stuff in any prod=
>uct.  i am sorta averse to really newfangled goofy shit like this.  guess i=
>t's the Luddite in me.
>
>i've also never heard of 3-state PSK.  but why not? :-)
>
>i can imagine this 3-state PSK thingie (essentially 3-QAM with an equilater=
>al triangle constellation) to do *differential* binary coding.  so you woul=
>dn't give a rat's ass which actual point you're at, the receiver only cares=
> if the movement of the quadrature IF vector is clockwise or counter-clockw=
>ise.  that sorta makes sense to me.  could be *real* clean and simple.  lik=
>e OQPSK, each movement of the IF vector corresponds to exactly one bit of d=
>ata.
>
>i think it's accurate to say that any QPSK or 4-QAM is simple 4-valued data=
> transmission (2 bits per symbol).  another reason why i think that *Offset=
>* QPSK is more beautiful than "regular" QPSK is that the serial stream does=
> not have to be divided up into "di-bit" symbols.  the new bit arrives from=
> the data stream just in time for the quadrature IF vector to know whether =
>it's going clockwise or counter-clockwise from its present position.
>
>> >> what does OQPSK (or regular QPSK) do for idle channel and for frame sy=
>nchronization?
>> >
>> >That is specified by the protocol, and there are numerous protocols.
>> >
>> >Frame synchronization is typically done with the use of an unique word=
>=20
>> >(specified by the protocol). One way to deal with spurious locks is that=
>=20
>> >frame synchronizer is actually a state machine.
>
>of course it is.  that's the way it frames up and decodes the data.  it has=
> to know whether it's an even bit time or an odd bit time.
>
>> > If it's already in lock=20
>> >it _expects_ to see the unique word at the start of the next frame, so=
>=20
>> >it would ignore the unique word if it occurs in the middle of the frame.
>
>it should do more than ignore it.  what if it ignores it and it doesn't see=
> the next frame sync when it expects to?  then it's "ooops, i guess that wa=
>s meant to be a frame sync."
>=20
>> >If locked frame synchronizer fails to see the unique word at the start=
>=20
>> >of the next frame it lowers its state and finally gets out of lock.
>
>what if it sees that unique word at the start of the next frame, but it was=
> out of lock?  how should it deal with the unique word?  what if it thinks =
>a possible version of a frame sync is just happenstance data in the middle =
>of the frame?

>> As mentioned, this is very system specific.   Robert, are you thinking
>> of a continuous stream system or a bursty system?
>
>both.  either.  whichever is worst case.  but even if the receiver *thinks*=
> it bursty, i think it should work with a forever continuous stream.  and v=
>ice-versa.  even with a forever continuous stream, there should be occasion=
>al frame syncs, just to keep everyone on the same page.

Not necessarily, because it takes up bandwidth and may do nothing but
complicate the system.  A system with a convolutional code that just
runs continuously would have to make an exception and suspend decoding
every time this annoying sync word showed up. It'd also have to know
how to distinguish the sync word from the rest of the bit stream.
There's really no benefit to a synch word in that sort of system.

For this reason the frame markers are sometimes done after decoding,
where they can be much shorter because they're protected from errors
by the FEC, and a binary instead of sampled symbols and therefore
simpler to detect.

>> For a continuous system the framing is often done after demodulation,
>> i.e., in the decoded bits, and is then independent of the modulation
>> and coding (FEC).
>
>but you don't necessarily have valid decoded bits after demodulation if the=
> synchronization wasn't right to start with.

If your demodulator is worth its salt you'll know whether it is
synchronized properly or not before you ever get the data bits, or,
better still, you won't be handed any demodulated bits unless they're
known to be from a synchronized condition.

>doesn't there have to be some unambiguous transmission, that if received wi=
>thout error, tells the receiver in no uncertain terms, that we're starting =
>a new frame?

Only if framing is required, which it often isn't.   And even if the
physical layer has framing, it may be independent from any framing
that it also in the data stream.

>>   Sometimes there are advantages to synchronizing
>> the coding, and in those cases Unique Word is usually used or some
>> like a modulated preamble to define a super frame and aid in initial
>> acquisition.
>>=20
>> For bursty systems the demodulator often has to fully synchronize
>> frequency, phase, and symbol timing from burst-to-burst, so the
>> preamble must contain features that facilitate all of those as well as
>> unambiguously mark the start of modulated data.
>
>that's what i am thinking.  i am thinking of a stream of data already happe=
>ning, and you turn on your receiver that has and *idea* of what f_c and f_d=
> are and will be totally useless until the first frame-sync ("preamble", th=
>at's the word for it, much better than "unique word") that it sees.  but wi=
>th OQPSK, when the receiver is turned on and listening to a solid f_c, it d=
>oesn't have any idea where the IF vector is pointing.  could be 00, 01, 11,=
> or 10.  the only way it can do that is have an unambiguous preamble that c=
>an never appear in the data.  and the only way i know of doing that is to d=
>o bit stuffing to prevent a combination of bits that happen to look like th=
>e preamble from being transmitted inside the data block of the frame.

That's rarely done at the physical layer.   Sometimes bit stuffing is
done just above the physical layer, but it is certainly possible to
build an OQPSK modem without it.

>> Sadly, the patterns you mention aren't very good for those tasks,
>
>why?  those two patterns are the only patterns that will detune the carrier=
> away from its center value to the maximum deviation.  it would seem to me =
>to be the easiest and cleanest to adapt a matched filter to.

Why do you want to move the carrier off center?   I don't see the
motivation.

Matched filters aren't normally "adapted", but are pre-set to be
compatible with the other end of the link.   If there is an adaptive
filter for equalization (and there often isn't), that is often done
separately from the matched filter, so that it only has to deal with
channel distortion.   This can be done "blind" from modulated data, or
with a unique word during a preamble or framing marker.   Using the
patterns you mention can make it difficult to maintain
synchronization.

>> but they are often used for testing.   They're a good way to detect
>> distortion like channel balance, phase balance, etc.
>
>for OQPSK, what is a good preamble?  like what would be a good bit pattern?=
>  and, without knowledge of phase sync, how does a receiver detect it (and =
>get all sync'd up)?  and if you don't do bit stuffing, like SDLC does to pr=
>event a faux preamble from transmission, how do you robustly keep the recei=
>ver from getting confused?

OQPSK is a bit of an odd duck because there is an interdependence
between phase and symbol timing that doesn't exist with QPSK.   That
being said, the most efficient preambles tend to be carefully selected
patterns (usually a Unique Word of some kind with good autocorrelation
properties) that provide good detection (i.e., good autocorrelation),
as well as good phase and timing synchronization properties.

Designing a good UW for a preamble and the demodulator algorithms to
reliably detect and synchronize it is sometimes difficult depending on
the expected channel impairments.   Sometimes the UW has to also train
the channel equalizer, if there is one.

>thanks Eric.  thanks Evgeny.
>
>r b-j


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On Fri, 1 Apr 2016 23:25:58 -0700 (PDT), robert bristow-johnson
<rbj@audioimagination.com> wrote:

>On Friday, April 1, 2016 at 11:45:28 PM UTC-4, Steve Pope wrote:
>> robert bristow-johnson  <rbj@audioimagination.com> wrote:
>>=20
>> >for OQPSK, what is a good preamble?  like what would be a good bit
>> >pattern?  and, without knowledge of phase sync, how does a receiver
>> >detect it (and get all sync'd up)? =20
>>=20
>> Some (many?) standards that employ OQPSK have an alternating zero-one
>> preamble pattern, i.e. 0101010101010101010101010101010101 ,
>
>wouldn't that be an idle pattern?

Idle patterns are pretty rare in wireless comm.   If you're idle, you
get off the channel to save power and perhaps let somebody else use
it.

If you have a continuous system that doesn't have traffic, idle
handling is done at a higher layer.   At the physical layer you
generally want high entropy to keep the synchronization working
efficiently (and, sometimes, keep the psd and papr low), so whitening
scramblers are used regardless of whether the data stream is idle or
not.

>> followed by
>> more of a traditional sync pattern with good distance properties.
>
>what would that be?  i dunno what others think a "traditional sync pattern =
>with good distance properties" is.  seems to me it should be 00110011001100=
>11 or 0110011001100110, which detune the instantaneous frequency the most.

Preambles, or sync words, or whatever you want to call them, have to
do several jobs, and which one is the most difficult in any given
system may drive certain properties of the UW (sync word).

If detection is critical and the system allows it, starting with a
chunk of CW is hard to beat.   Some systems don't tolerate CWs for a
variety of reasons, and they take up bandwidth that can't be used for
timing or channel estimation, because CWs are not good at those tasks.

It used to be pretty common to start a preamble with a CW, but it is
getting rarer these days, partly because complexity is cheaper so
gnarly algorithms can be applied to get the same function with a
shorter preamble.

The point of that is just that, like most things, what makes the best
sync pattern depends on the system requirements.

And OQPSK doesn't really do CW, but it was just an example of the
tradeoffs.

>> The advantage of this is that it does, in fact, establish an
>> absolute phase reference point, as the carrier phase is simply slewing
>> back and forth between 0 and pi/2.
>
>sure, you get a lock on f_c, but you have no idea whether it's 01010101... =
>or 10101010... or 11111111... or 00000000...  all of those patterns will gi=
>ve you the same solid sinusoid at f_c (but with different phase, relative t=
>o the transmitter clock, which is not known by the receiver, the receiver h=
>as to derive it and cannot from any of those four patterns).  i can see any=
> one of these as an idle pattern, but i *really* don't see how that is usef=
>ul at all for a preamble which should, besides telling you that a frame of =
>data is about to come your way, tells you how to sync up to the whole thing=
>.  how can you possibly get the quadrature IF vector pointing in the right =
>direction with such a preamble if your reference to phase was ambiguous bef=
>ore?  seems to me you need 0011001100110011... or 0110011001100110... in or=
>der to do that.
>
>> The disadvantages are I think fairly obvious. (And I'm on warning
>> not to post obvious stuff here...)
>
>well, dunno what the obvious disadvantages are, because i don't see *any* a=
>dvantages.

In busy systems bandwidth and efficiency are important, so using sync
words that are longer or more frequent than necessary just decrease
efficiency and you get you in trouble with either management or the
customer or the shareholders or all of the above.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Eric Jacobsen <eric.jacobsen@ieee.org> wrote:

>Idle patterns are pretty rare in wireless comm.   If you're idle, you
>get off the channel to save power and perhaps let somebody else use
>it.

This is only when you're not practicing traffic flow security.
(One would think that after Snowden / Apple / FBI etc. one would
re-think this security gap.)

I once used the SDLC bit-stuffing protocol specifically so that,
after encryption, there is no way to distinguish between an
idle channel and a packet.  Either way it is a stream of random bits.

Steve

On Sat, 02 Apr 2016 22:35:26 +0000, Eric Jacobsen wrote:

> On 02 Apr 2016 11:18:27 GMT, Allan Herriman <allanherriman@hotmail.com>
> wrote:
> 
>>On Sat, 02 Apr 2016 12:21:43 +0300, Evgeny Filatov wrote:
>>
>>> On 01.04.2016 23:01, Eric Jacobsen wrote:
>>> (snip)
>>> 
>>>> I was trying to sort out how to map the constellation, since there
>>>> isn't a power-of-two number of points.   Even mapping across multiple
>>>> symbols isn't straightforward, since 3 doesn't go into 2^N evenly for
>>>> practical N.
>>> 
>>> Some simple choices to map binary to ternary words (with some ternary
>>> words left unused) could be 2^11 into 3^7 (losing 0.3 dB), or 2^19
>>> into 3^12 (losing 0.06 dB), or 2^84 into 3^53 (losing 0.009 dB), or
>>> 2^659 into 3^359 (losing 0.0046 dB), or 2^1054 into 3^665 (losing
>>> 0.0002 dB).
>>> Mapping could be done by simple division. But that would have bad
>>> implications for error propagation, i.e. a single error in a 3-tuple
>>> would (on average) corrupt half of a binary word.
>>
>>
>>4B3T, which maps 4 bits into 3 ternary symbols, was (still is?) used for
>>basic rate ISDN (144kb/s useful data rate on phone lines) in Europe.
>>This is baseband signalling, and some of the redundancy was used to
>>create a null at DC, and some was used for framing.
>>
>>2B1Q (2 bits mapping to 4 levels) was (is?) used for basic rate ISDN
>>outside Europe.
>>There was no null at DC.
>>
>>Basic rate ISDN is transformer coupled.  I vaguely recall designing a
>>transformer for this a long time ago, and the design was much more
>>difficult for 2B1Q because of the low frequency response needed.
>>
>>2B1Q gave better reach because of the lower symbol rate though.
>>
>>Regards,
>>Allan
> 
> Aw, somebody actually built it as part of standard?   It's much less
> interesting now.  ;)


Specifically (*) ITU-T G.961.  Appendix I describes 4B3T and Appendix II 
describes 2B1Q.  Published in 1993 and still in force.

Lurkers may be interested in the 4B3T code table in FIGURE I.1/G.961.

Download:
https://www.itu.int/rec/T-REC-G.961-199303-I/en


(*) sorry about the pun.

Regards,
Allan

On 03.04.2016 0:03, Evgeny Filatov wrote:

(snip)

> Differential modulation doesn't mean that you must move anywhere each
> time you transmit a symbol (although that's a somewhat popular
> misconception). It only means you are transmitting the _difference_
> between two succeeding original symbols you had. The same difference
> twice in a row is legit (like 0-1=1, then 1-0=1 in D-BPSK). If you make
> it forbidden in your system, perhaps you are losing capacity.

Apologies! Precisely the opposite is true -- in differential encoding 
the information symbol determines the change in the transmitted symbol. 
Still it's a legit event if the transmitted symbol remains the same for 
a while (and I do hope you do not rely on my words to implement a real 
system).

Evgeny

On 03.04.2016 15:33, Evgeny Filatov wrote:
> On 03.04.2016 0:03, Evgeny Filatov wrote:
>
> (snip)
>
>> Differential modulation doesn't mean that you must move anywhere each
>> time you transmit a symbol (although that's a somewhat popular
>> misconception). It only means you are transmitting the _difference_
>> between two succeeding original symbols you had. The same difference
>> twice in a row is legit (like 0-1=1, then 1-0=1 in D-BPSK). If you make
>> it forbidden in your system, perhaps you are losing capacity.
>
> Apologies! Precisely the opposite is true -- in differential encoding
> the information symbol determines the change in the transmitted symbol.
> Still it's a legit event if the transmitted symbol remains the same for
> a while (and I do hope you do not rely on my words to implement a real
> system).
>
> Evgeny
>

As they said in Edda (Hovamol, 5),

"Wits must he have | who wanders wide,
But all is easy at home;
At the witless man | the wise shall wink
When among such men he sits."

Evgeny

On Sun, 3 Apr 2016 00:47:44 +0000 (UTC), spope33@speedymail.org (Steve
Pope) wrote:

>Eric Jacobsen <eric.jacobsen@ieee.org> wrote:
>
>>Idle patterns are pretty rare in wireless comm.   If you're idle, you
>>get off the channel to save power and perhaps let somebody else use
>>it.
>
>This is only when you're not practicing traffic flow security.
>(One would think that after Snowden / Apple / FBI etc. one would
>re-think this security gap.)

Or when you're observing government regulations, or saving power, or
keeping your network efficient, or...

>I once used the SDLC bit-stuffing protocol specifically so that,
>after encryption, there is no way to distinguish between an
>idle channel and a packet.  Either way it is a stream of random bits.
>
>Steve

Part of my point was that "idle channel" often means something
different or has very different implications at the bottom of the
physical layer than it does at its output.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

On Saturday, April 2, 2016 at 6:53:39 PM UTC-4, Eric Jacobsen wrote:
> On Fri, 1 Apr 2016 20:30:26 -0700 (PDT), robert bristow-johnson
> <rbj@audioimagination.com> wrote:
> 
> >On Friday, April 1, 2016 at 1:28:43 PM UTC-4, Eric Jacobsen wrote:
> >> As mentioned, this is very system specific.   Robert, are you thinking
> >> of a continuous stream system or a bursty system?
> >
> >both.  either.  whichever is worst case.  but even if the receiver *thinks*=
> > it bursty, i think it should work with a forever continuous stream.  and 
> >vice-versa.  even with a forever continuous stream, there should be occasional
> >frame syncs, just to keep everyone on the same page.
> 
> Not necessarily, because it takes up bandwidth and may do nothing but
> complicate the system.  A system with a convolutional code that just
> runs continuously would have to make an exception and suspend decoding
> every time this annoying sync word showed up. It'd also have to know
> how to distinguish the sync word from the rest of the bit stream.
> There's really no benefit to a synch word in that sort of system.
> 
> For this reason the frame markers are sometimes done after decoding,
> where they can be much shorter because they're protected from errors
> by the FEC, and a binary instead of sampled symbols and therefore
> simpler to detect.
> 
> >> For a continuous system the framing is often done after demodulation,
> >> i.e., in the decoded bits, and is then independent of the modulation
> >> and coding (FEC).
> >
> >but you don't necessarily have valid decoded bits after demodulation if the=
> > synchronization wasn't right to start with.
> 
> If your demodulator is worth its salt you'll know whether it is
> synchronized properly or not before you ever get the data bits, or,
> better still, you won't be handed any demodulated bits unless they're
> known to be from a synchronized condition.

but this is begging the question.  or at least *i* am begging the question.

what if synchronization is lost, you have a good idea what the carrier frequency is (f_c) and a good idea what the bit rate is (f_d), but you have *no* idea in what direction the IQ vector is pointing and you want to *both* get into synchronization *and* mark the beginning of a data frame with a single preamble word.  what do you do?  how do you do that?

> >doesn't there have to be some unambiguous transmission, that if received wi=
> >thout error, tells the receiver in no uncertain terms, that we're starting =
> >a new frame?
> 
> Only if framing is required, which it often isn't.   And even if the
> physical layer has framing, it may be independent from any framing
> that it also in the data stream.

seems to me that if you want to kill both birds with a single stone, if you can.  seems to me that if you can transmit a short segment of signal that will establish exactly when "things" are beginning, that's what you wanna do.

> 
> >>   Sometimes there are advantages to synchronizing
> >> the coding, and in those cases Unique Word is usually used or some
> >> like a modulated preamble to define a super frame and aid in initial
> >> acquisition.
> >>=20
> >> For bursty systems the demodulator often has to fully synchronize
> >> frequency, phase, and symbol timing from burst-to-burst, so the
> >> preamble must contain features that facilitate all of those as well as
> >> unambiguously mark the start of modulated data.
> >
> >that's what i am thinking.  i am thinking of a stream of data already happe=
> >ning, and you turn on your receiver that has and *idea* of what f_c and f_d=
> > are and will be totally useless until the first frame-sync ("preamble", th=
> >at's the word for it, much better than "unique word") that it sees.  but wi=
> >th OQPSK, when the receiver is turned on and listening to a solid f_c, it d=
> >oesn't have any idea where the IF vector is pointing.  could be 00, 01, 11,=
> > or 10.  the only way it can do that is have an unambiguous preamble that c=
> >an never appear in the data.  and the only way i know of doing that is to d=
> >o bit stuffing to prevent a combination of bits that happen to look like th=
> >e preamble from being transmitted inside the data block of the frame.
> 
> That's rarely done at the physical layer.   Sometimes bit stuffing is
> done just above the physical layer, but it is certainly possible to
> build an OQPSK modem without it.
> 
> >> Sadly, the patterns you mention aren't very good for those tasks,
> >
> >why?  those two patterns are the only patterns that will detune the carrier=
> > away from its center value to the maximum deviation.  it would seem to me =
> >to be the easiest and cleanest to adapt a matched filter to.
> 
> Why do you want to move the carrier off center?   I don't see the
> motivation.

the motivation is that it establishes exactly where the IQ (or "IF") vector should be pointing at the very end of the preamble.  and if the preamble is a "unique word", then it never happens in the data stream.  but the only way to guarantee it never happens in the data stream is to stuff in a bit (or maybe two, since this is a form of 4-QAM) when it appears that unique word is about to be sent out.


> Matched filters aren't normally "adapted", but are pre-set to be
> compatible with the other end of the link.

yes, i meant a matched filter to be "adapted" or "designed" to light up when the "Unique Word" happens to show it's happy face in the signal.

>   If there is an adaptive
> filter for equalization (and there often isn't), that is often done
> separately from the matched filter, so that it only has to deal with
> channel distortion.   This can be done "blind" from modulated data, or
> with a unique word during a preamble or framing marker.   Using the
> patterns you mention can make it difficult to maintain
> synchronization.

"adapted" was the wrong word.  "designed" is a better word.

> 
> >> but they are often used for testing.   They're a good way to detect
> >> distortion like channel balance, phase balance, etc.
> >
> >for OQPSK, what is a good preamble?  like what would be a good bit pattern?=
> >  and, without knowledge of phase sync, how does a receiver detect it (and =
> >get all sync'd up)?  and if you don't do bit stuffing, like SDLC does to pr=
> >event a faux preamble from transmission, how do you robustly keep the recei=
> >ver from getting confused?
> 
> OQPSK is a bit of an odd duck because there is an interdependence
> between phase and symbol timing that doesn't exist with QPSK.

but with QPSK (or 4-QAM, i think they're the same) you still need synchronization.  otherwise you don't know what direction the IQ vector is pointing.

>   That
> being said, the most efficient preambles tend to be carefully selected
> patterns (usually a Unique Word of some kind with good autocorrelation
> properties) that provide good detection (i.e., good autocorrelation),
> as well as good phase and timing synchronization properties.

i can see that if it wasn't quadrature.  if it was BPSK, i could see just waiting for the Unique Word to appear and sync up. (and i would think we would bit-stuff to prevent that Unique Word from ever appearing happenstance in the data and causing spurious syncing.)  but BPSK is half the bit rate that QPSK is.  with QPSK, it's like you have an FM detector and you have to take the output of the FM detector and integrate it to get PM.  but there is the initial state of the integrator to set up correctly and that's where the frame syncing comes in.  and extreme frequencies that happen in OQPSK with the 00110011 or with 01100110 is unambiguous to an FM detector.

> Designing a good UW for a preamble and the demodulator algorithms to
> reliably detect and synchronize it is sometimes difficult depending on
> the expected channel impairments.   Sometimes the UW has to also train
> the channel equalizer, if there is one.

thanks Eric.  i hope you can continue to tolerate pedantacy from me.  unlike the "circular DFT" arguments we have had in the past, i am fully aware that i don't really know squat about this.  but, with OQPSK (at the "physical layer") i think i can construct what it looks like in the frequency domain when the IQ vector does not move (which would be 00000000, 11111111, 01010101, or 10101010) and when it moves consistently clockwise (00110011) or counter-clockwise (01100110) which is the maximum detuning of the carrier.  (referring to the constellation at https://en.wikipedia.org/wiki/Phase-shift_keying#/media/File:Pi-by-O-QPSK_Gray_Coded.svg )  if you don't have a phase lock, all you know is frequency.  then, the only preamble that i understand that will be detected unambiguously is one of those two extremes.

do you understand what my point is (and where it's messed up)?

r b-j

robert bristow-johnson  <rbj@audioimagination.com> wrote:

>On Saturday, April 2, 2016 at 6:53:39 PM UTC-4, Eric Jacobsen wrote:

>> Why do you want to move the carrier off center?   I don't see the
>> motivation.

>the motivation is that it establishes exactly where the IQ (or "IF")
>vector should be pointing at the very end of the preamble.  and if the
>preamble is a "unique word", then it never happens in the data stream. 
>but the only way to guarantee it never happens in the data stream is to
>stuff in a bit (or maybe two, since this is a form of 4-QAM) when it
>appears that unique word is about to be sent out.

Or you could introduce a bit-error into the raw transmitted data
stream should it otherwise be emitting the synch pattern when
it shouldn't.  (Done in, at least, the DVD standard and I'm
sure many other places.)

Steve

On Friday, April 1, 2016 at 12:45:37 PM UTC-4, Evgeny Filatov wrote:
> On 01.04.2016 9:13, robert bristow-johnson wrote:
> 
> (snip)
> 
> > i've asked this before, but cannot find the post in our new, improved Google Groups but i am still sorta obsessed with OQPSK thing because it seems beautifully natural to me.  i like engineering that is beautifully natural.
> 
> (snip)
> 
> > the IF quadrature vector is  i[n] + j*q[n]  and always transitions from one quadrant to an adjacent quadrant during a single bit transition and never to the opposite quadrant.  this is why i think Offset QPSK is so cool.  it keeps the signal level up, like FM.
> 
> Do you know a modulation more beautifully natural? Ternary PSK (TPSK).
> 
> That's PSK with a constellation consisting of 3 possible states. The 
> uncoded TPSK is superior to QPSK in terms of bit-error rate for the same 
> SNR (up to 0.75 dB gain without bandwidth expansion).
> 
> Like in OQPSK, there are no transitions through zero in TPSK, but TPSK 
> does that without staggered bits. I've seen claims in the literature 
> that TPSK is even more spectrally efficient than OQPSK.
> 
> (snip)
> 
> > what does OQPSK (or regular QPSK) do for idle channel and for frame synchronization?
> 
> That is specified by the protocol, and there are numerous protocols.
> 
> Frame synchronization is typically done with the use of an unique word 
> (specified by the protocol). One way to deal with spurious locks is that 
> frame synchronizer is actually a state machine. If it's already in lock 
> it _expects_ to see the unique word at the start of the next frame, so 
> it would ignore the unique word if it occurs in the middle of the frame. 
> If locked frame synchronizer fails to see the unique word at the start 
> of the next frame it lowers its state and finally gets out of lock.
> 
> Evgeny

A ternary modulation is tempting in that there is a ternary Golay code (perfect code)! The ternary Golay code was invented before Golay's discovery to hedge bets in a football pool.

Clay