GPS Units = Show road steepness?

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

On Tuesday, March 12, 2019 at 7:14:59 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:

On Tuesday, March 12, 2019 at 2:27:28 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:

On Tuesday, March 12, 2019 at 10:30:52 AM UTC-4, Radey Shouman wrote:
Zen Cycle writes:


Interesting how you characterize it as 'noise'.

For the speedometer the main source of noise is quantization error,
resulting from reducing a continuous wheel position to an integer number
of revolutions.

But that has to do with the digital filtering. I was under the
impression that the ASICS most bike computer companies use calculate
speed by the number of timing pulses between the wheel revolutions. As

As far as I can tell, none of us actually *know* how a bike computer
works internally, we're all guessing, based on personal experience.

I'm pretty sure no bike computer manufacturer is thinking so far
outside the box that that most of us with a reasonable amount of
electronic engineering experience can't make reasonably accurate
assumptions. The biggest issue with companies like cateye, polar,
garmin, etc. is cost. There's simply no reason for them to invest some
sort of proprietary speed calculation algorithm with error correction
when a simple counter and ALU provides more than enough accuracy.

So, Sure, if your sampling period is sufficiently close to the number
of data points, but this is what made Nyquist famous - for greater
accuracy and fewer quantization errors, increase the number of
samples.

However, bicycle computer speed calculations aren't DSPs, even on a
fundamental level. This is still pretty simple math. The number of
rising edges represents an elapsed time between number of reed switch
'clicks'. Then it's simply distance (wheel circumference) over
time. The only significant error inherent in the architecture would be
the point at which the switch contact is measured within the waveform
of one period*. Obviously the click occurring immediately after an
edge is counted would be the same number as the click occurring just
before the next rising edge, so the key is to get as many rising edges
as possible, i.e a higher timer rate. The faster the count between
reed switch 'clicks', the more accurate the speed can be. A 1KHz timer
is probably an order of magnitude more accurate than necessary for a
bicycle, but these days even a 1MHz clock rate is pretty cheap in a
mass produced ASIC.

I wonder what kind of ASIC you think is used for a bike computer.

One that can be used for cycling computer functions. The design
concept is simple - write some code in VHDL that does what you want,
then have a die constructed to perform the function. In large volumes,
this drives manufacturing costs down because you don't have to have a
programming step in the manufacturing process. It also keep the device
smaller and can use less power. I don't know if any manufacturers
actually do this, but I can see it as a business model.

I know what an ASIC is, I just doubt they are used in bike computers.
I have been wrong before.

I
would be amazed to find anything other than a general purpose
microcontroller.

This is probably true if the plan isn't to sell more than a few
thousand units a month.

The problem with higher clock rates is battery
consumption, so there is an incentive to stay as slow as possible.

Considering I've gone for a couple of years in my Polar 720 without
changing the battery, clock rate probably isn't as much of an issue as
you're thinking. The big power pig in any portable device is a display
backlight.



If you're talking about a GPS based speedometer, errors are introduced
in the form of data errors (bit errors). The micro in a GPS based unit
is more than accurate enough to handle the low data rate of the GPS
signal. I know the GPS system transmits FEC data, but I don't know if
the particular receivers in a cycling GPS computer use that code or
not, though I think some smart phones do. I use my phone for strava,
and occasionally I still get a straight line across the map for a
significant period of time, when I was following winding country road.



you mentioned in the other thread, even a 100hz timing pulse is going
to give accurate results well beyond the typical 3 digit display of a
bike computer. This is a simple math function rather than an a/d
conversion, so I don't think quatization error applies here. Speed
calculation could be considered a strict d/a, where the speed display
is an analog number, yet derived purely as a digital process. There
really isn't any 'noise' in speed calculations, except that even at a
constant speed there would be some variation in the number of timing
edges in between the wheel magnet triggers

If you look at the real wheel position versus time at constant speed, it
is a line. The measured position, based on a signal from a reed switch,
is a staircase. If you subtract the real position line from the
staircase measured position line you get a sawtooth wave. The term of
art for the difference between the measured and the actual signal is
"noise". Quantization error is noise, noise is a property of a signal,
not a calculation.

That's a fun calculus exercise, and I know it's a legitimate concern
for applications that require stable and high accuracy, but we're
talking about bicycles here. Sure, keep track of quantization errors
and add correction algorithms for the space shuttle, it just isn't
necessary for bicycles. To invest in that kind of software development
for a bike computer simply isn't cost effective, they'll never get the
NRE return. For us, a simple counter with an ALU is more than
enough. I'd be legitimately shocked if bike computer companies were
applying error correction factors to counting the number of edges on a
timing pulse between revolutions, there simply is no need for that
level of accuracy.

I don't get it, but maybe I'm confounding the various skeptics. On the
one hand they say that specialized algorithms are not likely, yet reject
the most straightforward, standard approach: Sample position in
revolutions at several times the display rate, difference, run through
an IIR filter.

I don't believe that to be the case. I think the most straightforward
and accurate approach is to count clock pulses in between wheel
revolution triggers. From there it's simple math, no digital filtering
needed.

They say the application is simple and the requirements
modest, yet refuse to believe in the possibility of a few seconds lag
(on top of up to 1 sec delay for display).

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?

For the 2-d field of altitudes obtained from a map I
suspect that the quantization of position, ie, the limited number of
data points, perhaps at irregular places, is the main source of noise.

Here I can see the quantization error being an issue, since most bike
computers use a barometric pressure transducer to detect
altitude. Averaging is pretty critical here, and there is the issue of
the transducer a/d then being processed back d/a for the display. As I
mentioned above, short/steep gradients are more likely to be smoothed
over intentionally to get rid of the quantization noise associated
with attempting to oversample the transducer.

How to turn topographical survey data into something that looks like a
continuous function is a whole field of study -- there are many ways to
go wrong, and no one perfect way to do it right.

Sure, but I think that's way beyond the application requirements of a
bicycle computer. There's no reason to over complicate the issue for
us. If this was a military application, or something like flight
computers in a passenger aircraft, the more accurate _and_ fast the
better.


On the issue of 'many ways to do it right' - My company builds
products for oil and gas processing. Some of our products use use dual
microprocessors in an n-version programming architecture. The outputs
of both UPs have to give the same result, or the system shuts down -
this is a failsafe application, not a life support system which would
require redundant (fault tolerant) systems to keep people alive.

Standards (and prices) for your companies products are much higher than
for bike computers, obviously.

Only stated as point of reference. By the same token, we also have a
monitoring device that reads a sensor status for testing outside of
the system. It's a simple off-the-shelf arduino driven device with an
integrated display. We have a junior software engineer that wrote the
code using open source ware. It's cheap, and does exactly what our
customers want. We could have designed an entirely proprietary
architecture, it would have taken months longer, and doubled the cost
of the product. This is much closer to what Cateye and VDO are up to,
I suspect.


In either case, errors that would be fairly small in altitude or
distance become larger when differentiated to estimate speed or
gradient.

I think technology has progressed well beyond the point where that's
an issue even in a cycling computer application.

Sorry, that's nonsense. That differentiating amplifies (high frequency)
noise is a mathematical fact that technology cannot change.

My point was that such considerations are outside the realm of what is
necessary for bicycles. DSP isn't necessary for bicycle computers.


Remember, this whole conversation started because because a guy
claimed his speed increased on flat ground without a tailwind or
pedaling - the idea that he had the display set to average speed is
much more plausible.

Oddly enough, whatever his display showed had to be some approximation
of "average speed", preferably over some short interval. The Platonic
ideal of the magnitude of the derivative of position is just not
directly available to any of us mortals. And that ideal is what the
laws of physics deal with.

--

*Certainly the accuracy of the clock in the system can be considered
to be an inherent error, but considering the phase jitter of even a
cheap timing crystals is on the order of 10e-7 these days, the
measuring accuracy of user inputting the wheel circumference is
several orders of magnitude more significant.

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. The thing about an RTC that is likely to make users
unhappy is having to adjust the clock time.

GPS and Altimeter/speedos cannot use a gate array. Designing a custom chip is possible but why? It would be cheaper to use a uP.

This is reminiscent of the guy telling me he put solar panels on his house and reduced the power bill in the summer by $178. I asked what the panels cost - $40,000. I held my tongue. But it was difficult.

In the winter you save nothing. So let's say that 9 months out of the year you average a savings of $100. This is $900 per year. $40,000/900 = more than 44 years to pay the panels off. The life span is claimed to be 20 years but when I went to a solar show with a friend and talked to the actual engineers it was 10 years to a 50% output.

Radey Shouman wrote:
Radey Shouman writes:

Mike A Schwab writes:

Here is a great article by Sheldon Brown showing how bicycle
cyclometers work. When bladed spokes came out, some units would
register twice the distance at slow speed up to 6 mph 10 kph, so it
can give you an idea of how fast it can register the magnetic field
closing and opening a reed switch in the pickup.

https://www.sheldonbrown.com/cyclecomputer-magnet.html

That does seem to show that, at least at slow speeds, on a high-end
computer, every reed switch pulse is used to compute a new speed. It's
not clear whether the computer fails to register a double pulse at
higher speeds, or that the internal algorithm changes. Either one is
possible.

Oops, posted in haste, and less than half right.

The identified cause was a double pulse on the reed switch signal, the
symptom was, at lower speeds, "a speed readout varying erratically
between 7 and 12 MPH", which was roughly twice the true speed.

The computer worked as expected at higher speeds. The most likely
explanation for that is that analog signal conditioning circuitry
filtered out the double pulses when closer together. A conceivable but
less likely explanation is that software either deliberately or by
accident de-bounced the signal.

Since it worked consistently at high speed, I'm guessing that the
de-bouncing happened sometimes at low speed and sometimes not. If this
wasn't true then I don't have a good explanation.

1) Obviously speed was not computed by the dividing rollout distance by
elapsed time between pulses. In that case the speed reading would
alternate between almost right and very high. Linear filtering would
result in a speed that was much too high. Using the most recent value
would result in a speed that was usually almost right.

2) The speed could have been computed by multiplying the number of
pulses by the rollout distance and dividing by the combined elapsed
time.

3) The speed could equally well have been computed by dividing rollout
distance times number of pulses in a fixed time, by the fixed time, and
then filtering.

4) It's certainly possible that Shimano used some algorithm I'm not
familiar with.

Looking at the output would have given a clue: For (2) we would expect
the speed shown to be either about right or about double. For (3) we
would expect the speed to vary between about right and about double,
with values in between.

So what did "varying erratically" mean? I favor "taking many values
between", but "oscillating irregularly between approximately the same
two values" is not impossible.


.... or when the magnet passed the reed switch at a slow rate of speed, the
switch didn't open or close cleanly, but it did when the magnetic field
changed more quickly.

On Wednesday, March 13, 2019 at 10:52:57 AM UTC-5, Radey Shouman wrote:
Mike A Schwab writes:

Here is a great article by Sheldon Brown showing how bicycle
cyclometers work. When bladed spokes came out, some units would
register twice the distance at slow speed up to 6 mph 10 kph, so it
can give you an idea of how fast it can register the magnetic field
closing and opening a reed switch in the pickup.

https://www.sheldonbrown.com/cyclecomputer-magnet.html

That does seem to show that, at least at slow speeds, on a high-end
computer, every reed switch pulse is used to compute a new speed. It's
not clear whether the computer fails to register a double pulse at
higher speeds, or that the internal algorithm changes. Either one is
possible.

Here is a bicycle handlebar bubble inclineometer if you are still interested.
https://www.amazon.com/Sun-Company-C.../dp/B06XCMXRVP

--

OK. 10,000 meters per hour / 3600 seconds per hour gives 2.78 meters per second. A 700c road tire is about 2.1 meters per revolution, so 1.3 revolution per second. The width of the gap between the magnetic field has to be under 10 MM 0.010 M so 0.013 second minimum time without magnetic field to detect gap between the two sides of the magnetic field. So 100 hz detect frequency???

On Wed, 13 Mar 2019 08:13:15 -0700, sms
wrote:

On 3/11/2019 3:07 PM, AMuzi wrote:

snip

Just wait for eBikes with 'autonomous navigation' a.k.a. 'killer robots'.

Already he https://www.youtube.com/watch?v=LSZPNwZex9s.

I think you meant this video:
https://www.youtube.com/watch?v=6gOjRqlgk_Y

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Thursday, March 14, 2019 at 12:41:11 AM UTC-4, Jeff Liebermann wrote:
On Wed, 13 Mar 2019 08:13:15 -0700, sms
wrote:

On 3/11/2019 3:07 PM, AMuzi wrote:

snip

Just wait for eBikes with 'autonomous navigation' a.k.a. 'killer robots'.

Already he https://www.youtube.com/watch?v=LSZPNwZex9s.

I think you meant this video:
https://www.youtube.com/watch?v=6gOjRqlgk_Y

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

When I saw SMS's video and then saw that the bike was going to be introduced April 1st, I immediately thought it was an early April Fools joke.

Cheers

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. 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.....



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.

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?

Mike A Schwab writes:

On Wednesday, March 13, 2019 at 10:52:57 AM UTC-5, Radey Shouman wrote:
Mike A Schwab writes:

Here is a great article by Sheldon Brown showing how bicycle
cyclometers work. When bladed spokes came out, some units would
register twice the distance at slow speed up to 6 mph 10 kph, so it
can give you an idea of how fast it can register the magnetic field
closing and opening a reed switch in the pickup.

https://www.sheldonbrown.com/cyclecomputer-magnet.html

That does seem to show that, at least at slow speeds, on a high-end
computer, every reed switch pulse is used to compute a new speed. It's
not clear whether the computer fails to register a double pulse at
higher speeds, or that the internal algorithm changes. Either one is
possible.

Here is a bicycle handlebar bubble inclineometer if you are still
interested.
https://www.amazon.com/Sun-Company-C.../dp/B06XCMXRVP

--

OK. 10,000 meters per hour / 3600 seconds per hour gives 2.78 meters
per second. A 700c road tire is about 2.1 meters per revolution, so
1.3 revolution per second. The width of the gap between the magnetic
field has to be under 10 MM 0.010 M so 0.013 second minimum time
without magnetic field to detect gap between the two sides of the
magnetic field. So 100 hz detect frequency???

When I threw out 100 Hz I was imagining a solution based on software
interrupt handling -- that was a WAG, and I doubt that's actually what
is used. I would pick a micro with hardware encoder input that can be
configured to count step and direction, so everything happens in
hardware. 13 ms is a long time in that case.


--

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.

--

On Wednesday, March 13, 2019 at 5:04:39 PM UTC-7, Ralph Barone wrote:
Radey Shouman wrote:
Radey Shouman writes:

Mike A Schwab writes:

Here is a great article by Sheldon Brown showing how bicycle
cyclometers work. When bladed spokes came out, some units would
register twice the distance at slow speed up to 6 mph 10 kph, so it
can give you an idea of how fast it can register the magnetic field
closing and opening a reed switch in the pickup.

https://www.sheldonbrown.com/cyclecomputer-magnet.html

That does seem to show that, at least at slow speeds, on a high-end
computer, every reed switch pulse is used to compute a new speed. It's
not clear whether the computer fails to register a double pulse at
higher speeds, or that the internal algorithm changes. Either one is
possible.

Oops, posted in haste, and less than half right.

The identified cause was a double pulse on the reed switch signal, the
symptom was, at lower speeds, "a speed readout varying erratically
between 7 and 12 MPH", which was roughly twice the true speed.

The computer worked as expected at higher speeds. The most likely
explanation for that is that analog signal conditioning circuitry
filtered out the double pulses when closer together. A conceivable but
less likely explanation is that software either deliberately or by
accident de-bounced the signal.

Since it worked consistently at high speed, I'm guessing that the
de-bouncing happened sometimes at low speed and sometimes not. If this
wasn't true then I don't have a good explanation.

1) Obviously speed was not computed by the dividing rollout distance by
elapsed time between pulses. In that case the speed reading would
alternate between almost right and very high. Linear filtering would
result in a speed that was much too high. Using the most recent value
would result in a speed that was usually almost right.

2) The speed could have been computed by multiplying the number of
pulses by the rollout distance and dividing by the combined elapsed
time.

3) The speed could equally well have been computed by dividing rollout
distance times number of pulses in a fixed time, by the fixed time, and
then filtering.

4) It's certainly possible that Shimano used some algorithm I'm not
familiar with.

Looking at the output would have given a clue: For (2) we would expect
the speed shown to be either about right or about double. For (3) we
would expect the speed to vary between about right and about double,
with values in between.

So what did "varying erratically" mean? I favor "taking many values
between", but "oscillating irregularly between approximately the same
two values" is not impossible.


... or when the magnet passed the reed switch at a slow rate of speed, the
switch didn't open or close cleanly, but it did when the magnetic field
changed more quickly.

Ralph, in most magnets only a single pole is pointed at the switch. In other cases the bar magnet parallels the spoke but only a single poll trips the switch. There is a point at which the switch won't trip but it seems to be an either or situation.

On Thursday, March 14, 2019 at 1:37:04 PM UTC-4, Radey Shouman wrote:
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 didn't write that I don't have any experience at it - I've been involved in code reviews at my various positions for over 30 years. In my current position, one of my responsibilities is maintaining and updating Labwindows CVI (also c-based) for our manufacturing ATE, and even then I've been caught sleeping with my fingers on the keyboard. IF I had to write those whole 10K+ lines of code from scratch.....ugh.


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.

You don't say...

In hardware,
everything happens at once, which can bite you in the ass.

Well, that's the first I've heard that concurrent task handling and speed are a bad thing, though I do remember having to write synchronizers into the combinatorial sections because the propagation delay took us a bit by surprise. This wasn't exactly a bad problem to have.

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.

Right, that's why earlier I wrote "To invest in that kind of software development [quantization error correction] for a bike computer simply isn't cost effective, they'll never get the NRE return. For us, a simple counter with an ALU is more than enough". You're suggesting an ASIC won't give the return on investment - which can be true - and I'm suggesting quantization error correction won't give the return.


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.


Nah....from https://electronics.stackexchange.co...stom-asic-made

*********
FPGA Conversions: ........

Pros: Low NRE (US$35k is about the lowest). Low minimum quantities (10k units/year).

Cons: High per-chip costs-- maybe 50% the cost of an FPGA. Low performance, relative to the other solutions.
**************

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.

Considering that a cheesy 8 bit Microchip ucontroller is about $5 in the 100's it's likely you're right - most non-gps bike computers are probably ucontroller based.




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.

Right, just bringing things into perspective. Quantization error correction and crystal stability can be critical issues in certain applications, I just don't think bike computers are one of them

I think IoT is a
tool of the Devil, and would hate myself if I helped it spread.

LOL....I like that, I may use it the next time it's brought up in one of our market requirements review meetings. I personally have no use for IoT, but I have several friends and co-workers that want to run their whole house from their smart phone. I tell them I'd rather ride my bike.


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.

Right, remember this?

https://en.wikipedia.org/wiki/Genera...switch_recalls

"The company continued to recall more of its cars over the next several months, resulting in nearly 30 million cars worldwide recalled and paid compensation for 124 deaths. The fault had been known to GM for at least a decade prior to the recall being declared. As part of a Deferred Prosecution Agreement, GM agreed to forfeit $900 million to the United States."

All to save a couple of bucks on the ignition switch, which had already been redesigned for the problem before the cars went into production. At least my clock isn't going cause any deaths.