Using Machine Learning to Predict Sensing Voltage Changes in NAND Flash Cells to Maximize Data Retention
Advisor: Mr. Dievendorf
Internship Location: Scaleflux at 900 N McCarthy Blvd Suite #200, Milpitas, CA 95035
Onsite Mentor: Jiangpeng Li
With technology’ increasing influence on society, maintaining data reliability is crucial, especially for healthcare centers, where medical information safekeeping directly impact patients. Currently, data degradation shortens storage devices’ lifespans and makes them unpredictable, which leads to prevalent data loss. The goal of my project is to maximize the duration of accurate data. One solution lies in knowing the sensing voltage—an accurate sensing voltage prediction indicates a strong likelihood that the data will be maintained precisely and estimates the storage’s current stage in its total lifespan. Drawing from my experience in coding a storage lifespan elongation program in 2023 and 2024, I plan to code a similar program that predicts the sensing voltage of each storage disk. To achieve this, I will first collect initial sensing voltage data under controlled environmental conditions. Following, I plan to program a machine learning model (MLM) that predicts future sensing voltage data, and finally, I will validate the model's predictions against observed outcomes. I anticipate that the MLM will maintain data accuracy by 15-30% longer. My project contributes to a more sustainable NAND flash storage design with improved lifespan and performance. This change may have significant impacts on sectors like healthcare, where preserving data integrity can save lives.
Project Blog
Post 1: Welcome to Blog #0!
Hi guys, welcome to my first senior project blog! I’m so excited to share with you guys my journey to discover what exactly happens inside a storage device. I hope you will join me to find ways to improve data storage so it’s safer, faster, and more secure for everyone!
In our storage disks, such as in your phone and your laptop, there is a flash storage system that holds all of your photos, videos, and files. But as storage ages, the cells in the storage device degrade, causing something called the sensing voltage to become inaccurate. The inaccuracies in the sensing voltage is what leads to storage systems forgetting and losing your data.
My project focuses on predicting the storage’s sensing voltage throughout its lifespan. An accurate sensing voltage allows the storage to maintain accurate data even if it is aging. Plus, it allows us to figure out how old the storage is so we can replace it before it fails.
I became interested in software-hardware integration the first time I interned at Scaleflux, a semiconductor supplier and company. Programming was like puzzle-solving to me since it challenged my logic and creativity, and I fell in love with creating tangible solutions by integrating my code into hardware devices.
At Scaleflux in 2023 and 2024, I worked on a common NAND flash memory issue called read disturb. This happens when repeatedly reading a cell accidentally alters the data in nearby cells, leading to data degradation. Using C programming, I created a NAND flash model to simulate the problem and tested how techniques like read wear leveling could mitigate it. This experience gave me a deep understanding of flash memory architecture and inspired me to tackle broader reliability challenges in my senior project by applying AI and machine learning.
Over the next few months, I'll be working with my external advisor, Jiangpeng Li, and internal advisor, Mr. Dievendorf. I’ll start by taking introductory courses on machine learning and researching more about flash systems. I’m excited to build on everything I learned last summer to explore the potential of AI in extending the life of storage systems!
Thanks for stopping by! Stay tuned for more updates, and I hope to see you all again soon. Bye!!
Krystal Sun
Week 1: Trying Machine Learning, NAND Flash, and a Whole Lot of Learning!
Welcome back to my blog! This week was full of new inspiring concepts about NAND Flash and Machine Learning that I learned, and I’m so excited to share them with you all. My focus during this stage of my project is deepening my knowledge of NAND Flash memory and familiarizing myself with machine learning.
Before I begin, here’s some quick background information that’ll come in handy: NAND Flash is a type of non-volatile memory, which means that it retains data even when power is removed, and it’s widely used in SSDs, mobile devices, and memory cards.
This week, I refreshed my fundamental understanding of NAND Flash memory and deepened my understanding of its internal organization. I learned of two types of NAND, namely raw and managed NAND. While managed NAND has error correction and other data management functions built-in, raw NAND doesn’t. Error correction is a programming technique used to automatically fix mistakes in the NAND Flash memory. I also explored single-level cells (SLC), multi-level cells (MLC), and triple-level cells (TLC). While SLCs have the highest performance, endurance, and reliability, TLCs have the lowest cost but have other tradeoffs such as slower performance and worse endurance. A typical 2 GB NAND Flash Memory structure is called a chip or die, and it contains 2 planes. These planes are made up of 2048 blocks, with 1024 in each. Each block is made up of 64 pages and 2112 bytes, or cells, per page (Shin, 2019). Each page delegates 64 bytes towards error correction code. I found this organization really interesting because I didn’t realize that error correction code was so specific.
Now here comes the more interesting part! The most fundamental concept in my project is understanding that an accurate threshold voltage is crucial for maintaining accurate data! When I approached the section about what operations engineers use to NAND Flash memory performance, I came across a technique called the incremental step pulse programming (ISPP), which precisely sets the cell’s threshold voltage by applying multiple pulses and verifying each time (Micron, 2006). ISPP caught my eye immediately, because this type of programming would be useful when I am coding my program to match each cell’s threshold voltage.
Now here comes the highlight of my entire week: working with the MAGIC Gamma Telescope. I know it sounds random, but the MAGIC Gamma Telescope is one of UC Irvine’s Machine Learning models that I used to predict a type of rock (either gamma or hadron). I worked on supervised machine learning by graphing the given dataset by importing numpy, pandas, and Matplotlib into Python. I also learned to identify the independent and dependent variables and find out the patterns in the dataset that help us predict the result. I also separated the given dataset into three categories: (1) training, (2) validation, and (3) testing data. But when it came to understanding the Standard Scaler, I was stuck. I didn’t understand why I needed to fit my data into a standard scale, or what would happen when I did. As I continue studying and applying machine learning, I am excited to finally understand this concept.
You might be wondering why I’m working with a completely different dataset this week. I’m working with the MAGIC Gamma Telescope to hone my machine learning understanding of fundamentals. After this first week, I’m starting to fundamentally understand connections between machine learning and NAND Flash memory!
This week was full of exciting moments, but my favorite moment was seeing the clean results I got when I plotted 7 graphs of the MAGIC Gamma Telescope with two lines of code. Here are 2 of them!
That’s all for this week! Now that I understand NAND Flash memory more and have gained hands-on experience with machine learning, I realize how important these steps were in shaping my future project. Though I do need to review certain topics more like standard scaling, I am excited to keep exploring and see how NAND Flash and ML connect. Next week, I will continue and wrap up the machine learning example I worked on this week! I hope you enjoyed reading about my first week, and I look forward to seeing you guys again next time!
Week 2: Wrapping up Machine Learning (ML) and NAND Learning, Planning Data Gathering
Hey guys! Welcome to my second blog for my project, I’m so excited to share with you guys everything I got to learn this week. I was mainly focused on finalizing my machine learning and NAND Flash knowledge to ensure that I’m well-prepared for the upcoming weeks.
Last week, I started learning various concepts that would be relevant while I start my project. I studied NAND Flash: a non-volatile memory that’s used a lot in SSDs, phones, and laptops. I also started my journey learning ML, and tried it out on my own as well!
This week, I started off by wrapping up NAND Flash learning. I read this updated article called NAND 201 from 2011 that discussed density enhancements made to NAND Flash memory. For instance, NAND Flash used to only be made up of 1 die, but now they can be made up to 4. Some NAND Flash now hold up to double the number of pages as before. These enhancements help each device have a higher-density of memory without utilizing more resources like silicon.
In addition to NAND 201, I read another paper on PCIe SSDs. PCIe SSDs are a type of SSD that is a lot faster than typical SSDs. Though it is usually more expensive, PCIe SSDs can handle large amounts of data while having high endurance. They’re suitable for enterprise setups and data centers. You might be confused why I had to read this paper, as it doesn’t really discuss NAND Flash. The CSD5000, which is the Scaleflux SSD product I will be collecting data on, is a PCIe SSD, so it’s necessary to know the structure and uses of these SSDs.
But the main focus this week was machine learning! There are two types of supervised machine learning: classification and regression. Classification is used when you want to predict a value out of a fixed number of outcomes (like classifying a dog breed), while regression is used when you want to predict a continuous value (like the price of a house). I realized that my machine learning project would use regression, so I focused on learning and practicing regression. By watching Stanford Online lectures on Machine Learning, I dove into linear regression, decision tree regression, and support vector regression. Through these Stanford lectures and last week’s machine learning video, I started seeing more connections between machine learning and math. For example, here’s a really intimidating calculus equation used in linear regression.
This equation is the gradient (derivative) of the cost function. It describes the change (represented by the partial derivative on both sides) in the deviation from the predicted value (hθ(x)) to the actual value (y). The equation is squared to increase the consequence of having a larger difference between the predicted and actual value. Also, there is a ½ fraction at the beginning of the equation to simplify the result after taking the derivative (because ½ * 2 = 1). Oh, and θ represents the importance of the feature x on affecting the predicted value hθ(x). This equation is really useful for finding the best θ value to minimize the differences between y and hθ(x). That way, the prediction can be as close to the actual value as possible!
Here’s the link to the Stanford lecture I referenced: https://www.youtube.com/watch?v=gqKaVgQxEJ0&list=PLoROMvodv4rNyWOpJg_Yh4NSqI4Z4vOYy&index=2
And that’s all for now! I spent a lot of time this week refining my knowledge in NAND Flash, Python coding, and machine learning through reading papers, watching lectures, and trying it out on my own. Stay tuned for next week, where I’ll finally begin gathering physical data from Scaleflux’s SSD product called CSD5000. I’ll also begin coding my first program of the project next week. I hope you guys had a wonderful week, and I will see you soon!
Sources:
Cooke, Jim, and Micron Technology. “Nand 201: The Continued Evolution of NAND Flash.” EE Times, EE Times, 13 Feb. 2011, www.eetimes.com/nand-201-the-continued-evolution-of-nand-flash/.
Kim, Eden, et al. “PCIe SSD 101.” SNIA, 2013, www.snia.org/sites/default/files/SNIASSSIPCIe101WhitePaper_120314.pdf.
Week 3: How I Accessed Threshold Voltage (Vt) Using Terminal
Another week is completed! During week #3, I focused on gathering the necessary data I needed to start the machine learning programming process.
The four types of data I needed from the computer were (1) Block ID, (2) Page ID, (3) Program/Erase (P/E) cycles, and (4) Threshold voltage. Block and page IDs are used to identify the indexes where the data is, and they influence the threshold voltage, which is why I decided to gather it. I also needed P/E cycles because the more P/E cycles that occur, the older the SSD and less accurate the threshold voltage becomes! Lastly, I needed the threshold voltage as a result of the block ID, page ID, and number of P/E cycles. All of this data works together to help me develop my function during the machine learning process.
How do I gather all this data? First, I opened the terminal on my computer. I connected my laptop to a Linux computer that communicates with the SSD, called CSD5000. I started by running a “fio test” on it, which writes test data into the blocks. I also can view a log of the computer’s actions through a separate tab called minicom. After the write cycle is over, I checked the status of all the blocks through the command “vtdbg 2”. This is the result that I get! It directly tells me the location (wl []) and block ID (before the colon) and accurate threshold voltage (after the colon).
Unfortunately, this communication process with the other computer took a long time because I ran into some errors. At first, I didn’t know how to navigate the terminal that well and I took a few days to get used to the commands and understand what they meant. However, through continuous practice and patience, I finally understood!
Anyways, that’s all for this week! Next week, I’ll start organizing this data so that it’s ready for the machine learning process. Stay tuned, bye bye!
Week 4: Developing the Machine Learning Program
Hi guys, welcome to week #4 of my blog! In addition to analyzing some of the problems from last week, I worked on developing the machine learning program to predict my threshold voltage.
If you remember from my week #3 blog, I came across a problem where managing the terminal commands was difficult. This week, I realized that it was because after writing data on the block, I couldn’t just read the threshold voltage immediately, because data retention hasn’t set in yet. However, after waiting for a couple days, the threshold voltage was updated! Through this program, I was able to retrieve the block number, wordline, die number, and the threshold voltage.
After I retrieved all the data, I coded a short Python program that separated all four data types into four distinct columns that I could easily separate in Google Sheets. This saved me days of time, because I definitely didn’t want to manually type in 1800 rows of data! After organizing the data, I saved the Google Sheet as a .csv file, which I imported into my machine learning program folder.
Now, it’s finally time to develop my ML program. I started by importing all of the necessary libraries I needed for Machine Learning. The first library I downloaded was Scikit-Learn, which is used for easy access to various machine learning algorithms (I used it for K-means clustering, which I’ll get into later). The second library I downloaded was NumPy, which I used to separate my data into training, validation, and testing data. I used Matplotlib to create a visual diagram of my features’ impact on threshold voltage. Lastly, I used Pandas, which I used to read my data.csv file.
This week, I decided to start with K-means clustering, which is a machine learning algorithm that separates data into a k number of “clusters” based on their features. I decided to use clustering because it helped me group together data points with similar voltage patterns, leading to more accurate threshold voltage predictions. Although this Machine learning algorithm is not yet finalized, I definitely learned a lot about the patterns within my data. Below is an image of how k-means clustering separated my data.
Next week, I look forward to using a new set of data and continuously improving my machine learning program. In a few weeks, I look forward to finalizing this program and completing my goal of predicting threshold voltage to elongate SSD lifespan. I wish to play around with other machine learning programs to see which algorithm is most compatible with my data’s pattern. See you soon!
Week 5: More data, more learning!
Aaaaand another week has quickly passed. Last week, I dipped my fingers into machine learning with my data, but this week, I deepened my knowledge, and I made a couple of changes to my coding approach. First, I added the threshold voltage value to the z-axis in the cluster graph and removed the block number from the graph. Second, I changed my clustering algorithm from K-means to DBScan clustering, which I will explain soon! Lastly, I got to work with a new set of data this week, which I was really excited about.
Let’s first start discussing the changes I made to my cluster graphs. Last week, I only made one clustering graph comparing block number, wordline, and die number. This week, I decided to make one clustering graph for each unique block number so that I could incorporate the threshold voltage value into the z-axis. Here’s an example for block 260:
Here, you can totally see that this week’s clusters (left) are more defined compared to last week’s (right)! Clearly defined clusters allow me to predict the threshold voltage with greater accuracy.
Oh, and that leads me to my next point. In machine learning, there are many types of clustering. Last week, I used K-means clustering, which needed me to input how many clusters I wanted. I wanted the program itself to decide the number of clusters to make, so this week, I switched to another type of clustering: DBScan Clustering. DBScan Clustering only needs me to type in the maximum distance between two points to be a neighbor and also the minimum number of clusters that the program will create. Changing from K-means clustering to DBScan Clustering also helped increase the definition of each cluster.
Now, let’s talk about the new data that I used! Last week, I used the threshold voltage measured 2 days after all blocks were written. This week, I used the threshold voltage measured 9 days after the write cycle. There were 1.5 thousand threshold voltages values in one block this time (block 260). Last week, there were only 2 values for block 260… Because this week, the program only gave me threshold voltages for one block only, I decided to only predict the threshold voltage of block 260 only. Removing block numbers as a feature helped simplify my model significantly and helped me see patterns more clearly.
This week wasn’t completely smooth, however. After day 9, an incorrect operation occurred within the company that caused all of the card’s data to be lost. Originally, I planned to take day 10 data, but I must start back at day 1 now. But, I know that after I wait for a couple days, I will have lots of data again!
Anyways, thank you so much for reading my blog and I hope you had fun! During week #5, I built my base machine learning model on solid data and have planned how to strengthen my model with a second set of data. Next week, I will continue this process of adding new data to my machine learning model. I also plan on starting my final product next week (Wow, time flies). See you next time :)
Week 6: Coming to terms with my final product
Hi everyone, I’m so glad that you can join me again for this week’s blog #6! This week, I spent a lot of time coming up with a final product to showcase.
As you all know, my product is a machine learning program, which is difficult to present as a tangible product. Before I started this project, I wanted to make a product website, but that idea is becoming less and less possible. This week, I talked to many employees at Scaleflux, and I was granted the privilege to bring the Solid-State Drive (SSD) I have been using these past few weeks for my final presentation. Yay! Along with this SSD, I decided that creating a research poster would be more appropriate for my tangible product. A research poster for this topic would allow me to explain my project’s concept in a subsequent manner, which will be easier for the audience to understand.
Now, let us move onto an update on the status of my machine learning program.
If you’re new here, this is what is going on: I’m gathering data on a Solid-State Drive cell. Some of this data includes the cell’s location and its age (in days). The goal is to use this data to predict the threshold voltage of that cell. Right now, I’m separating all of the data into separate groups, called clusters, to see if there is a pattern in the data. Figuring out the pattern allows the ML program to learn the data more accurately and efficiently. If that threshold voltage prediction is accurate, the SSD cell’s data will not leak, and data accuracy is maintained!
Unfortunately, due to the recent shortage of devices at Scaleflux, another employee was accessing the drive I was using and my data was completely reset. This means that my second round of data has to restart from day 1. Luckily, Scaleflux unplugged the drive, allowing the retention time of the drive to worsen. Retention time is the time that the drive can maintain accurate data. This worsening means that I can gather the data much earlier than before. For instance, now I can gather the original day 4 data just 2 days after the write cycle.
That concludes this week’s blog. I’m so glad that I was finally able to decide what to do for my final product this week! Although I ran into a problem in my data this week, I was able to learn more techniques to increase or decrease retention time. Next week, I plan to start finalizing my data for this machine learning program and start predicting some threshold voltage values.
Week 7: Developing my website
Yayyy, I’m so happy to finally announce that I have started developing the dashboard for my machine learning program! This dashboard will be especially beneficial for readers who are unfamiliar with SSDs and data retention (I hope 🤞). In this blog, I’ll be going over the planned layout of my dashboard and how I will create it. This week, I have also been working further on gathering data and analyzing them, but there are no current updates.
As you all know, I am developing a machine learning algorithm that predicts the threshold voltage of a cell. This prediction relies on the cell’s location and age data. Because this algorithm is hard to display to a large audience range, I decided to create a visual dashboard that allows users to simulate this prediction algorithm. I created this dashboard with Streamlit, which enables programmers to create dynamic data apps (2025, Streamlit).
Check out this article I referenced to introduce Streamlit: https://docs.streamlit.io
Now, let’s move onto the progress I’ve made with my dashboard thus far. In the last couple of blogs, I showed you guys a lot of the clusters that I’ve created with machine learning. My goal was to show the dashboard user how machine learning groups thousands of lines of data and how those clusters change over time. So, I created a new csv file that added the clusters as the last column.
The number in the fifth column describes which cluster that data point is at.
After creating the cluster column for all my data files, I imported them into my new dashboard program. I created a dropdown menu that asks the user to choose the day that they would like to display. Viewing different days allows the user to see how the clusters and threshold voltages change over time. After choosing, the program will display the cluster graph that I showed in previous blogs.
Neat, right? This is all that I have on my dashboard currently, but I’m so excited to add more features to this dashboard!
Other potential additions to this dashboard include allowing users to input their own die number, wordline, and day variables. Then, the machine learning algorithm will take in the user’s given features and output a predicted threshold voltage.
That’s all I have for this week! I hope you enjoyed reading my blog! Next week, I’ll continue building onto this dashboard and I’ll have further updates for you on my gathered data and machine learning algorithm. See you next time!
Week 8: Updates on data
Welcome back! I just came back from spring break, but I’m so excited to share with you guys everything that I’ve worked on this week. This week, I finally completed data collection and finished organizing and coding my machine learning program.
In the previous blogs, I always talked about gathering data, but unfortunately, because there were so many breakages in my data collection, I started over. As a recap, I’m gathering threshold voltage (vt) data based on an SSD cell’s location and age. To speed up the aging process, my external advisor and I baked the disk that we were using to mimic 2 days of data over a much shorter period of time (like 4 hours). Therefore, I collected my location, age, and vt data every 4-6 hours. Luckily, nothing happened to the disk that I was gathering data from this week. By the end of the week, I had collected 4 substantial samples of data. Yay!
Like in the previous blogs before, I combined and organized my data into 4 features:
hours elapsed
block number
die number
wordline
The next step is to organize thousands of lines of data into clusters. This week, I switched back to K-means clustering because I learned a technique called the Elbow Method to determine the ideal number of clusters.
According to the Elbow method, the number of clusters where the graph starts to flatten out is the most ideal. Therefore, I ended up choosing 5. By using this method, I realized that the number of data points in each cluster was more even.
Ok, now I’ve FINALLY completed the clusters. Now, how are we going to predict the vt?
Let’s say a data point is 8 hours old, is located at block 159, die number 8, and wordline number 32. The K-means clustering algorithm is going to fit this data point in one of the formulated clusters, and the predicted vt is going to be equal to the average vt of the existing data points in that cluster. Finally, to grade the algorithm on its accuracy, we compare the predicted vt with the actual vt.
Next week, I’m really hopeful on coding the machine learning algorithm so that it will improve itself based on the accuracy score of the predicted vs. actual vt. I’m sure you know that data collection took a lot of time, but it’s also important to accept that sometimes, things don’t always go your way and that’s ok! I don’t really see my previous attempts as worthless because I gained deeper knowledge in SSDs and coding every time. There are only 2 weeks left in my senior project! Let’s continue to work hard together. I’m really excited to see my project slowly come together. See you next week!
Week 9: My machine learning model is complete!
Hello everyone, I seriously cannot believe that this week is the second to last week of my senior project! This week, I finally completed my machine learning model… with some problems. Let’s get into it!
Clustering is an unsupervised machine learning algorithm, meaning it doesn’t really have training, testing, and validation datasets. It’s like having an x variable without a y value. So, how did I plan on predicting the vt, you may ask?
As stated before, I had grouped my data into various clusters. In each cluster, I found its average threshold voltage value. Whenever I had a new data point, I used my clustering algorithm to figure out which cluster that data point fit into. Then, the predicted vt would just be the average vt of that cluster. I originally thought that this way of predicting would work well, but after testing them out with the r^2 score and mean absolute error, I was proven wrong.
For context, a good r² score is around 0.8–1, and a good mean absolute error (MAE) is something as close to 0 as possible. But my scores were bad. As you can see my r^2 score was in the negatives, which means that the correlation was even worse than just predicting the vt’s average. Additionally, my MAE value was far far away from 0.
So I had to rethink everything. The problem was that finding the average vt alone wasn’t going to get me an accurate vt value. An average vt would most likely get me a decimal number, which would definitely not be an accurate prediction vt value.
I ended up grouping different sets of threshold voltages at the same point. And instead of finding the average value, I found the most common value in the set, which allows the machine learning program to ignore any inconsistencies and outliers in the data. If a point only had one set, then the machine learning program wouldn’t predict the point and move on.
Lastly, I ended up choosing one block again: block 45. I chose this block because it appears across 3 samples consistently, so therefore it would make the most accurate predictions because there are more sets for each datapoint.
The final accuracy of block 45 was 72%, which isn’t perfect, but it is the best accuracy I can accomplish given the span of my data. There are definitely some errors that occurred that stumped my accuracy, such as: (1) not having enough training data, (2) not factoring in other variables that may have affected the threshold voltage, such as the number of P/E cycles. But overall, I am very happy with the improvements I made this week.
So all in all, I was able to make the predictions that I wanted in my proposal for one block. Though it is difficult to measure the predictions’ impact on an SSD’s lifespan due to time restraints, I strongly believe that I’ve contributed to setting a strong foundation in increasing data retention. Next week is my last week, and I’ll be finishing up my Streamlit dashboard and working on prepping for my final presentation. I honestly can’t believe how fast this flew by. See you next week!
Week 10: Wrapping up!
I hope you are all doing well! Welcome to my week #10 blog! I am so happy to let you guys know that I have finally completed my senior project. This week, I completed my dashboard, so I would like to introduce to you guys everything that I included in my dashboard.
The first thing I included was the clustering graphs that I spent so many weeks talking about. The user on the website can adjust the number of clusters that they would like the graph to make, but there is a note included at the bottom that explains why 5 is the ideal number of clusters. Users can also use the textbox at the sidebar to type in a specified location in an SSD. Remember, the hierarchy goes like this: blocks and dies are the largest, while wordlines are the smallest.
The graph will update based on the user’s inputs. But, it will take a few seconds!
Next, I included the fun part: prediction! It’s located at the bottom of the sidebar, and users can choose an SSD cell location from the dropdown. Then, the dashboard shows the predicted threshold voltage from the machine learning algorithm. There is also a button located below the predicted threshold voltage that reveals the actual threshold voltage. This way, users can see the accuracy of my machine learning program simply.
Lastly, I know that many of the dashboard users may not be familiar with the concepts that I’ve presented, so I created a dropdown at the top of the main page that gives users explanations of the terms I used and overall what was going on. Additionally, in the caption of every section, I explain the purpose of the section and how it plays a role in my project.
Overall, this dashboard was straightforward when it came to coding—I just had to learn the syntax of Streamlit! Streamlit made it incredibly easy to learn, because they had a page where they explained all their syntax. Unfortunately, only I can access my Streamlit dashboard because it is a local file. If someone wanted to access my dashboard, they would have to download my code and Streamlit, which would be a complicated process. Therefore, I plan to submit my product as a screen recording with voice overs, and perform a live demo during my presentation.
link: https://docs.streamlit.io/develop/quick-reference/cheat-sheet
I’ve recently just been working hard on my presentation, so that is all that I completed for this week. Thank you so much for reading, and thank you for following for 10 weeks. Bye!!