During my second year at the University of York studying electronic and computer engineering, I was tasked with a group project for designing, constructing and testing a digital multimeter utilising in-house components found in the university laboratories. This project aimed to enable the application of theoretical knowledge learnt during lectures, providing students with hands-on experience. This article reports on the progress of this project and my experiences as the elected project manager.
As I’m formatting this document to place on my website from the original report that I submitted to the department, I felt the need to include this postscript. From my current (4th-year) knowledge, I can think of countless ways of improvements that this project could’ve benefitted from. It shows vast intellectual progression from when I carried out this project to now, around 2-years later. I am very proud of this aspect, and I’m glad I carried out the project the way I did since I wouldn’t have learnt anything had I not made mistakes.
Our aim was to design and construct a digital multimeter utilising the in-house development system board and the electronic components available in the laboratory, with the STM32F4 Discovery Board’s ARM Cortex-M4 microcontroller at the heart of the entire project. As a team, we decided to prioritise simplicity and ease of use, with our multimeter performing only the fundamental functions that is needed from a digital multimeter, but what sets ours apart is the fact that it will be fully open source in both the hardware and the software, and it will be designed with headroom for extra features that the end user can add at their own will.
To support the idea of modularity and the quality of being open source, the product has to be designed in a very specific way. The chassis has to be large enough to hold the fundamental infrastructure, with the ‘production-ready’ version of the in-house development system board, and any additional user-added circuitry and functionality.
Figure 1: Orthogonal projection drawing of the final product
I have drawn the production prototype construction of the product in the form of an orthogonal projection shown in Figure 1. The front panel of the product will consist of screw-holes in each corner, allowing the user to remove it to work on the internal circuitry. This panel consists of an LCD, which can also be unscrewed, removed, and replaced, as well as an empty panel which can also be unscrewed, removed, and replaced with additional displays or dials. And at the bottom are the two buttons passed through from the Discovery Board, the reset and mode select button.
The Discovery Board can be programmed using the USB port and the whole board can be powered using the barrel connector, both found at the top side of the product. Again, there is more removable panels which the user can remove and replace with something else such as additional input/output ports in this case. The power supply will be provided with the product and will be situated externally, this will be done to increase the safety of the product so that mains voltages are completely isolated. The power supply will be plugged into mains voltages, and will output +20V, -20V and ground to the product.
The bottom side consists of rubber feet in case the user wants to sit the product vertically upright, as well as the probe inputs, and cooling holes to help with air circulation. The right side of the product consists of more cooling holes, but these are designed specifically for small cooling fans. The fans will not be included out of the box as none of the components will get too hot, however, as this product will be open source, the user will be able to add extra circuitry which may require cooling. These perforated cooling fan panels will be removable as well, in case the user wants to add things such as controls, displays, input/outputs, etc.
On the left side of the product, there will be another removable panel which the user can repurpose, also there will be a GPIO pass through from the Discovery Board. Passing through the GPIO pins can be extremely powerful as the inputs and outputs to and from the ARM Cortex-M4 are being exposed. The bottom of this product will simply have two rubberised feet, so that the user can lay the product down, as well as another large panel which the user could use to access the internals from the bottom of the product.
The dimensions of the product have not been finalised, however as a team we do understand that it cannot be too big. I think that the best size would be a 11-inch diameter for the front panel, and a 2.5-inch product thickness. This will not only be enough to hold the ‘production’ version of the circuitry, but it also leaves more than enough space for the user to add additional circuitry. The best way to find the sweet-spot for size is by producing prototypes of different form-factors and testing it.
The project will be very modular as well as open source in both the hardware and software side. The hardware will be developed in such a way that the user will have the headroom to carry out any upgrades on the design, whether that’s adding extra features or improving the already existing ones. The hardware’s voltage inputs will be rated to ±10V, the input current will be rated to ±100mV and the load resistance input will be rated to between 1Ω and 1MΩ. These input ranges are lower than most traditional digital multimeters, however, this decision in input range reduction was done with our target audience in mind.
We think that this product will be a crucial asset to our planned target audiences, hobbyists, and students. The open source and modular nature of this project will create a playground environment for hobbyists, with scope to add additional functionality as well as improve existing ones, hobbyists can happily spend hours with our product. With the lower input ranges, the hardware inside our multimeter can be much simpler, as it’s made to only work with smaller and harmless voltages. This allows our product to provide a safe and beginner friendly environment for students to learn about the fundamentals of electronic and electrical engineering. And once our clients have learnt about the fundamentals, perhaps increasing the input ranges accurately and safely could be a potential project with our product.
For a beginner, this product might be slightly challenging, and, for a younger beginner, this product might not be suitable. We’ve chosen the minimum age rating of the target audience to be 16 for this product. At the age of 16, the client should have enough theoretical knowledge on mathematics and physics to not only be able to understand how to use the multimeter, but also be able to research how the multimeter works with the help of the internet. We have not limited the maximum age rating of this product, as we think that you can never be too old to learn. Aside from the potential complexity factor of the product, the hardware will be designed in a way where all voltages will be small enough to be harmless, therefore the product is safe to be open to all ages.
Some aspects of this project will be quite highly complex, as not only is the hardware being developed, but the software is being developed too, and at the completion of both sides, they need to be bridged together. For increased efficiency, I have decided to split my team into two parts initially, hardware engineers and software engineers. At the start of the project, the hardware team will design, prototype each individual functionality of the multimeter (i.e., voltmeter, ammeter, and ohmmeter), and the software team will progress through the provided lab scripts which should hopefully give them a foundation to programming the ARM Cortex-M4 microprocessor. I think an agile approach will be quite beneficial, with the project split into parts, each part will be designed, prototyped then tested, we will be able to spot issues and debug much earlier which saves a lot of time, not only this, but the team will also experience bursts of encouragement throughout the course of the project as a result of successful sprints, with each individual part of the project working as intended.
| Week # | Software Team | Hardware Team | Bridging |
|---|---|---|---|
| 1 | Work on Lab 0 – Introduction to STM32, C programming | Create voltmeter, ammeter, ohmmeter circuits’ draft #1. | Hardware and software teams share their progress. |
| 2 | Work on Lab 1 – Introduction to uVision IDE | Test the draft #1 of all circuits. | Hardware and software teams share their progress. |
| 3 | Work on Lab 2 – Working with GPIOs | Optimise draft #1 and create draft #2. | Hardware and software teams share their progress. |
| 4 | Work on Lab 3 – ADCs, timers, interrupts, and the LCD | Test the draft #2 of all circuits. | Hardware and software teams share their progress. |
| 5 | Based on the specifications, the first draft of the code can commence development. First for DC voltages | Optimise draft #2 and create draft #3. Make a detailed specification sheet of the hardware to help the software team write the code. | Hardware and software teams share their progress. The hardware team go through all the hardware specifications with the software team. |
| 6 | Test DC voltmeter code and commence work on the ammeter and ohmmeter code. | Test the draft #3 of all circuits. | Hardware and software teams share their progress. Hardware team helps software team with any doubts in the specification. |
| 7 | Test the ammeter and ohmmeter code. | Optimise draft #3 and create final draft #4, making sure hardware follows the proposed specifications. | Hardware and software teams share their progress. Hardware team helps software team with any doubts in the specification. |
| 8 | Work on AC voltmeter code. | Build the final draft (#4) on the breadboard. | Hardware and software teams share their progress. Hardware team helps software team with any doubts in the specification. |
| 9 | Test the whole code without the hardware (using external variable power supplies) | Finish building the final draft (#4) on the breadboard. And test without software (with external variable power supplies). | Prepare the team for the bridging process (when hardware and software are merged). |
| 10 | Test the whole code with the hardware prototype. | Test the breadboard prototype with the software. | Bridge the hardware and software, debug and fix any issues that arise on the way. |
Table 1: A week-by-week work breakdown for hardware & software.
Above in Table 1, a work breakdown that I made for the team is shown but only for the hardware and software teams. In addition to the work specified above, some of the human resources, few from the hardware team and a few from the software team will form an additional team just for testing. They will receive the built prototype of the draft which they will then test to provide feedback of the testing to their respective teams. Furthermore, we have a team that manages marketing and sustainability, they will work with the hardware and software team at each step to make sure that the product fulfils sustainability targets as well as to learn about the features of the product to help with marketing it.
As previously stated, we will implement lower input ranges to make sure the product will be safe to all ages as well as all levels of experience with the world of electronics. The voltmeter functionality will work with both AC and DC signals, it will work with inputs in the range of ±10V, at a theoretical accuracy of ±0.5V. AC signals between 100Hz and 10kHz, the RMS and frequency will be displayed, and at higher frequencies up to 1MHz, only frequency will be displayed on to the LCD. Apart from the 10V range which will measure voltages in the aforementioned input range, there will also be a 100mV range which will measure signals between ±100mV at a theoretical accuracy of ±5mV. For the ammeter functionality of the multimeter, there will only be a single range measuring inputs between ±100mV at a theoretical accuracy of ±4.9mA. And finally for the ohmmeter functionality of the multimeter, it will be able to measure load resistances between 1Ω and 1MΩ at a theoretical accuracy of ±1kΩ. The theoretical accuracies stated above are only for the hardware implementation itself. The total accuracy can be drastically improved via the code with the use of some input/output mapping offsets.
I have designed the voltmeter hardware to utilise two probes, a positive and a common, to measure the voltages. The signal from each probe will go through a voltage buffer stage using the TL07x op-amp (this op-amp is used throughout the product, in the TL071, TL072 and TL074 forms) to massively increase the input impedance. These signals will then be passed into a differential amplifier which will take the difference of the two signals and amplify them. For the 10V range, a gain of 1 is set, however in the 100mV range, a gain of 100 is set. The output from the differential amplifier stage is then passed through a pull-up resistor configuration. The main aim of this is to shift the voltages from the ±10V range to the 0V to 3V range, which can be safely read by the ADC. This pull-up resistor configuration also houses a 3.6V Zener diode which acts as a form of protection against over-voltages for the ADC, as its maximum voltage input is in fact 3.6V.
Figure 2: LTSpice schematic of the voltmeter circuitry
Figure 3: Simulated voltmeter circuit output (10V range)
Figure 4: Simulated voltmeter circuit output (100mV range)
Shown in Figure 2 is the schematic of the voltmeter circuitry that I simulated in LTSpice. If the input voltages were to ever exceed 10V, the Zener diode will automatically ground the signal as soon as it exceeds 3.6V, protecting the ADCs from any form of damage. The results of my simulations are shown in Figure 3 and 4, the results show the input vs output graph.
As I expected, the graphs show a linear line until the 10V/100mV input threshold exceeds, and when that happens, the output voltage gets clamped to 3.6V. We can see a slight offset, when the input voltage reaches 10V or 100mV, the output should be exactly 3V in an ideal condition, however, with our circuit we see an output of around 3.15V. Aside from the noise we encounter from the op-amps, the 0.15V offset is mainly due to the pull-up resistor configuration with the Zener diode. This offset can be easily patched inside of the code, doing so will drastically improve accuracy, albeit reduce the total usable input range slightly.
As mentioned already, this circuit will also work with AC signals. The slew-rate of the TL07x family of op-amps is 16V/μS, which will be more than enough to process 20V peak-to-peak signals up to our specified 10kHz, and more than enough to process small 1V peak-to-peak signals up to 1MHz. The code will have to be written to sample the input AC waveform at a frequency higher than or equal to at least twice the input’s frequency to follow the Nyquist-Shannon sampling theorem.
My design for the ammeter circuitry is quite simple. Two probes will be used, a positive and a negative, where the negative probe is grounded. The positive line will be connected to a 1Ω shunt resistor in series with ground. As current flows through the shunt resistor, it will induce a potential difference, this signal is amplified by a non-inverting amplifier with a gain of 100 and then the output signal is passed through the same pull-up resistor and Zener diode configuration as I’ve mentioned in the voltmeter hardware.
Figure 5: LTSpice schematic of the ammeter circuitry
Figure 6: Simulated ammeter circuit output
As the ammeter is only rated for an input range of ±100mA, passing that through a 1Ω resistor would result in an induced voltage within the range of ±100mV. A gain of 100 was chosen for the amplifier stage to increase the voltage to fit in the ±10V range so that it could be passed into the same pull-up resistor and Zener diode configuration as the one used in the voltmeter hardware. We are using the same TL07x family of op-amps, meaning that the slew-rate will be sufficient for AC signals here too. The ammeter circuitry has been designed with only 1 range, the output for this is shown in Figure 6. As we’ve seen before for the voltmeter circuitry, I have simulated what would happen if the user were to input more current than the 100mA limit, and what we can see is the Zener diode clamping the maximum voltage to the ADC’s safe maximum value of 3.6V. Unfortunately, just like the voltmeter circuitry, we see a slight offset which reduces the accuracy of the measurement. However, this can be simply fixed in code.
When I was in the initial stages of designing this circuitry, I knew I had two options, a fixed voltage source driving a potential divider with one known resistance and an unknown resistance, or a fixed current source inducing a potential difference through the unknown load resistance. I disregarded the first option as this would result in the ADC trying to parse a very non-linear input. So, I initially designed an ohmmeter circuit using a current mirror, but I was very upset with its performance within simulation. The current output was not exact, and it fluctuated as the load resistance changed. I then researched IC solutions to generate a fixed current source. The requirement for the ohmmeter is to measure resistances from 1Ω to 1MΩ. To do this I would need a 1μA current source, allowing a potential difference in the range of 0V to 1V to be induced across the unknown load resistor. I concluded that the LM334 IC would be best suited for this.
Figure 7: LTSpice schematic of the ammeter circuitry
Figure 8: Simulated ohmmeter circuit output
Figure 9: LM334 zero tempco current source
The LM334 was perfect for this as it can be programmable to output a current from as small as 1μA. By referring to this IC’s datasheet, I was able to construct a zero temperature-coefficient current source. Essentially, by adding a diode and resistor to the standard configuration with the R_SET resistor can cancel the temperature dependant characteristics of the IC, allowing for a more stable current source. The current source circuit that I built is shown in Figure 9, I had to initially build this circuit in isolation to test the various resistor values, from the calculations that was shown in the IC’s datasheet, I had derived that R_1 was 153.2kΩ and R_2 was 1.2MΩ. However, this circuit was outputting only around 0.68μA. I had to use trial and error to finally reach a stable and exact output of 1μA, which I was able to get with R_1 set to 91kΩ and R_2 set to 1.2MΩ.
Shown in Figure 7 is the schematic of the entire circuitry that I designed, unfortunately as the LM334 model was not in LTSpice, I had to replace it with an ideal current source. Due to the current source and with the aforementioned resistance ranges, there will be a 0V to 1V signal induced, this is then amplified by a non-inverting amplifier with a gain set to 3, this is then passed to the ADC with a 3.6V Zener diode branching it to ground. And as the simulated results in Figure 8 shows, if the user inputs a resistance higher than the specified range, then the voltage output gets clamped to 3.6V, protecting the ADC.
There is a total of 4 outputs from the entire hardware circuitry, 2 outputs from the voltmeter (10V range and 100mV range), 1 output from the ammeter and 1 from the ohmmeter. I have designed a system that requires the use of 2 ADCs, the 10V range voltmeter output, the ammeter and ohmmeter outputs will all be multiplexed and outputted to ADC1. The 100mV range voltmeter output will be directly connected to ADC2.
Figure 10: Multiplexer configuration
Shown in Figure 10 is the configuration which I have planned. I will be using the DG409 4 channel mux to multiplex 3 signals into a single output signal. 2 GPIO pins will be needed to select the mux inputs. My plan for the code is, when voltmeter mode is selected, ‘00’ will be outputted from the GPIOs to the mux select pins, the code will parse the signal from ADC1, if it’s between ±100mV, then the data from ADC2 will be parsed and then displayed on to the LCD, else it will display the parsed data from ADC1. In ammeter or ohmmeter mode, the GPIOs will output either ‘01’ or ‘10’, and the data from ADC1 will be parsed and displayed, ADC2 will not be used for anything apart from reading the 100mV voltmeter range.
In AC and DC voltmeter mode, the input into ADC1 is read first then the real input voltage (the signal that the user has inputted into the multimeter) is calculated. If this signal is outside of the ±100mV range, then the calculated voltage from ADC1 is displayed, if the signal is within ±100mV, ADC2 is then made to read and calculate the signal, and the output from this is displayed on to the LCD. In DC mode the amplitude of the signal is displayed, in AC mode for signals below 10kHz, the RMS and frequency is displayed, for frequencies higher up to 1MHz, just the frequency will be displayed. Below is the mathematical equation which will be used in code to convert ADC1’s read voltage to the actual input voltage into the digital multimeter (DMM):
Below is another equation which maps ADC2’s input to the actual voltage being input to the DMM:
For the ammeter, we only need to read from ADC1, therefore, the GPIOs need to select input 2 of the mux, and the following equation is used in code to convert the data read from ADC1 to the actual current being input into the DMM:
And finally for the ohmmeter, this works in a similar way to the ammeter. Input 3 is selected on the mux, and the following equation is used in code to convert ADC1’s measured voltage to the resistance being input to the DMM:
I have written a document named ‘Software Plan’ which acts as a sort of specification document which will help the software team write the code that implements the hardware that I have developed. This document is extremely detailed, and it includes not only these equations mentioned above, but also snippets of pseudocode outlining how the ADCs need to be used to measure the signals, how an offset can be implemented to make the measured values more accurate, how the data will be displayed to the LCD to form a sort of GUI, etc. This will be very challenging to succinctly include within this report due to the length, however, I will try to do so in one of the following sections.
Each circuit was first built on a breadboard and was tested. First, I built the voltmeter circuitry implementing both of the ranges, I used the lab-bench power supply to input 20V, -20V and ground then I used the signal generator to input a signal between ±10V. I measured the output with the lab-bench DMM. I made sure to test both the ranges, and when I was happy with the results, I built the circuit on to the final prototype breadboard. The same was done with the ammeter circuitry and ohmmeter circuitry.
Figure 11: Product prototype board
The final prototype consists of a 3 breadboard stack, the first breadboard row consists of the power supply, which takes in the aforementioned signals from the lab-bench power supply and outputs 3.3V, 5V and 0.8V, the 0.8V and 5V outputs were mainly designed for the current mirror but as I changed the design to implement the IC at the last minute, these voltage outputs still exists. The first row also consists of a TL074 which is used as a voltage buffer for the voltage sources as well as the voltmeter probe inputs. The second row consists of the main voltmeter circuitry, the differential amplifier as well as the pull-up resistor and Zener configuration, the ammeter circuitry with its non-inverting amplifier and pull-up resistor and Zener configuration and finally the ohmmeter circuitry with its zero tempco current source and non-inverting amplifier. The bottom row simply consists of the DG409 multiplexer, the outputs from the voltmeter, ammeter and ohmmeter gets brought here and 2 outputs are fed to the Discovery Board’s ADCs and 2 inputs are brought from the Discovery Board’s GPIOs. During testing, I noticed that the Zener diode protection didn’t work, with inputs outside of the specified range, the output to the ADC exceeded the safe 3.6V threshold, not only this but the Zener diode also caused a decrease in accuracy. To overcome this, I used a MCP6002 op-amp, placed next to the mux, powered by the 3.3V regulator and built a voltage buffer for the two outputs that were going to be fed to ADC1 and ADC2, I then removed the Zener diodes. After this, the output voltage never exceeded 3.3V in testing and the accuracy was increased. Due to this being a last-minute change, Figure 11 hasn’t been updated to show the MCP6002.
To be as blunt as possible, I am not proud of this prototype that I have built, shown in Figure 11. It looks extremely messy, and there are quite a few unnecessary components like the 5V regulator, 0.8V source. It was the first time I’ve ever built a circuit as complex as this, with multiple breadboard and single core wire instead of jumper-cables. By getting rid of the unused components, and by following a more structured breadboard building technique, I could’ve reduced the total footprint of this prototype so that it only uses 1 or at most 2 breadboards. But I am happy with this as it does accomplish the tasks of a prototype and it works as intended.
Following on from when I previously mentioned the ‘Software Plan’ that I wrote, I started that document by describing the initialisation screen, a simple UI that switched between two LCD outputs. I did include some pseudocode within the document which describes how it can be programmed using the sleep() method and the write_to_lcd() method. I created these LCD display output images using a website that I found on the internet [1].
Within this document, I then mentioned how to implement the mode switching, where the user can switch between the different modes, AC/DC voltmeter, ammeter and ohmmeter using the pushbutton. I also wrote some pseudocode of a case statement for this. The next thing I wrote about was how to implement the DC voltmeter functionality, I started with the need to output a signal to the mux via the GPIOs, then to set up a timer which runs at 50kHz and triggers the ADCs. I then went on to describe using pseudocode how the ADCs need to measure a cumulative average of the inputted signals and how they need to switch between the 10V and 100mV ranges.
Not only this, but I also mentioned how to set the refresh rate of the LCD so that it doesn’t glitch due to the rapid 50kHz timer. I also mentioned how to implement a voltage offset which can be tweaked during the final testing phase to increase the accuracy of the measured signals. I also described how measuring current and resistances are done in the same way as the DC voltage, except for the different GPIO outputs and the mathematical formulas, I also included pseudocode showing the slight variations of the different modes.
Finally, although not written in the ‘Software Plan’ document, I did have a meeting with the software team leader to discuss how we could measure and display AC voltage signals. We initially decided to increase the timer from 50kHz to 5MHz, I did mention that this will be very hard to get right as we need to prioritise efficiency.
| Range | Input / (V) | Expected Output / (V) | Measured Output / (V) | Delta / (V) |
| 10V | -10 | 0.0 | 0.0016 | 0.0016 |
| 10V | 0 | 1.5 | 1.5607 | 0.0607 |
| 10V | 10 | 3.0 | 3.0239 | 0.0239 |
| 10V | 15 | 3.3 | 3.2818 | -0.0182 |
| 100mV | -100m | 0.0 | 0.0252 | 0.0252 |
| 100mV | 0 | 1.5 | 1.5886 | 0.0886 |
| 100mV | 100m | 3.0 | 3.1560 | 0.1560 |
| 100mV | 200m | 3.3 | 3.2966 | 0.0034 |
Table 2: Voltmeter hardware testing
Overall, I think there is quite a bit of discrepancy between the expected and the measured outputs. This will affect the accuracy of the final calculated measurements; however, we can minimise this affect via code. But the hardware could’ve been made better to minimise the inaccuracies by using more ranges. As mentioned in one of the previous sections, during these tests I noticed that the Zener diode was not working as intended, I reworked the over-voltage protection feature, replacing all the Zener diodes with a single MCP6002 powered with 3.3V acting as a voltage buffer.
| Input / (Ω) | Expected Output / (V) | Measured Output / (V) | Delta / (V) |
| 0 | 3.3 | 3.2962 | 0.0038 |
| 510k | 1.5285 | 1.5575 | -0.0290 |
| 1M | 3.0 | 3.0083 | 0.0083 |
| 1.5M | 3.3 | 3.2969 | 0.0031 |
Table 3: Ohmmeter hardware testing
Next, I tested the ohmmeter circuitry of the project, the results are shown in Table 3. I simply attached a test resistance to the multimeter and measured the output using the lab-bench DMM. The mux was also tested in both this test and the voltmeter test as I had to select the output by simulating the GPIO pin outputs using jumper cables. The deltas here were much smaller than the voltmeter ones, however, as we are using a single range, smaller output voltage variations could result in large measurement discrepancies.
Unfortunately, as I had to work on software, I had to offload the ammeter and AC voltmeter testing to the testing team this time, however they found it really difficult to construct a constant current source to connect to the ammeter to test the product. Due to this roadblock, we didn’t have time to test both the ammeter and the AC side of the voltmeter. To test the ammeter, an external circuit has to be built which acts as a current source, it needs to be attached to the multimeter. The output needs to be measured by setting the right select bits on the mux and by reading the output using a lab-bench DMM. An LM337 needs to be used here as we need to test up to 200mA. For AC voltmeter testing, the signal generator needs to output a 20V peak-to-peak signal centred at 0V. The output needs to be read from the mux with the right select bits, an oscilloscope should be used to measure the output, and this should be similar to the input, but with a 3V peak-to-peak centred at 1.5V.
During these tests, I noticed that the multiplexor started to get very hot to the touch. It was quite surprising as I was within specification with my ±20V dual rail power supply. I went over the circuitry, and I concluded that I could reduce the power supply to ±15V. This resulted in the product consuming less power and the components to not over-heat, making it more efficient as a whole. I could’ve reduced the power supply to just ±10V as this is the maximum voltage the op-amps need to not saturate, unfortunately, the TL07x are not rail-to-rail.
I am quite happy with the planned user interfacing of the product, a simple button interface to switch between the modes and a simple GUI to display the measurements on to the LCD display. Thinking back at it now, there are many different ways I could’ve designed the hardware of this product, perhaps implementing an instrumentational IC for the voltmeter, and allowing it to have a gain which is settable with a multiplexer and interfacing that with the GPIOs, so that the ammeter and ohmmeter can reuse the same in-amp used for the voltmeter but with a different gain set. Not only would this have reduced the overall footprint of the product’s circuitry, but it would’ve also reduced the power consumption as well as would’ve increased the accuracy at which it measures at. Furthermore, based on testing I could clearly see quite a large discrepancy over the experimental measured signal and the theoretical measured signal, shows quite a drastic inaccuracy. This can be somewhat fixed by using more ranges for the different measuring circuitry. Additionally, the pull-up resistor configuration causes a slight shift in the output accuracy due to the resistor tolerances. This part of the circuitry needs to be reworked in the future. The prototype needs more thorough testing, especially with the AC voltmeter. I really do feel upset with the fact that the current product has not been tested well enough, but I really felt as though I was drowning with the workload of this project due to the fact that the teams of people that I delegated tasks to were not completing them. We also need to work on software. Unfortunately, our software team really struggled with the complexity of this project, resulting in the progress of code completion to be extremely slow.
At the first milestone of this product, which is manufacturing it at its ‘production-ready’ state, I intend on the actual product to be injection-moulded. As the filament used for injection-moulding is normally plastic, we can minimise the amount of plastic waste by using an eco-friendly, biodegradable filament such as PLA, which is corn-starch based. With the chassis of the product injection-moulded, we don’t need to worry about gluing panels together like we have to if we use a 3D printer, as sometimes 3D printing horizontally and elevated from the printing bed can be very difficult and would need temporary supports to prevent the print from slanting.
Due to the modular nature of the product, ‘production-ready’ hardware will feature multiple printed circuit boards, one acting as the STM32F4 Discovery Board’s motherboard, one for the voltmeter, one for the ammeter, one for the ohmmeter, one for the buttons and one for the probe input ports. These separate PCBs will be linked together with small single core wires, due to this, there may be quite a lot of offcuts due to cutting the wire to size. These offcuts can be recycled, the core can be melted and remade into Phillips-head screws, and the insulation can be ground into a powder and formed into 3D printing filament, perhaps it could be blended with the PLA to create a stronger plastic-based alloy.
All of the components will be soldered on to the PCB using lead-free solder. We will offload the PCB manufacturing to a company that has a lower carbon footprint and recycles materials such as fibreglass and metals. Manufacturing PCBs following the IPC standard is a good way to ensure that the product is made to a good standard, in terms of both output standards when the product is working and when it’s at its end of life. This standard dictates the maximum amount of chemicals that can be disregarded into the environment, chemicals such as the ones used to get rid of the residues during the process of making a PCB, when fiberglass or plastic sheets are layered with industrial-grade epoxies, also the chemicals used when soldering, whether it is in the solder or in the flux used. This coincides with the RoHS Directive, restricts the use of certain hazardous substances which can be substituted with safer alternatives. From the datasheets of all the components that we are using for our product, we can confirm that it is all RoHS compliant. This can help prevent the risks which may affect the end-users or the environment, due to the waste at the end of the product’s life cycle.
At the end of this product’s lifecycle, many of its parts can be repurposed for other electronic projects. The modularity will allow for the circuitry to be taken apart and reused as well as the housing itself. But in case it is thrown away, the PLA housing will biodegrade. Luckily the WEEE, EU’s regulations on handling electrical waste, still applies to us (post-Brexit UK), the circuitry will have to be disposed correctly so that it doesn’t end up in landfill and so that it follows the WEEE regulations, the working components can be extracted and repurposed for other electrical devices, and the metals can be recycled. The other more toxic substances will have to be disposed safely if they cannot be recycled.
With the modularity of the construction of this product, we are promoting the ‘right-to-repair’ movement, with the easy to dismantle housing, due to the use of very common Phillips-head screws, and with the fact that each PCB in the product being easily accessible to be replaced if something fails. As this product will be open source, we plan on releasing circuit diagrams as well as the source code on to public domain. The product will not feature any components that are glued down, they will all be screwed instead. Not only does this reduce the usage of chemicals, but it also makes the product designed for disassembly, this ideology makes sense for our product as we aren’t trying to make it as small as possible.
With 91% of students saying their place of study should actively incorporate and promote sustainable product, 84% saying sustainable development should be actively promoted in their courses and 66% saying sustainable development is something they’d like to learn about, based on the Sustainability Skills Survey 2020-21 [2], our product will be incredibly popular and useful for places of studies. Based on the Sustainability University League Tables [3], the University of York ranks 93rd out of 154 universities, given its sustainability score of 36.9%, only scoring 37.5% in the ‘Waste and Recycling’ section. Not only can the quality of education be drastically improved by implementing project-based teaching with products such as ours, but universities can also score much higher in sustainability, environmental and ethical performance comparisons. This will improve the quality of our planet as well as shape the future cohorts to take environmental and ethical situations more seriously. By following the various standards and regulations for electronics, this product will be fulfilling many of the ‘Sustainable Development Goals’ formed by the United Nations [4]. We’ll be fulfilling quality education, responsible consumption, and production as well as climate action with our sustainable product both during its lifecycle, after and before it too.
Unfortunately, our current product prototype is slightly far from reaching completion, with software being still fairly uncompleted. Although once software reaches completion and hardware has been fully tested, we can work to increase the accuracy of the product with another better constructed breadboard prototype, without any unnecessary components and taking up a smaller physical footprint. This project has taught me a lot, from understanding the basic theories of electronics better, all the way to reading datasheets and building large and more complex electronic circuits. It has been a fun experience working as a team, and being the team leader, although I couldn’t quite practice making things like Gantt charts and Work Breakdown Structures, I have learnt a lot with the aspects of making sure the teammates’ morale are high and making sure everyone is in sync. I just hope that my teammates also found this experience as useful as I did, and I hope our progress did in fact improve their understanding of the fundamentals of electronic and electrical engineering.
[1] A. Avtanski, “LCD/LED Screenshot Generator,” 2022. [Online]. Available: http://avtanski.net/projects/lcd/.
[2] Students Organising For Sustainability, “Sustainability Skills Survey - Research SOS-UK,” 2020. [Online]. Available: https://www.sos-uk.org/research/sustainability-skills-survey.
[3] People & Planet, “2021 People & Planet University League,” 2021. [Online]. Available: https://peopleandplanet.org/university-league.
[4] The United Nations, “Take Action for the Sustainable Development Goals,” 2015. [Online]. Available: https://www.un.org/sustainabledevelopment/sustainable-development-goals/.