Company: Buckman Hardy Associate
Position: Junior Embedded Engineer
Start Date: June 2018
End Date: September 2019
The year in industry is part of the 4-year BENG course from the university of kent. It contributes 10% to the final grade. The aim of this is to get real-world industry experience. Much has been achieved over the course of 15 months.
At the start of my placement, I and Alan created aims checks list. This list outlines what I want to achieve from my placement. It was one of the first things that were done, and I think it was extremely helpful throughout the year since I could go back and check what aspect of engineering I have covered and what I haven’t. Due to my interests and the fact BHA is a small company, this incorporated all aspects of product development however it did focus mainly on the technical side of the development. I have only included the aims I have achieved.
- Contributing to a discussion of the task in hand
- Able to locate resources for the project (datasheet of IC)
- Role of each of the team member in the project.
- Tools needed to view and edit different types of file (dxf, sch etc)
- Importance and methodology of backups
- Customer meetings preparation
- Assembly of PCB’s through-hole and surface mount including difficult objects in a prototyping environment.
- Identifying components and available sources – UK suppliers (Farnell, Mouser, RS) & China factory parts availability.
- Understanding circuit diagrams with references to a functional requirement in order to identify the key test and how to do them.
- Fault Finding various categories of fault with a strategy for attempting each one
- Use of test equipment to help fault finding (Multimeters, Winlogic, Windisp, Debuggers, Oscilloscope).
- Critical analysis of prototypes for the next PCB (printed circuit board) board turn.
- Understanding to standards to which equipment must comply to.
- Creepage and clearance during circuit design for sensitive and high voltage circuit design.
- Voltage and current requirement vs component rating (real-world values)
- Analog circuit simulation in spice and Tina to prove theory works.
- Understanding digital circuit IC datasheet then implementing it to a design to make a schematic.
- Understanding sources of noise in electrical circuits and how to reduce its effects.
- Understanding how EMC affects the design
- Understanding switching & linear power circuit design for (diagnostic & troubleshooting)
- Understanding port in characteristics during different mode (ISP, RESET, Normal)
- Onboard peripherals modules (ADC, PWM, UART, CAN.)
- Choosing a processor-based on project specification. (size, number of pins, price)
- External and onboard AD converter.
- Using BHA and commercial development environment tools (Kiel 4, 5, MCU Expresso, Proteus, Winlogic, Windisp, George, Subversion)
- Understanding BHA embedded operating system and software components
- Understanding custom BHA RTOS & using it
- Breaking large software projects down into small bite-size chunks.
- Using the custom made BHA Library (cannot use open source lib due to licencing issues)
- Writing readable code in embedded C / C++
- Understanding the concept of layering & multiple file programs
- Use complex C structures (function pointers, pointers, memory management, structures)
- Using interrupts and timing in code
- Subversion for storing and keeping track of changes
- Debugging using Windisp (BHA software)
- PCB layout using Proteus Labcenter
- The custom footprint of IC and symbol creation
- Understanding strategies to set up the PCB package
- Creating BOM (Bill of Materials) & Stocklist
- Checking using checknets script
- Using different display types LCD, Static
- Input and keypad for control
- Using ramtex graphical libraries
- Designing and making custom GUI interfaces
- Learning how to manage unknown hardware with unknown software.
- Hello World in a new embedded system & new prototype board
- Develop scripts for George (custom BHA software).
- Develop pc software using windisp tool to display UART data.
- Understand what aspect of the project is tested and understand the different stages of testing.
- Customising the hardware with software personality at factory
- Designing and creating product calibration parameter for factory
- Understanding the costs of various components and how they impact the design and quote
- Understanding how product sale price constraints to design choices and parts
- Alternative parts & price and availability
- Working with the customer to create a complete specification
- Analysis of the key areas of the project and attempt at unit costing, estimating development time and guessing what resources will be required.
- Project planning (Gantt chart)
- Handling changes and addition to specification mid-development.
- Commenting code to a good standard
- Using the logbook provided to its fullest
- Documenting faults with hardware in the build report
- Maintaining change notes for hardware and software
- List of documents to be supplied (issued files)
- Bug tracking (using Mantis bug tracker)
- Understand different ways to approach software bugs and hardware faults.
- Use tools to troubleshoot faults
- Use software to trace bugs
- Checking factory counter samples
- Finding production issues
- Dealing with faults on sold products
Software for HVDC UI: A/D reading to detect the battery level, DAC to control the beeper volume, SCT PWM to control LCD backlight level. Multi microcontroller project CAN bus communication with multiple nodes. A graphical user interface to control HV handle which can generate up to 40,000 Volts via CAN bus. Account system and user-level management system on an embedded platform with GUI access for passcode management. Reading and writing to EE flash, using LPC Open library, UART communication and getting it working with legacy software. Keypad software to detect button press and long presses. Putting everything together to create a working embedded system operating system. Dealing with bugs as they come along.
Software for Fuse Finder 3 receiver: Read the A/D, compare differential measurement, and convert to the logarithmic range, displaying the correct value on the LED bar graph. Write a driver to drive the full H-Bridge beeper using SCT PWM with pitch and beep frequency control.
Software for Barbra DNO: Convert existing 3 wire loop measurement device code (KT63) to a 2 wire (LN differential measurement) device with reduced functionality. Modify the code to make it work with a new display. Write some custom code which detects if the installed fuse is blown/missing and alert the user. Write the device driver for a new 16Bit ADC IC using the datasheet provided with the IC. Integrate the hardware changes with the old digital board and get measurements working.
Assembling / Disassembling PCB through holes and SMD using scopes, hot plate, special flux
Designing HVDV UI schematic using PH Project as reference.
Designing custom Proteus IC footprint & schematic model for new parts
Modifying old parts on Proteus to fit the current component (battery holder PH project)
Documentation for the client to use with the engineering sample of the product.
Using test equipment (oscilloscope, multimeters) to find faults.
Making a bill of material & shortage list for projects.
Doing the layout for HVDC UI & Fuse Finder 3 RX, considering design constraint.
Using a range of different microcontrollers to do projects: LPC1549, LPC824, LPC1763
Creating custom characters and libraries.
Creating custom symbols and icons with icon edit and using it in embedded systems.
Calibrate devices with factory adjustment box and write custom George script to automate calibration.
Testing case and hardware for thermal issues (Barbara DNO, HVDC)
Testing device and making sure the code works properly.
Custom Windisp scripts for HVDC, FuseFinder 3, Barbra DNO for UART communication and byte size code execution.
Subversion: Revision control for software – tracking software changes.
Mantis: Bug tracking for projects (software and hardware)
Serial debug and using professional debuggers to troubleshoot software problems.
Integrated Development Environment: Keil 5, 5 & MCU Xpresso (eclipsed based).
Using custom BHA RTOS for software development.
Programming: C (HVDC), C++ (Fuse Finder 3 RX), C & C++ (Barbara DNO) and writing clear readable code.
Investigating a stepper motor drive system: Using ESP8266 as a receiver, Arduino as the microcontroller and a second ESP8266 as WIFI remote (transmitter) to control stepper motor driver (micro-stepping investigation)
When I first started working at BHA, they were not sure what experience I had and started me with the basics; soldering & PCB assembly, because it’s a low risk task with which requires minimal technical knowledge. However, it’s a skill all engineers should possess. For the first few months at the company, all I did was make new boards.. I did have some experience soldering however it was mainly through-hole. Soldering surface mount resistor and capacitors was easy but soldering 100pin LPC1763 microcontrollers using Alans method was a nightmare. I ended up going on YouTube to find a better method, I found drag soldering with a flat solder tip worked really well.
As I look back at the whole year, there has been a gradual change not just on the type of work but how I interacted, and me as a person. At the start of the year, I was quite outspoken. I would often bring up ideas and things that were taught at university e.g. using Arduino. It took a while to understand that the university uses what they do for the purpose of learning and in the industry the same tools & platform will be impractical. There is a divide when it comes to hardware and software used for teaching and actual hardware and software used in the professional industry.
I was assigned a research project by Mike: search the market and come up with suitable alternatives for a new microcontroller to be used on an upcoming project and evaluate maker boards such as Arduino and raspberry pi. I spent a week searching the internet, in the end, I had a spreadsheet with 20 development boards with its detail’s pros and cons. I ended up answering most of my earlier questions. It was an eye-opener; there is a massive world outside of education and university only covers a small aspect of project development. The education system itself is tailored to teach, the tools, hardware and software are tailored to teach. I cannot take them and use it at BHA it doesn’t fit the ecosystem, instead, I must use the transferable skills which I have developed during the first 2 years of university. What I can take is concepts and idea of things that’s can be moulded as the situation calls for it. This was an important lesson which I learnt quite early on in my placement.
Alan also owns another business called AWR they produce equipment for astronomy. His current stepper motor drive system design is quite old so he asked me if I could investigate a more efficient design based off development boards available on the market. Then compare the linearity of the micro-stepping in these systems with the current system. This was a low-risk side project which has no value if it did or didn’t work, however as I look back, I think they were testing me on what I know. Because it encapsulates everything; the research to understand a new concept (micro-stepping) and research to find a suitable hardware design under a certain budget. It incorporated some hardware such as using the development board and connecting it to the current stepper motors [Figure 1]. And a lot of software, since essentially, I was buying a micro-stepping driver on board, I had to connect a suitable microcontroller. I stuck with what I learned from university and ended up using the Arduino software environment with the ESP8266 system on chip which I used in my second-year project. However, no libraries existed so I ended up making my own for the stepper-motor driver IC, looking back I think they were very impressed with my work and promptly changed me to work on something useful to the company, a project they are getting paid for.
Figure 1 Stepper-motor using ESP8266 & Arduino
I started working on the hardware of the Barbara DNO soon after. Barbara DNO is a 2 wire (neutral and live) loop tester, it can also measure voltages to 1% accuracy up to 500volt AC. This is a simplification and improvement of an existing product (KT63). One of the first things I did at the start of the project was to list down the tasks I need to perform for this project and how to best tackle each of the problems. I broke down each of the large tasks into small tasks and these small tasks into an even smaller task to a point where I can start writing code for these tasks. For example, one of the main functions of the DNO is too able to read AC voltage up to 500 volts. To get voltage reading I had to make sure the ADC is functioning and the conversion formula from raw to volts is correct. To get valid raw ADC reading I must establish SPI communication. To understand how the SPI peripheral works for this specific microcontroller I must consult the user manual. At university, we were always encouraged to use the datasheet and user manual to solve problems like this, however, hardly anyone did so in the second year. This was because most of the projects involved Arduino modules and there are prewritten libraries for these modules, so there was no need to consult the user manuals/datasheets, instead, students focused their time on understanding the API so they can use it in their project. This does not really work in the industry since the components and parts are unique and for the most part, there are no precompiled libraries for that specific IC (not a module). All you get is a datasheet and if you’re lucky you might get some application note, however from my experience I found application notes tend to contain a lot of bugs and it should be taken with a grain of salt.
Since the hardware of the DNO was based off a previous edition, it was my responsibility to make the new analogue board work with the old digital board. This meant I was hacking and modding the analogue board . This was a tedious process since the PCB is all surface mount and it was confusing dealing with so many jumper cables. I hand modified the schematic for the analogue board then I explained to Will what needed to be changed for the second board turn. Since the DNO is a split branch of an existing product I used the KT63 product as a starting point. Although the processor on KT63 was same as the DNO the analogue circuitry was completely different. I had to write the driver software for a new 16-bit ADC. At university, we were taught the theory on how analogue to digital converters work and some of the implications converting the real world to digital (noise). In Dr Winston’s microcontroller lectures SPI interface was briefly mentioned among other types of communication I2C, UART RS232. However, we have never connected an ADC to a microcontroller and then use the SPI interface to read the raw ADC count to convert the raw data to real-world voltages. At BHA while I was developing the ADC driver, I had to read the datasheet in detail. I had to understand the timing diagram for the 16bit ADC IC in order to understand how to communicate with the device. At first, it didn’t work, and it took many attempts to get it to work. To overcome my issues, I used a 4 channel multi-meter to check the pattern and timing diagram to verify they were correct, it turned out the board had not been assembled properly.
A lot more work has gone into the DNO project to get it where it is. It’s currently at a stage where it can be sent to the beta tester for evaluation after the factory counter sample fixes have been applied. However, the journey getting the software was full of trials and error, to me, it felt like I was walking in the darkness with a narrow beam torchlight. I had to throw away the parts of the KT63 code that were no longer relevant which is easier said than done because I had no idea what the code did in the first place. Also, at the office, there were differing views on how I should tackle the issue. Mike who wrote the KT63 code (which ended up being the base for DNO code) suggested I get rid of all the unnecessary code; this will make the code smaller and easier to understand. However, Alan who was supervising the project suggested I should keep all the old code in place and comment out the bits of code that I don’t need. This ended up being a chicken and egg paradox. I didn’t understand the whole code because there was too much code (107 files) some dating back to 2003. So, I couldn’t delete code randomly without knowing if it’s relevant and I couldn’t just comment the bits out because this makes the code even harder to follow. I came up with my own solution to the problem. I concentrated on getting small tasked completed and while in the process, I would comment irrelevant code surrounding that type and once I had the task working, I would delete the commented code. As I got more parts of the software working it became more readable. This resulted in a slower start to the project but picked up its paces once I understood how each part of the code linked and worked with other codes.
Overall, I did not face many problems with the projects and other than minor inconveniences which are expected in an engineering project. I was able to finish the software on time and according to the project timeline. Some of the other things I worked on the DNO includes writing software for a new display and configuring the memory map of the screen. I also ended up working closely with the customer to come up with an animation for the measuring screen. Sometimes the customers have no idea how something should be. This was the case here, so I came up with 3 different animations for the measuring screen, the customer ended up choosing one out of the 3. The process would have been much longer if I asked them exactly how they want the animation, there would have been a lot more back and forth communication which uses up valuable time.
“Anything that can go wrong will go wrong” – Murphy’s law
This was certainly true for the fuse finder 3 project. Fuse finder 3 is a device for electricians to determine how the house wiring is connected. Mike was leading the project and he was also responsible for the hardware design of both transmitter and receiver. My job was to write the software for the receiver and general diagnosis of hardware and to build them. The project has been ongoing since 2017. When I started working on the project the transmitter software and hardware was mostly done whereas only the schematic had been done for the receiver. It was far behind its counterpart.
There were problems after problems: The footprint of the LPC MCU was smaller than recommended which meant it was near impossible soldering the processor. I had to ask Will to order me tools and flux used by professionals (Louis Rossmann: High-density PCB repair specialist from YouTube). The receiver PCB would latch-up and short out randomly, which ended up damaging multiple board and processors, it was a complete nightmare; especially when no one in the office could explain why this was happening. To add salts to injury the problem was intermittent. After 3 weeks spent analysing it came down to the power supply, during start-up the voltage would spike to 13 volts when it was set to 3 volts, this damaged the switcher and secondly, the processor was booting up too fast and the switcher was not able to supply the current for the processor. This was fixed with a 10-millisecond delay during the bootup process. The power supply was modded to eliminate the voltage spike.
The customer wanted an inductive beeper because it’s louder and you can control the pitch and the frequency however the beeper ended up interfering with the electromagnetic signals from the transmitter. I ended up doing a lot of controlled testing to determine this see figure 3 below.
Figure 3 Control Testing the FF3 Receiver
Mike has sourced an alternative beeper which uses a different technology. The software was completed with version 1 of hardware and there will be minor changes to the software going to version 2. However, a lot of the hardware has changed. I have handed fuse finer back to Mike since I was busy working on the project (HVDC UI).
HVDC is a holiday detector which can check paint coatings for various materials to make sure there are no microscopic holes. The product has multiple use cases from medical to acid factory. When I started at BHA back in June 2018 the project was in its early stages, this was different from the other 2 projects which have been going on for a year or two.
This meant I got to experience how a concept idea went from something in customers mind to a working product. I got to experience how to interact with customers to understand what they really want. Which may be different from what they say and write down on paper. I also found sometimes the customers don’t know how they want it, especially when it comes to deciding on the details. They are however quite good at judging the final work – constructive criticism is key to success.
I the start of the project Alan who was supervising me assigned me to basic tasks on this project such as build the PCB boards for the UI and handle. Using pH project as base create the schematic & layout for the UI board. However, as I became more competent at programming shown by my earlier project contribution, Alan grew more confident and started assigning software jobs. I ended up overtaking all the software for the HVDC UI and Mike did the software for HVDC Handle. Will was responsible for the handle hardware as well as overlooking the UI hardware which Alan was responsible for.
The HVDC UI software was at a good stage when I left. I wrote over ~27,000 lines of code spread across 149 different files. The software was at a stage where it did all the things the existing product line can preform plus a lot more. It incorporated a user account system, pin code locking/unlocking, Hot-swappable handles, CAN implementation, support for multiple handles. Here are some images of the UI which I have been working on [ 5 – 14].
Driver software like backlight control, beeper volume and battery measurement protocol are easy, because once you get it working it’s unlikely you will have to redo it again unless there’s a major hardware change. However, when it comes to UI (User Interface) graphics/text/ menu on display which users interact with. The functional aspect becomes a lot less important. Its how the user feels, does it feel right and a lot of opinion-based decision is made. I and Alan disagreed upon a lot of the user design choices especially early on the project. We disagreed mostly on aesthetics and layout of graphics I think it could be due to the age gap between us. For example, for the menu icon, Alan suggested a scroll as the icon whereas I used something modern. In the end, the customer is always right and he liked my design of the icon, so we stuck with it.
At the start of the project, I was advised of this by Mike – “UI code can get messy very quickly”. But I found this the hard way. Even though I was coding the best way possible, employing skills and rules taught in OOP Java lectures from stage 1 & 2. How do you prepare for future possible changes, especially when the specification is so loosely defined by the customers?
There were many instances where the customers ended up changing the specification of the project during the monthly meetings. The changes were mostly related to the UI as expected. As an example, they defined the account system specification very loosely and once it was completed, the customers said this was not what they had in mind exactly. I figured monthly meeting was not enough contact time with the customers so I visited their office (with permission from BHA) and discussed in detail, the changes they will like to make. The customers of the HVDC project were quite hands-on and contributed to the mechanical design of the project. However, with so many specifications change the project were delayed by several months. After having an internal company meeting, we concluded we won’t be accepting any further specification changes unless the customers are willing to pay for it and accept the time delay. When dealing with customers you cannot outright reject their request, things will get sour very quickly. However, if you tell them it will cost more money and will delay the project further, they usually stop tampering with the specification unless it’s something critical.
At the start of the placement, Alan kept a close eye on me. He would regularly come and check how I was managing and if I needed any assistance. However, over time I got less supervision from Alan. I think it can be broken down in 3 stages. Stage 0: At the start Alan would explain what the task is in great details, breaking it down to its components and would show me where to start on the task. He would come and check up on me once a day, however, I would usually just report back to Alan upon completing the task. At the time I don’t think I made that many decisions on my own accord. I just followed by Alan’s examples. Stage 1: few months in my placement I started my own decisions. I had my own way of writing software mostly techniques learn from the university. I became more independent and was able to get on with the task on my own. I also became more involved during internal and external meetings; I would take over speaking when it came to my part of the project.
The last stage was achieved in the last 6 months of work. I felt like an employee, not just a trainee. My presence in meetings was required because Alan did not know in enough details what I am working on. What I had to say could potentially alter the specification and Mike who was working on the HVDC Handle firmware treated me as a fellow engineer rather than a trainee engineer.