Project Journal for Amir Mokhtarpour
=============== Week 15: =================
Entry 5: -----------------------------------------------------------------
Date: Friday April 25thStart Time: 11 AM
Duration: 2 hours
there was some current limitation issue we tried to increase the voltage on the boost converter but it didn't help the motor wouldn't have enough toruqe to rotate the pegs after a certain point but this was perfectly enough for tuning. we put the voltage back to 5v and the current as max as possible. demoed the project and everything was working fine.
Entry 4: -----------------------------------------------------------------
Date: Thursday April 24th - Friday April 25thStart Time: 10:30 PM
Duration: 8:30 hours
after coming back to the lab I wanted to solder a 3.3v LDO Katis found but I thought to my self the MCU don't required too much current so whu would the VSYS fail so this made me think the issue is not current or the current limit is really low. so I decided to find the issue with the booster because if it get to work with the booster the buck will work too. I connected the boost converter to the power supply to see what is the current draw from the converter which was 15mA (because the stepper motor was not connected)
Next I connected a 4v power supply to imitate the battery, and rule out if the battery current is not enough, even with the 4v power supply the over current protection still jumpped in but When the USB is connected the boost would work.
At this point i thought the issue might be a soldering issue or a faulty charger IC. just before taking out the charger with the added resistor, I realized that one hair thick strand of wire was came off so the current set was floating and any small amount of current would cause the charger to go into over current protection. after soldering the wire back to the pad I connected the booster and it worked just fine!
But now the motor drive was on all the time, getting 1A constantly. so I wanted to make 4 cells of a lipo in parallel I took out the cells of a 4 cells LiPo battery:
One of them was inflated:
just when I wanted to solder them together I relized that I might be able to controller the boost converter from one of the test points we put on the MCU. I connected a wire to the Enable pin of the 5V boost converter and TP10:
Which was connected to Pin C7:
Then I added the enable pin toggle before and after the motor move and you can see that the booster turns on only when the C7 pin is high:
Next I connected the VSYS to the buck converter and measured the voltage with and without the motor load which was perfectly stable:
Labeled the buck boost converter:
checked the voltage on the buck converter and it was 3.3V and here is First standalone (not from programmer) power up:
Connected the USB charger to check it is being charged:
And the battery is indeed being charged:
I also tested that it can still be programmed without the 3.3V connected from the MCU which it did
One of the plastic screws came out and LCD was finicky so I changed them to metal:
I also found metal screws with the right length to replace Cat's choice of plastic screws and use of folded paper as spacer.
Entry 3: -----------------------------------------------------------------
Date: Thursday April 24thStart Time: 10:16 AM
Duration: 5:44 hours
Cat didn't have a chance to test the buck/boost converter so I connected the vsys and ground to the bosst converter, but it would shut down the VSYS completely. it turned out A- when choosing the converter there was no attention to try to supply the converter from the battery baby sitter,or if it was there was a mistake made by choosing a completely different charger ic with lower current rating. It was wierd because the converter was working without a load but not with a load, I tried to decrease the motor current but that didn't help either. after Dr. Walter helped us to reschadule the demo, he mentioned a solution to connect the boost converter to the battery directly and have an LDO for the 3.3v.
Entry 2: -----------------------------------------------------------------
Date: Wednesday April 23rd - Thursday April 24thStart Time: 7:00 PM
Duration: 12:45 hours
I first worked on my section of the ABET report. I continued my last week's effort to get the UART working for 24 bit. The issue Seth and I were facing was the UART being super slow and we were not being able to see the plot properly. So we opted for just printing the top frequencies. I still was not able to read accurate values from the 16bit so decided to continue with 24 bits. But I couldn't make that work. Seth and I suspect that the DMA gets overflowed. So I went back to the 16 bit. Going back to the demo on the CubeIDE I was able to get the data as we did before but again the frequency would not go below 150 Hz. But then I realized the bin size for the FFT is calculated based on: Sample rate / FFT sample points = bin size And we had 512 FFT sample points with a 48000 sampling rate which would be 93Hz per FFT bin! So I reduced the sampling rate to 16000 (the lowest mic could go) and increased the buffer size to the point that the RAM memory would let us which was 4096 samples for the FFT. So our bin size became about 4Hz and this actually gave us a decent accuracy. I used https://onlinetonegenerator.com/ to make frequencies similar to the guitar string and we got values very close to what was being played:
| Guitar String | Freq (Hz) | Measured Freq (Hz) |
|---|---|---|
| E (Low) | 82.41 | 78.1 |
| A | 110.00 | 109.3 |
| D | 146.83 | 140.6 |
| G | 196.00 | 203.1 |
| B | 246.94 | 250 |
| E (High) | 329.63 | 328.1 |
I looked into different filter types: https://www.advsolned.com/difference-between-iir-and-fir-filters-a-practical-design-guide/
Entry 1: -----------------------------------------------------------------
Date: Monday April 21stStart Time: 6:00 PM
Duration: 4:20 hours
Today I began by checking the connectivity of the buttons as Seth was seeing multiple interrupts called when any of buttons b1 b2 b3 was pressed. Measuring the resistance with the multimeter between D&E&F didn't show any short just a very high resistance which I thought was because of internal circuitry of the MCU. Measuring D&A or B&E or C&F I would see a 1k so the 1k array resistor seemed to be fine. Measuring between A&3.3V showed me about 3k which I found weird but then measuring between A&B or B&C showed a short.
So I took out the plastic part of the JST connectors to get a better view of the resistor array:
And there was some remnant of solder paste under the 3 pins so after cleaning it was working fine so I put back the plastic part of the button connectors. Next I moved to fixing the charger as proposed in the previous week (TLDR: during the design the pins selecting the current limit and battery limit were sharing one resistor, and for a 4.2V battery the charging current was not enough)
I needed to take out the charger IC. Using the soldering iron I was not able to desolder the IC because of the ground pad underneath so I took out the plastic part of the battery connector and put a lot of temperature resistant tape on top of the LEDs and used the hot gun to take the charger out.
After taking out the IC with the hot gun, under the microscope I slowly disconnected the pads 7 and 8 from each other. Now Pin 7 was connected to the R12 and pin 8 was floating. So I put the charger IC back with the hot gun and some solder paste. As mentioned in week 13 I chose a 500 ohms resistor for the current select resistor because it would give us: (from table 12 of the charger data sheet where 300 is a constant and 500 is the resistor value I = 300/R) 300/500 = 600 mA. I chose the 1206 size and soldered the right side to the ground. To connect the resistor pad to the charger pad I used a single strand of a wire (same size of human hair). It took me a long time to do this surgery but the way I was able to do it was to solder the strand of wire on the resistor pad first and then make it close to the IC pad.
Then I connected a battery and provided the VBUS (5V that is supposed to come from the USB) and the charging LED turned! So I connected the multimeter to the battery and saw that the battery got charged!
Next I soldered the VUSB-VBUS fuse (with a soldering iron):
And now with the USB connected also the battery would charge (yellow LED is the Battery charge, blue is VSYS or battery voltage after the regulator inside the charger IC):
The hardware now is ready for Cat to test the buck booster with it.
=============== Week 14: =================
Entry 3: -----------------------------------------------------------------
Date: Friday April 18thStart Time: 4:00 PM
Duration: 3:55 hours
My initial plan was to send both filtered and unfiltered signal to Python for a live comparison. This idea of sending 2 signals was stupid because after changing the bit size to 24 I needed to change the UART packet size to 2 bytes instead of 1, and so the UART would need to send 4 bytes. And then there were adjustments on the Python. I decided to add a tag in the 8 empty bits of the signal but I could not get it to work after hours of wrestling (and wasting time). The issue I think is the number of bytes and the buffer exceeds the baud rate of 115200. I then decided to simplify the issue. I assigned a button and an LED to set the data sent to the UART to be either filtered or unfiltered.
Although I was able to get the data flow to the Python, the data seemed laggy even without the filter on. This is either because of the wrong UART adjustment or the need to change the buffer processing works for a 24bit data instead of 16. I think I need to stop wasting time and go back to 16bit data and try the filtering and FFT. If it wasn't enough then we might be able to shift the mic data to right by 8 bits, meaning to get rid of the 8bits of the MSB values because we only care about the lower frequencies.
Entry 2: -----------------------------------------------------------------
Date: Thursday April 17thStart Time: 1:00 PM
Duration: 2:10 hours
To get rid of the noise and to design a digital filter I found the list of our target strings:
Then I searched about digital design and found this (wonderful) tool for finding the coefficients design. I chose the Low pass filter and Blackman window type which has a sharp response and low ringing in the side lobes (as studied in 438). Setting our sampling rate and cutoff frequency with the lowest transition bandwidth I got the coefficients as a Python code so it could be easily edited (it can be found on https://github.com/SG295/ece477_guitartuner/tree/MIC-on-CMSIS/cubemxi2s/Core/Src/scripts)
I changed the code a bit to print in a C array format:
Next I studied how to implement the FIR filter on ARM. I found that there is a CMSIS-DSP library in arm_math.h library. From the function list https://arm-software.github.io/CMSIS-DSP/main/group__FIR.html I chose the arm_fir_f32() function based on 32bit size and then using the example provided in https://arm-software.github.io/CMSIS-DSP/main/group__FIRLPF.html I added the filter initialization and use to our code. There was an issue of the Platform.io not being able to find the CMSIS-DSP library but I solved this with including the path on the .ini file:
Next to fix the issue of accuracy I increased the data format size from the 16bits on 32 bits frame to 24 bits as specified in the Mic datasheet:
Next I started by changing the UART function to support sending a word. I thought it was a few minutes work but it requires planning so next I need to update the UART.
Entry 1: -----------------------------------------------------------------
Date: Wednesday April 16thStart Time: 9:10 AM
Duration: 3:30 hours
I realized that maybe there is a minimum charging current required for the battery so I started looking at the battery datasheet: https://www.jauch.com/downloadfile/5bf529f63b6494eba86e5aa056cd18ed7/1200mah_-_lp633750js_1s1p_2_wire_70mm.pdf According to the datasheet we need a current of 280 mA.
Doing the calculation based on the charger datasheet, as noted in last week:
So to charge the battery we need a resistor less than (300/280) = 1.0714k. As removing the IC, cutting the trace and adding a resistor requires a "surgery" I asked Dr. Walter whether we could use an external module for charging. After getting the green light I asked Cat to look into this. Next I started working on getting the I2S check off done. I began by turning on the I2S2 in the CubeMX. I also turned on UART2 to send the data over UART to visualize it with Python.
The configuration for both were as follows:
32K sampling rate with 16bit data over a Word buffer.
After wrestling with buffer sizes I finally got to get the data to a serial monitor. And I used Claude to write a quick script to visualize the Time domain as well as doing an FFT on the signal. The firmware and script can be found on our GitHub repo https://github.com/SG295/ece477_guitartuner/tree/MIC-on-CMSIS
Testing this via a noise generator software the FFT didn't seem accurate and very noisy but it was enough to get the check off but we realized we didn't need a third PSDR checked so I left this as is. Next I need to figure out how to get rid of the noise and increase the accuracy.
=============== Week 13: =================
Entry 7: -----------------------------------------------------------------
Date: Friday April 11thStart Time: 4:38 PM
Duration: 3:32 hours
Today I got back to trying to get the mic PSDR check off because I realized charging the battery is not a PSDR. at first I was planning on uploading the Cube IDE code onto our board. I couldn't find an efficient way of migrating to F405 from F407 so I manually added UART2, I2S2, and SPI3 for the OLED to F405: (this picture is in cube IDE)
I copied and pasted the whole main function from the F407 FFT demo. I could see the hello world being printed but no other data:
This was because for the hello world I was manually using the DMA vs using the printf:
It turned out I had forgotten to setup ITM but instead of setting that up I changed the printf write function from calling the ITM to directly using the DMA to send the TX data.
To:
This worked in the sense of being able to see the data being printed:
However only one set of FFT would be printed. This was because the uart_busy flag would never get cleared. I technically can spend some time figuring this out but since the team are using CMSIS for the rest of the modules I decided to do some research. In the rabbit hole of googling I came across CubeMX which would let you do the configuration like Cube IDE. (this picture is in cube MX which literally the same gui)
I used Claude to figure out how to configure the CubeMX to generate the CMSIS. Under Project Manager tab, in the advanced setting section, the firmware library package for each module can be changed from HAL to LL (Low Level):
This would then generate only register-based definitions like:
With the structure of:
Which can be used via Platform.io to get uploaded to the MCU. I was able to get the blink LED demo working. I shared this with seth as he is taking over. Next week I will be getting back to fixing the charging system.
Entry 6: -----------------------------------------------------------------
Date: Thursday April 10thStart Time: 5:30 PM
Duration: 2:40 hours
I soldered the JST connector to the battery we got so we could work on bringing up battery management section of the PCB and so we have 2 batteries to see different voltage levels with the battery demo code Seth made. Before connecting the battery, I connected the power supply as the battery. Turning the power supply on did not turn on the VSYS LED:
I then used the microscope to check the soldering under the battery charger and battery management IC and some pads seemingly didn't have enough solder on them so I used the hand solder, the thin solder wire and some extra flux to add more solder to the pads. Then I cleaned the PCB with alcohol, let it dry. After connecting the power supply as the battery the VSYS LED turned on!
After connecting the 3.3V via the programmer header and a battery we were able to read the voltage level with Seth's code:
Next I focused on the charging. I still didn't solder the USB fuse so I connected a 5V source from the power supply to VBUS test point but this turned on both status pin 1 and 2.
So checking the charger IC datasheet table 8-2 mentioned that this was a hard fault:
Note that on our circuit the Stat1 and 2 are in sink mode so the LED on happens at pin state low and vice versa.
I checked our schematic for sources of issues. Cat mentioned she used the Sparkfun board as a reference (https://www.sparkfun.com/sparkfun-battery-babysitter-lipo-battery-manager.html) but this board uses another charger IC rather than our charger IC bq25185. After googling I found that Adafruit has a module that uses our chip https://www.adafruit.com/product/6091. Comparing our schematics I realized we should have had 2 separate resistors for VSET and ISET.
Instead of having them shorted and sharing 1 resistor like what we did:
Looking at the schematic the resistor value of 1.1k put the device on battery only so connecting the VBUS would cause a hard fault.
So to set the battery value of 4.2V the lowest resistor value was the 13k. But this will put the charging current rate very low.
I found the exact formula from the schematic so the charging current would be 300 / 13k = 23 mA
Using the online calculator https://www.omnicalculator.com/everyday-life/battery-charge-time This meant our battery would take about 55 hours to charge...
But at least to check it could get charged I soldered the 13k resistor instead of the 1.1k resistor and connecting the VBUS then showed that the battery was charging according to table 8-2:
Looking at the power supply it seemed like the charging current was about 5mA:
I left the charger connected for about 10 minutes but the battery voltage did not change at all:
I then connected a current meter between the battery and the battery connector. With the charger voltage off (VBUS) the current was +0.35221A. + meaning the current was flowing from the battery to the board.
With the charger connected the current was about 32 µA which didn't make any sense to me.
My theory is that the current limit set on the charger is not strong enough to overcome the battery. My proposed solution is to disconnect the ISET pin from VSEL and add a resistor between ISET and the ground:
Entry 5: -----------------------------------------------------------------
Date: Thursday April 10thStart Time: 3:15 PM
Duration: 1:20 hours
I switched gears so we could get more PSDRs besides the mic. Katis and I started looking into the motor subsystem of the PCB. I soldered the 2A fuse on the PCB, we connected the 5V power supply into the boost converter place. While the 5V LED turned on (meaning that the fuse was working) the motor was not moving. I thought maybe having the M1 and M2 pins floating was the issue but shorting those pins to the ground didn't do the trick. I then started probing the voltage pins on the driver VMOT and VINT. While I was measuring the voltages, I think the VINT and VMOT got shorted and then the motor started to spin! When we reset the power, the motor wouldn't spin again. So I looked into the schematic:
It turned out directly connecting the Sleep to VINT would not take the driver out of sleep mode hence no VINT output would be generated and the catch-22 cycle continues. To solve this I soldered a 10k resistor as the R24 which was previously "DNP-ed". The 10k resistor didn't do the trick. We looked at the datasheet for the driver:
And after making sure the sleep pin could handle being directly connected to VMOT (can handle 7 volt while VMOT is 5V) we decided to short the R24. But this would short VMOT to VINT so we disconnected pin 1 and 2 on the JP7.
And voila, the motor started spinning!
And we got the check off for it.
Entry 4: -----------------------------------------------------------------
Date: Wednesday April 9thStart Time: 9:50 AM
Duration: 2:30 hours
I started looking into how to get the mic demo working on F405 chip using the STM32CubeIDE. I read about importing the settings from the F407 code to F405 but because of having fewer pins it was not letting me directly import the code. Reference Link We then had our conflict resolution so we had to stop working on anything.
Entry 3: -----------------------------------------------------------------
Date: Sunday April 7thStart Time: 2:30 AM
Duration: 1:36 hours
finished working on A10 and submitted it.
Entry 2: -----------------------------------------------------------------
Date: Saturday April 6thStart Time: 9:40 PM
Duration: 2:05 hours
Continued Working on A10 didn't finish it on time.
Entry 1: -----------------------------------------------------------------
Date: Saturday April 6thStart Time: 4:00 PM
Duration: 3:30 hours
Worked on A10
=============== Week 12: =================
Entry 4: -----------------------------------------------------------------
Date: Friday April 4thStart Time: 3:45 PM
Duration: 2:25 hours
I started by placing the switches on a protoboard trying to figure out the comfortable access to push the switches.
I then cut the board with the board cutter in the lab. Using the Dremel I also made 3 holes bigger for the power switch and 10 more for the wires (5 connectors, 2 wires). I pushed through the wires from the bottom to the top and then soldered the wire from the bottom to make sure the wire would not come out. After soldering every wire I made 3 x M2.5 holes so we can screw the boards to the packaging.
Entry 3: -----------------------------------------------------------------
Date: Friday April 4thStart Time: 11:25 AM
Duration: 2:55 hours
Cat refused to do her part in soldering so I came to lab to solder wires for the OLED, MICs and switches.
I spent about half an hour trying to find the parts for prototyping from the ECE shop including the headers for the OLED and heat shrinks.
I started by soldering the 6-pin JST connector for the Adafruit mic, adding hot glue under heatshrink to keep the wires in place.
Next I wanted to make a 2x4 connector but the ECE shop was out of one clamp (I am not sure what you would call the metallic part that goes inside the connector - I had 7 but I needed 8).
So what I did was taking out the black section of one side of a female-to-female header and pushed the wires in with the metal clamp part already attached.
Entry 2: -----------------------------------------------------------------
Date: Wednesday April 2ndStart Time: 12:30 PM
Duration: 1:50 hours
I realized some of the MCU pins were not connected because they were wobbly under the microscope when poked with tweezers. I realized the solder paste was not enough to connect the MCU pins to the pads so I added more solder to pads and after testing, the STLink could find the MCU.
Using Claude and the Arduino platform of PlatformIO, I made a quick code to blink the LEDs on the PCB and test the programmability of the board.
And it worked!
Entry 1: -----------------------------------------------------------------
Date: Wednesday April 2ndStart Time: 9:30 AM
Duration: 2:40 hours
I used the X-ray machine in the ECE shop to check the ICs and the MCU. Everything except the motor driver was fine. I removed the motor driver with the hot gun, removed the solder from the pads and replaced the driver.
Using the diode tester I checked all the LEDs. Next Seth and I tried to power up the MCU. We connected the 3.3V bypass jumper. When trying to program the MCU the programmer couldn't find it. I downloaded the STLink utility app from https://www.st.com/en/development-tools/stsw-link004.html and tried with the 362 board but it would not connect to the target.
It turned out I needed to update the STLink firmware.
But still the STLink couldn't find the target. Dr. Google took us to this STM forum page: https://community.st.com/t5/stm32-mcus-products/stm32f405rgt6-custom-board-not-detected-on-stm32programmer/td-p/691766 It mentioned that VCAP1 and VCAP2 (picture below) should be 1.2V to show that the MCU is powered. But the multimeter showed nothing.
=============== Week 11: =================
Entry 2: -----------------------------------------------------------------
Date: Friday March 28thStart Time: 4:10 PM
Duration: 7:00 hours
I began by taping down 3 boards on the stone. Using the stencil I added solder paste and spread it around using a junk PCB:
I printed the fab view from Orcad and began placing the components:
One issue I found was an error in silk screen - C15 and R23 silkscreens were flipped:
On two of the PCBs I only placed non temperature sensitive components (LEDs, all the connectors including the USB connector, the electrolytic capacitor and the switches). On one of the PCBs I placed all components. Using the hot plate, I thought setting it on 300, which I normally use with the hot air gun, should be safe but I burnt down the PCB waiting for the solder paste to melt. For the other two boards I wiped down the solder paste on the pads for all the temperature sensitive components so after using the hot gun the surface for those components are flat and there is no solder on their pads. Using the hot gun I melted the solder paste. In one of the boards there are some shorted pins on the MCU but the other one looked good. There were some shorts on the resistor array pins which I removed using a handheld solder iron. I then added the temperature sensitive components one by one and soldered them manually and finished one PCB:
Entry 1: -----------------------------------------------------------------
Date: Wednesday March 26thStart Time: 9:30 AM
Duration: 2:00 hours
Using the updated latest BOM I found and organized the discrete components for easier soldering. I also asked Katis to organize the parts we bought from Digikey.
=============== Week 10: =================
Entry 2: -----------------------------------------------------------------
Date: Monday March 17thStart Time: 5:10 PM
Duration: 0:40 hours
I added the changes Dr. Walter mentioned which was adding an extra LED for V_SYS and the gerber files were uploaded to JLC PCB. The final file was:
Entry 1: -----------------------------------------------------------------
Date: Saturday March 15thStart Time: 12:40 AM
Duration: 3:40 hours
Changes made based on the TA reviews: Fixed the acute angles on: - R8 pin2 - U5 pin13 - RN3 pin3 - R13 pin2 - C6 pin5 - C7 pin4 - U8 pin2 - F2 pin2 The J11 pin 1 was unconnected. The OSC_OUT was made floating. Although Setsuna pointed out the big size SW8, I couldn't find any part number availability on Brightspace in the lab because we already had our parts ordered. I added a pull down resistor on BOOT0 just for better safety. I fixed the silkscreen and added our team info and a guitar logo.
=============== Week 9: =================
Entry 6: -----------------------------------------------------------------
Date: Thursday March 13th to Friday March 14thStart Time: 10:00 PM (Thursday)
Duration: 13:30 hours
Adding the IDC header makes me realize how the placing would be difficult and how having bigger vias and traces can be troublesome. And the fact that it would be better to have shorter routes to the motor driver. so I changed the placement from:
To:
When started routing I wanted to make sure we are meeting the JLC production capabilities so I checked their website: https://jlcpcb.com/capabilities/pcb-assembly-capabilities And also I found a repo that had the kicad design rules saved ready to import: https://github.com/labtroll/KiCad-DesignRules It said kicad v7 but it was compatible with v8:
When reviewing the motor driver I realized the VINT shouldn't have connected to any sources and it is in fact an internal regulator.
Looking at this example I also confirmed this: https://makersupplies.sg/products/drv8834-low-voltage-stepper-motor-driver-carrier
So I changed the schematic to:
Next for the placement of the buck-boost converters I was not sure the needed clearance for them so I downloaded the datasheet. According to my calculations 1 board needed Total height 6.32mm + (the connector) 2.54 = 8.82mm
But I couldn't figure how to minimize space by putting them close to each other so I downloaded the step file for the module as well as the 2.54 mm right angle header and using Fusion I figured the minimum required dimension to be 5mm between the header pins.
I then adjusted the header clearance and did the routing. There was about 200 DRC errors including small annular ring width not meeting JLC requirements but I was able to fix them:
I used https://github.com/easyw/RF-tools-KiCAD/blob/master/README.md for stitching vias.
Entry 5: -----------------------------------------------------------------
Date: Thursday March 13thStart Time: 3:15 PM
Duration: 1:15 hours
We are worried about going over budget so I checked the PCB prices on the PCB shopper website. We have about $70 left which can be enough if we order from JLC:
PCBway was more expensive:
Seth and I looked at the MAX7375 Oscillator as Dr. Walter gave us a review to use this since it is smaller:
We also changed the JTAG programmer to match the STM32 dev board:
Entry 4: -----------------------------------------------------------------
Date: Wednesday March 12thStart Time: 9:30 AM
Duration: 2:00 hours
I looked at the motor driver datasheet the DRV8834 and found this layout guide:
However looking at the footprint pinout we realized the pinout was off. The original:
And we fixed it to:
We got a feedback to change the layout to 4 layer. I debated this in week 1 with the reasoning of having noise. But others didn't agree.
Entry 3: -----------------------------------------------------------------
Date: Monday March 10thStart Time: 10:10 PM
Duration: 0:50 hours
We added the non-generic parts existing in the lab from the BOM file to the buy request file. Based on the TA instructions we order about 10x of the parts which have the risk of breaking such as the motor driver and current sensing resistor.
Entry 2: -----------------------------------------------------------------
Date: Monday March 10thStart Time: 2:00 PM
Duration: 2:00 hours
In process of entering the BOM part numbers I realized we don't have any partnumber for the ferrite Bead so we took the value from the ECE362 Board which was fcm1608:
But in this process looking at the schematic I realized C23 and 22 must be an electrolyte cap and looking at the layout of the dev board the bigger footprints confirmed this.
Entry 1: -----------------------------------------------------------------
Date: Sunday March 9thStart Time: 12:50 AM
Duration: 7:00 hours
In the presentation we got a feedback about following the layout guides in the datasheet. I started with the bq27441-G1 ic. From the datasheet: https://www.ti.com/lit/pdf/SLUA366 I checked the value of the capacitors:
But more importantly I realized how the layout for the current sensing resistor should be done:
I didn't know about Kelvin connect so I read more about it on this application note from TI: https://www.ti.com/lit/pdf/SLUA366 And https://www.raypcb.com/kelvin-connection-pcb/ Next looking at the datasheet of the charger IC, BQ25185, I added 2 LEDs for the charge status:
And changed the layout to:
We also had a feedback on adding ESD protection for our switches so I searched Digikey database for an array of 4 ESD diodes. The reasoning was that we are using 2 arrays of 4 capacitors and array of 8 resistors for our debouncing because of easier soldering. I added SMS05T1G: https://www.digikey.com/en/products/detail/onsemi/SMS05T1G/920310
For the layout I wasn't sure whether I could use via or how short should be the trace so I found this application note which points out the route to the diodes should be direct: https://www.ti.com/lit/an/slva680a/slva680a.pdf After reviewing the PCB I realized on the MCU side the net was called +3.3V instead of 3.3v and this caused the MCU not to be connected to any power supply at all. +3.3v vs 3.3v:
=============== Week 8: =================
Entry 4: -----------------------------------------------------------------
Date: Monday March 10thStart Time: 4:00 PM
Duration: 1:30 hours
We did the presentation. I was assigned to do the PCB so we agreed on someone else making my presentation parts.
Entry 3: -----------------------------------------------------------------
Date: Monday March 10thStart Time: 2:00 AM
Duration: 4:25 hours
Got the placement back from Cat:
Started by making it more "routable". I also found a 4 resistor array of 22 ohms resistors for JTAG: https://www.digikey.com/short/f9dj743t
Then I did the routing for the main components:
Entry 2: -----------------------------------------------------------------
Date: Saturday March 8thStart Time: 11:00 PM
Duration: 7:30 hours
I continued by finding the array resistor. The 1k array for debouncing the buttons: https://www.digikey.com/short/5q4wf8vq Also we had 4 LEDs for debugging so I found a 4 resistor 680 ohms for the LEDs: https://www.digikey.com/short/31m3h4j3 For the 100nF debouncing capacitor I couldn't find any SMD part with 8 capacitors that was in stock so I decided to go with 2 of 4 caps in a package. Also I chose a cap with the same width of the resistor arrays, 1.6mm, and a voltage rating of 16v: https://www.digikey.com/short/zwd3n3nb The CAD model didn't have a multipart capacitor so using this tutorial: https://forum.kicad.info/t/kicad-7-8-creating-schematic-symbols-with-multiple-units/47166 I split the caps into four parts:
Seth asked me to check his JTAG programmer section and the oscillator section. I used this as a resource to add 22 ohms resistors before his JTAG connector pins: https://github.com/Netrona/STM32F_Audio_Codec_pcb?tab=readme-ov-file
And I used: https://community.st.com/t5/stm32-mcus-products/how-to-choose-the-8mhz-crystal-oscillator-for-stm32f407/td-p/218315 For the crystal section I need to talk with him about this:
There was no footprint for the motor driver potentiometer. It was a 10k potentiometer based on the datasheet: https://www.pololu.com/file/0J1909/drv8434a-stepper-motor-driver-carrier-schematic-diagram.pdf https://www.digikey.com/short/8011rtw9 I used: https://www.pololu.com/product/2134 To add some test points to the schematic:
I started working on the PCB. The push button and the capacitor looked huge so I changed the packaging to smaller parts:
Finished the initial placement of the components and sent to Cat:
Entry 1: -----------------------------------------------------------------
Date: Saturday March 8thStart Time: 12:33 PM
Duration: 3:00 hours
I began by finding a proper 2mm 6pin jst connector to connect the mic to the PCB: https://www.digikey.com/short/q843d7v7 But it was out of stock, after googling the part number I found a kit with both male and female connectors: https://a.co/d/bmhTO8l
Next I started working on adding fuses to our circuit. I checked Cat's battery charger data sheet, based on her resistor values for Riset = 1.1k. The current charge is between 150mA and 500mA so just to be safe I chose a 1A fuse:
For the Motor power supply I am a little concerned about the current spikes so I decided to go with a bigger SMD package size: https://www.digikey.com/en/products/detail/bel-fuse-inc/C1F-2/4968250 For the ESD protection of the USB, I went to digikey ESD section and found a 5v diode. I wasn't sure about the orientation of the pins so I checked its datasheet and it was stated that it is bidirectional: https://www.digikey.com/short/v2q2dmvw I also wasn't sure about the ID pin of the USB so upon research I found out it is for the transfer of data and specifies the host if grounded. In our application it kinda doesn't matter but we are keeping it floating so it is a slave device: https://electronics.stackexchange.com/questions/35462/why-does-micro-usb-2-0-have-5-pins-when-the-a-type-only-has-4
Host: ID connected to GND Slave: ID not connected (floating) Next I looked at the UI subsystem. The order of the debouncing seemed off (with the 1k resistor being in between the pullup resistor and the MCU pin):
After some research I found this source: https://hackaday.com/2015/12/09/embed-with-elliot-debounce-your-noisy-buttons-part-i/ Which recommended moving the pullup resistor to left, connected to the GPIOs. For the power part I found the current sensing resistor on the eval board schematic: WSL0805R0100FEA1 From https://www.ti.com/tool/BQ27441EVM-G1A#supported-products Next I thought about using the 2mm 2 pin version of the JST for the buttons: https://www.digikey.com/short/npj834qr And replacing the resistors with array resistors, the 10ks (all of the resistors have one pin connected to each other) and 1ks are split resistors. For the 10ks I couldn't find 6pin resistors so I decided to use an 8 pin and make two extra debouncing circuits in case we needed more buttons. The 10k array: https://www.digikey.com/short/m0h4qv1v
=============== Week 7: =================
Entry 6: -----------------------------------------------------------------
Date: Wednesday February 26thStart Time: 12:00 AM
Duration: 0:20 hours
Seth pointed out he has found a newer version of the Discovery board schematic: - New: https://www.st.com/resource/en/schematic_pack/mb997-f407vgt6-e01_schematic.pdf - Old: https://www.st.com/resource/en/schematic_pack/mb997-f407vgt6-b02_schematic.pdf Additionally he mentioned he couldn't find f407 in a 64LQFP package. To check this I searched stm32f407 on both mouser and digikey and couldn't find it either:
Upon searching the datasheet we came across this table:
This means the F405 has a 64 pin package not the 407. But I pointed out that from this table we can see everything is the same between F407 and F405 except the number of GPIOs, ADC channels and the camera interface. All of which is not applicable to us so per Seth's decision we are going with the F405 model.
Entry 5: -----------------------------------------------------------------
Date: Wednesday February 26thStart Time: 9:30 AM
Duration: 2:00 hours
We came together and I explained to team how the hierarchical sheets work. I then asked them to pull and work on their dedicated sheet and to add their libraries to the parts_library folder. When the TAs and Professor Walter gave us the green light of increasing the PCB size, and when I asked him whether we can use the MIC module instead of having the mics on the PCB he let us do that. Setsuna then gave us two great advices: 1) was to look at table 12 of the stm32f4xx datasheet to optimize/minimize the powering of the micro, and 2) they pointed out we can use the 64 pin instead. Looking at the density of the board and USB-to-UART not being our PSDR, we decided to remove that subsystem from our project so I changed the toplevel schematic to:
I plan to add more protection to the USB subsection, for instance ESD protection diodes and fuses to protect the power supply and the power for charging the battery. Given these plans I decided to make a task/todo list shared with the team to be able to track our tasks.
Entry 4: -----------------------------------------------------------------
Date: Wednesday February 26thStart Time: 1:20 AM
Duration: 4:10 hours
I got the Combined schematic from Cat:
I wanted to convert it into a hierarchical schematic so I googled on how to do this and watched this YouTube video: KiCad 5 #17 Hierarchical Labels & Pins I started by making separate sheets with names as close as possible to what we named our individual parts before giving it to Cat:
Next I cut and pasted each part to these sub-sheets and using the "change to" tool I converted the nets we wanted to share with other sections to a hierarchical label:
Here was the final overview of the separate subsystems. I used this tutorial on how to reduce the sheet size as Cat made it big to fit all schematic sections. I kept the USB outside technically because it couldn't fit in either category:
Next I ran the schematic to PCB tool and saw a lot of packages were missing a footprint. This was because when we shared our schematic with Cat we didn't include the libraries/footprints we used. Using the edit symbol tool in the schematic viewer I got a list of the components plus their footprint name:
Since we wanted to get a sense of overall placing size I changed the footprint of all passive parts to 0805. I checked Digikey to make sure there were high capacity (100uF, 22uF) capacitors available in the 0805 package size. Additionally to get the footprints for the ICs and the mics I searched the part numbers on Digikey and used the CAD section to get the footprints:
For the motor, Katis didn't put any connectors so I searched for a standard 2.54 pitch 4pin JST and downloaded and added it directly to PCB: https://www.digikey.com/short/bc9w1jb8 I had asked Cat about the PCB size (4 × 6 cm) so I made a 4 × 6 rectangular in KiCad PCB design and placed the main components:
I then pushed the schematic and this initial PCB to a new branch on our GitHub repo. Additionally I made a folder, parts_library, and added all the footprints used to this folder.
Entry 3: -----------------------------------------------------------------
Date: Tuesday February 25thStart Time: 9:15 AM
Duration: 1:00 hours
Using the Footprint editor and the datasheets I checked the footprints of the main components, the mics and the FT232 to A) have the same dimensions and B) have the right pin linking. Page 31 of https://ftdichip.com/wp-content/uploads/2020/08/DS_FT232R.pdf Page 8 of https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/908/SPH0645LM4H-B.pdf For instance for the MIC, checking pin 1 being WS on the correct pad for the mic. Also I checked to see pin 3 is through-hole because it is essentially the sound input of the mic:
Entry 2: -----------------------------------------------------------------
Date: Tuesday February 25thStart Time: 7:45 AM
Duration: 0:50 hours
I started working on cleaning up my part of the schematic: the mics and the USB to UART converter. I got rid of power LED for the FTDL chip because it was an indicator for the 3.3V which should already be added to the power delivery subsystem.
Next I cleaned up the net names and deleted the nets we weren't using:
=============== Week 6: =================
Entry 5: -----------------------------------------------------------------
Date: February 18thStart Time: 9:00 Am
Duration: 2:00 hours
I started to try to make a python script to sweep the frequency, play it from my headphones and read the data from the serial monitor (microphone + embedded fft) and see how much is difference between the reality and the measurement however I failed because I couldn't find a way to get the winsound or playsound libraries working with threads. The threads were necessary because of constant reading of UART as well as plotting. So I gave up and checked the accuracy manually. I started working on my part of the schematic as well as the FTDL module
It is almost done I need to adjust the offpage connectors to match Seth's MCU schematic part.
Entry 4: -----------------------------------------------------------------
Date: February 18thStart Time: 1:00 Am
Duration: 5:00 hours
Today I continued with the link tutorial. As well as link and link. I installed DSP library from component select in CubeIDE
And under property, path and symbols I added the "ARM_MATH_CM4" library to be able to use arm_math library. Next I followed the steps in the tutorial more specifically the 2nd section of its video STM32 DSP CMSIS: Real-Time FFT| Python script to plot spectrogram in real-time talking about the FFT algorithm. The way he does it is to take the time domain samples from the buffer, perform an FFT with arm_rfft_fast_f32 to get the frequency components. Next step is to then calculate the magnitude of each frequency using arm_cmplx_mag_f32(). In order to understand these functions better I used link. There was a need to remove the bias which was done with data_out_fft1[0] = 0; or setting the first element to zero.
Next to be able to get the data to a python script, the tutorial asked for utilizing UART 2 and a DMA for transmitting data. I connected the FTDL USB to UART module from 362 to PA2 and PA3 the USART2_TX USART2_RX. The connection in the tutorial was the same as the one on the STM32f4 discovery board:
However I was not able to get any readable data from the serial monitor.
I did some research and found more references utilizing the UART2 exactly as described above. Such as link. Finding no results I connected an AD2 to the UART TX (MCU tx)
I could see visible packet data and no framing error but the serial monitor would share gibberish still
After playing around with different parameters such as Baud rate, oversampling, increasing the stop bit for more than an hour It occurred to me that the data coming to UART2 are from the FFT calculations, and they are different than ascii value of numbers! To test this hypothesis I decided to set the value in the DMA's buffer to a constant and voila! (I was so mad that I made this mistake)
Next using Claude I made a quick python script to open a com port with the baud rate (115200) and extract the FFT data from the sent data on the UART and visualize the data. I averaged the data 4 times and showed the peak frequency.
The code is:
import matplotlib.pyplot as plt
import numpy as np
from matplotlib.animation import FuncAnimation
import serial
import struct
from threading import Thread
from collections import deque
# uart comport
uart_mcu = serial.Serial('COM3', 115200, parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE, bytesize=serial.EIGHTBITS)
# number of frequencies
N = 32
# defining plot parameters
fig = plt.figure(figsize=(12,6))
ax1 = plt.subplot(111)
x = np.linspace(0, 14000, N) # x-axis in Hz
fft_values = np.zeros(N)
fmt = "%df"% (N)
# Deque to store last 5 maximum frequency points
max_freq_points = deque(maxlen=5)
# creating thread to read the uart
def read_uart():
global fft_values
print("running thread")
while True:
data_uart = uart_mcu.read_until(b'\xf9\xf8xN')
if data_uart.__len__() == N * 4 + 4:
fft_values = struct.unpack(fmt, np.flip(data_uart[0:(N * 4)]))
# animation function to update the plot
def plot_animation(i):
global fft_values, max_freq_points
ax1.clear()
# Find frequency of maximum value
max_index = np.argmax(fft_values)
max_freq = x[max_index]
max_freq_points.append(max_freq)
freq_avg = sum(max_freq_points) / len(max_freq_points)
# Plot setup
ax1.set_xlabel('Frequency (Hz)')
ax1.set_ylabel('Magnitude')
ax1.set_ylim(0, 10000)
ax1.grid(True)
# Plot line with markers
line = ax1.plot(x, fft_values, 'b-o', markersize=4,
label=f'FFT (Avg Max Freq: {freq_avg:.1f} Hz)')
# Highlight the current maximum frequency point
ax1.plot(max_freq, fft_values[max_index], 'ro', markersize=8)
# Add legend
ax1.legend(loc='upper right')
ani = FuncAnimation(fig, plot_animation, frames=100, interval=10, blit=False)
if __name__ == "__main__":
t1 = Thread(target=read_uart, daemon=True)
t1.start()
plt.show()
The final testing demo is:
One issue that I noticed was that the frequency wouldn't get less than ~410 Hz which is very problematic and needs to be investigated.
Entry 3: -----------------------------------------------------------------
Date: February 17thStart Time: 9:25 pm
Duration: 1:00 hours
Next I followed the steps on the link to make the printf working. But I faced the issue of debugger getting past the printf line but would not print it. The majority of my time (was wasted) trying to fix this. But then I found this link manual and realized the trace option was not checked (I was very angry)
Entry 2: -----------------------------------------------------------------
Date: February 17thStart Time: 7:40 pm
Duration: 1:30 hours
I started by searching about HAL Including link in which I got an idea of how the structure is. Next I installed the stm32cubeide. I then used the tutorials regarding setting up the I2S with HAL including link for general examples But more so link This repo and project was really what we need: running SPH0645LM4H with STM32f4 using HAL and then doing FFT on the signal. I setup the i2s as: Half duplex master receiver 32bit mode only using half word (discarding the 2 bits of the MIC data) Clock 32kbit DMA in circular mode for SPI2 One important section the tutorials were mentioning was to have the system clock as high as possible which was 168 MHz for f4 board
I was unable to generate code because the f4 specific packages were not installed with the App itself - it took about 20 minutes to complete.
Entry 1: -----------------------------------------------------------------
Date: February 16thStart Time: 4:40 pm
Duration: 0:30 hours
I worked on A7, the BOM, for my parts and adjusted some packaging types on the table
=============== Week 5: =================
Entry 6: -----------------------------------------------------------------
Date: February 13thStart Time: 4:30 pm
Duration: 0:50 hours
I went to the lab to check the driver. Katis was trying to drive a 7HS19-2004S1 motor link Which needs 20v dc to operate. But our driver has a maximum 11v rating
. Asking a TA we went to find a bipolar stepper with a rated voltage of less than 11v but the motors were either unipolar or had higher voltage ratings. So we ordered the QSH4218-41-10-035 link And additionally I ordered a PWM controlled DRV8834 based motor driver link just in case we couldn't get the serial motor driver to work.
Entry 5: -----------------------------------------------------------------
Date: February 12thStart Time: 7:10 pm
Duration: 0:45 hours
Katis says he can't get the driver to work because it is for a brushless motor. I checked the driver's schematic
And then the motor driver IC's schematic
It is confusing because the SparkFun library website link says that the library cannot be used for steppers but then the newer version says we can link
Entry 4: -----------------------------------------------------------------
Date: February 12thStart Time: 10:10 am
Duration: 1:30 hours
The motor driver
was delivered without the cables. Katis and I looked at the schematic, the both black connectors were connected to each other I decided to take out one side and directly connect the wires to the pads. In the process one pad got ripped off so I found a pull-up resistor on the schematic and connected the wire there. Next, we found out we need a 3.3V supply besides the motor's supply, so I soldered another wire to the other side of the I2C pull-up resistor.
To check the connection I asked Katis to download and use an Arduino Nano to run the I2C_scanner script link. We found out what pins are the I2C output on the Nano to see whether we see the I2C device and hopefully we did see the device.
Entry 3: -----------------------------------------------------------------
Date: February 11thStart Time: 2:45 AM
Duration: 1:45 hours
I tried to implement this link and the STM32F FFT project with SPH0645LM4H mic on my STM32F091xB board from the 362 but I realized stm32cube IDE won't support f0 microcontrollers. So I made a mistake of not using an Arduino to make the proof of concept of we can get data from the mic using I2S. First I implemented the UART5 to make prints from the microcontroller.
Then I read a lot about I2S protocol and the clocking from the datasheet of the f0 family link More specifically section 28 - page 755. additionally using the microphone datasheet link I connected the microphone to I2S2: So: - WS -> PB12 - CLK -> PB10 - SD -> PC3 Then I wrote the functions to: Setup the GPIO as alternative functions: For the pins on portB they were AF1. For the pins on portC they were AF0. Next I enabled the I2S pin as introduced in the page 28
I also configured the DMA to move data from SPI2(I2S2) to the buffer and then used UART to print out the raw data. The microphone has a left and right pin which allows the use to connect two mics together but for this reason, it requires to read a 32 bit from it and only use the half 16 bit of the data. I think the data was wrong because of the clocking issue and or the half word data. I wanted to debug this but since we decided to move to f4 I am planning on using HAT as a TA recommended and use help from the GitHub repo to do the FFT as well.
Entry 2: -----------------------------------------------------------------
Date: February 8thStart Time: 4:20 pm
Duration: 4:40 hours
I started working on the A4 based on the information the team put on the A5 and the components they chose. I began by expanding the subsystems I divided the project into in A2. In the compute and operation system section, I explain the importance of the MCU as the central unit that connects all other subsystems. The STM32F407 was chosen specifically for its floating-point unit capabilities, which I explained we needed for our DSP and FFT calculations. Additionally, I explained how the MCU interfaces with each subsystem through various protocols: I2S for the MEMS microphone, PWM for motor control, SPI for the OLED display, GPIO for buttons, and I2C for battery management. For the electrical considerations, I made two points, one was to specify our compute frequency/speed and rates for the different operations we were doing. For this, I started with the core MCU frequency of 168 MHz link and then detailed the various interface speeds: 3 MHz for I2S to support 48 kHz audio sampling link, 6.66 MHz for the OLED display's SPI communication link, above 20 kHz for the PWM motor control to avoid audible noise link, and 100 kHz for I2C battery management communication link. I also analyzed the computational requirements for our DSP operations, noting that a 1024-point FFT would take 855 µS at our operating frequency, which is sufficient for processing guitar string frequencies ranging from 82.4 Hz to 329.6 Hz link sampled at 48 kHz. Based on the main components given in A5 by the team I found the max current and operating voltages of the components and calculated the total power consumption by the components
[1] [2] [3] [7] [8] [9] [10] Next I added the powers together both when the motor is active and it is in standby and based on a 3000 mAh battery “Makerfocus 3.7V 3000mAh Lithium Rechargeable Battery 1S 3C LiPo Battery (Pack of 4),” MakerFocus, 2021 I calculated how long the device can last on the two modes. I decided to be safe and set a discharge limit of 85% the calculations were as follows:
For the interface sections I mentioned all the interfaces we are going to use including 1. I2S 2. SPI 3. I2C .. PWM UART . JTAG and then also mentioned having a USB C on the board for the UART and charging. Lastly I updated the diagram to show the power lines better and changed the components such as LCD to OLED and the F0 to F4 microcontroller
Entry 1: -----------------------------------------------------------------
Date: February 14thStart Time: 1:30 pm
Duration: 2:30 hours
I started working on A5, I begin with adding the subsystem division to the component analysis
and polishing the added data from the other team members. Next I introduced a grading system to the team to streamline the component selections
the idea was to improve our selection process for each component by giving each criterion a given weight and a score and to add the points to find the necessary component. Some criteria had a higher importance. For instance, the power consumption for the motor had a criteria of 3x while the MCU had a criteria of 1x, and the OLED had a weight of 2x, this is because the high order of power consumption for the motor essentially makes the power consumption of the other products more negligible. Next I wrote the microphone project explaining the need for the sound data to be used with FFT for finding the frequency. I researched for mic options and found 4 options. To make a selection I found 3 sources:
- J. Lewis, "Analog and Digital MEMS Microphone Design Considerations," Analog Devices, Technical Article MS-2472, 2013
- J. Lewis and B. Moss, "MEMS Microphones, the Future for Hearing Aids," Analog Dialogue, vol. 47, Nov. 2013
- "Analog vs Digital Wireless Microphone Systems," Gear4music Blog
I checked the datasheets for them and put the data in our scoring graph. The datasheets were:
- Electret Microphone Amplifier - MAX4466 with Adjustable Gain
- Adafruit Silicon MEMS Microphone Breakout - SPW2430
- Adafruit I2S MEMS Microphone Breakout - SPH0645LM4H
- Adafruit PDM MEMS Microphone Breakout
=============== Week 4: =================
Entry 3: -----------------------------------------------------------------
Date: February 7thStart Time: 7:00 pm
Duration: 1:50 hours
I, again, put a lot of time updating the html file, converting my entries from OneNote to this.
to be honest I only put short words in my OneNote and I format it while I am entering them here:
Entry 3: -----------------------------------------------------------------
Date: February 7thStart Time: 4:00 pm
Duration: 2:30 hours
I started coding for the mic there are multiple sections to how to get the mic working: 1- initializing the I2S (to get the data from the mic)
2- setting up DMA (to transfer the data to a buffer)
3- initializing the UART (to send the data to the serial monitor)
4- setting up an interrupt (to see when the DMA transfer was done)
5- and a loop to read the data from mic and repeat
here is a small snapshot of the functions I have so far
I am unfortunatly unable to see the uart output from the VScode, the debugger shows the code moving with no error but it needs more debug.
Entry 2: -----------------------------------------------------------------
Date: February 6thStart Time: 2:30 pm
Duration: 1:45 hours
Today I went to the lab to figure out why our motor and driver were not delivered the TA was looking for them because the dirver was still in transit and he said we have to use an available motor in the lab I disagreed with him explaining we needed a motor with a specific torque and voltage requirements: a torque of 2.5 lb-in and a voltage of 5 VdC but he was not convinced speaking to team we decided to risk and go with whatever motor available in the lab. the motor we randmoly picked was PK244-02AA link
I spent sometime to find it online and its datasheet. acording to the datasheet the motor requires 6 VDC can provided 32 oz-in or 0.22 N-m of torque which is not enough for our project. but the team thinks it is fine to do the demo with this. I have argued that we need to test that the onpaper required torque tally with the real word (it does actually able to turn the peg) they are not convinced and we decided to go with whatever we have.
for the rest of the time I started on writing the library to get the mic working on the STM32F091RCT6. my plan was to print the data from the mic to the serial monitor and copy and visualize it on audacity. as described on: link
Entry 1: -----------------------------------------------------------------
Date: February 5thStart Time: 8:30 Am
Duration: 3:45 hours
Once I got to the lab I started by cleaning my breadboard from the last semester for 362, Since we haven't decided on cortex type yet I decided to get the mic working with the stm32 dev board from last semester.
this board has a STM32F091RCT6 microcontroller on it datasheet here] Next I setup the VScode with the necessary extension to program and flash the stm dev board because last semseter I only used the lab computers.
Next I searched for the pinout and datasheet of the mic we have had picked the "Adafruit I2S MEMS Microphone Breakout with SPH0645LM4H" link
the SPH0645LM4H datasheet can be found here
and the pinout is as follows:
next was to get more details about the I2S protocol and how to use it with STM32F091RCT6. looking at the datasheet here] again I found that the A) I2S is supported on STM32 and B) the SPI should be a similar protocol to SPI which I initially thought it might be I2C! C) it has 2 I2S channels (changing spi to I2S)
I also undertood we can use DMA to get the mic data stored in the memory without direct intervention of the CPU.
looking at the datasheet I decided to use I2S channel 2 so if we decided to use an LCD with SPI we can use it in channel 1, I don't thin there is a fundamental different at this time but we might have to rearrange the pins in a new microcontroller or if we gonna have some interrupt/dma confilction from table 13 (to large to post) I saw that we could use different ports for the I2S2 looking at our dev board pinout I decided to go with port B. (ignore the red markings this is from a previous semester and they are forbidden pins)
again from the datasheet these pins are altrenate function 0 for PB12, PB13, PB14, and PB15.
now I am was not familiar with the wording of this pins, of course looking at the image above I could tell SD is equivilant to MOSI in spi and so on but I decided to use google to understand this. I spent quite some time on understanding how it works: the most important resource was the adafruit website link digikey was more in depth: link at the end of session we had a meeting with Dr. Walter about what PCB editor to use and decided to go with KiCAD staying a little longer I also found this video very helpful: link
=============== Week 3: =================
Entry 5: -----------------------------------------------------------------
Date: January 29thStart Time: 6:00 pm
Duration: 2 hours
I have been working on expanding my entries in this journal as I take notes in OneNote and then convert images and links to HTML format:
PS: I really don't think this html formatting is sustainable 2 hours could be spent on research.
Entry 4: -----------------------------------------------------------------
Date: January 29thStart Time: 5:00 pm
Duration: 1:10 hours
Researched for the 2 cell lipo management IC with fuel gauge and buck converters on digikey, analog devices, TI and Mouser websites. the challenging part is two things. A) to support a 2 cells lipo battery and B) supporting the 2A @ 4.5 VdC for the motor Monolithic Power Systems 2 Series Cell Chargers Found the following ICs:
the MP2760 seems to have the requirments for us:
power managment for 2 cells Lipo
high current 5v output for the motor
and the 3.3v for the microcontroller
a TQFN-30 packaging easy to be soldered
Entry 3: -----------------------------------------------------------------
Date: January 29thStart Time: 9:45 am
Duration: 2:30 hours
I was late for the lab, upon arrival I started focusing on the motor. as it was discussed with the team we decided to go forward with a stepper motor. I opened digikey and started looking for a stepper motor that can provide the torque we need (2.5 lb-in or 0.28 N-m). The digikey unit was in oz-in so I had to convert our requirement to oz-in which was 40 oz-in using: link I realized there are two types of stepper motors on digikey:
1- bipolar
2- unipolar
after some research I found that bipolar motors provide better torque, have fewer connections (4 vs 6), but they require more complicated drivers.
Here are some sources for more information:
- Difference between Unipolar and Bipolar Stepper Motors - Tech Explorations
- Difference between Bipolar Drives and Unipolar Drives for Stepper Motors - Portescap
- Difference between Unipolar and Bipolar Stepper Motors - StepperOnline
choosing the biploar option, I then chose our minimm requred tourque. our next priorty was the size, there was only one nema 8 motor available: link
as can be seen, the length of the motor was too long. so I went with nema 17 motor. Because of the high current requirements of some low power voltage levels, I selected the a voltage level between 4 and 9 vdc, and I ,then, sorted with price and chose this motor from Analog devices link
looking at the datasheet here I realized there is a version with an encoder but after previous discusions with the group we decided to use the audio as the feedback instead of an extra encoder. using the power (4.5 vdc voltage and 1A current) requirements I then searched for the motor drivers which can support a 10W load (4.5*2= 9W just to be safe in terms of spikes) I chose this driver because of the power requirements: here
figuring out the dimensions of out motor "Square - 1.665" x 1.665" (42.30mm x 42.30mm)" we kinda had an idea of how big of a screen we can choose. We decided to go with oleds because of low power consumption. we didn't need the touch requirments because of having the keys to select the modes I then proposed two 1.5" lcd options to the team which were about the same size of our motor and was controlled via SPI:
1) color
2) monocolor
the team were woried about the power consumption of the color oled but I argued that our motor will be consuming about 5W of power so we need a big battery anyway and hence we decided to go with the color oled. I then finally order the motor,the driver and the lcd for prototyping.
Entry 2: -----------------------------------------------------------------
Date: January 25thStart Time: 6:10pm
Duration: 0:45 hours
After taking a break I continued reviewing the A2. I worked on the mechanical constraints and found these sources for the required torque: A) D. Prokopczak, S. Erickson, and K. Chen, “Automatic Guitar Tuner Project Proposal,” 2014. Accessed: Jan. 25, 2025. [Online]. Available: https://courses.grainger.illinois.edu/ece445/getfile.asp?id=6180
B) A. Bocanegra, “Automatic Acoustic Guitar Tuner MASSACHUSETTS iNSTrTE OF TECHNOLOGY,” 2005. Accessed: Jan. 25, 2025. [Online]. Available: https://dspace.mit.edu/bitstream/handle/1721.1/32878/62588821-MIT.pdf According to the sources the torque required is between 2.4 lb-in (or 0.27 N-m) and 2.5 lb-in (or 0.28 N-m). which should be considered when choosing the motor
Entry 1: -----------------------------------------------------------------
Date: January 25thStart Time: 3:20pm
Duration: 3:00 hours
I started working on A2 Specifaclly the functional description, the theroy of operations. For the theory of operations I catogtized the process of tuning into 3 sub categories: - Selecting the note and the instrument using the user interface - Digitally processing the note, the sound frequency, after the string is plucked - Rotating the peg to tune the note. Based on these I designed the top-level flow diagram for the project including the following flow diagram of how the top level process should look like. Additionally I added the updated toplevel diagram with the stepper motor and the motor driver
I also devided the whole project into 5 subsystems:
Subsystems:
- Subsystem 1: User Interface System: including the display module, and the buttons
- Subsystem 2: Sound Analysis System: the microphone
- Subsystem 3: Motor Control System: Comprising the stepper motor and the motor driver
- Subsystem 4: Power Delivery System: including Buck-Boost regulator(s), battery management IC, USB-C connector, and circuitry for charging
- Subsystem 5: Communication: and the UART-to-USB converter
Additionally, I divided the power delivery into smaller subsystems:
The system is powered by a rechargeable battery. Using regulators, the power is divided into two main parts: A high-voltage source for the rotation system and a lower voltage for the MCU and the rest of the components such as the LCD screen and the microphone. The power delivery system also utilizes a battery management IC to: - charge the battery through the USB-C circuitry and - transmit the battery level to the MCU to be displayed to the user.
=============== Week 2: =================
Entry 4: -----------------------------------------------------------------
Date: January 24thStart Time: 10pm
Duration: 1:30 hours
as I was checking the journal for submission I decided to make a pros/cons template to solve the challanging questions that comes up in the design process, I shared it with the group need to talk with them in person about how to utlize it.
the process of fixing the html formatting and adding images took me a while
Entry 3: -----------------------------------------------------------------
Date: January 24thStart Time: 6:45pm
Duration: 0:45 hours
Seth brought up a good point about the need to use an MCU with ability to do float point, did some research about doing FFT on STM microcontrollers and found this opensource project
Entry 2: -----------------------------------------------------------------
Date: January 23thStart Time: 7:30pm
Duration: 2 hours
Searched briefly about the LCDs we can use proposed one to the team LCD display, based on the motor voltage requirement decided to go with a 2 cells lipo battery like: Zeee 2S Lipo Battery spend a lot of time trying to find a PMIC on analog devices, TI, Digikey websites for a two cells lipo but couldn't find anything in a qfn >= package, then decided to go with a separate Battery management/charger + ldo + battery protection order. picked the i2c enabled MAX17044
Entry 1: -----------------------------------------------------------------
Date: January 22thStart Time: 9:45am
Duration: 1:45 hours
I was late for the lab, once I arrived we worked on the A2. After talking to the group about TAs announcment that parts can be delayed, I also put an order for the microphone module microphone module
=============== Week 1: =================
Entry 3: -----------------------------------------------------------------
Date: January 17thStart Time: 7:30pm
Duration: 1:30 hours
worked on the A1 proposal, had some discussion about how many layers of PCB we should do as the proposed cost was unrealistic, made a pros/cons table to discuss the reasoning but will need to see what more functionalities we need to add to the project.
Entry 2: -----------------------------------------------------------------
Date: January 16thStart Time: 9:30am
Duration: 2 hours
this was the first week of lab so only did propose the project to the TAs, and had a tour around the lab
Entry 1: -----------------------------------------------------------------
Date: January 13thStart Time: 11:37am
Duration: 1 hours
worked with cat to transform her diagram sketch to a draw.io file, add more components to it and found the initial components to include them on the diagram.
