Deutsch   English   Français   Italiano  
<vm3t6d$2101v$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: AMuzi <am@yellowjersey.org>
Newsgroups: rec.bicycles.tech
Subject: Re: Suspension losses
Date: Mon, 13 Jan 2025 14:31:10 -0600
Organization: Yellow Jersey, Ltd.
Lines: 216
Message-ID: <vm3t6d$2101v$1@dont-email.me>
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; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 13 Jan 2025 21:31:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ce70e83366a473d712f409064307176c";
	logging-data="2129983"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5LI4IMsBt3uchQJGnLRC9"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:f2gOrQlAkhUWblP8fkEXqARDTe8=
Content-Language: en-US
In-Reply-To: <ndjaoj5n5nu30b23hsk75idtgldqtk4oue@4ax.com>
Bytes: 12023

On 1/13/2025 1:48 PM, Wolfgang Strobl wrote:
> 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
> and perhaps solve it, but that won't help you, because you don't have
> the necessary equipment (and knowledge). And even I have stored away
> most of the stuff I need for such work, in order to get space to build
> and maintain our bikes.
========== REMAINDER OF ARTICLE TRUNCATED ==========