TE
Tofurk Ei
Sun, Jul 8, 2012 4:10 PM
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a DVB-T
dongle/upconverter combo could almost certainly handle PM easily to output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of doing
this kind of thing, one builds a "flow graph" where the actual demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost certain that
gnuradio might be quite useful to rapidly design a tool to demodulate it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of this
combination in any other manner. If I were interested in trying this I
would join the gnuradio mailing list and ask there. Perhaps the answer is
surprisingly simple.
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a DVB-T
dongle/upconverter combo could almost certainly handle PM easily to output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of doing
this kind of thing, one builds a "flow graph" where the actual demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost certain that
gnuradio might be quite useful to rapidly design a tool to demodulate it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of this
combination in any other manner. If I were interested in trying this I
would join the gnuradio mailing list and ask there. Perhaps the answer is
surprisingly simple.
P
paul
Sun, Jul 8, 2012 4:56 PM
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a DVB-T
dongle/upconverter combo could almost certainly handle PM easily to output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of doing
this kind of thing, one builds a "flow graph" where the actual demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost certain that
gnuradio might be quite useful to rapidly design a tool to demodulate it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of this
combination in any other manner. If I were interested in trying this I
would join the gnuradio mailing list and ask there. Perhaps the answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
> If the changeover you are talking about is this one:
> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a DVB-T
> dongle/upconverter combo could almost certainly handle PM easily to output
> whatever it encodes, when paired with gnuradio..
>
> The RTL2832U chip might also be able to handle some low band signals
> directly, using direct sampling. No upconverter.
>
> Regardless, then the data would be fed into gnuradio - the gnuradio
> developers GUI is called "gnuradio companion" It has a nifty way of doing
> this kind of thing, one builds a "flow graph" where the actual demodulation
> is simply laid out graphically and tested.
>
> When everything works to one's satisfaction the file is saved and it gets
> compiled - then it can run - its basically a python script.
>
> If the modulation scheme is public, I think you can be almost certain that
> gnuradio might be quite useful to rapidly design a tool to demodulate it.
> Perhaps very quickly.
>
> For the money, one really couldn't hope to beat the flexibility of this
> combination in any other manner. If I were interested in trying this I
> would join the gnuradio mailing list and ask there. Perhaps the answer is
> surprisingly simple.
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
PG
Peter Gottlieb
Sun, Jul 8, 2012 10:40 PM
Any possibility of using the decoded signal to un-do the modulation and
feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
DVB-T
dongle/upconverter combo could almost certainly handle PM easily to
output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of
doing
this kind of thing, one builds a "flow graph" where the actual
demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it
gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost certain
that
gnuradio might be quite useful to rapidly design a tool to demodulate
it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of this
combination in any other manner. If I were interested in trying this I
would join the gnuradio mailing list and ask there. Perhaps the
answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Any possibility of using the decoded signal to un-do the modulation and
feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
> Ei
> Sorry if I have your name reversed. By taking this approach it
> eliminates the ability to use wwvb as a frequency reference because it
> destroys that traceability.
> Thats what we are trying to preserve. Or at least re-establish for the
> older phase measuring receivers.
> Regards
> Paul
>
> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>> If the changeover you are talking about is this one:
>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
>> DVB-T
>> dongle/upconverter combo could almost certainly handle PM easily to
>> output
>> whatever it encodes, when paired with gnuradio..
>>
>> The RTL2832U chip might also be able to handle some low band signals
>> directly, using direct sampling. No upconverter.
>>
>> Regardless, then the data would be fed into gnuradio - the gnuradio
>> developers GUI is called "gnuradio companion" It has a nifty way of
>> doing
>> this kind of thing, one builds a "flow graph" where the actual
>> demodulation
>> is simply laid out graphically and tested.
>>
>> When everything works to one's satisfaction the file is saved and it
>> gets
>> compiled - then it can run - its basically a python script.
>>
>> If the modulation scheme is public, I think you can be almost certain
>> that
>> gnuradio might be quite useful to rapidly design a tool to demodulate
>> it.
>> Perhaps very quickly.
>>
>> For the money, one really couldn't hope to beat the flexibility of this
>> combination in any other manner. If I were interested in trying this I
>> would join the gnuradio mailing list and ask there. Perhaps the
>> answer is
>> surprisingly simple.
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
P
paul
Sun, Jul 8, 2012 10:46 PM
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
Regards
Paul.
On 7/8/2012 6:40 PM, Peter Gottlieb wrote:
Any possibility of using the decoded signal to un-do the modulation
and feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because
it destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for
the older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
DVB-T
dongle/upconverter combo could almost certainly handle PM easily to
output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of
doing
this kind of thing, one builds a "flow graph" where the actual
demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it
gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost
certain that
gnuradio might be quite useful to rapidly design a tool to
demodulate it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of this
combination in any other manner. If I were interested in trying this I
would join the gnuradio mailing list and ask there. Perhaps the
answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
Regards
Paul.
On 7/8/2012 6:40 PM, Peter Gottlieb wrote:
> Any possibility of using the decoded signal to un-do the modulation
> and feed the reconstituted signal to the older receiver?
>
>
>
> On 7/8/2012 12:56 PM, paul wrote:
>> Ei
>> Sorry if I have your name reversed. By taking this approach it
>> eliminates the ability to use wwvb as a frequency reference because
>> it destroys that traceability.
>> Thats what we are trying to preserve. Or at least re-establish for
>> the older phase measuring receivers.
>> Regards
>> Paul
>>
>> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>>> If the changeover you are talking about is this one:
>>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
>>> DVB-T
>>> dongle/upconverter combo could almost certainly handle PM easily to
>>> output
>>> whatever it encodes, when paired with gnuradio..
>>>
>>> The RTL2832U chip might also be able to handle some low band signals
>>> directly, using direct sampling. No upconverter.
>>>
>>> Regardless, then the data would be fed into gnuradio - the gnuradio
>>> developers GUI is called "gnuradio companion" It has a nifty way of
>>> doing
>>> this kind of thing, one builds a "flow graph" where the actual
>>> demodulation
>>> is simply laid out graphically and tested.
>>>
>>> When everything works to one's satisfaction the file is saved and it
>>> gets
>>> compiled - then it can run - its basically a python script.
>>>
>>> If the modulation scheme is public, I think you can be almost
>>> certain that
>>> gnuradio might be quite useful to rapidly design a tool to
>>> demodulate it.
>>> Perhaps very quickly.
>>>
>>> For the money, one really couldn't hope to beat the flexibility of this
>>> combination in any other manner. If I were interested in trying this I
>>> would join the gnuradio mailing list and ask there. Perhaps the
>>> answer is
>>> surprisingly simple.
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
JF
J. Forster
Sun, Jul 8, 2012 10:58 PM
Hi Peter,
That's be the hard way, but yes, if the message BPSK coded is computable
and of a known format. If the message contained more than time, like solar
flux, it gets more complicated very rapidly.
A similar thing was done with the Equatorial system 30+ years ago. In that
case, each data bit was broken into something like 32 or 64 chips (I don't
remember). There were two maximally distant, orthogonal chip patterns,
representing 1 and 0. The incoming BPSK message went through a 0 or 180
degree switch, then the IF stages. The switch was driven from a local
(known pattern) chip generator, so that if everything was synced up the
narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
trick vastly improved the system S/N becaust it narrowed the receiver IF
bandwidth many times.
If the chip pattern is not known (fixed) or computable (like a correct
TOD) things go to pot quickly.
Rather than building such a kludge, it would be easier to use the locked
clock in a newly designed receiver and phase compare that to your local
standard directly.
-John
==================
Any possibility of using the decoded signal to un-do the modulation and
feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
DVB-T
dongle/upconverter combo could almost certainly handle PM easily to
output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of
doing
this kind of thing, one builds a "flow graph" where the actual
demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it
gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost certain
that
gnuradio might be quite useful to rapidly design a tool to demodulate
it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of this
combination in any other manner. If I were interested in trying this I
would join the gnuradio mailing list and ask there. Perhaps the
answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi Peter,
That's be the hard way, but yes, if the message BPSK coded is computable
and of a known format. If the message contained more than time, like solar
flux, it gets more complicated very rapidly.
A similar thing was done with the Equatorial system 30+ years ago. In that
case, each data bit was broken into something like 32 or 64 chips (I don't
remember). There were two maximally distant, orthogonal chip patterns,
representing 1 and 0. The incoming BPSK message went through a 0 or 180
degree switch, then the IF stages. The switch was driven from a local
(known pattern) chip generator, so that if everything was synced up the
narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
trick vastly improved the system S/N becaust it narrowed the receiver IF
bandwidth many times.
If the chip pattern is not known (fixed) or computable (like a correct
TOD) things go to pot quickly.
Rather than building such a kludge, it would be easier to use the locked
clock in a newly designed receiver and phase compare that to your local
standard directly.
-John
==================
> Any possibility of using the decoded signal to un-do the modulation and
> feed the reconstituted signal to the older receiver?
>
>
>
> On 7/8/2012 12:56 PM, paul wrote:
>> Ei
>> Sorry if I have your name reversed. By taking this approach it
>> eliminates the ability to use wwvb as a frequency reference because it
>> destroys that traceability.
>> Thats what we are trying to preserve. Or at least re-establish for the
>> older phase measuring receivers.
>> Regards
>> Paul
>>
>> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>>> If the changeover you are talking about is this one:
>>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
>>> DVB-T
>>> dongle/upconverter combo could almost certainly handle PM easily to
>>> output
>>> whatever it encodes, when paired with gnuradio..
>>>
>>> The RTL2832U chip might also be able to handle some low band signals
>>> directly, using direct sampling. No upconverter.
>>>
>>> Regardless, then the data would be fed into gnuradio - the gnuradio
>>> developers GUI is called "gnuradio companion" It has a nifty way of
>>> doing
>>> this kind of thing, one builds a "flow graph" where the actual
>>> demodulation
>>> is simply laid out graphically and tested.
>>>
>>> When everything works to one's satisfaction the file is saved and it
>>> gets
>>> compiled - then it can run - its basically a python script.
>>>
>>> If the modulation scheme is public, I think you can be almost certain
>>> that
>>> gnuradio might be quite useful to rapidly design a tool to demodulate
>>> it.
>>> Perhaps very quickly.
>>>
>>> For the money, one really couldn't hope to beat the flexibility of this
>>> combination in any other manner. If I were interested in trying this I
>>> would join the gnuradio mailing list and ask there. Perhaps the
>>> answer is
>>> surprisingly simple.
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
BC
Bob Camp
Sun, Jul 8, 2012 11:11 PM
Hi
In this case the data format and it's contents are highly "computable". If you have a good local clock and an initial lock, the rest of what follows is predictable. That of course assumes we know the real format ….
Bob
On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
Hi Peter,
That's be the hard way, but yes, if the message BPSK coded is computable
and of a known format. If the message contained more than time, like solar
flux, it gets more complicated very rapidly.
A similar thing was done with the Equatorial system 30+ years ago. In that
case, each data bit was broken into something like 32 or 64 chips (I don't
remember). There were two maximally distant, orthogonal chip patterns,
representing 1 and 0. The incoming BPSK message went through a 0 or 180
degree switch, then the IF stages. The switch was driven from a local
(known pattern) chip generator, so that if everything was synced up the
narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
trick vastly improved the system S/N becaust it narrowed the receiver IF
bandwidth many times.
If the chip pattern is not known (fixed) or computable (like a correct
TOD) things go to pot quickly.
Rather than building such a kludge, it would be easier to use the locked
clock in a newly designed receiver and phase compare that to your local
standard directly.
-John
==================
Any possibility of using the decoded signal to un-do the modulation and
feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
DVB-T
dongle/upconverter combo could almost certainly handle PM easily to
output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of
doing
this kind of thing, one builds a "flow graph" where the actual
demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it
gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost certain
that
gnuradio might be quite useful to rapidly design a tool to demodulate
it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of this
combination in any other manner. If I were interested in trying this I
would join the gnuradio mailing list and ask there. Perhaps the
answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
In this case the data format and it's contents are highly "computable". If you have a good local clock *and* an initial lock, the rest of what follows is predictable. That of course assumes we know the real format ….
Bob
On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
> Hi Peter,
>
> That's be the hard way, but yes, if the message BPSK coded is computable
> and of a known format. If the message contained more than time, like solar
> flux, it gets more complicated very rapidly.
>
> A similar thing was done with the Equatorial system 30+ years ago. In that
> case, each data bit was broken into something like 32 or 64 chips (I don't
> remember). There were two maximally distant, orthogonal chip patterns,
> representing 1 and 0. The incoming BPSK message went through a 0 or 180
> degree switch, then the IF stages. The switch was driven from a local
> (known pattern) chip generator, so that if everything was synced up the
> narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
> trick vastly improved the system S/N becaust it narrowed the receiver IF
> bandwidth many times.
>
> If the chip pattern is not known (fixed) or computable (like a correct
> TOD) things go to pot quickly.
>
> Rather than building such a kludge, it would be easier to use the locked
> clock in a newly designed receiver and phase compare that to your local
> standard directly.
>
> -John
>
> ==================
>
>
>
>
>
>
>> Any possibility of using the decoded signal to un-do the modulation and
>> feed the reconstituted signal to the older receiver?
>>
>>
>>
>> On 7/8/2012 12:56 PM, paul wrote:
>>> Ei
>>> Sorry if I have your name reversed. By taking this approach it
>>> eliminates the ability to use wwvb as a frequency reference because it
>>> destroys that traceability.
>>> Thats what we are trying to preserve. Or at least re-establish for the
>>> older phase measuring receivers.
>>> Regards
>>> Paul
>>>
>>> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>>>> If the changeover you are talking about is this one:
>>>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
>>>> DVB-T
>>>> dongle/upconverter combo could almost certainly handle PM easily to
>>>> output
>>>> whatever it encodes, when paired with gnuradio..
>>>>
>>>> The RTL2832U chip might also be able to handle some low band signals
>>>> directly, using direct sampling. No upconverter.
>>>>
>>>> Regardless, then the data would be fed into gnuradio - the gnuradio
>>>> developers GUI is called "gnuradio companion" It has a nifty way of
>>>> doing
>>>> this kind of thing, one builds a "flow graph" where the actual
>>>> demodulation
>>>> is simply laid out graphically and tested.
>>>>
>>>> When everything works to one's satisfaction the file is saved and it
>>>> gets
>>>> compiled - then it can run - its basically a python script.
>>>>
>>>> If the modulation scheme is public, I think you can be almost certain
>>>> that
>>>> gnuradio might be quite useful to rapidly design a tool to demodulate
>>>> it.
>>>> Perhaps very quickly.
>>>>
>>>> For the money, one really couldn't hope to beat the flexibility of this
>>>> combination in any other manner. If I were interested in trying this I
>>>> would join the gnuradio mailing list and ask there. Perhaps the
>>>> answer is
>>>> surprisingly simple.
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts@febo.com
>>>> To unsubscribe, go to
>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>>
>>>
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
JF
J. Forster
Sun, Jul 8, 2012 11:29 PM
A risky assumption, and a cold start could be tricky.
Equatorial took many minutes to lock up, with a much higher data rate, and
it did it by slowly sweeping the local clock.
Aside: That's why military spread spectrum systems like good local clocks.
They lock up a whole lot faster that way.
-John
================
Hi
In this case the data format and it's contents are highly "computable". If
you have a good local clock and an initial lock, the rest of what
follows is predictable. That of course assumes we know the real format
.
Bob
On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
Hi Peter,
That's be the hard way, but yes, if the message BPSK coded is computable
and of a known format. If the message contained more than time, like
solar
flux, it gets more complicated very rapidly.
A similar thing was done with the Equatorial system 30+ years ago. In
that
case, each data bit was broken into something like 32 or 64 chips (I
don't
remember). There were two maximally distant, orthogonal chip patterns,
representing 1 and 0. The incoming BPSK message went through a 0 or 180
degree switch, then the IF stages. The switch was driven from a local
(known pattern) chip generator, so that if everything was synced up the
narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
trick vastly improved the system S/N becaust it narrowed the receiver IF
bandwidth many times.
If the chip pattern is not known (fixed) or computable (like a correct
TOD) things go to pot quickly.
Rather than building such a kludge, it would be easier to use the locked
clock in a newly designed receiver and phase compare that to your local
standard directly.
-John
==================
Any possibility of using the decoded signal to un-do the modulation and
feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
DVB-T
dongle/upconverter combo could almost certainly handle PM easily to
output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of
doing
this kind of thing, one builds a "flow graph" where the actual
demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it
gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost certain
that
gnuradio might be quite useful to rapidly design a tool to demodulate
it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of
this
combination in any other manner. If I were interested in trying this
I
would join the gnuradio mailing list and ask there. Perhaps the
answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
A risky assumption, and a cold start could be tricky.
Equatorial took many minutes to lock up, with a much higher data rate, and
it did it by slowly sweeping the local clock.
Aside: That's why military spread spectrum systems like good local clocks.
They lock up a whole lot faster that way.
-John
================
> Hi
>
> In this case the data format and it's contents are highly "computable". If
> you have a good local clock *and* an initial lock, the rest of what
> follows is predictable. That of course assumes we know the real format
.
>
> Bob
>
> On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
>
>> Hi Peter,
>>
>> That's be the hard way, but yes, if the message BPSK coded is computable
>> and of a known format. If the message contained more than time, like
>> solar
>> flux, it gets more complicated very rapidly.
>>
>> A similar thing was done with the Equatorial system 30+ years ago. In
>> that
>> case, each data bit was broken into something like 32 or 64 chips (I
>> don't
>> remember). There were two maximally distant, orthogonal chip patterns,
>> representing 1 and 0. The incoming BPSK message went through a 0 or 180
>> degree switch, then the IF stages. The switch was driven from a local
>> (known pattern) chip generator, so that if everything was synced up the
>> narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
>> trick vastly improved the system S/N becaust it narrowed the receiver IF
>> bandwidth many times.
>>
>> If the chip pattern is not known (fixed) or computable (like a correct
>> TOD) things go to pot quickly.
>>
>> Rather than building such a kludge, it would be easier to use the locked
>> clock in a newly designed receiver and phase compare that to your local
>> standard directly.
>>
>> -John
>>
>> ==================
>>
>>
>>
>>
>>
>>
>>> Any possibility of using the decoded signal to un-do the modulation and
>>> feed the reconstituted signal to the older receiver?
>>>
>>>
>>>
>>> On 7/8/2012 12:56 PM, paul wrote:
>>>> Ei
>>>> Sorry if I have your name reversed. By taking this approach it
>>>> eliminates the ability to use wwvb as a frequency reference because it
>>>> destroys that traceability.
>>>> Thats what we are trying to preserve. Or at least re-establish for the
>>>> older phase measuring receivers.
>>>> Regards
>>>> Paul
>>>>
>>>> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>>>>> If the changeover you are talking about is this one:
>>>>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
>>>>> DVB-T
>>>>> dongle/upconverter combo could almost certainly handle PM easily to
>>>>> output
>>>>> whatever it encodes, when paired with gnuradio..
>>>>>
>>>>> The RTL2832U chip might also be able to handle some low band signals
>>>>> directly, using direct sampling. No upconverter.
>>>>>
>>>>> Regardless, then the data would be fed into gnuradio - the gnuradio
>>>>> developers GUI is called "gnuradio companion" It has a nifty way of
>>>>> doing
>>>>> this kind of thing, one builds a "flow graph" where the actual
>>>>> demodulation
>>>>> is simply laid out graphically and tested.
>>>>>
>>>>> When everything works to one's satisfaction the file is saved and it
>>>>> gets
>>>>> compiled - then it can run - its basically a python script.
>>>>>
>>>>> If the modulation scheme is public, I think you can be almost certain
>>>>> that
>>>>> gnuradio might be quite useful to rapidly design a tool to demodulate
>>>>> it.
>>>>> Perhaps very quickly.
>>>>>
>>>>> For the money, one really couldn't hope to beat the flexibility of
>>>>> this
>>>>> combination in any other manner. If I were interested in trying this
>>>>> I
>>>>> would join the gnuradio mailing list and ask there. Perhaps the
>>>>> answer is
>>>>> surprisingly simple.
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>> To unsubscribe, go to
>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>> and follow the instructions there.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts@febo.com
>>>> To unsubscribe, go to
>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>>>
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
MD
Magnus Danielson
Mon, Jul 9, 2012 12:07 AM
On 07/09/2012 12:46 AM, paul wrote:
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is
being shown. Has anyone established the 14 bit sync-word and verified
the format? It seems that aligning up with the normal AM broadcast
should be possible.
Can someone record it as it has been reduced to say 2 kHz and analyze
the produced audio file? Recoding with 48 kHz sampling rate should allow
almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
Cheers,
Magnus
On 07/09/2012 12:46 AM, paul wrote:
>
> Peter indeed there could be
> But it should not need to be decoded to undo the psk.
> Plus documentation lacks some of the details I think to actually do it.
> But that would be a significant project since the formats not been
> settled completely yet.
I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is
being shown. Has anyone established the 14 bit sync-word and verified
the format? It seems that aligning up with the normal AM broadcast
should be possible.
Can someone record it as it has been reduced to say 2 kHz and analyze
the produced audio file? Recoding with 48 kHz sampling rate should allow
almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
Cheers,
Magnus
BC
Bob Camp
Mon, Jul 9, 2012 1:01 AM
Hi
The clocks we would be using are much better than what most military systems use….
I also assume that an initial lock up that takes a hour is perfectly acceptable in this application. You will still need a lot of hours / days / what ever of data to get useful stability off of WWVB, spending an hour or more to acquire from a cold start will have little net impact.
Bob
On Jul 8, 2012, at 7:29 PM, J. Forster wrote:
A risky assumption, and a cold start could be tricky.
Equatorial took many minutes to lock up, with a much higher data rate, and
it did it by slowly sweeping the local clock.
Aside: That's why military spread spectrum systems like good local clocks.
They lock up a whole lot faster that way.
-John
================
Hi
In this case the data format and it's contents are highly "computable". If
you have a good local clock and an initial lock, the rest of what
follows is predictable. That of course assumes we know the real format ….
Bob
On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
Hi Peter,
That's be the hard way, but yes, if the message BPSK coded is computable
and of a known format. If the message contained more than time, like
solar
flux, it gets more complicated very rapidly.
A similar thing was done with the Equatorial system 30+ years ago. In
that
case, each data bit was broken into something like 32 or 64 chips (I
don't
remember). There were two maximally distant, orthogonal chip patterns,
representing 1 and 0. The incoming BPSK message went through a 0 or 180
degree switch, then the IF stages. The switch was driven from a local
(known pattern) chip generator, so that if everything was synced up the
narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
trick vastly improved the system S/N becaust it narrowed the receiver IF
bandwidth many times.
If the chip pattern is not known (fixed) or computable (like a correct
TOD) things go to pot quickly.
Rather than building such a kludge, it would be easier to use the locked
clock in a newly designed receiver and phase compare that to your local
standard directly.
-John
==================
Any possibility of using the decoded signal to un-do the modulation and
feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
DVB-T
dongle/upconverter combo could almost certainly handle PM easily to
output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of
doing
this kind of thing, one builds a "flow graph" where the actual
demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and it
gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost certain
that
gnuradio might be quite useful to rapidly design a tool to demodulate
it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of
this
combination in any other manner. If I were interested in trying this
I
would join the gnuradio mailing list and ask there. Perhaps the
answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
The clocks we would be using are *much* better than what most military systems use….
I also *assume* that an initial lock up that takes a hour is perfectly acceptable in this application. You will still need a lot of hours / days / what ever of data to get useful stability off of WWVB, spending an hour or more to acquire from a cold start will have little net impact.
Bob
On Jul 8, 2012, at 7:29 PM, J. Forster wrote:
> A risky assumption, and a cold start could be tricky.
>
> Equatorial took many minutes to lock up, with a much higher data rate, and
> it did it by slowly sweeping the local clock.
>
> Aside: That's why military spread spectrum systems like good local clocks.
> They lock up a whole lot faster that way.
>
> -John
>
> ================
>
>
>
>> Hi
>>
>> In this case the data format and it's contents are highly "computable". If
>> you have a good local clock *and* an initial lock, the rest of what
>> follows is predictable. That of course assumes we know the real format ….
>>
>> Bob
>>
>> On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
>>
>>> Hi Peter,
>>>
>>> That's be the hard way, but yes, if the message BPSK coded is computable
>>> and of a known format. If the message contained more than time, like
>>> solar
>>> flux, it gets more complicated very rapidly.
>>>
>>> A similar thing was done with the Equatorial system 30+ years ago. In
>>> that
>>> case, each data bit was broken into something like 32 or 64 chips (I
>>> don't
>>> remember). There were two maximally distant, orthogonal chip patterns,
>>> representing 1 and 0. The incoming BPSK message went through a 0 or 180
>>> degree switch, then the IF stages. The switch was driven from a local
>>> (known pattern) chip generator, so that if everything was synced up the
>>> narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
>>> trick vastly improved the system S/N becaust it narrowed the receiver IF
>>> bandwidth many times.
>>>
>>> If the chip pattern is not known (fixed) or computable (like a correct
>>> TOD) things go to pot quickly.
>>>
>>> Rather than building such a kludge, it would be easier to use the locked
>>> clock in a newly designed receiver and phase compare that to your local
>>> standard directly.
>>>
>>> -John
>>>
>>> ==================
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Any possibility of using the decoded signal to un-do the modulation and
>>>> feed the reconstituted signal to the older receiver?
>>>>
>>>>
>>>>
>>>> On 7/8/2012 12:56 PM, paul wrote:
>>>>> Ei
>>>>> Sorry if I have your name reversed. By taking this approach it
>>>>> eliminates the ability to use wwvb as a frequency reference because it
>>>>> destroys that traceability.
>>>>> Thats what we are trying to preserve. Or at least re-establish for the
>>>>> older phase measuring receivers.
>>>>> Regards
>>>>> Paul
>>>>>
>>>>> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>>>>>> If the changeover you are talking about is this one:
>>>>>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
>>>>>> DVB-T
>>>>>> dongle/upconverter combo could almost certainly handle PM easily to
>>>>>> output
>>>>>> whatever it encodes, when paired with gnuradio..
>>>>>>
>>>>>> The RTL2832U chip might also be able to handle some low band signals
>>>>>> directly, using direct sampling. No upconverter.
>>>>>>
>>>>>> Regardless, then the data would be fed into gnuradio - the gnuradio
>>>>>> developers GUI is called "gnuradio companion" It has a nifty way of
>>>>>> doing
>>>>>> this kind of thing, one builds a "flow graph" where the actual
>>>>>> demodulation
>>>>>> is simply laid out graphically and tested.
>>>>>>
>>>>>> When everything works to one's satisfaction the file is saved and it
>>>>>> gets
>>>>>> compiled - then it can run - its basically a python script.
>>>>>>
>>>>>> If the modulation scheme is public, I think you can be almost certain
>>>>>> that
>>>>>> gnuradio might be quite useful to rapidly design a tool to demodulate
>>>>>> it.
>>>>>> Perhaps very quickly.
>>>>>>
>>>>>> For the money, one really couldn't hope to beat the flexibility of
>>>>>> this
>>>>>> combination in any other manner. If I were interested in trying this
>>>>>> I
>>>>>> would join the gnuradio mailing list and ask there. Perhaps the
>>>>>> answer is
>>>>>> surprisingly simple.
>>>>>> _______________________________________________
>>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>>> To unsubscribe, go to
>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>>> and follow the instructions there.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>> To unsubscribe, go to
>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>> and follow the instructions there.
>>>>>
>>>>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts@febo.com
>>>> To unsubscribe, go to
>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
BC
Bob Camp
Mon, Jul 9, 2012 1:02 AM
Hi
The gotcha is that they may change the sync word based on test data. They may also tweak other vague points in the spec based on the troubles they run into in their tests or with their silicon.
Bob
On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
On 07/09/2012 12:46 AM, paul wrote:
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is being shown. Has anyone established the 14 bit sync-word and verified the format? It seems that aligning up with the normal AM broadcast should be possible.
Can someone record it as it has been reduced to say 2 kHz and analyze the produced audio file? Recoding with 48 kHz sampling rate should allow almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
The gotcha is that they may change the sync word based on test data. They may also tweak other vague points in the spec based on the troubles they run into in their tests or with their silicon.
Bob
On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
> On 07/09/2012 12:46 AM, paul wrote:
>>
>> Peter indeed there could be
>> But it should not need to be decoded to undo the psk.
>> Plus documentation lacks some of the details I think to actually do it.
>> But that would be a significant project since the formats not been
>> settled completely yet.
>
> I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is being shown. Has anyone established the 14 bit sync-word and verified the format? It seems that aligning up with the normal AM broadcast should be possible.
>
> Can someone record it as it has been reduced to say 2 kHz and analyze the produced audio file? Recoding with 48 kHz sampling rate should allow almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
>
> Cheers,
> Magnus
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
JF
J. Forster
Mon, Jul 9, 2012 1:16 AM
If you have a deep fade every few hours or minutes, as is common, relock
time becomes an issue.
-John
==============
Hi
The clocks we would be using are much better than what most military
systems use
.
I also assume that an initial lock up that takes a hour is perfectly
acceptable in this application. You will still need a lot of hours / days
/ what ever of data to get useful stability off of WWVB, spending an hour
or more to acquire from a cold start will have little net impact.
Bob
On Jul 8, 2012, at 7:29 PM, J. Forster wrote:
A risky assumption, and a cold start could be tricky.
Equatorial took many minutes to lock up, with a much higher data rate,
and
it did it by slowly sweeping the local clock.
Aside: That's why military spread spectrum systems like good local
clocks.
They lock up a whole lot faster that way.
-John
================
Hi
In this case the data format and it's contents are highly "computable".
If
you have a good local clock and an initial lock, the rest of what
follows is predictable. That of course assumes we know the real format
.
Bob
On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
Hi Peter,
That's be the hard way, but yes, if the message BPSK coded is
computable
and of a known format. If the message contained more than time, like
solar
flux, it gets more complicated very rapidly.
A similar thing was done with the Equatorial system 30+ years ago. In
that
case, each data bit was broken into something like 32 or 64 chips (I
don't
remember). There were two maximally distant, orthogonal chip patterns,
representing 1 and 0. The incoming BPSK message went through a 0 or
180
degree switch, then the IF stages. The switch was driven from a local
(known pattern) chip generator, so that if everything was synced up
the
narrow band IF would put out the 0 or 1 that had been encoded. BTW,
this
trick vastly improved the system S/N becaust it narrowed the receiver
IF
bandwidth many times.
If the chip pattern is not known (fixed) or computable (like a correct
TOD) things go to pot quickly.
Rather than building such a kludge, it would be easier to use the
locked
clock in a newly designed receiver and phase compare that to your
local
standard directly.
-John
==================
Any possibility of using the decoded signal to un-do the modulation
and
feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because
it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for
the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept
a
DVB-T
dongle/upconverter combo could almost certainly handle PM easily to
output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band
signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of
doing
this kind of thing, one builds a "flow graph" where the actual
demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and
it
gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost
certain
that
gnuradio might be quite useful to rapidly design a tool to
demodulate
it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of
this
combination in any other manner. If I were interested in trying
this
I
would join the gnuradio mailing list and ask there. Perhaps the
answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
If you have a deep fade every few hours or minutes, as is common, relock
time becomes an issue.
-John
==============
> Hi
>
> The clocks we would be using are *much* better than what most military
> systems use
.
>
> I also *assume* that an initial lock up that takes a hour is perfectly
> acceptable in this application. You will still need a lot of hours / days
> / what ever of data to get useful stability off of WWVB, spending an hour
> or more to acquire from a cold start will have little net impact.
>
> Bob
>
> On Jul 8, 2012, at 7:29 PM, J. Forster wrote:
>
>> A risky assumption, and a cold start could be tricky.
>>
>> Equatorial took many minutes to lock up, with a much higher data rate,
>> and
>> it did it by slowly sweeping the local clock.
>>
>> Aside: That's why military spread spectrum systems like good local
>> clocks.
>> They lock up a whole lot faster that way.
>>
>> -John
>>
>> ================
>>
>>
>>
>>> Hi
>>>
>>> In this case the data format and it's contents are highly "computable".
>>> If
>>> you have a good local clock *and* an initial lock, the rest of what
>>> follows is predictable. That of course assumes we know the real format
>>>
.
>>>
>>> Bob
>>>
>>> On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> That's be the hard way, but yes, if the message BPSK coded is
>>>> computable
>>>> and of a known format. If the message contained more than time, like
>>>> solar
>>>> flux, it gets more complicated very rapidly.
>>>>
>>>> A similar thing was done with the Equatorial system 30+ years ago. In
>>>> that
>>>> case, each data bit was broken into something like 32 or 64 chips (I
>>>> don't
>>>> remember). There were two maximally distant, orthogonal chip patterns,
>>>> representing 1 and 0. The incoming BPSK message went through a 0 or
>>>> 180
>>>> degree switch, then the IF stages. The switch was driven from a local
>>>> (known pattern) chip generator, so that if everything was synced up
>>>> the
>>>> narrow band IF would put out the 0 or 1 that had been encoded. BTW,
>>>> this
>>>> trick vastly improved the system S/N becaust it narrowed the receiver
>>>> IF
>>>> bandwidth many times.
>>>>
>>>> If the chip pattern is not known (fixed) or computable (like a correct
>>>> TOD) things go to pot quickly.
>>>>
>>>> Rather than building such a kludge, it would be easier to use the
>>>> locked
>>>> clock in a newly designed receiver and phase compare that to your
>>>> local
>>>> standard directly.
>>>>
>>>> -John
>>>>
>>>> ==================
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Any possibility of using the decoded signal to un-do the modulation
>>>>> and
>>>>> feed the reconstituted signal to the older receiver?
>>>>>
>>>>>
>>>>>
>>>>> On 7/8/2012 12:56 PM, paul wrote:
>>>>>> Ei
>>>>>> Sorry if I have your name reversed. By taking this approach it
>>>>>> eliminates the ability to use wwvb as a frequency reference because
>>>>>> it
>>>>>> destroys that traceability.
>>>>>> Thats what we are trying to preserve. Or at least re-establish for
>>>>>> the
>>>>>> older phase measuring receivers.
>>>>>> Regards
>>>>>> Paul
>>>>>>
>>>>>> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>>>>>>> If the changeover you are talking about is this one:
>>>>>>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept
>>>>>>> a
>>>>>>> DVB-T
>>>>>>> dongle/upconverter combo could almost certainly handle PM easily to
>>>>>>> output
>>>>>>> whatever it encodes, when paired with gnuradio..
>>>>>>>
>>>>>>> The RTL2832U chip might also be able to handle some low band
>>>>>>> signals
>>>>>>> directly, using direct sampling. No upconverter.
>>>>>>>
>>>>>>> Regardless, then the data would be fed into gnuradio - the gnuradio
>>>>>>> developers GUI is called "gnuradio companion" It has a nifty way of
>>>>>>> doing
>>>>>>> this kind of thing, one builds a "flow graph" where the actual
>>>>>>> demodulation
>>>>>>> is simply laid out graphically and tested.
>>>>>>>
>>>>>>> When everything works to one's satisfaction the file is saved and
>>>>>>> it
>>>>>>> gets
>>>>>>> compiled - then it can run - its basically a python script.
>>>>>>>
>>>>>>> If the modulation scheme is public, I think you can be almost
>>>>>>> certain
>>>>>>> that
>>>>>>> gnuradio might be quite useful to rapidly design a tool to
>>>>>>> demodulate
>>>>>>> it.
>>>>>>> Perhaps very quickly.
>>>>>>>
>>>>>>> For the money, one really couldn't hope to beat the flexibility of
>>>>>>> this
>>>>>>> combination in any other manner. If I were interested in trying
>>>>>>> this
>>>>>>> I
>>>>>>> would join the gnuradio mailing list and ask there. Perhaps the
>>>>>>> answer is
>>>>>>> surprisingly simple.
>>>>>>> _______________________________________________
>>>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>>>> To unsubscribe, go to
>>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>>>> and follow the instructions there.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>>> To unsubscribe, go to
>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>>> and follow the instructions there.
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>> To unsubscribe, go to
>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>> and follow the instructions there.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts@febo.com
>>>> To unsubscribe, go to
>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>>
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
JF
J. Forster
Mon, Jul 9, 2012 1:24 AM
There is not an infinity of good sync words. A typical good sync word has
a high positive autocorrelation when synced, sloping downwards
monotonically.
Thus the cross-correlation of the received word with a locally stored
reference can be used to steer the loop using a small dither and a lock-in
technique.
-John
================
Hi
The gotcha is that they may change the sync word based on test data. They
may also tweak other vague points in the spec based on the troubles they
run into in their tests or with their silicon.
Bob
On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
On 07/09/2012 12:46 AM, paul wrote:
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is
being shown. Has anyone established the 14 bit sync-word and verified
the format? It seems that aligning up with the normal AM broadcast
should be possible.
Can someone record it as it has been reduced to say 2 kHz and analyze
the produced audio file? Recoding with 48 kHz sampling rate should allow
almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
There is not an infinity of good sync words. A typical good sync word has
a high positive autocorrelation when synced, sloping downwards
monotonically.
Thus the cross-correlation of the received word with a locally stored
reference can be used to steer the loop using a small dither and a lock-in
technique.
-John
================
> Hi
>
> The gotcha is that they may change the sync word based on test data. They
> may also tweak other vague points in the spec based on the troubles they
> run into in their tests or with their silicon.
>
> Bob
>
> On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
>
>> On 07/09/2012 12:46 AM, paul wrote:
>>>
>>> Peter indeed there could be
>>> But it should not need to be decoded to undo the psk.
>>> Plus documentation lacks some of the details I think to actually do it.
>>> But that would be a significant project since the formats not been
>>> settled completely yet.
>>
>> I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is
>> being shown. Has anyone established the 14 bit sync-word and verified
>> the format? It seems that aligning up with the normal AM broadcast
>> should be possible.
>>
>> Can someone record it as it has been reduced to say 2 kHz and analyze
>> the produced audio file? Recoding with 48 kHz sampling rate should allow
>> almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
>>
>> Cheers,
>> Magnus
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
BC
Bob Camp
Mon, Jul 9, 2012 1:32 AM
HI
My assumption is that for what we would be doing, one lock is all it's going to take. The local clock will be good enough to allow you to never need to re-aquire. You will indeed steer to maintain phase, but you already have and know what's coming in on the modulation.
Bob
On Jul 8, 2012, at 9:16 PM, J. Forster wrote:
If you have a deep fade every few hours or minutes, as is common, relock
time becomes an issue.
-John
==============
Hi
The clocks we would be using are much better than what most military
systems use….
I also assume that an initial lock up that takes a hour is perfectly
acceptable in this application. You will still need a lot of hours / days
/ what ever of data to get useful stability off of WWVB, spending an hour
or more to acquire from a cold start will have little net impact.
Bob
On Jul 8, 2012, at 7:29 PM, J. Forster wrote:
A risky assumption, and a cold start could be tricky.
Equatorial took many minutes to lock up, with a much higher data rate,
and
it did it by slowly sweeping the local clock.
Aside: That's why military spread spectrum systems like good local
clocks.
They lock up a whole lot faster that way.
-John
================
Hi
In this case the data format and it's contents are highly "computable".
If
you have a good local clock and an initial lock, the rest of what
follows is predictable. That of course assumes we know the real format
….
Bob
On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
Hi Peter,
That's be the hard way, but yes, if the message BPSK coded is
computable
and of a known format. If the message contained more than time, like
solar
flux, it gets more complicated very rapidly.
A similar thing was done with the Equatorial system 30+ years ago. In
that
case, each data bit was broken into something like 32 or 64 chips (I
don't
remember). There were two maximally distant, orthogonal chip patterns,
representing 1 and 0. The incoming BPSK message went through a 0 or
180
degree switch, then the IF stages. The switch was driven from a local
(known pattern) chip generator, so that if everything was synced up
the
narrow band IF would put out the 0 or 1 that had been encoded. BTW,
this
trick vastly improved the system S/N becaust it narrowed the receiver
IF
bandwidth many times.
If the chip pattern is not known (fixed) or computable (like a correct
TOD) things go to pot quickly.
Rather than building such a kludge, it would be easier to use the
locked
clock in a newly designed receiver and phase compare that to your
local
standard directly.
-John
==================
Any possibility of using the decoded signal to un-do the modulation
and
feed the reconstituted signal to the older receiver?
On 7/8/2012 12:56 PM, paul wrote:
Ei
Sorry if I have your name reversed. By taking this approach it
eliminates the ability to use wwvb as a frequency reference because
it
destroys that traceability.
Thats what we are trying to preserve. Or at least re-establish for
the
older phase measuring receivers.
Regards
Paul
On 7/8/2012 12:10 PM, Tofurk Ei wrote:
If the changeover you are talking about is this one:
http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept
a
DVB-T
dongle/upconverter combo could almost certainly handle PM easily to
output
whatever it encodes, when paired with gnuradio..
The RTL2832U chip might also be able to handle some low band
signals
directly, using direct sampling. No upconverter.
Regardless, then the data would be fed into gnuradio - the gnuradio
developers GUI is called "gnuradio companion" It has a nifty way of
doing
this kind of thing, one builds a "flow graph" where the actual
demodulation
is simply laid out graphically and tested.
When everything works to one's satisfaction the file is saved and
it
gets
compiled - then it can run - its basically a python script.
If the modulation scheme is public, I think you can be almost
certain
that
gnuradio might be quite useful to rapidly design a tool to
demodulate
it.
Perhaps very quickly.
For the money, one really couldn't hope to beat the flexibility of
this
combination in any other manner. If I were interested in trying
this
I
would join the gnuradio mailing list and ask there. Perhaps the
answer is
surprisingly simple.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
HI
My assumption is that for what we would be doing, one lock is all it's going to take. The local clock will be good enough to allow you to never need to re-aquire. You will indeed steer to maintain phase, but you already have and know what's coming in on the modulation.
Bob
On Jul 8, 2012, at 9:16 PM, J. Forster wrote:
> If you have a deep fade every few hours or minutes, as is common, relock
> time becomes an issue.
>
> -John
>
> ==============
>
>
>> Hi
>>
>> The clocks we would be using are *much* better than what most military
>> systems use….
>>
>> I also *assume* that an initial lock up that takes a hour is perfectly
>> acceptable in this application. You will still need a lot of hours / days
>> / what ever of data to get useful stability off of WWVB, spending an hour
>> or more to acquire from a cold start will have little net impact.
>>
>> Bob
>>
>> On Jul 8, 2012, at 7:29 PM, J. Forster wrote:
>>
>>> A risky assumption, and a cold start could be tricky.
>>>
>>> Equatorial took many minutes to lock up, with a much higher data rate,
>>> and
>>> it did it by slowly sweeping the local clock.
>>>
>>> Aside: That's why military spread spectrum systems like good local
>>> clocks.
>>> They lock up a whole lot faster that way.
>>>
>>> -John
>>>
>>> ================
>>>
>>>
>>>
>>>> Hi
>>>>
>>>> In this case the data format and it's contents are highly "computable".
>>>> If
>>>> you have a good local clock *and* an initial lock, the rest of what
>>>> follows is predictable. That of course assumes we know the real format
>>>> ….
>>>>
>>>> Bob
>>>>
>>>> On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
>>>>
>>>>> Hi Peter,
>>>>>
>>>>> That's be the hard way, but yes, if the message BPSK coded is
>>>>> computable
>>>>> and of a known format. If the message contained more than time, like
>>>>> solar
>>>>> flux, it gets more complicated very rapidly.
>>>>>
>>>>> A similar thing was done with the Equatorial system 30+ years ago. In
>>>>> that
>>>>> case, each data bit was broken into something like 32 or 64 chips (I
>>>>> don't
>>>>> remember). There were two maximally distant, orthogonal chip patterns,
>>>>> representing 1 and 0. The incoming BPSK message went through a 0 or
>>>>> 180
>>>>> degree switch, then the IF stages. The switch was driven from a local
>>>>> (known pattern) chip generator, so that if everything was synced up
>>>>> the
>>>>> narrow band IF would put out the 0 or 1 that had been encoded. BTW,
>>>>> this
>>>>> trick vastly improved the system S/N becaust it narrowed the receiver
>>>>> IF
>>>>> bandwidth many times.
>>>>>
>>>>> If the chip pattern is not known (fixed) or computable (like a correct
>>>>> TOD) things go to pot quickly.
>>>>>
>>>>> Rather than building such a kludge, it would be easier to use the
>>>>> locked
>>>>> clock in a newly designed receiver and phase compare that to your
>>>>> local
>>>>> standard directly.
>>>>>
>>>>> -John
>>>>>
>>>>> ==================
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Any possibility of using the decoded signal to un-do the modulation
>>>>>> and
>>>>>> feed the reconstituted signal to the older receiver?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/8/2012 12:56 PM, paul wrote:
>>>>>>> Ei
>>>>>>> Sorry if I have your name reversed. By taking this approach it
>>>>>>> eliminates the ability to use wwvb as a frequency reference because
>>>>>>> it
>>>>>>> destroys that traceability.
>>>>>>> Thats what we are trying to preserve. Or at least re-establish for
>>>>>>> the
>>>>>>> older phase measuring receivers.
>>>>>>> Regards
>>>>>>> Paul
>>>>>>>
>>>>>>> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>>>>>>>> If the changeover you are talking about is this one:
>>>>>>>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept
>>>>>>>> a
>>>>>>>> DVB-T
>>>>>>>> dongle/upconverter combo could almost certainly handle PM easily to
>>>>>>>> output
>>>>>>>> whatever it encodes, when paired with gnuradio..
>>>>>>>>
>>>>>>>> The RTL2832U chip might also be able to handle some low band
>>>>>>>> signals
>>>>>>>> directly, using direct sampling. No upconverter.
>>>>>>>>
>>>>>>>> Regardless, then the data would be fed into gnuradio - the gnuradio
>>>>>>>> developers GUI is called "gnuradio companion" It has a nifty way of
>>>>>>>> doing
>>>>>>>> this kind of thing, one builds a "flow graph" where the actual
>>>>>>>> demodulation
>>>>>>>> is simply laid out graphically and tested.
>>>>>>>>
>>>>>>>> When everything works to one's satisfaction the file is saved and
>>>>>>>> it
>>>>>>>> gets
>>>>>>>> compiled - then it can run - its basically a python script.
>>>>>>>>
>>>>>>>> If the modulation scheme is public, I think you can be almost
>>>>>>>> certain
>>>>>>>> that
>>>>>>>> gnuradio might be quite useful to rapidly design a tool to
>>>>>>>> demodulate
>>>>>>>> it.
>>>>>>>> Perhaps very quickly.
>>>>>>>>
>>>>>>>> For the money, one really couldn't hope to beat the flexibility of
>>>>>>>> this
>>>>>>>> combination in any other manner. If I were interested in trying
>>>>>>>> this
>>>>>>>> I
>>>>>>>> would join the gnuradio mailing list and ask there. Perhaps the
>>>>>>>> answer is
>>>>>>>> surprisingly simple.
>>>>>>>> _______________________________________________
>>>>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>>>>> To unsubscribe, go to
>>>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>>>>> and follow the instructions there.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>>>> To unsubscribe, go to
>>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>>>> and follow the instructions there.
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>>> To unsubscribe, go to
>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>>> and follow the instructions there.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts@febo.com
>>>>> To unsubscribe, go to
>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>> and follow the instructions there.
>>>>
>>>>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts@febo.com
>>>> To unsubscribe, go to
>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
DJ
David J Taylor
Mon, Jul 9, 2012 5:38 AM
Could not the phase modulation be made +/-90 degrees, with the appropriate
number of stuff bits being added so that the average phase remains constant?
Would the older receivers simply average out the phase variation over a
longer period?
David GM8ARV
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Could not the phase modulation be made +/-90 degrees, with the appropriate
number of stuff bits being added so that the average phase remains constant?
Would the older receivers simply average out the phase variation over a
longer period?
David GM8ARV
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
DI
David I. Emery
Mon, Jul 9, 2012 5:53 AM
On Sun, Jul 08, 2012 at 09:02:53PM -0400, Bob Camp wrote:
The gotcha is that they may change the sync word based on test data.
They may also tweak other vague points in the spec based on the troubles
they run into in their tests or with their silicon.
I finally read the wwvb.pdf paper (yes, do so before opening
mouth)...
I think I read the "Binary Phase Shift Keying Modulation"
paragraph on page 10 to indicate they are using ABSOLUTE, not
differential BPSK.
They refer to the "baseband waveforms s0(t) and s1(t)". To me
this is the absolute I vector... and this clearly says that a 0 is
always upward (or by convention in phase), and a one is always downward
(180 out)... They clearly say the phase shift is 180 degrees...
I would think this clearly could be phrased better...
It appears the data format they propose is quite well defined in
the paper, though they clearly indicate that a proposed extension is
changing the barker code sync word for frames every so often so as to
indicate a different frame type that might contain highly entropic (eg
volatile and unpredictable) information of undefined character
including a possible mechanism for sending arbitrary and completely
apriori unpredictable bitstreams, though doubtless constrained by the
hamming codes used for FEC/error detection and the barker code sync
word.
On a quick read it appears the complete 60 second time frame
format is defined unambiguously. There are somewhat unpredictable DST
bits and leap second bits in there... but in practice those change VERY
infrequently from 60 second frame to frame or even from week to week
or year to year. (Yes Congress likes to muck with DST every decade or
so...).
I am still reading more carefully, but I think this means that
the entire phase and amplitude sequence of the signal is defined for the
current initial version if you know the time of day and date and the
current leap second and DST settings (which change VERY infrequently).
And I THINK I understand this means the absolute phase sequence
relative to the 60 KHz going into the modulator at the transmitter....
Thus the initial signal phase modulation could be removed by
some comparatively simple itty bitty microp software driving a balanced
modulator BUT future signal extensions might not have that property.
As for acquiring bit sync with the signal, both the amplitude
and phase information should allow a micro to do this easily and
relatively quickly if the I vector were provided to the micro somehow.
This would presumably be possible by either sampling the 60 KHz directly
with an A/D (at 240 Ksample/sec) or by using an external balanced mixer
driven by local synthesized 60 KHz. Even just an envelope detector
would work with strong signals because of the AM component, and this
might be enough to acquire adequate bit sync for some purposes.
Software PLLs at 1 second rate are duck soup for even a SLOW
micro... and frequency errors are tiny so tracking can be tight. And
acquisition for these is also very fast given reasonable SNR. Only takes
forever if SNR is so low it takes that many seconds correlation to see a
reliable tick.
I admit as I think about this that if one synthesized the clock
for a itty bitty simple micro from say a local DUT 10 MHz whose phase
relative to WWVB one is monitoring one could do much of the entire job
by using programmable timers on the micro and its internal A/D. This
includes phase error versus WWVB output and of course TOD output.
One would almost certainly want to either use external balanced
mixers (FET switches ?) and produce an analog I and Q (low pass
filtered) for processing by a really slow micro or use a fast enough one
to take a stream of actual real 60 KHz input samples at 240 KHz and
compute filtered I and Q) (and LP filter/decimate it) (yes, with
accurate A/D clocking from suitable microp output pin interval timers
you might well be able to subsample by a lot and not actually ever deal
with even any close to a 240 KHz sample stream with the micro).
This would of course allow computation of the vector positions
of the WWVB signal modulation in I and Q space relative to the 10 MHz
clock from the DUT. And from that one should be able to compute
the various moments of 10 MHz DUT clock drift and do a decent job
of compensating for it (better and better as the DUT clock gets more
stable/predictable) and ride out fairly long fades and outages without
losing a pretty good idea of the expected WWVB phase.
Presumably most standards whose phase one is tracking with such
setups are very stable, thus the holdover should be considerable
if one uses a good error and drift estimate to adjust ones local
idea of WWVB phase relative to local clock derived from the standard
to compensate. And guess what, determining a local error and drift
estimate is precisely what such a system is doing...
And yes one could also drive a balanced modulator with the micro
to generate a de-psked signal for legacy receivers in the museum, but
in fact the micro would already know all that those things typically
provided by legacy equipment (phase of local DUT standard versus WWVB
and time of day and possibly SNR and or signal strength).
It has occurred to me that it might be necessary to either
squelch (eg turn off) the de-psked output to the legacy receivers on
signal fades or perhaps BPSK modulate it with a several times the 1
second bit rate pseudo random bit stream to ensure that the legacy
receivers never saw anything they thought was good lock until the time
of day lock allowed determination of absolute WWVB signal phase reliably
(and the new code with FEC seems to make this VERY reliable).
Enough drunken ramblings late at night...
Bob
On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
On 07/09/2012 12:46 AM, paul wrote:
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is being shown. Has anyone established the 14 bit sync-word and verified the format? It seems that aligning up with the normal AM broadcast should be possible.
Can someone record it as it has been reduced to say 2 kHz and analyze the produced audio file? Recoding with 48 kHz sampling rate should allow almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Dave Emery N1PRE/AE, die@dieconsulting.com DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
On Sun, Jul 08, 2012 at 09:02:53PM -0400, Bob Camp wrote:
> Hi
>
> The gotcha is that they may change the sync word based on test data.
> They may also tweak other vague points in the spec based on the troubles
> they run into in their tests or with their silicon.
I finally read the wwvb.pdf paper (yes, do so before opening
mouth)...
I think I read the "Binary Phase Shift Keying Modulation"
paragraph on page 10 to indicate they are using ABSOLUTE, not
differential BPSK.
They refer to the "baseband waveforms s0(t) and s1(t)". To me
this is the absolute I vector... and this clearly says that a 0 is
always upward (or by convention in phase), and a one is always downward
(180 out)... They clearly say the phase shift is 180 degrees...
I would think this clearly could be phrased better...
It appears the data format they propose is quite well defined in
the paper, though they clearly indicate that a proposed extension is
changing the barker code sync word for frames every so often so as to
indicate a different frame type that might contain highly entropic (eg
volatile and unpredictable) information of undefined character
including a possible mechanism for sending arbitrary and completely
apriori unpredictable bitstreams, though doubtless constrained by the
hamming codes used for FEC/error detection and the barker code sync
word.
On a quick read it appears the complete 60 second time frame
format is defined unambiguously. There are somewhat unpredictable DST
bits and leap second bits in there... but in practice those change VERY
infrequently from 60 second frame to frame or even from week to week
or year to year. (Yes Congress likes to muck with DST every decade or
so...).
I am still reading more carefully, but I think this means that
the entire phase and amplitude sequence of the signal is defined for the
current initial version if you know the time of day and date and the
current leap second and DST settings (which change VERY infrequently).
And I *THINK* I understand this means the absolute phase sequence
relative to the 60 KHz going into the modulator at the transmitter....
Thus the initial signal phase modulation could be removed by
some comparatively simple itty bitty microp software driving a balanced
modulator BUT future signal extensions might not have that property.
As for acquiring bit sync with the signal, both the amplitude
and phase information should allow a micro to do this easily and
relatively quickly if the I vector were provided to the micro somehow.
This would presumably be possible by either sampling the 60 KHz directly
with an A/D (at 240 Ksample/sec) or by using an external balanced mixer
driven by local synthesized 60 KHz. Even just an envelope detector
would work with strong signals because of the AM component, and this
might be enough to acquire adequate bit sync for some purposes.
Software PLLs at 1 second rate are duck soup for even a SLOW
micro... and frequency errors are tiny so tracking can be tight. And
acquisition for these is also very fast given reasonable SNR. Only takes
forever if SNR is so low it takes that many seconds correlation to see a
reliable tick.
I admit as I think about this that if one synthesized the clock
for a itty bitty simple micro from say a local DUT 10 MHz whose phase
relative to WWVB one is monitoring one could do much of the entire job
by using programmable timers on the micro and its internal A/D. This
includes phase error versus WWVB output and of course TOD output.
One would almost certainly want to either use external balanced
mixers (FET switches ?) and produce an analog I and Q (low pass
filtered) for processing by a really slow micro or use a fast enough one
to take a stream of actual real 60 KHz input samples at 240 KHz and
compute filtered I and Q) (and LP filter/decimate it) (yes, with
accurate A/D clocking from suitable microp output pin interval timers
you might well be able to subsample by a lot and not actually ever deal
with even any close to a 240 KHz sample stream with the micro).
This would of course allow computation of the vector positions
of the WWVB signal modulation in I and Q space relative to the 10 MHz
clock from the DUT. And from that one should be able to compute
the various moments of 10 MHz DUT clock drift and do a decent job
of compensating for it (better and better as the DUT clock gets more
stable/predictable) and ride out fairly long fades and outages without
losing a pretty good idea of the expected WWVB phase.
Presumably most standards whose phase one is tracking with such
setups are very stable, thus the holdover should be considerable
if one uses a good error and drift estimate to adjust ones local
idea of WWVB phase relative to local clock derived from the standard
to compensate. And guess what, determining a local error and drift
estimate is precisely what such a system is doing...
And yes one could also drive a balanced modulator with the micro
to generate a de-psked signal for legacy receivers in the museum, but
in fact the micro would already know all that those things typically
provided by legacy equipment (phase of local DUT standard versus WWVB
and time of day and possibly SNR and or signal strength).
It has occurred to me that it might be necessary to either
squelch (eg turn off) the de-psked output to the legacy receivers on
signal fades or perhaps BPSK modulate it with a several times the 1
second bit rate pseudo random bit stream to ensure that the legacy
receivers never saw anything they thought was good lock until the time
of day lock allowed determination of absolute WWVB signal phase reliably
(and the new code with FEC seems to make this VERY reliable).
Enough drunken ramblings late at night...
>
> Bob
>
> On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
>
> > On 07/09/2012 12:46 AM, paul wrote:
> >>
> >> Peter indeed there could be
> >> But it should not need to be decoded to undo the psk.
> >> Plus documentation lacks some of the details I think to actually do it.
> >> But that would be a significant project since the formats not been
> >> settled completely yet.
> >
> > I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is being shown. Has anyone established the 14 bit sync-word and verified the format? It seems that aligning up with the normal AM broadcast should be possible.
> >
> > Can someone record it as it has been reduced to say 2 kHz and analyze the produced audio file? Recoding with 48 kHz sampling rate should allow almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
> >
> > Cheers,
> > Magnus
> >
> > _______________________________________________
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
--
Dave Emery N1PRE/AE, die@dieconsulting.com DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
JF
J. Forster
Mon, Jul 9, 2012 7:01 PM
There is an advantage to BPSK switching at the zero crossings in that the
spectrum is significantly narrowed.
-John
==============
There is an advantage to BPSK switching at the zero crossings in that the
spectrum is significantly narrowed.
-John
==============
> Could not the phase modulation be made +/-90 degrees, with the appropriate
> number of stuff bits being added so that the average phase remains
> constant?
> Would the older receivers simply average out the phase variation over a
> longer period?
>
> David GM8ARV
> --
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-taylor@blueyonder.co.uk
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
MD
Magnus Danielson
Mon, Jul 9, 2012 10:15 PM
On 07/09/2012 03:32 AM, Bob Camp wrote:
HI
My assumption is that for what we would be doing, one lock is all it's going to take. The local clock will be good enough to allow you to never need to re-aquire. You will indeed steer to maintain phase, but you already have and know what's coming in on the modulation.
Except for leap second announcements.
Another thing is to monitor for cycle-slips.
Cheers,
Magnus
On 07/09/2012 03:32 AM, Bob Camp wrote:
> HI
>
> My assumption is that for what we would be doing, one lock is all it's going to take. The local clock will be good enough to allow you to never need to re-aquire. You will indeed steer to maintain phase, but you already have and know what's coming in on the modulation.
Except for leap second announcements.
Another thing is to monitor for cycle-slips.
Cheers,
Magnus
BC
Bob Camp
Mon, Jul 9, 2012 11:46 PM
Hi
Leap seconds may never happen if PHK gets things organized … :)…
Cycle slips are the main thing you would be watching for. The "slow steer" to maintain synch is to catch or correct cycle slips.
Bob
On Jul 9, 2012, at 6:15 PM, Magnus Danielson wrote:
On 07/09/2012 03:32 AM, Bob Camp wrote:
HI
My assumption is that for what we would be doing, one lock is all it's going to take. The local clock will be good enough to allow you to never need to re-aquire. You will indeed steer to maintain phase, but you already have and know what's coming in on the modulation.
Hi
Leap seconds may never happen if PHK gets things organized … :)…
Cycle slips are the main thing you would be watching for. The "slow steer" to maintain synch is to catch or correct cycle slips.
Bob
On Jul 9, 2012, at 6:15 PM, Magnus Danielson wrote:
> On 07/09/2012 03:32 AM, Bob Camp wrote:
>> HI
>>
>> My assumption is that for what we would be doing, one lock is all it's going to take. The local clock will be good enough to allow you to never need to re-aquire. You will indeed steer to maintain phase, but you already have and know what's coming in on the modulation.
>
> Except for leap second announcements.
>
> Another thing is to monitor for cycle-slips.
>
> Cheers,
> Magnus
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
P
paul
Wed, Jul 11, 2012 7:48 PM
David
Read your comments and have been traveling. So finally a chance to email.
I read the document also and walked away with what I shared.
In your reading would you believe the following.
Its an absolute phase and that when it switches to 0 there is 1
transition at the beginning of the second to 180 degrees staying that
way to the next bit or flipping again to 0 degrees if its a 1 at the 1
sec tic???
Is there a way to sense from the document that there is a bias towards 0
lets say.
I could not figure that out.
What I have seen on the scope is that I believe a 0 could be multiple
flips during the 0 bit and thats perplexing.
Regards
Paul.
On 7/9/2012 1:53 AM, David I. Emery wrote:
On Sun, Jul 08, 2012 at 09:02:53PM -0400, Bob Camp wrote:
Hi
The gotcha is that they may change the sync word based on test data.
They may also tweak other vague points in the spec based on the troubles
they run into in their tests or with their silicon.
I finally read the wwvb.pdf paper (yes, do so before opening
mouth)...
I think I read the "Binary Phase Shift Keying Modulation"
paragraph on page 10 to indicate they are using ABSOLUTE, not
differential BPSK.
They refer to the "baseband waveforms s0(t) and s1(t)". To me
this is the absolute I vector... and this clearly says that a 0 is
always upward (or by convention in phase), and a one is always downward
(180 out)... They clearly say the phase shift is 180 degrees...
I would think this clearly could be phrased better...
It appears the data format they propose is quite well defined in
the paper, though they clearly indicate that a proposed extension is
changing the barker code sync word for frames every so often so as to
indicate a different frame type that might contain highly entropic (eg
volatile and unpredictable) information of undefined character
including a possible mechanism for sending arbitrary and completely
apriori unpredictable bitstreams, though doubtless constrained by the
hamming codes used for FEC/error detection and the barker code sync
word.
On a quick read it appears the complete 60 second time frame
format is defined unambiguously. There are somewhat unpredictable DST
bits and leap second bits in there... but in practice those change VERY
infrequently from 60 second frame to frame or even from week to week
or year to year. (Yes Congress likes to muck with DST every decade or
so...).
I am still reading more carefully, but I think this means that
the entire phase and amplitude sequence of the signal is defined for the
current initial version if you know the time of day and date and the
current leap second and DST settings (which change VERY infrequently).
And I THINK I understand this means the absolute phase sequence
relative to the 60 KHz going into the modulator at the transmitter....
Thus the initial signal phase modulation could be removed by
some comparatively simple itty bitty microp software driving a balanced
modulator BUT future signal extensions might not have that property.
As for acquiring bit sync with the signal, both the amplitude
and phase information should allow a micro to do this easily and
relatively quickly if the I vector were provided to the micro somehow.
This would presumably be possible by either sampling the 60 KHz directly
with an A/D (at 240 Ksample/sec) or by using an external balanced mixer
driven by local synthesized 60 KHz. Even just an envelope detector
would work with strong signals because of the AM component, and this
might be enough to acquire adequate bit sync for some purposes.
Software PLLs at 1 second rate are duck soup for even a SLOW
micro... and frequency errors are tiny so tracking can be tight. And
acquisition for these is also very fast given reasonable SNR. Only takes
forever if SNR is so low it takes that many seconds correlation to see a
reliable tick.
I admit as I think about this that if one synthesized the clock
for a itty bitty simple micro from say a local DUT 10 MHz whose phase
relative to WWVB one is monitoring one could do much of the entire job
by using programmable timers on the micro and its internal A/D. This
includes phase error versus WWVB output and of course TOD output.
One would almost certainly want to either use external balanced
mixers (FET switches ?) and produce an analog I and Q (low pass
filtered) for processing by a really slow micro or use a fast enough one
to take a stream of actual real 60 KHz input samples at 240 KHz and
compute filtered I and Q) (and LP filter/decimate it) (yes, with
accurate A/D clocking from suitable microp output pin interval timers
you might well be able to subsample by a lot and not actually ever deal
with even any close to a 240 KHz sample stream with the micro).
This would of course allow computation of the vector positions
of the WWVB signal modulation in I and Q space relative to the 10 MHz
clock from the DUT. And from that one should be able to compute
the various moments of 10 MHz DUT clock drift and do a decent job
of compensating for it (better and better as the DUT clock gets more
stable/predictable) and ride out fairly long fades and outages without
losing a pretty good idea of the expected WWVB phase.
Presumably most standards whose phase one is tracking with such
setups are very stable, thus the holdover should be considerable
if one uses a good error and drift estimate to adjust ones local
idea of WWVB phase relative to local clock derived from the standard
to compensate. And guess what, determining a local error and drift
estimate is precisely what such a system is doing...
And yes one could also drive a balanced modulator with the micro
to generate a de-psked signal for legacy receivers in the museum, but
in fact the micro would already know all that those things typically
provided by legacy equipment (phase of local DUT standard versus WWVB
and time of day and possibly SNR and or signal strength).
It has occurred to me that it might be necessary to either
squelch (eg turn off) the de-psked output to the legacy receivers on
signal fades or perhaps BPSK modulate it with a several times the 1
second bit rate pseudo random bit stream to ensure that the legacy
receivers never saw anything they thought was good lock until the time
of day lock allowed determination of absolute WWVB signal phase reliably
(and the new code with FEC seems to make this VERY reliable).
Enough drunken ramblings late at night...
Bob
On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
On 07/09/2012 12:46 AM, paul wrote:
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is being shown. Has anyone established the 14 bit sync-word and verified the format? It seems that aligning up with the normal AM broadcast should be possible.
Can someone record it as it has been reduced to say 2 kHz and analyze the produced audio file? Recoding with 48 kHz sampling rate should allow almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
David
Read your comments and have been traveling. So finally a chance to email.
I read the document also and walked away with what I shared.
In your reading would you believe the following.
Its an absolute phase and that when it switches to 0 there is 1
transition at the beginning of the second to 180 degrees staying that
way to the next bit or flipping again to 0 degrees if its a 1 at the 1
sec tic???
Is there a way to sense from the document that there is a bias towards 0
lets say.
I could not figure that out.
What I have seen on the scope is that I believe a 0 could be multiple
flips during the 0 bit and thats perplexing.
Regards
Paul.
On 7/9/2012 1:53 AM, David I. Emery wrote:
> On Sun, Jul 08, 2012 at 09:02:53PM -0400, Bob Camp wrote:
>> Hi
>>
>> The gotcha is that they may change the sync word based on test data.
>> They may also tweak other vague points in the spec based on the troubles
>> they run into in their tests or with their silicon.
> I finally read the wwvb.pdf paper (yes, do so before opening
> mouth)...
>
> I think I read the "Binary Phase Shift Keying Modulation"
> paragraph on page 10 to indicate they are using ABSOLUTE, not
> differential BPSK.
>
> They refer to the "baseband waveforms s0(t) and s1(t)". To me
> this is the absolute I vector... and this clearly says that a 0 is
> always upward (or by convention in phase), and a one is always downward
> (180 out)... They clearly say the phase shift is 180 degrees...
>
> I would think this clearly could be phrased better...
>
> It appears the data format they propose is quite well defined in
> the paper, though they clearly indicate that a proposed extension is
> changing the barker code sync word for frames every so often so as to
> indicate a different frame type that might contain highly entropic (eg
> volatile and unpredictable) information of undefined character
> including a possible mechanism for sending arbitrary and completely
> apriori unpredictable bitstreams, though doubtless constrained by the
> hamming codes used for FEC/error detection and the barker code sync
> word.
>
> On a quick read it appears the complete 60 second time frame
> format is defined unambiguously. There are somewhat unpredictable DST
> bits and leap second bits in there... but in practice those change VERY
> infrequently from 60 second frame to frame or even from week to week
> or year to year. (Yes Congress likes to muck with DST every decade or
> so...).
>
> I am still reading more carefully, but I think this means that
> the entire phase and amplitude sequence of the signal is defined for the
> current initial version if you know the time of day and date and the
> current leap second and DST settings (which change VERY infrequently).
> And I *THINK* I understand this means the absolute phase sequence
> relative to the 60 KHz going into the modulator at the transmitter....
>
> Thus the initial signal phase modulation could be removed by
> some comparatively simple itty bitty microp software driving a balanced
> modulator BUT future signal extensions might not have that property.
>
> As for acquiring bit sync with the signal, both the amplitude
> and phase information should allow a micro to do this easily and
> relatively quickly if the I vector were provided to the micro somehow.
> This would presumably be possible by either sampling the 60 KHz directly
> with an A/D (at 240 Ksample/sec) or by using an external balanced mixer
> driven by local synthesized 60 KHz. Even just an envelope detector
> would work with strong signals because of the AM component, and this
> might be enough to acquire adequate bit sync for some purposes.
>
> Software PLLs at 1 second rate are duck soup for even a SLOW
> micro... and frequency errors are tiny so tracking can be tight. And
> acquisition for these is also very fast given reasonable SNR. Only takes
> forever if SNR is so low it takes that many seconds correlation to see a
> reliable tick.
>
> I admit as I think about this that if one synthesized the clock
> for a itty bitty simple micro from say a local DUT 10 MHz whose phase
> relative to WWVB one is monitoring one could do much of the entire job
> by using programmable timers on the micro and its internal A/D. This
> includes phase error versus WWVB output and of course TOD output.
>
> One would almost certainly want to either use external balanced
> mixers (FET switches ?) and produce an analog I and Q (low pass
> filtered) for processing by a really slow micro or use a fast enough one
> to take a stream of actual real 60 KHz input samples at 240 KHz and
> compute filtered I and Q) (and LP filter/decimate it) (yes, with
> accurate A/D clocking from suitable microp output pin interval timers
> you might well be able to subsample by a lot and not actually ever deal
> with even any close to a 240 KHz sample stream with the micro).
>
> This would of course allow computation of the vector positions
> of the WWVB signal modulation in I and Q space relative to the 10 MHz
> clock from the DUT. And from that one should be able to compute
> the various moments of 10 MHz DUT clock drift and do a decent job
> of compensating for it (better and better as the DUT clock gets more
> stable/predictable) and ride out fairly long fades and outages without
> losing a pretty good idea of the expected WWVB phase.
>
> Presumably most standards whose phase one is tracking with such
> setups are very stable, thus the holdover should be considerable
> if one uses a good error and drift estimate to adjust ones local
> idea of WWVB phase relative to local clock derived from the standard
> to compensate. And guess what, determining a local error and drift
> estimate is precisely what such a system is doing...
>
> And yes one could also drive a balanced modulator with the micro
> to generate a de-psked signal for legacy receivers in the museum, but
> in fact the micro would already know all that those things typically
> provided by legacy equipment (phase of local DUT standard versus WWVB
> and time of day and possibly SNR and or signal strength).
>
> It has occurred to me that it might be necessary to either
> squelch (eg turn off) the de-psked output to the legacy receivers on
> signal fades or perhaps BPSK modulate it with a several times the 1
> second bit rate pseudo random bit stream to ensure that the legacy
> receivers never saw anything they thought was good lock until the time
> of day lock allowed determination of absolute WWVB signal phase reliably
> (and the new code with FEC seems to make this VERY reliable).
>
> Enough drunken ramblings late at night...
>
>
>
>> Bob
>>
>> On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
>>
>>> On 07/09/2012 12:46 AM, paul wrote:
>>>> Peter indeed there could be
>>>> But it should not need to be decoded to undo the psk.
>>>> Plus documentation lacks some of the details I think to actually do it.
>>>> But that would be a significant project since the formats not been
>>>> settled completely yet.
>>> I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format is being shown. Has anyone established the 14 bit sync-word and verified the format? It seems that aligning up with the normal AM broadcast should be possible.
>>>
>>> Can someone record it as it has been reduced to say 2 kHz and analyze the produced audio file? Recoding with 48 kHz sampling rate should allow almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
>>>
>>> Cheers,
>>> Magnus
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
PS
paul swed
Wed, Jul 11, 2012 7:48 PM
David
Read your comments and have been traveling. So finally a chance to email.
I read the document also and walked away with what I shared.
In your reading would you believe the following.
Its an absolute phase and that when it switches to 0 there is 1 transition
at the beginning of the second to 180 degrees staying that way to the next
bit or flipping again to 0 degrees if its a 1 at the 1 sec tic???
Is there a way to sense from the document that there is a bias towards 0
lets say.
I could not figure that out.
Regards
Paul.
On 7/9/2012 1:53 AM, David I. Emery wrote:
On Sun, Jul 08, 2012 at 09:02:53PM -0400, Bob Camp wrote:
Hi
The gotcha is that they may change the sync word based on test data.
They may also tweak other vague points in the spec based on the troubles
they run into in their tests or with their silicon.
I finally read the wwvb.pdf paper (yes, do so before opening
mouth)...
I think I read the "Binary Phase Shift Keying Modulation"
paragraph on page 10 to indicate they are using ABSOLUTE, not
differential BPSK.
They refer to the "baseband waveforms s0(t) and s1(t)". To me
this is the absolute I vector... and this clearly says that a 0 is
always upward (or by convention in phase), and a one is always downward
(180 out)... They clearly say the phase shift is 180 degrees...
I would think this clearly could be phrased better...
It appears the data format they propose is quite well defined in
the paper, though they clearly indicate that a proposed extension is
changing the barker code sync word for frames every so often so as to
indicate a different frame type that might contain highly entropic (eg
volatile and unpredictable) information of undefined character
including a possible mechanism for sending arbitrary and completely
apriori unpredictable bitstreams, though doubtless constrained by the
hamming codes used for FEC/error detection and the barker code sync
word.
On a quick read it appears the complete 60 second time frame
format is defined unambiguously. There are somewhat unpredictable DST
bits and leap second bits in there... but in practice those change VERY
infrequently from 60 second frame to frame or even from week to week
or year to year. (Yes Congress likes to muck with DST every decade or
so...).
I am still reading more carefully, but I think this means that
the entire phase and amplitude sequence of the signal is defined for the
current initial version if you know the time of day and date and the
current leap second and DST settings (which change VERY infrequently).
And I THINK I understand this means the absolute phase sequence
relative to the 60 KHz going into the modulator at the transmitter....
Thus the initial signal phase modulation could be removed by
some comparatively simple itty bitty microp software driving a balanced
modulator BUT future signal extensions might not have that property.
As for acquiring bit sync with the signal, both the amplitude
and phase information should allow a micro to do this easily and
relatively quickly if the I vector were provided to the micro somehow.
This would presumably be possible by either sampling the 60 KHz directly
with an A/D (at 240 Ksample/sec) or by using an external balanced mixer
driven by local synthesized 60 KHz. Even just an envelope detector
would work with strong signals because of the AM component, and this
might be enough to acquire adequate bit sync for some purposes.
Software PLLs at 1 second rate are duck soup for even a SLOW
micro... and frequency errors are tiny so tracking can be tight. And
acquisition for these is also very fast given reasonable SNR. Only takes
forever if SNR is so low it takes that many seconds correlation to see a
reliable tick.
I admit as I think about this that if one synthesized the clock
for a itty bitty simple micro from say a local DUT 10 MHz whose phase
relative to WWVB one is monitoring one could do much of the entire job
by using programmable timers on the micro and its internal A/D. This
includes phase error versus WWVB output and of course TOD output.
One would almost certainly want to either use external balanced
mixers (FET switches ?) and produce an analog I and Q (low pass
filtered) for processing by a really slow micro or use a fast enough one
to take a stream of actual real 60 KHz input samples at 240 KHz and
compute filtered I and Q) (and LP filter/decimate it) (yes, with
accurate A/D clocking from suitable microp output pin interval timers
you might well be able to subsample by a lot and not actually ever deal
with even any close to a 240 KHz sample stream with the micro).
This would of course allow computation of the vector positions
of the WWVB signal modulation in I and Q space relative to the 10 MHz
clock from the DUT. And from that one should be able to compute
the various moments of 10 MHz DUT clock drift and do a decent job
of compensating for it (better and better as the DUT clock gets more
stable/predictable) and ride out fairly long fades and outages without
losing a pretty good idea of the expected WWVB phase.
Presumably most standards whose phase one is tracking with such
setups are very stable, thus the holdover should be considerable
if one uses a good error and drift estimate to adjust ones local
idea of WWVB phase relative to local clock derived from the standard
to compensate. And guess what, determining a local error and drift
estimate is precisely what such a system is doing...
And yes one could also drive a balanced modulator with the micro
to generate a de-psked signal for legacy receivers in the museum, but
in fact the micro would already know all that those things typically
provided by legacy equipment (phase of local DUT standard versus WWVB
and time of day and possibly SNR and or signal strength).
It has occurred to me that it might be necessary to either
squelch (eg turn off) the de-psked output to the legacy receivers on
signal fades or perhaps BPSK modulate it with a several times the 1
second bit rate pseudo random bit stream to ensure that the legacy
receivers never saw anything they thought was good lock until the time
of day lock allowed determination of absolute WWVB signal phase reliably
(and the new code with FEC seems to make this VERY reliable).
Enough drunken ramblings late at night...
Bob
On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
On 07/09/2012 12:46 AM, paul wrote:
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format
is being shown. Has anyone established the 14 bit sync-word and
verified the format? It seems that aligning up with the normal AM
broadcast should be possible.
Can someone record it as it has been reduced to say 2 kHz and analyze
the produced audio file? Recoding with 48 kHz sampling rate should
allow almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
David
Read your comments and have been traveling. So finally a chance to email.
I read the document also and walked away with what I shared.
In your reading would you believe the following.
Its an absolute phase and that when it switches to 0 there is 1 transition
at the beginning of the second to 180 degrees staying that way to the next
bit or flipping again to 0 degrees if its a 1 at the 1 sec tic???
Is there a way to sense from the document that there is a bias towards 0
lets say.
I could not figure that out.
Regards
Paul.
On 7/9/2012 1:53 AM, David I. Emery wrote:
On Sun, Jul 08, 2012 at 09:02:53PM -0400, Bob Camp wrote:
Hi
The gotcha is that they may change the sync word based on test data.
They may also tweak other vague points in the spec based on the troubles
they run into in their tests or with their silicon.
I finally read the wwvb.pdf paper (yes, do so before opening
mouth)...
I think I read the "Binary Phase Shift Keying Modulation"
paragraph on page 10 to indicate they are using ABSOLUTE, not
differential BPSK.
They refer to the "baseband waveforms s0(t) and s1(t)". To me
this is the absolute I vector... and this clearly says that a 0 is
always upward (or by convention in phase), and a one is always downward
(180 out)... They clearly say the phase shift is 180 degrees...
I would think this clearly could be phrased better...
It appears the data format they propose is quite well defined in
the paper, though they clearly indicate that a proposed extension is
changing the barker code sync word for frames every so often so as to
indicate a different frame type that might contain highly entropic (eg
volatile and unpredictable) information of undefined character
including a possible mechanism for sending arbitrary and completely
apriori unpredictable bitstreams, though doubtless constrained by the
hamming codes used for FEC/error detection and the barker code sync
word.
On a quick read it appears the complete 60 second time frame
format is defined unambiguously. There are somewhat unpredictable DST
bits and leap second bits in there... but in practice those change VERY
infrequently from 60 second frame to frame or even from week to week
or year to year. (Yes Congress likes to muck with DST every decade or
so...).
I am still reading more carefully, but I think this means that
the entire phase and amplitude sequence of the signal is defined for the
current initial version if you know the time of day and date and the
current leap second and DST settings (which change VERY infrequently).
And I *THINK* I understand this means the absolute phase sequence
relative to the 60 KHz going into the modulator at the transmitter....
Thus the initial signal phase modulation could be removed by
some comparatively simple itty bitty microp software driving a balanced
modulator BUT future signal extensions might not have that property.
As for acquiring bit sync with the signal, both the amplitude
and phase information should allow a micro to do this easily and
relatively quickly if the I vector were provided to the micro somehow.
This would presumably be possible by either sampling the 60 KHz directly
with an A/D (at 240 Ksample/sec) or by using an external balanced mixer
driven by local synthesized 60 KHz. Even just an envelope detector
would work with strong signals because of the AM component, and this
might be enough to acquire adequate bit sync for some purposes.
Software PLLs at 1 second rate are duck soup for even a SLOW
micro... and frequency errors are tiny so tracking can be tight. And
acquisition for these is also very fast given reasonable SNR. Only takes
forever if SNR is so low it takes that many seconds correlation to see a
reliable tick.
I admit as I think about this that if one synthesized the clock
for a itty bitty simple micro from say a local DUT 10 MHz whose phase
relative to WWVB one is monitoring one could do much of the entire job
by using programmable timers on the micro and its internal A/D. This
includes phase error versus WWVB output and of course TOD output.
One would almost certainly want to either use external balanced
mixers (FET switches ?) and produce an analog I and Q (low pass
filtered) for processing by a really slow micro or use a fast enough one
to take a stream of actual real 60 KHz input samples at 240 KHz and
compute filtered I and Q) (and LP filter/decimate it) (yes, with
accurate A/D clocking from suitable microp output pin interval timers
you might well be able to subsample by a lot and not actually ever deal
with even any close to a 240 KHz sample stream with the micro).
This would of course allow computation of the vector positions
of the WWVB signal modulation in I and Q space relative to the 10 MHz
clock from the DUT. And from that one should be able to compute
the various moments of 10 MHz DUT clock drift and do a decent job
of compensating for it (better and better as the DUT clock gets more
stable/predictable) and ride out fairly long fades and outages without
losing a pretty good idea of the expected WWVB phase.
Presumably most standards whose phase one is tracking with such
setups are very stable, thus the holdover should be considerable
if one uses a good error and drift estimate to adjust ones local
idea of WWVB phase relative to local clock derived from the standard
to compensate. And guess what, determining a local error and drift
estimate is precisely what such a system is doing...
And yes one could also drive a balanced modulator with the micro
to generate a de-psked signal for legacy receivers in the museum, but
in fact the micro would already know all that those things typically
provided by legacy equipment (phase of local DUT standard versus WWVB
and time of day and possibly SNR and or signal strength).
It has occurred to me that it might be necessary to either
squelch (eg turn off) the de-psked output to the legacy receivers on
signal fades or perhaps BPSK modulate it with a several times the 1
second bit rate pseudo random bit stream to ensure that the legacy
receivers never saw anything they thought was good lock until the time
of day lock allowed determination of absolute WWVB signal phase reliably
(and the new code with FEC seems to make this VERY reliable).
Enough drunken ramblings late at night...
Bob
On Jul 8, 2012, at 8:07 PM, Magnus Danielson wrote:
On 07/09/2012 12:46 AM, paul wrote:
Peter indeed there could be
But it should not need to be decoded to undo the psk.
Plus documentation lacks some of the details I think to actually do it.
But that would be a significant project since the formats not been
settled completely yet.
I have looked at the PTTI 2011 paper (wwvb.pdf) and much of a format
is being shown. Has anyone established the 14 bit sync-word and
verified the format? It seems that aligning up with the normal AM
broadcast should be possible.
Can someone record it as it has been reduced to say 2 kHz and analyze
the produced audio file? Recoding with 48 kHz sampling rate should
allow almost trivial 2 kHz I-Q demodulation to illustrate phase swaps.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
DI
David I. Emery
Fri, Jul 13, 2012 11:49 PM
On Wed, Jul 11, 2012 at 03:48:52PM -0400, paul swed wrote:
David
Read your comments and have been traveling. So finally a chance to email.
I read the document also and walked away with what I shared.
In your reading would you believe the following.
Its an absolute phase and that when it switches to 0 there is 1 transition
at the beginning of the second to 180 degrees staying that way to the next
bit or flipping again to 0 degrees if its a 1 at the 1 sec tic???
What I mean by absolute phase is that a 1 is always 180 degrees
and a zero always 0 degrees. In your example this would imply that the
two ones in a row would result in two seconds of 180 degree phase
without a flip after the first 1.
The document is confusing, but the best I can do with its
language is to conclude they are talking about absolute phase. Normally
when one talks about baseband waveforms one is referring to absolute I
and Q components relative to an unchanging carrier phase, not relative I
and Q with respect to the last bit phase. So I take their language to
mean a zero is 0 degrees and a 1 180 degrees relative to an unchanging
carrier.
Differential encoding is the opposite, a 1 is always the
opposite phase from the last bit, a zero always the same phase as the
last bit (or sometimes the inverse where a zero is the transition and a
one is not).
Is there a way to sense from the document that there is a bias towards 0
lets say.
Differential encoding tends to have little "DC" component or
bias toward either one or zero or one phase or the other, absolute
encoding does if the data it encodes does.
--
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
On Wed, Jul 11, 2012 at 03:48:52PM -0400, paul swed wrote:
> David
> Read your comments and have been traveling. So finally a chance to email.
>
> I read the document also and walked away with what I shared.
> In your reading would you believe the following.
> Its an absolute phase and that when it switches to 0 there is 1 transition
> at the beginning of the second to 180 degrees staying that way to the next
> bit or flipping again to 0 degrees if its a 1 at the 1 sec tic???
What I mean by absolute phase is that a 1 is always 180 degrees
and a zero always 0 degrees. In your example this would imply that the
two ones in a row would result in two seconds of 180 degree phase
without a flip after the first 1.
The document is confusing, but the best I can do with its
language is to conclude they are talking about absolute phase. Normally
when one talks about baseband waveforms one is referring to absolute I
and Q components relative to an unchanging carrier phase, not relative I
and Q with respect to the last bit phase. So I take their language to
mean a zero is 0 degrees and a 1 180 degrees relative to an unchanging
carrier.
Differential encoding is the opposite, a 1 is always the
opposite phase from the last bit, a zero always the same phase as the
last bit (or sometimes the inverse where a zero is the transition and a
one is not).
> Is there a way to sense from the document that there is a bias towards 0
> lets say.
Differential encoding tends to have little "DC" component or
bias toward either one or zero or one phase or the other, absolute
encoding does if the data it encodes does.
--
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
MD
Magnus Danielson
Sat, Jul 14, 2012 12:38 AM
On 07/14/2012 01:49 AM, David I. Emery wrote:
On Wed, Jul 11, 2012 at 03:48:52PM -0400, paul swed wrote:
David
Read your comments and have been traveling. So finally a chance to email.
I read the document also and walked away with what I shared.
In your reading would you believe the following.
Its an absolute phase and that when it switches to 0 there is 1 transition
at the beginning of the second to 180 degrees staying that way to the next
bit or flipping again to 0 degrees if its a 1 at the 1 sec tic???
What I mean by absolute phase is that a 1 is always 180 degrees
and a zero always 0 degrees. In your example this would imply that the
two ones in a row would result in two seconds of 180 degree phase
without a flip after the first 1.
The document is confusing, but the best I can do with its
language is to conclude they are talking about absolute phase. Normally
when one talks about baseband waveforms one is referring to absolute I
and Q components relative to an unchanging carrier phase, not relative I
and Q with respect to the last bit phase. So I take their language to
mean a zero is 0 degrees and a 1 180 degrees relative to an unchanging
carrier.
I think the PTTI article isn't as much documentation as presentation of
general principle, showing details more as to present how it can be
done, but not necessarily guarantee it will be done that way. Knowing
the synchronisation sequence, polarity should not be ambiguous. Also
note that other data such as hours would be known from the AM signal, so
we can reverse engineer it. A receiver knowing this sequence will either
bootstrap from the AM or attempt straight lock. It's not too hard to
build a maximum likelihood receiver for it.
Cheers,
Magnus
On 07/14/2012 01:49 AM, David I. Emery wrote:
> On Wed, Jul 11, 2012 at 03:48:52PM -0400, paul swed wrote:
>> David
>> Read your comments and have been traveling. So finally a chance to email.
>>
>> I read the document also and walked away with what I shared.
>> In your reading would you believe the following.
>> Its an absolute phase and that when it switches to 0 there is 1 transition
>> at the beginning of the second to 180 degrees staying that way to the next
>> bit or flipping again to 0 degrees if its a 1 at the 1 sec tic???
>
> What I mean by absolute phase is that a 1 is always 180 degrees
> and a zero always 0 degrees. In your example this would imply that the
> two ones in a row would result in two seconds of 180 degree phase
> without a flip after the first 1.
>
> The document is confusing, but the best I can do with its
> language is to conclude they are talking about absolute phase. Normally
> when one talks about baseband waveforms one is referring to absolute I
> and Q components relative to an unchanging carrier phase, not relative I
> and Q with respect to the last bit phase. So I take their language to
> mean a zero is 0 degrees and a 1 180 degrees relative to an unchanging
> carrier.
I think the PTTI article isn't as much documentation as presentation of
general principle, showing details more as to present how it can be
done, but not necessarily guarantee it will be done that way. Knowing
the synchronisation sequence, polarity should not be ambiguous. Also
note that other data such as hours would be known from the AM signal, so
we can reverse engineer it. A receiver knowing this sequence will either
bootstrap from the AM or attempt straight lock. It's not too hard to
build a maximum likelihood receiver for it.
Cheers,
Magnus
DI
David I. Emery
Sat, Jul 14, 2012 3:35 AM
On Sat, Jul 14, 2012 at 02:38:34AM +0200, Magnus Danielson wrote:
I think the PTTI article isn't as much documentation as presentation of
general principle, showing details more as to present how it can be
done, but not necessarily guarantee it will be done that way. Knowing
the synchronisation sequence, polarity should not be ambiguous. Also
note that other data such as hours would be known from the AM signal, so
we can reverse engineer it. A receiver knowing this sequence will either
bootstrap from the AM or attempt straight lock. It's not too hard to
build a maximum likelihood receiver for it.
I read the article as not a definitive specification frozen in
stone, but as a complete and relatively fully specified proposed design
with perhaps some details subject to adjustment or revision.
The question of absolute versus differential phase shift keying
is, of course, rather fundamental to being able to decode the signal at
one level but at another not terribly central to the core of the design
for a coding and modulation scheme that works at much lower C/N levels
than the AM version did while preserving the legacy AM and its coding
for existing hardware.
SOME place in the design of a differentially coded signal there
has to be a decision whether or not to structure the data encoding so
some specific bit (or more properly symbol) in each frame (or at least
some known frames relative to the time of day) (in this case I mean 1
minute long TOD frame) is of a known absolute reference phase.
If this is done than it becomes possible in a reasonable time to
determine an absolute 60 KHz carrier phase after a fade, if it is not
done and every single bit of data is not absolutely predictable (the
current TOD coding would be absolutely predictable given knowledge of
the time and date and of leap seconds and DST settings, but they make
clear future extensions would probably not have this property as
additional messages are added including emergency messages and the like
which are never predictable) there is no way to reliably decide after a
fade which phase is which as this depends on knowing the number of ones
and zeros in all the frames transmitted since one last saw the signal,
something that is in the general case impossible if the signal has faded
and the bits were not observed.
An absolute encoding has no ambiguity - if one knows the time of
day within a second one knows the transmitted phase except for during
bits that might vary with unknown data (eg emergency messages,
extensions to the standard and newly changed DST and leap second
settings and FEC bits based on them) and MOST bits are always known
phases, especially of course the sync code words. So even with
terribly poor C/N one should be able to relatively quickly resolve the
phase ambiguity after a period of signal loss... and in many cases if
one still has a good idea of the time, within a couple of seconds
(symbols) of signal reacquisition.
On another point, I am not of the school that providing much
better weak signal performance for simple, low power, and cheap LF time
of day clocks using WWVB is somehow a minor improvement that primarily
benefits China because they make most cheap self setting "atomic"
clocks. There are innumerable applications for low cost low power
human level 1 second accurate time of day in modern electronic systems -
examples are traffic lights and school crossing signs and water
sprinklers and street lights and other outdoor lighting and many
others... these systems are not normally network connected and there is
no current wide area technology short of power hungry GPS with its weak
signals and relatively high cost and difficult reception from many
locations to do this.
And with minimal effort to ensure compatibility, there should be
no conflict with use of the same carrier signal as a frequency reference
too... the problem of several decades old antique time and frequency
gear being incompatible seems very minor, and of course we have already
discussed ways to handle this if needed.
And as long as the existing frequency reference use of the
carrier continues to work as a backup to GPS with modern updated gear
that capability hasn't been lost - except maybe if your particular
variety of tin foil hat requires vacuum tube VLF reference gear because
of EMP fears or something similar.
I think the new WWVB proposal seems sensible and a reasonable
design...that should serve the public well.
--
Dave Emery N1PRE/AE, die@dieconsulting.com DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
On Sat, Jul 14, 2012 at 02:38:34AM +0200, Magnus Danielson wrote:
> I think the PTTI article isn't as much documentation as presentation of
> general principle, showing details more as to present how it can be
> done, but not necessarily guarantee it will be done that way. Knowing
> the synchronisation sequence, polarity should not be ambiguous. Also
> note that other data such as hours would be known from the AM signal, so
> we can reverse engineer it. A receiver knowing this sequence will either
> bootstrap from the AM or attempt straight lock. It's not too hard to
> build a maximum likelihood receiver for it.
I read the article as not a definitive specification frozen in
stone, but as a complete and relatively fully specified proposed design
with perhaps some details subject to adjustment or revision.
The question of absolute versus differential phase shift keying
is, of course, rather fundamental to being able to decode the signal at
one level but at another not terribly central to the core of the design
for a coding and modulation scheme that works at much lower C/N levels
than the AM version did while preserving the legacy AM and its coding
for existing hardware.
SOME place in the design of a differentially coded signal there
has to be a decision whether or not to structure the data encoding so
some specific bit (or more properly symbol) in each frame (or at least
some known frames relative to the time of day) (in this case I mean 1
minute long TOD frame) is of a known absolute reference phase.
If this is done than it becomes possible in a reasonable time to
determine an absolute 60 KHz carrier phase after a fade, if it is not
done and every single bit of data is not absolutely predictable (the
current TOD coding would be absolutely predictable given knowledge of
the time and date and of leap seconds and DST settings, but they make
clear future extensions would probably not have this property as
additional messages are added including emergency messages and the like
which are never predictable) there is no way to reliably decide after a
fade which phase is which as this depends on knowing the number of ones
and zeros in all the frames transmitted since one last saw the signal,
something that is in the general case impossible if the signal has faded
and the bits were not observed.
An absolute encoding has no ambiguity - if one knows the time of
day within a second one knows the transmitted phase except for during
bits that might vary with unknown data (eg emergency messages,
extensions to the standard and newly changed DST and leap second
settings and FEC bits based on them) and MOST bits are always known
phases, especially of course the sync code words. So even with
terribly poor C/N one should be able to relatively quickly resolve the
phase ambiguity after a period of signal loss... and in many cases if
one still has a good idea of the time, within a couple of seconds
(symbols) of signal reacquisition.
On another point, I am not of the school that providing much
better weak signal performance for simple, low power, and cheap LF time
of day clocks using WWVB is somehow a minor improvement that primarily
benefits China because they make most cheap self setting "atomic"
clocks. There are innumerable applications for low cost low power
human level 1 second accurate time of day in modern electronic systems -
examples are traffic lights and school crossing signs and water
sprinklers and street lights and other outdoor lighting and many
others... these systems are not normally network connected and there is
no current wide area technology short of power hungry GPS with its weak
signals and relatively high cost and difficult reception from many
locations to do this.
And with minimal effort to ensure compatibility, there should be
no conflict with use of the same carrier signal as a frequency reference
too... the problem of several decades old antique time and frequency
gear being incompatible seems very minor, and of course we have already
discussed ways to handle this if needed.
And as long as the existing frequency reference use of the
carrier continues to work as a backup to GPS with modern updated gear
that capability hasn't been lost - except maybe if your particular
variety of tin foil hat requires vacuum tube VLF reference gear because
of EMP fears or something similar.
I think the new WWVB proposal seems sensible and a reasonable
design...that should serve the public well.
--
Dave Emery N1PRE/AE, die@dieconsulting.com DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
RW
Ron Ward
Sat, Jul 14, 2012 5:07 AM
I received the following message from John Lowe at NIST.
I thought it might be of interest to you.
-----Original Message-----
From: John Lowe [mailto:lowe@boulder.nist.gov]
Sent: Monday, July 09, 2012 12:55 PM
To: Ron Ward
Subject: Re: Phase-locking 60 kHz timing and frequency standard
receivers
We are changing the format to improve our reception capability.
Frequency standard comparisons will still be possible with new or
modified equipment.
On 7/5/2012 9:39 AM, Ron Ward wrote:
Hi John:
Why is WWVB changing to BPSK? For cheaper clocks?
What about frequency standard comparisons with WWVB?
How am I going to monitor GPS and ensure that it's working correctly and
not being played with by DOD?
What am I going to do with our phase-locking 60 kHz timing and frequency
standard receivers?
Why did you not make the new data format backward compatible with
existing phase-locking 60 kHz timing and frequency standard receivers,
like they did with black and white to color TV transition in the 1950's?
What about +- 45 degree modulation?
We use to have LORAN, OMEGA, and WWVB.
Thanks,
Ron
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of David I. Emery
Sent: Friday, July 13, 2012 8:35 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Phase modulation detection/NIST plan
On Sat, Jul 14, 2012 at 02:38:34AM +0200, Magnus Danielson wrote:
I think the PTTI article isn't as much documentation as presentation
general principle, showing details more as to present how it can be
done, but not necessarily guarantee it will be done that way. Knowing
the synchronisation sequence, polarity should not be ambiguous. Also
note that other data such as hours would be known from the AM signal,
we can reverse engineer it. A receiver knowing this sequence will
bootstrap from the AM or attempt straight lock. It's not too hard to
build a maximum likelihood receiver for it.
I read the article as not a definitive specification frozen in
stone, but as a complete and relatively fully specified proposed design
with perhaps some details subject to adjustment or revision.
The question of absolute versus differential phase shift keying
is, of course, rather fundamental to being able to decode the signal at
one level but at another not terribly central to the core of the design
for a coding and modulation scheme that works at much lower C/N levels
than the AM version did while preserving the legacy AM and its coding
for existing hardware.
SOME place in the design of a differentially coded signal there
has to be a decision whether or not to structure the data encoding so
some specific bit (or more properly symbol) in each frame (or at least
some known frames relative to the time of day) (in this case I mean 1
minute long TOD frame) is of a known absolute reference phase.
If this is done than it becomes possible in a reasonable time to
determine an absolute 60 KHz carrier phase after a fade, if it is not
done and every single bit of data is not absolutely predictable (the
current TOD coding would be absolutely predictable given knowledge of
the time and date and of leap seconds and DST settings, but they make
clear future extensions would probably not have this property as
additional messages are added including emergency messages and the like
which are never predictable) there is no way to reliably decide after a
fade which phase is which as this depends on knowing the number of ones
and zeros in all the frames transmitted since one last saw the signal,
something that is in the general case impossible if the signal has faded
and the bits were not observed.
An absolute encoding has no ambiguity - if one knows the time of
day within a second one knows the transmitted phase except for during
bits that might vary with unknown data (eg emergency messages,
extensions to the standard and newly changed DST and leap second
settings and FEC bits based on them) and MOST bits are always known
phases, especially of course the sync code words. So even with
terribly poor C/N one should be able to relatively quickly resolve the
phase ambiguity after a period of signal loss... and in many cases if
one still has a good idea of the time, within a couple of seconds
(symbols) of signal reacquisition.
On another point, I am not of the school that providing much
better weak signal performance for simple, low power, and cheap LF time
of day clocks using WWVB is somehow a minor improvement that primarily
benefits China because they make most cheap self setting "atomic"
clocks. There are innumerable applications for low cost low power
human level 1 second accurate time of day in modern electronic systems -
examples are traffic lights and school crossing signs and water
sprinklers and street lights and other outdoor lighting and many
others... these systems are not normally network connected and there is
no current wide area technology short of power hungry GPS with its weak
signals and relatively high cost and difficult reception from many
locations to do this.
And with minimal effort to ensure compatibility, there should be
no conflict with use of the same carrier signal as a frequency reference
too... the problem of several decades old antique time and frequency
gear being incompatible seems very minor, and of course we have already
discussed ways to handle this if needed.
And as long as the existing frequency reference use of the
carrier continues to work as a backup to GPS with modern updated gear
that capability hasn't been lost - except maybe if your particular
variety of tin foil hat requires vacuum tube VLF reference gear because
of EMP fears or something similar.
I think the new WWVB proposal seems sensible and a reasonable
design...that should serve the public well.
--
Dave Emery N1PRE/AE, die@dieconsulting.com DIE Consulting, Weston,
Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole
- in
celebration of what could have been, but wasn't and is not to be now
either."
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I received the following message from John Lowe at NIST.
I thought it might be of interest to you.
-----Original Message-----
From: John Lowe [mailto:lowe@boulder.nist.gov]
Sent: Monday, July 09, 2012 12:55 PM
To: Ron Ward
Subject: Re: Phase-locking 60 kHz timing and frequency standard
receivers
We are changing the format to improve our reception capability.
Frequency standard comparisons will still be possible with new or
modified equipment.
On 7/5/2012 9:39 AM, Ron Ward wrote:
Hi John:
Why is WWVB changing to BPSK? For cheaper clocks?
What about frequency standard comparisons with WWVB?
How am I going to monitor GPS and ensure that it's working correctly and
not being played with by DOD?
What am I going to do with our phase-locking 60 kHz timing and frequency
standard receivers?
Why did you not make the new data format backward compatible with
existing phase-locking 60 kHz timing and frequency standard receivers,
like they did with black and white to color TV transition in the 1950's?
What about +- 45 degree modulation?
We use to have LORAN, OMEGA, and WWVB.
Thanks,
Ron
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of David I. Emery
Sent: Friday, July 13, 2012 8:35 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Phase modulation detection/NIST plan
On Sat, Jul 14, 2012 at 02:38:34AM +0200, Magnus Danielson wrote:
> I think the PTTI article isn't as much documentation as presentation
of
> general principle, showing details more as to present how it can be
> done, but not necessarily guarantee it will be done that way. Knowing
> the synchronisation sequence, polarity should not be ambiguous. Also
> note that other data such as hours would be known from the AM signal,
so
> we can reverse engineer it. A receiver knowing this sequence will
either
> bootstrap from the AM or attempt straight lock. It's not too hard to
> build a maximum likelihood receiver for it.
I read the article as not a definitive specification frozen in
stone, but as a complete and relatively fully specified proposed design
with perhaps some details subject to adjustment or revision.
The question of absolute versus differential phase shift keying
is, of course, rather fundamental to being able to decode the signal at
one level but at another not terribly central to the core of the design
for a coding and modulation scheme that works at much lower C/N levels
than the AM version did while preserving the legacy AM and its coding
for existing hardware.
SOME place in the design of a differentially coded signal there
has to be a decision whether or not to structure the data encoding so
some specific bit (or more properly symbol) in each frame (or at least
some known frames relative to the time of day) (in this case I mean 1
minute long TOD frame) is of a known absolute reference phase.
If this is done than it becomes possible in a reasonable time to
determine an absolute 60 KHz carrier phase after a fade, if it is not
done and every single bit of data is not absolutely predictable (the
current TOD coding would be absolutely predictable given knowledge of
the time and date and of leap seconds and DST settings, but they make
clear future extensions would probably not have this property as
additional messages are added including emergency messages and the like
which are never predictable) there is no way to reliably decide after a
fade which phase is which as this depends on knowing the number of ones
and zeros in all the frames transmitted since one last saw the signal,
something that is in the general case impossible if the signal has faded
and the bits were not observed.
An absolute encoding has no ambiguity - if one knows the time of
day within a second one knows the transmitted phase except for during
bits that might vary with unknown data (eg emergency messages,
extensions to the standard and newly changed DST and leap second
settings and FEC bits based on them) and MOST bits are always known
phases, especially of course the sync code words. So even with
terribly poor C/N one should be able to relatively quickly resolve the
phase ambiguity after a period of signal loss... and in many cases if
one still has a good idea of the time, within a couple of seconds
(symbols) of signal reacquisition.
On another point, I am not of the school that providing much
better weak signal performance for simple, low power, and cheap LF time
of day clocks using WWVB is somehow a minor improvement that primarily
benefits China because they make most cheap self setting "atomic"
clocks. There are innumerable applications for low cost low power
human level 1 second accurate time of day in modern electronic systems -
examples are traffic lights and school crossing signs and water
sprinklers and street lights and other outdoor lighting and many
others... these systems are not normally network connected and there is
no current wide area technology short of power hungry GPS with its weak
signals and relatively high cost and difficult reception from many
locations to do this.
And with minimal effort to ensure compatibility, there should be
no conflict with use of the same carrier signal as a frequency reference
too... the problem of several decades old antique time and frequency
gear being incompatible seems very minor, and of course we have already
discussed ways to handle this if needed.
And as long as the existing frequency reference use of the
carrier continues to work as a backup to GPS with modern updated gear
that capability hasn't been lost - except maybe if your particular
variety of tin foil hat requires vacuum tube VLF reference gear because
of EMP fears or something similar.
I think the new WWVB proposal seems sensible and a reasonable
design...that should serve the public well.
--
Dave Emery N1PRE/AE, die@dieconsulting.com DIE Consulting, Weston,
Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole
- in
celebration of what could have been, but wasn't and is not to be now
either."
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.