Development Over Time

Testing Waters

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.[1][2]. 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.

Stage 0 – Using University Skills 

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.

Stage 1 – Showing What I Know

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

Stage 2 – Working on a paid project

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 [4]. 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.

Stage 3 – Overcoming major problems in projects

“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).

Stage 4 – Part of a large project

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].

UI (User Interface) – Feel over functional

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.

Making my own decisions

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.