[time-nuts] LTE-Lite module
albertson.chris at gmail.com
Sat Oct 25 19:52:16 UTC 2014
Mostly we don't even write the guts of those algorithms. For example,
you'd use a PID library. One line to create a PID controller object
then one line to call the PID for each phase measurement.
This goes double for, say, drawing a graph of the phase over time to
an LCD display, you'd use a graphic library for that. And for
communicating over USB to a computer. Who would want to take time to
learn the details of USB and LCD graphic controllers? Most code we
write is just "glue" that connects functions.
After a a few decades doing this I'd have to say that reinventing
well-tested wheels is the certain mark of a beginner/amateur. Either
they don't understand how to use these libraries or they don't know
they exist or think they can do it better. They spend 4X longer to
get something working and then it still does not cover all the "corner
cases and exceptions" those libraries might cover.
Ages ago CPU performance or space might mean you HAD to tightly code,
but now even a $1.79 8-bit AVR chip can hold well over the
equivalent of 1,000 lines of C++ code. OK there is the case a
manufactures who wants to be able to use the $1.69 chip and save 10
cents but most projects are not going to be built in high qualities.
Back on-tpic. Now that we have many low cast ($10 and under) uP
development boards building a GPSDO is simple. You don't even need a
custom PCB or many chips. And the simple $10 controller can have a
fancy LCD screen and connect to a computer and log stats and it can
all be up and running in a day or two.
If someone today wanted a harder challenge type project that would
push the state of that art out a little, why not build an "ensemble"
type device? One that accepts PPS timing from several sources,
figures out in realtime which of them to accept then runs several
local oscillators, perhaps an Rb and a couple OCXOs and compares their
outputs. So now you use both Rb and GPS, maybe a few of each to
A while back I tried to prove to myself how easy it is now to build a
GPSDO that was good enough to drive typical lab equipment. Something
like a dozen lines of C code and $8 did it. It's no longer "cutting
edge to built these. Time to think about the next generation kind of
low-cost device. So maybe one could combine the best properties of
several different kinds of devices? Has this been done yet?
On Sat, Oct 25, 2014 at 8:23 AM, Charles Steinmetz
<csteinmetz at yandex.com> wrote:
> Bob wrote:
>> PHK has a roughly 6 line code snippet that does a basic PLL. Add two more
>> lines to check / clamp the integrator if you wish. That's 8 lines. If you
>> want a D term (to give it an FLL component) add 2 more lines. We're up to 10
>> It's just a control loop, not a full GPSDO. There's not a lot to it.
> There's a bit more to it than that. For any loop slow (narrowband) enough
> to be useful disciplining a good OCXO, I consider a dual- or triple-rate
> loop filter to be essential. There is also always a fair amount of
> error-trapping, and other overhead. These can add lines fairly quickly.
> I'm sure I have lots more to learn about writing efficient code. (But note
> that there is a difference between coding one's chosen algorithm more
> efficiently and choosing a different algorithm that is not really what you
> want, just because it is more efficient.)
> Best regards,
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
Redondo Beach, California
More information about the Time-nuts_lists.febo.com