reply to mike_m: Class E power supplies and RF power amplifiers are also similar to CRT-television horizontal-output stages with the retrace taking 50% of the time instead of the usual 10%.
I have spent my career so far in analog, digital (including VHDL), and embedded firmware all at once on the same projects. Recent projects added computational electromagnetics to the mix. I could discuss details with all my colleagues, which details some of my colleagues could not discuss with each other. I also have RF experience through amateur radio construction projects.
I am now retired from a plant closing, and now have the time to pursue my projects in open-source form.
Analog Devices used to publish a journal, "Analog Dialogue". I remember particularly their article reporting when their newly-hired first senior RF engineers started conversing with their senior high-speed analog-chip design engineers. The two groups were from very different worlds: 50-ohm environment on the bench versus whatever-is-optimal on chip; minimize use of expensive discrete transistors versus transistors are the cheapest part of the chip.
Digital on a chip is part of the analog, not the other way around. As speeds go up, we all know that analog knowledge is key for a succesful design.
Agreed. I thought that's what I had said.
Further, molding an engineer to specific skills is limited: One should always take into account what the best qualities of a person are.
Yes, agreed again. When you start out at your first job, you and the company should figure out soon enough what you do best, and the job molds around you that way. But at the same time, everything changes fast enough that whatever you do, you have to keep up, so you are also being molded by the job.
That's why this excessive pigeon-holing doesn't make a lot of sense.
I guess I've been blessed to work for companies and for customers who understand this. If you're given a task on some brand new technologies, the customer should know that you need to figure it out before using the technologies. For instance in my case, I introduced Interet Protocols into our products as soon as the customer allowed, and was only able to do this rapidly because, as an engineer, I knew I needed to learn this stuff inside out. As well as all the other protocols we're supporting. Even introduced protocols, like ATM, that we ended up not using, as part of an exploration of update options. The customer supported this type of work, because we explained what we needed to achieve.
If we need to process signals, I write the algorithms, code them up, and test them. Then send them out for peer review. These are all skills EEs should have. Initially taught at school, but of course upgraded all the time.
Over time, what I do has changed quite a lot. Yet I don't consider myself to be a different type of EE. And I see the others around me doing the same sort of thing.
Sorry, but I fully disagree with your opinion: Digital on a chip is part of the analog, not the other way around. As speeds go up, we all know that analog knowledge is key for a succesful design. Further, molding an engineer to specific skills is limited: One should always take into account what the best qualities of a person are. Electronics alone is soooo enormous broad in the things you can do. Another thing is that I find it pretty easy just to say that an engineer simply has to update his skills. You are right about that. A good engineer wants that, no doubt, but the company must give her/him the space and time to do so. Unfortunately -as explained in this great article- this is not always the case....
That was at my past job just a few years ago where the PS engineers were the absolute worst at listening to the RF group and going blindly on their own not having any consideration for other groups.
At my present job they have started to listen and now take suggestions from the RF group seriously which makes my life half easier
Unfortunately; I still have to deal with other companies poorly designed 3rd party devices in particular LED lighting on aircraft with very noisy power converters many of which are making my job appear more and more like customer support as opposed to RF design.
Interesting comment. I have to say though, that as a former power supply engineer I am surprised that the power supply engineers you work with would contribute to the EMI problem. For one thing, if it is connected to the AC line their power supply needs to comply with FCC conducted and radiated emissions specifications. For another, EMI is a huge problem within power supplies themselves, trying to prevent the switching frequency or its harmonics from leaking through to the output or interfering with other systems in the box is a continual struggle. Most of the power supply engineers I have known have been very knowledgeable in the areas of shielding, grounding, filtering, and cross talk. It's also interesting that many of the resonant switching power supplies are similar to classes of RF switching amplifiers, the Class E DC/DC converter or RF power amplifier comes to mind.
@mike_m Every company I worked at skimped on their dedicated RF engineers and most were managed by software and digital groups
Like the software superman that headed one of my project teams and told me that since the system clock was only 20 MHz we did not have to worry about FCC Part 15 because they were only concerned about radiated emissions above 30 MHz.
that they need to put a shields over their Clock oscillators,
Or let the optical receiver designer put a shield over the low-level analog portions of the PCB because of the TTL-carrying ribbon cable a quarter inch away. Management said "No", so I designed without the shield, then proved to management that "their" design (not mine; I wanted the shield) did not work. Did a PCB respin with a shield. After that management listened when I said I needed to shield something.
Being the only analog designer in the company gets you flack from the PCB layout guys "Not another one of these! Why can't you design like everybody else?"
Lately I spend 75 % of my time not designing RF products but instead resolving RFI/EMI issues
A digital group "upgraded" a shelf-mounted DS3 card by adding a feature that snaked some RG174 cables out through the cracks between the card front faceplates. The cable is shielded, so no problems, right? But connecting the shield to the digital ground plane turns that shield into a very effective radiator. I managed to resolve all their problems, passed the emissions testing, then the marketing guy had the gall to ask me how they were going to explain to the customers to whom they had already (and illegally) sold the product why they had to do so many mechanical modifications?.
I answered him very succinctly - "That's YOUR problem."
It is not the end of the world for good Analog IC Designers...regardless of the number of gray hairs on your head.
Scenario #1: You're bright, have done dozens of designs and know enough to have thought about what the world needs next...or you know a customer who has a specific analog IC need that is not being addressed. Then turn your design idea into your own IC. If you can carry an idea thru to a GDS II, we can assist you with the rest. Start your own virtual semiconductor company... we'll manage all your back end...wafer fab, assembly and test, shipping to the customer, invoicing, etc. Sometimes we can even provide assistance with the marketing and sales side for you. If you can't get to a GDS II, maybe our Analog Engineers can help.
Scenario #2: We are always looking to expand our network of Analog IC Design Consultants. Why would you want to do that? Because we treat our designers like the valuable resources they are. They get 10%age of the profits of the chips they design for us for the life of the product...an annuity, so-to-speak.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.