Project Journal for Cullen Bradley

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

Date: April 25th
Start Time: 11:06 AM
Duration: 7 hours

Today is demo day. We have a good amount to do, including:
-Soldering the buttons for the second device
-Adding resistors to the buttons to connect the circuits around the buttons
-Some reliability increases to the menus and message sending
-Batteries to the enclosure
-The rest of the assembly
So we’ve got to get going. I’m going to start by adding the resistors to each button by following the schematic and using the step by step process Sophie gave me yesterday. Hoping to have all of the buttons working pretty quickly. I can connect the circuit by soldering either R19, C24, or R20 since U13 is already on. Because I want the button to be pulled low when it’s not pressed, I need to solder the 10k resistor on for each button. Going to do that now.
I soldered everything, Hunter came in. We tested the buttons and none of them worked :(. At this point, I’m assuming I did the soldering wrong. We talked about a plan going forward and decided we should try to basically just get our PSDRs that we can. This means we won’t be able to navigate menus or send variable length messages, but none of those are PSDRs. We’re going to start with trying to get two devices working.
I spent some time trying to get the OLED to display, but no dice. It did occasionally, but not often and seemed to be indiscriminate between working and not working. I cycled through all of our available cables and our OLED displays, but didn’t get anything to work. I also tried changing the code, but it ran fine on our other board so I don’t believe that’s the issue. I also doubt it’s the screen itself or the cable, given that I tried so many. The header and the other side of the ribbon cable are both outputting 3.3 V and there aren’t any shorts. I’m at a bit of a loss, but it’s not a great sign.
A late update- we actually ended up somehow shorting the LoRa TX pin on our microcontroller, so it’s permanently grounded. We ended up having to switch to the third board, on which the buck converter doesn’t output 3.3 V (just 2V). We jerry rigged a setup with the DC motor on the PCB and ran a test, which did actually work. For packaging points, we used electrical tape to seal the screen to the top of the device and then crammed all of the wires inside while we sealed it. I had to hold it perfectly shut while Hunter screwed it in because the wires were too large. We have to keep the debugger attached because somehow it doesn’t work without. We hooked the power and ground wires for the LoRa module to the 3.3V and grounds on the PCB, so it should be powered by our device, with the RX/TX pins connected to the pads that we soldered wires onto. It looks almost good if you ignore the wires coming in and out. You can send messages from the fully enclosed device and receive them in the debugger.
We added a way to receive and then send a message, but it’s extremely finicky due to how we attached the wires to our LoRa module. We attempted to demo but weren’t able to because our LoRa module wasn’t connected and it was left spinning. We semi rectified the issue by pulling it tighter and it seems to be working now. Starting the process of uploading my journals now.

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

Date: April 24th
Start Time: 12:48 PM
Duration: 12 hours

Hunter and I are in the lab right now, Visuwanaath is going to be here shortly. I’m back on the LoRa, while he’s working with the OLED and keypad. We want to see if the oscilloscope outputs are consistent between the prototype and the actual board, so we’re measuring the same code on the oscilloscope to see. I connected channel 1 of the oscilloscope (the yellow) probe to LoRa TX and channel 3 of the oscilloscope (blue) to LoRa RX. However, I have to cut holes for our push buttons first. I’m going to just drill circular holes using the Craftsman ⅜ drill in the lab. I had to find a tutorial because it’s an old drill and actually requires a “key” to screw and unscrew bits, but once I learned that it was pretty simple. I cut 5 holes in a cross formation plus one on the side. I’m going to keep handling the assembly of the product. There is a slot for a 9V battery but the prongs that are meant to conduct aren’t set. I need a way to attach them, as well as the PCB. The screws that come with the case are for putting the front and back of the case together, there are none for the PCB to screw into. Based on the drawing, we need a #4 screw with a 0.11 inch radius. We’ll also need 9 V disposable batteries, which I’ll have to get as well. According to Visuwanaath, Bechtel should have the screws we need as well as a 9V battery, so we’re gonna go there at 4:30 PM. One of the resistors on our buck converter got detached from the rest of the circuit on one end, so I’m resoldering it now. I’m also going to solder LoRa RX/TX wires onto the pads of our other working board. I noticed that the board I just resoldered is now only getting 2 volts across the whole board, which leads me to wonder if the LoRa chip could still maybe work. I soldered the RX/TX wires on. Buttons- it sounds like Sophie will come in and do the soldering.
Walked to Bechtel with Visuwanaath and picked up some screws suitable for the PCB into the case, as well as some extra buttons. They didn’t have the ones we wanted, so I went to the ECE shop and picked some up. Unfortunately, they are square buttons, which is super annoying, but the covers do come off and reveal the same button type. We also got lucky enough to find other button covers for them in a box in the lab. After this, I spent an hour or so trying to glue the buttons on one of the cases. I got it successfully after a while but I had to cut out the other case and repeat the process. Once I had them all attached, I gave Sophie one of the boards along with the case so she could begin soldering the buttons on. I continued to work with Visuwanaath on LoRa, and we realized that the reason it was impossible to tell what was being sent/received over the RX and TX lines was because the lora module on the board was still sending garbage. Once we scratched off the traces, it was smooth sailing. We were able to actually send a message via LoRa, and also cross off a third PSDR. However, because we need 1 software PSDR and there are three hardware ones crossed off, we still have yet to pass the ABET. Sophie texted me and I came up to the ECE shop, where she told me she was still feeling incredibly sick and wasn’t going to be able to solder the buttons to the PCB. I took over the job for her and did all of the soldering, which took me 2-3 hours because wires kept popping up. Once I finished, I came back down to the lab, where I gave Hunter the finished product. One thing I didn’t realize was how difficult it would be to attach the OLED cable to the PCB, which took a bit to figure out. The buttons do not work, which once we glanced at the schematic we realized was because there’s a resistor missing that’s necessary to complete each of the circuits for the buttons. Sophie called me briefly to help me work on soldering small components, which I’ll probably do tomorrow morning.
Dab a bit of the liquid flux on to the pads, put solder on one side of the pads, use tweezers to pick up the component and feed the component to the pad while melting the solder, and then add solder to the other side.
We modified Hunter’s code in the meantime to automatically send a message after 5 characters, which can be entered by the keypad. I also soldered wires onto a DC regulator so that we can use it without it being attached to something, because the wires are small. Hunter and Visuwanaath were able to successfully type out and send a custom message.

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

Date: April 23rd
Start Time: 9:36 PM
Duration: 2 hours

Going to work on our final report rough draft, it’s due at midnight. I probably won’t say much else because it’s pretty basic stuff.

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

Date: April 23rd
Start Time: 2:51 PM
Duration: 5 hours

Working on LoRa with the beacons. Trying to step through LoRa_init function, which sends commands to set parameters for the module. However, only the first command seems to send properly, even though the buffer doesn’t hold anything afterwards. I know it’s sending something because the DMA callback breakpoint that I set is being triggered, meaning the DMA recognizes that there’s data in the buffer even though it’s all 0s. I tried adding a DMA UART_TX channel as well, but it didn’t seem to make any difference. I realized that it won’t make a difference unless I actually use HAL_UART_Transmit_DMA to send data, so I made that change after reading this link. about polling and DMA modes for UART.
We spent several hours trying to figure out what was going on. Eventually we realized that the ground pins of the LoRa chip on the PCB were getting 3.3 V. Looking at the PCB layout, we noticed a host of ground pads on the backside of the module, and when we probed them with a DMM, we got 3.3 V there too. Likely this means that our module is fried, which is a very bad sign. We ended up talking to Shivam, who looked at our layout and didn’t see anything wrong, and then referred us to Dr. Walter. We went into his office and showed him the results we had, after which he said there’s most likely a short between pins and that since the LoRa modules are probably fried (on at least two boards, probably more), we should try to flywire to the RX/TX pads on the board and then connect that to our prototype LoRa modules. I ended up soldering two wires to the board, and then we set up the module on the breadboard with the wires connected, taking care to find common ground for everything. Once again, it didn’t work. Visuwanaath showed up around 7 after Hunter and I took a short break, and we began our debugging efforts again. We are trying to use the oscilloscope in serial mode while connected to the RX/TX pins of the module to capture what it’s sending/receiving. We also have to write our final report, so I’m working on that at the same time. On the prototype board, we managed to get proof that we were both sending and receiving using the serial mode on the oscilloscope. After that, we rigged up the actual board connected to the external LoRa module. There, we checked the connections and realized we had the TX and RX pins switched, because Sophie already made the switch and labeled them for the LoRa module, but we had double switched. Once we did that, we tried to run the code again, this time plugging in the OLED to ensure that the code was actually running. The OLED turned on, but no messages popped up on the oscilloscope. At this point, I left for a previously scheduled event.

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

Date: April 22nd
Start Time: 1:42 PM
Duration: 5 hours

First order of business today is dealing with mechanical design. Going to go to ECE machine shop and see what I can do. I got a form to fill out with measurements, so I’m doing that now. I filled out the form, which took me forever, but he said he’s not gonna be able to do it by thursday, so I want to dremel it myself. I spent a while learning how to use the dremel via youtube, and then I enlisted the help of someone to actually use it. It took roughly an hour for me to figure out how to properly detach the head and all of the respective parts, but we are about ready to go now. I cut two holes in two cases- one for the OLED and one for the wire on the 4x3 keypad. The keypad hole is designed so that the wire feeds through and then the adhesive will go on top of the hole, covering it completely. The first OLED hole that I cut ended up being too high up on top, such that the green PCB of the screen is visible, but the second one looks much better. I haven’t elected to cut the other two yet or cut the holes for our push buttons, because I’m anticipating we have other changes to that part. Niraj came into lab to help us figure out some of these odd issues we’re having. We showed him what our issue is and then we started stepping through the code. We originally thought the issue was with SysTick but after a lot of stepping we realized it wasn’t the issue, but there was something commented out in the vector table, and once it was uncommented, the code ran properly. In the file system_stm32l4xx.c, line 126 is a #define USER_VECT_TAB_ADDRESS, once uncommented the code ran like a dream.
We also wanted to figure out why our PCB doesn’t reset and run without the debugger connected. What we realized is that since the reset button isn’t connected, the NRST pin is floating at ~0.8V, instead of being pulled up to 3.3V like it should. However, when the debugger is connected, it sits at 3.3 V, and can be reset. We need to pull NRST up and solder the button on. We tried connecting a 10K resistor and a wire to RST to pull it up, but that didn’t work. Going to try displaying on the oscilloscope to catch a reset when flashing code with the debugger. We expect that it SHOULD drop to 0 at some point during the process, but we’ll see. We connected the ground pins from the debugger to the ground on the buck and 3.3v sources. Once we did this, we were able to get a successful reset without the debugger after Sophie added a reset button. Niraj mentioned something called “ground plane dissipation”, but I’m not exactly sure what that is. It does work now, which is great! Sophie is going to add a reset button to the other board, as well as flywire the ground planes together so that we can actually use the pcb without it connected to the debugger.

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

Date: April 21st
Start Time: 6:15 PM
Duration: 4 hours

I had to redownload/update KiCad so I could load the schematic. I want to figure out why we can’t power cycle the PCB without the debugger being connected. In this quest, I decided to learn exactly how the ST-Link works. I found a reddit post. That provides a pretty good explanation. At the same time, I also have been trying to work with the LoRa on several boards Sophie just brought. I acquired another DC power supply, and then spent roughly 30 minutes trying to find banana plug to grabber wires, which was fruitless. Once I remembered that I could use the oscilloscope, my life was changed and I hooked that up instead. However, the oscilloscope either doesn’t send a steady 3.3 V or the buck converter doesn’t work properly for this other board, because the power LED doesn’t stay on steadily. After another 10 minute search, I found a couple and was able to power it steadily. Once that was done, I created a new project with the new STM and assigned the proper pins. However, when I run the project it gives me the same issue we were having before, where “Break at address "0x1fff51da" with no debug information available, or outside of program code.” I followed the same process where I checked 0x08000000 and looked for good hex, and then checked 0x42002200 and then checked the swboot0 and other boot0 register, but this time both are set to 0. This means that, according to the chart, the processor may be booting to embedded SRAM? I’m not entirely sure how. I’m going to try running this code on the other board I have on hand. I get the same message for the exact sme address. This address is located in system memory, which means this may be trying to boot to system memory. This is confusing to me, because this would mean nBOOT1 was set to 1, or nSWBOOT0 and BOOT0 are both 1, neither of which seem to be true. I have zero fucking idea what is going on and I’m going to crash out.

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

Date: April 21st
Start Time: 2:05 PM
Duration: 3.5 hours

Back from nationals. Going to post my journals now and look over my teammates’. I sent an email detailing the cuts that we’ll need to make to our enclosure to a friend of mine in the ME machine shop, along with pictures and drawings of the parts. Hunter came into lab describing a problem he wants me to fix- The ST-LINK clone is the only thing that allows a power cycle. When the clone is unplugged, the display stays on, but once the power is turned off and back on, the display doesn’t work again. Since the power pins of the clone aren’t connected to power on our PCB, this means it has to do with the microcontroller’s settings relative to the pins that are connected. I want to look into this more in depth. I also talked to Hunter about how slow the display was, but we fixed this very quickly by increasing the system clock frequency from 4 MHz to 32 MHz.
This is what my friend said in reply: “Making the display visible would require end-milling. Which is a very common thing at the machine shop but is time consuming, especially considering the non-uniform geometry of your enclosure I’m not sure how I would stabilize in the vice for the Mill. Additionally end-milling doesn’t produce 90° corners; they would be rounded. I honestly don’t think I will be able to machine this this week. I’m sorry about that. However I do think that 3D printing would be the easiest and best option. Removing supports is easy, and I would have enough time to bring it to the machine shop to clean it up, or check out items for you (a variety of files). I could also tap the holes for the screws if needed. Another option is CNC. Which is super precise machining that is done through programming. I believe you have access to the Artisan and Fabrication Lab which has CNC. Again, I’m very sorry I can’t machine this for you, both for time and machine shop limitations, but I do want to help you get this done, if you run into other problems let me know and I will machine what I can, but the display (and buttons) is the reason I believe 3d printing would be better. And again, I can tap the hole super quick. Again, sorry for leaving you stranded here.”
I talked to him as well as Shivam a bit more about the issue. It should be doable by hand since it doesn’t need to be super precise. My options are the machine shop below the lab or Bechdel, and Shivam thinks that I may not need an appointment because it would be simple. I think I’m going to take one of those options. However, both are closed now so that will be something I do tomorrow. I talked to Sophie and she gave me two boards with LoRa modules and antennas soldered on, so we can start testing them.

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

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

Date: April 15th
Start Time: 11:30 AM
Duration: 30 min

I went to Dr. Walter’s office hours, where I described the problem to him. He said he’s never heard of what’s happening, but that my first step should be to make sure that we’re actually grounding BOOT0, and then to isolate exactly when we get these weird error messages. Hunter and I briefly discussed yesterday that we thought maybe it was because he’d changed some setting when trying to fix it on the broken microcontroller, which I’m not sure if that’s true but it is worth looking into.

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

Date: April 14th
Start Time: 3:37 PM
Duration: 3 hours

Talked to Hunter and Sophie, we are unable to flash any code to STM32 at this point in time. Voltage doesn’t make it to the heartbeat pin and a plethora of other errors have occurred. I sent a message to one of my knowledgeable coworkers to see if he could help me understand the process of flashing code to an STM32. We found some resources online that show Flash memory of the STM starts at address 0x08000000. There is code written under that address in the Memory tab, which means we are flashing to the microcontroller. Here’s the situation: We occasionally get a message saying “break in address 0x1ff…. With no debug information available, or outside of program code”. When we looked up the message, most resources said to pull the boot0 pin down because it meant that the MCU wasn’t reading from flash. However, we got this message at seemingly random times when running. There were times we would run the same setup back to back and have issues only once. We took this to mean that the pin was floating, and soldered a wire to the pin so that we could manually ground it. However, this didn’t seem to affect the issue. Eventually, we checked the FLASH registers (located at address 0x4002200 in the MCU memory) and with offset of 0x20 for FLASH_OPTR register. (first two bits of second A in highlighted box) We checked the nBOOT0 and nSWBOOT0 pins, which were set to 1 and 0, respectively. According to the diagram in the reference manual,
These definitions align with line 3 of this chart, where BOOT0 is labeled as a DNC and main flash should be selected. It’s possible that I misread the memory configuration, but I believe the issue may lay elsewhere. It feels as though there are two issues at hand here: firstly, we get these random popup messages saying it couldn’t find the code, and secondly, in either case the code doesn’t seem to output- none of the pins being set high in the code show voltage output on a multimeter. I think we’re going to go to office hours for Dr. Walter tomorrow. We switched the boards out and setup the debug configuration. When we flashed the code, we didn’t have any issues flashing and there was no voltage at any of the set pins. However, it turns out that Hunter had forgotten to set them high. Once he did, we started getting voltage. The heartbeat LED is still not turning on, however. We tried the same code on the other board once again and still no dice, so we think there may be something wrong with the microcontroller. With the pull down to boot0 of the working board, we get voltage output. With the pull up to the working board, we do not get voltage output. On this working one, he’s going to try displaying to the OLED with code he “tested” previously on the dev board.

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

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

Date: April 10th
Start Time: 5:26 PM
Duration: 1 hour

Back in the lab after class.Visuwanaath and I spent some time working on the DMA sending and receiving. Ended up deciding to use 1 address for every module. It works fairly well, but it still is a little confusing. Tomorrow we’re gonna add his packet parsing to what we wrote and then try to get that integrated.

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

Date: April 10th
Start Time: 12:40 PM
Duration: 4 hours

Today I want to start implementing UART over DMA. Last time I looked into it, I found a github repository DMA implementation. that details this. I’m gonna read through what’s inside and figure out how this applies to our use case. It’s also been awhile since I’ve done anything DMA related (since 362) so I’ll need to refresh myself on that as well. DMA is effective because it allows the received packet to be stored directly into memory without intervention from the CPU. It works well with low power systems and with larger data transfers. However, the number of bytes must be known. This is definitely something to consider, as I’m not sure if the code Visuwanaath wrote does that. After some reading, I’ve begun to think of a set up for the device. We want to send a packet automatically and on a timer, so if we set up the transmit in normal DMA mode (meaning it’ll only transmit once and then stop), we can call it on a timer so that it’ll transmit this data every so often. However, my concern comes from receiving. I spent 30 minutes setting up Cube on the desktop. Once I got it set up, I added the Lora_init function and the OLED_print function to the project. I set up DMA_RX for USART2. I created the RX_callback and added a line for receive_DMA. I got the receive working similarly to how it was before. However, I’m still having issues with the buffer filling on incrementing indexes. I’m trying to change this so that it’ll reset the buffer and fill from index 0 every time. My solution is to create an “init_buffer” with 5 characters, so that whenever I want to check whether I successfully sent an AT command to my own lora module, it will return +OK. This way the buffer will also be filled with each one, but I need to figure out when to reset the buffer to 0. Right now, it’s happening in the callback. I ended up solving the problem by creating the packet and init buffers. When I want to check whether something returned a +OK, I set init to 1, which means it’ll check the init_buffer. Otherwise it’ll check the packet buffer. In the init case, it checks whether the init_buffer == +OK in a while loop before setting to 0 and running the dma again.

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

Date: April 9th
Start Time: 3:30 PM
Duration: 2 hours

ManLab. I spent some time talking with Sophie, Hunter, and Visuwanaath trying to figure out and itemize the tasks we have left before this project is done. Here’s the base list:
Assembly: we need to continue adding parts onto the PCB and verifying to make sure they work
Mesh network: visuwanaath spent some time last week writing code to serialize and de-serialize packets that will get sent out as well as to create a set of packet types that represent different functions for the device. This includes packets that each device will automatically send out in order to add/be added to lists from other devices. We need to test what he’s written so far on the LoRa modules and build a mesh network.
State machine: we need to build a state machine that encapsulates all of the device’s function- from the mesh network aspect to the gps coords, this will include all of the menus, packets to be sent automatically, and the gps function
Machining: we need to get all of the holes cut in our device, for our screen, antenna, and the buttons/cable for the keypad. This isn’t super urgent, but definitely would give our project a finished look and be helpful. Talk to Nick in the ME machine shop or look into the Bechdel design center to figure out what the explicit next steps are for that.
Integration: we’ve sent basic packages on the prototype board and prototyped the gps and IMU individually, but we haven’t put anything together yet. This goes along with the state machine, but we need to figure out how all of the code for these modules will fit together. As I said, this will get done with the state machine and will probably be one of the last things we do software-wise.
The UI is also important. Since this is a prototype, our UI doesn’t have to be super in-depth, but it would be good to have a reliable and simple setup. Sophie is soldering on the OLED now, so once that’s on I want Hunter to start on this.
Low power: this isn’t really a PSDR but since battery efficiency is a large part of our device, we should start looking into the low power modes on the micro we bought and figure out how to integrate those into our design. One consideration is that it has LPUART, which is PA2,3. These are connected to our LoRa module, which is great for us.
Optimization: since this is a small-memory and portable device, we should try to optimize the battery life and the memory. This is our last priority and only will happen if/once we get everything else done
We also have some stuff to return, which isn’t really too much of an issue
Tomorrow, I’ll come into the lab after 11:45 AM and work on LoRa interfacing with DMA. After class tomorrow, I’m going to work with Visuwanaath on integrating his packet serializing code with LoRa so that we can be sending fully encoded packets by the end of this week. I assume it’ll take some time to get that working, so I’m giving us until the end of this week and Monday and Tuesday next week to get that working. If we finish that early, I want to begin setting up the full workflow of our product, meaning: creating global variables, data structures to store what we need to, and setting up the actual functionality. Hunter will work on the UI for the OLED while we do this and Sophie will continue to solder. Before I leave for nationals, I’d also like to have at least an exact plan for how we’ll create our cutouts in the packages.

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

Date: April 8th
Start Time: 5:36 PM
Duration: 2 hours

I’m in the lab today and I want to take some time and plan out the rest of our semester. We need to check off three PSDRs before our final demonstration, which will likely be Thursday April 24th or the 25th. The three that we will most likely get checked are the PSDR for our buck converter, for LoRa interfacing, and for OLED interfacing. OLED and buck converter are both hardware, while our LoRa send PSDR is software. We need to have a better, more coordinated handle on the software we’ll develop before our final demo. I also want to read up on what Visuwanaath has been working on, so that we don’t duplicate our work. Reading up on his journal, it seems as though he’s working on packet formation and parsing. He built a union containing all different packet types and cases for parsing through each one while conserving memory as much as possible. Based on his work, it seems like the best next steps are for me to continue working with the LoRa modules and streamline the sending process. My first step is to figure out how to properly reset and set the buffer so that it’s easy to check for proper receives. Previously, I tried implementing a while loop that would wait while(buffer != "+OK\r\n"). However, this condition never seems to complete. When opening the loop and printing the contents of buffer typecasted to a char * within the loop, it prints “+OK” with another unspecified character that looks like a colon and a period together. It prints the same when not typecasted, which makes sense. This behavior doesn’t change when typecasting the string buffer is compared to with a char *. Here’s a screenshot of me running on the debugger. You can see that within each of the first 5 array indices, the buffer contains “+OK\r\n”. This has me slightly confused. After a few google searches, I believe that my error may come from the lack of a null terminator within the buffer. From this link: (Stack overflow.) . I’m going to try using the strncmp function to do this by setting a string length that excludes the null terminator. while(strncmp(buffer, compare, 5)){ OLED_SendString(buffer); } This was the code I added, which was bypassed and this means it worked properly. I set compare to be equal to the string I want to compare to, and I figure that since the majority of transmits from lora will return this exact message, it’s worth storing. Next, I want to make sure I can clear the buffer after each time it’s filled so that it doesn’t just compare with the results of the previous send. I added a line that sets every index of the buffer to 0 once the +OK is received and then moves on to send once again. However, when running the debugger I noticed that the next +OK received is actually still 5 indexes from the top. It seems as though there’s something that tracks the index to store the next return from the buffer in. I’m going to look at the HAL_receive_IT function to understand this a little better. After some searches, it seems like the HAL IT function is not useful for repeated sends and receives, and a better solution would be to set up a DMA to handle it and take some load off of the CPU. I’m going to work on this tomorrow, here’s a link I found of a DMA implementation: (DMA implementation.

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

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

Date: April 2nd
Start Time: 2:48 PM
Duration: 4 hours

Today in the lab trying to get two LoRa modules communicating with one another. By looking at the RYLR896 AT command manual, there’s a step by step process listed. The first thing I wanted to change was to streamline the process of printing the messages received from our LoRa module by printing them within the receive interrupt callback. However, I’m having many issues with getting the setup to even connect to Cube. I switched to the other LoRa setup and the issues ceased. However, it seems as though the buffer doesn’t get printed when it prints in the interrupt. After reverting, I decided it’s best to start working on initializing both LoRa modules. I created a function called LoRa_init which will follow the step by step process above. I set the address to 100, the network ID to 3, and the band to 915 MHz. Network ID and band must be the same for both devices. I sent all of these to the LoRa module. I added a while(buffer != “+OK\r\n”); line after each one gets set, but it doesn’t appear to be sending each one. Either that, or it’s entering a loop of some kind. I tried switching it out for a HAL_Delay(50) between each transmission as well as using a blocking transmit function instead of a transmit_IT function. Once I removed the OLED printing from the callback function, it printed all messages in succession. Here’s a screenshot of the function: However, this isn’t a certainty that the code actually works. One other thing to consider is that when sending larger blocks of data, we should use DMA for it. I found a website that provides a helpful tutorial for setting that up, which I plan on following once I have a better understanding. After printing the buffer to the OLED, we realized that it’s receiving an error message, not a +OK. This is why the while loop wasn’t working properly before. ERR=1 means that our message being sent isn’t properly terminated. Previously, I fixed this by setting each message to a fixed-length array where the null terminator didn’t fit. However, when we want to send variable-length packets, this won’t work. We fixed this the easy way, using the same solution as above. Now, I have a 15 character buffer that prints “+OK:” after it’s received, but it fills the buffer each time. So the first time, it prints “+OK:”, the second time, it prints “+OK:+OK:”, and adds a third one the third time. I want to be able to check the buffer and not let the code move forward until I’ve received a +OK. Attempting to run the debugger caused a lot of issues, and trying to modify my clock speed didn’t seem to help. After some time, I decided to try setting a GPIO pin in the interrupt callback. I chose to set PC14 to a GPIO output pin and putting an LED in that pin, with the other pin connected to ground. This didn’t seem to work either. Since these issues aren’t exactly functional and we know we’re setting all of our parameters, we’re going to try to send a message from one module to another. Module 1 is connected to my computer and module 2 is connected to Hunter’s. His is set to address 101, while mine is address 100, they’re both on network 3. Using the following command: "AT+SEND=100,16,Hello, Hunter.\r\n" I attempted to send Hello, Hunter as a message to his module. I get a +OK, but Hunter doesn’t appear to receive it. I realized that 100 isn’t the correct address, and once I fixed that, it worked! He got the message and it displayed on his OLED. A big step forward for today!

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

Date: April 1st
Start Time: 11:00 AM
Duration: 45 minutes

Happy April Fool’s! I’m in lab for roughly 45 minutes, so I want to retest the board once again to make sure I didn’t do something wrong last time. After a quick retest, it looks like C4 is still getting ~4.2 V, and the inductor has no voltage across it. I went to the ECE shop, where they x-rayed the circuit and it looks like the solder around the inductor is fine. I’m not exactly sure, but it seems like the part itself may just be faulty?

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

Date: March 31st
Start Time: 4:17 PM
Duration: 2 hours

In the lab today, I need to make some serious prototyping progress this week. The biggest thing would be getting the LoRa modules sending back and forth. However, after my git issues, the repository I was using for my project got corrupted and now is unusable, meaning I had to create an entirely new project. Now, there is nothing showing on the display, which isn’t ideal. The issue was a simple fix, just had to change the SPI word length to 10 bits from 4. Note to self-> the setting for data length is under “Parameter Settings”. Once that was fixed, it displayed again.
However, I learned that Sophie has strep, which means I need to shift gears to more hardware issues. She attempted to begin soldering the buck converter and it sounds like there isn’t any power output. Since there is a 9 V input, this is definitely an issue. In a quick conversation she told me that with a 9 V input, we get around 1.6 V through C4 into the inductor. Since we already performed electrical checks across the entire board, it’s most likely something to do with the solder. I talked to Shivam as well, who said that a good first step is to go to the ECE shop and see if I could possibly get it x-rayed for bridges or shorts. The x-ray is a good way to tell exactly what’s wrong with the solder, if there is an issue. Since the ECE shop is closed, that’ll be a problem for tomorrow. However, I would like to check the connections between some of the parts using a multimeter tonight and record what I get. C3- 9 V, C2- 9 V, R8 ~0V, R9~ 0V, R10~ 0V. Notably, there’s 4.2 V across U2, which is a TPS629330 voltage buck converter, from VIN to SW. C4- 4.6 V, and C5~ 0V. It seems as though everything up to this inductor is connected properly, since there is voltage across the capacitor before. From here, I’m not sure if I can really do much more on my own since Shivam left. Going to take a dinner break and then come back to do more with the LoRa modules.

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

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

Date: March 28th
Start Time: 3:30 PM
Duration: 5 hours

Firstly, I emailed Dr. Walter about our PSDR change to let him know that we’ll be modifying PSDR #4 to 200 characters. After sending the email, I updated it on the website and the checkoff sheet, which I then printed on the printer in the lab. Next step is working on the Legal and Regulatory analysis assignment. I looked up the various organizations referenced in the slides as well as in the red text of the word document. On each official website, I looked for the scope of the organization and determined whether the buddy beacon would fall under that scope. I started with organizations that I figured wouldn’t be in our area, such as the FAA, FDA, CRDH, and ITAR. However, the IEC, CE, FCC, and RoHS all have standards that our device most likely falls under. The FCC is the primary body that manages standards for all electronic devices in the US, and CE does the same thing for the European Union. If intending to sell our product in the US and Europe, we need to be certified by both organizations. The IEC is an international organization that collects and creates guidelines and rules for manufacturers to follow when developing a wide scope of products. While an IEC certification isn’t necessary, these standards are held by many countries and provide a good confidence level.The IEC has a variety of “fundamentals”, many of which our device should be tested on. The Ingress Protection (IP) rating system falls under this category. These ratings give a number that represents both the water resistance and dust resistance of a device. As an outdoor product, our device would be a good candidate to obtain an IP rating as well as get a certification for.
Another example of an applicable fundamental is electromagnetic compatibility, or EMC. This works to determine if a device may not be safe to use in certain settings, such as a hospital or an aircraft, based on EMI. Because our device uses LoRa radio technology and GPS technology, EMI is something to be taken into consideration, especially when multiple devices are within a close vicinity. RoHS is an EU directive that regulates the quantity per weight of certain heavy metals in electronic devices, such as cadmium, lead, and mercury. SInce we are using a lead-based solder, we need to be certain that we meet the required 0.1% maximum. We also need to make sure that capacitors and other discrete components won’t exceed their respective numbers as well. Since we’re using 9V Alkaline batteries, there’s no cadmium or mercury.

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

Date: March 28th
Start Time: 9:10 AM
Duration: 1 hour

I came into the lab and started off with the quiz. After that was completed I ended up creating a new STM32 project from scratch, and adding all of the pins that I had before. I copied in the main file because I’d sent it to Hunter previously. However, the debugger is extremely finicky. I can’t get the code to run fully, instead of printing “Waiting for LoRa…” as the code expects, it prints “Waiting.” and doesn’t refresh on a loop. It’s a little perplexing, and it hasn’t actually run properly once. Every time I’ve tried to re-flash the code, it either doesn’t run or only prints that. I realized that I forgot to add #include #include . I also accidentally copied an extra while loop into my main.c. However, even after correcting my code it still will not display anything.

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

Date: March 26th
Start Time: 3:30 PM
Duration: 3 hours

I came into the lab and started by creating the PSDR Checkoff sheet and the Legal and Regulatory documents. Sophie is doing the visual inspection of our PCBs and Visuwanaath and Hunter have started working on software design. I have some concerns about our PCB clearances with the push buttons, the antenna, and the screen. The edges of our OLED screen peek past the case and cover our antenna spot when it clears the push buttons on the PCB, and it completely covers the top button when clear of the antenna.
Another concern is the character limit, which as noted previously, is 240 bytes for a single LoRa transmission from the RYLR896. The RYLR993 is slightly better, with a payload of 242 bytes, and we’ve been given permission to modify our PSDR from 300 characters to lower it. Once we get a better number to work with, we’ll modify that. With a 1 B packet number, a 12 B beacon UID, a 12 B receiver UID, 16 B Beacon name, a 1 B message length, that means the maximum message size could be 216 bytes/chars. However, we want some leeway, so we’re going to use a 200 byte cap. However, we’ll need to modify our PSDR 4- instead of 300 characters maximum, it’ll be 200. Note- this isn’t final, I will email Prof. Walter once Hunter and Visuwanaath figure out the final number. I did fill out the Final Checkoff Sheet, but won’t print until we know. I need to figure out how we’ll cut the proper holes in our package. One idea that Hunter had was to actually solder the antenna attachment to the back of the PCB, and cut a hole out the back side of the case instead of on top. This would also solve an issue with the attachment, as the antenna will screw in perpendicularly. The solution would be slightly odd, but for our prototype it should be fine. For the Legal analysis, I spent some time looking at the various organizations that we may need to certify with, which appears to be just the FCC.
We’re going to get our Git working on STM32Cube. I found a video tutorial (same as the one I followed in Harry’s STMicro UART with HAL Guide.) and am going to see how to finish it out. I started by cloning the Github repository into Cube, and once I did this I realized it was a mistake. I also realzied that in past work, I’d already created a repository for the project within the IDE, which interfered with my ability to put one into the other. I attempted to merge repositories, and while I thought I succeeded in pushing the project into a branch, the folder containing all important files and drivers was inaccessible. When I tried rerunning the code on the development setup, I got an error “the selection cannot be lost”, because in the process I accidentally deleted the .project file. I think my best course of action is to create a new project from scratch and copy the main file back in once I’m done.

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

Date: March 25th
Start Time: 2:24 PM
Duration: 0.5 hours

This week the Legal and Regulatory Analysis assignment is due. The other three that will be due are the Reliability and Safety Analysis, Ethical and Environmental Analysis, and the User Manual. The User Manual is due April 19th, meaning the week of my club volleyball nationals tournament, which goes from 04/16/25 - 04/20/25, meaning I won’t be able to contribute as much in mind. Therefore, I need to delegate assignments based on who is able to put in more time those weeks. Sophie has an exam this week, next week, and a project after that, so she is going to do the User Manual. Hunter has an exam this week, and Visuwanaath has one next week, so I’m going to do this week’s assignment, Hunter will do next week’s, and Visuwanaath will do the one after that.

=============== Week 10: =================

No work- Spring Break

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

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

Date: March 14th
Start Time: 3:08 PM
Duration: 1 hour

Continuing to work on a send function. I wrote the following code:

This function is supposed to send a message and wait to make sure that it’s properly received. When the message is delivered it receives a +OK. Right now it’s not super fleshed out, because I was more concerned with getting proper concatenation of the AT command. I calculated the maximum size of the command being sent based on a few things. According to the LoRa command manual, the max payload size is 240 bytes. Since we said we could send messages up to 300 characters, that will be something to think about. It might have to be sent as multiple messages or split up in some way. But the AT format is 15 characters + the message itself, and then that gets sent using the HAL_UART function. I’m a little worried that this receive format is going to infinitely loop if it doesn’t send properly. However, I can’t test it because I don’t have a LoRa module with me. A few other interesting things that I noticed from the LoRa Command document are that you can set a password for AES128 encryption, that you set your network ID and address manually, and that you can set basically any parameter for sending, even frequency band. Lots to explore!

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

Date: March 14th
Start Time: 10:24 AM
Duration: 2 hour

Happy Pi day! Today I’m in the lab once again. I first want to spend some time reviewing Hunter’s code which he posted in Github so that I can understand a little bit more about how the OLED works. The code of interest is posted in the Source section of the website, under the file OLED_print.c, in the function OLED_sendString(String). For the most part, the code makes sense. It’s fairly similar to some of what I wrote in terms of how it loops through the string character by character. However, there are a few lines that confused me. Firstly, this section:
I was under the impression that putting the cursor in the first spot was done by setting SPI1 -> DR = 0x02, not 80. However, when I changed it to 0x02, it didn’t change anything. The other portion of the screenshot above that confuses me is the setting of DR -> 0x06, which he says is to move the cursor after each character. However, this only happens once at the start of the function and not after each character. There are several comments above it that makes it clear Hunter doesn’t know why this is needed either, but the code breaks without it. I commented the lines out and it does work when run, but once unplugged and plugged back in it stops functioning properly. It only prints one character on each line and not any of the other letters, spaces, etc. I tried setting the DR directly to 0x06 instead of 0x02 or 0x80, but when run, the code doesn’t properly print any of the extra characters on overflowing screens like it should. The OLED display output doesn’t change once it’s power cycled, however. I tried using this function in conjunction with the UART LoRa module, and it prints nonsense until the buffer is filled. Once the buffer is filled, it prints “+MODE=0XX” with X being a nonsense character, but once the function refreshes it rotates once to “MODE=0XX+”, and so on. The connection between the MCU and my laptop is extremely finicky. Around 50% of the time trying to run as a debugger I get some sort of connection error, which is slowing my progress considerably. Next step is to get LoRa modules sending back and forth and then displaying. I added some logic that only prints the message if it’s been received, otherwise it prints “Waiting for LoRa…”. The send LoRa command has format as follows:

I started writing a function called LoRa_sendmsg that takes a string and the address and sends it to another LoRa module. The address must be known for this to work. A lot of string concatenation is required, which I’ll work on once I come back.

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

Date: March 12th
Start Time: 2:35 PM
Duration: 4 hours

Came into lab to work on prototyping. My goal is to work on sending messages back and forth between lora modules and display them on the screen, but when I ran the same exact code, it didn’t work. I’m very confused.
I was able to improve it to displaying more of the characters by increasing the delay between each send.

After this, I tried switching to the HAL version and that fixed it almost immediately.


My next goal will be to write a quick function that will convert a string into something that can be passed in as an argument to the SPI_Transmit function. This way I can take the string that’s received by LoRa and display it directly on the screen. Things devolved very quickly. The code I wrote was extremely inconsistent and I didn’t understand very well how the screen works. After another hour of debugging, we were able to figure out how the screen works a bit more. Displaying one character at a time requires setting the cursor and moving it each time. On the top row, to move the cursor one character you increment it by 4. On the bottom row, you increment by one or sometimes 0. If you send the entire message at once, it prints in little endian format, meaning that the first character (H) prints on the screen and the rest of the word wraps off the screen to the left. If you wait, the word will wrap around the bottom right corner but backwards. The code that I wrote below prints “HELLO” on both lines until a message is received by the buffer via LoRa, at which point it prints out the entire contents of the buffer instead (up to the \r\n that end it). Currently, the buffer tends to scroll each time, which is slightly vexing. It will print the + first time, and then will start with the M next time, while the + will be wrapped around to the back.

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

Date: March 11th
Start Time: 3:17 PM
Duration: 1 hour

Came into lab and Hunter was working on the OLED screen. He figured out our issue in a meeting with Niraj this morning, which was basically just that we were in 8 bit SPI mode when we have to be in 10 bit. By changing the mode in the SPI1 init function, we were able to get something to display. Next step is getting a specific message to display. We found the 362 lab code for reference and are semi-following it. He was able to get “Message Received” to display on the first line, but nothing on the second. I started by redeclaring the NSS pin (PE12) and then copying his clock and peripheral settings. After that, I sent the commands to initialize the display and it turned on. I was super happy about that, but I wanted to play around with the cursor setting and try displaying things on both levels, so I displayed a message on level one and level two by sending 0x02 and 0xC0 to the SPI1 -> DR, respectively. I attempted to display the message “HALLO” on both lines, but was only able to get fuzz on line two. After adding the 0x200 to let the display know I was writing to it, I got the message to successfully display.

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

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

Date: March 5th
Start Time: 11:30 AM
Duration: 3 hours

Finished my sections of the presentation, which were the component analysis, mechanical/packaging, block diagram, and gantt chart. After I finished those, we did a practice run through and then I practiced my parts on my own.

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

Date: March 4th
Start Time: 1:50 PM
Duration: 3 hours

Working on the presentation again. The major components I’m going to review are microcontrollers, LoRa modules, GPS modules, OLED displays, and matrix keypads. The two microcontroller choices are STm32L4 and F4 series micros, which I already wrote most of the slide for. I wrote about how we chose the L4 series primarily for its low power mode capabilities and because we didn’t need the faster clock that the F4 series offers.Regarding LoRa modules, we chose the RYLR993 because we couldn’t find a surface mount version of the 896. The 896 used the 890 and sx1276, which we didn’t want to implement on our pcb for complexity reasons. We chose our GPS module (the SAM-M8Q) because we had it in lab, it worked, and we didn’t really find any other good options when looking (a lot of our comparable options were obsolete). We chose our OLED display purely because we wanted the larger size display, and we needed a graphical display.

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

Date: March 3rd
Start Time: 3:51 PM
Duration: 2.5 hours

In the lab, continuing to work on the presentation I started yesterday. I delegated Sophie and Hunter to work on firstly finishing the PCB design and secondly uploading the schematic and layout to the slides. I plan on filling the gaps and doing kind of whatever is left. I think I want Visuwanaath to handle the prototyping progress section of the presentation, and I’ll do most of the introductory stuff, major components, and the timeline. Sophie is going to handle the PCB layout and Hunter is going to do the schematic. I need to figure out some way to create a picture of the “finished product”, because the group presentation examples were very polished looking, and I don’t have any idea how to make something of that caliber. I also need to find a software for creating some form of timeline. Two of the ones I know of are Microsoft Project and ProjectLibre. Microsoft Project is unfortunately paid to use and you need a subscription for it, so that doesn’t seem like a feasible option. My other choice is ProjectLibre, which supposedly has a free trial but I need a TA to download the software for me. Before writing any slides, I went onto our webpage and uploaded all of the remaining datasheets and reports that weren’t already present. I also added pictures to our website to flesh it out more, like a few to the Media section, and a team picture to head the Team section. I added some fun code Easter eggs into our webpage… With some assistance from ChatGPT, I was able to make the transition a bit more pronounced, but not as easy to trigger.

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

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

Date: February 21st
Start Time: 11:47am
Duration: 2 hours

Today I’m in the lab, planning on picking up where I left off. I’m using an article for reference:
STMicro UART with HAL Guide. It shows how to set up UART between two devices, and it does say that the HAL_UART_Receive function does only receive once. This leads me to wonder if maybe we’re only receiving the first character. I first switched out the HAL_UART_Transmit with the Interrupt version and enabled the UART global interrupt in the NVIC settings of the .ioc file. After code generation, I got the same result. Next, I tried adding the Receive_IT function instead of regular receive. Once I implemented this along with the callback for it, I set a breakpoint in the callback and ran the debugger. Here, I was able to see that I am now getting the message “+ERR=1\r\n+E”, which is just a repeating message saying there was an error in the encoded message. Looking in the list of AT commands in the “LoRa AT Command RYLR40x_RYLR89x_EN” pdf, ERR=1 means that “There is not “enter” or 0x0D 0x0A in the end of the AT Command.” I then changed the size of the message array to 11 explicitly and tried sending the “AT+MODE?\r\n” command. This time, I received an ERR=4, which means that it’s an unknown command. I looked at the format of the message array and noticed that there’s an extra array slot for the null termination. By shrinking the message array size by one, I was able to remove the null terminator of the string, and I finally received the command “MODE=0” repeating, which meant the command was working. Here’s a screenshot of the main loop of code with the final result stored into ‘buffer’ in the “Expressions” section on the right.

Now that I’ve ensured the LoRa module works, I’m going to set up the screen separately and then attempt to display the LoRa message on it. I only have access to one LoRa module at this point in time, since Visuwanaath has the other with him.
For the OLED, since I’m using the SOC1602A for prototyping, I found the manual for it: SOC1602A OLED Manual. I’m using the 4-pin serial setup at this point in time, so I’m referring to section 11 of the manual, titled “Serial Interface”. I’m going to read through the manual to refresh myself on how to connect to it. I’m also using the ST webpage on SPI connectivity with HAL, linked here: STMicro SPI with HAL Guide. However, I ran out of time to work on this, so I’ll pick up with the OLED next week, and work to build a full prototype. I also have attached an image of the current circuit for reference:

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

Date: February 20th
Start Time: 5:30pm
Duration: 2.5 hours

Today I’m starting by testing my LoRa module with an ESP32 feather v2 board (datasheet here: Adafruit ESP32 Feather V2 Manual.) I have the MCU from a previous class. I brought it into the lab with me and connected it to my laptop, running Thonny (a MicroPython editor). From here, I wired the RX/TX pins on the board (pins 16 and 17) to the RYLR896 module and created a basic micropython file. I followed along with a MicroPython quick reference: MicroPython Quick Reference and modified the code slightly to send an “AT+\r\n”, but started getting an infinite loop of “Invalid Header: 0xFFFFFFFF that I couldn’t fix. However, while debugging it I realized that I connected the TX pin for the MCU and the LoRa module to one another, instead of TX of one to RX of the other, and vice versa. A little bit of a rookie mistake, but upon realizing that, I put the chip back on the board with the STM32. After rerunning the code, it started running an infinite loop without actually receiving anything. To fix this, I turned the delay in each receive from HAL_MAX_DELAY down to 1 second (1000 ms). Now, I receive a ‘+’, but I should be expecting a +OK. However, whether I send the command as before or an “AT+RESET\r\n”, I get the same response from the LoRa module. I tried messing with the baud rate, which didn’t work. I also tried receiving messages on a loop to see if it would receive character by character. That didn’t work either. I then tried increasing the clock speed from MSI RC- which is set to 4KHz to 16MHz, the system clock speed, because I figured that maybe the high baud rate required a faster clock than what I had currently. This also didn’t work, sadly. Here’s a screenshot of how I configured the clocks for the USART2 peripheral.

Even when sending a random message (one not fitting the AT command format, like “random”) only a ‘+’ was returned. The buffer I store the returned message in is a 50 slot array, so space is not an issue. I think my next step should be to try using the HAL_UART_Receive_IT function instead of the regular receive, but I don’t have time to do that tonight.

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

Date: February 19th
Start Time: 3:30pm
Duration: 3 hours

In ManLab, we’ve started building a breadboard prototype. Visuwanaath and I are working together to build two of them. I wired the RYLR 896, which uses RX/TX (USART) and connected it to PA2 and PA3, respectively. The GPS module I connected via I2c to pins PB6 and PB7. We wanted to connect the OLED display (SOC1602A) to SPI_1 using pins PA4-7, but realized that they aren’t on the development board, so we found PE12-15, which function as NSS, SCK, MISO, and MOSI, respectively. I connected the display serially using SDI-> MOSI, SDO-> MISO, SCK-> SCL, and CS-> NSS.
I connected all of these peripherals, and now it’s time to test them. FIrstly, I use STM32Cube to generate code for the assigned pins in their alternate functions. I’m using the HAL driver code. I want to test the LoRa module by sending a message, so I created some starter code to do that. In the RYLR 896 module webpage, there’s a PDF of all of the AT commands we send and receive via LoRa, and I’m referencing that. Within an infinite loop, I added the following set of code:

This code should send message, encoded as an AT command, to the LoRa module, which should then send back a “+OK”. However, I could not get the code to receive anything. I attempted to use debug mode and step through line by line, but to no avail. One thing I did realize is that the way I was storing the messages meant I wasn’t sending the entire quoted line, just the first letter. I fixed this by changing the data type to a uint8_t message[] array. I also shrunk it to only send one command, the “AT+\r\n” command, and still to no avail. I have an ESP32 at home that I’ll use to test the LoRa module to make sure it works, but I measured the rails of the breadboard and it does appear to be getting power. We also measured the TX pin with an oscilloscope and saw that it was sending out varied voltage signals, which we took to assume messages were being transmitted. However, there wasn’t any variance in the RX voltage, and so we figured that it meant that messages weren't being received. We didn’t come up with a fix for this tonight, but I plan on testing the LoRa module with an ESP32 that I have at home to make sure the module itself is functional.

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

Date: February 18th
Start Time: 5:30pm
Duration: 1 hour

I’m in lab with the full group, I want to start prototyping. We have two dev boards with STM32L476 chips on them, and I think we should build two devices using them to communicate back and forth. I talked to Prof Walter, who said he recommends using STM32Cube for that, because it builds all of the drivers for you automatically, which is super convenient for our use. I tried to download STM32Cube on the lab station, but I don’t have administrator privileges. I instead decided to download it on my personal laptop, and once I did I opened it up and created a blank project using the STM32L476VGT6 chip in the library. It generated a .ioc file but it wouldn’t build code, so I had to troubleshoot that. It turns out Visuwanaath, who was doing the same thing with his board on his laptop, had the same issue and we figured out that it was because the Cube doesn’t let users download code unless you create a free account. Once I did that, it was smooth sailing from there. I created a project and generated drivers and code. From there, I figured it was time to begin building a physical prototype. I think my first step is going to be connecting the display, then the LoRa module so that we can send messages back and forth and show them on the displays. However, one thing I realized later on is that this dev board is obsolete. I looked at its manual and it doesn’t appear to have very much interfacing. There’s no SPI buses, just I2C, which is a little annoying. I think I need to talk to Shivam and see if there are better options for us to prototype with.

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

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

Date: February 14th
Start Time: 1:00pm
Duration: 3 hours

Just at home today, working on finishing the mechanical overview assignment. I found and uploaded sketches of the enclosure and antenna in their datasheets and also have two products to write about and compare to ours. Firstly is the SpotX Two-Way Satellite Messenger. It's a very well packaged product. According to the official website, it measures 6. 34" by 2. 9" by 0. 94".
For comparisons, our enclosure is the H65 Serpac Handheld. It measures 4. 94 in tall, 2. 75 in wide, and 0.94 in deep.

Our product will measure roughly 8 in tall with the antenna fully extended. When it's folded, it will be 6 in. tall. The other product I'm examining is the Garmin eTrex. This product is a GPS, so it's kind of the other side of our function. It measures 4. 0 " by 2.4" by 1. 3". It's covered in a plastic/rubber mix and the screen is listed as "chemically strengthened glass" on the site. It has two buttons on each side of the device for navigation. Our device can definitely take inspiration from the small screen, but we definitely need more buttons for UI. However, it's important to note this device has much more narrow functionality. PCB design -the most important thing is that our Lora and GPS modules are on opposite sides of the PCB. Other than that, It doesn't matter much, but the microcontroller should be centered relative to the other parts on the board.
AII links are in the "parts" document we created. I created a "footprint" in DrawIO that is a not-to-scale drawing of a PCB with all of the parts on it. I added all of the links to the parts into the table in the assignment, read through, and then submitted my work.

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

Date: February 12th
Start Time: 2:00pm
Duration: 5 hours

Notes from Lab start: update website with datasheets In the lab, I'm working on the Mechanical Overview. Hunter found a case that we can use and modify for our design called the H65 handheld enclosure. It even has a 9V battery compartment. The website for it also has the CAD files linked for download, which is a huge plus and will make my design effort much easier, I need to modify the model and add cutouts/parts for:
- old screen
- keypad/wires coming through
- buttons
- antenna
On the Digikey part link for the antenna, I found all of its dimensions in the datasheet.
Based on these dimensions, I'm going to start building a rough CAD model to insert in the assignment. I also found a CAD model for the entire H65 enclosure we plan on using. It's linked under the "Models" section in the H65 Handheld Enclosure
After talking with Prof Walter, I learned that I don't need a full 3D CAD model and can work with the sketches for the case we chose and the antenna. Because of this, I added the sketches to the website. I need to remember to cite them. However, this does mean that the CAD model I started building (even though I didn’t make fantastic progress) was a waste of time and a dead end.
Hunter and I once again updated the functional description on the website to include low-power modes, the antenna (and the fact it folds), the stretch PSDRs, the types of commands we're sending over LoRa (AT commands), the mesh network, and other miscellaneous stuff. He sent an email to Professor Walter so that we can receive feedback on them.

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

Date: February 11th
Start Time: 5:25pm
Duration: 2 hours

Hunter, Sophie, and I came to lab after lecture. I intend to start writing the mechanical Overview and work on updating PSDRs, I have notes from Manlab last week with specific changes to some of the PSDRs, which I'll update this weeks. A large drawback of our current design is our keypad. The 4x3 matrix is most definitely not ideal for typing entire custom messages. Because of this, I'd like to spend some more time tonight looking for an alternative to the 4x3. After around an hour of searching, I don't feel very good about the odds. Here's what Hunter and I have found:
- a BlackBerry (yes, the phone)QWERTY keypad-completely obsolete, the ones for sale were single models on eBay, and we can't interface with it.
- many variations of the BlackBerry Keypad soldered on to PCB -it looked promising, but every model we could find was either obsolete or too wide for our form factor.
Link: BlackBerry Keyboard on PCB
- the mini PiQWERTY USB mechanical thumb keyboard-too wide for our form factor.
Link: Mini PiQWERTY USB wired Keyboard
- TT60 mini keyboard-only have bluetooth models.
Link: TTGO wireless
I also found a video of a very small mechanical keyboard, titled I made the Worlds Smallest Keyboard (WITH RGB) , where the creator makes a very small keyboard, because I wanted to see how he does it. He used mouse switches and put them on a tiny version of a keyboard PCB. Unfortunately, that doesn't seem plausible for us as it's very time consuming. The other keyboard idea that Hunter and I discussed is a capacitive touch Keyboard, similar to a smartphone. We searched Digikey but all options were very expensive and it seems complex to implement.

Since we already have a lot on our plate, and because we found basically zero good options, we're decided to stick with the 4x3 keyboard matrix and deal with its annoyances.

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

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

Date: February 7th
Start Time: 2:00pm
Duration: 2.5 hours

I'm in the lab today to work on the component analysis document and submit my journals to the webpage. I plan on being here for >2 hours to get this done, and I want to assign certain parts of the assignment to others that spent more time on it. I gave the GPS module and antennae sections to Hunter, the hall effect sensor section to Viswanath, and wrote the MCU and LoRa sections myself. Here, I basically just reiterated conclusions that I've already written in this journal.
-I noted that we picked the L4 + series for the low power functionality and chose the L4R5 specifically because It has a pretty basic feature set outside of that.
-We picked the RYLR993 module over the 896 because of the antenna mostly -not having to solder/desolder it is a major plus, and it uses an STM32 SOC architecture that we know is compatible with our MCU.
Now, I plan on updating my journals on the website before calling it for the weekend.

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

Date: February 5th
Start Time: 12:00pm
Duration: 7 hours

I'm trying to follow the SolidWorks built in tutorials, but I'm running into issues when logging in. It keeps asking me for my company, which I do not have an answer for. I was able to find a different way to access the tutorials in app and get started making a part. So far, it's pretty straightforward, but there's a lot that goes into it. Notably, you have to set all of the dimensions down to the mm, which is pretty exact. At this point in time, I'm not sure exactly how to determine dimensions. I'm currently following the tutorial for a specific part. It seems as though CAD mostly involves starting with a shape in the features tab, and then setting a dimension for it. from there, you can set, modify, or create any number of other features on the part. Some examples include a fillet (which is like rounding) on edges, putting holes in a currently built design (which there are multiple ways to do) and a lot of other things that I have yet to learn about. I finished my first part in SolidWorks: It's tilted Pressure Plate and it looks pretty complete! The most important thing I learned was probably the part creation to feature creation workflow. Generally you want to start larger/more general and add features/fillets as you go on and get more precise. Now that this Is done, we are going to discuss parts and attempt to narrow down which models we want to use for all required parts.
On part agenda:
- LoRa modules
- GPS modules
- microcontroller
- voltage converter
- IMU/hall effect sensor
- Antennae maybe (time dependent)
- Dpad? maybe (time dependent)
- keypad maybe (time dependent)
LoRa modules:
we looked at RYLR896, 689, 498, 993. Visuwanath has STM32 modules with built in LoRa functionality, but these don't have enough storage. We'd need an SD card or something along those lines. I'm also not sure what the difference between LoRa modules listed above is. The STM32s with LoRa lack many pins and generally are not very robust, so I don't think we'll end up going with that. It seems as though the main distinction between differing LoRa modules is frequency band, Some, like the 896, 689, and 993 have much higher radio frequency (from 820 MHz to 900 MHz) while the 498 and 684 have a much lower frequency range (of 416 MHz -510 MHz). The 993 has an antenna, LoRaWan function, and AES128 data encryption. The 684 has none of these things. The only other module with AES 128 encryption is the 896, which also has a transmission range listed from 4 km to 15 km. None of the other transceiver modules have that listed which leads me to wonder why this is the case? I think 993 is our choice: It has good range, a dedicated chip option, and AES encryption. GPS is our biggest concern- we want to avoid antenna interference/clutter, so we need to make sure they aren't close on PCB & that the GPS antenna is facing upward. meeting:
- PSDR2 is software, needs to be more descriptive
- PSDR3 doesn't properly describe function
- PSDR4 needs to talk about matrix keypad /doesn't properly represent hardware
- need 4 prototypes
- PSDRs need more work, no stretch PSDRs present either
- Maybe a buzzer for message notifications?
After meeting, we settled on the RYLR993 chip, which has the features we need (see bottom of last pg) as well as the STM32L4R5VIT6 microcontroller, which has 2MB of flash, 640 KB RAM, 100 pins, LQFP solder size, and runs on ARM-Cortex M4 32 bit architecture with a 120 MHz clock. It's the lowest power micro of all our options, which is perfect for our application. It also has RTC and plenty of peripherals. We talked about direction for the near future, and our PCB design is the most important constraint for our size. Also CADDING button covers

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

Date: February 4th
Start Time: 5:30pm
Duration: 1.5 hours

After a rough week last week, I need to spend some time today catching up on content and some more time on housekeeping. Updating the links on our website to our actual documents , reading the Software Overview fully & understanding everything , and updating my picture on the website & my description. I created the Component Analysis doc & uploaded it to our shared drive. I plan for us to have an official discussion about specific component choices tomorrow in the lab. I also created the Mechanical Overview assignment and uploaded it to the shared drive. I plan to find a tutorial on SolidWorks online to get some understanding of the software, even though the assignment isn't due until the end of week 5. I'll also need to include a rough PCB layout sketch in this document. At the end of that week, our bill of materials is also due. I hunted on the internet for some SolidWorks tutorials, and it only took me a minute before I realized that the software has built-in tutorials that are reportedly very useful. There's also a video on YouTube titled "Getting Started: Lesson 1, Parts | SOLIDWORKS Built-In Tutorials" that I plan on following tomorrow before lab. SolidWorks is already installed on our lab computers, which is super convenient.

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

Note: This week has less work due to being sick from Sunday the 26th to Thursday the 30th, as well as having a volleyball tournament Saturday and Sunday after. My team was made aware of this.

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

Date: January 30th
Start Time: 7:30pm
Duration: 2 hours

I watched a YouTube video titled Learn Kicad 8 in 45 minutes- From idea to upload in one video and followed along with the tutorial. The video was extremely informative and did a good job walking through the program, from schematic building all the way to building a pcb and even links resources in the description for printing the physical pcbs.

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

Date: January 29th
Start Time: 3:30pm
Duration: 3 hours

Hunter and I wanted to build a workflow for our project to capture all design aspects. We started by making a DrawIO diagram but very quickly realized we were reiterating what Visuwanaath had written, so we switched gears and I ended up modifying our functional description. We were told that it needed to be more specific, so I started from scratch and ended up rewriting the entire thing. I added a physical description, battery and power information, including information about the buck converter we’re using to step our voltage down from 9 V to 3.3 V. I also described the interfacing more in depth, using the actual communication protocols such as UART, SPI, and I2C in each peripheral’s functionality. I also tried to encapsulate the functionality for different software aspects as best as I could, but that is something that hasn’t been finalized yet. Once I’d finished with the functional description, I worked on modifying the PSDRs for our device. I wanted to make them less ambiguous and more consistent with the functional description.

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

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

Date: January 24th
Start Time: 11:00am
Duration: 4 hours

My first task is looking at STM32 microcontrollers so we can find a good one to use. One important thing is memory, as we think we'll want to use close to 2 MB per device in non volatile memory. This is based on the following calculations: The beacon can store
• 20 buddy names (32B * 20 = 640B)
• 30 Waypoints (4B * 30)= 128B
• the past 100 text msgs, each w/300 char limit (for all 20 buddies) 350B * 100 * 20 = 688 KB
• compiled C code (expected under 1MB)
Based on this, we'll need roughly 2 MB of flash. Sophie did some research and figured that the STM32F4 series was a good option for us because of its ability to do floating point operations in real time, which is helpful for GPS coordinates. If we want this to have 2 MB flash, then the best option for us is the STM32F469/STM32F479 microcontroller line which have a 180 MHz CPU, 2056 KB flash, 384 KB RAM, dual-quad SPI and lots of other features (including RTC). Based on my findings this past Wednesday, I’m looking at the STM32L4 + series. There are plenty of options with 2 MB flash. These micros have more RAM (640KB), also have FPU and RTC. However, the biggest plus of these is the power efficiency, which is extremely high. Each has 5 different low power modes, with ultra low-power mode drawing 2nA without RTC and 150nA with RTCenabled. Based on our requirements for power efficiency, I wonder if this is a better option? The specific microcontroller model I looked at is the STM32L4S5VIT6, linked here: https://www.st.com/en/microcontrollers-microprocessors/stm32l4s5vi.html
A side note: this series also has AES encryption which could be useful if our LoRa modules don’t encode/decode the radio waves going in and out. That’s a question I have yet to answer, though.

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

Date: January 22nd
Start Time: 2:00pm
Duration: 3.5 hours

I continued to work on the functional specs. The whole group was present, so we talked about the benefits of using a full keyboard versus a smaller 4x3 matrix keypad. The benefit of a full keyboard is aesthetic and some efficiency since it's easier to type on, but we struggled to find one that would fit our small form factor. We also (for right now)feel that the extra speed when typing isn't necessarily worth how easy it is to find a waterproof matrix keypad, which is important to us for our use case.
We talked about graphical screens versus character screens, but we're going with a graphical screen because we need to display lots of arrows and possibly other artwork for compasses and directional indicators. I started looking into microcontrollers with a focus on low power draw, and It seems like the STM32 is a better line than ESP32, since we don't need Wifi support, and ESP32s tend to be less power efficient. The STM32L4 and 4+ series seem like good places to start. As team lead, I assigned sections of our functional specs document to group members. Each section is mostly completed with bullet points, but needs to be written more formally, which I plan on doing Friday.

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

Date: January 21st
Start Time: 5:30pm
Duration: 2 hours

We obtained two LoRa modules, an OLED screen, and a GPS module for testing with Arduinos. I began writing functional specification document with general bullets & ideas for functionality features that we want to include (listed below):
• portable: can fit in one hand
• lightweight: should be lighter or as light as iPhone
• want our device to meet IP standards for water/dust resistance.
• We’re going to set a goal for a dust rating of 6 and a water rating of 5, with 6 being a stretch.
• mechanical keypad for quality: we want it to feel nice to use (vs rubber, which would arguably be better for durability)
• an OLED screen: OLED is better for battery life than LCD, and also looks better
• a long battery life: 24thrs of "on"time (where it can send or receive msgs)
• want to keep assembly cost below $100, since all other competitors we've seen are at or above the $150 mark
• want a simple/easy to use UI
We will need to get a lot of prototypes if we plan on testing durability in any way, shape, or form. Sophie tested both LoRa modules on two arduinos. It seems like one of them isn’t working, but that wasn’t confirmed yet. Visuwanath tested the Sparkfun GPS module on arduino but it didn’t appear compatible, he will test on his ESP32 chip at home.

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

Date: January 21th
Start Time: 3:30pm
Duration: 50 min

I spent an hour before class with Sophie In lab loading the webserver onto our lab station computer, but when making edits to memberN.html files in VScode it doesn't load to actual webpage. We solved this by just copying “memberN” contents directly into team.html in its respective places.

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

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

Date: January 15th
Start Time: 3:30pm
Duration: 3 hours

What did I work on?
As a team, we relegated roles and followed the steps linked in the Week 1 assignment "Create Team Project Website" to set up our web server. I also filled out a description of my skills on the Final Project Proposal.
· How did I work on it?
I just followed the instructions for the various assignments linked in BrightSpace.
· What were the results? What did I learn?
We completed some housekeeping. I learned more about my teammates and their various skills from their descriptions.