Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Radey Shouman <shouman@comcast.net>
Newsgroups: rec.bicycles.tech
Subject: Re: Suspension losses
Date: Tue, 14 Jan 2025 11:51:17 -0500
Organization: None of the above
Lines: 216
Message-ID: <87y0zdcpa2.fsf@mothra.hsd1.ma.comcast.net>
References: <vlcoil$n7o7$1@dont-email.me>
	<dva1ojp9dah7npllc8qmukmndqih94sbtj@4ax.com>
	<vlqs89$3b77g$3@dont-email.me>
	<7ee2ojpq2b75m6gsd5svace02b19qassrk@4ax.com>
	<beh2ojhsarrl8p37i446fenvlm4sa4tac8@4ax.com>
	<vlsfta$a60l$1@dont-email.me>
	<led5oj98n5et2ocr2tgvdlp2683c3qe41l@4ax.com>
	<vlv3dq$r4s1$8@dont-email.me>
	<cn38ojd35canqdv4pq2sqrgo4pcuupsh3p@4ax.com>
	<vm1sds$1g6ul$1@dont-email.me>
	<gps9oj9j428a2i8rf8ope35464dcuv5ffb@4ax.com>
	<vm3iem$1sl3f$1@dont-email.me>
	<ndjaoj5n5nu30b23hsk75idtgldqtk4oue@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 14 Jan 2025 17:51:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="37fc08f89117f12bf66847f1707c9a78";
	logging-data="2626206"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+l1v5VNPpvMrbbW752w6jc0EusL8MA3FU="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:O7vndLtGLmFvv0sA3bP7CLiRT5E=
	sha1:z6fSWr0qdR644LsaFxlDl4sRrkM=
Bytes: 11950

Wolfgang Strobl <news51@mystrobl.de> writes:

> Am Mon, 13 Jan 2025 12:27:27 -0500 schrieb Frank Krygowski
> <frkrygow@sbcglobal.net>:
>
>>On 1/13/2025 9:57 AM, Wolfgang Strobl wrote:
>>> Am Sun, 12 Jan 2025 21:05:47 -0500 schrieb Frank Krygowski
>>> <frkrygow@sbcglobal.net>:
>>> 
>>>> On 1/12/2025 3:33 PM, Wolfgang Strobl wrote:
>>>>> Am Sat, 11 Jan 2025 19:46:50 -0500 schrieb Frank Krygowski
>>>>> <frkrygow@sbcglobal.net>:
>>>>>
>>>>>> To me, a big advantage is the ability to _look_ at a mechanical device
>>>>>> and _see_ what's wrong....
>>>>>
>>>>>> That, and the fact I can often affect a repair.
>>>>>
>>>>> I prefer devices that don't need repair over their lifetime.
>>>>
>>>> The weakness I see with that is the assumption that "lifetime" is
>>>> defined as "the amount of time it works." if something stops working,
>>>> its lifetime is over! Throw it out!
>>> 
>>> That's far too simplistic.
>>> 
>>> It depends.  For my purposes, I indeed prefer bicycles that may need
>>> repairs and modifications over their lifetime, for various reasons. I
>>> change over my lifetime, so do my bicycles.  But there are limits. Want
>>> it cheap, longlived, lightweight and functional? Choose any two.
>>> 
>>> 
>>>>
>>>> As I said, I hate the Kleenex ethic - "It's no good any more, just throw
>>>> it away."
>>> 
>>> A strawman isn't getting any more pretty, over time. You won't find many
>>> complex products, machines, vehicles or components with an unlimited
>>> lifetime.  Product lifetime has to be planned. There is innovation,
>>> innovation means change.  There are technical limits. So far, I haven't
>>> heard about bicycle tires that tolerate heavy use over a lifetime of 40
>>> years, as you ask for.  To be precise, I don't know of any that I would
>>> like to use or that I would risk using.
>>
>>I think my Cannondale touring bike qualifies. Of course I've replaced 
>>consumable items like tires, chains, cogs, brake shoes, handlebar tape 
>>and occasionally a chainring. 
>
> That way, any bicycle qualifies. There is essentially no part of a
> bicycle that isn't "consumable".  If you are lucky, all consumable items
> are consumed at the same time.  So you can just buy another bike, call
> it the repaired one and throw out the old one. :-)  Given that declaring
> something consumed is a rather arbitrary decision, you have quite a lot
> of slack with that. 
>
>
>>I've made some equipment substitutions 
>>(saddle, bar-end shifters, "aero" brake levers) but the original 
>>equipment is exceptionally durable.
>
> That is a tautology. Of course the remaining equipment is exeptionally
> durable, otherwise it would have been replaced earlier, for whatever
> reason.
>
>>
>>For one example: The square taper cranks that Tom mocks still work 
>>perfectly well. I had to replace the original sealed bottom bracket one 
>>time, but there was no confusion about compatibility (and my cranks did 
>>not fall off!). The Stronglite roller bearing headset has also lasted 
>>decades, with one parts replacement. The SunTour rear derailleur is 
>>still perfect, although I did cheat a bit. When I powder coated our 
>>bikes, I traded my derailleur for my wife's, figuring hers had many 
>>fewer miles; but both still work just fine. Wheels are not original 
>>because I switched from 27" to 700C, but they're 20 years old.
>
> So why didn't you buy a 40 years old bicycle from somebody who doesn't
> need his bicycle anymore?  
>
> I guess you don't drive a Ford Model T and you don't use an grammophone
> that needs a steel needle for playing shellac records. 
>
> Personally, I am more concerned about how to use a bicycle rather than
> other modes of transport and optimising the bike for that purpose, and I
> am less concerndedabout whether the bike choosen it will last ten,
> twenty or thirty years. 
>
> How long a bicycle lasts depends upon how much it is used and under what
> conditions. A bicycle that lasts more than thirty years is most likely a
> display piece. That some people like you have the time, space and energy
> to maintain a bicycle much longer than its useful life is under normal
> conditions doesn't prove the opposite.  That is not an argument against
> repairing, but an argument against repairing, whatever the cost. I'm not
> talking about money only, here. I mostly miss a sense of proportion. 
>
>
>>
>>> Anyway, I see no reason why the wireless shifting of our bikes shouldn't
>>> outlive a similar purely mechanical one...
>>
>>I guess we'll see, eventually.
>
> If we don't try, we certainly won't see it. Try to see it the following
> way: _you_ don't have any reason to try a group with wireless shifting
> like the one I built our bikes with, I understand that.  So just let
> people like us who experience, like and sometimes need the benefits pay
> the money, try this innovation, and serve as guinea pigs. 
>
>>
>>> There was a similar problem with our TV, too many separate components. I
>>> solved that by using a power strip combined with a separate central
>>> switch at an easy to reach location.  Powering on/off needs two actions:
>>> central switch plus a button on the PC, powering off is done via
>>> keyboard and central switch.  That way, all that stuff doesn't consume
>>> standby power, when not in use.
>>> 
>>> 
>>>> I pump the TV sound through our stereo amplifier, which
>>>> has its own remote (whose volume control seems to have stopped working),
>>>> the CD/DVD player has a separate remote, etc. etc. If we had a friend
>>>> house sit for us, I'd have to write a manual on how to run the system.
>>> 
>>> This can actually be automated quite easily for devices with IR remote
>>> controls. However, it does require a little programming and soldering
>>> work.
>>
>>About that: A few years ago I got annoyed at the number of remotes. I'd 
>>read a good review about a programmable universal remote, and bought it. 
>>I followed the tedious instructions to program it so I could hit one 
>>button for "Watch TV", another button for "Play CD", another button for 
>>"Listen to radio" etc.
>>
>>It's less than ideal. Part of the problem, I think, is that some of the 
>>devices use the same signal code as a toggle for "power-on" & 
>>"power-off", as opposed to a separate code for "On" and "Off." If a 
>>device is left in the wrong state, things don't work. There was also 
>>some dimly remembered problem where commands from the remote had to 
>>arrive at the TV at the proper instant - not too soon, not too late - 
>>and the program couldn't manage that, despite the nice lady at the 800 
>>help number trying over and over to cure. (I suppose I could dig back 
>>into the programming, but I'm not motivated.)
>
> Some years ago, I helped extending a library that implements both
> reading (decoding) and sending (generating) IR codes, the primary author
> was quite prolific in extending it to any protocol that he got
> specificattions and/or samples for. I only wrote a driver part for a not
> yet supported microcontroller, but that was good enough to understand
> some of its workings.  Sadly, the project has mostly stalled after 2015.
> The code is still working and small microcontrollers and IR remotes
> don't change that much.
>
> From your description, I cannot deduce whether a single button press on
> your IR control serves as an "invert the boolean that denotes  specific
> state" (power on/off, for example), or if it is something else.  Some
> universal remotes are just simple and stupid recorders, recording and
> replaying a bitstream without decoding, perhaps after some signal
> cleanup. Others decode and work from tables. 
>
> From memory, most IR remotes use the NEC protocol, after extracting an
> abstract code from the bistream, that code essentially is triple (device
> address, command number, modifier), device denoting a specific tv model,
> for example, command number some arbitrary numbering of the keys on the
> remote, modifier in this case just a single bit denoting "this is
> comming from a repeating, still pressed keys). 
>
> Usually, the behaviour of a IR remote control is as simple as that.  
>
> So much about the basics. Knowing neither your universal control, nor
> anything about the remote control in question, I can't even guess what
> is causing that problem.   I could tell you what I would do to analyze
========== REMAINDER OF ARTICLE TRUNCATED ==========