Hi everyone, I am currently trying to repeat previous work of members of this list in convincing the REF 0, to run standalone with a given 1PPS signal from a gps. Similar to: https://syncchannel.blogspot.se/2015/08/standalone-operation-of-lucent-ks-24361.html I am using a skytraq gps with 100ms, 74AC04 for inverting and level shifting and I added the jumper wires on J5. I simulate the Oncore messages with a python script using a usb->uart cable and triggering on the 1PPS pulse on the CTS line. I am sending @@Ea, @@En, @@Bb, @@Ap, @@Aw, @@Ag, @@At, @@Az, @@Bj, @@Bo with a delay of 75 ms, as suggested in the blog above: https://github.com/thpe/oncore/blob/master/oncore_emu.py Surprisingly, I have a constant delay of 0.8 ms, and only a jitter of +/-0.1 ms for the oncore messages compared to the pulse on the CTS line. Short everything is working and if I force external 1PPS usage it locks to it (NO GPS light goes off). Using pForth: 1 force_ext_1pps 1 force_gps_1pps But, it does not do it on its own, since it ignores the tracking mode for the satellites and, I guess after reading the Z3801A manual, therefore it claims the GPS 1PPS signal as invalid. E.g., for the entry with @@Ea: 0x02, 0x08, 0xFF, 0x82 meaning satellite 2 in mode 8 (used for positioning) it assumes mode 0. The other values, like signal strength 0xFF and channel status 0x82 are taken, even if I change them to something else. The mode value is ignored no matter what it says. In the attached files on sees that "GPS 1PPS Invalid: not tracking", and the mode of the is 0. I forced it to use the external 1PPS signal. So, the question what tiny detail did I miss while reading the mailing list archive and those blogs on how to set the REF 0 up for standalone operation just using the Oncore messages? Does someone has dump of the communication between REF 1 and REF 0, until the REF 0 is happy (I don't have a REF 1)? Regards, Thomas DK6KD SA6CID

Hi The only serial dialog between the two units is a repeat of the output of the GPS module. My guess is that there is some subtle difference between the Oncore data and they skytraq…. Bob > On Feb 6, 2017, at 1:23 PM, Thomas Petig <thomas@petig.eu> wrote: > > Hi everyone, > I am currently trying to repeat previous work of members of this list in > convincing the REF 0, to run standalone with a given 1PPS signal from a > gps. Similar to: > https://syncchannel.blogspot.se/2015/08/standalone-operation-of-lucent-ks-24361.html > > I am using a skytraq gps with 100ms, 74AC04 for inverting and level > shifting and I added the jumper wires on J5. I simulate the Oncore > messages with a python script using a usb->uart cable and triggering on > the 1PPS pulse on the CTS line. I am sending @@Ea, @@En, @@Bb, @@Ap, > @@Aw, @@Ag, @@At, @@Az, @@Bj, @@Bo with a delay of 75 ms, as suggested > in the blog above: > https://github.com/thpe/oncore/blob/master/oncore_emu.py > > Surprisingly, I have a constant delay of 0.8 ms, and only a jitter of > +/-0.1 ms for the oncore messages compared to the pulse on the CTS line. > > Short everything is working and if I force external 1PPS usage it locks > to it (NO GPS light goes off). Using pForth: > 1 force_ext_1pps > 1 force_gps_1pps > > But, it does not do it on its own, since it ignores the tracking mode > for the satellites and, I guess after reading the Z3801A manual, > therefore it claims the GPS 1PPS signal as invalid. E.g., for the entry > with @@Ea: > 0x02, 0x08, 0xFF, 0x82 > meaning satellite 2 in mode 8 (used for positioning) it assumes mode 0. > The other values, like signal strength 0xFF and channel status 0x82 are > taken, even if I change them to something else. The mode value is > ignored no matter what it says. > > In the attached files on sees that "GPS 1PPS Invalid: not tracking", and > the mode of the is 0. I forced it to use the external 1PPS signal. > > So, the question what tiny detail did I miss while reading the mailing > list archive and those blogs on how to set the REF 0 up for standalone > operation just using the Oncore messages? > > Does someone has dump of the communication between REF 1 and > REF 0, until the REF 0 is happy (I don't have a REF 1)? > > Regards, > Thomas > DK6KD > SA6CID > <pstat.txt><print_stat.txt>_______________________________________________ > 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, Thank you for your reply. As always, the solution appears after sending the mail on the list. I send a wrong character for terminating the message and therefore the REF 0 was confused when the message ends (it expected 0x0D 0x0A, but got 0x0D 0xA0 from me). It seems that in pForth, pr_gps_debug will count this as frame error. Regarding my setup, I am sending the Oncore messages from Python via a USB cable. I just trigger the Python script on the PPS, I don't read the actual what the skytraq sends. It seems the REF 0 is happy with the timing of my Oncore messages. Regards, Thomas DK6KD SA6CID On Mon, Feb 06, 2017 at 03:40:23PM -0500, Bob Camp wrote: > Hi > > The only serial dialog between the two units is a repeat of the output of the > GPS module. My guess is that there is some subtle difference between > the Oncore data and they skytraq…. > > Bob > > > On Feb 6, 2017, at 1:23 PM, Thomas Petig <thomas@petig.eu> wrote: > > > > Hi everyone, > > I am currently trying to repeat previous work of members of this list in > > convincing the REF 0, to run standalone with a given 1PPS signal from a > > gps. Similar to: > > https://syncchannel.blogspot.se/2015/08/standalone-operation-of-lucent-ks-24361.html > > > > I am using a skytraq gps with 100ms, 74AC04 for inverting and level > > shifting and I added the jumper wires on J5. I simulate the Oncore > > messages with a python script using a usb->uart cable and triggering on > > the 1PPS pulse on the CTS line. I am sending @@Ea, @@En, @@Bb, @@Ap, > > @@Aw, @@Ag, @@At, @@Az, @@Bj, @@Bo with a delay of 75 ms, as suggested > > in the blog above: > > https://github.com/thpe/oncore/blob/master/oncore_emu.py > > > > Surprisingly, I have a constant delay of 0.8 ms, and only a jitter of > > +/-0.1 ms for the oncore messages compared to the pulse on the CTS line. > > > > Short everything is working and if I force external 1PPS usage it locks > > to it (NO GPS light goes off). Using pForth: > > 1 force_ext_1pps > > 1 force_gps_1pps > > > > But, it does not do it on its own, since it ignores the tracking mode > > for the satellites and, I guess after reading the Z3801A manual, > > therefore it claims the GPS 1PPS signal as invalid. E.g., for the entry > > with @@Ea: > > 0x02, 0x08, 0xFF, 0x82 > > meaning satellite 2 in mode 8 (used for positioning) it assumes mode 0. > > The other values, like signal strength 0xFF and channel status 0x82 are > > taken, even if I change them to something else. The mode value is > > ignored no matter what it says. > > > > In the attached files on sees that "GPS 1PPS Invalid: not tracking", and > > the mode of the is 0. I forced it to use the external 1PPS signal. > > > > So, the question what tiny detail did I miss while reading the mailing > > list archive and those blogs on how to set the REF 0 up for standalone > > operation just using the Oncore messages? > > > > Does someone has dump of the communication between REF 1 and > > REF 0, until the REF 0 is happy (I don't have a REF 1)? > > > > Regards, > > Thomas > > DK6KD > > SA6CID > > <pstat.txt><print_stat.txt>_______________________________________________ > > 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. >

There was a fellow time nut that created an Arduino that would control the unit. It faked out what the GPS sent so the unit thought it was connected to a complete system. It works very well the the quality of the unit simply depends on the quality of the 1 pps from the GPS receiver chosen. I used some NEOs but it sounds like there are better receivers. Regards Paul WB8TSL On Tue, Feb 7, 2017 at 5:39 PM, Thomas Petig <thomas@petig.eu> wrote: > Hi, > Thank you for your reply. > As always, the solution appears after sending the mail on the list. I > send a wrong character for terminating the message and therefore the REF > 0 was confused when the message ends (it expected 0x0D 0x0A, but got > 0x0D 0xA0 from me). > > It seems that in pForth, pr_gps_debug will count this as frame error. > > Regarding my setup, I am sending the Oncore messages from Python via a > USB cable. I just trigger the Python script on the PPS, I don't read the > actual what the skytraq sends. It seems the REF 0 is happy with the > timing of my Oncore messages. > > Regards, > Thomas > DK6KD > SA6CID > > On Mon, Feb 06, 2017 at 03:40:23PM -0500, Bob Camp wrote: > > Hi > > > > The only serial dialog between the two units is a repeat of the output > of the > > GPS module. My guess is that there is some subtle difference between > > the Oncore data and they skytraq…. > > > > Bob > > > > > On Feb 6, 2017, at 1:23 PM, Thomas Petig <thomas@petig.eu> wrote: > > > > > > Hi everyone, > > > I am currently trying to repeat previous work of members of this list > in > > > convincing the REF 0, to run standalone with a given 1PPS signal from a > > > gps. Similar to: > > > https://syncchannel.blogspot.se/2015/08/standalone- > operation-of-lucent-ks-24361.html > > > > > > I am using a skytraq gps with 100ms, 74AC04 for inverting and level > > > shifting and I added the jumper wires on J5. I simulate the Oncore > > > messages with a python script using a usb->uart cable and triggering on > > > the 1PPS pulse on the CTS line. I am sending @@Ea, @@En, @@Bb, @@Ap, > > > @@Aw, @@Ag, @@At, @@Az, @@Bj, @@Bo with a delay of 75 ms, as suggested > > > in the blog above: > > > https://github.com/thpe/oncore/blob/master/oncore_emu.py > > > > > > Surprisingly, I have a constant delay of 0.8 ms, and only a jitter of > > > +/-0.1 ms for the oncore messages compared to the pulse on the CTS > line. > > > > > > Short everything is working and if I force external 1PPS usage it locks > > > to it (NO GPS light goes off). Using pForth: > > > 1 force_ext_1pps > > > 1 force_gps_1pps > > > > > > But, it does not do it on its own, since it ignores the tracking mode > > > for the satellites and, I guess after reading the Z3801A manual, > > > therefore it claims the GPS 1PPS signal as invalid. E.g., for the entry > > > with @@Ea: > > > 0x02, 0x08, 0xFF, 0x82 > > > meaning satellite 2 in mode 8 (used for positioning) it assumes mode 0. > > > The other values, like signal strength 0xFF and channel status 0x82 are > > > taken, even if I change them to something else. The mode value is > > > ignored no matter what it says. > > > > > > In the attached files on sees that "GPS 1PPS Invalid: not tracking", > and > > > the mode of the is 0. I forced it to use the external 1PPS signal. > > > > > > So, the question what tiny detail did I miss while reading the mailing > > > list archive and those blogs on how to set the REF 0 up for standalone > > > operation just using the Oncore messages? > > > > > > Does someone has dump of the communication between REF 1 and > > > REF 0, until the REF 0 is happy (I don't have a REF 1)? > > > > > > Regards, > > > Thomas > > > DK6KD > > > SA6CID > > > <pstat.txt><print_stat.txt>_________________________________ > ______________ > > > 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. >