diff --git a/README.md b/README.md index 0ce9b164f2c2fd56d69c16513e56ffaaabeadbcc..872c7e2df7679300174b7237efa94e14709e75fa 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ - natnik-9@student.ltu.se ## High level specification -- FM AM radio anntenna +- FM/AM radio anntenna - Speaker - Dimmable light - OLED Display @@ -32,7 +32,7 @@ - Nathanael - Expected contributions towards grade 4 - Basic functions for alarm clock include: - * Radio, evt. Buzz + * Radio, evt. Buzz/Vibration * Working clock on OLED Display - Expected contributions towards grade 5 - Extras: @@ -43,24 +43,29 @@ ## What whent right/wrong For the most part the issues were in hardware and not in the software, -even though we first thought it was in software but after testing connections with a multimeter and oscilloscopes it is clear that hardware is copable most of the problem. -For example one problem we have is that when we set some of the pins to high they do not get set to high on the target board but it does on the devkit(both the buzzer and the led), +even though we first thought it was in software but after testing connections with a multimeter and oscilloscopes it is clear, that hardware is responsible for most of the problems. +For example one problem we faced is that when we set some of the pins to high, they do not get set to high on the target board but it does on the devkit (both the buzzer and the LED), while others pins get set as intended. -There are several reasons why this might be. Firstly we soldered the pcb 3 times to get all of the resistors, capatitors and other parts on there, which could have damaged the pcb as it's not a very expensive pcb, and since we soldered the chip on first, the multibe pcb soldering might have damaged the chip. -Secondly there where some componets that where wired incorrectly during the PCB-Design phase, most notable the button which caused some confusion. -Thirdly we did not store the pcb in a esd bag which could have damaged the chip. +There are several reasons why this might be. Firstly we soldered the PCB three times to get all of the resistors, capatitors and other parts on there, which could have damaged the PCB as it's not a very expensive PCB, and since we soldered the chip on first, the multiple PCB soldering might have damaged the chip. +Secondly there were some componets that were wired incorrectly during the PCB-Design phase, most notable the button which caused some confusion. We tried resoldering a new button (which in theory should work), but failed to extract the old button without damaging the board significantly. The repair process includes work to which we need access to other tools than currently available. +Thirdly we did not store the PCB correctly in a ESD bag which could have damaged the chip and contributed to unwanted behaviour. -On the software side most of the problems was caused by not having prior knowlage of rust and rtic, but after some time and effort it seems like we solved all of the issues. +On the software side, most of the problems were caused by not having prior knowlege of Rust and Rtic, but after some time and effort it seems like we solved all of the issues. - What we would do different next time * Double check that all of the compenets are wired correctly - * Add more test pads, and power lights to help debug the hardware - * Solder the pcb board fewer times - * Store the pcb in a esd bag and add some bubble wrap or other padding to minimize damage to the board - * Use less material when hand soldering parts to avoid shorting and making it easier to dissasemble if something goes wrong during assembly. + * Ask a more experienced person if the PCB design and footprints are correct and expected to work + * Add more test pads and power lights to help debug the hardware + * Try to solder/cook the PCB board a few times less + * Correctly store the PCB in a ESD bag and add some bubble wrap or other padding to minimize the risk for damage to the board + * Use less material (eg. soldering balls) when hand soldering parts to avoid shorting the circuit and making it easier to dissasemble if something goes wrong during assembly. -## [Video]( https://youtu.be/O3TuSXGsFAg) -Due to the unfortunate problems with the hardware stated above we will showcase the software on the dev kit instead. +## [Video]( https://youtu.be/O3TuSXGsFAg) (lower the Volume before watching) +Due to the unfortunate problems with the hardware stated above we will showcase the software on the software development kit (SDK) instead. As seen in the Video, the internal clock does now work correctly and triggers an alarm at a desired time of day. The button allows to turn the (annoying) alarm off. +## Summary +Overall, we are very pleased with what the project has taught us. The subject is extremely complex and with the guidance received, we were able to esablish a ground for what would be needed for extending the functionality of the alarm clock. The theoretical part about software (programming in Rust) was eye opening on why we should develop our skills in this particular language and will have a good time doing so. Also seeing how someone can solder and have a steady hand, with experience, was a joy to watch. We would really be satisfied if the MCU did not struggle to work in the last instance and would have to, unfortunately, redo the soldering (if not even begin from the design) part of the project, to then consider building a functioning case and make the optional parts work as well (OLED display, Radio, Dimmable lamp and more). This could be a fun project to realize, because the fully working clock would be a usable one on the nightstand. + +Since we did not fulfill the requirements for grade 5 or 4, our assessment would be grade 3, because the basic clock is functional. \ No newline at end of file