mng2

It's essentially statistical. First, the beam. The beam at a collider is actually made out of longitudinal 'buckets' of particles. The buckets are timed to cross at the interaction point inside the detector, where magnetic lens arrangements squeeze the beam as far down in physical size as is practical. By controlling the beam, you know when exactly to look for collision products, and expected collision rates are calculated from particle distributions and cross-sections.

Next, the detectors. There are a variety of detectors around the interaction point that serve different purposes. Broadly speaking, they measure deposited energy, and in which direction it is going. That's what physicists are interested in, so they can work out what those particles were.

Everything at an experiment like this is modeled and calculated. At the very bottom you have fundamental physics, particles being created and destroyed, modeled in a simulation tool such as Pythia. Once you know what's supposed to come out, you can simulate how the products behave in your detectors, by building a model in a tool like Geant. If you model from end to end, you essentially test physics theory against the hard bedrock of reality.

Yeah, it's not exact, but in RF/microwave work you often get on order of a dB of loss through the cable or connectors anyway. Plus signal sources and spectrum analyzers are not spec'ed to be as accurate as you might expect. So you end up with error bars in your head.

That reminds me of an infamous episode from my hometown's history: the surprise 'Welcome' sign installed by the county's Art Commission. It was widely panned and ended up being taken down after two months. Looking back at it now, the sign was indeed somewhat tacky, but the perception that the county had done this without seeking local input is what really drove the vitriol.

[0]: https://www.sfgate.com/news/article/Saying-Goodbye-to-Castro... [1]: https://www.eastbaytimes.com/2011/07/22/castro-valley-canoe-...

Back in '77, op-amps weren't as good as they are now in terms of PSRR and output power. That push-pull output stage is quaint but given that they wrapped it in the feedback loop of the last op-amp, it may have been a necessity at the time.

I have the same Pace box and can replicate. Pinging 1.1.1.1 from my OpenWrt router fails.

The biggest question in my mind about the ARC proposal is how well these new superconductors stand up to radiation. This is a concern for ITER as well, which uses more traditional superconductors. The ARC team is looking into it, but I'm going to remain unenthusiastic about ARC until they've really proven out the concept.

Agreed. Being a human pick and place for anything more than low tens of parts is incredibly unfun, and paying someone to manufacture one or two doesn't really make sense. I don't care if it takes a few days, I'd rather not be sitting for hours wearing down my fine motor skills and eyesight.

I recall seeing it on Slashdot back in the day (and guessing its meaning by context), but I first heard it in person from an older physicist, probably the right age to have been reading Heinlein as a youth.

"Hardware" tends to imply just electronics. It sounds like you want tutorials in robotics.

I don't mean to be contrarian but since there is a perfect counterexample near where I live...

https://goo.gl/maps/vfpo5KGRqhs

The 'VU9P has ~2.5M logic elements and 6840 DSP units. The M2S090 has ~90K logic elements and 84 math blocks. It's nowhere near the same class of device.

The AWS FPGA offering only makes sense if you absolutely need a massive FPGA connected to massive amounts of RAM, and don't want to spend the bucks to own it yourself.

The starting point is probably V.21 / Bell 103. Check out the datasheet for the AMI S3531 single-chip modem, it's got useful background and timing info.

That pricing sounds waaaay too low to me; these are big, cutting edge parts, basically unobtainium at the moment unless you have a close relationship with Xilinx. When they reach the channel they will not be cheap either.

https://octopart.com/search?q=xcvu9p

My friend at work is a former Navy Nuke and this came up the other day. He said that he felt a little misled coming out of the service since only a small fraction of his credits were eligible to transfer to a NucE degree program, due to it not being "calculus based". (He is a EE now.) It sounds like one could get into a NucE Tech position fairly readily though.

It's probably a price point issue. The latest Odroids have Exynos SoCs with the latest feature set and a price to match. Anything lower market is not going to have the chip IP, internal data bus, and high-speed transceiver IP to support these interfaces because the markets the SoCs were originally aimed at (cellphones, set-top boxes, IoT junk) don't need them.

I agree, I realized the truth of your second-to-last sentence sometime during grad school. These people have played the academia game and it worked out for them, and their sense of self-worth and prestige is tied to their standing inside the system. Of course, the academia game is a lot more difficult to play these days.

From what I've read, the theory amounts to "there are more photons bouncing off the fat end versus the thin end hence thrust." Which personally I think is highly questionable given the low-energy regime involved.

Yeah, and that's the crossing from Yerba Buena to SFMOMA. It's obviously designed to give pedestrians a lot of breathing room. Autonomous or not, blowing through that crossing was Very Bad.

You can estimate to some extent based on FPGA resources. For example you know you need X thousand flip-flops, Y hundred block RAMs, and Z hundred DSP blocks. And then you look at the switching speed specs and guess how fast you can clock it.

But in the projects that I've been involved with, it turns out that it just wasn't feasible to route all the stuff that was originally envisioned at the planned speed. Interconnect is a big killer of hopes and dreams, once your FPGA starts to fill up.

Really, the only way to be sure is to run your design all the way from synthesis to place and route. The problem with that is you rarely have the luxury of starting a hardware design with all the HDL already written.

I don't think the plasma being too hot is a problem in a tokamak. The average ion energy is not enough for fusion; we rely on the high-energy tail end of the Maxwellian distribution. Any potential source of heat loss from the ions is a liability, including the natural predilection for ions to transfer their energy to electrons, not to mention radiative losses. Keeping the plasma hot enough is really the essential problem.

Yep, steam turbines. For more exotic fusion scenarios that don't produce neutrons, Direct Conversion is a possibility, but that's even more pie-in-the-sky at this point.

It's an incremental step on a long road. To be sure, the ultimate goal is to understand how to control the plasma well enough to support indefinitely long pulses. But incremental improvements add up, or rather they compound like interest.

Agreed on the verification aspect. And what happens when an error makes it through and your customer has to scrap $xK worth of boards?

I work at a $largeco with dedicated footprints people and a long DFM pipeline, and footprint errors still get through from time to time. When there's tens of thousands of dollars riding on a board turn, you're still going to check it yourself.

I have calendar reminders set four months apart to get and review credit reports, going round-robin through credit agencies. This gets me a (free) credit report 3 times a year.

I have a Citi Doublecash with no annual fee and they provide a credit score. Been with them for many years though so your eligibility may vary.

I do FPGAs and hardware design. The FPGA part of my work is more like software I guess; bug fixes, feature enhancements, maintenance, etc. Hardware design comes in waves depending on how complex the design is and how the requirements change. When it's "design season" I spend most of my time in schematic and PCB layout, then wait for hardware to come back, then do bringup. I also get to dabble a bit in RF/microwave and DSP.

But as others have said, EE jobs run the gamut. Depending on where you go to school and what emphasis you choose, you could be doing digital IC design (which contains multitudes within itself, e.g. high-level architecture, clock trees, verification, integration), analog IC design, RFIC design, board-level RF, chip package design, embedded systems, power electronics, antennas, FPGA, HDL/IP cores, test engineering, digital signal processing, control theory, communications systems -- the list goes on and on.

Judging from 2008, much emptier BART trains and reasonable traffic on the freeway.

Those are various combinations of IC package, temperature grade, and bulk packaging. They are demonstrating that all the different types they sell have gone through environmental testing. There is no such thing as 'higher quality', generally, but a part with extended temperature range or a faster speed grade does cost more.

On the other hand, if you get accustomed to using better software, and end up working at a place that uses, say, Orcad 16.2, it will be much more painful of an experience.

I admire your tenacity. A thought about the DDR2 interface: since you own both sides of it, you can cheat. Write identical data to addresses n and n+1, and use the standard rising edge on the FPGA. When reading data back to the SoC, throw away every other word.

I wouldn't say datasheets lie as much as Oh hey I didn't tell you that this sentence here on page 9 is super important and also this little note hidden in the table on page 13 and by the way this little schematic on page 11 of the {document that's not the main datasheet} is critical...