Hi, original presenter here :) The beginning is FTs 101. The end gets more application-centric around OFDM and is why it feels 'unreasonably effective' to me. If it feels obvious, there's a couple of slides at the end that are food for thought jumping off points. And if that's obvious to you too, let's collab on building an open source LTE modem!
Lance -- I really like this comment because it is a compelling argument for something other than the viewpoint I hold. Obviously I am not fully convinced by it (yet?). But this is the kind of discussion that we had hoped for in response to this post. Thanks for posting it.
I was Chris's housemate at the time, the victim of the hours of 'sssshhhh sssshhhh shhhhh'. Interestingly, he rendered this mostly by drawing boxes in pov-ray -- I'm not sure what he used to make dimensioned drawings, but it was definitely not any of the modern CAD tools, and they were mostly for his reference.
But these days, I do highly recommend Onshape -- it breaks down a lot of the 'rules' that I thought I knew about CAD software. I started using it about two months ago; one of my clients uses it for real industrial design of some IoT hardware, so it is powerful enough to do real things. Before I started using Onshape, I thought that 1) all CAD software was a million billion gigabytes, and required stupidly powerful hardware for no readily apparent reason, and 2) had an annoying licensing model that requires you to jump through hoops to get access to the free tier. Well, neither of these are true with Onshape: I went from 'hmm, maybe I should try this for my personal projects' to 'constraining a sketch' in about 90 seconds ... on Linux ... in Firefox ... on my Shenzhen ThinkPad ... with an Intel GPU. I was blown away at how much it failed to suck.
Anyway, my suggestion on choosing software is: it probably doesn't all that much matter. What you want to learn is the CAD mindset, not the software. An experienced MechE once told me that if you are not careful, you can end up writing 'spaghetti CAD'. These tools these days give you a lot of features that are, in theory, more expressive, but in practice, can result in unmanufacturable parts or unmaintainable designs: be careful!
Oh, and a quick update on this -- I just got mail back from Chip at Wahoo. (Looks like my previous mail got caught in a spam filter.) They're looking to get a bunch of the attribution and source issues cleaned up shortly. I'll update the blog post later today, but I wanted to give HN first knowledge of this!
I was kind of surprised too. I have some conjectures about the internal politics from the output that I observed (super friendly, super helpful support team; development team knew it was an issue, and had orders from above?).
And yes, the ELEMNT is an ok cycling computer, but I think with a few bug fixes, it would work 'at least tolerably' for hiking (that is to say, at least as well as the Garmin Edge 510 did). The Edge 510 was not a great hiking computer, but for 'datalogging with a separate battery from my phone, and capable of speaking ANT+ to my heart rate monitor', it at least captured correct data...
Hi, HN! Author, here. Yeah, I was a little disappointed by the GPL and attribution issues, too. But also, I feel a little bad not having given them too much time to respond, or too much heads up that I was gonna write a piece about it. So if anyone has a way to reach out to them, I don't want to trash them too much, and I'd be really happy to update that blog post!
But also, the other side of this is that the attribution issue is, perhaps, only 50% of my thrust here -- the other 50% being that it's actually a really cool device inside, and it's neat to see how they managed to build a device that's (mostly) competitive with Garmin's rich feature set so quickly. And so that, I think, might be what would be even more interesting to HN, rather than just torching them. If they opened the platform up to tinkerers a little bit -- perhaps if they 1) unlocked the bootloader; 2) provided /system images; and 3) enabled a switch to give you access to adb -- then it would be a really really cool form factor of a toy for a lot of different uses.
Well, what you want and the physical realities of synthesis are different :-)
In the early days of compilers, of course, you were mostly writing C as a macro language for your system's assembly language. If you wanted your program to perform well, you'd have to write C that was, more or less, a translation of assembly that you'd constructed in your head first. If you wrote bizarre C, you'd either get incorrect results, or if you were lucky, you'd get correct but inefficient results.
But that's also Dan's point: Verilog isn't a "high level language". You don't write programs with it, you describe hardware with it. (In fact, that is why it is called a 'hardware description language'!) So if you try to write a program, instead of describing hardware, you'll get something that isn't really either.
I think I agree with at least some of what you say. I feel bad viewing content from small blogs without "paying" for it. My current best compromise is that I run uBlock Origin with an exemption for Google, and then I use Contributor.
It's still not a perfect solution. I give up a lot privacy that way, and in order to use Contributor, I have to give up some of the other uBlock features that I really like (in particular, element-based blocking).
I will note, though, that I don't feel in the slightest bad viewing Facebook or Twitter with ads blocked. Facebook and Twitter survive by network effects; I couldn't reasonably opt out of using their services even if I want to. Since I'm forced to use their services, then, I think it's reasonable that I do so on my own terms.
I started blocking ads because they dramatically slowed down my browsing experience. But I keep blocking ads because, fundamentally, I believe that advertisements are neurotoxins, and nobody has the right to poison me.
I've served a whole bunch of roles in my five years at my current employer, and I'd probably classify myself as being an "electrical engineer" for all of them. (No single experience is typical, but mine is probably representative of a lot of chip companies.)
When I joined the company, the very first role I was put in was on the core bringup team for a complex ASIC -- that is to say, the team responsible for screening chips, and working on issues that affect all of the individual functional blocks. I joined about a month or two before silicon was to come back. So, I spent the first six or eight months or so at the company in the lab; the first month was spent familiarizing myself with the tools and boards that we'd be using, and then once silicon came back, I spent a bunch of long nights and weekends in the lab getting chips to various teams, and, in general, solving whatever system-wide problems showed up. Bringup was a lot of work but it was also a really good view into "how the sausage was made", so to speak.
After bringup, I moved to an IP team [1], where my title was "ASIC Engineer". At the phase in the project that we were in, most of the RTL [2] had already been written, and owners for each sub-block had already been assigned. So my job was to do a bunch of the "checklist" items for netlist quality. For instance, I spent a while reviewing test coverage, and waiving coverage for things that couldn't possibly ever be reached. Or I reviewed tool output that did "clock domain crossing verification" -- basically, the tool pattern-matched on various chunks of code to make sure that they were safe. And yes, I spent some time staring at waveforms, trying to debug our testbench, or any kinds of such things.
I spent a while on another couple bringups, which I volunteered for this time. I enjoyed them, and then gave myself some time off for each to compensate myself for my nights and weekends.
At some point, someone decided that I was a better architect than engineer, which is probably for the better, because I was very slow at checklist items. So at some point I switched to an architect role, which meant that I was responsible for doing the definitions of sub-units, rather than implementing the hardware for them or implementing the testbenches for them. And, in general, the whole specification process is part of the architecture team's job. So, one day, when there was an output quality problem with our block -- it worked as specified, but given that it did some image processing, the image quality had some defect, so the specification was wrong -- I was tasked with spending a few weeks to reproduce it on hardware, find register settings that made it better or worse, and finally, understand what the defect was in the specification, and how to avoid it in the future.
Another task I had as an architect was to do the definition for a sub-unit from the ground up. This was a year or two of work. My primary output, interestingly, was not code, but instead a 100-or-so page Word document that specified how the block was to work, and what registers should program it; the consumers of that document would be the hardware team that implemented it, and the software team that would build the software. And, subsequently, I was tasked with implementing a model of that block in C, which could be checked against the RTL that the design team wrote. Near the end of that project, I wrote validation tests for it, and yes, I then spent some time staring at waveforms helping the design team to understand why their RTL implementation diverged from my C model. (They were, often, right. I am very lucky to work with an extremely skilled RTL team.)
These days, I'm doing more algorithmic research, trying to figure out what should be next for the block that I'm working on. In parallel, I sometimes get on phone calls with, for instance, image sensor vendors, understanding on an electrical level what's going on inside of their next sensors, and how they will be transmitting data back to our processor. So even though I work in the digital domain a lot of the time, having a firm grounding in 'is it possible to wire this to this' has gone a long way to help out, and being handy with a soldering iron has made my life a lot better on more than one occasion.
My experience spans some gamut, but not all of it. I don't work on place-and-route, and I don't work on board design (at work, at least). There are a lot of things that electrical engineers do :-)
Hope this helps. (I can answer questions, I suppose, if you like.)
[1] For some reason, the semiconductor industry calls functional blocks IPs -- yes, as in 'intellectual property'. This particular IP was not something that we licensed to anyone, or that we licensed from anyone; the only 'customer' of this IP was our own chip team.
[2] Again, another acronym whose expansion ("Register Transfer Level") is not super descriptive. Essentially, source code. Usually in Verilog, or an even higher level language. EEs seem to love Perl and Tcl, so most places I've worked have had Perl or Tcl preprocessors before their Verilog. Ugh.
I applaud the idea of helping people with depression, anxiety, mood disorders, and that cluster of symptoms and illnesses. We talk a lot about how it's prevalent, but we don't talk a lot about what to do about it.
That said, I don't agree with the advice of the original poster. Self-medicating, /especially/ when you're in the thick of depression, is dangerous; there really isn't a whole lot of data around with regards to either safety /or/ efficacy in patients with depression. It's important that you have a support system around you.
So the paragraph that's buried in the middle -- "discuss with whoever's relevant" -- I think is the crux of it. And beyond that, the most important thing is to begin. Talk to your primary care physician; if you don't trust them, talk to a close friend; find a referral to either a psychiatrist or a psychologist. There are forms of therapy these days that are grounded in evidence, and once you have a support system in place, you might well find that experimenting with pharmacological therapies that are outside the gamut of institutional medicine is something that you want to try.
But if you have pain every day, the most significant bit is that it doesn't have to be that way, and there are ways to treat it; and beyond that, there are tested ways, and it's probably worth going with those first, so that you have the highest probability of feeling better faster, with the lowest risk of feeling even worse or compounding your problems with other side effects.
It seems that this is getting downvoted, and I want to explain why I agree with the downvotes:
The policy on that web page has two egregious issues.
1) It does not have any provisions for SPAM. I regularly get e-mail SPAM that has CloudFlare-protected links. That abuse page does not even apply. Effectively, CloudFlare offers spammers a 'pink contract'.
2) CloudFlare has a reputation for ignoring abuse, and that page effectively says nothing about whether abuse will be stopped; that page only offers to transmit the personal information of someone who reports abuse off to an abuser. This is not a theoretical; this has happened in the past, and the personal information of someone who reported a site that contained child pornography was then posted all over the net for its users to begin harassment with.
So if you find something abusive or malicious, your best bet really is not to report it. CloudFlare won't act, other than to put you at risk.
Interesting. I've seen some other work done on gradient-aware demosaic using directional masks, and the devil appears to be in the details: it can reconstruct a lot of sharpness when images are aligned with masks, but it also tends to take images that aren't aligned with the masks and "forceably align" them -- e.g., circles get turned into polygons, etcetera.
Perhaps the additional green resolution on X-Trans sensors can help avoid this some. But I'd be interested to see how well this ends up doing on trickier images...
I think there is a fair bit of "how to lie with graphs" here going on. For instance, the 'housing construction boom' very carefully does not show any context before 2014, and although it rockets up from the bottom left of the graph to the top right, that's only a delta of 25%, because the bottom is not zero. It also doesn't show how many housing units ever make it /out/ of the pipeline -- a perennial issue in San Francisco.
It also seems to declare that employment is the only source of housing occupancy. This is less true if you consider, for instance, real estate speculators (and with China's economy as well as it is and is expected to be, I don't foresee that slowing down), and also if you consider the new short-term rental market.
So, maybe the housing bubble will collapse. But I'm not convinced that either of those forces are as powerful as the author claims, and the author doesn't really give any text considering and dismissing other known forces, so you can consider me unconvinced by this article alone.
I think I'd take the opposite tack, by the way. I get about a zillion job recruiter e-mails, and the vast majority are mail merge. It's irritating, but not disqualifying, for the recruiter.
If we put up with it that direction, why not put up with bulk solicitation the other way?
