@zeeglen: So why was he looking into transistor data sheets to try to find a match to the obscure code printed on the package when the circuit itself indicated this was a passive device, probably a R/C/L filter network?
@David: I'm just so glad I came form an era where you had to know about the guts of the equipment and actually pulled it apart and fixed it instead of just swapping it out and sending the old one off for repair....
I agree -- I'd go further -- I'm glad I came from the era when microprocessors were just coming online and memory was so small and expensive -- so you had to learn to create really efficient code that had th esmallest possible memory footprint and used the fewest number of clock cycles -- it gave you a real appreciation for what was going on "under the hood"...
... and you tell the young engineers today and they don;t believe you (mutter mutter mutter mutter...)
Even after being a member of the site for a while now, this is first time I have ever decided to leave a comment!
Welcome! I hope you become an active particpant. I can only speak for myself, but I really appreciate it when someone actually responds to something I have said. I find it quite disheartening when I put several hours into a blog and it seems to fall on deaf ears.
Thanks for adding to the converstation. And to everyone else who only reads these blogs, please add to the vibrancy of the forums.
I first off want to say hello to the community of EE Times! Even after being a member of the site for a while now, this is first time I have ever decided to leave a comment! But, first time for everything, right?
"This friend is a particularly bright guy with an MSEE, but he left engineering and went to "the Dark Side" (project management) about 30 years ago."
"How about someone being ignorant of something you would absolutely have assumed that person knew?"
Not going to lie, this one of my biggest fears once I retire as a student. This is also part of the reason why I decided to continue to my life on the "light side" as graduate student. I understand the importance, but it seems as though going into management is pretty lousy if it means potentially forgetting a lot of the technical (and more interesting) concepts, which even includes Ohm's Law for some people. Once, my dad's friend who used to work for TI asked me for assistance with an embedded project using a MCU. From working with me, he realized how lousy his C programming became since going into management. That's SUPER scary, I think. At this point in my life, I can hardly imagine not programming for more than a day, let alone long enough to forget anything.
"How about you? Have there been any occasions when you discovered that you'd forgotten some fundamental concept?"
As graduate student, I think I may have an advantage here, especially since I often have to review a lot basic concepts in preparation for more advance topics. Still, I remember the professor I had for Introduction to Machine Learning being fairly surprised at me (and the most of the class, if I may add) for stumbling with basic stastical and probability concepts (e.g. correlation, covariance, expectation, etc.).
@betajet: Your story about the student's commented code made my night, by the way.
"In the high and far-off times", students learned to program with punched cards and paper listings, and if a student couldn't get a program to work he or she brought the listing to a "consultant" -- generally a near-mininum-wage CS student -- for help. My favorite story is that one day a student's program didn't produce any output at all. The consultant looked at the code, which was a total mess, but he couldn't figure out why it produced nothing instead of a bunch of error messages. Finally he saw that the student had commented out the entire program, which is why it didn't produce anything. When he pointed this out, the hapless student said: "But that's the only way I could get it to compile!"
@david But I am constantly surprised at how much my fellow Telecomms techies DON'T know about electronics
Just a few days ago a lead tech came to me with a problem - help identify a device in a SOT143 package. He had already searched out some potential transistor candidates. Then emailed me a photo of the PCB etch.
Two of the 4 pins connected to the ground plane, one pin was capacitor coupled to an IC, the forth pin went to a mini coaxial cable connetor. There were four of these devices in all, four 50ohm coax cables connected the mini coax connectors to an OC48 (2488.32 Mb/s) optical receiver; two for differential data, two for differential clock, both ends AC coupled through a capacitor.
No bias-TEE anywhere. So why was he looking into transistor data sheets to try to find a match to the obscure code printed on the package when the circuit itself indicated this was a passive device, probably a R/C/L filter network?
I have always been into everything...as my handle says on my blogs, I am a "Jack of all trades" and - I freely admit - a master of none. But I am constantly surprised at how much my fellow Telecomms techies DON'T know about electronics - which is after all what drives all the gear that we use.
Recently my company gave us all a raise in pay (yes it does happen!) but we were required to have a diploma level qualification to get the new pay scale. If we didn't have one (and mine were so old and from a galaxy so far, far away that they didn't count :-) the company paid for us to get one. This was done mostly via RPL - Recognition of Prior Learning - we had to write up jobs we had done that applied to the competencies we needed to get the qualification. It was an awakening for me - almost no technical stuff at all - more procedural rubbish on dealing with jobs in order of priority, obseving health and safety regulations, etc.
So I guess we all have our areas of expertise. I'm just so glad I came form an era where you had to know about the guts of the equipment and actually pulled it apart and fixed it instead of just swapping it out and sending the old one off for repair....
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. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.