Sr. Electronics Engineer

Biography has not been added


's contributions
    • What I like to put at the top of the list after understanding the configuration and trying to reproduce the problem is to find out what side of the fence is it on? Hardware or Software. I usually try to establish that by insuring ALL critical functions are sound: Power supply, Clocks, Signal Integrity of data signals ect. This also can be accomplished by asking the question: "has the problem shown up on multiple other pieces of hardware?". Then the other question for hardware is environment: temp, humidity, and combined. Access to a environmental chamber is key here.

    • A use case for radar makes sense. I have serious doubts about the viability of this frequency replacing WiFi like devices. If the reason is confining the signal to a room, that use case makes sense, but for bandwidth forget it. I moved up from 2.4Ghz WiFi to 5.8Ghz and only saw a 50% throughput increase (from 20Mbps to ~30Mbps). So by going to 60Ghz, you will raise the cost of the equipment, and have marginal increase in speed. As far as interference, I don't buy it because I'm in a suburban area. I hope we don't do to Wifi what Comcast did to cable TV (promise stuff we don't need and raise prices 70%).

    • Jack good list of books. I would add that anyone serious about op-amp design to get "Optimizing Op Amp Performance" by Jerald Graeme, or some of his earlier works while part of Burr-Brown. TI has some good app notes as well. I agree that now many interface circuit designs are so old that people think they "connect the dots" and it just works. Usually they find out otherwise. If you don't understand it, it will likely bite you in the *&#.

    • So you have had 2 cars that did this and you are still buying what you call "American"...why? You do know that many Toyotas are built in the US right? I'm ok with people buying Cars because they like the style and features, but question buying on characteristics that can't be easily verified (American content?). Only recently are the domestic car vendors focusing more on reliability. The Japanese vendors have been selling on that for some time which is partly why the uproar of Toyota having such a problem.

    • Aubrey, good to know about the chips you mentioned. When it comes to making an elastomeric keyboard, what people forget in the pursuit of is I see some try a HASL coated surface for making the switch contact with the carbon pill attached to the key. Works for a little while then fails because of the oxidation. There are selective coatings for such areas if you need to stay with HASL for cost, otherwise go ENIG (gold) and the product will work for years.

    • So at Carnegie Mellon, students are not taught to design to the "best commercial practice" standards? Sounds like doublespeak. You can't have it both ways (displaying the code on the University website as an "example"). And as far as scaling metrics, it is done all the time in the commercial world when no other methods are available. Yes, the scaling may not be linear, but it is a reasonable approximation in many cases of system design.

    • The concept of "High Visibility" is a great tool. It applies to more than just the documents we write. It is all about effectively communicating a concept to a target audience(s). A document well crafted is useful a a thing of beauty :-). Thanks for the templates and concepts, definitely a new tool in my tool box. Yes, I'm one of the strange engineers that doesn't mind creating documents explaining my work for others effectively and creatively.

    • Layout is progressing to a "weird phase" right now, by that I mean seeing amazing products (like the I-phone), yet when I try to find a contract layout firm in the Northeast US (where I live and work), the overall skill level except for digital only designs is very poor. Discussions with managers at these firms indicate work coming at them by low-skill EE's with almost no experience, with unrealistic expectations. Checking artwork is art and science. The tools are very good at verifying connectivity (can't live without PADS DRC!), but checking proximity of devices/traces to other features is the "art" or recognition of what physics may be at play and knowing what to do about it. Layout is a bit Like Integration in Calculus, you start with an assumption, and progress from there. You can't take everything into account simultaneously, you must start with a basic assumption (part placement) and solve the puzzle from there...

    • Job well Done Jack...thank you. Your articles helped this EE know enough about the programming world to be dangerous :-)..

    • While I welcome others exploring coding through trial-and-error, it is a path that does not assure success. An EE by trade, and having experimented with the Arduino platform, I find the general level of code quality available for "free" is pretty poor, so the old saying "you get what you pay for". By earning a BS or MS degree, you are forced to take some classes that are not necessarily fun, but some of those build your critical thinking skills - short cuts are not what will launch a sustainable career in engineering. I would encourage people to try out the maker space, and if it appeals to you, then pursue a more formalized education. The quality of what results will generally be much better than without.

    • Tip of the iceberg Jack. Show something on a digital display and people will believe it and not question it. I work in the life sciences sector and it is not unusual to come across a scientist checking a temperature reading that is expected to be within 0.1C with a meter only capable of +/-1-DegC. So much for precision :-) I do laugh at forecasts with 0.1% resolution!

    • Jack that gets the "KISS" award! From a reliability standpoint (comparing commercial marine electronics with mechanical), I would think that the mechanical approach as you mentioned might be slightly more reliable only because it could be inspected before launch. Then as Bob Synder has suggested, use the electronics in a SCADA mode. Nice combo with excellent reliability.

    • Thanks Jack, some good rules not only for coding, but for NET NAMING in circuit board design. The only item I would disagree with is use of abbreviations. Some industries rely upon them heavily and are well known. I don't see a problem with using them if you provide the user with a common list somewhere in the comments section. As a EE reading someone elses code, I have a hard time following code written with 30character variable names. It separates the operators too much with long names - not as easy to scan quickly.

    • Nice introduction to Python Max, thanks. What I find interesting is that I don't hear much discussion about experience, libraries and reliability when I hear discussions about tool selection. While using the latest "hammer" may appear "cutting edge", at the end of the day what counts for professionals is what gets done and how reliable it is. Adding more languages dilutes the experience pool of programmers. I'd rather have a guy programming solid "C" for 10years, than someone who only jumped on the Python wagon within the last year. What contracts are in place for supporting all the tools required. And lets not forget the learning curve to know how to use all the libraries for the processors we use. At some point a company has to "standardize" on something for at least a little while.

    • Aubrey, thanks for not assuming we all know what this is (coming out from under my rock). In the US, they must only use facebook or something like that (That I don't bother with :-)) I see Mouser Electronics are starting to pick them up, I'll have to check it out.

    • Don't forget some of your peripherals may have a built-in self test such as MEMS accelerometers. We have had a failure where the core of the device (accelerometer) communicated with the CPU, yet an axis failed to provide live data (output was fixed). Exercising the built-in test would have detected that failure mode.

    • Jack, I'm sure every one on this site could add to your list (great list to focus on, I completely agree), but one comes to mind when I buy a piece of engineering instrumentation. "Customer expectations". The example to leaps to mind is Tektronix. They used to be the darling of the Oscilloscope market until they tried to compete on Price - and failed on reliability, my key requirement or expectation. When I'm in the trenches fighting bugs, the last thing I need to worry about is my scope failing or lying to me. Price is great, but once you build a great reputation, it is foolish to lose what got you there.

    • Michael, a very good summary and puts things in a balanced perspective. The other angle I would add to the open source experience is as follows. The quality also appears to be related to the relative number of users. As a hardware engineer's first foray into the open source world, I tried the Arduino platform. Overall, I find it meets my expectations for "open source" and is relatively easy to use. However, I downloaded an open source driver for a Microchip I/O expander and found the quality of the code well below expectations. I would imagine the # of users of the Arduino IDE is several orders of magnitude greater than this driver. Now I will expect to have to rewrite any driver I get for "Free". Will it still save time, perhaps.

    • My current experience with arduino (my first project) is painful at the moment. I find that if you are working with peripherals directly connected to the arduino, the arduino code is pretty solid and works. Beyond that I question the benefit. I downloaded a class of routines to drive a microchip I/O expander and am finding quite a few errors and poor coding techniques. This is a challenge for me as I'm also learning C++ at the same time. Again, you get what you pay for. Perhaps if I code for a living (I'm a hardware engineer) it would be more acceptable.

    • Thanks for the article Jack. Reliability in engineering whether it be hardware or software is of keen interest to me. As I'm starting to hear more about Agile, the statement "One of the rationales for agile methods is, as Kent Beck puts it, everything changes all of the time" is a self fulfilling prophesy. Are you going to tell me that a Arm9 Processor with 26million transistors is more complex? Yet, those function without having to be "swapped" out all the time. Yes, there is errata sheet, but nowhere near the churn I see in software. I think a lot of development teams haven't been forced to seriously look at formalizing requirements. My current employer, having been in existence for more than 40years is only now methodically looking at requirements as key quality driver. Yes, its hard, but prototype displays, and the like are what we are using to get buy in from "the customer" as to how an interface is to work. From that, we will complete the formal requirements. Putting your ideas to "paper" force you to think more critically about what you are about to do, rather than "wing it". To be fair, hardware is no different and it has its share of issues to maintain quality in an era of escalating complexity and speed of development.