December 2025 Journal Entries

#0074 (2025-12-31): Matt DiPalma - web (misc)

Continued development of Mary-bot. Got the Python bot to more or less successfully run the bash script that regenerates the entire website, though the paths need to be updated for the links and the image references. Still not yet ready for full journal submission migration.


#0073 (2025-12-30): Matt DiPalma - web (misc)

Continued development of Mary-Bot. It now can automatically name images entries. All the user needs to do is type [IMG] in the corresponding place in their text content. Not yet ready for full journal submission migration. I'd like to put in the ability to edit entries thru Discord commands as well.


#0072 (2025-12-28): Matt DiPalma - web (misc)

Continued development of Mary-Bot. She can now track and edit the project list thru Discord commands and populate a new journal .ini automatically along with uploading a set of image files. Another day of work will be required.


#0071 (2025-12-27): Matt DiPalma - web (misc)

Set up VPS with https and attached it to the marian-scientific.org domain. Set up the preliminaries of Mary-Bot, a Discord bot that will automatically push journal entries to the site. Another day or so of work will be required.


#0070 (2025-12-26): Matt DiPalma - 03010 (xMM2)

Updated draft schematic and created PCB design for the main control board using the latest PCB-etching lessons learned. This board will be fabricated in-house. See 03010-002 Kicad project.



#0069 (2025-12-25): Matt DiPalma - 03010 (xMM2)

Created draft schematic for the main control board. See 03010-002 Kicad project.


#0068 (2025-12-24): Matt DiPalma - 03010 (xMM2)

Created SVG for laser cutting & engraving simplified ruler. See project CAD directory.


#0067 (2025-12-23): Matt DiPalma - 22001 (RP2040_AVR)

Incorporated a host of improvements to the PCB design of the 12001 RP2040 AVR programmer into a productionized version. See project entry for a list of the improvements and the CAD files. I can begin to fabricate some of these when I get back from my trip.





#0066 (2025-12-22): Matt DiPalma - 03010 (xMM2)

After brainstorming follow-on math manipulatives with the client, we are launching a prototype effort for a manipulative involving ruler measurements. As was learned on xMM1, moving parts and a tactile input device make the manipulative very engaging for the children. This manipulative will consist of a box with an exposed sliding piece of plastic that the children will need to measure. The plastic slide will be connected to a rack and pinion so it can be driven by a servo to expose different lengths of plastic to be measured. The children will need to place a ruler against the box, and to make sure they line up the ruler correctly with the start of the plastic slide, there will be a reed switch that detects that and shows a green status LED. When the measurement is made, the child will be able to select the value (in half-inch increments) using a pegboard, by putting a peg with a magnet into the corresponding marked circular slot. The different values can be connected to a series of resistors to be able to detect the voltage value with a single ADC pin, versus having to waste a lot of GPIO pins. If the rack and pinion approach does not work due to space limitations, a servo-controlled paper scroll can be used instead.


#0065 (2025-12-21): Anthony Remark - 03009 (MM1 Minute Hand)

Yesterday, I programmed another stm32 bluepill and I added a Logic Leveler from 3.3V to 5V. The second Bluepill was an attempt to power the whole circuit with the micro B usb input. The Top Bluepill's micro B usb has no clearance. So another Bluepill was placed in the bottom and configured to work with the rest of the circuit.


The Bluepill is unable to supply the Max7219 and the Seven segment displays with enough current to operate. Another thing that was discovered is that the Max7219 was not operating as expected. There may have been issues with the code but what is expected is the issue is with the logic levels being sent to the max7219. The Max7219 is configured to receive logic levels of 5V, but the Bluepill outputs 3.3V for logic High. A Logic level is used to attempt to correct this issue. But the expected operation was not observed. The Max7219 was not displaying anything. An attempt to understand why was made using the Analog Discovery Oscilloscope feature.

The Blue signal reading from the oscilloscope is the CLK signal before the logic leveler. So it's from the bluepill.

The Yellow Signal reading from the oscilloscopre is the CLK signal after the logic leveler.

Together, both signals are like this,

But This doesn't tell us much. If we zoom into the signals, we get this:

But this essentially tells us nothing because we know the CLK signal is supposed to be a pulse Train with a period. So when the sampling is turned up to 100 MHz, we get something that looks like what the CLK signal should look like.

Well, we have a lot of Squiggles that shouldn't be there. My hypothesis is that the Logic Leveler is corrupting the signal. When learning Digital Circuits, the class stresses that the signal delays and the degrating of the signal are important variables to consider when designing a circuit. It seems that the Max7219 is not 'in time' with the bluepill because of the logic leveler. The Remedy for this is perhaps alteration of the shiftout function, or making our own shiftout function that doesn't need to be soo fast. Or we can use the atmega chip instead of the bluepill, but that would require great alteration of the code.


#0064 (2025-12-20): Matt DiPalma - 12001 (RP2040_AVR)

Designed programmer PCB and attempted to create a DIY PCB at home using etching solution. See video of it in action. First two attempts were using photoresist, so the mask was negated.


I didn't have a reliable source of UV, so I used the New England winter sun...


...which overexposed the photoresist after 10 and even only 5 minutes. Also I had bubbles in the film because I applied it with a clothes iron, whereas a laminator would have done a far better job. In any case, these two attempts failed.


So I tried the toner-transfer method. I did a much better job of cleaning and scuffing the copper-clad board using 240-grit sandpaper and acetone.


I printed a non-negated (and unfortunately mirrored, a mistake) plot on glossy paper using a laser toner printer.


I ironed the paper onto the copper-clad board,


...and dissolved off the paper over 30 minutes in some warm water. You have to get everything off, even the white paper haze that might find itself between pins and traces that will otherwise prevent the etchant. Noticed I failed to do this on the right, where the RP2040-zero mounts.


Then I set the board in Ferric Chloride and gently agitated it for 10-15 minutes outside. If I had made most of the board the ground plane, it would have gone a lot faster because less copper would have needed to dissolve away.


It turned out pretty well, but notice there was still some copper between the pads on the top of the board.


So I wiped the remaining toner off with acetone and popped some holes in using a very small 0.8mm endmill. In retrospect I should have made the copper pads larger, because I drilled out most of the copper even with my smallest endmill. I also drilled out a hole for the underside of the rp2040-zero board, which although it has castellated edges, cannot be set flat on a board without cutting away the board beneath it. Then I began soldering components. Again, in hindsight, my traces should have been on the opposite side of the board as my components, because they were extremely challenging to solder because the pads were directly beneath. In the future, traces should be on the background copper face if the components will be mounted on the top, and that would not have required that I even mirror the board plot in the first place. I could have also toner-transferred some nice-looking component labels and even a part number if I had set the traces on the opposite side as the components. Either way, this investigation was a learning experience, so I don't mind the soldering challenge and all the other added complexity.


The photos below show the final product which actually works well as an Atmega328P programmer; I tested several blink programs. The rows of header pins also almost make this into an Arduino-like devboard, though it lacks any external oscillator or other peripherals. I did have to shave down the bottom of my USB-C cable so it could come in flush. A lot about this whole project could be improved significantly, but I had a lot of fun with it. This investigation was a massive success, and we did barely manage to complete it on schedule.




#0063 (2025-12-19): Matt DiPalma - 12001 (RP2040_AVR)

Got the programmer working, which was a combination of the code running on the RP2040 and a Python script transmitting the serial data over USB from my PC. See video.


#0062 (2025-12-18): Matt DiPalma - 12001 (RP2040_AVR)

Wasted ~2 hours today alone tracking down a very dumb mistake - I was off by one on the SPI pins on the Atmega328. No wonder I wasn't getting a response. I completely obliterated the code trying to track it down, so I will reconstitute something clean tomorrow. The AVR chip nonetheless acknowledges our attempts to program it now.


#0061 (2025-12-17): Anthony Remark - 03009 (MM1 Minute Hand)

Yesterday, When the Mounted seven segment displays arrived, I realized I has a little problem. This is a front that was designed by myself for MM1 Minute hand.


So we had a little problem. The slots cut out at the top were for smaller Seven segment displays. No matter, the solution was to either go with the original plan, which was to use a small perf board and solder everything needed. And this would take hours. OR

Today, we acquired plywood and cut out the necessary parts.

This material had maple veneers on both sides and a particle board middle.


#0060 (2025-12-17): Matt DiPalma - 12001 (RP2040_AVR)

Finished a likely buggy implementation of both the rp2040-USB-programmer and the PC-based hex file transmitter using python. See code directories 005 and 006. The clock and data transmission works as expected, but for some reason the Atmega328P is completely unresponsive; no signal is being transmitted back over MISO.


#0059 (2025-12-17): Anthony Remark - 03009 (MM1 Minute Hand)

A few days ago, there was a lot of work done. The circuit was constructed on a breadboard.


The Team constructed the encoder circuit and it uses a 74LS00 to interface with the stm32 bluepill. The bluepill interfaces with the Max7219. The Max7219 is wired for 2 seven segment displays that are supposed to disply the position of the minute hand.
Below are plans of the corresponding position of the EN16AB encoder to the expected output of the Max7219. The Binary column was my reading of the outputs of the Encoder. The Green column is the properly written binary output wit the Leftmost bit treated as the Most Significant Bit.

The issue of the 12 position encoder is that the binary outputs do not follow an obvious chronological pattern, so An array was constructed to extract the necessary data.

We conventionally discribe the sequence of binary numbers as following an increasing number pattern. But the Encoder doesn't output that. So We use an array to organize whatever is given from the green column (the output of the encoder corresponding to the position) to something that the code can use. This 'something' is a workable sequence of numbers to tell us what position the encoder is at.
Below is the myArray array we use. We use a sequence of binary numbers to correspond to decimal numbers. For example, the 0010 number is supposed to be the 3rd number but we have to use it as the 1st number because the EN16AB datasheet says this is the first position output. I decided to follow that convention. Another example is that 1100 is not the 10th number in binary counting but it is the 10th position output on our chosen encoder, so we set the content of that array to be 10 which corresponds to the 10 position of the encoder.

Last image is the notes on how the data from myArray will be used and the operations that will be done to feed the Max7219 the proper value to the appropriate address.


#0058 (2025-12-16): Matt DiPalma - 12001 (RP2040_AVR)

Soldered pins to the RP2040-Zero board for preliminary breadboard tests. Got control of the built-in RGB LED working over PIO (very interesting and powerful) and began working the ICSP algorithm. Link to top-level project directory..


#0057 (2025-12-15): Matt DiPalma - 12001 (RP2040_AVR)

Launched short-term investigation into developing a RP2040-based programmer for AVR ICSP-capable chips, especially the Atmega328P. After internal discussions 2025-12-14, both of these chips seem to be the best avenues for future electronic project development. Completed first three preliminary tasks establishing a functional Atmega328P and RP2040-zero toolchain to complete the remainder of the investigation.


#0056 (2025-12-15): Matt DiPalma - 03007 (AFSM)

Received 6 of 6 (no extras) 03007-001 stepper coil-driver PCBs from OSH Park. They arrived in 15 days. The communication from the company was far better than DKRed. The board quality is decent, and the price is comparable. Boards (purple cheapest and default option) do come with jagged edges where they are broken from a larger PCB platter. I do prefer them to DKRed.


#0055 (2025-12-14): Matt DiPalma - 03008 (xMM1)

Recorded final video of manipulative working. The prototype will be used as a template for a future productionization effort and, afterwards, permanently donated to the test classroom.


#0054 (2025-12-12): Matt DiPalma - 03008 (xMM1)

Tested the project with 6-7 year olds, and it was a massive hit. Kids were fighting over the 3 magnetic input blocks, and I kept a half-dozen or so busy for around 15 minutes during dismissal. They thought it was professionally-made. I think one factor about the manipulative that they enjoyed was the tactile nature, which is not something familiar to them in an age of touchscreen-everything.


#0053 (2025-12-11): Matt DiPalma - 03008 (xMM1)

Project complete 3 days early. Made final updates to the full project code to fix the RNG and the intermittent failed 7-segment initialization. Also somehow the power draw is now high enough that it doesn't seem to automatically shut off the USB power bank, though the power bank still reads 100% after 3 days of testing. Designed a new 03008-010 input block with standoffs and a bigger grip area. See latest CAD. Printed two versions in new white PLA and applied the 'Alligreater' image (one mirrored) to the front with a glossy transparent parent sticker. Will test this device with the children tomorrow.




#0052 (2025-12-10): Matt DiPalma - 03008 (xMM1)

Updated the full project code. Entire project essentially works - including the buzzer, RNG, LEDs, magnetic inputs, etc. See video of it in action. Still needs an improved input block and there is still a glitch where it sometimes initializes with 88/88 on the displays.



#0051 (2025-12-09): Anthony Remark - 03009 (MM1 Minute Hand)



Above is the test setup for testing how the encoder works and how the toggle switch works Also I did more planning for the infacing of the stm32 and seven segment displays with the Max7219 chip


#0050 (2025-12-09): Matt DiPalma - 03008 (xMM1)

Toyed around with the code for a while, but there is something amiss with the buzzer control timer and the rest of the control logic, so I implemented a buzzer-less version. Had to improve the solder connections, but everything fits in the box pretty well. Needs to be cleaned up slightly. See video of it in action.


#0049 (2025-12-08): Matt DiPalma - 03008 (xMM1)

After 2.5 weeks, received 03008-006 PCBs from DKRed. Board quality very good, no mistakes were made on my end or theirs. Silkscreen font kind of squiggly in places. Overall experience was positive, though very slow. They sent 2 extra boards (6 instead of 4). Should probably make the thru holes slightly larger next time. Soldered 7-segments and JST connectors to the PCB and tested some sample code to display digits. There is some software/hardware glitch that is interfering with the buzzer and LEDs. Also, had to hand-crimp the individual JST metal pins to each wire using needle-nose pliers, as the junky JST crimpers I purchased are terrible. I also prepared two additional boards to be shipped out to support the 03009 project.




#0048 (2025-12-07): Matt DiPalma - 03008 (xMM1)

Behold a rasterized version of my 'Alligreater' SVG to be either laser engraved cut or printed/laminated/pasted to the front of the magnet block.


#0047 (2025-12-07): Matt DiPalma - 00001 (CNC Mill)

Put final counterbores into X-Y gantry plate and test-fit the linear rails and ballscrew ball nut carriage block. Somehow miraculously everything is aligned. I do still need to put in tapped M5 mounting holes for attaching things.




#0046 (2025-12-06): Matt DiPalma - 03008 (xMM1)

Compiled the full project code from the minimum viable test cases, but I am unable to test it easily until USPS delivers the 7-segment breakout PCBs, which were supposed to be delivered yesterday.


#0045 (2025-12-05): Matt DiPalma - electronics (misc)

Threw a quick GPS data display together using a Pi Zero (overkill, used only for the USB GPS dongle). It shows lat/long/alt/speed and the fix status and number of satellites observed.


#0044 (2025-12-05): Anthony Remark - 03009 (MM1 Minute Hand)

Here is an isometric view of 03009 MM1 Minute Hand with a 'cutoff' from the front panel. The purpose is to show that the Gears are fastened and secure rather than not.


In the Cross Sectional view, we can see that the Driver gear (minute gear) is secured onto the shaft of the Encoder.
The Encoder is secured in place on the Anchor panel. The Front panel has a hole that allows the Minute hand and the hour hand will be visible and freely move while the gear mechanism is hidden.
The Encoder is hot glued to the Anchor Panel.


Behind the Front Panel, We can see more of the configuration of the Gears. The Second gear that's driven is secured to the 3rd Gear and both are freely rotating on a 1/4 inch dowel. This dowel is planned to be hot glued to the front panel, or the anchor panel.

From the left Side of the Isometric view, it's more clear that the Dowel will have a 'cap' configuration to prevent the Gears from wandering out of place.


#0043 (2025-12-04): Matt DiPalma - web (misc)

I updated the web journal-generating script to add some additional info and formatting.


#0042 (2025-12-03): Matt DiPalma - 00001 (CNC Mill)

Began to drill and counterbore mounting holes for the X-Y gantry plate. These slotting counterbore bits are really nice but get gummed up quickly and stall the motor of my weak drill press. Also have to use a cordless drill to reach the central holes. Would be nice to make a nice drill press.


#0041 (2025-12-02): Matt DiPalma - 00001 (CNC Mill)

Took inventory of CNC mill project after long hiatus. Updated CAD model to reflect length of installed collet and bit and migrated to organization repository. Marked out the drill and tap locations for the X-Y gantry plate.








#0040 (2025-12-01): Matt DiPalma - 03008 (xMM1)

Snipped down main circuitboard to fit snuggly inside the box. Debugged minor soldering issue with one of the RGB LEDs. Wrote this code to control the lights in unison with the buzzer depending on the reed switch status. See video example.