Skip navigation

I have been covering the basics of radiation effects over my last few blogs on Planet Analog and this time I discussed a bit about TID effects.  These are a little simpler to evaluate as the test procedure is relatively simple.  Of course, I say it is simple because the product test engineer has done a lot of the work for us already.  When checking a high speed ADC for TID effects the product is tested pre- and post-radiation exposure on the ATE.  A control unit is also tested for a comparison baseline.  In this case a control unit plus 4 units exposed to radiation were tested. The idea in this type of radiation analysis is to check for performance shifts in the ADC after it has been exposed to a specified amount of radiation.  In the case of the AD9246S in my blog the product was tested out to 100kRads.  As you can see below the performance has very little shift after radiation exposure which is exactly what you'd want for a space application.  Ideally there would be no shift, but in the real world things are rarely ever ideal.  However, in this case it is about as close as you can get and the AD9246S shows it holds up well to radiation for the case of TID.  If you'd like to read more please hop on over to Planet Analog and check out my blog: Planet Analog - Jonathan Harris - Total Ionizing Dose (TID) Effects with High Speed ADCs.


AD9246S HDR Report AC Parameters Plot

Every year I always look forward to bag day. It's usually filled with excitement, scramble, and way too much coffee way too late in the evening. But any way you cut it, Bag Day is the culmination of a rough 6 weeks of nonstop work.


On Team 2655, it also means some combinations. After being dared by a student last year on Valentines day to try dipping my donut in a bowl of queso, and subsequently discovering it actually tasted mildly like a cream cheese Danish, I accidentally started the most polarizing debate on the team to date. Several students requested I bring the odd pairing back again for bag day and, well, the rest is history. I'm kind of hoping it becomes this joke of a tradition. Another student tried dunking apples in honey mustard this year. Some people will try anything. Hey, an engineer has to keep an open mind, right?



Weird foods and sleepless nights aside, it's fun to see lots of cool robot reveal videos start to flood YouTube after being up past 1am last night. We've already spotted a few instances of our donation boards making appearances on robots. We're also seeing reveals from our other ADI teams across the globe. It's such a fitting time for bag day this year, since it happens to line up with National Engineer's Week. Seeing the work we put in culminate in a running robot makes all the blood, sweat, and tears more worth it than you can imagine.


Here's a team with a great cameo from our ADIS16448 IMU board about 30 seconds in.



Here's a great robot from ADI team 2471 Team Mean Machine from Camas, WA. Bruce told me about a cool tip-over avoidance/correction application they're trying to implement using the ADIS16448 IMU to help their driver out with controlling this beast of a robot when it's fully extended. Don't tip the robot guys! That thing is scary!



As more videos trickle out, I'm getting more and more excited for the competition season to get rolling. A couple of our ADI teams competed last weekend at the official Week 0 event, including 1153 Walpole Robo-Rebels and 4905 Andromeda One. Both even advanced to the playoffs. Looks like we're in for an exciting season across all of our ADI teams this year.




This blog is part of a series covering the 2018 season of the FIRST Robotics Competition, FIRST POWER UP. Stay tuned for more updates, including coverage of the Championship Events in Houston and Detroit at the end of April! Get to know the ADI teams, learn more about our donation boards, and meet the employee mentors that make it all happen!


2018: A Space Odyssey?

Posted by J.Harris Employee Feb 14, 2018

Now that I am working in the space products group at Analog Devices I pay much more close attention to various events occurring that are related to space and its exploration.  We are now just a few short weeks into 2018 and we have already had some very cool events some of which are pretty historic.


To start off 2018 on January 1st we had a full super moon.  If you do not know a super moon is termed as such because it is closer to Earth and appears brighter than usual in the night sky.  Since this particular one was the first full moon of the year it is often termed the Full Wolf Moon which is a term that goes back to Native Americans since they would often hear howling wolves outside their villages in the month of January.  This was not necessarily a historic event but turned out to be a precursor for some cool things to come. Only one day into 2018 and we had the first full moon and it was a super moon...pretty cool!


At the end of January we had the Super Blue Blood Moon with a lunar that is a mouthful!  Talk about the stars (ahem moon) lining up!  This was quite an historic event to have a super moon that was also a blue moon (second full moon in a month) and on top of that a lunar eclipse!  What a nice cherry on top! Take a look at a screenshot I grabbed from NASA's live stream of the event.  What a beautiful site to behold!


2018 Super Blue Blood Moon Lunar Eclipse


If you were up early enough on January 31st I hope you were able to catch this event on the live feed.  It wasn't terribly early on the east coast (start time was about 6:50AM) but was quite early for the west coast folks (that's 3:50AM).  The best view was from the west coast and thankfully NASA had the live stream for folks like myself who did not have a great view locally.If you missed the whole event, don't worry, you can watch a nifty time lapse from Griffith Observatory here: Super Blue Blood Moon Lunar Eclipse Time Lapse.


There will also be another lunar eclipse in late July of 2018.  It won't be lined up with a super moon or a blue moon however, but is still very neat to behold.


Next up we had an historic rocket launch when SpaceX launched their Falcon Heavy on February 6th.  The rocket is the most powerful operation rocket by a factor of two.  That is pretty amazing in itself.  The plan was for the Falcon Heavy to launch, send its two secondary boosters back to Earth landing them two platforms, subsequently send its main booster back to Earth landing it on a mobile platform in the ocean, and ultimately send "Starman" out in an orbit that would take it around Mars.  Starman is a SpaceX space suit riding in a Tesla, how is that for cool???  You can see more about the plan via the animation at


SpaceX Falcon Heavy Launch Animation


You can also see the video of Starman riding in his Tesla through space at the same link on the SpaceX website.


SpaceX Starman

Finally, if you want to see the real thing you can also see that.  The video is quite long so plan ahead, but it is really neat to watch.  I won't spoil the outcome for you so you'll have to go check out the video to see if SpaceX was completely successful with the launch.  I will say that you won't be disappointed!


SpaceX Replay of Falcon Heavy Launch


There are many other neat space events to see coming up in 2018.  For a pretty good list of events you can go to the calendar provided by over at Space Calendar 2018 - Rocket Launches & Night Sky Events


Another neat place to find a list of must-see events in 2018 is here: Top 8 Must-See Sky Events for 2018


I'd encourage you to take a space odyssey in 2018 and see all the cool events occurring in the sky overhead. Take a break from looking down at your computer all the time and look up and be mesmerized by the incredible sights to behold in the skies above us!

One of the blogs I follow regularly is that of John V-Neun from Team 148 the Robowranglers, a team that many in FRC are very familiar with. People like to think that all of the powerhouse teams just magically come up with a robot that works, or, heaven forbid, have a robot that is designed/built by the mentors and not the students themselves. No struggles, no difficulties, it just works. But if you read JVN's blog, you find that this just isn't the case. Higher caliber teams face many of the same struggles that even the most basic team has, and these struggles often parallel those we face in the engineering world.


JVN's most recent blog last week talks about the constant "two steps forward, one step back" pattern that is inescapable when working through the development process, and how disheartening and frustrating it can be. You show up to work or to the meeting with exactly one goal to accomplish for the day. And by some stroke of horrible luck, that one singular task does not get done, or worse, fails spectacularly. For JVN and his team, this was exactly what happened on Day 31 of the build season (for those not counting, that was February 5th). And believe me, both 5679 and 2655 have had their fair share of Day 31's this build season. I've definitely had my fair share of Day 31's in the 3 years I've been with ADI.


Think of all of the great accomplishments that we have seen in our lifetime... We have seen the revolution of IoT. We've witnessed the dawn of a new age of space exploration. We put the Juno probe in orbit around Jupiter! We saw SpaceX successfully land two booster rockets simultaneously, side by side. We sent a TESLA ROADSTER...TO MARS...JUST because we COULD! Think what would have happened if anyone in any of those accomplishments would have just given up after having a Day 31. None of these things would have happened. (JVN points to the countless failed rocket return landings from SpaceX before they had any successes, just as an example.)


One of the most important lessons any engineer can learn is to stare at failure in the face, laugh, and carry on looking for another solution with your head held high. If FRC doesn't teach that lesson to students I don't think there's a program around that will. It's the proverbial trial-by-fire of Day 31's. But darn it if all of those struggles don't make the successes that much sweeter when they do come.




This blog is part of a series covering the 2018 season of the FIRST Robotics Competition, FIRST POWER UP. Stay tuned for more updates, including coverage of the Championship Events in Houston and Detroit at the end of April! Get to know the ADI teams, learn more about our donation boards, and meet the employee mentors that make it all happen!

I started talking about radiation effects last month in my blog on Planet Analog.  In that blog post I looked at the cumulative effects that are observed.  In my latest installment this month on Planet Analog I discuss the different single event effects (SEEs) that are recorded when a device is exposed to radiation. This is a very important aspect of working with space products.  It is imperative to know what the performance of a particular device will be when exposed to radiation.  As you can imagine there is no shortage of radiation when outside the protective atmosphere of Earth.  There is a good bit even here in terrestrial applications but not on the order of what a device can be exposed to in space.  Think about how much radiation that Juno is exposed to while orbiting Jupiter...I'll give you a hint: its a LOT!  This is the reason we do such extensive radiation testing in cyclotron facilities. 


As I mentioned last month I had previously worked with ADCs so it was a natural fit to provide insight to the radiation experts in our group when looking at testing ADCs.  It is quite fun to be able to learn new things (radiation effects) and apply previous experience (from ADCs).  I hope that you enjoy learning some things about SEEs in my blog on Planet Analog, A Quick Overview of Radiation Effects: Single Event Effects. Stay tuned as I continue the series and explore how these different effects apply to high speed ADCs.

Before I begin this week's blog, I wanted to let you all know that jchong made some major updates to the IMU library code on GitHub. There is now complete support for all three official languages (LabVIEW, C++, and Java) and handy guides specific to each language. Check out the most recent drivers and user guide here!


If you have been following this blog series for a while, you likely know all of the teams that have enjoyed support from ADI employee mentors and sponsorships in the past. But with the merger with LTC last year, we were able to bring a few new teams to the list. This week, I talked some more with Bruce Whitefield, a Quality Manager at the Camas facility in Washington.


I had the pleasure of meeting Bruce in person at the Houston World Championship last year and snagged a cool team t-shirt (in exchange for a Platypi t-shirt of course...t-shirt trading is apparently pretty big in the FRC community, particularly at World's). Is this not the most clever use of a team name ever? And I thought 2468 Team Appreciate was a cool team name/number combo.


24 hours, 7 days a week, 1 build season24 hours a day, 7 days a week, 1 build season

I may or may not have been wearing mine a lot this build season...


Bruce is one of the core mentors for 2471, Team Mean Machine. He started off helping his son, who was one of the founding student members of the team. His son has since graduated high school and college as a Mechanical Engineer. Now, he designs 3D printers. Bruce jokingly said "I'm still playing around with robots!"


As mentors, we typically get to see a lot of development during the four years a student is on the team. They rarely leave the team the same person they were when they came in, and it's one of the things I love most about mentoring. Their successes are our successes, and their struggles are our own. I asked Bruce what the most amazing thing he's seen one of his students accomplish and he told me about one of his students that went on to become a Dean's List winner at the 2014 World Championship. To be selected as part of that small group of students is an amazing feat. It typically brings extra scholarship opportunities and makes a nice addition to college resumes, sure. But the students that get selected usually went to great lengths to help out in their communities, and do robotics, and keep their grades high. It's a special caliber of student, and they are usually the most amazing to watch do their work on a team.


Like any job, being an FRC mentor has its rough patches. I've had my fair share in just the 3 years I've been doing this with 2655. (Bruce has done 11 years so far!) However though it gets, though, there's something that keeps us coming back for more even when we get to Week 3 of Build Season and wonder "Why did I decide to give up life outside of work for this again???" For Bruce, it's watching what students are able to accomplish because of the impact that being on the team had on their lives. "The growth in learning and capabilities and confidence is amazing," Bruce said, "They launch out of high school on a much higher trajectory because of their FRC experience." One of their lead mentors bad to pull away in the middle of build season last year due to a death in the family. "The next week we had four team alumni show up at the shop saying 'We're here to help,'" Bruce told me. If that's not an indication that their lives had been so touched by this program, I'm not sure what is.


In the spirit of last week's article, I asked Bruce if there was anything he had learned by being a mentor that he might not have learned otherwise. "Quite a bit about CAD software, machining and CNC tools that I never would have had the opportunity or motivation to explore on my own," he said. "You don't learn until you have to teach it."


His favorite story though?


"I often remember the freshman who was watching from the periphery of the action on a preseason project. I handed him a drill and pointed to where the hole needed to be. He looked at the drill and then at me and asked incredulously, 'You mean you guys will let me drill a hole?" Turns out he had never held a drill before. I said, 'You can drill them all!' After we got the drill pointed the right direction, he proceeded to do so wih the biggest smile I've ever seen. Simply being trusted to touch the equipment started changing his life."




This blog is part of a series covering the 2018 season of the FIRST Robotics Competition, FIRST POWER UP. Stay tuned for more updates, including coverage of the Championship Events in Houston and Detroit at the end of April! Get to know the ADI teams, learn more about our donation boards, and meet the employee mentors that make it all happen!



When Mentors Learn

Posted by TheFeminineEngineer Employee Jan 15, 2018

Most of the time, FIRST is a fun way for me to volunteer my time to help create the future generation of engineers and to better the lives of young high school students in my local community.


But then there are those special days when I actually learn more than the students did. And on Saturday, it was one of those days.


When mentoring, I tend to gravitate towards the students that are struggling the most. Maybe I see my own timid self in them, maybe I just find joy in helping them achieve something they thought was impossible to surmount. Whatever the case may be, this year that resulted in taking charge of the CAD design team and guiding the climber subsystem team through the prototyping and designing process. Our climber team is in sort of a bind at the moment. They know exactly what we're doing for our climber and the concept is one we've stolen from last year's climber, so not much prototyping is involved. And since our mechanism relies on the cube lifter team's mechanism to be complete before we can even begin to assemble it, they're feeling pretty unproductive at this point.


This is where I would normally be able to say I gave them some side project and hooray everyone felt better and everything was rainbows and unicorns. But that would be lying. I'm not even 3 years into my career and about as many years into mentoring a robotics team, so I have exactly zero experience with managing a team. I tried bringing the team to the local tool shop to get some inspiration on how exactly to execute the part of the climber that actually grabs the rung, looking at different hooks, carabineers, and latches. I tried getting them all to Google some ideas. We watched videos of past years with similar climbing field elements. But nothing I did would get them thinking. Needless to say, by the end of Saturday our entire subsystem team left feeling uninvolved, unenlightened, and perhaps even dejected.


I was beginning to feel pretty terrible. Another day gone in the build season and we had accomplished just about nothing in our subsystem team other than "Look! I found last year's climber over here!" and "Let's use Velcro to attach it to the shaft again." Even Juan couldn't get them motivated to up and do something. The only part of the day in which they looked engaged was when we went to the machine shop to actually help the intake team with prototyping because they needed more than four hands. Why was I having so much trouble getting them excited about their system? And how much longer could they flounder before they lose interest in the team completely?


The nice part about mentoring an FRC team like ours is that there is usually a wealth of knowledge to be gained from other mentors, be it others on your team or others across the globe. Luckily, I didn't have to look far. I decided to turn to Kevin, an ADI engineer with plenty of experience leading teams between managing a team of engineers here at ADI and his numerous years as a Boy Scout leader.


He explained to me that when you are working with a team, regardless of what skill the task at hand requires, they will typically fall into one of four quadrants, and each quadrant requires a different coaching style for them to be as successful as possible.


Confident Competence - When you can give someone a task and they can go run with it without you worrying about them making too many mistakes along the way, that person is probably in this quadrant. These are the people that dive in head first and can be autonomous enough (and knowledgeable enough) to return to you once they've solved the problem at hand. Through most of my time mentoring the team, I've dealt with team members like this. These are the kids that are typically still trying to solve robots problems at home when the meeting is over, or that one programmer that decides to write a program to test the program he wrote because he didn't feel like typing in a bunch of random possible inputs. Very few people actually start here right out of school or when they first join the team.


Confident Incompetence - They'll dive in alright! But they'll ask you for a map and a GPS. Maybe they need a textbook or some other resource to learn more before they can start, assuming they know where their knowledge is lacking. If they are blissfully unaware of their knowledge deficiencies, they might charge forward so fast that they just run straight off the cliff because they thought they didn't need a map. Simply put, these people will have the confidence to jump in but they won't know where to start or might start in the wrong place. They need a little coaching to bring their knowledge up to speed, but once they're there you can let them go.


Competent, Lack of Confidence - To be honest, this is where I started in my career. Sure there were things I didn't know, but for the most part I knew what I was doing. But at a certain point, I realized that my input to a discussion was just as valid as the engineer with 20 years of experience sitting next to me and that it was worth speaking up about. People in the Competent Lack of Confidence quadrant know exactly what needs to be done. But they are too afraid to jump in and do it. This is where I feel like most new engineers tend to start. And to get them going you'll need to help them recognize their strengths before they truly blossom.


Lack of Competence, Lack of Confidence - This is where most rookies fall, and in many areas new engineers as well. They don't know where or how to start and usually either don't know enough to know where to ask for help or are too afraid to ask for help. Much like the Competent Lack of Confidence quadrant, they're quiet, and rarely attempt to add any input in a group conversation even if the room is dead silent. They require the most guidance to get them to the point where they can be autonomous. These are not the people whom you can just give a task and they will go run with it. This is where half of the Climber subsystem team falls, as half of them are brand new to the team.


That was my issue. I was trying to get these students going like they were in a Confident Competence quadrant when really the majority of them lacked both confidence and knowledge to get the job done on their own. Of course anything Juan or I tried wasn't going to work! With that in mind going into tonight's meeting, I'll have to come up with something different to do with them to keep them engaged.


It's situations like this that are the reason why I encourage everyone I meet to try mentoring a team, whether they have technical skills or not. Technical skills can be learned outside of robotics. But these soft leadership skills can only truly be learned with experience. It's much safer to try and fail in leadership on a robotics team than on the job. I really can't say it enough times, sometimes I think I learn more than the kids do on the team.




This blog is part of a series covering the 2018 season of the FIRST Robotics Competition, FIRST POWER UP. Stay tuned for more updates, including coverage of the Championship Events in Houston and Detroit at the end of April! Get to know the ADI teams, learn more about our donation boards, and meet the employee mentors that make it all happen!

It's that time of year once again as thousands of high school students across the globe begin the scramble to design, build, and test a robot in 6 weeks. This year's challenge has just been released this morning and I'm just as excited for FIRST Power Up as a dog is for tennis balls.


You are doing doggo a heckin excite there fren!

Throw the ball already!


You can watch the game reveal video on the FIRST Robotics Competition YouTube page!


Rather than talk about the teams today, I wanted to take some time to introduce everyone to what ADI has to offer to give your team an advantage, and why you want to use them!


ADXRS450 Gyro Board - Available on FIRST Choice and for Purchase on AndyMark

This is the same gyro board we included in the Kit of Parts last year. Code to use these boards is already integrated into the WPI library, so you can plug it into your SPI connector on the RoboRIO and get started right away. We talked to several teams at Championship and saw that many had great results during autonomous using them last year. Using a gyro is an easy way to determine which direction your robot is pointing, making it great for performing turns during autonomous or keeping your mecanum drive robot facing in the correct direction while strafing. The ADXRS450 gyro board is a great place to start for teams that are brand new to the world of gyro heading on their robot.


ADIS16448 10-Degree-of-Freedom IMU Board - Available on FIRST Choice

Back again on FIRST Choice this year is the ADIS16448 industrial grade inertial measurement unit (IMU). If you really want to get precise motion control, the IMU is the way to go. Each unit is calibrated individually at the factory, meaning more precision for your robot. High vibration environments (like being mounted on a competition robot with motors and pneumatics and crashing into walls) can also lead to significant errors on less expensive gyros, however the ADIS16448 happens to excel at rejecting this influence - it was designed for industrial grade UAVs after all! All of that adds up to superior performance when it comes to helping your robot know where it's pointing. Code is available on github here courtesy of jchong and there is even a handy installer available for teams that are using LabVIEW.  In addition, we know teams have had issues with this board in the past, and we are pleased to announce that with the newest RoboRIO image, teams can expect improved performance from the IMU compared to previous years. This applies to all of our IMU boards regardless of when they were obtained.


The metric most teams like to use when selecting a gyro for their robot is drift. Let's explore what that means for your robot.


Most gyros, including the ADXRS450 and the ones inside of the ADIS16448 IMU, produce an output that has a unit of degrees-per-second. It's a measure of the rate of rotation in a particular unit of time t. The higher the number, the faster your robot is rotating. A gyro does not simply output the degrees you've rotated your robot. A gyro will take hundreds of readings over the course of a given time period, indicated by the purple, red, and green lines in the figure below. If you were to add each of those readings together, you end up with the actual change in angle that occurred during that set time period (one second in the example below). The calculus term for this is integration. For those who have taken calculus (or those of you "older folk" that remember your calculus classes "back in the day"), this is the same as calculating the area under the curve. This math is done for you in the WPI library and in the code linked above for the IMU.


When you first turn on the robot, the orientation you place the robot in will be set as 0 degrees. Think of this as your robot's idea of "due-north" or straight forward (for example, towards the opposing team's driver station).


Top is the front of the robot in this case


However, since no gyro is perfect, that direction will drift over time. Remember how we have to obtain the actual direction in degrees by adding every single sample together? Over time, every little error in each individual reading begins to add up. These errors could be from any number of different internal and external sources. (If you're interested in learning more about all of these error sources, you can check out this article.) The biggest contributing factor to this drift is the gyro's Bias Stability spec, which is a measure of how stable the gyro measurement is over a long period of time. If you were to leave your robot powered on for a full hour without moving it, the gyro value would read something very different from zero at the end of that hour.


Again, the top is the front of the robot


This is what teams typically refer to as gyro drift. Once you take into account the different error sources mentioned in the article linked above, teams can expect the IMU to drift somewhere between 20 and 30 degrees per hour. At first glance, that might seem like a lot of drift! But if you look at what this means over the course of a match, we see this drift is actually not so bad. If we assume your robot stayed powered on for a full 7 minutes before the match even started, your robot will think it's heading has only changed by about 3 degrees. By the end of the match, that number is closer to 4 or 5 degrees, which is much smaller and more manageable.


Now that all of you are experts in gyro drift (right?), you are armed with the knowledge to make the most epic autonomous routine ever!


This year we want to give a huge shout out to Samtec for providing the connectors on both of these boards as a donation to FIRST Robotics! Samtec offers a wide range of connector solutions, ranging from simple digital/analog I/O to RF and even optics. They have been a long-time partner for the iSensor product family, and we're excited to have them on board with this year's donations! You can check out their website here and their FIRST Kickoff blog post here.


Are you ready to POWER UP? Share your thoughts about the game reveal below or how you would solve this year's challenge. Be sure to follow The Engineering Mind for updates throughout the robotics season!




This blog is part of a series covering the 2018 season of the FIRST Robotics Competition, FIRST POWER UP. Stay tuned for more updates, including coverage of the Championship Events in Houston and Detroit at the end of April! Get to know the ADI teams, learn more about our donation boards, and meet the employee mentors that make it all happen!

It can sometimes be a challenge to come up with good ideas to blog about each month.  I have typically pulled a lot from past experience, common customer questions, and interactions with coworkers.  While it seems like a potentially large pool of information to pull from it can be difficult at times to get that really good idea that makes a great blog.  As I was trying to coming up with that great topic this month it came to me that it would be a great series of blogs to combine two of the areas I have worked with here at ADI; high speed ADCs and radiation.  I've blogged quite a bit about various topics related to the high speed ADCs that we offer here at ADI.  I've also done a few blogs about radiation testing and how this is done at facilities like the one at Texas A&M University.  Why not combine the two topics and talk a bit about how radiation affects high speed converter operation.  In order to talk about those effects specifically though we must first take a look at what types of radiation effects we typically try to observe.  That leads me to the first blog in this series where I begin by looking at an overview of different radiation effects. You can find that on Planet Analog here: A Quick Overview of Radiation Effects. I encourage you to take a look and learn a little about radiation effects and prepare to see how these affect high speed ADCs in my next few blogs in the coming months.

In my last post I talked a bit about coding in Python for line regulation on an LDO.  In my latest installment on Planet Analog I talked a bit more about coding but focused on load regulation.  The two measurements are very similar so there was opportunity to re-use a lot of the Python code from the line regulation to do the load regulation.  Obviously some tweaks were required, but there was a lot in common between the two scripts.  I hope it helps to see how useful coding can be to help improve the efficiency in our tasks, especially in collecting data in the lab.  Check out my latest blog post on Planet Analog here: Load Regulation Measurement Coding in Python.

The last couple of blogs that I had written had me thinking about how coding (programming) skills have been valuable in my engineering career.  While by no means am I an expert at writing code, the little that I do know has proven quite useful.  I didn't fully grasp how useful it would be all those years ago when my graduate school advisor put an emphasis on coding.  He thought every EE should know how to write code.  I look at the engineering roles I work with regularly and see how many could not do their jobs without know how to code.  In applications engineering I am using it to automate bench measurements.  Similarly the product engineers that I know also do the same.  Test engineers have to write code for the ATE. The list goes on and on.  In that vein I thought I'd write a bit about the basics on a recent Python script to share with everyone. Take a look at my latest blog on Planet Analog: Line Regulation Measurement Coding in Python. Do you using coding in your daily functions?  How valuable is it for you?

I recently had a very interesting experience pulling an all-nighter to get some important testing performed down at the cyclotron at Texas A&M.  Do you remember pulling those long nights working on that critical project?  Perhaps you've even still had a few of those nights working as an engineer when a tape out date was approaching or a critical customer issue was pressing.  Take a look at my latest blog on Planet Analog Pulling an All-Nighter and hear a little about my recent experience.  I also encourage you to keep the folks that were in the paths of Harvery and Irma as well as those currently being affected by Maria in your thoughts and prayers.

I took a few months off in June and July due to moving to a new house.  I was back in August where I wrote about the continual learning process.  One of the examples I used was related to the usefulness of software on the job.  I am a tried and true 'hardware' guy but the more I work in the field of engineering the more I realize how important and valuable software can be.  I've had to continually learn on the job in many aspects, but software has definitely been a challenging one for me.  I encourage you to read more here: Learning Is Not Just for New Engineers.  Please also stay tuned as I'll have another blog post up soon during September.

Things are changing, they are changing very rapidly. You could apply this phrase to many different things in your life, and yes, it would be fine but I want to focus in the environment where engineers, in fact most professionals, spend a good amount of their time; at work.


In the work environment, engineers are applying their knowledge to advance existing technology, be it the World Wide Web, IoT or the way you ride your bicycle. All these improvements most certainly requires change. It can range from an adoption of new processes/technology to organizational approaches that aim at accomplishing desired product performance or functionality. But what they all have in common is the need to modify a behavior, the manner in which an engineer chooses to pursue and implement his/her ideas. It can be that tools once available to assist in a specific task do not exist or are no longer supported, forcing one to change the means used to accomplish a task. And in that, there’s a possibility that new knowledge is required, a long day of research or lecture depending on what the needs are. It is right at this point where tensions rise.



I can testify that changing is difficult, independent of how good it appears. But, what motivates me is when I perceive the benefits to me personally, to my coworkers and to the organization I am a part of. It is true that the global environment we live in requires us to constantly change, and if change doesn’t happen you’re left behind (I’ll leave this to your interpretation). But, it is not only the responsibility of the individual to pursue changes, rather the organization as a whole. The management team must provide the vision and the reasons why such changes are beneficial to each individual. The individual engineer must understand that change is inevitable, unless one is a conformist and has no desire for improvements of any kind. I cannot see personal growth without change, and that’s the reason I choose to always learn/change.


Nothing is perfect! Any change will be difficult, there will be mistakes. But, there should be a starting point, at the end of the day things will normalize. Engineers should understand this and not be afraid to voice their opinions about changes and what could be improved. Conformism should not be a part of anyone’s profession, it tends to delay outcomes and prevents change. Organizations should understand that any change needs reasoning and should help individuals see the benefits of it. Also, and this is applicable to both parties, the individual should know that change is possible and the organization should note that some individuals might not agree with their proposed changes. As an individual, I want to be prepared for all the new exciting things happening around me. I want to be able to enjoy every single bit of it while enjoying my life and those around me.


“At times of change, the learners are the ones who will inherit the world, while the knowers will be beautifully prepared for a world which no longer exists.” – Alistair Smith

I hope you enjoyed reading my last blog post on my first FIRST experience.  I wanted to go back and take a look at the event after the fact and explore a bit more about the demonstrations we showed while in Houston and Saint Louis.  Several days were exhausting and the entire two week stretch was pretty exhausting overall, but it was an incredible experience.  Take a look at my latest blog on Planet Analog where I explore more about the two weeks spent supporting FIRST for ADI.  You can find my blog here: A Look Back at Two Weeks of FIRST.