Posted on

Gleb’s Status Report for 12/6

This week, I worked primarily on system integration.

  • Debugged the ethernet driver on the STM32 and developed a PC-side Python visualization tool.
  • Helped rework the LED modulation PCB and the driver PCB. Helped debug hardware issues with the CC driver.
    • Fixed LED modulation issues originating from bad connections and poor placement of tiny components. Performed xray and visual inspection to validate component placement.
  • Tested integration between the illumination module and the CC module
  • Tuned parameters of the imaging sensor to get the best possible depth map
Posted on

Sid’s Status Report – 12/6/2025

These past two weeks, I worked with the rest of the team on integration tasks. I helped debug our LED driver. It turns out we were running the enable pin at too high of a voltage, which was causing some overcurrent issues. Quite a fun issue to solve! I also did some rework on the LEDs and passive components on the illumination module. Finally, I gave our final presentation and helped out with some coding tasks here and there, including adding in LED driver enables, etc.

For next week, we are just debugging some final phase offset inconsistencies and our entire project should be good to go, and my firmware portion is also on track/completed. We will all work together to finish up the final paper/video as well next week!

Posted on

Team Status Report for 12/06

Integration of entire system introduced hardware bugs that were worked through, currently working through software to retrieve depth imaging.

Unit tests were conducted on the 3 PCB modules separately before putting them all together, utilizing EE tools to help debug signals and identify electrical contact issues.

Overall system tests were done to determine depth, modulation offsets using a scope between all of the modules, FPS, and range. Initial tests indicate >10 fps, and linear increase in pixel values based on depth.  No major design changes were needed after test completion.

Posted on

Claire’s Status Report for 12/06

Updated pre-demo introduction, assembled rev 2 of our power supply board, debugged with teammates hardware issues integrating overall system, see team report.

Aim to help wrap up software issues in time for final demo.

Posted on

Sid’s Status Report for 11/22

This week, I did a lot of heavy firmware lifting. I debugged the DCMI connection to the STM32, writing up the I2C sequencer code to get the chip to turn on and start sending back information. This required a lot of thought around the functional modes we wanted to keep the chip in, as well as the issues around why the chip was not getting into a data acquisition mode. I also redesigned and ordered the power board to have enable lines that are easily accessible by the STM32, which will allow us to precisely power sequence the sensor in the way the datasheet says to.

I also started working on getting DCMI data back over DMA to the chip. I had to do a lot of debugging of usage/hard faults in memory, which came from a very obscure HAL and workflow for this type of data transfer. We had bugs in the NVIC definitions of interrupts and with our buffer size, but we were finally able to get some data back from the chip. For next week, I need to debug the correct buffer size, enable continuous mode for the chip, and start sending this data over through Ethernet. However, the end is near, and we seem to all be on schedule and the device should start coming together in the next week as a whole! See team status report for scope pictures.

Posted on

Team Status Report for 11/22

Preparations for final presentation, validating stability of modulation circuit with high side LED voltage switching cleanly, designed and ordered 2nd iteration of our smaller power board to easily perform the power up sequence necessary for the EPC600 on interface board (currently done in a tedious manner manually), DCMI alive and able to send data, much of firmware progressed this week. We are much closer to integration of our different components, and close to ready on getting system-level testing done. We have included a photo here of digital signal waveforms that show the data coming back from our image sensors.

Throughout this process, we have learned a lot about both mechanical/electrical integration, firmware nuances, and system-level design. We had to learn how to manage tradeoffs in size and power, serviceability and compactness. We also had to learn a lot more debugging skills for both hardware and software, from new types of breakpoints to PCB X-rays. We also had to do thorough design reviews and learn about the process of analog design, as well as heavy circuit theory for simulation. A lot of this knowledge came from consulting friends/colleagues who are very experienced in these areas, as we had TartanAUV alumni helping in the debugging process and design reviewing our boards.

Posted on

Gleb’s Status Report for 11/22

This week, I have been focused on testing the modulation boards. Last week, we assembled single-channel versions of the LED board and the driver board. Over the last few days, I have used x-ray to inspect the LED board and make sure the soldering is correct, and tested the 24 MHz light modulation. To do that, I used the Illumination board’s LVDS clock source, which is the same setup as we will have in the final application.

The modulation circuit is stable, and we can see that the high-side LED voltage (blue on the screenshot below) oscillates between zero and 24 MHz as required.

I also tested the constant-current driver with the LED board.

Once the illumination boards is ready, I helped Sid investigate power-up sequence of the power board and other firmware issues.

Posted on

Claire’s Status Report for 11/22

Started putting together final presentation slides and updating diagrams.

Currently on schedule, will be working on testing and validation for the final presentation due.

Reading through data sheets was necessary to gather parameters for power consumption and current draw of parts, with recommended layout guidelines. Searching up examples from other schematics and common practices for layout was a method I used to learn.

Watching YouTube videos helped me to understand how to operate some EE tools for debugging that I haven’t used before, like the X-ray.

Posted on

Sid’s Status Report 11/15

This week, I worked on Ethernet validation and board bringup for the interim demo. We were able to get the clock chip working, for which I did a lot of the firmware bringup. All three of us also collectively debugged the LWIP implementation of Ethernet on the image sensor board to ultimately enable our computers to ping the device. I also helped out with rework/soldering and harnessing to connect the power board to the image sensor board. See images in team status report/demo presentation. We got a ton done this week and should be on track! For the next week, I plan to continue debugging DCMI connection and protocol on the image sensor board.

 

For subsystem level validation, I hope to measure the throughput of DCMI after we get the peripheral to work, and see how much jitter is in the frame rate throughput. I also want to measure the memory utilization using ST debugger tools to see how big of a buffer we might need for holding frames depending on the program size in RAM.

Posted on

Gleb’s Status Report for 11/15

  • This and last weekend we were busy assembling and bringing up the boards
  • Assembly and hardware debugging was largely a collaborative effort. My personal contributions were:
    • Placing most components (>100) on the imaging boards and doing reflow
    • Procuring a reflow oven
    • Micro-soldering bodges on the STM32
    • Assisting Claire & Sid with debugging the high-speed clock generator and the ethernet peripheral
    • Assisting Claire & Sid with x-ray imaging the ethernet circuit to find a loose contact
    • Assembling a single-channel version of the LED board (aluminum-core).
    • Testing single-channel LED board in DC mode, and testing the bandpass filter with the LEDs
    • X-raying the LED board to make sure that the BGA package of the modulation shunt IC is reflowed correctly (picture below)
    • Used a differential probe to verify the waveform of the 24 MHz LVDS clock going from the imaging board to the LED board

LED Board Assembly X-Ray

We were concerned that the tiny BGA package of EPC21603 shunt won’t solder well, but it turned out okay! The package can be seen as 6 dots (balls) near the center of the image. One can see the LVDS modulation clock line going from the connector on the bottom to the IC. For the LVDS traces are 0.1mm wide, and the balls are 0.5mm apart.

I assembled the board by hand under a microscope.

 

Testing & Validation

My primary focus will be validating the LED board and the CC driver.

  • I have already done some LED board testing & validation:
    • I have tested the LEDs in DC mode, and made sure that the wavelength of the bandpass matches that of the LEDs
    • I also determined a maximum LED current for safe operation with no heatsink: 0.7 A through two LEDs results in the LED temperature of 105C as measured by a thermal camera.
  • To validate the LED board individually, I will
    • use a clock gen and an external current supply to make sure the modulation circuit works
    • I will use an oscilloscope to check the voltage on the high side of the LEDs and make sure that the snubber circuit is working correctly
      • The snubber circuit is responsible for absorbing high-frequency (100MHz+) ringing when the modulation shunt is opened and closed.
        • I may need to tune the snubber zener diode threshold
    • I will use a photodiode to evaluate the modulation of the light
      • At this point, I should be able to measure the LED bandwidth at different frequencies (By how much does the peak LED brightness decrease when it’s modulated vs DC?)
  • To validate the CC driver individually, I will
    • use an external PSU and an adjustable electronic load to make sure that the current source can supply the nominal current of 1A
    • use a thermal camera to make sure that no components overheat
    • use an oscilloscope to make sure that there are no current spikes during on/off transients