Zen Cycle writes:

On Wednesday, March 13, 2019 at 5:36:37 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:


The simple count method I listed would easily be able to update
current speed with a one-second display refresh rate.

We'll just have to disagree, then. Have you written any embedded
software at all?

Not using a microcontroller/processor as the target. I'm not a
software engineer - quite franlkly it bores the **** out of me.

And yet you are entertained by arguing about it. Odd.

I'm a
hardware engineer. I've written VHDL with Altera and Xilinx targets
for combinatorial boolean blocks and counter/timer functions. It's all
C-based, so not too far removed from 'real' software (our software
team used to like to bust our chops about 'real' SW vs FW/VHDL). Some
were implemented in manufacturing as programmed FPGAs, but a few were
prototypes with the intention of using the resultant structure to
develop an ASIC. This was part of a telecom optical network testing
tool for commissioning optical network switching hubs (aka 'central
office') when I was with a telecom test group at HP in the early
'90s. We specialized in asychronous transfer mode (ATM) protocol error
injection to test the ability of the networks to both detect the
errors and correct them. Our senior scientist got a patent for a
segmentation and reassembly chipset that used the 'leaky bucket'
algorithm. Those were fun times.....

That explains the idea of an ASIC, and the idea that it's simple to count
clocks between two signal edges.

Designing for hardware is much different from software. In hardware,
everything happens at once, which can bite you in the ass. In software,
at least with only one core, you can't do two things at once no matter
how convenient it would be. In hardware, if you have the gates you can
dream up completely new ways of capturing inputs. In software, you use
what the hardware gives you, sometimes ingenuity pays off and you can
use it for an unintended use, but that's not the way to bet.

Consumer electronics is also much different from industrial test
equipment. In consumer software the three most important things a

1. BOM cost
2. BOM cost
3. Schedule, it has to ship in time for Christmas, no matter what.

That's why I don't believe an ASIC is used in bike computers, sure you
could build in a bunch of neat features, but the NRE for a new ASIC,
while it has come down a lot, is still well north of $1M. Making that
back on a product with a wholesale price of a few dollars is just not
easy. Also note #3, picking parts that are available now is the way to
go.


A typical frequency tolerance for an RTC crystal today is +/- 20 ppm.

Frequency tolerance and phase jitter aren't the same thing, but even
so, 20ppm is 2*10e-5. So a typical ~32KHz xtal is accurate to less
than .001 Hz. More than accurate enough for a bike computer.

Nor did I say they were the same. Frequency tolerance is more
interesting.

It depends, Tight frequency tolerance is great, but doesn't help
phased based modulation schemes if your base synthesis has high phase
errors. A crystal with a tight phase tolerance helps keep loop
bandwidth tight, which means higher data throughput for phase based
wireless datacomm protocols in use today (e.g. QAM and its'
derivatives). If you're into wireless IoT, phase tolerance _should_ be
just as interesting as frequency tolerance. FWIW, phase error can have
just as much of an effect on quantization errors as frequency
instability, depending on the sampling technique.

But we were talking about an RTC on a bike computer. I think IoT is a
tool of the Devil, and would hate myself if I helped it spread.

The thing about an RTC that is likely to make users
unhappy is having to adjust the clock time.

I find this aggravating. I know this probably isn't a legit RTC, but
the clock in my car loses a minute per month (no, I'm not
exaggerating), yet I have a ten year old MP3 player I use when working
out that I've never had to rest the clock (I paid $40 for it in
2009). My car is a 2010 element, and it's had this problem since it
was new. I understand from reviewing several internet forums that this
is sort of a known issue, and the dealer said all hondas from that
period that _don't_ have factory navigation systems have this
problem. I understand that saving a few pennies per car means a lot on
the overall cost of the product, but really?

Somebody saved $0.05 on parts. Not always a win.

--