Blind vias connect an exposed surface with an inner layer, but do not go through the entire board.

Buried vias connect inner layers with each other, and to not extend into the top or bottom layer.

Microvias are drilled with a laser instead of a regular drill bit, usually in a process step before the layers are laminated together.

While there is no technical reason why blind and buries vias couldn't be drilled regularly, their main use case is in BGA breakout, where high density is important, and mechanical drills would be too fragile.

Thus, blind and buried vias are microvias.

A four layer board is constructed by laminating two thinner two layer boards together, and connecting these together. Blind vias can then be placed between layer 1 and 2, and between layer 3 and 4, and do not affect the other half of the board.

Buried vias become possible starting from four layers on -- 1-2, 1-2-3, 4-5-6 and 5-6 are possible options for blind vias, and 2-3 is a possible option for a buried via.

Using microvias and restricting the layers touched by the via mainly defines which drill file the coordinates go into, and which layers get a copper blob around these coordinates. It is perfectly possible to use a microvia through all layers as well.

Drill pair properties define which layers are manufactured together. Usually, 1-2, 3-4, 5-6 etc. go together, unless you have a strange stackup. In general, try to make microvias only between drill pairs, as manufacturing can become more expensive if there are additional drilling and plating steps even for the in-between substrate (here, normal vias should probably work fine.
 One thing about microvias is that each via connect two adjacent layers, only. The laser cannot punch through more than two layers. To connect layers that are not adjacent or several layers you need to setup staggered or stacked microvias.
Stacked are just that: stacked on top each other. Staggered are placed next to each other but not on the same layer.
<img src="https://m.eet.com/contenteetimes/images/Design/Embedded/2015/01-15/Nexlogic%20BGA%20-Fig-8-450.jpg" alt="picture of stacked and staggered microvias">

Altium PCB Layout: The Difference of Through Via, Micro Via, and Burried Via

Got part of my question from here:

100g to go to the 100th line 
50p to go to 50% into the file 
100P to go to the line containing 100th byte 

To determine the current line number or byte offset, use <kbd>Ctrl</kbd>+<kbd>g</kbd>.

"less" (linux) get/go-to X offset in file

First, you could try replacing the diodes with square-law device tied BJT's. As it mentions in the image, the stability improves.

<img src="https://i.stack.imgur.com/d3rPt.png" alt="log amplifier">

Instead of reinventing the wheel, it may be useful to check out TI's guide to logarithmic amplifiers. In particular, figure 1 with I_in as the input current. 

<img src="https://i.stack.imgur.com/LYVQ8.png" alt="log amplifier">

To quote the pdf a bit more ... "This confirms that the circuit output voltage is logarithmically related to the circuit's input."
 You have a couple of problems with your circuit. 1st, LTC6268-10 is a 5V part. You can't go and feed it +/- 5V! At +/-2.5V the circuit works more like advertised. 

Second, your diode circuit is oscillating because the opamp feedback gets out of whack. Very scientific, I know, but without bothering to do the hard math, you can fix this by adding a series resistor to the light sensor which matches the TC of your bypass resistor. You also need a series resistor on the diode. Lets use 100R for that. 

For the light sensor series resistor 1k + 1p equals about 12p and 82R. If we experiment a bit we'll find that 22R gives faster response but more ringing and 1k is unstable. 

3rd, You now have a voltage limiting circuit, congragulations! Alas, MMSD4148 is not a fast recovery diode, it takes tardy 5ns to switch off. That's not good for 10ns pulses! 
<img src="https://i.stack.imgur.com/uKrKe.png" alt="MMSD4148 + 100R">

Let's replace it with a much more reasonable vishay BAS70E6327 with 100ps Trr. 

4th, yay, now we have voltage clamping that works fairly reasonably. However .. it's not exactly balanced. Going down, that diode + 100R resistor will pull the output down much faster than 1k can charge the 12pF capacitor in the other direction. To add insult to injury, 100R clamps the voltage fairly close to the Vf so we see a nice sharp transition in one direction and RC droop in the other.
<img src="https://i.stack.imgur.com/bHwJt.png" alt="BAS70 + 100R in series">

We can make this look prettier by changing series resistor to 330R but it mostly makes it look better as now the voltage clap is at higher voltage and ringing is eliminated but it doesn't actually do anything about returning to zero.
<img src="https://i.stack.imgur.com/y4fEO.png" alt="BAS70 + 330R in series">

That droop is caused by the parasitic ~2pF capacitance of that diode. So basically you want ultrafast recovery, ultralow reverse current and ultrasmall capacitance. Don't we all.

Your basic problem here in general is that your measurement range is fairly unreasonable. On the other hand you want to measure 1uA/1mV signal (how?) and then you come back and want to handle 1mA/1V signal too with the same circuit! You get that tail-off from RC delay that'll round things off more and more the stronger the signal is. At 1mA it's +14ns to cross 1mV. At 100uA it's 11ns. at 10uA it's about 8ns. At 1uA you've got the opposite problem as the signal doesn't reach 1mV but infinitely gets closer. 

So definitely for any kind of fidelity this needs some other kind of circuit or more limited range of signal or longer pulses.. It would be also helpful to properly do the feedback loop stability analysis as it's obviously marginal here. I think using 500MHz high slew rate amplifier would work better than 4GHz amplifier, you can get same 3kV/us slew rate from 300-500MHz parts and they're much more stable. Also it'd help if you can find that perfect diode but I'll leave it as an excercise for you, I already spent ages on this..

Here's the modified circuit.
<img src="https://i.stack.imgur.com/NV2DS.png" alt="Circuit without capacitor as we've got parasitic cap from diode already">

Limiting Output Voltage of the Opamp-to avoid saturation

The modification is a proper part of the design of the product. So, no, don't "hand draw that on the PDF". 

Add it to the schematics. You should have proper versioning control for your schematics anyway (Try git. It's thought for source code, but it works with any file type – you just won't get useful differences displayed between revisions, but that's not a problem here). Clearly annotate it in your schematics. If your EDA suite allows that, change color, stroke, whatever of the modification to make clear it's a modification.

If your modification is just a wire bridge: it's not uncommon for schematic design programs to have some kind of special "external connection" component. 

Since you're probably want to still be able to generate a valid board from that schematic, make sure the "external connection" component you have has a small single pad that you can place on a wire in your board design. That way, you also get a guarantee you have something to solder too in the end.

Again, I don't know what software you use, but it will still make sense to "formalize" even the crudest hack into some kind of footprint/component: your wire bridge could simply consist of two components with one pad each, which share the same net name. That way, you could actually "place" the fix in your board design, and hence, have it documented.

Also, your board might fail design rule checks. Which would obviously be correct.
 Create a new minor revision for the intermediate changes and indicate them however you like as long as they can be printed out or copied reliably. They will not be used to create new faulty PCBs hopefully in the future so it is a dead end path.

The next more significant revision should incorporate those changes and any others that may have occurred which will allow new boards to have missing parts placed and traces to be routed correctly. That version does not need to indicate the history of how you got there as it is in the version history already.

Avoid reallocating part designators if you have released any documents outside the design office.
 The classic way is to designate a (paper) copy of the schematic as a working master. All changes get entered on the schematic in red. When you're ready to fab the next rev of the board, you hand over the master to whoever is doing the schematics.

At the same time, you need to start keeping a notebook. Sketch out your design ideas as you think of them, and record your design experience. When it comes time to start troubleshooting, record all changes you make in your notebook, as well as marking up the schematics. Then, when you're ready to update the design, cross-check the master schematic with the notebook, and make sure that they agree.

How do you document bodges?

<blockquote>
 What makes fast mode fast?
</blockquote>

The difference is certainly well-hidden :-) Look at the AC Characteristics table in the datasheet. It says that the normal <code>READ</code> command (03h) has a maximum clock frequency of 65 MHz. Whereas all other commands, therefore including the <code>FAST_READ</code> command (0Bh), have a maximum clock frequency of 100 MHz:

<img src="https://i.stack.imgur.com/rUeNU.png" alt="A25L032 AC Characteristics">

This is why <code>FAST_READ</code> can be faster, depending on the actual clock frequency chosen.

However due to the dummy byte required when using the <code>FAST_READ</code> command (but not when using the normal <code>READ</code> command), then if both commands are used for many small reads with a clock frequency of &lt;=65 MHz, then the data throughput would actually be slower when using <code>FAST_READ</code> commands, compared to using <code>READ</code> commands, due to the overhead of all the dummy bytes (one per <code>FAST_READ</code> command sent to the device).

If a faster (&gt;65 MHz) clock frequency is used, and if fewer but larger <code>FAST_READ</code> commands were used (because the dummy byte overhead is "per command"), then the greater throughput would start to outweigh the overhead of the dummy bytes.

<blockquote>
 Why not just have a single mode that can work upto 100MHz?
</blockquote>

This is getting into the realm of speculation - I suspect that there is an internal minimum latency required to start the data read process (perhaps charging the internal charge pump?).

My hypothesis is that the latency could be "hidden" behind the time required to receive the <code>READ</code> command at &lt;=65 MHz (i.e. relatively slower speeds), but the required latency (before starting to read) is longer than the time taken to receive a <code>READ</code> command at &gt;65 Mhz (i.e. relatively faster speeds). That could explain why a different command protocol (which adds an extra byte before the data read phase starts) is needed for faster speed reading. A dummy byte is required for the <code>FAST_READ</code> and <code>FAST_READ_DUAL_OUTPUT</code> commands, and a mode byte is required for the <code>FAST_READ_DUAL_INPUT_OUTPUT</code> command. These bytes all serve to delay the start of the data output phase, which suggests to me a fixed internal latency requirement - something which I have seen before with other devices. Of course the real answer would need to come from the manufacturer :-)

What is the difference between "normal read" and "fast read" in the flash A25L032

Yes, newer LEDs are also static sensitive. I learned this the hard way when testing a batch of blue SOIC chips with (unknown to me) a soldering iron with defective ground which was later found to be floating at &gt;30V.
I can assure you that the LEDs did not work after this experience and it wasn't heat as a single touch to one side of a diode at even 100C ruined it.
Some started flashing like demented strobes, some just died completely.

Incidentally newer LEDs based on quantum wells are also highly sensitive to ionizing radiation, I learned this by reading about folks venturing into the ruins at Tchernobyl and Fukushima. The white LEDs in their caving lamps would often begin to flicker and eventually fail, at survivable (for humans) radiation doses.
Silicon carbide ones are less so but still eventually fail, rumor has it that Cold War era LED technology is still used today on the ISS Zvezda module and the Progress spacecraft.
I did also find that some GaN based blue LEDs can be used as varicaps, in some cases with no effect from brightness loss. The mechanism can generate 100pF changes comparable with an expensive part.

Why are 'modern' high-efficiency LEDs easier to damage than 'old' LEDs?

It is a mouth-full to say as a full name.
I found this description here.



<blockquote>
 hFE is an abbreviation, and it stands for "Hybrid parameter forward current gain, common emitter", and is a measure of the DC gain of a
 junction transistor. So on a multimeter, it indicates a mode where
 the meter can measure (probably crudely), the HFE of a transistor.
</blockquote>

EDIT: When I talk about transistor gain with other engineer's, we often use the term 'beta', yet in a datasheet 'hFE' is normally what is used by the manufacture based on calibrated equipment for a standalone transistor. For some transistors hFE readings may be done at several crucial frequencies as well as DC. 'Beta' is a better term for common-base designs, or just a general statement about DC and/or AC current gain in a known circuit. As a refinement of the original answer, @carloc mentioned that a 'hFE' spelling refers to a DC signal of relatively large amplitude, while 'hfe' refers to a small signal measured deferentially around some common bias point. No specific thresholds were given, though my original answer refers to 'hFE', the DC gain of the transistor.
 I'm not sure if I'm understood correctly the question; You want to know the meaning of "F" and "E"? 
H is for Hybrid (parameter), F meaning Forward (current amplification) and E is for common Emitter configuration.
 In simple terms it runs a small current fron base to emitter and measures how many times greater the resulting collector to emitter current is. This is the DC amplification or DC beta. Besides a crude test to see if the transistor is working it is useful in DC awitching circuits. For AC beta they measure amount of change in collector current resulting from a change in base current.

What is Full form of hFE of a digital multimeter?

There is a line in the Parameters table on p.1 of the datasheet, which describes the function of the Tri-state.

<img src="https://i.stack.imgur.com/3Uzwn.png" alt="enter image description here">

It's a kind of an enable-disable pin. 

<ul>
<li>If Tri-state pin is logic "1", then oscillator is connected to the output pin. Same happens if Tri-state is left unconnected (there's probably an internal pull-up). </li>
<li>If Tri-state pin is logic "0", then oscillator is not connected to the output pin, and output is floating. The fact that it's floating may be useful if you need to switch between several clock sources. You would enable one of them, and Tri-state the others to prevent contention between multiple outputs.</li>
</ul>

edit: 
Here's an example where an enable/disable with tri-state is used with an external clock source. When connecting external clock source to J1, the J2 jumper should be installed. The resistor R1 protects from a direct short between clock outputs.

<img src="https://i.stack.imgur.com/eQRnI.png" alt="enter image description here"> 
(schematic from p.22 in this user guide and datasheet for that oscillator)
 There are already a slew of answers that explain the functioning of the enable pin on the oscillator part. Let me provide some reasons that pin can be useful in real world situations.

<ol>
<li>Sometimes a circuit board is tested with an automated test fixture with pogo pin test points all over the board. In such test environments the clocks for the circuit are often supplied from the tester equipment so it is necessary to shut off on board oscillators so that the tester clocks can drive the board.</li>
<li>In similar test situations like #1 above the test fixtures with pogo pins have 100's of long wires connecting the test fixture to the test equipment. On onboard oscillators can create a problem with overall noise if they are allowed to run. A test point access to disable the oscillators can be beneficial to shut off the oscillator.</li>
<li>Some board designs may have logic tied to the oscillator output. That logic consumes power when the clocks are running. If the design is one that needs to save power by going to sleep for periods of time a GPIO can be attached to the oscillator enable to allow it to be disabled when entering the sleep state.</li>
<li>There are some complex ICs that have multiple power rails that must be sequenced on and off to ensure proper operation. There are cases where sequencing requirements also require that clocks to the part are held off until the appropriate point in the power sequence. Clocks provided by oscillators can use the enable pin to hold it off till the right time.</li>
</ol>
 When the tri-state pin is High or not connected, the oscillator will produce its normal output. If the tri-state pin is connected to Ground, the oscillator output will be high impedance, effectively disabling the output. This is described in the second-last line of the "Standard Specifications" table.

You might want to use this feature if you wanted to switch between two or more clock sources.

What is the purpose of a tri-state pin in a Oscillator

The Matsuo date code is explained in more detail in their other datasheets,
such as
p. 2 of the
Matsuo Tantalum Solid Electrolytic Capacitors datasheet.

The codes repeat every 4 years:

The 12 uppercase letters A through M (minus "I") represent the 12 months Jan through December for one of the years 1997, 2001, 2005, 2009, 2013, 2017, ...

The 12 uppercase letters N through Z (minus "O") represent the 12 months Jan through December for one of the years 1998, 2002, 2006, 2010, 2014, 2018, ...

The 12 lowercase letters a through m (minus "i") represent the 12 months Jan through December for one of the years 1999, 2003, 2007, 2011, 2015, 2019, ...

The 12 lowercase letters n through z (minus "o") represent the 12 months Jan through December for one of the years 2000, 2004, 2008, 2012, 2016, 2020, ...

The capacitor you have with date code "M" was apparently manufactured in December in one of the years 1997, 2001, 2005, 2009, or 2013.
(Since you had it in your hands June 2016 we can rule out any later years).

The Jaro date code looks like it might be exactly the same as the Matsuo date code.
 This coding standard is defined according to Japanese Industrial Standard JIS
5101, table 12 (as stated in the datasheet linked by davidcary) and in the Corresponding International Standards IEC 60384-1:2008 that refers, for the coding method, to IEC-60062, section 6.3.1 – Four-year cycle (small components, SM and THM only).
<img src="https://i.stack.imgur.com/iN72W.png" alt="Table 12 – One-character code – 4-year cycle">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IEC-60062: Table 12 – One-character code – 4-year cycle
&nbsp; 
N.B.: The letters "O","o", "I" and "i" are omitted to avoid ambiguity.
For the same reason, IEC-60062 stated that:
<blockquote>
If there is a possibility that a single lower-case letter could be
read as an upper-case letter, for example, v for V, the lower-case
letter could be marked with a cross bar above it.
</blockquote>
&nbsp;
<h3>Example (from the Original Question)</h3>
The capacitor Matsuo 553 with date code "M" was
manufactured in December in one of the years 1997, 2001, 2005, 2009, or 2013.
(I know the PCB came from '90, then the year is 1997).
The Jaro date code looks like it might be exactly the same as the Matsuo date
code.
(Thanks to davidcary)

Date code in components marking

A big lead that should help you is the fact that you can access each of the player's statistics in the world's <code>stats</code> folder.

Inside the folder you'll see a bunch of JSON files, one for each player, named with their UUID:

<img src="https://i.stack.imgur.com/xQ0un.png" alt="JSON files">

Open up the JSON files with any text editor, and you can look through everything the game stores to show the player on their statistics screen. One of the things you'll probably want to look for is if the player's "stat.useItem.minecraft.tnt" (how many times they've placed TNT) increased between the saves.

<hr>

Another thing to check in the NBT data is both player's enderchests under the <code>EnderItems</code> tag; this may be where they are hiding the diamonds.

Using NBTExplorer, or MCEdit, you should also be able to check both player's coordinates before and after the incident, although it may be that whichever one did it ran far away immediately afterwards. 
 The easiest way to know for certain is to ask them directly with their parents present, both at the same time ideally. Tell their parents that someone has been bullying other kids in the online game you host and that, based on the logs, you can determine that the only people online at the time were their kids. Then you can let the parents discuss this with their kids and take the necessary steps.

Alternatively, you say they blew something up and destroyed blocks, right? You could in theory check if one of them has lost materials that can make a button, a redstone torch or a lever, and how much durability their pickaxe and/or axe has lost. However, this would be much more intensive to check, because you also need to verify that they didn't lose that in another way.

New posts