sci.electronics.repair@googlegroups.com

Google Groups

juanjo <juanjo@benages.eu>: Jul 30 09:44PM +0200 My nephew's Nintendo 3ds has this problem. One night he connected the charger and the next morning the console was dead. No response whatsoever, totally bricked.   Today I had time to try to repair the console and because the battery self-discharge, today was working. I have charged the battery and measured the voltage, when is over 3.8 volts the machine doesn't work.   I think that i will have to change the complete motherboard, but anyone has a better idea?

Sjouke Burry <burrynulnulfour@ppllaanneett.nnll>: Jul 31 12:04AM +0200 On 30.07.16 21:44, juanjo wrote: > measured the voltage, when is over 3.8 volts the machine doesn't work.   > I think that i will have to change the complete motherboard, but anyone > has a better idea?   Get a charger that does not over-charge.

juanjo <juanjo@benages.eu>: Jul 31 04:34PM +0200 El 31/07/16 a las 00:04, Sjouke Burry escribió:   >> I think that i will have to change the complete motherboard, but anyone >> has a better idea?   > Get a charger that does not over-charge.   The battery at 3.8 volts is not over-charged, it is normal for a lithium battery to go over 4 volts when fully carged

Jeff Liebermann <jeffl@cruzio.com>: Jul 24 09:05PM -0700 On Mon, 25 Jul 2016 02:36:20 +0000 (UTC), Aardvarks   >Is it theorectically or practically even possible to mooch off if a typical >WISP   Sigh. Do you really expect me to post detailed instructions on how it might be done?   I'll assume that the leach has a compatible wi-fi client bridge radio, a decent dish or panel antenna, a good location to see the WISP access point antenna, and is able to associate (synchronize with the pseudo random spread spectrum spreading code). Basically, the means the leach can get a "connect" indication from his client bridge radio.   The next obstacle is how much security has the WISP installed to protect his system. Nobody runs a wide open system, without encryption and no passwords. For a minimum, the WISP is certain to authenticate the MAC address of the client bridge radio. MAC addresses are easily spoofed, but this is mostly for identifying and blocking radios that are attempting to connect, but don't belong on the system.   The next layer is WPA2-AES-Enterprise encryption and authentication. Unlike the typical home wi-fi router, which uses WPA2-AES-PSK (pre-shared key), WPA2-AES-Enterprise does not have a single encryption key for the entire system. A new and unique key is issued for each connection and at regular intervals. Even if you could crack the encryption key, it would only be good for a maximum of 3600 seconds. The RADIUS authorization and 802.1x authentication system would also have a stored login and password.   There are a bunch of other tricks to improve security that are used, which I don't want to disclose or discuss. Most do not really prevent someone from breaking into the system, but rather act as a burglar alarm to identify attempted breakins.   I would say that trying to get past WPA2-AES-Enterprise, even with inside information, is not possible (unless you're the NSA). Spoofing an existing connection or working WISP customer is somewhat less difficult. One would need the previously mentioned hardware list, a means of tweaking the client bridge MAC address, the RADIUS login and password, and inside knowledge of what the WISP is using for authentication. One would also need to somehow disable the real customer as it would not do to have two client bridge radios trying to authenticate using identical credentials. That will certainly set off alarms (if the WISP pays attention to alarms and reads the log files). That's possible, but hardly practical, and certainly not reliable.   Leeching is usually NOT done by trying to connect to the WISP access point. Instead, it's done by connecting to the wireless router installed by the WISP customers. In other words, the neighbors. These are typical home wireless commodity routers, secured by a single WPA2-AES-PSK password key. If you know the key (or its hash code), and have good RF connectivity to the neighbors wireless router, you're on the system.   So, to answer your question... yes, it's theoretically possible but no, it's not easy, practical, worthwhile, or reliable. Incidentally, it's also a crime and legally actionable as "theft of services" which increases the element of risk.     -- 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

Aardvarks <aardvarks@a.b.c.com>: Jul 25 05:39AM On Sun, 24 Jul 2016 21:05:10 -0700, Jeff Liebermann wrote:   > Sigh. Do you really expect me to post detailed instructions on how it > might be done?   Hi Jeff, I knew you'd be on either a.i.w or s.e.r (although you hang out more on the latter nowadays, I think).   > point antenna, and is able to associate (synchronize with the pseudo > random spread spectrum spreading code). Basically, the means the > leach can get a "connect" indication from his client bridge radio.   The theoretical leach would be me (but I already have free WiFi access from my WISP in return for being an access point for him) so the question really *is* theoretical, and you actually know all the WISPs in this area (let's not state their company or real names, for privacy reasons, but you know of Loren at H.....p and Dave at S.....t and Mike at R...........s, and Herman at E.....c, etc., who are the respective WISP proprietors).   > The next obstacle is how much security has the WISP installed to > protect his system. Nobody runs a wide open system, without > encryption and no passwords.   Exactly! Nobody runs a wide open system where leaches can just latch on for any reasonable period of time.   Loren is the least restrictive, Herman is the most restrictive - with the others in between on security.   > addresses are easily spoofed, but this is mostly for identifying and > blocking radios that are attempting to connect, but don't belong on > the system.   Actually, as you pretty well know, that end of the MAC address is, think, the harder one to spoof (I think it was you who told me that long ago).   But let me confirm...   The end that the WISP sees is the hard one to spoof, isn't it?   > The next layer is WPA2-AES-Enterprise encryption and authentication.   Yup. While Loren doesn't even use encryption on the 802.11 equipment, he has plenty of 900MHz equipment which has to be specially set up, and Mike, for example also makes use of non-wifi protocols. So does Dave and Herman's system isn't at all compatible with customer owned equipment.   > the encryption key, it would only be good for a maximum of 3600 > seconds. The RADIUS authorization and 802.1x authentication system > would also have a stored login and password.   Yup. And that doesn't even count the protocol tricks that these guys use to get better bandwidth throughput and noise rejection.   > which I don't want to disclose or discuss. Most do not really prevent > someone from breaking into the system, but rather act as a burglar > alarm to identify attempted breakins.   They all run a watchdog of some sort.   > I would say that trying to get past WPA2-AES-Enterprise, even with > inside information, is not possible (unless you're the NSA).   Actually, I have more knowledge than most because I'm a repeater so I am sometimes called to do troubleshooting to save them a visit - but for this discussion - we should assume I'm a normal customer of the WISP.   > means of tweaking the client bridge MAC address, the RADIUS login and > password, and inside knowledge of what the WISP is using for > authentication.   You also need the protocol information, and the IP address information, but presumably you could sniff that over the air.   > authenticate using identical credentials. That will certainly set off > alarms (if the WISP pays attention to alarms and reads the log files). > That's possible, but hardly practical, and certainly not reliable.   Yup. While doing a site discovery isn't hard, you have to also crack the admin password on the radio, which changes frequently, among other hurdles.   > Leeching is usually NOT done by trying to connect to the WISP access > point.   Agreed. It's just too hard to do and too easy to get caught since a house doesn't move all that fast.   > Instead, it's done by connecting to the wireless router > installed by the WISP customers.   OK. That's *easy* by way of comparison. But we weren't talking about breaking into the homeowners' SOHO router (which is a different topic altogether).   > WPA2-AES-PSK password key. If you know the key (or its hash code), > and have good RF connectivity to the neighbors wireless router, you're > on the system.   Yes. Plenty of neighbors have wide open networks. Sigh. They're the Santa Cruz 60's hippy trusting type of people. You know ... people like you! :) (jk - you're too knowledgeable to be trusting!)   > no, it's not easy, practical, worthwhile, or reliable. Incidentally, > it's also a crime and legally actionable as "theft of services" which > increases the element of risk.   Yup. Just what I had thought.   The Apple iOS "experts" blandly accuse people of this stuff, not even taking into account *any* of the many potential hurdles, not the least of which that a house doesn't move all that fast and is easy to locate when stealing WISP bandwidth.   If you're not the NSA, then you're probably not hacking into the WISP. It's just not feasible.   Thanks for your insight!   PS: What do you think about the possibility of tapping into a Starbucks in downtown Santa Cruz from Loma Prieta?

Aardvarks <aardvarks@a.b.c.com>: Jul 25 02:36AM Is it theorectically or practically even possible to mooch off if a typical WISP   In the iPhone newsgroups, a typical Apple Fundamentalist assumed I mooch off of my SF Bay Area Santa Cruz Mountain WISP simply because I get my Internet connection over the air via a WISP ISP a couple of mountains away.   In my response to this iOS right winger, who is used to so used to paying through the nose for everything that he can't even comprehend the *concept* of legitimate freeware, I told him (nospam) that I can't possibly even *think* of how a typical WISP would accidentally allow moochers.   While I used to have a 2.4GHz Rocket M2, I switched to the less noisy 5GHz Rocket M5 which has vertical and horizontal channels that are set by the WISP (who logs into the antenna to set it up from afar).   Certainly the WISP keeps logs of all connections, and, in my case, he has to assign a static IP address to *each* customer.   So, this question is only one of theoretical/practical possibilities.   Is it even theoretically or practically possible to mooch off of your WISP provider without him knowing about it (assuming he's a normal conscientious WISP using all the normal tools that a WISP would use).

Micky <NONONObobbyburns1111@gmail.com>: Jul 25 04:23AM -0400 A friend gave me what looks like a network cable, with a modular plug with 8 slots, but the only ones with wires are slots 1,2,3 and 6.   What is this cable meant for?

frank <frank@invalid.net>: Jul 25 08:37AM > Il giorno lunedì 25 luglio 2016 10:23:48 UTC+2, Micky ha scritto: >> A friend gave me what looks like a network cable, with a modular plug >> with 8 slots, but the only ones with wires are slots 1,2,3 and 6.   RJ-45 plug has 8 contacts (slots?), and wiring only 1,2 and 3,6 pairs makes a 10 Mbit/s cable, either straight or crossed. It could be made to connect an old 10 BASE-T network card or it's just a leftover from the previous century.   Frank

Andy Burns <usenet@andyburns.uk>: Jul 25 02:31PM +0100 Micky wrote:   > A friend gave me what looks like a network cable, with a modular plug > with 8 slots, but the only ones with wires are slots 1,2,3 and 6.   > What is this cable meant for?   Fast ethernet (100Mbps) only uses pins 1, 2, 3 & 6, all eight are used for Gigabit ethernet, do the pairs cross over 1/2->3/6 or straight through 1/2->1/2?

N_Cook <diverse@tcp.co.uk>: Jul 24 08:37AM +0100 So SMD 400V MLCC caps do exist (or did exist) http://www.mouser.co.uk/ProductDetail/AVX/22258C224KAT9A/?qs=sGAEpiMZZMvsSlwiRhF8qtMAW1uaXrptEm0l1HszexY%3d     non-stocked, none on order, I wonder why

avagadro7@gmail.com: Jul 30 03:32PM -0700 Verizon Samsung 5 Android beats V MiFi PC Dell Inspiron 2013......

Jeff Liebermann <jeffl@cruzio.com>: Jul 30 05:49PM -0700 On Sat, 30 Jul 2016 16:18:02 -0000 (UTC), Aardvarks   >In your experience with *both* Android & iOS mobile devices, have you also >found the iOS devices severely lacking in WiFi sensitivity (resulting in >dropped connections when Android devices are still working fine)?   Nope. About the same range. At least the same range within some reasonable tolerance range, such as +/- 10% or so. Note that I consider "range" to be somewhat equivalent to your "sensitivity" where "sensitivity" is limited to receive only and does not involve the antenna or environmental situations. Also note that anecdotal evidence of a problem is not definitive as measurements such as "range" and "sensitivity" tend to follow a bell curve.   >This is a question borne out of experience setting up WiFi for dozens of >local neighbors, some of whom use Apple ipads & iPhones, and others who use >Android mobile equipment.   I'll resist the temptation to offer my opinion of Apple engineering and RF design. Well, maybe not totally. This is my play on the iPhone 4 antenna grip problem in 2010: <http://802.11junk.com/jeffl/cellular/cell-test.htm> Steve Jobs was right that all phones have the antenna grip problem. He just didn't mention that the iPhone 4 had it 10 times worse than the others.   >multiple iPads and Android phones, and in the large homes of my neighbors, >the Apple iPads and iPhones almost always have *far worse* WiFi reception >than do the Android phones.   How far worse? How did you measure "reception"? What were you measuring? Using wi-fi receive signal strength from an app or counting "bars" isn't worth much. These vary substantially between devices and is affected by temperature.   >Has this been your experience also? >If so, why do you think this is the case?   Yes of course. Since I don't like Apple, every Apple is by definition far worse than Android. Or course, for a nominal bribe, I can reverse the situation.   >NOTE: Jeff is honest to a fault, so, his opinion matters greatly.   Jeff lives on a fault. Being honest improves my karma, and prevents earthquakes from ruining my day.   In the past, I've offered you various ways of running a controlled range (performance) test. The next time you get your hands on a test device, try it. It's quite easy.   1. You will need a reasonably fast computah running iperf ver 2, iperf3, or jperf. This turn the compoutah into an iperf server by running just: iperf -s The computah should be connected via an ethernet cable to the users router. Gigabit ethernet is nice for measuring maximum speeds, but that's not what we're doing here.   2. Next, you'll need a iperf client on the phone or tablet. There are iperf clients for most OS's. Note that iperf2 and iperf3 are quite different and not really compatible. If the version is not specified, it's probably iperf2.   Android: <https://play.google.com/store/apps/details?id=net.he.networktools&hl=en> <http://networktools.he.net/> <https://play.google.com/store/apps/details?id=com.magicandroidapps.iperf&hl=en>   IOS: <https://itunes.apple.com/us/app/he.net-network-tools/id858241710?mt=8> <http://networktools.he.net/> <https://itunes.apple.com/us/app/iperf-network-bandwidth-measurement/id951598770?mt=8> <https://itunes.apple.com/us/app/iperf3-network-bandwidth-performance/id986846572?mt=8>   PC, OS/X, Linux, etc: <https://iperf.fr/iperf-download.php>   Note that most Linux mutations ship with iperf2 and that iperf3 must be installed. You can have both iperf and iperf3 installed at the same time: <https://iperf.fr/iperf-download.php#more-recent>   JAVA (runs on anything that groks Java and does pretty graphs): <https://www.rarst.net/software/jperf/> <https://sourceforge.net/projects/iperf/files/> JPerf is iperf2 not 3. Version 3 is for higher speed wireless. Don't mix versions.   Tutorials on iperf and jperf: <http://openmaniak.com/iperf.php> <https://www.jamescoyle.net/how-to/574-testing-network-speed-with-iperf> <https://www.jamescoyle.net/cheat-sheets/581-iperf-cheat-sheet>   I recommend the HE (Hurricane Electric) versions which will test either IPv4 and IPv6.   YouTube video of a typical test: <https://www.youtube.com/watch?v=4qdKgHBO_Gc>   Some notes I made from a talk on iperf and jperf: <http://802.11junk.com/jeffl/FLUG-talk-2015-03-28/iperf3%20talk.htm>   3. Connect your test phone or tablet via wi-fi and just run a test to see if it works. If you're running Jperf, you should see something like this: <http://802.11junk.com/jeffl/FLUG-talk-2015-02-28/802.11gn%20direct.jpg> Note that the max speed is about 60 Mbits/sec.   If you insert a wireless repeater in between the wireless router and the client, you get this mess: <http://802.11junk.com/jeffl/FLUG-talk-2015-02-28/802.11gn%20through%20Netgear%20repeater.jpg> Note the drastic drop in maximum speed. I'll save my rant against mesh networks for another day.   4. Now comes the big trick. Temporarily change the speed of your wireless router from "automatic" to a fixed speed and/or protocol. For 802.11g, that would be 54 Mbits/sec. For faster protocols, it can be faster. If you have an 802.11ac wireless router, leave both 2.4 and 5GHz on. However, if you're testing with a lesser protocol, enable only one frequency band at a time, so that you know which one you're testing. I would initially do the test using 802.11g and 54Mbit/sec because higher speeds and protocols allow for fallback, which will produce odd results.   By fixing the speed and protocol, you're eliminating the ability of the wireless router to slow down the wireless connection speed and thus improve the range. As you walk away from the wireless router, instead of a general slowdown, you'll see an abrupt drop in speed, possibly followed by a disconnect. The typical 2.4GHz 802.11g system will go about 10 meters before the speed drops abruptly. Measure and record this distance along with the test conditions (devices, frequency, protocol, fixed speed, etc).   You'll find indoor testing to vary substantially, mostly depending on reflections and wireless router antenna positions. Outdoors works better, but only if you don't have any interference. Try to pick an empty channel (good luck with that).   5. If you're lazy and don't want to deal with servers and iperf, you do something similar with just ping. You still have to set a fixed speed and protocol, but you don't get the pretty graphs and data. Just continuously ping the wireless router. At some point, the latency will drastically increase, followed by 100% packet loss, and possibly a disconnect. This is not as precise as iperf because you're not saturating the pipe with traffic, but probably good enough.   6. That's all there is. The "range" of a device, which is a measurement of the overall radio design, antenna, internal noise, packaging, orientation sensitivity, etc quality, should give you a clue as to relative quality of the various test devices. If everything you test craps out at approximately the same range (using the same speeds and protocols), then as far as I'm concerned, they're all the same. However, if you see substantial variations, then you can legitimately claim that Apple and Android devices are different.   7. Incidentally, you can also try it pointing iperf to a public server instead of your own iperf server. Note that you'll be measuring the speed of your internet connection, not the speed of the wireless. I wouldn't do that for the range test. Iperf public servers: <https://iperf.fr/iperf-servers.php> Also, if you want to be sick, try running iperf over a cellular data connection.   Just do it. I didn't spend an hour writing all this so that you lean back in your chair and deliver your "impressions" or "feelings". Such things as range can and should be tested. If you need help, you know where you can try to pry me out of my hole.   Good luck...     -- 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

nospam <nospam@nospam.invalid>: Jul 30 09:54PM -0400 In article <aleqpb932uap89en74ckq9rlbj7lhbipk4@4ax.com>, Jeff > Steve Jobs was right that all phones have the antenna grip problem. He > just didn't mention that the iPhone 4 had it 10 times worse than the > others.   the iphone 4 was not 10x worse.   it was comparable to other phones and in many cases, those other phones were substantially worse, even dropping to no service, something the iphone 4 didn't do.   palm pre drops to no service: <https://www.youtube.com/watch?v=zft3-Lwh2bo>   droid incredible drops to no service: <https://www.youtube.com/watch?v=c4zbQ3f7H0U>   droid 2 had serious issues: <https://techcrunch.com/2010/08/13/uh-oh-early-droid-2-units-having-sign al-issues/> The signal on one of the two units we received is all over the board, dipping from full signal down to nearly none whilst sitting in the same spot (and no, weąre not holding it wrong). Engadgetąs review says that four out of four of their units show endlessly fluctuating bar counts, and our buddy Rich Brome of Phonescoop says heąs having bad luck with his, as well. Thats 6 review units, all showing signs of signal woes. Not a good sign.   > Yes of course. Since I don't like Apple, every Apple is by definition > far worse than Android. Or course, for a nominal bribe, I can reverse > the situation.   that explains everything.

Jolly Roger <jollyroger@pobox.com>: Jul 31 02:16AM > droid 2 had serious issues: > <https://techcrunch.com/2010/08/13/uh-oh-early-droid-2-units-having-sign > al-issues/>   I remember those findings near the end of the whole Antenna Gate circus. It was comical seeing comparable phones also drop signal when "held wrong". I recall the Apple trolls denying that reality back then too - just as they apparently still are today. : D   -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead.   JR

Aardvarks <aardvarks@a.b.c.com>: Jul 31 02:59AM On Sat, 30 Jul 2016 17:49:59 -0700, Jeff Liebermann wrote: > About the same range. At least the same range within some > reasonable tolerance range, such as +/- 10% or so.   Interesting. Very interesting, as I have Apple and Android devices, and my WISP has dealt with them, and almost *every* home that complains about piss poor WiFi reception is an Apple home where I help out.   > consider "range" to be somewhat equivalent to your "sensitivity" where > "sensitivity" is limited to receive only and does not involve the > antenna or environmental situations.   Fair enough.   > Also note that anecdotal > evidence of a problem is not definitive as measurements such as > "range" and "sensitivity" tend to follow a bell curve.   I have had the two iPads tested at the Apple Genius bar, and they passed "that" test, even though they both fail miserably at having the same WiFi reception as all four of my Android devices have.   > Steve Jobs was right that all phones have the antenna grip problem. He > just didn't mention that the iPhone 4 had it 10 times worse than the > others.   I *knew* you had tested Apple antennas in the past! "The worst phone I tested dropped the rx signal 16 times (-12dB). The iPhone 4 rx signal dropped 100 times (-20dB) to 288 times (-24.6dB) . That's a 6 to 18 times worse signal drop for the iPhone 4. Little wonder it drops calls. My guess(tm) is that something more than detuning the antenna is happening. I suspect that the receiver front end might be slightly regenerative, where touching the antenna kills the regeneration and the associated sensitivity."   > measuring? Using wi-fi receive signal strength from an app or > counting "bars" isn't worth much. These vary substantially between > devices and is affected by temperature.   In all cases in "my" house, I had my Android devices on a flat surface within a foot of the iOS devices when the Android devices would easily connect home broadband router at the far fringes of the home, while the iOS devices failed to make any connection.   I had to solve the problem by setting up a spare WRT54G router as a wired extension (crawling under the house and cursing Apple the entire time), so, the fact that the WiFi reception of the iOS devices sucks compared to that of the Android devices caused me considerable effort.   In addition, as you know, I assist my small WISP in setting up customers and troubleshooting when they have WiFi problems. Almost invariably, the Apple-based customers are highly non technical, so, they call up with problems that aren't really the WISP's prerogative, such as the fact they can't connect to either his or their routers (he insists everyone have a router so he gives them one if they don't have their own).   Almost always, if not always, I put their iDevices next to my Android device to test WiFi connectivity and signal strength at the distance that the customer complains.   Even though the tools available to sniff WiFi issues on iOS devices are downright primitive, you "can" easily see that the Android devices "connect" to the router at distance while the iOS devices are oblivious of the router at the same distances.   Working in the other direction, I start with the iOS device in one hand, and the Android device in the other hand, using the primitive iOS tools and the more sophisticated (aka modern) Android sniffing tools, so that I can see the BSSID and perceived signal strength (in case there are multiple SSIDs of the same name, as I have in my own setup), and almost always, if not always, the iOS devices *drop* the connection well before the Android devices do (I generally walk outside until the Android device drops the connection).   After having done this so many times, whenever we get a call, we ask if they're using Apple equipment, and, if they are, we know what's going on.   > Yes of course. Since I don't like Apple, every Apple is by definition > far worse than Android. Or course, for a nominal bribe, I can reverse > the situation.   While my grandkids play games almost exclusively on the iDevices, the main problem "I" have with Apple is that it's primitive in terms of being able to do useful things, e.g., WiFi reception sniffers on iOS are primitive in comparison to what's available on Android. > Jeff lives on a fault. Being honest improves my karma, and prevents > earthquakes from ruining my day.   Given the century-long cycles, you already had yours in 1989. Let someone else have their faults! > In the past, I've offered you various ways of running a controlled > range (performance) test. The next time you get your hands on a test > device, try it. It's quite easy.   Looks like iPerf is available on iOS & Android & Windows & Linux! https://iperf.fr/iperf-download.php   > The computah should be connected via an ethernet cable to the users > router. Gigabit ethernet is nice for measuring maximum speeds, but > that's not what we're doing here.   I don't have any fast computers - but just basic laptops.   > <https://itunes.apple.com/us/app/iperf3-network-bandwidth-performance/id986846572?mt=8>   > PC, OS/X, Linux, etc: > <https://iperf.fr/iperf-download.php>   This is good that we an lay two mobile devices on a desk and run the same iPerf utility to check performance. > be installed. You can have both iperf and iperf3 installed at the > same time: > <https://iperf.fr/iperf-download.php#more-recent>   I'd just pick one. Probably iPerf2 for compatibility. > <https://sourceforge.net/projects/iperf/files/> > JPerf is iperf2 not 3. Version 3 is for higher speed wireless. Don't > mix versions.   I'd stick with iPerf 2. > either IPv4 and IPv6.   > YouTube video of a typical test: > <https://www.youtube.com/watch?v=4qdKgHBO_Gc>   Interesting that Mike Pennacchi set up a linux box running iperf -s. Then he runs Android iperf -c to get 10.0.10.80 as the linux box. Then he runs Android iperf for 60 seconds & gets 50Mbps throughput.   With iPerf, not only Android but even the primitive iOS phones can be turned into powerful network-troubleshooting tools!   This is great information! > Some notes I made from a talk on iperf and jperf: > <http://802.11junk.com/jeffl/FLUG-talk-2015-03-28/iperf3%20talk.htm>   You used iperf3, but I'd probably use iPerf 2 only because I want simple compatibility with iOS and Android, Windows, and Linux.   > like this: > <http://802.11junk.com/jeffl/FLUG-talk-2015-02-28/802.11gn%20direct.jpg> > Note that the max speed is about 60 Mbits/sec.   Are the three graphs (purple, green, and blue) different access points? Or are they different ports on the computer (1840, 1872, & 1860)?   > <http://802.11junk.com/jeffl/FLUG-talk-2015-02-28/802.11gn%20through%20Netgear%20repeater.jpg> > Note the drastic drop in maximum speed. I'll save my rant against > mesh networks for another day.   Thanks to you, I set up a *wired* extender out of my spare WRT54G router, as you had explained, long (long) ago, that the extender is faster, in effect, than the repeater - even though the repeater is easier to set up (but not easily set up on a WRT54G v5 due to lack of memory).   > 4. Now comes the big trick. Temporarily change the speed of your > wireless router from "automatic" to a fixed speed and/or protocol.   I've never done this. I'll have to check how to set the speed on the Netgear WNDR2400 router and the Linksys WRT54G router. I'm sure the speed is currently set at defaults.   > testing. I would initially do the test using 802.11g and 54Mbit/sec > because higher speeds and protocols allow for fallback, which will > produce odd results.   Hmmmm....   > By fixing the speed and protocol, you're eliminating the ability of > the wireless router to slow down the wireless connection speed and > thus improve the range.   Ah. That makes sense!   > As you walk away from the wireless router, > instead of a general slowdown, you'll see an abrupt drop in speed, > possibly followed by a disconnect.   Eureka! That's the test I need to run!   > will go about 10 meters before the speed drops abruptly. Measure and > record this distance along with the test conditions (devices, > frequency, protocol, fixed speed, etc).   That's a PERFECT test! My hypothesis is that the iOS devices will drop in half the distance that the Android devices will drop - but that remains to be seen in the test.   > reflections and wireless router antenna positions. Outdoors works > better, but only if you don't have any interference. Try to pick an > empty channel (good luck with that).   We're in the boonies. Empty channels aren't hard to find. Especially in the 5MHz range. > will drastically increase, followed by 100% packet loss, and possibly > a disconnect. This is not as precise as iperf because you're not > saturating the pipe with traffic, but probably good enough.   In general, for utilities, the limitation is that iTools don't allow powerful tools, but it seems, on iOS, apparently there is a simple ping app from MochaSoft: https://itunes.apple.com/us/app/network-ping-lite/id289967115?mt=8   Android, as would be expected for a mature mobile operating system, has a bunch of usable ping utilities, e.g., StreamSoft makes: https://play.google.com/store/apps/details?id=ua.com.streamsoft.pingtools&hl=en > everything you test craps out at approximately the same range (using > the same speeds and protocols), then as far as I'm concerned, they're > all the same.   I would agree with you.   If the two devices under test crap out at the same time, then they're equivalent. If the Android device craps out at twice the distance of the iOS devices, then the hypothesis is supported.   Of course, I'd have to test multiple random devices to be sure of the data.   > However, if you see substantial variations, then you > can legitimately claim that Apple and Android devices are different.   I've already many times over seen substantial variations. So, what remains is only a more rigid test, as you have proposed. > <https://iperf.fr/iperf-servers.php> > Also, if you want to be sick, try running iperf over a cellular data > connection.   Cellular is not in the cards; just WiFi.   > back in your chair and deliver your "impressions" or "feelings". Such > things as range can and should be tested. If you need help, you know > where you can try to pry me out of my hole.   I will set up the iperf 2 on the various devices and test this out!

Jeff Liebermann <jeffl@cruzio.com>: Jul 30 08:44PM -0700 On Sat, 30 Jul 2016 21:54:55 -0400, nospam <nospam@nospam.invalid> wrote:   >the iphone 4 was not 10x worse.   Well, you're certainly entitled to an opinion. Personally, I prefer opinions based on repeatable tests, measurements, numerical results, and calculations. However, I'll accept your assertion for what it's worth. However, I did make one mistake. The iphone wasn't 10 times worse, but more like 6 to 18 times. Citing my web page: <http://802.11junk.com/jeffl/cellular/cell-test.htm> "The worst phone I tested dropped the rx signal 16 times (-12dB). The iPhone 4 rx signal dropped 100 times (-20dB) to 288 times (-24.6dB). That's a 6 to 18 times worse signal drop for the iPhone 4... "   One problem was that I didn't have access to an iphone 4 at the time of the controversy. None of my friends would trust me to jailbreak their phone just so I could get a signal strength reading in dBm instead of "bars". So, I had to use the test results from the Anantech article. A friend has an iPhone 4 that he's not using, so I could probably repeat my test given sufficient inspiration.   >it was comparable to other phones and in many cases, those other phones >were substantially worse, even dropping to no service, something the >iphone 4 didn't do.   Yeah, that was cute. Initially, Verizon phones would stay connected for quite a while after total loss of signal. I put a VZW iphone 4 in a shielded box during a call, waited up to about 2 minutes, and was able to resume the call uninterrupted. Nicely done by VZW. However, AT&T was initially a different story. I did the same test with an AT&T phone (not an iPhone) and found that it would disconnect after only a few seconds. About a month later, after AT&T announced that they had "upgraded" their network to match capabilities of the new iPhone, it would also stay connected after 2 minutes of carrier loss.   >palm pre drops to no service: ><https://www.youtube.com/watch?v=zft3-Lwh2bo>   I have an old VZW Palm Pre somewhere in the office. I'll try it on Mon or Tues.   Interesting test. He's in a weak signal area. Grabbing the phone drops the signal level enough to produce a loss of connection. That's not surprising. It would be more interesting if he put the phone in the Field Test Mode to see how much the signal drops. If the phone is right at the bitter edge of disconnecting, and the signal drops a few dB, I would expect it to umm.... disconnect. Note that all the phones used in my test showed about a 9 dB drop in receive signal from a death grip, which would produce exactly the same results in a weak signal area as the Palm Pre.   >droid incredible drops to no service: ><https://www.youtube.com/watch?v=c4zbQ3f7H0U>   This is almost as bad as the Pre test. Instead of being in a one bar weak signal area, he's got 2 bars. I'm not so sure that the HTC Droid Inedible (VZW only) has the antenna at the bottom. I tried to find it on the iFixit teardown at: <https://www.ifixit.com/Teardown/HTC+Droid+Incredible+Teardown/42422> and couldn't find it. Other users are also having problems: "FIX HTC INCREDIBLE S RECEPTION ANTENNA ISSUES" <https://www.youtube.com/watch?v=QHIdl1qrdkc> (6:42) Fast forward to 4:35 to see what he's done. In other words, not the best phone or antenna system. Of course, the author doesn't care about potential SAR problem.   > bar counts, and our buddy Rich Brome of Phonescoop says heąs having > bad luck with his, as well. Thats 6 review units, all showing signs > of signal woes. Not a good sign.   That's just a crappy phone. It could be anything from bad design, bad implementation, bad parts, bad metering, or just having a bad day. I assume that this has something to do with your defense of Apple, but I lack the wisdom to make the connection.   >> far worse than Android. Or course, for a nominal bribe, I can reverse >> the situation.   >that explains everything.   Even honesty has a price tag.   -- 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

Jeff Liebermann <jeffl@cruzio.com>: Jul 30 09:42PM -0700 On Sun, 31 Jul 2016 02:59:24 -0000 (UTC), Aardvarks   >I have had the two iPads tested at the Apple Genius bar, and they passed >"that" test, even though they both fail miserably at having the same WiFi >reception as all four of my Android devices have.   I don't have a proper 802.11 tester, but can make some fairly good BER (bit error rate) and signal level tests on my messy workbench. Yeah, it's all antiques but it's probably better than what you'll find at the Genius Bar: <http://802.11junk.com/jeffl/pics/home/slides/test-equip-mess.html> Mostly, I find that RFI/EMI from the computah section of a smart gizmo causes most of the loss of wi-fi reception problems. For example, my Droid X and X2 would show reduced sensitivity when the display backlighting was on full compared to when it was dim. My guess(tm) is that most of the wi-fi radios are quite good, but in proximity of the computah noise generator, don't do as well. How Apple or Android compare, I don't know.   >within a foot of the iOS devices when the Android devices would easily >connect home broadband router at the far fringes of the home, while the iOS >devices failed to make any connection.   Well, that's a fairly good side by side comparison. However, it might not be the radios. One of my customers is all Apple. They must have one of everything, although wisely, they never buy the latest devices. I had problems with range at their house. My Chrombook, Nexus 7 tablet, and Moto G phone were also having range problem. I eventually found a neighbor with Roku 2 and 3 boxes streaming away furiously 24x7, with both located near facing windows. I convinced the neighbor to let me connect the Roku boxes with ethernet cable (3ft and 6ft away), which eliminated the problem. Range was then dramatically improved.   >extension (crawling under the house and cursing Apple the entire time), so, >the fact that the WiFi reception of the iOS devices sucks compared to that >of the Android devices caused me considerable effort.   You'll get no sympathy from me. I do that all the time. However, my days of crawling under houses are largely over thanks to health issues. I was pulling wires and installing wall jacks last week for about a day, and still haven't recovered. Maybe I'll learn to like power line connected wireless repeaters instead.   >problems that aren't really the WISP's prerogative, such as the fact they >can't connect to either his or their routers (he insists everyone have a >router so he gives them one if they don't have their own).   Ok, the first step to solving a problem is to blame someone. In this case Apple. I tend to allow other options, such as junk routers and interference. I carry a WiSpy 2.4Ghz spectrum analyzer, that isn't limited to seeing wi-fi devices. Amazing what I find out there. <http://www.metageek.com> <http://www.metageek.com/products/wi-spy/index-3.html>   However, I did have problems with the older Apple Airport wireless routers. Even the Apple products would not stay connected. Almost anything could connect, but didn't stay connected. Streaming was the big problem, where it would disconnect abruptly and without much provocation. I usually solved it by temporarily replacing the router with a Linksys equivalent. Current favorite is a Linksys EA2700. Range is not so good because it's a lower power device than most. I don't care because if a customer want's to go through walls, I just sell them another EA2700 router.   >downright primitive, you "can" easily see that the Android devices >"connect" to the router at distance while the iOS devices are oblivious of >the router at the same distances.   You're being generous. I use my Android phone and tablet as if they were test and diagnostic equipment. I don't know what Apple allows, but as I recall from using an iPhone 3G for a while, it's not much. I had to jailbreak my 3G to install something useful. Here's the latest version: <https://www.adriangranados.com/apps/ios-wifi-explorer>   >Looks like iPerf is available on iOS & Android & Windows & Linux! >https://iperf.fr/iperf-download.php   If you recall, I offered exactly the same song and dance to you about 2 years ago. There were versions for just about every OS available at the time, but I must admit, were somewhat crude. So, this time, please run the tests, and you can thank me later.   >I don't have any fast computers - but just basic laptops.   Sorry. You'll need a fairly fast computah if you're going to do tests with gigabit ethernet or 802.11ac. The idea is to make sure that everything involved is faster than the wi-fi link. You'll also need to use iperf3 to get accurate numbers for the higher speeds. However, we're not interested in how fast you can go. We're looking for when the data no longer is flowing smoothly or when it drops out. You can get away with almost anything that looks like a computah and will run iperf. I have an microSD card that I use on a Raspberry Pi 2 box as a quick an dirty iperf server. It won't do gigabit, but I usually don't need such test speeds.   >This is good that we an lay two mobile devices on a desk and run the same >iPerf utility to check performance.   Yep, but always have a reference machine handy that you know for sure that runs fast and well. When everything you test runs badly, and you don't know if the problem is with everything you're testing, or with the server, router, network, interference, etc, it's always nice to have a tie breaker.   >I'd just pick one. Probably iPerf2 for compatibility.   Try jperf for starters. It's the easiest to use and includes the iperf2 binaries in the package buried in a subdirectory. If you want to do speed testing, switch to iperf3.   >With iPerf, not only Android but even the primitive iOS phones can be >turned into powerful network-troubleshooting tools!   Yep.   >> <http://802.11junk.com/jeffl/FLUG-talk-2015-02-28/802.11gn%20direct.jpg>   >Are the three graphs (purple, green, and blue) different access points? >Or are they different ports on the computer (1840, 1872, & 1860)?   It was 3 separate runs of the program. The numbers are NOT port numbers. I was doing some fiddling with the setup and wanted to see what produced the best throughput.   >That's a PERFECT test! >My hypothesis is that the iOS devices will drop in half the distance that >the Android devices will drop - but that remains to be seen in the test.   We shall soon see.   Good luck.   -- 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

"Ian Field" <gangprobing.alien@ntlworld.com>: Jul 30 08:12PM +0100 The DVD player tray jammed and wouldn't eject the disk.   After undoing a surprisingly large number of screws to get the case open - I noticed the rectifier/reservoir electrolytic was starting to bulge.   First one of those I've seen fail in quite a while. Its nearly always the secondary side caps.

thekmanrocks@gmail.com: Jul 30 05:15PM -0700 Engineered to fail...

rssalerno@gmail.com: Jul 30 01:27PM -0700 Two years ago the DIG-220 salt water generator for our pool started acting up. The two line VFD display was displaying gibberish although the unit still functioned & generated chlorine. I got lucky and found failed solder joints on the 10,000 µF caps on the power board and touching up the solder joints fixed it. Two years later my luck ran out and now the display is completely dead and the check system light is blinking a two short-one long-one short pattern. Have not been able to find out what this means. Upon inspection I found two of the six 1,000 µF caps were bulging so I replaced all six. One of the fans was pretty sticky so a little WD-40 took care of that. Put it back together and still fubar. Bummer! I'm waiting to get my hands on a signal generator so I can do an ESR check on all caps on both boards but in the meantime, anyone have a schematic or service manual, or any other suggestions for troubleshooting this unit? thanks, Russ S.

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.