Project Journal for Brendan McLaughlin

=============== Week 15: =================

Entry 4: -----------------------------------------------------------------

Date: April 24th
Start Time: 11:00am
Duration: 6.5 hours

We reconvened more energized to test more modes before the demo. I spent the majority of this time debugging modes and giving input on how to improve what we had. The code often threw errors due to mismatched JSON names between the app and the Pi, but that was always a simple fix. We also found that the Bluetooth is sometimes buggy when multiple users try to connect to it, so we actively avoided that to speed up testing. That is a problem that can be addressed in the future. Krish updated the computer vision to be more accurate, but at the expense of running much slower, and we added a post-insertion deck check to make sure that all cards have been found and that we are presenting a standard deck to the algorithms, this fixed basically all the rest of the algorithmic errors. I believe the main problem with the computer vision we were running into was the RAM limits of the Pi Zero, so we made plans to upgrade at this point, but only after the demo since we didn’t want to break anything.

More and more modes were working at this point, especially after Johnny reprinted the card weight tray. This eliminated all double feeds, except in the edge case of the second to last card. I worked with Johnny and Craig to adjust the motor parameters after Craig wrote the code for this case, and we got it to function properly about 20 minutes before the demo. I also tested to make sure the code would run on bootup using the cronjob I created last week, and it initially failed when I just rebooted the Pi. I am not sure what happened in this case, but I suspect it had to do with unexpected UART communication from the STM which was still on at that point. I then tried to just full power cycle the entire device, and everything worked like a charm. It is annoying how long it takes for everything to start, but that is a future problem. We then had the demo, where everything worked perfectly aside from one slight computer vision error at the end. After a lot of work, our project has been a very great success.

Entry 3: -----------------------------------------------------------------

Date: April 23rd
Start Time: 9:00pm
Duration: 12 hours

I don’t have a perfect memory of everything that happened in this session, as basically everything that could go wrong did over the course of the night. We began by focusing on computer vision, where we realized the code had some major merge conflicts to resolve mostly due to me not pushing code on the Pi since I assumed it would always be the most up-to-date copy. This was a dumb assumption but after we fixed it, we continued problem solving the accuracy of the computer vision, and after showing a real-time display of the output, we found that a small piece of something had gotten under the lens and was obstructing a part of the image. This meant we had to completely remove the camera, which was a hassle since it was fixed in place and meant we would have to retake all of our reference pictures if the new alignment was not identical. After some struggle we got it out and got it cleaned up, and then reinserted it to take new reference images. While doing so, one of our DC motors used to feed cards decided to completely stop working, and after testing with external power we decided the cause was the motor driver on the PCB. Since we didn’t really have time for extensive testing, we decided to take two separate approaches to this issue. Craig and I worked to get the backup PCB working while Krish and Johnny tried to remove the old motor driver from the working PCB and add a new one.

We had never tested the backup PCB at this point, and initially, the backup PCB simply could not be flashed. Cube showed that no device was found, and Craig and I tried everything in the book to get it working. After we checked that all the circuitry was correct, I used the microscope to check the STM pins for any bad connections and found that the reset pin was simply not soldered down. Once I fixed this, the STM booted right up and we began slowly testing all the components on the board, adding parts one by one so as to prevent a catastrophic failure. This was especially annoying since the old PCB used female headers and the new one used male headers. Krish and Johnny were greatly struggling and ultimately decided to stop working on removing the old motor driver, meaning this PCB was our one shot to get everything working. Fortunately it did, and by about 4am we were back to about where we left off in the previous session. I helped brainstorm the computer vision some more, but ultimately we decided that we were quite scared of this happening again and that I should solder a new backup board. Since it was my third (kind of, Krish and I split the two previous boards) it was not too daunting, and I got the STM fixed easily. The lab is out of a bunch of components, so I had to cannibalize some capacitors from the old PCB, resulting in its total destruction. We also had to remove the power header from the old PCB since we only ordered two, which Johnny did by cutting the pins after a ton of work trying to remove it by other means. I then struggled to get the cut pins to fit into the new PCB, but in the end got it hopefully fully soldered. At this point the team was starting to test new modes and improve the computer vision, and we decided to take a short rest break.

Entry 2: -----------------------------------------------------------------

Date: April 23rd
Start Time: 3:00pm
Duration: 4 hours

During this period we got everything to an almost working status. The entire system integration worked and was feeding cards in and outputting them in a mostly correct order. I was mainly working on robustness testing of the device and making sure that everything was in order, and helping to brainstorm ideas on how to get the computer vision working better. At some point the wheel started skipping during testing due to high friction between the cards and the gate, which we initially attributed to the servo motor not pressing hard enough into the slot. We switched servos, which fixed the issue at first, but after a few runs we noticed it losing power and found that it was running extremely hot, enough to melt the hot glue that was helping to fix it in place. After determining that this was not normal and replacing it, Johnny and I also brainstormed ways to reduce friction through the design of the gate, and he left to print a new one. I also assisted him in building the box while working at this time, although I did not do much.

Entry 1: -----------------------------------------------------------------

Date: April 23rd
Start Time: 9:30am
Duration: 3.5 hours

This was a very long day of bug fixes and integration that I was much more focused on than writing this journal, so I do not have a lot of detail. We started by ironing out the kinks in the control code and testing, which worked mostly well. We had to align the wheel and the feeder to make sure that it was feeding properly, and it did after a bit of motor tuning. I readded the error checking code that I wrote last week since it was throwing errors in my absence, this time it worked properly, although there were a few issues when the computer vision did not recognize a card, which I fixed. During this time the computer vision was a bit inaccurate, so our goal following this session was to improve that.

=============== Week 14: =================

Entry 5: -----------------------------------------------------------------

Date: April 18th
Start Time: 11:00am
Duration: 1 hours



A small syntax error made it through since I have no real way to test the code I am writing, but this was a simple fix. After this I updated the main code to check the two error conditions, first where the card is the same as the previous, meaning that it was not dispensed properly, and second where the prediction is not valid, meaning the card is not aligned. Both of these require sending a UART signals, which I need to talk with Craig about since he is most familiar with that. It did require a slight change in the main logic, since it needs to wait until a valid next card is read, and without being careful this could cause threadlock. Right now the logic is to idle in a while loop, constantly grabbing the lock, checking validity, then releasing it. This should work in theory, but it could fail in practice, which is quite annoying since I can’t test it at all.

Entry 4: -----------------------------------------------------------------

Date: April 17th
Start Time: 2:00pm
Duration: 1.5 hours

I am in Phoenix so I am doing my best to get done what I can, Krish finished up the computer vision code so I am trying to first understand then port it into the main driver code. After discussing with him, I found the right driver file and ported it into the main to run in a separate thread. From my understanding, it runs a constant video feed that is always outputting the best guess of what the card is. I simply need to make that guess available to the main thread so that it can build the deck, and safely so that there are no edge cases where it changes mid-use. Fortunately I have written a lot of multithreaded programs so it was simple to just add a lock to the curr_card variable which holds the guess. As long as nothing is attempting to idle with the lock it should be safe. I discussed with Krish what conditions we need to handle, but for now I just wrote the base case of a valid card read, then pushed it through.

Entry 3: -----------------------------------------------------------------

Date: April 14th
Start Time: 5:30pm
Duration: 3 hours

Since I still don’t have too much code to work on, I soldered a backup PCB. This turned out to be pretty simple, as the only part I was worried about was the micro. I got it aligned on the first try and aside from adding a bit extra on one of the sides it soldered perfectly. I guess I have gained some soldering skills since the last practice. Everything else was just time consuming, I took a few breaks to help Krish diagnose issues with the computer vision code, it seems like his initial approach was too RAM intensive, but I am not sure what he did to fix this. I soldered everything on the backup PCB besides the heartbeat LEDs, the capacitor that we need to flywire (since Krish did the last one and I imagine he is more comfortable doing it), and the header pins since we do not have any right now.


A small syntax error made it through since I have no real way to test the code I am writing, but this was a simple fix. After this I updated the main code to check the two error conditions, first where the card is the same as the previous, meaning that it was not dispensed properly, and second where the prediction is not valid, meaning the card is not aligned. Both of these require sending a UART signals, which I need to talk with Craig about since he is most familiar with that. It did require a slight change in the main logic, since it needs to wait until a valid next card is read, and without being careful this could cause threadlock. Right now the logic is to idle in a while loop, constantly grabbing the lock, checking validity, then releasing it. This should work in theory, but it could fail in practice, which is quite annoying since I can’t test it at all.

Entry 2: -----------------------------------------------------------------

Date: April 14th
Start Time: 4:30pm
Duration: 3 hours

Honestly I don’t have too much to write for this session, since my work is done for now until the Computer Vision Code is ready to be integrated, I just floated in the lab supplying ideas and helping to support where I could. We were mainly focusing on integrating the card feeder, since Johnny had a new print where the front roller was all the way at the end of the feeder. This made a massive difference, as cards now effectively shoot out instead of just sliding and falling out. We tested a few different weights since we know we will need to press the cards down into the rollers. Light weight was enough for the majority of the deck but once the end of the deck was reached it didn’t work as well. More fine tuning will be required.

Entry 1: -----------------------------------------------------------------

Date: April 12th
Start Time: 2:30pm
Duration: 5 hours

I got to the lab a bit early, so I soldered on the button header pins and the associated resistors and capacitors, I had to look up why the capacitors had no markings. It turns out the small capacitors we are using for that part of the circuit are unpolarized, meaning the direction doesn’t matter. I was able to solder them real quick, and then I also soldered most of the rest of the header pins.

Next, Krish and I hashed out the rest of the bluetooth issues. When we left yesterday we could send and he was updating the app to send code properly formatted. It worked basically out of the box today, sending proper JSON packages that the Pi read flawlessly. The only issue that we ran into is the case of userSpecs, which is where the user specifies the community cards and what each player receives. For some reason the app could not send buffers larger than 182 bytes, and the dictionary data structure was larger than this for most use cases. Krish updated the app to send it as a list, where the first five cards are always the community cards and then each pair after that is a user pair. I then wrote some quick code on the Pi side to parse this out into the dictionary that the sorting algorithm needs.


We standardized the last few modes and theoretically every part of the Bluetooth system is working. There has been no testing done for multiple devices attempting to connect, but that level of robustness is likely outside the scope of our project. Next we added the ability for the app to read the winner characteristic, this is set once the algorithm is run and the cards have all been read. While all of this was happening, we were both helping to provide ideas on how to vector the card feeder motors, since Johnny and Craig are fine tuning how to make it spit out exactly one card every time.

Turns out this winner characteristic was slightly annoying to get working, we wanted to send -1 to show that the winner was not yet determined, but that is throwing a dbus encoding error.


We fixed this by just sending 0 instead of -1, and everything worked properly after many attempts to get -1 working. The app now properly shows who the winner will be.


After we took some time to consider changes to the feeder, since it is very inconsistent even after lots of fine tuning by Craig and Johnny. The rubber bands we are using to get friction on the cards are not consistent all the way around since we need to double them up, so we are looking into alternatives. We considered a new roller with rubber wheels and a few other new configurations of the rollers, with the leading design something where the rollers pinch the cards together and then spit it out at high speed. We ordered some new rubber bands and we are planning to move one of the rollers to the end of the feeder. We also laid out the footprint so that Johnny can print the electronic box and we understand where every part will be.

=============== Week 13: =================

Entry 6: -----------------------------------------------------------------

Date: April 11th
Start Time: 2:00pm
Duration: 1 hours

I talked with the TA because one of our flywired capacitors ripped off the pad it was soldered to, there is nothing we can do. I think we’re going to just use a larger capacitor soldered to the other set of pads it was in parallel with since it is just a decoupling capacitor for our stepper motor driver. We found a 220uF capacitor rated at 35V that should work perfectly.

Once Krish got here we started working on the Bluetooth once again, we synchronized our JSON formats so that the data would be passed properly. Not much of a change, mostly just simplifying things on my ends because we can reuse multiple fields.


This is the new JSON template, topInt now holds the values for time and for phone number modes. We standardized a few of the other fields, like agreeing on a 24-hr clock sending hour and minute for the time mode, and moving the settings JSON object to three separate booleans.

Entry 5: -----------------------------------------------------------------

Date: April 10th
Start Time: 2:30pm
Duration: 4 hours

I updated the logic of the main Pi code to allow for persistent settings and new game modes, it’s hard to test right now because I need the STM connected as well for UART signals to send the start command. I also added more logging to make sure we can more easily tell what the Pi is doing. After, I soldered header pins onto the homing sensor daughterboard so that we could test that in the system.


Craig noticed I soldered on the photodiode backwards, so I used chipquick to remove the diode and then solder a new board since it was not great in the first place. After testing it worked properly, and then we integrated it into the system and used it for homing. We then spent about an hour just testing different aspects of the integrated system and discussing potential failure points and updates we want to make. The wheel shield that keeps that cards inside is a bit too close so we are expanding it, and we need to make sure that the gate is fully closed, otherwise cards have a tendency to get caught. If this happens the stepper could skip, making our sorting effectively useless.


At this time, I also deconstructed our power supply in the hopes that I could remove some of the unused connectors, since we only need the single 24-pin header. However, after opening it up it is clear that we cannot remove them, so I just closed it up and we plan to just push them to the side.


Following this, Krish and I worked on the Bluetooth connection between the app and the Pi. First we translated the JS code that I was using to test the app. This got a preliminary connection working, so we were able to discover the Pi and send some JSON data to it. It is not currently formatted correctly since we did not communicate too much on the actual structure of the data, but that should be a relatively simple fix in the future. Right now the important thing is that the Pi actually gets data and attempts to interpret it.

Entry 4: -----------------------------------------------------------------

Date: April 9th
Start Time: 11:30pm
Duration: 0.5 hours

I stopped in the lab after my volleyball practice to help solder the USB-C connector, the team was having difficulties and I have the most practice. After removing the existing solder I tacked it all down, then we tested to make sure it was supplying power properly.

Entry 3: -----------------------------------------------------------------

Date: April 9th
Start Time: 9:30am
Duration: 3 hours

Started today in ManLab with most of my specific work done, so I am trying to float around and help where needed. I soldered the heartbeat LEDs onto the board so that we can hopefully see if the power is propagating properly.



I then helped Krish get pictures of the sighting window for our computer vision, we finally have our camera and flashlight working, so it was pretty simple to run the script after aligning the parts and get some photos. We tried as a team to turn on and flash the STM via an STLink, but on diagnosis one of the diodes was preventing any current flow so nothing worked. In the meantime, I am trying to set up the Pi to run the necessary code on boot up, the best way I know to do this is to use Cronjobs. This should be simple by just adding ‘@reboot /path/to/python3 /path/to/main.py,’ the path to Python should just be /usr/bin/, and I used ‘realpath’ to show the absolute path to the main code, which is ‘/home/pi/SmartCardShuffler/integration/main.py’. After running ‘crontab -e’ I added this command to the end.


After rebooting and using ‘htop’ I can see the code running properly in the background. There is no monitoring file, so I need to update the cronjob to push the output into a logger file. I am not exactly certain how to stop this, I am using F9+Kill and that seems to work for now. I used >> to push the output in to a log file, and the log file is created, but for now it is not populating any data from the code. After some reading, I used ‘chmod 666’ to make sure the log file has the correct permissions, and I set the PYTHONUNBUFFERED environment variable to 1 in the cronjob. This seems to have worked, now I just need it to clear the file every time it runs.


This was a simple fix removing some old UART code that I missed, after everything appears to be in order. Now everything runs properly in the background, there may be some hiccups with the code if the BLE server is restarted later in the sequence, but that is a niche edge case that we can easily deal with later.

Entry 2: -----------------------------------------------------------------

Date: April 8th
Start Time: 2:30pm
Duration: 1.5 hours

I spent the majority of this time discussing integration between the Pi and the STM32 with Craig, since he had already written some Pi code to interpret UART. I migrated all of this over to the full integration code and tested it, and removed some unnecessary UART handler code since it became obsolete. Now the majority of the processing occurs within the main loop of the program, which should make it a bit easier to program and debug. We also had one of our software PSDRs checked off for running the sorting algorithm on the Pi, this took a bit of work since the code was configured to rely on the GATT server for JSON parsing and I had to manually configure it. After that everything worked as expected

Entry 1: -----------------------------------------------------------------

Date: April 7th
Start Time: 8:00pm
Duration: 0.5 hours

I discussed the current progress and went through the packages we finally received containing all of the necessary components. Everything seems to be in order besides the power header, which contains the right number of pins but is simply too small, so we will have to order a new one. I also discussed soldering the STM using the hotplate instead of manually, which we both agreed to do. I left to work on another lab, and came back when he finished. I then checked the solder to make sure all of the pins were soldered properly, everything looked good besides one or two pins that needed a bit more solder to fully connect.

=============== Week 12: =================

Entry 5: -----------------------------------------------------------------

Date: April 3rd
Start Time: 6:30pm
Duration: 3.5 hours

I wrote A10 Reliability and Safety Analysis.

Entry 4: -----------------------------------------------------------------

Date: April 2nd
Start Time: 9:30am
Duration: 2 hours

In mandatory lab I discussed with Craig what signals will be passed between the STM and the Pi, we determined that the order will be as follows: STM sends ready to Pi, Pi sends Start signal to STM, Pi sends card slots in order to load, the STM mirrors them back after loading, Pi sends unloading, STM acknowledges, Pi sends card slots to unload, STM mirrors them when done, Pi sends done, STM mirrors end signal. I also confirmed with Krish that likely the card detection will take less time than it takes for the STM to load a card, so I do not need to be concerned about saving the image files or threading the card detection algorithm. We also discussed changes to the card slot opening mechanism and ultimately selected a new design that hinges the opening to release the cards, and discussed whether to use a metal shaft or a 3D printed, deciding to print the wheel with capabilities for both. We attempted to find some SMD capacitors that would fit in the available space but there is not much available.

For future reference when connecting the app to the GATT server, I think it will be a good idea to check for error on every transaction so that we can make sure that everything is operating properly. Also, I think it might be beneficial for the Pi button to reset all of the threads instead of just the BLE thread, but that will slightly complicate the transaction with the STM.

Entry 3: -----------------------------------------------------------------

Date: April 1st
Start Time: 11:00am
Duration: 0.5 hours

I rebuilt the poker game mode to be more bare bones, now all it does is set the shuffler and create the first game’s deck order. The iteration will be handled by a get_deck_order function which will return the shuffled deck order, but if the mode is the persistent poker game, then it will regenerate and increment the games played by one. When doing this I also recognized that we will need a separate UART listener thread, because the STM will occasionally send unprompted UART codes (READY/ERROR) and we can’t really have the main driver code constantly listening to the port instead of performing its operations. To fix this I just added global variables for ready_flag and error_flag, as well as a daemon thread that constantly reads from the port and sets these flags. Likely this will conflict with any other attempt to read UART codes because I am not sure how threads will be prioritized, so this thread will probably need to be expanded.

Entry 2: -----------------------------------------------------------------

Date: March 30th
Start Time: 9:45am
Duration: 2 hours

I took some time to port my Neovim setup to the Pi so that I could use a few extra features, it will make development easier and I won’t have to fight my muscle memory. After this I implemented the rest of the gamemodes and tested each one to make sure it properly generated a new deck order. I think that no_pocket_pairs( ) is broken, it was not generating what I expected but I want to talk to Krish before I do anything. Similarly, the implementation for poker_game_mode( ), where multiple games are played to achieve a set probabilistic spread of winning across players was built in a vacuum, so it will need to be adjusted to work properly in our system. Right now it does the iterations on its own, but in the full system it will need to wait for a button press/ UART signal from the STM to iterate again.


I also resolved the Git issue, I just needed to set a divergent branch resolution strategy. I set it to merge because that is what I am familiar with and generally presents the least problems, and after I just pulled the remote changes and pushed my own with no issues.

Next since I need to wait to confer with Krish on the main code, I moved on to the Pi-STM UART connection. Only one byte is passed at a time across this line, but that is all we need. 0-51 will represent the card clots, then we can have other values between 52 and 255 represent any control signals we might need. I created an enum class to standardize these codes that way it is easier to change in the future.

Entry 1: -----------------------------------------------------------------

Date: March 29th
Start Time: 2:00pm
Duration: 6.5 hours

I intend to get a lot of work done today, starting with organizing all the components for the PCB solder. I probably won’t solder it yet since we don’t have the power header or the STM, but I may at least test the power circuits. I had to install KiCad 9 on the lab machine because my Arch Linux system does not have support for it, and while it installed I practiced soldering another micro, this time the same size as our STM will be. It was much easier this time, I think I am getting the hang of it as long as I use the proper flathead soldering iron. After installing KiCad I generated a Bill of Materials CSV file to see exactly what I would need and then collected the components.


A few of the components do not seem to fit, specifically the 100nF and 47nF capacitors. We may have to special order them, since as they are we almost certainly cannot use them. I will confer with Johnny since he is a lot more knowledgeable about the components. After this my practice solder was dry, I tested (almost) all the pins and everything seems in order except for a single corner pin that was bent upward slightly, not a hard fix at all.

I next soldered one of the breakout boards that contains the homing photoresistor, the 1 megaohm resistor does not come in a size that really fits the pad, but I was able to make it work. Soldering the photoresistor was not hard but I was not able to properly stabilize both the board and the photoresistor, meaning it is a bit tilted on the board. I tested all the connections and everything is in order, but I may try again in the future to make everything look better.

Moving on to software now since I can’t really do any more productive soldering, I tried running my changes from last session and it is again failing to register the service with the Bluetooth client, so I just rebooted. This worked properly and now I can connect as before, but something about the connection isn’t working properly. I did update the GATT server UUIDs so that the ERROR and CONFIG characteristics weren’t in conflict, but this is a separate issue. I tested it on my old Windows laptop and everything appears to be working fine, so it may be an issue with my Chrome web tools. I did some extensive testing with web tools and other environment factors, but nothing seems to work on my Linux setup. I am guessing it has to do with the Bluetooth stack that I am running, but as of now I do not have the knowledge to fix this, and it simply is not worth the time that I could spend developing more needed features.

I changed the code to not attempt to register a new Bluetooth application on restart but instead just gently quit and then re-run the existing defined one, and this works perfectly.


I reconnected the button to test the actual process and for some reason when the server restarts internally everything works properly, but when I try to use the button restart it resets the server object and the causes a thread crash.


The ‘is_ready()’ function should return whether the server is ready to receive a config. This ensures that the server does not reset when the shuffler is actively running, but the server object is being set to None on button press for some reason. The bug was just a line of legacy code that set the server to None on restart, which is not necessary because of the way the restart is handled.


The next step is actually loading the config sent by the app and initializing the correct shuffler. I had to go into all the dependencies in the Algorithms/ directory and add . before the local imports to tell the compiler where the imports were, and then all the imports ran smoothly. Krish has already written functions that properly use his created classes to selected the proper shuffler, run the algorithm and get the proper order, so I just need an overall function that can choose which function to use and to adjust those functions to pull data from the proper source. After considering what all is needed, I am building a separate ConfigReader class that will initialize based on a loaded config and current deck order and then be able to read the config and return the deck order as desired. This could also be structured as just an overall function, but if in the future we decide we want to allow users to change the config when cards have already been loaded, this will make that code update mostly trivial, and it is just overall more flexible.


I started by just getting one of the functions Krish wrote to work, the unopened_pack() function. After some dumb syntax errors everything worked basically right out of the box, it pulls the config, matches the mode, and then generates the proper new deck order. I next implemented the colors separated algorithm, but this is giving me a bit more trouble. The config is reading properly but the shuffler just isn’t generating a new order. The card on top function worked perfectly once I formatted the input config correctly, so it is an issue specific to the colors_sep() function.

I found the issue, it was just checking for the suit in the wrong part of the card ID string. My guess is that it was one of the first functions that Krish wrote, and he later updated the card ID format but forgot to change that. I changed two lines and everything worked. I implemented a few other functions with no problems, and I encountered an obvious issue when adding poker_user_select_cards(). I can tell from Krish’s debug notes it requires a dict with integer keys, but I was passing a JSON dict which has string keys, should be a very simple fix. Once the function was changed to cast the keys to strings everything worked perfectly.

I am calling it here, the Pi software can currently handle the following modes: “unopened_pack,” “colors_sep,” “card_on_top,” “palindromed,” “int_on_top,” and “poker_user_select_cards.” Adding the rest of the features should not be too bad now that the framework is in place, then all that needs to be done is the actual sending of card slots and the computer vision. I know Krish is waiting for the packaging to be done so that he can see the image the model will be working with, and Craig has worked a bit on the UART card slot transmission, so I will have plenty of support. For some reason my GitHub credentials are not letting me push, but that is a future issue.

=============== Week 11: =================

Entry 4: -----------------------------------------------------------------

Date: March 27th
Start Time: 5:30pm
Duration: 3 hours

I learned how to desolder a microcontroller from the PCB from a TA using the vacuum solder thing so that I could practice again. After pulling off the chip it appears I did not properly clean the board, as there was a lot of gunk on it which I presume was corrosive flux. Regardless I tried to resolder it again, I had more success tacking it down when first applying solder to a corner pin then connecting the micro. Alignment was still hard and I accidentally tacked down the other corner when it wasn’t fully aligned, meaning it would not work properly. I just practiced soldering the sides that were properly aligned, but they were quite difficult since there was some residual solder and I was not using a flat soldering iron. After doing what I could, I went on to practicing more resistor soldering on the practice PCB, it is not too hard, just time consuming.

I next spent some time verifying the PCB to make sure the traces were all intact, it's a slow process but I think I checked each one using the bench’s multimeter. It should be good to solder when I reach that point.

After I rebooted the Pi since it has been on all break, in the past issues arose when it was on for a while without rebooting, so I want to proactively prevent those. The next step is to actually build the main driver code for the system, so I am planning out the development steps now. What needs to be done is as follows: update GATT server to restart on button press, interpret incoming JSON configuration and create proper algorithm class, send load card signals, read card list from camera (Krish), generate card order, and send card order unloading signals. The two main areas of development I need to work on are the GATT server restart and the interpretation of incoming JSON. I am going to start with restarting the GATT server since it shouldn’t be too hard.

I started with the GATT server restart button, I already had some code to read the button for some testing so it was easy to repurpose for this task. It was simple to have the button_listener thread call a restart function, which ends the current server thread and then restarts it again. When running I discovered a few errors, namely that I also need to restart or change the main thread since it relies on the server object to read data. When the restart happens it creates a different server object, which throws and error if main tries to access it in the overlap.

Entry 3: -----------------------------------------------------------------

Date: March 26th
Start Time: 9:30am
Duration: 2 hours

I talked with Krish and Craig about the future development timeline, I am planning to solder the board over the weekend and hopefully do more work on the Pi main code. I soldered another practice micro, which did not go as well as last time. I was able to use a microscope, which helped, but I had even more difficulty tacking it down and did not get the alignment right at all. I tried to fix it by shifting it while the solder was hot, and I thought I fixed it, but did not notice that another pin bank was misaligned. I soldered one of the full sides and at that point it was too late to go back, so I did my best with the misaligned pins. The solder is pretty bad, but I understand a bit more now how to accurately judge how much solder is needed and how to drag solder accurately. I did not use a flathead iron this time, so it was a bit more difficult. I need more practice before I try actually soldering our micro to the board.

I also need to practice soldering the general components, so I grabbed one of the available PCBs and a few resistors and capacitors to learn how. The components are so small which was difficult at first, I found the best way for me to solder the parts was first to apply flux to the pads, then wick solder onto the pad before placing the component. I would then grab the component with tweezers in my left hand and liquefy the solder with the iron in my right, then solder the component to the first pad. After this it's easy to solder the other pad. I was shaky at first, but after doing it a few times I think I am getting the hang of it. I will definitely practice more before I work on our actual boards, but it is significantly easier than soldering the micro.

Entry 2: -----------------------------------------------------------------

Date: March 25th
Start Time: 5:30pm
Duration: 2 hours

This was the TA soldering help session, we were provided with small test PCBs and microcontrollers to practice on. One of the students who works in the ECE shop then took us to the shop to demonstrate techniques for soldering on the micro. To set up the station in the future, I need to turn on the fume vent thing and the soldering iron, then tip the iron and wipe it off with the sponge. She first added a generous amount of flux to the pads where the micro was going to be placed, then used tweezers and a microscope to align the pins to the pads. Next, she tacked down one of the corners to hold it in place, then made small adjustments while holding the iron on that solder to shift the micro. Once it was fully aligned, she tacked down the opposite corner then applied flux to one side of the pins. She applied a reasonable amount of solder then drag soldered across all the pins and used the copper wire stuff to remove excess solder. After doing this for all four sides, she washed the board with isopropyl alcohol and left it to dry.

I tried to do this myself with moderate success. I wasn’t able to use a microscope while soldering, only for actually aligning the micro, and by far the most difficult part was tacking down the micro in the correct position. I finally got it through trial and error, so next time I need to figure out an actual method to do it right. After tacking down the other corner I attempted to drag solder, a TA said it was significantly easier with a flathead soldering iron, so I switched to one of those, and it was pretty simple to pull the solder across the pins. Removing the excess solder was a bit more difficult than I expected, I found the best success when directly heating the solder with the iron then dragging the copper stuff across it to remove the solder. It took about 30 minutes, but I was able to get a good enough solder on all of the pins and had it checked by a TA.

Entry 1: -----------------------------------------------------------------

Date: March 24th
Start Time: 2:00pm
Duration: 0.5 hours



I came to the lab to check on the arrival of the PCBs and they did not disappoint. I unboxed and took inventory of all the components we got since we ordered a bunch before spring break, and then I did a visual analysis of the PCBs to make sure everything is in order. Everything seemed good, the next chance I get I am going to do a full analysis with conductivity tests for at least a subset of the boards to ensure quality.

=============== Week 9: =================

Entry 2: -----------------------------------------------------------------

Date: March 12th
Start Time: 9:30am
Duration: 2 hours

We spent the majority of the time checking the PCB and schematic to ensure that everything is correct. We removed all of the acute angles and adjusted the via size to be able to fully fit solder wires, and I checked to make sure the USART connection pins were correct. It seems like there are multiple possible pins for a single USART bus which threw me off for a bit, but everything was correct. Craig and I tested whether a resistor was needed to turn on the power supply since it requires two pins to short to ground, the resistor was not needed and we removed it from the schematic. I also worked with Krish to ensure that all of the possible settings made it into the configuration template so that the algorithm integration will be easier.

Entry 1: -----------------------------------------------------------------

Date: March 10th
Start Time: 1:00pm
Duration: 2.5 hours

I am making further progress on the integration, Krish is mostly done with the app so I have a clearer picture of what settings are needed. I noticed an issue when trying to upload my changes to GitHub, the way I installed a package necessary for Krish’s algorithm software by just cloning the repo and importing the files prevents proper management of our repo. I removed this and installed the package forcefully using pip’s - -break-system-packages setting. This is a bit risky since it could compromise the entire Python installation, but since it is a very simple package I feel comfortable doing it. If something is breaking in the future this is likely why.

To fix the issue with communication between the Pi and the STM should be very simple, I was casting integers to strings then ASCII encoding them, which means every value over 9 has two bytes. Changing it to send the raw integer value should fix this, and it did. ‘3’ is ASCII for 51, which shows it properly counted to 52 and received a response back.


Since I do not have access to the motor code currently, I set up the code to easily slot in functions for motor position. The next step is to build out the logic flow so that the more advanced algorithms can be added. I wrote some quick test code to check if the button connection is working, I am testing on GPIO 18 right now due to proximity to the other connections, but it will have to be adjusted to the PCB connection later.


I integrated the button into the prototype framework, we now have the capability to send a config to the GATT server, wait for a button to be pressed, then send the load sequence to the STM.

I also did some research into how to integrate the GATT server calls into the Flutter app’s backend. The best way seems to be through either the ‘blue’ or the ‘reactive_ble’ packages. It seems fairly straightforward to connect to the UUID and turn the service calls into functions. I will confer with Krish on where to go next since he has developed the Flutter infrastructure up to this point.

=============== Week 8: =================

Entry 4: -----------------------------------------------------------------

Date: March 7th
Start Time: 8:30am
Duration: 2 hours

We met in the morning before the presentation to go over the slides and get a rough time estimate. We also made sure that all necessary files were uploaded to the website and that we were completely ready to present. Then at 9:30 we presented for 50 minutes.

Entry 3: -----------------------------------------------------------------

Date: March 6th
Start Time: 4:30pm
Duration: 2 hours

We spent two hours working on the presentation. Johnny showed us the completed PCB layout and we added a few suggestions, and then we finalized who worked on which section. I am doing a few portions of the schematic, the PSDRs and the microcontroller selection, and the low-level software prototyping.

Entry 2: -----------------------------------------------------------------

Date: March 4th
Start Time: 2:15pm
Duration: 4.5 hours

I started this session by diagramming out the process the shuffler will take across the App, the Pi, and the STM32 so that I could better understand what control signals will be needed and visualize where some constraints might arise.


Now that I have a starting point I am going to begin impending the communication between the STM32 and the Pi since that is the bulk of the required communication. Before I begin the team will need a standard JSON format to send data to the Pi, so I’ll define a baseline here for testing that we can iterate on.


This comprises all of the potentially necessary signals for the algorithms we have built, I haven’t talked with Krish yet who wrote the algorithm code so likely these will need to be adjusted slightly. I reformatted the directory structure for the integration task, now there is one directory for the algorithms and one for the GATT server, I had to add an __init__.py to the gatt_server/ folder to treat it like a package so I could do proper importing, but aside from that it works properly. For some reason I cannot start the Advertisement portion of the GATT server now, and I am not sure why.


I rebooted the system and everything seems to work, we have been leaving the Pi on so that we can work remotely when needed and likely it just needed a fresh boot. I did first try restarting only bluetooth which did not work, so actually doing a full reboot is better for this issue.

I am now building out the functionality using the config, I made a template file to import so that we can easily add and update fields when needed and provide some safety when accessing config fields. I also updated the GATT server characteristics to accurately represent the incoming data, e.g. renamed them to ConfigCharacteristic.

After setting up some serial connections to test the additions I made, nothing seemed to work and the serial port simply was not reading at all, it was constantly being filled by zeroes. After much debugging with the help of Craig via an AD2, we realized that I simply connected the common ground incorrectly to the 3.3V channel instead of ground. After fixing this everything worked properly. I was able to send data to the STM32 and receive a response, although it stopped prematurely. I think it was due to some timing constraints since there was no delay between receive and send on either end.


I fixed the timing constraints but nothing changed, so I really am not sure what is causing this issue.

I spent about the next hour working on the presentation, I made demonstration videos for the UART and the BLE connections to show them working and we discussed which team member will present which section, as well as what additional charts we will need to make.

Entry 1: -----------------------------------------------------------------

Date: March 2nd
Start Time: 2:15pm
Duration: 2 hours

I am starting integration work now that general Bluetooth functionality has been established, I started by cloning our project repo onto the Pi so that I could access the actual algorithmic software the team will be using.

It took a bit of work to get the functionality running on the Pi due to the issues I have discussed in length earlier with installing packages. Our software requires a package called ‘treys’ which is fortunately very lightweight, which means that I was able to just ignore a proper install and clone the repo as a quick fix. Hopefully I will find a better solution in the future but for testing right now this is good enough. Below is a screenshot of one of the card algorithms running, the next step will be to send the card order via UART to the STM32 so that it can actually do the sorting.


Then I did some simple testing using the UART test programs I built earlier, where I just connected the proper TX and RX wires and then sent the incoming data decoded into JSON over the TX port. I had to implement a bit of multithreading for this so that the GATT server could be run in one thread while another thread reads the actual fields of the server periodically to make sure everything was working.

=============== Week 7: =================

Entry 2: -----------------------------------------------------------------

Date: February 27th
Start Time: 5:30pm
Duration: 6 hours

We spent about an hour going over the current schematics that include all of the necessary components, adding in protection diodes and making sure all of the pins were correct. We shifted from only driving the two DC motors that feed the cards into the system in one direction to enabling them to move in both directions. This was a simple change to the wiring of the L293D, shifting the PWM signals to the enables and changing the control pins to standard GPIO pins.

I then moved on to working on the Bluetooth once more, I found an open-source project that makes a simple CPU thermometer GATT server and cloned it, it worked right out of the box thankfully. It initializes a GATT server that can be seen from the Chrome Bluetooth Web Tools I am using, and querying it results in this:


Project: https://github.com/Douglas6/cputemp
While it is a concern that it does not state it is connected, the fact that it returns an ID at all and is discoverable is progress. Next I am going to try to hit some of the internal endpoints of the project to understand more how it works.

With the help of some generative AI I wrote a console script to hit the actual characteristics in the GATT server, it basically just connects via the service UUID then hits the characteristic UUID which returns the CPU temperature of the Pi, which can be seen at the bottom of the image.


Note: I tested this when my laptop was paired but not actively connected, it still functioned but was notably slower. I am not sure if this will be an issue in the future with potentially conflicting writes to the server, but that can be resolved once we have more of the app code written. Actually, it seems that sometimes when the device is actively connected it causes the GATT server request to fail:


This seems to be a bigger issue than initially anticipated, usually I can make one or two requests and then the Pi just fails all operations and I have no idea why. In testing I cannot seem to replicate this, it just seems to work on a clean console and sometimes it doesn’t. After researching, I believe that the issues when the device is actively connected has to due with which Bluetooth protocol is in use. The GATT server only works with Bluetooth Low-Energy (BLE), but if actively connected the device may attempt to use a different protocol. For now I will be working without this connection, it may result in some security vulnerabilities, but for now that is not a huge concern.

In doing a bit more digging, it seems that making a connection to the GATT server makes some fundamental changes to the Bluetooth service running on the Pi. I had Craig hit the server from his laptop and after this I was no longer able to do it from mine, it would throw a missing UUID error. Then, after restarting the entire Bluetooth service, I was able to connect just fine. This is done with the command ‘sudo systemctl restart bluetooth’, I want to find a better solution but this will do for now.

The next step now is to actually send data to the Pi, which is the primary function of this service since the Pi needs to get the card order from the user. This is a different type of function, and I tested the characteristic function in the sample project which has the ability to write back a character, which also worked properly.



Now it’s time to actually build a new GATT server with the functionality we actually need on top of the helper code from the open-source project. I first built a simple read only endpoint that the app could use to check if the system is ready to receive a new card order. This was a small task, as I just used the code from the temperature sensor project’s endpoint and updated it to return a boolean. Of note, the return type of the value must be cast properly for dbus to parse it correctly. To do this I used dbus.Boolean(...) to cast the boolean ready signal properly. After fixing this, everything worked properly. I had to adjust the console code to decode into a boolean instead of text, but that was a quick fix.


I then added code to support a read/write characteristic for the actual card order. The framework is again very similar, the __init__ just needs to include “write” and a WriteValue() function needed to be added. I added some JSON parsing code and now the server can properly handle accepting JSON objects over BLE. This should make the code much easier in the future, since we can easily add parameter fields when needed.

Entry 1: -----------------------------------------------------------------

Date: February 26th
Start Time: 9:30am
Duration: 2 hours

In laying out the PCB, we are configuring which pins are used for what, including UART. As such, it is likely that the pins I used in my testing will be changed, but we will determine which UART port to use based on which pins are most convenient.

I am attempting to send data to the Pi from my laptop once again, this time switching to use Chrome’s Bluetooth Web Developer tools:
https://googlechrome.github.io/samples/web-bluetooth/device-info.html?allDevices=true
This is basically an online toolset that I can use to test some basic functionality. However, as of now the device is not appearing as pairable, even though it is set to be advertising and I can connect to it from my laptop. Also, for some reason the code to start the GATT server no longer functions due to a compatibility issue between Python versions. I am attempting to downgrade the virtual environment I am using to Python2, hopefully that will fix the issue.

=============== Week 6: =================

Entry 5: -----------------------------------------------------------------

Date: February 21st
Start Time: 7:00pm
Duration: 2 hours



I spent today building up the schematics for the motors. We are using a TMC2209 stepper motor controller which I needed to model from scratch, and all connections for that are based off of what was told to me by Craig who has been working with the motor. Questions about the schematics should be referred to his journal, I based my schematics off of this diagram for a similar driver.


For the two DC motors that simply need to spin, we discussed using an L293D driver which can drive two motors at once, which fortunately is already modeled in KiCad. I am basing my diagram on the project at the link below, it’s a very simple driver so I just need a bit more time to iron out which input signals need to be mapped to PWM and which don’t.
https://www.instructables.com/Controlling-Two-DC-Motors-With-L293D-IC/

The last motor we need is another DC motor that will simply go back and forth to open and close the card release system, I need to discuss with the team how we are changing motor directions because we had a few separate ideas for that. Finally, I need to model the photoresistor system that we will be using to zero the motor, but that should be a very simple circuit.

Entry 4: -----------------------------------------------------------------

Date: February 19th
Start Time: 1:45pm
Duration: 1 hours

I met with Johnny to discuss the PCB schematics, he is working on the STM32 and I am scheming the Pi and the motor drivers, although we may reassign depending on workload. There is no existing Raspberry Pi Zero 2W schematic on Kicad, so I built one from scratch after watching a quick tutorial on building custom parts.
https://www.youtube.com/watch?v=3FGNw28xBr0&ab_channel=Mr.T%27sDesignGraveyard

While most of these pins will not be used, I think it's important for completeness’s sake to have this fully modeled. I will need to go in when we do layout and create the actual full custom layout for the Pi from the datasheet, but that is not important now. I also read up on the motor controllers we need so when I have more time I will begin building the schematics for those too.

Entry 3: -----------------------------------------------------------------

Date: February 18th
Start Time: 9:30am
Duration: 2 hours

Back to working on the GATT server, I am once again switching packages to try pydbus, this package is designed to have the most limited functionality possible to get a simple GATT server working. For this I needed to get the actual bluetooth device, which is done by running ‘busctl tree org.bluez’


I was able to get the GATT server running on the Pi, but now there are difficulties sending data from my Windows laptop. It seems that even though the devices are properly connected, there are some discoverability issues with the Pi’s MAC address. The sender program I am running cannot connect, which may be an issue with the package attempting to make a new connection instead of using the existing one.

We also had a lengthy discussion about some design changes to the device, specifically how the support for the wheel should be set up and how to implement the photoresistor in it for the motor homing system.

Entry 2: -----------------------------------------------------------------

Date: February 17th
Start Time: 1:30pm
Duration: 1 hours

Every time that the Pi reboots it generates a new IP address, which is very annoying since I have to manually look up the new one by connecting it to a monitor. I spent about 30 minutes trying to connect via the hostname, but nothing seems to work as my laptop cannot discover the device. Tabling this for later and some teammate input.

When I booted the Pi my laptop immediately connected to the Bluetooth module, so clearly the configuration from last week has properly persisted. I attempted to resolve the issues with the bleak package from last week using a virtual environment to pip the latest package version, but that failed too, so I am going to move on from that package. I am now trying to use the ‘gatt’ package which sets up a simple GATT client, which is needed since iPhone only supports this type of client. I think using a virtual environment is still the way to go since it ensures that all packages work properly, but there is an issue with dbus which is used to manage the network.


dbus is running here, but it is not properly being passed through to the virtual environment, so next time I need to figure out how to do that.

Entry 1: -----------------------------------------------------------------

Date: February 15th
Start Time: 9:00pm
Duration: 1 hours

I was able to pair my Windows laptop by actually opening the Pi’s desktop environment via the onboard HDMI and clicking connect when the connection request came through. This process will likely need to be streamlined for when we actually want to connect new devices. In doing some research, there are two main Bluetooth connection types, Classic which support serial-port like connections, and Low-Energy, which does not. From what I have read, Android devices support both versions when connecting to devices like our Pi, but iPhones only support BLE for this use case. As such, I am going to be attempting to use a GATT (Generic Attribute Profile) as the connection server. For this I am using a package called Bleak, which is a common standard for this use case. Note: ‘pip install ____’ does not work on the Pi, you need to use ‘sudo apt install python3-{package name}’ instead.

I had some issues installing this package, namely some of the features I need are only in the 0.21 release, and the installer was getting the 0.20 release. It is extremely painful trying to figure this out since I cannot use ‘pip,’ as Bleak does not have significant documentation for installing without ‘pip’. I will figure this out next time I am in the lab.

=============== Week 5: =================

Entry 4: -----------------------------------------------------------------

Date: February 14th
Start Time: 2:15pm
Duration: 1 hours

Back to working on the Bluetooth connection, first I added the file /etc/bluetooth/rfcomm.conf and added the lines:
rfcomm0 { bind yes; device ; channel 1; }
I tried adding to the BlueZ config file found in this forum: https://forums.raspberrypi.com/viewtopic.php?p=947185#p947185. I added these lines:
ExecStart=/usr/lib/bluetooth/bluetoothd -C
ExecStartPost=/usr/bin/sdptool add SP

I was able to get the Pi to pair following this by manually pairing via ‘pair {MAC_ADDRESS}’ after running ‘bluetoothctl.’ The connection then succeeded, resulting in some serial data being sent to the Pi:


My initial plan following this was to use the RFComm port to send data to the Pi from my phone, but it seems like this will be extremely difficult since iPhone’s only support this kind of connection in very specific circumstances that I do not yet understand. If our PSDRs are not yet locked down I would suggest other ways to connect, preferably a self hosted web server on a wireless LAN. Currently just doing more reading to understand the path forward.

Entry 3: -----------------------------------------------------------------

Date: February 13th
Start Time: 5:30pm
Duration: 5 hours

I started by just rebuilding the Pi serial connection python script using my notes from the previous journal, to add to a note I made then, it is important to ensure that the serial port is enabled. I thought I did this then saw a bunch of ‘Permission denied’ errors when trying to access the serial port. If you see the below error, do ‘raspi-config’ to enter the setup menu and enable the serial ports. I had to turn off the serial login shell to turn on the hardware serial.


I also realized that I was using the wrong ports for USART3, I switched to using GPIOC for the TX and RX. I also properly configured to pull up the TX pin and it seems to power in the same way as the TX:


However, when I connect the STM32 TX line to the Pi’s RX line, the python script hangs, and when I manually break the connection, it states that there is an invalid start bit. I connected an oscilloscope to see what is happening and it does appear to be sending valid UART bits.


Using the oscilloscope cursors I checked the length of pulses and they appear to be about 210us, which is twice as long as a 9600 Baud pulse should be. I am sending ‘U’ which in UART is a constantly oscillating signal to make it easier to tell the actual rate. I fixed the Baud rate by manually calculating out the BRR value, using the formula BRR = (f_clk / Baud Rate) * 16, where f_clk is the UART clock. For this chip the UART clock rate is 42MHz, so the BRR needed to be set to 0x1117. This will almost certainly need to change when we switch to the F7 from the F4 since the internal system clocks are different. Also as a note, I had to connect the grounds to ensure that they were common.

I got something by starting the python script while the STM was transmitting. I had to change the Python code to not use ‘readline()’ since that waits for a \n character that I was not sending. After this everything appears to be working properly, I made a similar test to check if the receiver on the STM32 is working properly by sending one character at a time and incrementing it. Using Cube’s debug mode, I checked the value of the received character and everything is in order.

I moved on setting up the Bluetooth connection, first by checking that it was running using
sudo systemctl enable bluetooth
sudo systemctl start bluetooth
I then configured Bluetooth by entering the Bluetooth terminal with ‘bluetoothctl.’ I then configured it with the commands: ‘power on’, ‘discoverable on’, ‘pairable on’, and ‘agent on.’ This sets it up to be properly visible.


I then checked my phone to see that it appears as a pairable device with the name ‘477,’ which is the name of the Pi. I renamed it with ‘sudo hostnamectl set-hostname ______’ so that it’s easier to see. By default the Pi is only discoverable for 3 minutes, I updated the DiscoverableTimeout to be 0 in /etc/bluetooth/main.conf so that it is always discoverable. Changing the name the way I described above actually causes a naming conflict, I instead just set the name in main.conf.

I have spent about an hour attempting to connect in various ways since the device is clearly discoverable, but pairing attempts have been failing every time. The pairing device shows that it needs a PIN and then spends about 2 minutes trying to connect, then fails. It does not appear that other people online have experienced this issue, but I will keep looking.

Entry 2: -----------------------------------------------------------------

Date: February 11th
Start Time: 5:30pm
Duration: 1 hours

The Raspberry Pi Zero 2 W came in today, which will be the single-board computer we use in the final design. As such, right now I am setting it up for development. First I reflashed the micro SD card with a proper OS for the board. I turned on the serial ports the same as I did previously using ‘sudo raspi-config’ to open the menu, check the previous journal entries for a full explanation. This board does not have an Ethernet port and there is no public WiFi available to connect to, so I am attempting to set up local ssh via something called gadget mode. I added the line “modules-load=dwc2,g_ether” after the ‘rootwait’ part of /boot/firmware/cmdline.txt which should enable this mode.

After some testing this did not appear to work, the Pi is simply not discovered by my machine. However, I tried connecting to eduroam and it worked, I just needed to check the ‘No CA certificate is required’ flag and input my username and password. From here setting up SSH was simple, just using ‘hostname -I’ to get the IP address then ssh-ing in from my terminal with the proper username and password. This should make development on the board significantly smoother going forward.

Entry 1: -----------------------------------------------------------------

Date: February 8th
Start Time: 1:30pm
Duration: 3 hours

I finished the A4 Electrical Overview today, it took approximately 3 hours to research and compile the information as well as complete the block diagram. All of my work can be seen within that document.

=============== Week 4: =================

Entry 4: -----------------------------------------------------------------

Date: February 7th
Start Time: 3:00
Duration: 2.75 hours

I took about 1.5 hours to reconfigure all of the tools on my new laptop and rebuild the file I was working on, see previous journal entries for this setup work. Since I am the Hardware Lead, I need to complete the A4 electrical overview along with the A5 component analysis.

I was responsible for the STM32 component analysis in A5, my thought process and work is listed there. All of my work for A4 will be completed tomorrow.

Entry 3: -----------------------------------------------------------------

Date: February 6th
Start Time: 5:30
Duration: 2 hours

Now it’s time to work on the STM32 UART connection. I had to relearn a bit of how to access the proper registers, which have aliases set up in the code. Additionally, the Cube IDE we are using sometimes will show an error even after it has been fixed up until running a build, so I need to remember in case I forget to rebuild. The first step of setting up UART is to properly configure the GPIO pins. I am using GPIO pins 10 and 11, which are accessed through GPIO register B. They need to be set to the alternate function mode, in this case AF7 to use the USART3 bus. First, the pins need to be set to alternate function mode using the MODER register. Then, to set the specific alternate function, we need to set proper areas in GPIOB->AFRH, which looks like this: (p289 of manual)


USART3 specifically requires AF7, so we have to set AFRH 10 and 11 to 4’b0111, as seen below.


Finally, to write the data I am pushing the character I want to send to the DR of the USART3 port. I connected the TX of the STM32 to the RaspberryPi’s RX with jumper cables and attempted to send, but it did not work. To note, I ran the Pi’s TX through an LED as I did earlier and it idles high, which is to be expected since UART is a high-idle protocol. When I did the same with the STM32’s TX, it did not light up. This likely means that I will have to configure the pins to pull up properly.
However, before I got a chance to configure this, Craig accidentally shorted two pins on the motor driver board while trying to adjust a potentiometer with a screwdriver (a poorly designed board in my opinion) which burnt the board and caused a 24V spike onto my USB port that was connected to the STM32. This burnt the motherboard on my laptop so I now need to reinstall all of the tools and restart my progress on my second laptop.

Entry 3: -----------------------------------------------------------------

Date: February 5th
Start Time: 8:30
Duration: 2 hours

Lots of team discussion today, Johnny printed a prototype of the card feeder and we tested it with some simple motors. It worked relatively well, but it was feeding multiple cards at a time which is an issue. We believe that with a proper setup of weights it will function as expected, but Johnny is testing more. We spent time discussing which power supply to get, and we settled on getting a PC power supply with multiple voltage levels, which the Lab TAs agreed with. The team wasn’t sure on how much to spend, ultimately we decided on a slightly more expensive version (around $38) to maintain our peace of mind.
I am focusing on getting the STM32 UART working, in doing some reading the general flow for this is as follows: Enable the system clock using APB1ENR and AHB1ENR control registers, set GPIO pins to UART mode, which is done through the AF control registers, then configure the UART using the USART3 control registers, and set the Baud rate. The Baud rate will most likely be 9600 to match with the Pi, but it may need to be adjusted.
I did some initial testing of the code, and I need to refresh myself on how to use the STM32 interface before moving forward. Once I do, I will be implementing the above code and everything should be functioning properly.

Entry 1: -----------------------------------------------------------------

Date: February 4th
Start Time: 1:30
Duration: 1.25 hours

I am starting by testing a UART receiver/transmitter on the Pi, since a robust module on this end will make it much easier to diagnose issues when I move to the STM32 implementation. Putting this here just for future reference:


I am first testing the TX by routing it through an LED to see the oscillation of the signal. I lowered the Baud rate to 50 and I increased the resistance from 220 to 1k Ohms to make the changes visible. Currently I am running into an issue where the change is not visible. I simplified the script to send over TX and decode the RX while connecting them directly together with a standard Baud rate of 9600, and this appears to work. It appears that it is not as simple as setting the Baud rate in the Python script to actually change the TX Baud rate, which while potentially not relevant I want to get working to demonstrate the TX and in case a new Baud rate is needed for the STM32. Using the standard command of ‘stty -F /dev/ttyS0 300’ to set the Baud rate to 300 fails with functionally no feedback, so more research is needed. (/dev/ttyS0 is the name of the GPIO serial port, it can be found with ‘ls -l /dev/serial0’ which searches for serial port 0).
In doing some reading I found some likely future relevant information. It seems like there are two separate UART interfaces, one for the Bluetooth module and one for the actual GPIO pins, and if both are in use the Baud rate must be fixed in order to make Bluetooth work. As of now that should not be an issue, it just means that the STM32 will also need to use a Baud rate of 9600. Should an unforeseen problem arise further down the road with that Baud rate, it may necessitate a separate Bluetooth module, but as of now it seems unlikely.
https://stackoverflow.com/questions/51234573/changing-the-baud-rate-of-a-serial-port-on-a-raspberry-pi-3

=============== Week 3: =================

Entry 3: -----------------------------------------------------------------

Date: February 1st
Start Time: 2:15
Duration: 1.5 hours

I updated the functional description to provide a more accurate view of what actually occurred within the Card Shuffler. This new description discusses each component instead of just giving an overview of what the design's intended final purpose is, and should give a better understanding of how it actually works, without delving into the technical implementations.

Then I worked on the UART connection between the Pi and the STM32. I started with getting serial ports up and running on the Pi. Using sudo raspi-config pulls the config menu below, which lets me turn on the serial ports.


After turning this on, I tested to make sure it worked with a simple LED circuit driven by a GPIO pin. I needed to install some Python packages for this, which was slightly annoying since RaspberryPi’s don’t support global pip installs any more. Instead I needed to use the Linux installer apt. I wrote a simple program to blink the LED off GPIO pin 18, which worked without an issue. The next step is to actually implement the UART protocol, which on the Pi is relatively simple due to the existence of built-in libraries. Creating the protocol on the STM32 will be the more difficult step, which I will tackle this week once I finish my ECE437 Computer Design lab.

In the meantime I did some reading on setting up how UART on the STM32: https://deepbluembedded.com/how-to-receive-uart-serial-data-with-stm32-dma-interrupt-polling/
It seems that there are two main ways to approach the UART we need, either a standard packet length-based protocol or an unknown packet length-based protocol. I will be discussing with the team as to which is more correct for this project, but I am guessing it will be the standard-length.

Entry 2: -----------------------------------------------------------------

Date: January 30th
Start Time: 5:30pm
Duration: 2.5 hours

My goal for today was to set up the Raspberry Pi for use on the other side of the UART protocol, with SSH capabilities and some rudimentary I/O for testing. However, we did not initially have an SD card so after acquiring one from a TA, Johnny flashed it with Raspbian since he already had the software installed. We chose Raspbian as the OS since it is simple and lightweight with lots of documentation, but we may move to Raspbian Lite if we can determine that we have unneeded features.

I attempted first to set up via USB Gadget mode, where I would not need to connect the pi to anything external, but this is not a supported feature on Raspberry Pi 4, which is the platform we are currently using. Instead, I had to connect peripherals to access it directly to set up a connection for remote use later. It took a while to source the cables since it uses micro-HDMI, but a TA was able to supply one eventually. After borrowing the lab computer mouse and keyboard, the Pi booted into setup mode, and took about 15 minutes to properly install the necessary packages. After setting the access credentials and connecting the Pi to the Ethernet switch at our lab bench, I can now access it via SSH. The user must be on the same network, so right now I have to be on PAL3.0. Craig attempted a connection through Eduroam, but that did not work, so we believe it has to be PAL. After depowering and rebooting the Pi, I was able to connect via SSH once again, meaning it is now ready for development and has a static IP.

Entry 1: -----------------------------------------------------------------

Date: January 29th
Start Time: 9:30am
Duration: 2.5 hours

I began working with the STM32 board with Craig, setting up my instance of the CubeIDE on Linux. There were some difficulties since the first install was corrupted, but ultimately I got everything to work. From there, I created a new project and selected the NUCLEO-F746ZG board which is our dev board. I had to create an ST account to download the necessary files to generate code, and we are working together to test our setup with some simple code to turn on the onboard LED.


My Linux setup was also missing a necessary debug library so I installed that before continuing. After downloading, we attempted to build, but the board we are on is lighting LD5, which signifies overcurrent draw. This means our board is either completely non-functional or broken in a way we cannot fix.


On build attempt both Craig and I are throwing ‘No device found’ errors as seen above. After more research, we felt the chip and it appears to get quite hot, so likely it is non-functional. Now the actual development begins.

I also did some research into how the UART connection should actually work:
https://emteria.com/kb/connect-uart-rpi
Seemingly it will be a lot more involved on the STM32 side, which is to be expected.

=============== Week 2: =================

Entry 3: -----------------------------------------------------------------

Date: January 24th
Start Time: 3:30pm
Duration: 1.5 hours




Team discussed designs with the ECE machinist to determine which design between tray-based and wheel-based design would be better. Based on the machinists response, the team has decided on wheel design due to a less complex mechanism and an easier time machining.

Following this, the team discussed next steps including what motors to acquire and how certain mechanisms will work. While we require more research to pick the final motor, we are in consensus that we need a both very powerful and very precise motor to ensure proper operation. The team also discussed feeding mechanisms and whether to sort after dispensing cards into the wheel or after. Generally, it seems that sorting after is considered the superior method, but mechanical constraints may cause the team to reconsider. Since the mechanism does not change based on this decision, it does not need to be set in stone until the algorithm is ready for deployment on the actual system.

Entry 2: -----------------------------------------------------------------

Date: January 23rd
Start Time: 5:30pm
Duration: 1.5 hours

Team met to finalize plans for design, however the machinist was not in, so the team plans to meet tomorrow. Instead, we allocated portions of the functional specification. I am writing the updated functional requirements section and the theory of operation section.

Team also determined a list of roles within the team for tasks that need to be completed so that work can actually begin. These roles were designed to encompass a small subset of the overall project, with each team member picking up multiple roles.

Entry 1: -----------------------------------------------------------------

Date: January 22nd
Start Time: 8:30am
Duration: 2 hours




Second lab period, team focused on determining exactly which design for project to go with.
Two main designs: tray-based system with a vertical motion and 8-13 card buckets, or circular drum design with full 52 buckets.

Tray Design:
Pros:
Faster and more efficient
Smaller
Generally accepted as cooler by the group

Cons:
More mechanically complex
More complex initial algorithm
Higher part precision required

Drum Design:
Pros:
Easier general algorithm
Simpler mechanically

Cons:
Already attempted
More difficult to optimize
Slightly less cool

Team ultimately decided to wait to discuss mechanical feasibility with ECE machinist before making a decision.

Team selected initial testing components for rest of design:
STM32 F7 as microcontroller - provides enough processing power for necessary algorithms while remaining cheap enough
Generic camera module for testing - a more feature-specific module will be chosen when the group understands the constraints of our design more
Raspberry Pi Zero for image processing

=============== Week 1: =================

Entry 3: -----------------------------------------------------------------

Date: January 16th
Start Time: 8:30pm
Duration: 1 hours

Worked on final project proposal assignment due Saturday 1/18 - divided individual work I wrote the functional description of the project, and team roles were assigned. I am the hardware lead now. Team discussed necessary components of project and created a budget for parts, and chose which of the individual reports each team member would work on.

Entry 2: -----------------------------------------------------------------

Date: January 16
Start Time: 3:30pm
Duration: 1 hours

New project idea meeting where team discussed current plan for Senior Project with team - team was not set on Guitar Amp idea
Each member instructed to come with a few alternative ideas for project

Team used the Internet and generative AI to provide inspiration for new ideas. Some ideas that were considered included:
Braille device to enable users to read from the Internet
Automatic card shuffler
Gesture-based audio controller

Team was most passionate about automatic card shuffler and decided to switch to that project. We met with the Professor who was similarly enthusiastic and advised the next steps to switching projects, which was completing the Final Project Proposal

Entry 1: -----------------------------------------------------------------

Date: January 15th
Start Time: 8:30am
Duration: 2 hours

First lab meeting, team met with TAs to discuss current project as well as the possibility of switching to something else Guitar Amp project was said to be a good project by TAs, but team unsatisfied.

Learned layout of the lab, along with tool locations and available parts for use, planned to meet later to discuss new project.