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