Digest for sci.electronics.repair@googlegroups.com - 9 updates in 5 topics

mogulah@hotmail.com: Jan 02 08:19AM -0800

On Friday, January 1, 2016 at 10:27:18 PM UTC-5, BTR1701 wrote:
> > does not want to do.
 
> It's not a matter of want. Apple simply *can't* decrypt customers' phones.
> They don't hold the decryption keys.
 
If its Blackberry, then which government? State? Federal? The UN, maybe? China, Iran or Russia or Israel?
Tim R <timothy42b@aol.com>: Jan 01 06:40PM -0800

I'm a mechanical engineer but I've been in management a long time, I don't get to do much technical stuff.
 
This week I got called to a gas leak. The emergency response and the mechanics had already been there and confirmed safe to reoccupy, but somebody wasn't so sure and called me.
 
These things are 80% one problem and 9% the other. The crew that showed up found and fixed the 80% problem, but it wasn't actually causing the leak. The leak was somewhere else. Just because one thing is broken doesn't mean something else isn't broken too.
 
Once a problem is identified, attentional blindness sets in. Contrary evidence is not just ignored, it cannot be seen.
 
In this case the pilot light was out in the kitchen, and they assumed the gas smell came from it. They shut off the gas to the kitchen and authorized the building to be reoccupied.
 
They ignored the evidence the real leak was somewhere else - well, they were incapable of seeing that evidence because they already knew what was wrong.
 
When I got on scene it took little time to find where the smell was coming from. Partly that's from my bias to try to avoid assigning the cause until I've looked at all the evidence, but partly it's from knowing human nature and knowing if it were the usual problem they would have fixed it the first time, and it obviously wasn't.
 
I sent the mechanics back and told them where to look, and the second trip they fixed it correctly. Of course I had to keep quiet my part in it, there's always politics in these things.
 
So yes, fix the most likely fault first, but bear in mind the potential cost of it being something else.
John Heath <heathjohn2@gmail.com>: Jan 01 09:55PM -0800

On Friday, January 1, 2016 at 9:41:01 PM UTC-5, Tim R wrote:
 
> When I got on scene it took little time to find where the smell was coming from. Partly that's from my bias to try to avoid assigning the cause until I've looked at all the evidence, but partly it's from knowing human nature and knowing if it were the usual problem they would have fixed it the first time, and it obviously wasn't.
 
> I sent the mechanics back and told them where to look, and the second trip they fixed it correctly. Of course I had to keep quiet my part in it, there's always politics in these things.
 
> So yes, fix the most likely fault first, but bear in mind the potential cost of it being something else.
 
I hear that. I remember being stuck on a problem so I asked a friend for a fresh look at it. He looks around then thought about it for a minute. He then looked at me and said " if you touch your head and it hurts and you touch you arm and it hurts and you touch your toe and it hurts maybe it is your finger that is the problem ". That was a strange way to put it but he was 100 percent right as I had my scope probe on 1 to 1 instead of 10 to 1 causing a loading problem. It is always a good idea to get a second opinion when you are spinning your wheels.
 
Another unrelated problem. You being an engineer will enjoy this one. The city has a water leak. They are not sure where the leak is. They can not dig up a whole city block to find it so they use a clever trick. They put two microphones about 50 feet apart where the leak seems to be. Then then record the random sound of water hissing out of the pipe. The two microphones are wired to left and right channel of the recorder. By adjusting the time delay of the right or left microphone they can find the sweet spot where the random noise from one microphone matches the random noise of the other microphone. Once the delay is know they know where the leak is within 1 or 2 feet. That is a clever trick.
 
There is a similar trick in cabling. You send a pulse down a cable that is about 80 percent c propagation speed. If you hear an echo you have a problem. By timing the echo at 80 percent c you know where the problem is.
jurb6006@gmail.com: Jan 01 11:04PM -0800

>"Another unrelated problem. You being an engineer will enjoy this >one. The city has a water leak. They are not sure where the leak is. >They can not dig up a whole city block to find it so they use a >clever trick. They put two microphones about 50 feet apart where the >leak seems to be. Then then record the random sound of water hissing >out of the pipe. The two microphones are wired to left and right >channel of the recorder. By adjusting the time delay of the right or >left microphone they can find the sweet spot where the random noise >from one microphone matches the random noise of the other >microphone. Once the delay is know they know where the leak is >within 1 or 2 feet. That is a clever trick. "
 
HA, HAHAHAHAHAH
 
HydroTDR
 
Water Domain reflectometry
 
Feel free to add your own, this could be fun. Water Wave Technology.
 
Oh, and sound is so much faster in water, but then that gives alot more accurate transmission, which os probably necessary to make this possible.
 
WDR. Water Domain Reflectometerty.
 
Yeah fukit
Tim R <timothy42b@aol.com>: Jan 02 07:14AM -0800

> >"Another unrelated problem. You being an engineer will enjoy this >one. The city has a water leak. They are not sure where the leak is. >They can not dig up a whole city block to find it so they use a >clever trick. They put two microphones about 50 feet apart where the >leak seems to be. Then then record the random sound of water hissing >out of the pipe. The two microphones are wired to left and right >channel of the recorder. By adjusting the time delay of the right or >left microphone they can find the sweet spot where the random noise >from one microphone matches the random noise of the other >microphone. Once the delay is know they know where the leak is >within 1 or 2 feet. That is a clever trick. "
 
> HA, HAHAHAHAHAH
 
> HydroTDR
 
Hah, I can top that one.
 
We had a power outage, traced to a break somewhere in an underground line. It was one of those ancient coaxial feeders, and it ran a good quarter mile through the woods, maybe more, it's been a while. How to find the break?
 
We hired this specialist with a thumper, which is a pulsed high voltage DC. It makes a noise like a gunshot when the arc jumps the gap. You walk the route of the line (which you never know exactly because your drawings are always a little sketchy) and listen.
 
Usually this works. Not this time - it arced for a while, then somehow the arc welded the break back together. No more pulses, no way to find the spot, we just turned the power back on and let it go.
"Paul M. Cook" <pmcook@gte.net>: Jan 01 08:36PM -0500

Thanks to everyone here, below is a summary I wrote of my current
understanding of just the UPnP versus Port Forwarding issue for
setting up the Transmission bittorrent client on Linux (Ubuntu) for
optimal speed.
 
It's written in my words, so, if there are errors in my understanding,
I'm fine with you pointing them out!
 
My summary of what was learned in this thread about UPnP & Port Forwarding
 
(0) The way things work is that an incoming request to WAN external IP
1.2.3.4 on port 12345 hits the SOHO router. Without port forwarding,
the SOHO router will drop that request (or any request to
any port).
 
But, with port forwarding, the router sees the external port WAN
request for 1.2.3.4:43101 and it forwards that external port to
a static LAN internal port of 192.168.1.10:43101, which the
Transmission client is listening on for upload requests (which
apparently require both TCP & UDP messages).

(Transmission settings are in $HOME/.config/transmission/settings.json)
 
(1) Since bittorrent maintains two download queues, the first priority
going to those who are uploading data and the second going to those
who are not uploading data, if I'm not uploading data, then I will
only download data when the first queue is empty.
 
(2) That means two different things if I don't open a port to the world:
- For those people with public sockets, I will be in the first
queue because they can get data from me even though I don't
have a public socket myself.
- For those people without public sockets, I will be in the
second queue because, to them, I'm not uploading any data
because I don't have a public upload socket open.
 
(3) Overall, not opening a port will probably increase my download
times (depending on a combination of how many other people have
public sockets open and on how full that first queue is).
 
(4) The *easiest* way to open a port for those external clients who
do not have a public socket is to simply turn on UPnP on both
the SOHO router and in Transmission. Optionally, if UPnP is
turned on in Transmission, I can set Transmission to use a
random port each time the application is started.
 
(5) The *safest* way to open a port is to turn off UPnP in both the
SOHO router and in the Transmission app, and just manually
forward a port in the router & set that same port in Transmission.
Pick a random port between 49152 & 65535. The default is 51413.
https://trac.transmissionbt.com/wiki/PortForwardingGuide

However, there are a bunch of things you have to do in order
to accomplish that task:
(a) You'll need to have your computer on a static IP address
on the LAN (e.g., 192.168.1.10).
This can be set (based on the computer wlan0 MAC address)
by the router, or, this can be set on the Ubuntu computer.
(b) You'll need to select an unused external/internal port set
to forward UDP & TCP packets to (e.g., port 51413)
(This port needs to be between 1025 and 65535.)
(c) You'll want to doublecheck your /etc/services files to ensure
whatever port you chose is not being otherwise used.
In my case, there are no ports in /etc/services between
port 27374 & 30865, and only 3 ports higher than 30865
{57000,60177,60179}, so, all other ports are fair game.
Application = trans
 
NOTE: There are other things you can set to improve Transmission speeds!
http://falkhusemann.de/blog/2012/07/transmission-utp-and-udp-buffer-optimizations/
 
REFERENCES:
http://portforward.com/help/portforwarding.htm
http://portforward.com/english/routers/port_forwarding
http://portforward.com/english/routers/port_forwarding/Netgear/WNDR3400v2/Transmission.htm
http://techsupportalert.com/content/optimizing-transmission-bittorrent-client-speed.htm
https://trac.transmissionbt.com/wiki/PortClosed
avagadro7@gmail.com: Jan 01 10:01AM -0800

AE6KS
 
AMAZING internet finding
 
 
Light Source: Bulb: Par 36 (4411-3) 12v
Designed at 12.8v, 2.9 amp, 35 watt, 2500 cp
 
http://www.partdeal.com/truck-lite-par-36-rubber-multi-purpose-work-lamp-12v-clear-620w.html?zmam=74973193&zmas=1&zmac=4&zmap=77153709&gclid=CKqZ0vKVicoCFQEoHwodtfAP6gLight Source: Bulb: Par 36 (4411-3) 12v
Designed at 12.8v, 2.9 amp, 35 watt, 2500 cp
 
http://www.partdeal.com/truck-lite-par-36-rubber-multi-purpose-work-lamp-12v-clear-620w.html?zmam=74973193&zmas=1&zmac=4&zmap=77153709&gclid=CKqZ0vKVicoCFQEoHwodtfAP6g
 
 
maybe buy 2 more...prob is the rubber case is not easily removed....forces in eg tire rim removal exceed what I expect from the glass edge.
 
the light is abaft the platform roof rack on my van, on a 1x3" stalk reachable if you're hungry or insane and 6' from the rear bumper...the ;ight is good and for $8.
 
There's a $35 Hella incandescent utility lamp on the shelf but....I see looking now for the $8 9N Model LED's should be within reach by spring.
 
Expansive backup lighting with LED running light flashers, BEEP BEEP ER and a recording calling
 
ATENCIÓN ATENCIÓN VEHÍCULO SE MUEVE
 
is AAA at MacDonalds, Yellowstone and Venice.
 
The man with the stuck button should try CRC Contact Cleaner from Walmart. Hold keyboard upside down, spray, toothbrush, and wiggle then spray again. Let dry upside down for an hour.
avagadro7@gmail.com: Jan 01 10:18AM -0800

AE6KS
 
oh yeah. I have gramlins breaking in wiring hot to ground. In repairing this last time before chaining doors, measured a 14' run with 8Ga then 10Ga with 12Ga for 12' more at 12.65V off 13V at the Odyssey battery...via Powerstreams calculator.
 
The roof horn blat blat blat deteres vandals so the pro vandals broke in disconnecting the system.
 
Where the extra wire comes from ....
 
After going thru the calculator all 5 roof lights, alarm horn went with individual 10Ga power supply and grounds. The foot dimmer switch 6 relay board disconnecting ground for 4 driving lamps impresses the curious.
 
There a relay box for 10Ga to the Hella headlamp units but need to work in a fail safe back up to the driving lights. The Hella headlamps hi beams maybe straving with Frod wires.
 
So I dida jig for a minute after measuring 12.65
 
I haven't sat behind the light bar LED systems. The smooth even flow of light onto the road surface is impressive from outside. Using the LED bar in rain on a dark road surface is an improvement over white halogens ?
 
As with bike lights....we would believe someone has worked out an answer for an obvious problem...
gyro_john <john.wetzel@shaw.ca>: Jan 01 09:17AM -0800

On Monday, December 28, 2015 at 4:17:44 PM UTC-6, Bob Engelhardt wrote:
 
> Is there anything else that I can try?
 
> Thanks,
> Bob
 
Might this be a battery issue? You see, a lot of these modern battery packs have a Battery Management System circuit board inside the battery pack, and its job is to properly charge the batteries and shut off the battery when it's drained. If the battery pack and the saw have to communicate with each other, maybe the BMS says it's time to shut off the battery, yet the battery is not yet dead.
 
You might be able to check by swapping in a different battery pack.
 
Good luck and Happy New Year.
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 - 9 updates in 5 topics"

Post a Comment