11 ms·

Ask HN: What does an electrical engineer actually do at work?

• seanxh 10y ago
  I was a RF engineer two years ago, and now I am doing software development. I think I kind of resonate with many of the above comments. While I was doing RF design, I spend a lot of time on CAD tools(I agree many of them are overpriced), after I got my design from the fabs or manufactures, I spend most of my time on lab to validate/optimize my designs, due to that fact that some unforeseeable fab/manufacture processes variation that are not captured by the CAD tools. thing I feel very gratifying was if you utilize the right framework/methods that are reason upon physics, the performance of the design most likely will mach to what you predicted, and that allow you to design something reach/surpass some industry benchmarks
• nicholas73 10y ago
  Like software engineers, there are many different jobs for electrical engineers. Some are more design and simulation, some are testbench, some are more theory and down to the physics level. Others are support and sales. Larger companies might have more defined roles, whereas others do a bit of each.
  • nickff 10y ago
    I am an embedded software engineer at a company that does handheld electronics, and agree that both jobs are along spectrums. I spend a lot of time with the hardware engineers, and we all spend time testing things on our benches with signal generators and oscilloscopes as well as using computer tools to develop (software in my case and hardware in theirs). If you want to work with some hardware, or on a test bench with lab equipment, you can always move over to embedded, as there are many jobs available; some even say it's less competitive.
    • vonmoltke 10y ago
      > If you want to work with some hardware, or on a test bench with lab equipment, you can always move over to embedded, as there are many jobs available; some even say it's less competitive. My experience has been that the embedded jobs are controlled by companies that are very picky about experience. I am an EE that has been out of the game (professionally) for four years. It's like pulling teeth to get anybody outside the Valley to talk to me about an embedded job.
• deleted 10y ago
  [deleted]
• iprashantsharma 10y ago
  Sleeping all night in night shift.
  • ramchip 10y ago
    This made a lot more sense after I saw your profile: > Working as shift engineer in power plant
    • bbcbasic 10y ago
      Wow Homer Simpson's job does exist.
  • throwaway7645 10y ago
    What subfield are u in?
• Gracana 10y ago
  I do a lot of drawing and sometimes I build panels for prototype machines, but mostly I spec out components, talk to vendors, and do paperwork. FWIW, I work at a small company that makes industrial meat processing and packaging equipment.
• FreedomToCreate 10y ago
  Typical day as an Electrical engineer at a autonomous vehicles company. - Work on Schematics and layout for various different boards (usually only get time for one each day). - Go to meetings with multiple different engineering teams to make sure that cross-functional requirements are being met (usually the software and mechanical guys making demands of what they need which just means what they want to make their life easier by making the EE's suffer). - troubleshoot issues on the already built hardware and add the fixes to upcoming revisions. - Argue with purchasing department about the reason I need to get a certain type of testing equipment. -A lot of component research and validation and meetings with vendors to determine if that components is right one. and this is just the pure hardware tasks. There is always potential to have to deal with firmware issues as well. I may spent half my day at my desk, at least an hour or two in a lab and the rest is for meetings.
  • cushychicken 10y ago
    God, meetings. So many meetings. Why? Why?!
    • mac01021 10y ago
      A significant fraction of designing any complex system consists of getting the people who design different parts to agree on the interface between those parts.
      • cushychicken 10y ago
        That was a very high minded response to an attempt at commiserating.
        • mac01021 10y ago
          Yeah. Sorry... I do think, though, that it's possible for an organization to structure it's meetings so that they're a useful and productive part of the job, and not a thing to be dreaded in the least. I've seen this done with varying degrees of success/failure.
• cushychicken 10y ago
  I'm an electrical engineer by trade, and do embedded systems design for a living. I do a lot of board placement and layout planning, plus writing test plans for verifying that what we build is good at scale. I also do a reasonable amount of debug, as that just comes with the territory. I'd say it's about 70% software time for planning and CAD work, 30% hands-on lab time. Note that it's not uniform - I might be in the lab for two months straight, then not go in for six. Generally, "embedded systems" implies some programming as well, but I do little to none of that. I think I'm the exception rather than the rule in that sense. If you wanna get simplistic about it, I spend half my time playing "connect the dots" in overpriced software, and the other half arguing with people about where I decided to put the lines. On the one hand, there's a lot more standardization in the components I string together to make a working system. On the other hand, it can be just as hard to track down the source of a problem. You happen to have caught me at a point where I'm stuck trying to figure out the proper answer to a mysterious boot issue, and let me tell you what - it's about as frustrating as frustrating gets. You have to push yourself to think hard about what you haven't done, even when you've done everything by the book. ("The book" in this context is documentation, design guides, processor reference manuals - things that tell you what to do to get your system working.) Point I'm trying to illustrate - don't think that hardware is any easier than software. It's very, very gratifying to see something real, that you can hold in your hands, work. Doubly so when people actually use your stuff and tell you how much they love it. (Yay, consumer electronics!)
  • posterboy 10y ago
    > embedded systems > there's a lot more standardization in the components I string together Embedded Systems is just one discipline in EE. How many people design something like an lm317 deployed on embedded devices? EE tries to teach that, too, until it's all to complex not to specialize on one branch. Another discipline I was offered to specialize in was Motor Appliances and Power Amplifiers. Those don't have much to do with CS, except maybe for digital control circuits.
    • cushychicken 10y ago
      When I said "a lot more standardization", I had things like DRAM or PCIe in mind, which are spec'd by their relevant consortiums (JEDEC and PCI-SIG, respectively). As in, there's clear limits on the way to make it work, and if you meet those limits, it's fine. I do a lot of POL planning for purposes of thermal management, so yeah. I'm definitely not that specialized.
• deleted 10y ago
  [deleted]
• lutusp 10y ago
  Somewhat related to the topic, but as time passes, electrical engineering becomes more and more about choosing which software remedy to apply to what once were pure hardware solutions. And when that is not the case, when hardware is going to be built, the decisions about circuitry and methods are increasingly determined in advance with software. Here's an example -- in my career as an electrical engineer (30 years ago) I designed any number of phase locked loops in circuitry. Now I design them with a keyboard and a computer monitor, [using methods like this](http://arachnoid.com/phase_locked_loop/ http://arachnoid.com/phase_locked_loop/). The new PLLs work much, much better than the hardware-based ones, as well as requiring far less guesswork and effort. So my advice is not to abandon a software-based approach, it increases your employability compared to someone who only knows hardware.
• jwise0 10y ago
  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.
• jimmyswimmy 10y ago
  There's a lot of overlap between the two, or there can be; there is as much variation in what one does in EE as you can imagine, from supervising operations to semiconductor design, etc. A design engineer tends to have a batch-oriented life. Typical workflow might be like CAD -> sim -> layout -> debug -> small scale production -> testing -> handoff to production. Of course all of this is as a member of a larger team. Somewhere in there you'll either work on software or firmware or both. I spend about half my time in the lab or field, the rest in my office or meetings. One bad side of EE is that you can break stuff much differently from software. When the magic smoke comes out, there's no 'svn revert' - you have to figure out what you broke and fix it before you can move on. This always happens when you're in a rush and causes plenty of unplanned late nights. And for additional fun, it's not uncommon for problems to crop up where you just have no way to get at the underlying issue. Datasheets don't have all the info you need, and you can't always figure it out. Sometimes you hit a wall and just have to start over. I used an Atmel processor which had a weird bug in its I2C slave module which prevented it from working properly. Best solution ended up being to go to a different processor, which was incredibly painful. It's really awesome to be able to hold on to a thing that you built and make it go. Seeing your thing go out in the field and work is very rewarding.
• joezydeco 10y ago
  How are your troubleshooting skills? I'd say my EEs spend 50% in design and 50% in debugging customer problems when a board fails in manufacturing or fails in the field. The answers can be easy (say, a resistor is out of tolerance or the wrong oscillator was placed on the board), or they can be really tough (a transient is killing a FET and locking things up).
• chclau 10y ago
  I have been working for about 20 years. At the beginning of my career I had a choice of being in the ASIC side or board design and chose for board design because I thought (rightfully so, I learned later), that that was a more "physical" task. So I worked for about 10 years in board design and my typical work day was not typical at all. Some of the time researching parts. Some making schematics of circuits. Some making PCB layout. Some on debug and integration. Some time mastering scope and logic analyzer use. Some time talking my way thru all the people I have to receive products from/deliver to: SW engineers, FPGA engineers, mechanical engineers... I made analog designs, digital designs, power supply designs... Then I started feeling more and more that I designed less and spent more time learning what the chip designers did, as chips incorporated more and more functions that once I did by myself. So at the end I switched to FPGA design and today my typical workday is coding, debugging, simulating... 95% of the time on my computer. A good friend of mine coined a good phrase: FPGA engineers are SW engineers that disguise themselves as HW engineers. A good joke. But every joke has a bit of truth in it.
  • pepijndevos 10y ago
    It seems like board design is a much less monotonous and more practical task that you seemed to enjoy. What made you change to FPGA? Do you feel that the bulk of what used to be board design is now happening inside silicon? I started my career as a software developer, but got bored by web development that seems to make up 90% of the industry, so I started to study EE because I really enjoy playing prototyping fun projects. I just ordered a PCB for one of my projects. But when I read your, and other comments, it seems that just as the things I enjoy about programming are not what a typical job is about, the things I enjoy about EE are not what typical EE jobs are about. I'm not sure where that leaves me...
    • chclau 10y ago
      Yeps, as I said, I felt that I was doing less design and more system integration or "lego building". Besides, I had been doing that for many years and I thought a change was due. From my description it may seem that FPGA is monotonous... that was not my intention at all. For me, FPGA design is much more challenging and fun than board design never was. The downside of FPGA design is that human contact is much more limited. You cannot really receive answers for your questions, because most of these things are subjective. You have to make your own way and make your own experience. Experience, after all, is the comb you get when you have no more hair ^^
• antoineMoPa 10y ago
  This year, I left my electrical engineering (EE) studies for software engineering. I had a lot of personal experience with coding before going in EE and I wondered if some hardware would make my life more interesting. After 1.25 years, I realized that I was spending all my life in a lab with no windows, to the smell of toxic soldering fumes, fighting against extremely annoying software (altium & other proprietary overpriced pieces of technical debt). Also, I realized whatever I created needed a lot of work for an unsatisfying outcome (A sound amplifier is less satisfying than some webgl stuff that moves [but it requires a lot more work]). The nice feeling of being powerful when writing software & the instant compiler/interpreter feedback is what I missed the most. At least, when you are a software engineer, you have more odds of finding a nice workplace, with windows and software you can choose. The part I miss from electrical engineering is the physics part (But we were only skimming this part anyway). Finally, circuits are a thousand times less satisfying to me than code. I've seen people for whom it was the opposite. They did not get programming at all, but they were designing circuits at the speed of light with an intuition that I did not have.
  • madengr 10y ago
    I like Altium and solder fumes.
    • antoineMoPa 10y ago
      I think the people who coded Altium liked solder fumes... A bit too much.
  • fake-name 10y ago
    If you think Altium is a "overpriced piece of technical debt", HOLY SHIT you should try anything it competes with. It's sooo much nicer then anything else out there in the EDA market. At my work they use Proteus, and it's horrible. Also, solder fumes aren't toxic!
    • deleted 10y ago
      [deleted]
• turnip1979 10y ago
  I'm a SW guy .. been mulling getting a job in hw at some point. I watch a lot of YouTube and do hw projects in my spare time. Is there something like sw boot camps for developing hw skills? I'm almost considering getting an ee bachelors or masters as a part time student.
  • yoloswagins 10y ago
    I got this in my inbox a few days. An Oakland, CA coworking space has an "Engineering Accelerator"[1] that they're doing on nights and weekends to help people do hw engineering. Not sure if it's 100% what you're looking for. [1] http://www.engineeraccelerator.com/ http://www.engineeraccelerator.com/
  • seanxh 10y ago
    depend on what hw skill that you try to acquire, things like fabrication/device level design, antenna RF design/measurement etc, you have to go to university, because many of these topic require some very expensive equipments to gain the hand on exp, but not necessary truth for like something like digital circuit design
  • fake-name 10y ago
    Not really, because hardware is not amenable to boot-camp style things. Basically, hardware is way /way/ harder then software. Imagine software where each compile took multiple weeks, and cost lots of money (hundreds of dollars for the simplest of projects, to tens or even hundreds of thousands for really complex things). Changing the layout or design almost always involves a complete board respin. There is no easy getting started (maybe arduino stuff, but there is SO MUCH horrible misinformation in the arduino communities), because the minimum functional system is a complete system. You basically have to get everything right the first time in hardware, or it won't work. The learning curve is more of a learning wall.
    • ZenoArrow 10y ago
      You're right that you couldn't do a 'boot camp' style short course and land an EE job, but it's not a hard as you make out if you set your sights lower. To give one example, let's say you want to start out by making guitar pedals. There's a healthy market for boutique guitar pedals, plenty of existing designs available online that you can modify when starting out, and when you're ready to start making designs from scratch you're looking at stuff you can understand with entry level electronics knowledge. Furthermore, there's room to grow as your knowledge improves (can get into DSPs, for example).
• mighty_atomic_c 10y ago
  I'm just a beginner. I write in hardware description languages for test benches, simulations, checkers and constrained random tests. I've also done PCB layout (hobbyist to RF microstrip), GUI programming (I don't enjoy that), and using IC design software for.simulation and layout. I also spend a lot of time working with hardware. The debugging process is very challenging, and certain aspects of it can be tedious. Overall I find it to be satisfying, challging work. I also get to apply my Linux knowledge most of the time when working on things, which is great.
  • deleted 10y ago
    [deleted]
• clw8 10y ago
  Just a note that if you go into automotive, you will spend 90% of your time in Matlab/Simulink. Pretty fun IMO.
  • lj3 10y ago
    Can you elaborate on that? What do you use Matlab/Simulink for in the automotive industry?
    • MarkMMullin 10y ago
      Enable wireless hacking gateways for cars ?
    • seltzered_ 10y ago
      Think it depends on the specific job in the industry, but think the author was referring internal combustion engine control systems / ECU development.
• patchorang 10y ago
  There are a bunch of EEs in here complaining about the software they have to use. I took a few EE courses in school and the only thing I remember is having to use horrible software. Why hasn't someone made good software for EEs to use? And if the have, why do no EEs use it?
  • Cyph0n 10y ago
    In my opinion, 1) Barrier to entry is way too high compared to other software niches. Good luck designing a cycle-accurate CPU simulator, or creating a reliable and robust analog circuit simulator that competes with offerings from EDA giants like Cadence and Synopsys. 2) The adoption process. I learn tool X in school, I start a company that uses tool X, I teach my hires tool X, etc. Once tool X becomes a central part of the design process, it's almost impossible to get rid of it.
  • madengr 10y ago
    There is lots of good software for EE, it just costs $$.
    • dwd 10y ago
      I worked on maintaining this software quite a few years back. It was quite innovative when first released. http://solutionselectricalsoftware.com/ http://solutionselectricalsoftware.com/
  • cushychicken 10y ago
    Most of my professional experience has been with Orcad, and the folks who write that tend to write it for people who pay good money for it. Generally, those people tend to be in the semiconductor industry. As a result, there are a ton of features in the Cadence suite that are highly optimized for that industry. That doesn't make them easy for laymen to use. It just makes it easier for the people who are keeping Cadence in business. That's my read on it, anyway. Anyone who figures out a way to make EE CAD software better and easier to use stands to do well for themselves.
  • yessql 10y ago
• madengr 10y ago
  Been doing RF/Microwave/Antenna design for 20 years. Fortunately I have stayed hands-on with hardware development. Start with simulation, then PCB layout, followed by lots of measurements in the lab. Sometimes meetings for customer requirements, writing technical parts of proposals, getting capital equipment purchased, etc.
  • sunstone 10y ago
    Hey what's with that 'path loss' equation? Looks sketchy to me.
    • rfdave 10y ago
      Looks sketchy in what way?
    • madengr 10y ago
      I'd say it is sketchy as people say path loss increases with frequency; well it doesn't if you have the same physical antenna apertures (think parabolic dish). Though the formula is called a loss since it's used that way from a circuit perspective, and you treat the antenna gains as not related to aperture, so loss does then increase with frequency.
      • sunstone 10y ago
        Yes that frequency term is precisely the sketchy bit. Because of that the equation doesn't conserve energy which is normally considered a bad sign. On the other hand to do it properly you have throw out the 'reciprocity' of sending and receiving antennas. They are not really the same at all.
• mankash666 10y ago
  There's a lot in EE that's nothing to do with hardware per se. Like digital communications and signal processing. EEs also study computer architecture and OS internals in detail, depending on one's emphasis.
• mng2 10y ago
  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.
• mattbillenstein 10y ago
  I've lived two careers -- one in semiconductors doing ASIC physical design (highly aided by writing software I might add), and another in startups doing backend database, systems, the gamut of server-side programming. The hardware job seemed more like "real" engineering -- it was more rigorous, there was less room for error or experimenting. But, I got bored with it eventually -- it was the same thing, just a bigger chip, more people working on it, and a longer design cycle from one thing to the next. Also, it seemed like upward mobility was hard -- I didn't want to be a middle manager anyway, and it felt hard to have a large influence in a company with thousands of engineers. In the end, I felt I didn't want to die at that desk, so I switched into working for internet startups. The software end of things has felt more creative and has definitely been more fun. It's more laid-back, people are generally a little more interesting and well-rounded, and you typically work at a place 2-4 years and then move onto something new -- which I like. You're generally working in smaller teams and you get to work on a variety of different pieces of the system if that's what you like to do. All in all, they were both rewarding experiences with good compensation -- the software thing might end up being more lucrative in the end and I just sorta have more fun doing it. At the time I made the switch, I took a pretty large pay cut going from a mid-level hardware engineer to a junior software engineer, but it's one of the best decisions I ever made looking back.
• loydb 10y ago
  This video is an amazing time lapse of the creation of a Eurorack synth module. It shows you what you'll spend a lot of time doing in a smaller org (smaller, as in, you do everything...). https://www.youtube.com/watch?v=1pawXfoTg1k https://www.youtube.com/watch?v=1pawXfoTg1k
  • catbird 10y ago
    Wow that was mesmerizing. I'm surprised that all of the traces were drawn manually. I had always assumed that modern design software would do all of that tedious stuff for you. The creator of that video was answering questions on reddit, and amazingly the whole design and build process took less than a week. https://www.reddit.com/r/ArtisanVideos/comments/50tqgx/the_design_and_build_process_of_a_synthesizer/ https://www.reddit.com/r/ArtisanVideos/comments/50tqgx/the_d...
• johan_larson 10y ago
  So EE today is almost entirely about digital circuitry?
  • Symbiote 10y ago
    I'd guess others are less likely to read HN. I know people that design electric motors, microphones for hearing aids, overhead electrification for railways, railway signalling systems and power distribution in very large buildings. However, I don't know what a typical day would be for any of them.
• MarkMMullin 10y ago
  TL;DR; I'm an impoverished small scale serial arsonist of expensive components remembering that software means never having to leave physical proof of your boo boos, most of the time. OK, I'm actually a software engineer back into hardware engineering after 20 some years cause I need to build custom cameras for machine vision projects. Major recovered sills are CAD (Eagle), more geometry (layout), exercising credit cards due to I'm still bad a spice, lazily using standard cap and resistor values even when they're wrong for >this< circuit, and excessive shining about stray capacitance - since I need to work at 3.3V and I'm in my 50's, I can't see the parts so well and my motor skills aren't what they once were, so thats even more expensive crap I need (rework station, reflow oven)
  • fest 10y ago
    Having just deployed a machine vision system (using GigE machine vision cameras): why exactly are you building custom cameras? If you don't mind/are allowed to share this information, of course.
    • MarkMMullin 10y ago
      I do hardware engineering because I started my career when it and heavy math were required to get into software courses (and you first computer came as a bag of parts) - the camera itself is spherical build, wedging 26 cameras, 4 beagleboneblacks, a netswitch,IMUs,GPS, and batteries for the souls sucking multiamp drain into a 5" ball (OK, I gave up on the batteries for the moment :-) My primary "actual engineering" has been the control distribution circuits across 8 paired I2C/SPI busses at 4-8MHz and trying not to corrupt the bits in the process (a little bit of whining on Wolfram Alpha with the theoreticals, a lot of being very neat and tidy with the layout - the power distro itself with its various internal taps because power is analog and analog is proof that God hates us, the various passives and actives involved in everybody actually powering up in some more or less controlled fashion, etc - technically for the camera I use the Arducam FPGA against OV2640's and OV5640s, cause that gives me a nice (slower) pure I2C/SPI interface - the real goal is to feed the tensorflow stuff in the cloud, the camera geometry, imu, and gps provide enough correlations for the system to lock onto pretty easily, i.e. stationary spherical image reconstruction and spatial analysis is a no brainer (relatively speaking :-) ), and the back end system is now getting more betterer at using the IMU data stream as a primary assist when the camera is in motion (oh, and then there was the pesky little issue of delivering the GPS clock to 4 linux based computers to establish a common timebase cause we all know that linux is an awesome RTOS)
• androng 10y ago
  I am a board level design engineer and the work is similar in many ways to software. It is very numerical and requires attention to detail. I spend 25% of the time talking about requirements to other engineers, 50% comparing components to use with datasheets, 12% in Altium Designer and 12% buying components and PCBs. Huge pain #1: the unbelievably slow process of manufacturing PCBs. Imagine that you were back in the old days of computing where you had to use punch cards with machine code and you had to give your stack of punch cards (your "program”) to the punch card operator. He would run it overnight and you would get your results the next day. If your program failed, then you have to meticulously comb through it and debug in your head. This is modern-day PCBs. Holes in a board that take forever to make. Then you have to pay $80 shipping to get them next day or you can pay your engineers to sit around doing nothing. And the PCB might not even work. Learning feedback loop is very slow. If you want to do anything remotely interesting like via-in-pad or four-layer boards, first you have to wait at least 24 hours for a custom quote. Half of PCB vendors don’t just give you the formula to make your own quote. Then you have to pay either $1000 and 2 days or $200 and 2 weeks to have 5 copies of your design. Huge pain #2: reinventing the wheel. When I open a datasheet, I have to read about the device. The pins, the maximum ratings, the application note “gotchas” like “don’t leave this pin floating or else the chip will be unpredictable!” Then I have to make the schematic symbol and footprint by hand. That means manually entering IPC package dimensions into Altium like a braindead zombie. Every package is slightly different. I cannot tell you how many Texas Instruments DC-DC converters I have hooked up. I have no idea why device manufacturers don't just hire someone full-time to make open-source 2D and 3D footprints for the top six CAD tools. SnapEDA and Altium Vault are trying to do this, but the footprints are flawed and they are outright missing a lot of parts. I cannot tolerate mistakes when each board costs hundreds of dollars. The device manufacturers already make footprints to test their parts. Why don’t they share them?? Huge pain #3: High barrier to entry. Very expensive software. In software engineering, professional tools like git, Visual Studio, Eclipse are all free. You can pull code at home from Git and start contributing immediately. The only barrier to entry is the time you need to understand the existing codebase. Even in firmware you can download Code Composer Studio or PSoC Creator for free. In board design, you need to pay $300 for EAGLE or $5000+500/year for Altium if you’re serious. Sometimes OrCAD goes on sale for $300. Lets say you want to simulate Bitcoin mining ICs frying themselves in their own heat. Or maybe you want to know the radiation pattern of your antenna. You can pay another four digit price tag for simulation software like CST or just copy a previous design like a zombie. Upverter is trying to solve the upfront cost problem with their $125/month SaaS subscription pricing, but I tried their editor 3 months ago and it was 15 FPS with the example board. Not cool. KiCAD is an open source alternative to Altium but as far as I know it is nowhere near comparable. Huge pain #4: ordering components and PCBs. In my last project I had to order components from China. Ordering from China is not very easy with the language barrier, bad spec sheets, time difference. Alibaba is the place to go for ordering from China, but all the prices are “Contact us”, which means you have to give all your information blah blah blah until you get an email with the price and then pay with wire transfer. Sometimes you get lucky and you can find what you want on AliExpress and pay with credit card. But the tradeoff to all of this is that if I do it correctly, I can hold something in my hand and give the software engineers a new API to play with. The APIs all stem from the hardware. The work is often more fundamental with equations and physics rather than purposeless corner cases I had to consider when I was in programming. And hardware often has the chance to be featured on the box of a product rather than software which is all just assumed to work. It feels more meaningful.
• max_ 10y ago
  Yann LeCunn is in fact an Electrical Engineer!
• johan_larson 10y ago
  Is it math-heavy in practice? Software engineers usually have to take quite a few courses in calculus, linear algebra, and stats. But that stuff very rarely comes up in practice, at least in most subfields.
  • phyllostachys 10y ago
    If you're doing signals stuff, it can get mathy (differential equations or Fourier analysis type stuff).