Re: [time-nuts] high (spacial) precision GPS in Kickstarter
AFAIK 'normal' RTK does not provide a clock solution. There's something called 4D RTK which does: http://saegnss1.curtin.edu.au/Publications/2010/Feng2010Four.pdf apparently the results can be very good - but I think the errors quoted are for time-transfer between two RTK receivers (?). If there are papers comparing time-transfer with dual-frequency PPP to this 4D RTK I'd be interested.. AW On Sat, Jan 25, 2014 at 4:10 AM, John C. Westmoreland, P.E. j...@westmorelandengineering.com wrote: Hello Daniel, Appears that is precision for position - not necessarily time. I think NIST had a write-up on something very similar. Regards, John Westmoreland On Fri, Jan 24, 2014 at 5:40 PM, Daniel Mendes dmend...@gmail.com wrote: http://www.kickstarter.com/projects/swiftnav/piksi-the-rtk-gps-receiver Has anyone seen this? Any time-nuts utility? Daniel ___ 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] Z3815 receiver transplant now fixed
Hi all, Well I've got it working absolutely perfectly now. My thanks to Dave Brown of this list who sent me a manual for the GT-74! The problem wasn't the receiver output message but the unusual antenna feed situation in the Z3815 that baffled me for a while. Briefly, GPS receivers feed the antenna connection with DC for the amplifier in the antenna and sense when it's under or over current for a software message re antenna health. In the Z3815 the receiver interface 5V antenna power pin is supplied with 5 V but the antenna cable from the receiver is capacitively isolated and possibly loaded (haven't checked yet) on the mother board and the antenna is fed from an independent 5V antenna supply which is monitored on the mother board, hence the alarm situation. I had an antenna directly connected to my new receiver and put a suitable load on the antenna power pin of the Z3815 connector but that didn't solve the problem. It wasn't till I loaded the (non-functional) Z3815 antenna connection that the alarm was cleared. The u.fl antenna lead connector that comes with the receiver would, I think, fit the connection on the mother board. Unfortunately the Chinese u.fl to SMA connector that I wasted $1.60 on was perfidiously the wrong size so I cut off the tiny connector in a fit of pique and terminated it on a BNC. No matter, I can salvage the cable from the old receiver as I'm going to butcher it anyway for the unusual 2mm pitch interface connector. Now that I know what's what I'm going to make a new interface board on which to mount the new receiver and then put it all together again. If anyone here wants to go down the same route, let me know and I'll send you the PCB pattern and schematic. I still use DOS based Easytrax to make PCBs but print to a file which you can output to a printer if you can remember how to drive a DOS window :-) Morris VK3DOC ___ 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.
Re: [time-nuts] high (spacial) precision GPS in Kickstarter
On 25/01/14 11:42, Anders Wallin wrote: AFAIK 'normal' RTK does not provide a clock solution. There's something called 4D RTK which does: http://saegnss1.curtin.edu.au/Publications/2010/Feng2010Four.pdf apparently the results can be very good - but I think the errors quoted are for time-transfer between two RTK receivers (?). If there are papers comparing time-transfer with dual-frequency PPP to this 4D RTK I'd be interested.. I think you need to differentiate between common-view time-transfer and the precision you get from the system itself. RTK uses the carrier phase corrections achieved from known position to kind of high-speed delta signals as received in it's neighbourhood. This affects both the position and time shifts of the receiver. If the RTK base also has a good timebase and is maintained in a good way time-wise, then both position and time gets good corrections. It's about the same type of errors as you get in the difference between common-view time-transfer comparisons. If you only do L1 C/A RTK, then naturally you will benefit from the RTK as you have no double frequency observations of your own. If you have double-frequency receiver, RTK assist to work on the tropospheric corrections and sat orbit and time errors for which a pure double frequency receiver isn't able to crack on it's own. 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.
Re: [time-nuts] Morion MV89A position
On 24/01/14 09:12, Azelio Boriani wrote: This issue has been discussed at length several times. Too much insulation is not necessarily desirable since the oscillator power has to be dissipated and the oven design of the MV89 wasn't meant to be put in a dewar. Better reduce the temperature gradient then fully isolate the OCXO. The upside-down position is not an issue in my opinion. Running it upside-down is by itself not an issue, but do expect that the frequency will shift when you turn it over and do expect that it will be starting a new drift period from the new frequency until it has relaxed. Always be careful with isolation and thermal loading, as the oven loop can turn nasty on you if you are not careful. 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.
Re: [time-nuts] Z3815A date problem fixed?
On 24/01/14 11:59, Morris Odell wrote: Hi all, There was some consternation here 5 months ago when Z3815A GPSDOs began reporting a date 1024 weeks in the past. This was due to a storage overflow condition in the Furuno GPS receiver in the Z3915A. The designers probably never anticipated that they would still be in use 20 years later Oscillator discipline was unaffected as the 1 pps was still good. It's kind of expected that the oscillator discipline works, because all what has happen is that the conversion from GPS time to normal time (being GPS or UTC) has been unable to unwrap the GPS week number properly. It's really a problem with the system than with the receiver. Obsessional types like me looked for a solution. There didn't seem to be any knowledge out there about reprogramming the receivers so it had to be a transplant. Interesting approach. There is two things one can do: Toss in a small PIC/AVR/whatever that modifies the time, or update to a receiver which does not have the issue. You can also just completely ignore the fact :) 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] Help OCXO ID
Hello all, does anyone know what's the OCXO (or else) in this picture? http://www.electronicsurplus.it/open2b/var/catalog/images/1354/0-c26b2bc0-800.jpg I'm trying to understand if it's something worth buying, but I can't find any information on the site other than 5 MHz oven quartz oscillator (and I'm not sure they exactly know even that). Thanks in advance. Frank IZ8DWF ___ 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.
Re: [time-nuts] high (spacial) precision GPS in Kickstarter
I know the Swift Nav guys and they are working on adding various forms of customizable timing inputs and outputs to the Piksi. It's also an open-source project, so it's pretty flexible in that regard. Henry On Sat, Jan 25, 2014 at 4:56 AM, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 25/01/14 11:42, Anders Wallin wrote: AFAIK 'normal' RTK does not provide a clock solution. There's something called 4D RTK which does: http://saegnss1.curtin.edu.au/Publications/2010/Feng2010Four.pdf apparently the results can be very good - but I think the errors quoted are for time-transfer between two RTK receivers (?). If there are papers comparing time-transfer with dual-frequency PPP to this 4D RTK I'd be interested.. I think you need to differentiate between common-view time-transfer and the precision you get from the system itself. RTK uses the carrier phase corrections achieved from known position to kind of high-speed delta signals as received in it's neighbourhood. This affects both the position and time shifts of the receiver. If the RTK base also has a good timebase and is maintained in a good way time-wise, then both position and time gets good corrections. It's about the same type of errors as you get in the difference between common-view time-transfer comparisons. If you only do L1 C/A RTK, then naturally you will benefit from the RTK as you have no double frequency observations of your own. If you have double-frequency receiver, RTK assist to work on the tropospheric corrections and sat orbit and time errors for which a pure double frequency receiver isn't able to crack on it's own. 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.
Re: [time-nuts] high (spacial) precision GPS in Kickstarter
On 25/01/14 22:32, Henry Hallam wrote: I know the Swift Nav guys and they are working on adding various forms of customizable timing inputs and outputs to the Piksi. It's also an open-source project, so it's pretty flexible in that regard. When I looked at it, it was obviously missing. The FPGA code isn't open, but it's the only thing they keep. What the FPGA code does is also a bit unclear. A friend mentioned it to me, and just the other day said they had some form of issues. Hope it works out. 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.
Re: [time-nuts] Z3815A date problem fixed?
Thanks for the reply Magnus. I know the frequency control function is unaffected by the date problem but I'm far too obsessional to ignore it :-) I contemplated the AVR solution to correct the code but once I looked at the output of the receiver with a MAX232 as suggested here, I found there were quite a few different and varying NMEA and proprietary sentences being sent each second and most of them contained the time date in one form or another. Not knowing which ones the Z39815 relies on means they all have to be identified and corrected. Programming an AVR to fix this would not be beyond me but it would be complex and time consuming compared to the receiver transplant and I'd still have to make the hardware for the AVR. It would also mean finding a bit of room inside the Z3815 to fit an AVR board . It's also sort of kludgy, like wearing gloves because your pen leaks. Better, I think, to transplant the receiver. The GT-8031 will suffer a similar fate according to the spec, at midnight on December 31, 2079 but I'll be 130 years old then so probably won't need to replace it again Morris From: Magnus Danielson mag...@rubidium.dyndns.org On 24/01/14 11:59, Morris Odell wrote: Hi all, There was some consternation here 5 months ago when Z3815A GPSDOs began reporting a date 1024 weeks in the past. This was due to a storage overflow condition in the Furuno GPS receiver in the Z3915A. The designers probably never anticipated that they would still be in use 20 years later Oscillator discipline was unaffected as the 1 pps was still good. It's kind of expected that the oscillator discipline works, because all what has happen is that the conversion from GPS time to normal time (being GPS or UTC) has been unable to unwrap the GPS week number properly. It's really a problem with the system than with the receiver. Obsessional types like me looked for a solution. There didn't seem to be any knowledge out there about reprogramming the receivers so it had to be a transplant. Interesting approach. There is two things one can do: Toss in a small PIC/AVR/whatever that modifies the time, or update to a receiver which does not have the issue. You can also just completely ignore the fact :) Cheers, Magnus -- ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts End of time-nuts Digest, Vol 114, Issue 96 ** - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3681/7031 - Release Date: 01/24/14 ___ 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.
