|
|
Thread Tools | Display Modes |
#81
|
|||
|
|||
GPS Units = Show road steepness?
Zen Cycle wrote:
:On Thursday, March 14, 2019 at 1:37:04 PM UTC-4, Radey Shouman wrote: : 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...ch-does-it-cos t-to-have-a-custom-asic-made :********* :FPGA Conversions: ........ :Pros: Low NRE (US$35k is about the lowest). Low minimum quantities (10k units/year). There's also a thriving semi-custom market. The bottom layers are stock, you put your logic in the top two or four. Lots cheaper, there's less mask work. In old (relatively large) processes, it can be pretty cheap, if someone has already done most of the work for you. -- sig 50 |
Ads |
#82
|
|||
|
|||
GPS Units = Show road steepness?
On 3/14/2019 3:59 PM, Zen Cycle wrote:
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. For what it's worth, Cateye says its units use a "4 bit one-chip microcomputer (Crystal controlled oscillator)" See https://www.cateye.com/files/manual_..._HP_ENG_v1.pdf -- - Frank Krygowski |
#83
|
|||
|
|||
GPS Units = Show road steepness?
Zen Cycle writes:
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 surmised that you enjoyed arguing about it because you continue to do so. 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. Where did I say it was a bad thing? 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 continue to be mystified by your suggesting that a complicated algorithm is used when a simple one would suffice. 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. ************** High per-chip cost is totally unsuitable for this application. I base my estimate on what I'm seeing at work. In my previous job the company sold a series of ASICs for multi-function printers, starting about 2001, and I see that costs have come down, but they're still fairly high. 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. It's quite a bit less than that when building something like a mass-market bike computer. It's hard to say how much, because the Chinese contract manufacturers quote a price for everything in the BOM, and source it by some mysterious process. 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. *Someone* could run your house remotely, it just might not be you. 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. -- |
#84
|
|||
|
|||
GPS Units = Show road steepness?
Frank Krygowski writes:
On 3/14/2019 3:59 PM, Zen Cycle wrote: 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. For what it's worth, Cateye says its units use a "4 bit one-chip microcomputer (Crystal controlled oscillator)" See https://www.cateye.com/files/manual_..._HP_ENG_v1.pdf I have never programmed a 4-bit micro, but I suspect division on one of them can make a person cry. -- |
#85
|
|||
|
|||
GPS Units = Show road steepness?
Radey Shouman wrote:
Zen Cycle writes: 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. Hey! Somebody got an employee of the month award, complete with $10 Starbucks gift card for saving that $0.05. |
#86
|
|||
|
|||
GPS Units = Show road steepness?
On Fri, 15 Mar 2019 01:58:37 +0000 (UTC), Ralph Barone
wrote: Radey Shouman wrote: Zen Cycle writes: 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. Hey! Somebody got an employee of the month award, complete with $10 Starbucks gift card for saving that $0.05. A chap I worked with had worked for Ford Motorcar Co. and had gotten a cash award for showing how they could install 2 fewer sheet metal screws in the firewall of a Ford motorcar. -- Cheers, John B. |
#87
|
|||
|
|||
GPS Units = Show road steepness?
On Thursday, March 14, 2019 at 10:17:21 AM UTC-5, Radey Shouman wrote:
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. -- Well, actually the reed switch is effectively a relay. Takes 1/100 of a second to close in the gap between the sides of the magnet. Computer could be sampling much more often. And a faster speed doesn't give the reed switch enough time to close. |
#88
|
|||
|
|||
GPS Units = Show road steepness?
On 15/3/19 1:47 pm, Mike A Schwab wrote:
Well, actually the reed switch is effectively a relay. Takes 1/100 of a second to close in the gap between the sides of the magnet. Computer could be sampling much more often. And a faster speed doesn't give the reed switch enough time to close. Why does it need to be "sampling"? The switch may be connected to a digital input that generates an interrupt upon a rising (or falling) edge, for example. The ISR could then read and reset a timer/counter since the last rising edge was detected. A counter can keep track of distance travelled. At 60 m/s (in excess of 200km/h), with a nominal 2m circumference, the wheel spins 30 revs per second. A 100 uS timer period would capture the speed of 1 rev with better than 1% accuracy at this speed. So long as it could count to 100,000 (not impossible for a 4 bit computer to handle roll over), it could also measure speed at 1km/h. The screen could be updated with the latest distance or filtered speed every second or when it has changed. -- JS |
#89
|
|||
|
|||
GPS Units = Show road steepness?
Am 15.03.2019 um 03:27 schrieb John B. Slocomb:
Hey! Somebody got an employee of the month award, complete with $10 Starbucks gift card for saving that $0.05. A chap I worked with had worked for Ford Motorcar Co. and had gotten a cash award for showing how they could install 2 fewer sheet metal screws in the firewall of a Ford motorcar. The cost of those 2 screws is not their material value but the time of the worker who has to screw them in. |
#90
|
|||
|
|||
GPS Units = Show road steepness?
On Thu, 14 Mar 2019 06:09:43 -0700 (PDT),
Zen Cycle wrote: On Wednesday, March 13, 2019 at 5:36:37 PM UTC-4, Radey Shouman wrote: 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) Seems I've read somewhere (or heard) that accuracy of some car clocks can be affected if the voltage isn't close enough to the expected 12 volts. I can't find much on the web (in a quick search) to support that possibility, so it may well be wrong. -- Ted Heise West Lafayette, IN, USA |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Pothole gardener stars on Road Rage TV show | Alycidon | UK | 0 | February 10th 16 02:12 PM |
Show off now faces arrest after road damage | Alycidon | UK | 5 | October 5th 15 11:00 PM |
gps units | recycled[_2_] | General | 1 | July 26th 09 11:59 PM |
FS: 2 Polar Power units | Andre | Marketplace | 0 | June 17th 05 12:13 AM |
FS: 2 polar power units | Andre | Marketplace | 0 | June 11th 05 10:49 PM |