- IcePower module - 6 Updates
- Security Token Questions - 8 Updates
| Phil Allison <pallison49@gmail.com>: Sep 19 08:52PM -0700 Hi to all my fans, just completed repairs on one of these: http://www.sound-power.ru/files/doc/ICEpower125ASX2_datasheet.pdf Found it fitted inside a mini-size bass instrument amplifier, which the owner had just purchased over the net and failed on him at first power up. Smelling a rat, I checked the AC switch on the rear panel first - blow me down, it was set to 120VAC and we live in a 240V country. Reset the switch, then it drew zero AC current - no surprise. Replaced the blown 5AT fuse in the IcePower module and then the PSU began hiccupping - drawing an amp or two very briefly then shutting off every few seconds. IME feeding double AC supply voltage to a unit with a SMPS is almost always fatal, sure the AC fuse blows but semis in the HV part of the circuit fail in a fraction of a second. But these must be OK this time because the PSU was hiccupping - ie working but sensing an overload so shutting down. Soon enough, multimeter testing showed two small power mosfets on the output side of the SMPS tranny were shorted while two others seemed OK. But what the heck are mosfets doing there ? Well, it's the fist time I have come across seen a *synchronous rectifier* in such an unit. IcePower had certainly gone all out to reduce losses and heat in this module by using a synchronous bridge. The particular TO-252 fets here are made by ON, number FDD86110 rated at 100V and 8mohms on resistance. Removing the duds cleared all shorts and after fitting some new ones ( delivered to me by Element14, from their Singapore warehouse ) I gingerly Variaced the unit up from zero. No hiccupping this time and it began to run normally - after which it passed all my usual bench testing, no problems. FYI: AC current draw was 120mA at idle, 2.4A at full power (340W rms/4ohms) No PFC and inrush surges were about 25A for a few milliseconds. There was a residual sine wave signal on the audio output of about 1V at 500kHz - no biggie except it makes THD testing a right PITA. I find it odd the way the SMPS failed, just two mosfets in the secondary rectifier, nothing else. For a brief time, the DC supply to the switching fets must have been nearly double voltage. Seems the two rectifier fets failed SHORT instantly and protected the rest of the circuitry - remember the power supply is NOT regulated, just a square wave inverter running at 100kHz. I also feel that supplying an expensive amplifier to a buyer living in a 240V country with the AC inlet set to 120V and giving NO warning is criminal. BTW the amp was fitted with a regular IEC inlet which most of the world uses for 240VAC. Any comments? ... Phil |
| John-Del <ohger1s@gmail.com>: Sep 20 04:58AM -0700 On Thursday, September 19, 2019 at 11:52:31 PM UTC-4, Mr. Charm & Warmth wrote: > Hi to all my fans, **There's internet in hell? > Smelling a rat, I checked the AC switch on the rear panel first - blow me down, it was set to 120VAC and we live in a 240V country. > I also feel that supplying an expensive amplifier to a buyer living in a 240V country with the AC inlet set to 120V and giving NO warning is criminal. ** I've found that when an item fails, the customer will flip every switch in a vain attempt to "repair" the failure. Even though the amp failed on first use, we don't actually know where the switch was set when the customer obtained the amp. There's an even (or better) chance the customer flipped it after the amp failed. > Any comments? **Good repair. |
| Rob <nomail@example.com>: Sep 20 12:02PM > Any comments? It may seem like this PSU is fancy, but in a really modern PSU there is no 120/240 switch and the PSU automatically works between 80 and 250V AC. |
| Phil Allison <pallison49@gmail.com>: Sep 20 06:21AM -0700 John Dope wrote: ---------------- > > Hi to all my fans, > **There's internet in hell? ** Small mistake, the internet IS hell. > > I also feel that supplying an expensive amplifier to a buyer living in a 240V country with the AC inlet set to 120V and giving NO warning is criminal. > ** I've found that when an item fails, the customer will flip every switch in a vain attempt to "repair" the failure. Even though the amp failed on first use, we don't actually know where the switch was set when the customer obtained the amp. There's an even (or better) chance the customer flipped it after the amp failed. ** Errr - nope. The particular "switch" is tiny - looks like a round, 20mm panel fuse holder with sub mm white print saying 120/240 - PLUS requires screw driver to operate. Every knowable fact points at the supplier being in the USA and sending the buyer here a "cardboard box" with a local model inside. The chance the amp arrived in the buyer's hand with a faulty low voltage mosfet in the synchronous rectifier cct AND no other fault is miniscule. > > Any comments? > **Good repair. ** I was careful, observant and a tad lucky. Replacing the 2 DPAK mosfets mounted flat on the PCB was a new job to me - everything I had read suggested it required solder paste & liquid flux that I did not have. In the end, I used 1.2mm Savbit 60/40 wire solder, a Hakko FX-888 iron set to 330 C and acted damn quick. ..... Phil |
| Phil Allison <pallison49@gmail.com>: Sep 20 06:31AM -0700 Rob wrote: ----------- > > Any comments? > It may seem like this PSU is fancy, but in a really modern PSU there is > no 120/240 switch and the PSU automatically works between 80 and 250V AC. ** Yep - most of those kind of SMPSs are know as "PFC corrected" . The incoming AC is rectified and converted to 400V DC by a switching converter that tracks the incoming AC voltage. Makes the current wave follow the voltage wave ( both sine) so the "power factor" is close to unity. Has advantages in terms of how many units can be run of the same power circuit and is often mandated in regulations for lighting and computer products. But not for domestic or entertainment audio. ..... Phil |
| Rob <nomail@example.com>: Sep 20 01:48PM > Every knowable fact points at the supplier being in the USA and sending the buyer here a "cardboard box" with a local model inside. Once I had a defective PSU in a Dell desktop PC, made a case at the local Dell phone number, got sent a PSU from a European parts center, and it was set to 120V. BANGGG!! (OF COURSE I did not check that! All newly delivered Dell PCs come with the switch correctly set for our region! and there was no "please be advised that you need to check the setting" note packed with it either...) Called them again, got sent another PSU, again set to 120V. Of course this time I switched it before plugging it in. I think this is crazy. When you manufacture PSUs and have to have a default setting, then at least SET IT TO 240V!!! When the local line is 120V then at least it will not fail, and when it does not work you can still change the setting. |
| Ken <Ken@invalid.com>: Sep 19 11:35AM -0500 I do business with a company that issues a security token, that when used with a password, allows access to my account. I know it works and has worked for years, but I was curious as to how it works: The number the token generates changes every minute or so, so knowing the number it generated a minute ago and the users password is of no value unless used while the number is valid. My questions are: How do they synchronize the timing of the token with that of the server that receives it? Since the token is good for several years before needing to be replaced, how do they synchronize the generated number with the server? I know this is an electronics newsgroup, but I thought if anyone knew the answer to my questions, it would be here. |
| Rob <nomail@example.com>: Sep 19 05:18PM > how do they synchronize the generated number with the server? > I know this is an electronics newsgroup, but I thought if anyone knew > the answer to my questions, it would be here. The software does not accept only a single reply, but rather accepts the numbers generated by the token at a range around the current time. When you enter a code that was valid a minute ago, it does not reject it but it accepts it and notes that the time in the token is apparently a minute behind. The next time you use the token the range of time has been shifted by a minute. This way the server "locks" to the drifting time of the token. When you would not use it for a very long time it could have drifted outside of the range, but in practice this does not happen (the clock in the token is accurate enough). |
| dplatt@coop.radagast.org (Dave Platt): Sep 19 11:08AM -0700 >how do they synchronize the generated number with the server? >I know this is an electronics newsgroup, but I thought if anyone knew >the answer to my questions, it would be here. Take a look at writeups (e.g. Wikipedia) for TOTP (Time-based One-Time Password). To sum it up: the token dongle has its own time reference driven by a stable oscillator (typically something like a watch-crystal). The token's time is synchronized initially when it's first set up. It can of course drift over time (initial tolerances, aging, temperature, and so forth) just as a digital watch does. The one-time password algorithm generates a unique password on a fairly coarse time scale - e.g. once a minute. The server will typically accept the validity of an OTP for longer than this e.g. for an additional 30 seconds or a minute on either side of the "nominal" minute. This allows for some amount of clock drift. To deal with larger amounts of clock drift, the server can be 'adaptive'. That is, if it is offered a password which is (e.g.) "5 minutes out of date" or "5 minutes early", it may refuse it, but ask the user to try again in another minute. If it receives several one-minute passwords in a row, which are all valid but all "late" or "early" by the same amount, the server can conclude that the token-generator is valid but that its internal clock has drifted by this amount. The server could then store the time offset along with the token generator's ID - essentially resynchronizing itself with the token generator. A somewhat similar technique is often used for "rolling code" security remote controls (e.g. car or garage door openers). If you accidentally activate such a device while it's in your pocket, it can "waste" a bunch of codes, and the car/garage receiver will still be expecting a code that has already been used up. In order to resynchronize you can push the remote button several times... a smart receiver will detect a valid sequence of codes coming from a "later" point in the sequence it was designed to accept, and will resynchronize. |
| Ken <Ken@invalid.com>: Sep 19 01:38PM -0500 Dave Platt wrote: > push the remote button several times... a smart receiver will detect a > valid sequence of codes coming from a "later" point in the sequence it > was designed to accept, and will resynchronize. Very clever way of compensating for a time difference. Then are the codes in all similar devices the same with respect to their code sequence, just that each device started the sequence at a different time?? |
| dplatt@coop.radagast.org (Dave Platt): Sep 19 12:11PM -0700 >Very clever way of compensating for a time difference. Then are the >codes in all similar devices the same with respect to their code >sequence, just that each device started the sequence at a different time?? Nope, not in the general case. Each individual device (or each instance of a token-generating application on e.g. a smartphone) has an individual secret (or secrets, if it's generating one-time passwords for multiple services). The service knows the secret for each device. The one-time passwords (codes) are generated by a deterministic process, which takes as input the time and the device secret. This process is designed to be cryptographically strong... it's infeasible to predict what one code will be, based on its predecessors, unless you know the correct shared secret. It's also infeasible to "compute back" and figure out the shared secret even if you know a large number of the OTP codes that have been generated. Thus, if you have two OTP generators, both generating codes for the same service (for e.g. two different user-IDs), and both happen to show a code of 123456 in this minute, it is extremely unlikely that they'll display the same codes during the next minute. You can, however, program two or more OTP generators with the same shared secret, if you choose. For example, if you own a smartphone and a tablet, you can sign up with a service that offers one-time-code access, get your secret (some services deliver it as a scannable barcode or QR code), and load the secret into an OTP-generating app on both devices. These devices will then generate the same code sequences and you can use either to authenticate. The TOTP algorithm is standardized, so you can use different OTP-generating dongles or apps based on a single shared secret, and they'll all interoperate. Different devices/apps can store their secrets differently. For example, as I understand it, the Google Authenticator app for Android stores the secrets in a smartphone's internal hardware-backed keystore, and won't ever export them or back them up to a server. If you lose or wipe the phone, all of the secrets are gone for good. Other apps (e.g andOTP) store the secrets in the device's flash memory, encrypted with a password that you must enter to use the app. andOTP will allow you to export the secrets via email (after encrypting them with a PGP key of your choice for security), and then re-import them into a different phone or tablet. |
| Jeff Liebermann <jeffl@cruzio.com>: Sep 19 03:13PM -0700 On Thu, 19 Sep 2019 11:08:03 -0700, dplatt@coop.radagast.org (Dave Platt) wrote: >To sum it up: the token dongle has its own time reference driven by a >stable oscillator (typically something like a watch-crystal). Tuning fork and watch quartz crystal oscillators out of fashion. The better dongles use a MEMS RTC (real time clock) that has built in temperature compensation via a lookup table. Drift is negligible: <https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator> I have a PayPal card by VeriSign, using OATH HOTP v2.1 that is crammed into a credit card size sandwich with no lumps. <http://blog.agm.me.uk/blog/uploaded_images/PayPaySecurityKey-706729.jpg> More than you probably wanted to know: "TOTP: Time-Based One-Time Password Algorithm" <https://tools.ietf.org/html/rfc6238> "HMAC-based One-time Password algorithm" <https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_algorithm> "HOTP: An HMAC-Based One-Time Password Algorithm" <https://tools.ietf.org/html/rfc4226> >typically accept the validity of an OTP for longer than this e.g. for >an additional 30 seconds or a minute on either side of the "nominal" >minute. This allows for some amount of clock drift. The authentication server does store the time offset. The real question is how big a time step window does it allow for drift. RFC6238 recommended time step is 30 seconds. All 4 of my key fobs are set to 60 seconds. "Validation and Time-Step Size" <https://tools.ietf.org/html/rfc6238#section-5.2> However, I've seen a few that are setup with absurdly long time steps. My guess(tm) is the vendor doesn't want to deal with irate customers who's cheap dongle suddenly doesn't work because of drift. In the systems I've looked at, the server pre-calculates 2 previous and 2 later codes, all of which it will accept as valid. Sometimes it will ask for the next code as a double check. With a 60 second time step, these codes give a +/-4 minute window, which more than enough to deal with any clock drift. -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558 |
| Rob <nomail@example.com>: Sep 20 11:57AM > barcode or QR code), and load the secret into an OTP-generating app on > both devices. These devices will then generate the same code > sequences and you can use either to authenticate. That works, but only when the device has accurate time synchronization by another method. E.g. NTP. If not, the times on the two devices will differ, and the algorithm in the server that tracks the time offset will fail. |
| Rob <nomail@example.com>: Sep 20 11:58AM > better dongles use a MEMS RTC (real time clock) that has built in > temperature compensation via a lookup table. Drift is negligible: > <https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator> Big fun when there is only a slight concentration of helium in the air! |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to sci.electronics.repair+unsubscribe@googlegroups.com. |
No Response to "Digest for sci.electronics.repair@googlegroups.com - 14 updates in 2 topics"
Post a Comment