I think (correct me if I'm wrong here) that if you have one or two houses with solar it is much easier for that power to be consumed by someone that is being fed power from the same transformer as you are.

This would seem like a much more manageable situation than if everyone had solar in your neighborhood and it has to start stepping up through the transformers looking for somewhere else to go.

Now if every neighborhood starts pushing power through the grid and all of these systems designed to put 10,000 amps one way go to shuffling around a few hundred amps from neighborhood to neighborhood.

Even if everyone had a radio link to the power company giving instant feedback of their generation, it would still be hard to keep voltage constant as clouds keep turning thousands of individual sources up and down.

With less and less power coming from the actual power company, who will be in charge of the grid? Imagine when we meet the break even point and power companies can shut off most of the day, who or what are all those thousands of separate Chinese inverters going to sync to?

In my imagination, I see waves of frequency, voltage and current fluctuations rippling uncontrollably around from transformer to transformer. Whole pulsating neighborhoods throbbing and blinking as these devices struggle to interoperate. A battle-royalle of cheap buggy firmwares fighting it to see who has the real 60 HZ... long after the power company automatically disconnected them.

Oh the voltage went up a little, I'll be a good little inverter and match it...

Oh hey the voltage went up a little, I'll be a good little inverter and match it.

That phase is kinda weird, good thing I can reshape it a little when I match it.

Wow my output just dropped 16 volts, Guess we need more juice quick, better step it up a notch!

7 second difference between time on feed and my computer! Can anyone else confirm this error?

  is this a problem with systemd:)

This always helps...

https://www.youtube.com/watch?...

I'll bet the other 10 or so they made worked fine, but they were deigned to point down!

I wrote a few gateway (protocol conversion) applications in assembly, and they were full of fun names and labels.

cp BeenWaiting, aWhile
brge CallTheBitchAgain

cp BeenWaiting, FuckingForever
brge WeGotFucked
.
.
.
CallTheBitchAgain: // because XYZ can't write a scheduler that works
decr TXbyteCounter
jmp RequestPacket
ret

WeGotFucked: // because losing the state of a connected peripheral when they're too busy is an acceptable practice to some
jmp BandAidRestart
jmp ConnectWithKey
ret

It's incredibly precise, I used to test ECU software to 12,000 RPM. That's 200 Revolutions per Second, or 72,000 Degrees per Second.

At 33Mhz, you have about 458 clock cycles per degree, so if you have a 60 tooth crank sensor with 6 degrees per tooth, you have a real time position update you need to task switch to, synchronize with, and schedule events on coming every 2750 clock cycles. In between them, you have to read filter and diagnose all of the sensors so you can look up, interpolate, and calculate all of the fuel and spark info, convert it back to binary time counts, then load or reload all of the different hardware timers safely at the proper time so they don't skip or wrap around.

You have to have over 7200 events (start and end of: fuel, air, spark on a 6 cyl, low emissions 2 stroke) happen at the exact time every second or the engine will misfire.

Starting with the Motorola MPC555 there was also a TPU (Time Processing Unit) that had multiple "self-synchronizing" counters and timers you can daisy chain, that took care of most of the heavy lifting (besides scheduling it!!!)

The TPU, along with a PowerPC core or two now allows modern ECUs to calculate everything based on a Simulink model of the engine while all of this is going on.

MTO

Microsoft Trackball Optical

http://vimeo.com/105855767

http://portableapps.com/

Or... They worked so well some(TLA)body got them all, while Intel tweaked it into knights corner / knights landing / xeon phi, where they now use it to dominate the top 500.

I did a starter on a Chrysler 300M, and if you didn't want to take the exhaust and the motor mount off, you can take the solenoid off, then take off the starter motor from the snout, then take the snout off the block, and get it out in like 20 pieces.

After all that bull I really didn't want to put it all back together (paper clips in the brushes, shims on the shaft where I can't see) even though all I found was just a corroded steel on copper washer in the solenoid. I cleaned it up, and greased it up and put it back together, it seemed to work fine and it is still working 5 years later.

A new starter was outrageous, and the labor was even worse.

Funniest part was my friend watching me come out with piece after piece, I know she was wondering how it was ever going to go back together again, or if it was going to just crap out on her again (really a rusty washer??? All those pieces??? Should I just have it towed???)

300M?

There's this glue called goop (not that goop from the hardware store) that they have at hobby stores that will hold aluminum tubing to nitro-methanol and oil soaked fiberglass. We used to use it for model boats and it would hold anything, to anything. It took a long time to set but it held on forever after that.

1. Hook Up oscilloscope
2. Start Engine
3. Look at oscilloscope
4. Replace Or Rebuild correct part

If you have to make #1 from an Arduino and a couple of resistors, bonus points for you.

If you release the resulting #1 as Autoduino or Alternatoduino on github it's a double bonus.

Triple bonus for a YouTube vid.

Have you priced a Kirby lately?