|
Andrew Zonenberg
@
azonenberg
The lab
|
|
Infosec, HW/SW RE, high speed digital, test equipment, network hardware, microscopy, FPGA/ASIC, @IOActive, KD2HKV, #SoOthersMayLive. Tweets are my own.
|
|
|
11.429
Tweetovi
|
404
Pratim
|
4.684
Osobe koje vas prate
|
| Tweetovi |
|
Andrew Zonenberg
@azonenberg
|
4 h |
|
Meetings and discussions w/ client prior to kickoff (i.e. scoping / do i want the project) aren't included. In-progress updates and feedback etc are mostly included in the relevant phase of the project.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4 h |
|
It was a fairly dense 6L board (space constrained application) with ~225 components, 9 ICs, and 1274 pads.
I'd say these percentages are pretty representative of my usual time spent on design of a board. Don't have any records handy for a project involving FW/prototyping.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4 h |
|
Total 49 hours from concept to gerber release, individual categories probably don't sum to 100% due to rounding.
This was a consulting project (hence why I had records for it) with deliverable being the gerbers, so there was no lab time or firmware dev involved.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4 h |
|
* 7 hrs (14%): footprint creation, floorplanning of layout, Sonnet simulations for stackup modeling and impedance matching
* 18.5 hrs (38%): layout
* 2.75 hrs (6%): layout review, silkscreen tweaks, last minute ECOs and bugfixes
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4 h |
|
Don't have stats for most of my projects. Here's one I do have records for:
* 4 hrs (8 %): initial skimming of datasheets and sch symbol creation
* 11 hrs (22 %): schematic entry
* 3.5 hrs (7 %): sourcing components, schematic review
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
16 h |
|
Awesome video from some of the best SAR pilots and aircrew I've had the pleasure of working with. twitter.com/NaswiSar/statu…
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
16 h |
|
Should be doable with the Tasker app on Android. No coding necessary, just create a few rules.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
19 h |
|
Is it bad that I knew what PHY you were using just from the screenshot?
Also oooh @ kintex version. All of my open HW/SW is 3-clause BSD license, although I admit to not being thrilled at the "binary" phrase.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
5. velj |
|
Also derp. I don't deal with non-reciprocal devices very often, it looks like I got the input/output numbering backwards. S21 is forward direction (port 1 to 2) - the output port number comes first.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
5. velj |
|
When talking about "frequency response" of a 2-port device, you're looking at S12/S21 vs frequency. Obviously with a >2 port device, or a directional one, it's important to specify the exact port pairing in question.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
5. velj |
|
Yeah the terminology is a little confusing at first but the concept isn't hard at all.
Insertion loss is another name for S12/S21 (although it's often expressed as a negative, so 3 dB means S12 = 0.5 since half the signal is lost), return loss is another name for S11/S22.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
5. velj |
|
You can generalize this to arbitrary N-port devices as well - S13 is signal passing from port 1 to 3, S44 is energy reflected from port 4, etc.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
5. velj |
|
S21 is signal passing through in the reverse direction (should equal S12 in a typical symmetric device made only of passives), S22 is signal reflected in the reverse direction.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
5. velj |
|
Sxy is effectively the amount of signal that goes from port X to Y.
So for a 2-port device, S11 = signal reflected off input, S12 = signal passing through. They should sum to 1 in a lossless device; any difference is energy dissipated in the device itself.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
5. velj |
|
The two overlap. Frequently.
jss.ecsdl.org/content/8/8/P4…
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4. velj |
|
Once you have a point where expected and actual behavior are measurably different, backtracking to find the root cause isn't usually that hard.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4. velj |
|
I often have a slightly different problem: everything I investigate looks to align with my view of how the system should work, and yet the overall behavior is wrong.
I typically spend most of my debug time trying to identify a divergence between actual and expected behavior.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4. velj |
|
Holy moley. FTDI messing with clones is one thing, but disabling *your own silicon* in legacy devices is massively worse. Nothing you do to secure your supply chain can defend against the chip vendor unilaterally nuking your product ex post facto.
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4. velj |
|
Thermal. So when they're playing rough you can say Neutron is getting Thermalized :D
|
||
|
|
||
|
Andrew Zonenberg
@azonenberg
|
4. velj |
|
I mean, secondary containment would be nice... And a proper overpack if it's being shipped.
|
||
|
|
||