Re: [time-nuts] An embedded NTP server
In message 50e4c479.5080...@earthlink.net, Jim Lux writes: On 1/2/13 11:37 AM, Poul-Henning Kamp wrote: Actually, the OS is not important, floating point support is. floating point support in the sense that the compiler supports it and generates appropriate code to use software FP or hardware FP as available? Either, as long as it is precise and you have room for it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
In message cahjg12qxpb9px8dp6ngk-x575etnsfc+csqr6acsrx7gfw-...@mail.gmail.com , Tom Harris writes: +1 for Forth! Indeed, but for me that is only an indulgence :-) +1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0 chips (e.g. LPC1113) for less than the PIC18 we were using before, and it has a real compiler and (unlike the real world) evidence of intelligent design! ARM is a very intelligent design, unfortunately it is falling prey to the curse that hits any successful CPU: more and more complicated instructions gets added to help this one important case... This curse already claimed IBM's mainframe CPU and x86 cpus, and with the thumb2 set, ARM is caving too. But it is a damn good CPU still. Do you really need an OS? Surely for a box that is only ever going to be an NTP server you just need a network interface and good maths? I've just seen a later comment where you mention floating point support, but would 64 bit integer maths work just as well? Depends how much code you want to write yourself. The advantage of having an OS, is that somebody else maintains a lot of the code for you and you get features like TCP/IP and SSH for free. The disadvantage is that you need more flash to hold all that junk. In general, you should reuse as much code as you can, life is too short to write another UDP checksum subroutine. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
On 1/3/13 12:53 AM, Poul-Henning Kamp wrote: In general, you should reuse as much code as you can, life is too short to write another UDP checksum subroutine. You captured it exactly.. The thrill of implementing sin() is long past. Heck, I'd be happy with something that ran Matlab/Octave/SciPy etc...interpreting and all. ___ 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] An embedded NTP server
On 1/1/2013 4:58 PM, time-nuts-requ...@febo.com wrote: True story: Many years ago when the very first ARM silicon arrived and they started testing it, it was generally execeeding expectations but a little bit flakey at high clock rates. After the bubbly had been drunk and hangovers subdued, the serious testing started and one of the first thing they found was that they had forgotten to hook up VCC: The chip ran entirely on leaked power from the I/O pins, most notably the #RESET pin. When they also connected the VCC pin, it was stable well above spec'ed speed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Ive also seen this, but with a design based on a 8 bit micro running at 50Mhz. Took a while to trace down, because the guy how laid out the board is usually good about power and gnd connections. We found it by putting a volt meter on the VCC pin, and realized it wasn't at 5 volts. (It's surprising how often people don't check VCC voltages on a new layout!) I never figured a 50Mhz proc at ~75mA would run from leakage current into the inputs, but realizing that a lot of I/O have protection diodes, it is probably more common than one would expect. Back on topic (sort of). I've been playing with some of the PIC24 chips lately. They have some neat oscillator options internally, however they seem to have a lot of jitter on I/O compared to other micros that run without a VCO and PLL. Again these PIC's are also designed to be run at low power if necessary. That said, some do have PWM with resolutions down to 1.04nS with special hardware which is impressive. I think it's a DLL locked to ~120Mhz ref clock, locked to an internal RC at ~7.5Mhz. Lots of multiplying going on there! Dan ___ 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] An embedded NTP server
In message 50e45382.8090...@irtelemetrics.com, Dan Kemppainen writes: Back on topic (sort of). I've been playing with some of the PIC24 chips lately. They have some neat oscillator options internally, I've given up on PIC and Atmel microcontrollers and their antiquated CPU designs. My life is too short to fight odd-ball compilers, when I can get a real 32 bit CPU and a good compiler instead. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
On Wed, Jan 2, 2013 at 11:16 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I've given up on PIC and Atmel microcontrollers and their antiquated CPU designs. My life is too short to fight odd-ball compilers, when I can get a real 32 bit CPU and a good compiler instead. That is a valid point if you are building a one-off project. Your time is worth something. But if you plan to sell a million AA cell battery chargers using a 32-bit controller is uneconomical. These will always be a bigger market for 8-bit chips then for 32-bit chips. For an NTP server I'd go with something that can run an OS and the NTP reverence implementation. ARM (and others) can do that. -- Chris Albertson Redondo Beach, California ___ 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] An embedded NTP server
In message CABbxVHuc1CcVqa2fgY_nriNrT3PYHtP8BSi=5=bsbk9eyhl...@mail.gmail.com , Chris Albertson writes: That is a valid point if you are building a one-off project. Your time is worth something. But if you plan to sell a million AA cell battery chargers using a 32-bit controller is uneconomical. But that's generally not what we discuss here on time-nuts, so I didn't feel I needed to state the obvious... For an NTP server I'd go with something that can run an OS and the NTP reverence implementation. ARM (and others) can do that. Actually, the OS is not important, floating point support is. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2013 19:25, Chris Albertson wrote: For an NTP server I'd go with something that can run an OS and the NTP reverence implementation. ARM (and others) can do that. This is exactly what I've done using the Raspberry Pi (Broadcom ARM SOC running Linux) and a GPS module with the PPS kernel hook for Linux GPIO. Still a beginner/aspiring time-nut so I'm not sure on accuracy (PLL offset jitter suggests ~5-10ms worst-case but I've not looked much into measuring it yet), but it's an improvement on internet NTP at least. (Brief writeup here: http://www.talkunafraid.co.uk/2012/12/the-ntpi-accurate-time-with-a-raspberry-pi-and-venus638flpx/ - - be gentle, it's my first 'real' timing project!) James -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlDkjUcACgkQ22kkGnnJQAzbXQCfU6nLKnJ7lPFLGcAZysxaJUuC POsAn3YKaX3IAhk4MbqGnGUNJOSv7oTa =d3dr -END PGP SIGNATURE- ___ 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] An embedded NTP server
From: James Harrison [] This is exactly what I've done using the Raspberry Pi (Broadcom ARM SOC running Linux) and a GPS module with the PPS kernel hook for Linux GPIO. Still a beginner/aspiring time-nut so I'm not sure on accuracy (PLL offset jitter suggests ~5-10ms worst-case but I've not looked much into measuring it yet), but it's an improvement on internet NTP at least. (Brief writeup here: http://www.talkunafraid.co.uk/2012/12/the-ntpi-accurate-time-with-a-raspberry-pi-and-venus638flpx/ - - be gentle, it's my first 'real' timing project!) James James, You might be interested in my write-up: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html and its performance: http://www.satsignal.eu/mrtg/performance_ntp.php I was playing with RasPi-1 today to see whether a different (navigation) GPS receiver or system configuration would make any difference to the oscillatory nature of the offset, hence the big step around 11:00 when the card was restarted after an hour's power down. RasPi-2 with a timing GPS receiver looks better, and it should have an identical configuration to RasPi-1 (except that the USB port is being sent data). Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@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.
Re: [time-nuts] An embedded NTP server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2013 20:05, David J Taylor wrote: James, You might be interested in my write-up: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html and its performance: http://www.satsignal.eu/mrtg/performance_ntp.php I was playing with RasPi-1 today to see whether a different (navigation) GPS receiver or system configuration would make any difference to the oscillatory nature of the offset, hence the big step around 11:00 when the card was restarted after an hour's power down. RasPi-2 with a timing GPS receiver looks better, and it should have an identical configuration to RasPi-1 (except that the USB port is being sent data). Cheers, David Interesting stuff indeed - the timing receiver certainly looks much more stable, which is to be expected. I'm not seeing quite as much stability on my Pi/setup - http://i.imgur.com/6L8ur.png is the munin-measured kernel offset for the last day. I've only been running it for a few days but I'd have thought the clock loop should've stabilized a bit more than it has at present. Could be that this particular GPS receiver isn't managing very well at all to give particularly precise PPS pulses, which is possible given it's a navigational receiver. The datasheet specifies a 60nsec accuracy but it's unclear if that relates to the 1PPS output. Once this one's been running for a few more days I should have some more interesting graphs; I'm getting one of my home boxes set up with Graphite so I can push more detailed statistics and information to that from the RPi about NTP etc and get a better feel for what's going on. Cheers, James -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlDkl9IACgkQ22kkGnnJQAyjxQCfUYma1e8MuRcWD8Ldk0IRHOKy lnQAoK8+Qr0DcADVwFJi0XtGvRC9hPx9 =5JMB -END PGP SIGNATURE- ___ 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] An embedded NTP server
On 1/2/13 11:37 AM, Poul-Henning Kamp wrote: Actually, the OS is not important, floating point support is. floating point support in the sense that the compiler supports it and generates appropriate code to use software FP or hardware FP as available? Or you need HW floating point for performance. (after all, I ran floating point FORTRAN code on a 4 MHz Z80 with 48k back in the late 70s... not speedy, but it works) We just went through an exercise to enable the use of HW FP on our SPARC processors for flight use. The original gcc tool chain RTEMS setup used software FP, even though the hardware has an FPU. But to implement the GPS receiver, we needed HW FP, so we had to work through all those issues. I don't recall precisely what the issues were (probably something about saving/restoring FPU registers or, at least, not tampering with their contents through an interrupt or library call). The problem wasn't that GCC couldn't generate the right object code, it was something more high level than that. ___ 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] An embedded NTP server
On Wed, Jan 2, 2013 at 12:37 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: Actually, the OS is not important, floating point support is. That is one reason that the recent crop of inexpensive ARM Cortex M4 experimenter boards is quite interesting. I picked up two of the TI Stellaris Launchpads on preorder for $5 each and also snagged a free STM32F3 board (both are Cortex M4). I haven't gotten to them yet, but I have projects in mind (always too many projects and not enough time). I just finished reading a book that described the STM Cortex line in detail. All I can say is wow. What you get for the money is quite impressive. Joe Gray W5JG ___ 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] An embedded NTP server
Hi That's the point I've been trying to make for about a month now. At some point, for a hobby project, the cost of the CPU becomes irrelevant. In my book, once the CPU goes below the price of lunch at McDonalds, it really doesn't matter much. Bob On Jan 2, 2013, at 7:36 PM, Joseph Gray jg...@zianet.com wrote: On Wed, Jan 2, 2013 at 12:37 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: Actually, the OS is not important, floating point support is. That is one reason that the recent crop of inexpensive ARM Cortex M4 experimenter boards is quite interesting. I picked up two of the TI Stellaris Launchpads on preorder for $5 each and also snagged a free STM32F3 board (both are Cortex M4). I haven't gotten to them yet, but I have projects in mind (always too many projects and not enough time). I just finished reading a book that described the STM Cortex line in detail. All I can say is wow. What you get for the money is quite impressive. Joe Gray W5JG ___ 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] An embedded NTP server
On 1/2/13 4:46 PM, Bob Camp wrote: Hi That's the point I've been trying to make for about a month now. At some point, for a hobby project, the cost of the CPU becomes irrelevant. In my book, once the CPU goes below the price of lunch at McDonalds, it really doesn't matter much. yes.. it's all about ease of interfacing and ease of programming. (unless you're making hundreds or 1000s of them) This is why Arduino is so popular.. dead simple for a lot of hackery kinds of things. The first steps on the learning stairway are pretty darn low (to the point that *artists* use them grin.. what is the world of computers coming to?) ___ 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] An embedded NTP server
Hi Arduino's original popularity was based on low cost. These days you can get a *lot* more for your money. Bob On Jan 2, 2013, at 8:07 PM, Jim Lux jim...@earthlink.net wrote: On 1/2/13 4:46 PM, Bob Camp wrote: Hi That's the point I've been trying to make for about a month now. At some point, for a hobby project, the cost of the CPU becomes irrelevant. In my book, once the CPU goes below the price of lunch at McDonalds, it really doesn't matter much. yes.. it's all about ease of interfacing and ease of programming. (unless you're making hundreds or 1000s of them) This is why Arduino is so popular.. dead simple for a lot of hackery kinds of things. The first steps on the learning stairway are pretty darn low (to the point that *artists* use them grin.. what is the world of computers coming to?) ___ 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] An embedded NTP server
+1 for Forth! +1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0 chips (e.g. LPC1113) for less than the PIC18 we were using before, and it has a real compiler and (unlike the real world) evidence of intelligent design! Do you really need an OS? Surely for a box that is only ever going to be an NTP server you just need a network interface and good maths? I've just seen a later comment where you mention floating point support, but would 64 bit integer maths work just as well? On 3 January 2013 06:25, Chris Albertson albertson.ch...@gmail.com wrote: On Wed, Jan 2, 2013 at 11:16 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I've given up on PIC and Atmel microcontrollers and their antiquated CPU designs. My life is too short to fight odd-ball compilers, when I can get a real 32 bit CPU and a good compiler instead. That is a valid point if you are building a one-off project. Your time is worth something. But if you plan to sell a million AA cell battery chargers using a 32-bit controller is uneconomical. These will always be a bigger market for 8-bit chips then for 32-bit chips. For an NTP server I'd go with something that can run an OS and the NTP reverence implementation. ARM (and others) can do that. -- Chris Albertson Redondo Beach, California ___ 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. -- Tom Harris celephi...@gmail.com ___ 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] An embedded NTP server
On 1/2/13 5:34 PM, Tom Harris wrote: +1 for Forth! +1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0 chips (e.g. LPC1113) for less than the PIC18 we were using before, and it has a real compiler and (unlike the real world) evidence of intelligent design! Do you really need an OS? Surely for a box that is only ever going to be an NTP server you just need a network interface and good maths? I've just seen a later comment where you mention floating point support, but would 64 bit integer maths work just as well? Well, one might not need a full-up multitasking OS, but I'd sure like to have a high level interface to the network (say BSD sockets or something like that). And most OSes (or OS-like infrastructure) also gives you some handy stuff like timers, threads, queues, etc. If you are doing something that is TRULY single function, the one big loop scheme can work, particularly if you've got a lot of nice libraries to do stuff like string handling/parsing/device interaction. I think the dividing line might be where you are trying to do more than one thing with different time scales. It would be straightforward to do something like multiple PID loops with a common sample/update rate (like a lot of PLC industrial controllers do), but as soon as you start running things at different rates (check the Ethernet, check the serial port, update the loop, etc.) having an OS to do the book-keeping is pretty nice. ___ 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] An embedded NTP server
On 01/02/2013 08:34 PM, Tom Harris wrote: Do you really need an OS? Surely for a box that is only ever going to be an NTP server you just need a network interface and good maths? I've just seen a later comment where you mention floating point support, but would 64 bit integer maths work just as well? You certainly do not need an OS. For this project I am using a RTOS called ChibiOS that provides a threading interface and handles the tedium of flinging packets as well as timers, serial, etc. but it's not an OS in the same sense as Linux is and I'm still interacting directly with the critical peripherals. Since the PPS measurements are being done in dedicated hardware and the Ethernet interface is a hard-wired MAC and not USB, it performs quite a bit better than something with the overhead of a managed OS. Raspberry Pi and some other Linux-ready boards I've seen also use Ethernet interfaces built into the USB host, not quite sure why that's more cost-effective but it's sure to result in much poorer jitter versus a direct MAC. I'm using a F1 part which does not have a FPU, so all the math is 64bit integers. Soft floats are also an option, and for even the fanciest GPSDO there's not nearly enough number crunching going on to make a FPU absolutely necessary. ___ 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] An embedded NTP server
On 03/01/13 03:26, Jim Lux wrote: On 1/2/13 5:34 PM, Tom Harris wrote: +1 for Forth! +1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0 chips (e.g. LPC1113) for less than the PIC18 we were using before, and it has a real compiler and (unlike the real world) evidence of intelligent design! Do you really need an OS? Surely for a box that is only ever going to be an NTP server you just need a network interface and good maths? I've just seen a later comment where you mention floating point support, but would 64 bit integer maths work just as well? Well, one might not need a full-up multitasking OS, but I'd sure like to have a high level interface to the network (say BSD sockets or something like that). And most OSes (or OS-like infrastructure) also gives you some handy stuff like timers, threads, queues, etc. If you are doing something that is TRULY single function, the one big loop scheme can work, particularly if you've got a lot of nice libraries to do stuff like string handling/parsing/device interaction. It fails quite quickly if you have not though through the real time execution needs. Essentially, what execute when, triggered by what, with what data and how late can it be, and what else needs to be done? Real time properties does not need to be resolved by a real-time operating system, but it needs to be resolved by doing the real time analysis, and then attempting to find stable solutions. Bare-bone processors can work just as well, but things like HW-drivers, lack of network support etc. can be trouble-some. I think the dividing line might be where you are trying to do more than one thing with different time scales. It would be straightforward to do something like multiple PID loops with a common sample/update rate (like a lot of PLC industrial controllers do), but as soon as you start running things at different rates (check the Ethernet, check the serial port, update the loop, etc.) having an OS to do the book-keeping is pretty nice. If it gives the needed infrastructure. It can just as well keep the confusion high enough that the issues becomes fuzzidized enough for you not to see them clearly. Also, do not underestimate what a little HW/FW-support can do to relax requirements significantly, or for that matter seemingly trivial OS support features. HW/FW timestamping is one. Good quality timer support another. Just grabbing an RTOS and believing that it will solve all problems will not work. I've seen it fail miserably. I all to often see people expecting a few lines of code to solve bad system design, so do the system design and figure out your needs, then figure out what hardware and software platforms support those needs the best. You end up with a few alternatives and then iterate a good solution. It's always in the nitty gritty details, so few wide assumptions work very well. 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] An embedded NTP server
how about a Propeller? 8 cpu's no waiting :-) Don Magnus Danielson On 03/01/13 03:26, Jim Lux wrote: On 1/2/13 5:34 PM, Tom Harris wrote: +1 for Forth! +1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0 chips (e.g. LPC1113) for less than the PIC18 we were using before, and it has a real compiler and (unlike the real world) evidence of intelligent design! Do you really need an OS? Surely for a box that is only ever going to be an NTP server you just need a network interface and good maths? I've just seen a later comment where you mention floating point support, but would 64 bit integer maths work just as well? Well, one might not need a full-up multitasking OS, but I'd sure like to have a high level interface to the network (say BSD sockets or something like that). And most OSes (or OS-like infrastructure) also gives you some handy stuff like timers, threads, queues, etc. If you are doing something that is TRULY single function, the one big loop scheme can work, particularly if you've got a lot of nice libraries to do stuff like string handling/parsing/device interaction. It fails quite quickly if you have not though through the real time execution needs. Essentially, what execute when, triggered by what, with what data and how late can it be, and what else needs to be done? Real time properties does not need to be resolved by a real-time operating system, but it needs to be resolved by doing the real time analysis, and then attempting to find stable solutions. Bare-bone processors can work just as well, but things like HW-drivers, lack of network support etc. can be trouble-some. I think the dividing line might be where you are trying to do more than one thing with different time scales. It would be straightforward to do something like multiple PID loops with a common sample/update rate (like a lot of PLC industrial controllers do), but as soon as you start running things at different rates (check the Ethernet, check the serial port, update the loop, etc.) having an OS to do the book-keeping is pretty nice. If it gives the needed infrastructure. It can just as well keep the confusion high enough that the issues becomes fuzzidized enough for you not to see them clearly. Also, do not underestimate what a little HW/FW-support can do to relax requirements significantly, or for that matter seemingly trivial OS support features. HW/FW timestamping is one. Good quality timer support another. Just grabbing an RTOS and believing that it will solve all problems will not work. I've seen it fail miserably. I all to often see people expecting a few lines of code to solve bad system design, so do the system design and figure out your needs, then figure out what hardware and software platforms support those needs the best. You end up with a few alternatives and then iterate a good solution. It's always in the nitty gritty details, so few wide assumptions work very well. 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. -- Neither the voice of authority nor the weight of reason and argument are as significant as experiment, for thence comes quiet to the mind. De Erroribus Medicorum, R. Bacon, 13th century. If you don't know what it is, don't poke it. Ghost in the Shell Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ 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] An embedded NTP server
Not only SSH access, loggin g things like DNS lookup and rading the ntp.comf file from local (flash?) memory. And then without an OS you'd have to implement sceduling and process creation yourself. How else to accept SSH log ins, talk to multiple NT clients and yu reference clocks and write to the log server all at the same time? The trouble is that if you decide to go with an OS all of this becomes easy because it is already available for ARM and any other platforms the OS runs on. On Wed, Jan 2, 2013 at 10:44 PM, David J Taylor david-tay...@blueyonder.co.uk wrote: From: Tom Harris +1 for Forth! +1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0 chips (e.g. LPC1113) for less than the PIC18 we were using before, and it has a real compiler and (unlike the real world) evidence of intelligent design! Do you really need an OS? Surely for a box that is only ever going to be an NTP server you just need a network interface and good maths? I've just seen a later comment where you mention floating point support, but would 64 bit integer maths work just as well? == Having an OS makes access to things like SNMP for monitoring, SSL for control, and Samba for log extraction and management easier. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@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. -- Chris Albertson Redondo Beach, California ___ 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] An embedded NTP server
Hi The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less… Bob On Dec 31, 2012, at 10:56 PM, Michael Tharp g...@partiallystapled.com wrote: On 12/28/2012 12:34 PM, Chris Albertson wrote: One idea that I like is to first get a large FPGA. Then you load in a soft CPU and then you run an OS and NTP on the soft CPU. Inside the softCPU the counter is implemented like it is in a real CPU but you can add the ability for a PPS to latch it. Basicaly you move the interrupt handler to hardware. The trick is if you can get good enough performance out of the soft CPU?There is some intelectual property problems with some soft CPS but I'm pretty sure there are free SPARC CPS you can use and SPARC is ideal for this as it can run BSD Unix. Most microcontrollers that I have seen (PIC, ARM, presumably AVR as well) already have a peripheral called input capture that does exactly this, and that's what my project is using. Since it's part of the timer peripheral it usually runs at (up to) the same speed as the CPU which in my case is 72MHz, plenty for a decent lock. It simply grabs the current value of the counter when a pulse arrives and saves it until the CPU can get around to retrieving it. To get another order of magnitude the next step would be an analog TDC or a FPGA running a vernier TDC, but you can get quite satisfactory results with just an off-the-shelf microcontroller. Free CPU cores for FPGAs are not a problem, I have investigated a little and come up with a few candidates. Right now my favorite would be a microblaze clone called aemb, but there is also light8080 (tiny but 8-bit is a headache) and OpenRISC (fat but full-featured). There is a free vernier TDC core as well that is made available by CERN. They are using it in their White Rabbit system which does some rather neat things with custom Ethernet transceivers and switches that can distribute time across significant lengths of fiber to very good precision. I have not yet dedicated enough time to finish wiring the TDC to a CPU but I have made some progress; it synthesizes but is not yet operating correctly. I will be the first to admit I am not very experienced with FPGAs but given enough time and interest it can be made to work. -- m. tharp ___ 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] An embedded NTP server
On Tue, 1 Jan 2013 11:23:57 -0500 Bob Camp li...@rtty.us wrote: The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less… What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] An embedded NTP server
On 01/01/13 17:34, Attila Kinali wrote: On Tue, 1 Jan 2013 11:23:57 -0500 Bob Campli...@rtty.us wrote: The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less… What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Many CMOS PLL solutions work like that. For instance, one chip I recall has a ~2.4 GHz oscillator, divides that down on the output side and then have input and feedback dividers as well. The benefit is that the tuning range of the core VCO can be fairly low, and you get decent jitter that way. For higher rates N-phase oscillators is used, typically 4-phase. Playing tricks which how those phases are used can keep divider noises down when doing fractional division rates. 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] An embedded NTP server
Hi Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the CPU is running at half or a quarter of that. Bob On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@kinali.ch wrote: On Tue, 1 Jan 2013 11:23:57 -0500 Bob Camp li...@rtty.us wrote: The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less… What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] An embedded NTP server
Hoi Bob, On Tue, 1 Jan 2013 12:03:49 -0500 Bob Camp li...@rtty.us wrote: On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@kinali.ch wrote: What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the CPU is running at half or a quarter of that. That's why i was specifically asking about those uC which use a higher frequency VCO for their clock generation. Ie not the tiny 8bit stuff, but those in the ARM7/Cortex-M3 class. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] An embedded NTP server
Hi The little Arm7/ Cortex-M3 micro's don't pay as much attention to the clock chain as some of their bigger brothers (like a Sandy Bridge I7) do. At least the M3's and M4's I have seen are running the VCO at 50 to 150 MHz to generate a CPU clock at that frequency. The clock is divided by two for the RAM clock, and divided by two again for the flash clock. They may be doing a fake out on the VCO frequency. If they are, it's well hidden. Bob On Jan 1, 2013, at 1:14 PM, Attila Kinali att...@kinali.ch wrote: Hoi Bob, On Tue, 1 Jan 2013 12:03:49 -0500 Bob Camp li...@rtty.us wrote: On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@kinali.ch wrote: What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the CPU is running at half or a quarter of that. That's why i was specifically asking about those uC which use a higher frequency VCO for their clock generation. Ie not the tiny 8bit stuff, but those in the ARM7/Cortex-M3 class. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] An embedded NTP server
Hi I'm not bashing the Arm parts, they are nice gizmos. They don't do the clock chains the way they do because they are lazy. They very much plan things out. Their main target audience is low power portable gear. Having a part that drops down to very low current when nothing much is going on is one of their goals. That drives them to keep the clocks / VCO's as slow as they possibly can. They worry about every uA of current drain… Bob On Jan 1, 2013, at 1:14 PM, Attila Kinali att...@kinali.ch wrote: Hoi Bob, On Tue, 1 Jan 2013 12:03:49 -0500 Bob Camp li...@rtty.us wrote: On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@kinali.ch wrote: What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the CPU is running at half or a quarter of that. That's why i was specifically asking about those uC which use a higher frequency VCO for their clock generation. Ie not the tiny 8bit stuff, but those in the ARM7/Cortex-M3 class. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] An embedded NTP server
In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@rtty.us, Bob Camp writes: I'm not bashing the Arm parts, [...] They worry about every uA of current drain True story: Many years ago when the very first ARM silicon arrived and they started testing it, it was generally execeeding expectations but a little bit flakey at high clock rates. After the bubbly had been drunk and hangovers subdued, the serious testing started and one of the first thing they found was that they had forgotten to hook up VCC: The chip ran entirely on leaked power from the I/O pins, most notably the #RESET pin. When they also connected the VCC pin, it was stable well above spec'ed speed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
I have had that problem more than once. Missing Vcc on a chip but the thing runs, just not necessarily well enough, or well enough to go through the next level of test. I have also used it when adding an inverter somewhere on a clock line, and a decoupling cap on the inverter's Vcc is enough to keep it running. Saves a jumper. Didier Sent from my Droid Razr 4G LTE wireless tracker. -Original Message- From: Poul-Henning Kamp p...@phk.freebsd.dk To: Discussion of precise time and frequency measurement time-nuts@febo.com, Bob Camp li...@rtty.us Sent: Tue, 01 Jan 2013 2:16 PM Subject: Re: [time-nuts] An embedded NTP server In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@rtty.us, Bob Camp writes: I'm not bashing the Arm parts, [...] They worry about every uA of current drain True story: Many years ago when the very first ARM silicon arrived and they started testing it, it was generally execeeding expectations but a little bit flakey at high clock rates. After the bubbly had been drunk and hangovers subdued, the serious testing started and one of the first thing they found was that they had forgotten to hook up VCC: The chip ran entirely on leaked power from the I/O pins, most notably the #RESET pin. When they also connected the VCC pin, it was stable well above spec'ed speed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
The NXP LPC111x series has a PLL that runs at 156 to 320 MHz. You then divide the clock down (internally by 2,4,8, or 16) to what you want. 50 MHz is the max. for the LPC111x series. Giving you capture ticks in 20nS increments. I have some experiments in the works with an LPC1114 chip and a 40 MHz DSA222MAB TCVCXO clock (divided by 2 for the LPC1114 input). But those experiments are just at the schematic stage. I do have the LPC1114s and the DSA222MABs in hand. Simon Engineering is the art of making what you want from what you can get at a profit. ___ 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] An embedded NTP server
In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si mon writes: The NXP LPC111x series [...] My personal preference is the LPC1343, because it has a USB port, and because there is a reltively nice codebase to start from: https://github.com/microbuilder/LPC1343CodeBase -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
On 1/1/13 12:16 PM, Poul-Henning Kamp wrote: In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@rtty.us, Bob Camp writes: I'm not bashing the Arm parts, [...] They worry about every uA of current drain True story: Many years ago when the very first ARM silicon arrived and they started testing it, it was generally execeeding expectations but a little bit flakey at high clock rates. After the bubbly had been drunk and hangovers subdued, the serious testing started and one of the first thing they found was that they had forgotten to hook up VCC: The chip ran entirely on leaked power from the I/O pins, most notably the #RESET pin. When they also connected the VCC pin, it was stable well above spec'ed speed. more than one person (including me) has found out that with boards powered from their I/O interfaces rather than the power supply that they forgot to turn on. It's a huge deal in the spacecraft world because of the desire to do cross strapped redundancy with cold spares. Is the interface truly dead faced? And if you have a pyro actuated cable cutter, what happens if power from one wire couples into an interface for an unpowered unit? ___ 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] An embedded NTP server
The design I'm working on brings out the UART pins to a header. I am designing adapter boards for RS-232 (using a MAX232 type equivalent) or USB using the FT232RL chip for the USB interface. There will also be an I2C interface for a display (16X2 to start with) or what have you. (more serial ports is one option) The code base is not going to be critical because I'm using Forth rather than C. I am no fan of C. And neither is my software guy who at one time managed 5,000 ATT programmers. The Forth is going to be pretty primitive to start with (assembler macros). But we may turn it into a full blown Forth as time goes on. When the first round is done and working we will publish a complete design (schematics and code - with bare boards available at a nominal cost). I like the LPC111x series because of its very low cost. I do have plans to move up to some of the higher series chips once this design is done - if I can figure out how to solder chips by hand that have pins on .5mm ctrs. Currently I can solder chips with .65 mm lead spacing without too much trouble. Simon Engineering is the art of making what you want from what you can get at a profit. From: Poul-Henning Kamp p...@phk.freebsd.dk To: M. Simon msimon6...@yahoo.com; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, January 1, 2013 9:26 PM Subject: Re: [time-nuts] An embedded NTP server In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si mon writes: The NXP LPC111x series [...] My personal preference is the LPC1343, because it has a USB port, and because there is a reltively nice codebase to start from: https://github.com/microbuilder/LPC1343CodeBase -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
I should add that the first published design will probably be a frequency/period counter. It will have an input for an external 10 MHz reference. Simon Engineering is the art of making what you want from what you can get at a profit. From: Poul-Henning Kamp p...@phk.freebsd.dk To: M. Simon msimon6...@yahoo.com; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, January 1, 2013 9:26 PM Subject: Re: [time-nuts] An embedded NTP server In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si mon writes: The NXP LPC111x series [...] My personal preference is the LPC1343, because it has a USB port, and because there is a reltively nice codebase to start from: https://github.com/microbuilder/LPC1343CodeBase -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] An embedded NTP server
Hi The VCO is part of the process, the PLL and it's loop are another part. There's no reason why they can't put a good loop in a micro, other than chip area for the passive parts. What ever they do, the loop will probably be a compromise, since the frequencies involved are not known at design time. A 4 MHz reference and a 40 MHz reference will need different loop components running a 100 MHz VCO …. Bob On Jan 1, 2013, at 3:45 PM, M. Simon msimon6...@yahoo.com wrote: The NXP LPC111x series has a PLL that runs at 156 to 320 MHz. You then divide the clock down (internally by 2,4,8, or 16) to what you want. 50 MHz is the max. for the LPC111x series. Giving you capture ticks in 20nS increments. I have some experiments in the works with an LPC1114 chip and a 40 MHz DSA222MAB TCVCXO clock (divided by 2 for the LPC1114 input). But those experiments are just at the schematic stage. I do have the LPC1114s and the DSA222MABs in hand. Simon Engineering is the art of making what you want from what you can get at a profit. ___ 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] An embedded NTP server
Yay for Forth! Don M. Simon The design I'm working on brings out the UART pins to a header. I am designing adapter boards for RS-232 (using a MAX232 type equivalent) or USB using the FT232RL chip for the USB interface. There will also be an I2C interface for a display (16X2 to start with) or what have you. (more serial ports is one option) The code base is not going to be critical because I'm using Forth rather than C. I am no fan of C. And neither is my software guy who at one time managed 5,000 ATT programmers. The Forth is going to be pretty primitive to start with (assembler macros). But we may turn it into a full blown Forth as time goes on. When the first round is done and working we will publish a complete design (schematics and code - with bare boards available at a nominal cost). I like the LPC111x series because of its very low cost. I do have plans to move up to some of the higher series chips once this design is done - if I can figure out how to solder chips by hand that have pins on .5mm ctrs. Currently I can solder chips with .65 mm lead spacing without too much trouble. Simon Engineering is the art of making what you want from what you can get at a profit. From: Poul-Henning Kamp p...@phk.freebsd.dk To: M. Simon msimon6...@yahoo.com; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, January 1, 2013 9:26 PM Subject: Re: [time-nuts] An embedded NTP server In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si mon writes: The NXP LPC111x series [...] My personal preference is the LPC1343, because it has a USB port, and because there is a reltively nice codebase to start from: https://github.com/microbuilder/LPC1343CodeBase -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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. -- Neither the voice of authority nor the weight of reason and argument are as significant as experiment, for thence comes quiet to the mind. De Erroribus Medicorum, R. Bacon, 13th century. If you don't know what it is, don't poke it. Ghost in the Shell Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ 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] An embedded NTP server
On 12/28/2012 12:34 PM, Chris Albertson wrote: One idea that I like is to first get a large FPGA. Then you load in a soft CPU and then you run an OS and NTP on the soft CPU. Inside the softCPU the counter is implemented like it is in a real CPU but you can add the ability for a PPS to latch it. Basicaly you move the interrupt handler to hardware. The trick is if you can get good enough performance out of the soft CPU?There is some intelectual property problems with some soft CPS but I'm pretty sure there are free SPARC CPS you can use and SPARC is ideal for this as it can run BSD Unix. Most microcontrollers that I have seen (PIC, ARM, presumably AVR as well) already have a peripheral called input capture that does exactly this, and that's what my project is using. Since it's part of the timer peripheral it usually runs at (up to) the same speed as the CPU which in my case is 72MHz, plenty for a decent lock. It simply grabs the current value of the counter when a pulse arrives and saves it until the CPU can get around to retrieving it. To get another order of magnitude the next step would be an analog TDC or a FPGA running a vernier TDC, but you can get quite satisfactory results with just an off-the-shelf microcontroller. Free CPU cores for FPGAs are not a problem, I have investigated a little and come up with a few candidates. Right now my favorite would be a microblaze clone called aemb, but there is also light8080 (tiny but 8-bit is a headache) and OpenRISC (fat but full-featured). There is a free vernier TDC core as well that is made available by CERN. They are using it in their White Rabbit system which does some rather neat things with custom Ethernet transceivers and switches that can distribute time across significant lengths of fiber to very good precision. I have not yet dedicated enough time to finish wiring the TDC to a CPU but I have made some progress; it synthesizes but is not yet operating correctly. I will be the first to admit I am not very experienced with FPGAs but given enough time and interest it can be made to work. -- m. tharp ___ 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] An embedded NTP server
On Thu, Dec 27, 2012 at 1:36 AM, Hal Murray hmur...@megapathdsl.net wrote: It would be interesting to see what ntpd would do on a system with a very good clock and/or what you could do to the code/heuristics to take advantage of a stable clock. I've read reports of people who have un-soldered the crystal from a motherboard and replaced it with a connection to somethig much more stable. The result is a more stable clock adjustment but not a more accurate NTP server. The bottleneck is not the oscillator. It is the uncertiantly in the interrupt latency on the PPS. If you want a much improved NTP server you need to build an external nanosecond counter and then modify NTP and the OS to read this counter rather than the internal one.So this could not work on Windows or any closed source OS. Then you use a hardware latch to shapshot the external counter when the PPS happens.The current system does the snapshot inside the interrupt handler, then sets a bit to indicate a new sample is available, the captured count is read by the background process. Building a counter that runs at 1GHz is not to hard but connecting it so the computer's OS can read it with very low latency is harder. Maybe the counter is built on a PCI card? It couldn't go on a USB port One idea that I like is to first get a large FPGA. Then you load in a soft CPU and then you run an OS and NTP on the soft CPU. Inside the softCPU the counter is implemented like it is in a real CPU but you can add the ability for a PPS to latch it. Basicaly you move the interrupt handler to hardware. The trick is if you can get good enough performance out of the soft CPU?There is some intelectual property problems with some soft CPS but I'm pretty sure there are free SPARC CPS you can use and SPARC is ideal for this as it can run BSD Unix. -- Chris Albertson Redondo Beach, California ___ 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] An embedded NTP server
Hi Much easier to simply use a cheap chip set (as in sub $3) that supports 1588 packet time stamping. It's doing everything you would need to do as far as packet time of arrival. The heavy lifting would all be in the area of porting that data into the NTP server. Bob On Dec 28, 2012, at 12:34 PM, Chris Albertson albertson.ch...@gmail.com wrote: On Thu, Dec 27, 2012 at 1:36 AM, Hal Murray hmur...@megapathdsl.net wrote: It would be interesting to see what ntpd would do on a system with a very good clock and/or what you could do to the code/heuristics to take advantage of a stable clock. I've read reports of people who have un-soldered the crystal from a motherboard and replaced it with a connection to somethig much more stable. The result is a more stable clock adjustment but not a more accurate NTP server. The bottleneck is not the oscillator. It is the uncertiantly in the interrupt latency on the PPS. If you want a much improved NTP server you need to build an external nanosecond counter and then modify NTP and the OS to read this counter rather than the internal one.So this could not work on Windows or any closed source OS. Then you use a hardware latch to shapshot the external counter when the PPS happens.The current system does the snapshot inside the interrupt handler, then sets a bit to indicate a new sample is available, the captured count is read by the background process. Building a counter that runs at 1GHz is not to hard but connecting it so the computer's OS can read it with very low latency is harder. Maybe the counter is built on a PCI card? It couldn't go on a USB port One idea that I like is to first get a large FPGA. Then you load in a soft CPU and then you run an OS and NTP on the soft CPU. Inside the softCPU the counter is implemented like it is in a real CPU but you can add the ability for a PPS to latch it. Basicaly you move the interrupt handler to hardware. The trick is if you can get good enough performance out of the soft CPU?There is some intelectual property problems with some soft CPS but I'm pretty sure there are free SPARC CPS you can use and SPARC is ideal for this as it can run BSD Unix. -- Chris Albertson Redondo Beach, California ___ 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] An embedded NTP server
On 12/28/12 9:34 AM, Chris Albertson wrote: On Thu, Dec 27, 2012 at 1:36 AM, Hal Murray hmur...@megapathdsl.net wrote: One idea that I like is to first get a large FPGA. Then you load in a soft CPU and then you run an OS and NTP on the soft CPU. Inside the softCPU the counter is implemented like it is in a real CPU but you can add the ability for a PPS to latch it. Basicaly you move the interrupt handler to hardware. The trick is if you can get good enough performance out of the soft CPU?There is some intelectual property problems with some soft CPS but I'm pretty sure there are free SPARC CPS you can use and SPARC is ideal for this as it can run BSD Unix. The LEON core for the SPARC V8 is free and available from gaisler.com. The free version doesn't come with testbenches or support, but all the source and documentation is there. There's a fairly active mailing list for support with participation by the guys who implemented the core. It's a fairly easy drop in to either Xilinx or Actel FPGAs, and it's configurable (e.g. if you don't want floating point you don't compile it in). There is are several prebuilt versions of *nix as well as RTEMS for the core on the gaisler website as well. There's a IPv4 stack for RTEMS, derived from the BSD stack. ___ 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] An embedded NTP server
albertson.ch...@gmail.com said: The VXCO quality hardly matters for an NTP server. As long as it does not gain out loose more then 1 uSecond per second. In other words one part per million is fine for NTP. The goal is not to produce a 10MHz GDPDO. Clients using this server over the Ethernet are happy to keep time ti 1 millisecond. This is time nuts. It's always fair game to discuss how good things are and/or how to make them better. :) The reference NTP package goes to a lot of work to figure out how far off the clock is and tell the kernel so it can keep (much) better time. In many systems, that's a pretty good thermometer. Another thing the reference package tries to do is stretch out the polling interval to minimize load on the network and servers. It's trying to find the bottom of the ADEV curve. The default range is 64-1024 seconds. It keeps track of it on disk to PPB. That doesn't work very well if the temperature/frequency isn't stable. The temperature swing with load change has probably gotten worse with newer machines. It would be interesting to see what ntpd would do on a system with a very good clock and/or what you could do to the code/heuristics to take advantage of a stable clock. Most (almost all) NTP servers use a TTL can oscillator. Are you sure? Or what's the current practice? A while ago (several/many years?) it was common for Intel boxes to have a clock generator chip. They ran off the standard 14.xxx MHz crystal and generated clocks for the CPU, PCI, USB, ... It usually included the spread spectrum hack. The ARM SOC chips I've worked with had similar stuff on chip. You connect up a crystal. It has an amplifier to make an oscillator and PLLs to make whatever clocks are needed. -- These are my opinions. I hate spam. ___ 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] An embedded NTP server
On 12/27/2012 01:41 AM, Michael Tharp wrote: The good news is that the disciplining algorithm I lifted from my previous GPSDO project works quite well, and I have the gritty details of measuring the PPS worked out. If I can get the Trimble working tomorrow I might have much better results soon, otherwise I'm traveling for a few days so it'll have to wait until the new year. And here we go, it works. Much more reasonable, tens-of-microseconds jitter figures. [root@rei ~]# ntpq -pn remote refid st t when poll reach delay offset jitter == -138.236.128.36 216.218.254.202 2 u 21 1024 377 68.8193.228 0.641 +108.59.14.130 209.51.161.238 2 u 298 1024 377 34.9201.167 0.288 +108.61.73.244 96.47.67.105 2 u 300 1024 377 39.5241.135 1.604 -64.6.144.6 128.252.19.1 2 u 772 1024 377 84.3296.609 0.252 *172.24.0.6 .GPS.1 u2 16 3770.320 -0.073 0.016 -172.24.0.66 135.34.116.162 3 u 237 1024 3770.1970.130 0.581 x172.24.0.68 172.24.0.6 2 u 291 1024 3770.237 113.341 77.665 -172.24.0.1 172.24.0.6 2 u 287 512 3770.1232.382 0.876 [root@maruko ~]# ntpq -pn remote refid st t when poll reach delay offset jitter == -67.18.187.111 129.7.1.66 2 u 965 1024 37 66.6951.952 0.842 +174.129.25.69 131.188.3.2212 u 753 1024 377 35.9261.734 0.250 *2001:470:1:15b: 132.239.1.6 2 u 513 1024 377 107.2400.982 0.373 -172.24.0.1 172.24.0.6 2 u 786 1024 3770.1872.960 1.027 +172.24.0.6 .GPS.1 u 55 16 3770.356 -0.008 0.060 -172.24.0.64 108.59.14.1303 u 912 1024 3770.3010.058 0.685 x172.24.0.68 135.6.140.0 3 u 938 1024 3770.378 243.604 166.234 [root@hanmyo ~]# ntpq -pn remote refid st t when poll reach delay offset jitter == *172.24.0.6 .GPS.1 u 25 64 3770.399 -2.390 0.258 172.24.0.64 172.24.0.6 2 u9 1024 3770.134 -2.273 0.708 -172.24.0.66 135.34.116.162 3 u 342 512 3770.216 -2.607 1.728 172.24.0.68 172.24.0.6 2 u 300 512 3770.092 245.910 124.378 -72.251.251.11 62.192.15.2123 u 22 1024 377 122.988 -0.097 1.585 +67.18.187.111 129.7.1.66 2 u 270 512 377 66.916 -1.235 3.977 -199.7.177.206 64.147.116.229 2 u 368 512 377 59.0353.838 1.815 +50.97.210.169 131.107.13.100 2 u8 1024 377 100.0032.547 1.025 hanmyo (172.24.0.1) is a small digital engine computer that I use as a router; it is pretty much 100% idle, has no fans, and is located in a closet where it is temperature stable. At the same time, it shows by far the highest jitter figure so I'm guessing its clock is not very good. I will have to probe around and see if there is something I can replace, because it is the best candidate for characterizing the performance of my little NTP server. It's hard to get quality measurements when the peer boxes are just ordinary desktops. I've only been testing this new firmware for ~30m so I will let it soak while I'm traveling and when I get back the numbers should look even better. -- m. tharp ___ 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] An embedded NTP server
Michael, Which version of Meinberg's NTP build did you install? I've had problems with high jitter content on one of them. Rob -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Michael Tharp Sent: 25 December 2012 20:44 To: time-nuts@febo.com Subject: Re: [time-nuts] An embedded NTP server On 12/25/2012 02:51 PM, David J Taylor wrote: I think you should be able to do better on the jitter as your algorithms develop. Yes, for starters something is causing a silly amount of extra latency hence the 2.4ms round-trip. I managed to cut that in half by changing compiler options but talking to someone using the same stack I should be able to get it down to ~ 400us round-trip, at worst. I have some ideas on how to achieve that but I want to get all the functionality working before I start optimizing. The main lack of functionality, which may or may not be the cause of the jitter, is that I haven't actually integrated the PLL/disciplining stuff yet. I just have a timer that resets with each GPS pulse, and runs at whatever nominal frequency the oscillator has. Not great but it succeeded at getting results fast. Not up to time-nuts standards though. Now I'm going back and adding the PLL. SNTP does imply something else, so perhaps avoid calling it that, although if it doesn't respond to all the NTP management calls I'm unsure what it should be called! I suppose that I could call it NTP and still sleep at night since, while not a traditional NTP implementation, it does still feature control loops similar to those found in purely software-based NTP. I have not yet looked at what administrative/query functionality I could implement. Some of it like listing peers does not make sense but perhaps other commands could be mapped to make it more complete. I would also like to expose some of the internal statistics via SNMP or some other means for graphing. Oh, and your Windows box 172.24.0.68 is either poorly configured or broken - they can work much, much better than yours illustrates as I expect you know. Yes, it's not healthy. I installed Meinberg's NTP build and configured it using defaults other than the server list but it seems to not be tracking well. Right now it's only 30ms off but as shown in the forum snippet it makes excursions into the hundreds. Still an improvement over default Windows timekeeping but I'd love for it to work properly. -- m. tharp ___ 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] An embedded NTP server
From: Michael Tharp [] Oh, and your Windows box 172.24.0.68 is either poorly configured or broken - they can work much, much better than yours illustrates as I expect you know. Yes, it's not healthy. I installed Meinberg's NTP build and configured it using defaults other than the server list but it seems to not be tracking well. Right now it's only 30ms off but as shown in the forum snippet it makes excursions into the hundreds. Still an improvement over default Windows timekeeping but I'd love for it to work properly. -- m. tharp == Michael, for comparison, I've put up a couple of plots of Windows using Internet-only servers running on Windows-7 and Windows-8 PCs. The Windows-8 PC should be better as it has a more precise GetSystemTime API (it's called GetSystemTimePreciseAsFileTime). This is using the newish POOL directive which provides about 10 NTP servers. http://www.satsignal.eu/ntp/Win-8+Internet.html Roll the mouse over the different captions below the graphs to see the various statistics. The Windows-7 PC shows offsets in the range 10 - 20 ms, with averaged jitter in the 3 - 9 ms range. Were my Internet connection more heavily loaded these figures could be worse. Windows-8 has offsets in the -3 to +5.5 ms range, with averaged jitter eventually 0.4 to 0.6 ms. I guess if your Internet connection is not as good as mine you might be seeing such large offsets. These are running a recent NTP development version which you could download from: http://www.satsignal.eu/ntp/x86/index.html and I would recommend this as it has significant improvements over the Meinberg in the Windows port. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@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.
[time-nuts] An embedded NTP server
You don't mention the quality of your VCXO. Do you have a part # or else specs i.e. ppm vs temp, time, voltage, etc. Nice pic btw. And that looks like an OSH Park gold plated board. I love their service. Simon === Message: 1 Date: Tue, 25 Dec 2012 12:18:30 -0500 From: Michael Tharp g...@partiallystapled.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: [time-nuts] An embedded NTP server Message-ID: 50d9dfe6.2050...@partiallystapled.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello and Merry Christmas, I made an embedded (S)NTP server. The software is still under development and will eventually include a low-grade GPSDO but right now even the simplistic algorithm is working quite well so I figured I'd share. http://www.eevblog.com/forum/oshw/%27laureline%27-embedded-gps-ntp-server/ This is a low-level microcontroller implementation, there is no OS nor ntpd in the traditional sense. Just enough logic to keep time using the incoming PPS and timestamps, and a tiny VCXO to discipline. It's no Thunderbolt and there is no clock output but it should be fantastic at NTP. Before too long I will have adapters for connecting to Oncore GT+/UT+ (and maybe M12, haven't checked) as well as Trimble Resolution T and Resolution SMT using a ribbon cable instead of the jumper wires. All open-source hardware and software. Pictures, details, and design documents are in the eevblog thread. I'll let you all know if and when I'm ready to sell them, for now I just wanted to show what I've got. -- m. tharp Engineering is the art of making what you want from what you can get at a profit. ___ 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] An embedded NTP server
The VXCO quality hardly matters for an NTP server. As long as it does not gain out loose more then 1 uSecond per second. In other words one part per million is fine for NTP. The goal is not to produce a 10MHz GDPDO. Clients using this server over the Ethernet are happy to keep time ti 1 millisecond. Most (almost all) NTP servers use a TTL can oscillator. On Wed, Dec 26, 2012 at 4:41 AM, M. Simon msimon6...@yahoo.com wrote: You don't mention the quality of your VCXO. Do you have a part # or else specs i.e. ppm vs temp, time, voltage, etc. Nice pic btw. And that looks like an OSH Park gold plated board. I love their service. Simon === Message: 1 Date: Tue, 25 Dec 2012 12:18:30 -0500 From: Michael Tharp g...@partiallystapled.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: [time-nuts] An embedded NTP server Message-ID: 50d9dfe6.2050...@partiallystapled.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello and Merry Christmas, I made an embedded (S)NTP server. The software is still under development and will eventually include a low-grade GPSDO but right now even the simplistic algorithm is working quite well so I figured I'd share. http://www.eevblog.com/forum/oshw/%27laureline%27-embedded-gps-ntp-server/ This is a low-level microcontroller implementation, there is no OS nor ntpd in the traditional sense. Just enough logic to keep time using the incoming PPS and timestamps, and a tiny VCXO to discipline. It's no Thunderbolt and there is no clock output but it should be fantastic at NTP. Before too long I will have adapters for connecting to Oncore GT+/UT+ (and maybe M12, haven't checked) as well as Trimble Resolution T and Resolution SMT using a ribbon cable instead of the jumper wires. All open-source hardware and software. Pictures, details, and design documents are in the eevblog thread. I'll let you all know if and when I'm ready to sell them, for now I just wanted to show what I've got. -- m. tharp Engineering is the art of making what you want from what you can get at a profit. ___ 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. -- Chris Albertson Redondo Beach, California ___ 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] An embedded NTP server
On 12/26/2012 12:01 PM, Chris Albertson wrote: The VXCO quality hardly matters for an NTP server. As long as it does not gain out loose more then 1 uSecond per second. In other words one part per million is fine for NTP. The goal is not to produce a 10MHz GDPDO. Clients using this server over the Ethernet are happy to keep time ti 1 millisecond. Most (almost all) NTP servers use a TTL can oscillator. Indeed, it's just a chip VCXO. Not much of an additional cost, and it can be disciplined in hardware. In a PC, the main oscillator is not tunable so the kernel has to emulate a tunable clock by tweaking the numbers on the way out. Now that I have the disciplining algorithm implemented I immediately discovered a problem -- and it's not my hardware. The receiver I assumed was a UT+ is actually a R1121N1145, which doesn't support position hold. But even worse, the PPS seems to jump forward by precisely 1ms every 16-20s and sticks that way. This probably explains the mediocre jitter of 0.3-0.6ms in the NTP results I posted on the 25th. With enough smoothing I can probably make it work, but in the meantime I will switch to using the Trimble receiver which I know works well. My goal with this project was always to support as many receivers as possible but the 100mil pitch header on the Oncore is much more convenient so that's where I started. The good news is that the disciplining algorithm I lifted from my previous GPSDO project works quite well, and I have the gritty details of measuring the PPS worked out. If I can get the Trimble working tomorrow I might have much better results soon, otherwise I'm traveling for a few days so it'll have to wait until the new year. -- m. tharp ___ 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] An embedded NTP server
Hello and Merry Christmas, I made an embedded (S)NTP server. The software is still under development and will eventually include a low-grade GPSDO but right now even the simplistic algorithm is working quite well so I figured I'd share. http://www.eevblog.com/forum/oshw/%27laureline%27-embedded-gps-ntp-server/ This is a low-level microcontroller implementation, there is no OS nor ntpd in the traditional sense. Just enough logic to keep time using the incoming PPS and timestamps, and a tiny VCXO to discipline. It's no Thunderbolt and there is no clock output but it should be fantastic at NTP. Before too long I will have adapters for connecting to Oncore GT+/UT+ (and maybe M12, haven't checked) as well as Trimble Resolution T and Resolution SMT using a ribbon cable instead of the jumper wires. All open-source hardware and software. Pictures, details, and design documents are in the eevblog thread. I'll let you all know if and when I'm ready to sell them, for now I just wanted to show what I've got. -- m. tharp ___ 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] An embedded NTP server
Hello and Merry Christmas, I made an embedded (S)NTP server. The software is still under development and will eventually include a low-grade GPSDO but right now even the simplistic algorithm is working quite well so I figured I'd share. http://www.eevblog.com/forum/oshw/%27laureline%27-embedded-gps-ntp-server/ This is a low-level microcontroller implementation, there is no OS nor ntpd in the traditional sense. Just enough logic to keep time using the incoming PPS and timestamps, and a tiny VCXO to discipline. It's no Thunderbolt and there is no clock output but it should be fantastic at NTP. Before too long I will have adapters for connecting to Oncore GT+/UT+ (and maybe M12, haven't checked) as well as Trimble Resolution T and Resolution SMT using a ribbon cable instead of the jumper wires. All open-source hardware and software. Pictures, details, and design documents are in the eevblog thread. I'll let you all know if and when I'm ready to sell them, for now I just wanted to show what I've got. -- m. tharp = Fascinating, Michael, a most interesting development. Excellent work! I think you should be able to do better on the jitter as your algorithms develop. SNTP does imply something else, so perhaps avoid calling it that, although if it doesn't respond to all the NTP management calls I'm unsure what it should be called! Oh, and your Windows box 172.24.0.68 is either poorly configured or broken - they can work much, much better than yours illustrates as I expect you know. Merry Christmas! David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@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.
Re: [time-nuts] An embedded NTP server
On 12/25/2012 02:51 PM, David J Taylor wrote: I think you should be able to do better on the jitter as your algorithms develop. Yes, for starters something is causing a silly amount of extra latency hence the 2.4ms round-trip. I managed to cut that in half by changing compiler options but talking to someone using the same stack I should be able to get it down to ~ 400us round-trip, at worst. I have some ideas on how to achieve that but I want to get all the functionality working before I start optimizing. The main lack of functionality, which may or may not be the cause of the jitter, is that I haven't actually integrated the PLL/disciplining stuff yet. I just have a timer that resets with each GPS pulse, and runs at whatever nominal frequency the oscillator has. Not great but it succeeded at getting results fast. Not up to time-nuts standards though. Now I'm going back and adding the PLL. SNTP does imply something else, so perhaps avoid calling it that, although if it doesn't respond to all the NTP management calls I'm unsure what it should be called! I suppose that I could call it NTP and still sleep at night since, while not a traditional NTP implementation, it does still feature control loops similar to those found in purely software-based NTP. I have not yet looked at what administrative/query functionality I could implement. Some of it like listing peers does not make sense but perhaps other commands could be mapped to make it more complete. I would also like to expose some of the internal statistics via SNMP or some other means for graphing. Oh, and your Windows box 172.24.0.68 is either poorly configured or broken - they can work much, much better than yours illustrates as I expect you know. Yes, it's not healthy. I installed Meinberg's NTP build and configured it using defaults other than the server list but it seems to not be tracking well. Right now it's only 30ms off but as shown in the forum snippet it makes excursions into the hundreds. Still an improvement over default Windows timekeeping but I'd love for it to work properly. -- m. tharp ___ 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] An embedded NTP server
This is good. And really good that you have opened the design. Once a few of these get out into the wild you can start seeing software contributions and the performance will improve. We know that an ARM based NTP server can do very well. Hopefully it can one day beat a low-end Linux setup which runs in the few uSecond range. You should be able to do it. Does the uP have enough RAM to run a stripped down OS, some kind of tiny Linux? On Tue, Dec 25, 2012 at 12:44 PM, Michael Tharp g...@partiallystapled.com wrote: On 12/25/2012 02:51 PM, David J Taylor wrote: I think you should be able to do better on the jitter as your algorithms develop. Yes, for starters something is causing a silly amount of extra latency hence the 2.4ms round-trip. I managed to cut that in half by changing compiler options but talking to someone using the same stack I should be able to get it down to ~ 400us round-trip, at worst. I have some ideas on how to achieve that but I want to get all the functionality working before I start optimizing. The main lack of functionality, which may or may not be the cause of the jitter, is that I haven't actually integrated the PLL/disciplining stuff yet. I just have a timer that resets with each GPS pulse, and runs at whatever nominal frequency the oscillator has. Not great but it succeeded at getting results fast. Not up to time-nuts standards though. Now I'm going back and adding the PLL. SNTP does imply something else, so perhaps avoid calling it that, although if it doesn't respond to all the NTP management calls I'm unsure what it should be called! I suppose that I could call it NTP and still sleep at night since, while not a traditional NTP implementation, it does still feature control loops similar to those found in purely software-based NTP. I have not yet looked at what administrative/query functionality I could implement. Some of it like listing peers does not make sense but perhaps other commands could be mapped to make it more complete. I would also like to expose some of the internal statistics via SNMP or some other means for graphing. Oh, and your Windows box 172.24.0.68 is either poorly configured or broken - they can work much, much better than yours illustrates as I expect you know. Yes, it's not healthy. I installed Meinberg's NTP build and configured it using defaults other than the server list but it seems to not be tracking well. Right now it's only 30ms off but as shown in the forum snippet it makes excursions into the hundreds. Still an improvement over default Windows timekeeping but I'd love for it to work properly. -- m. tharp ___ 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. -- Chris Albertson Redondo Beach, California ___ 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.
