The past two weeks saw some fantastic development! Lucas etched and manufactured our weight tag pcb’s. MeeDm worked on the Hub’s data analysis scripts. Tarush built out the Web App UI. Throughout Thanksgiving break, the team continued to work diligently. Thanks to Tarush staying on campus, we were able to continue to conduct system tests remotely.
After coming back from break, the team wrapped up the final presentation slide deck, and Tarush presented it on Wednesday. Way to go Tarush!
To wrap up the week, the team continued work on system integration. Specifically, Lucas and MeeDm worked to fix some final issues with the Hub not being able to find characteristic values sent by the Tags, and MeeDm and Tarush implemented further Hub controls into the Web App. We also got a fancy new enclosure designed and built for our weight tags.
As we enter the final week, we’re quite happy with the project. Still, there’s a lot left to be done. Our goals are to implement RFID sensing as well as polish the full project pipeline.
The past two weeks saw major development milestones reached and passed. First and foremost, I finally got the Weight Tag pcb etched and populated!
The tag runs our firmware and is powered from a single CR2032 coin cell battery.
I went back home to New Jersey for Thanksgiving but brought along plenty to work on…it got a bit messy:
While on break, I primarily worked on the RFID firmware, the Weight Tag hardware (populating a second board), and conducting live tests for our final presentation slides.
After coming back from break, I helped wrap up the final report. Specifically, I wrote the Solution Approach (slide 2), Hardware (slide 3), Live Testing (slide 7), Results (slides 8 and 9), Design Trade-Offs (Slide 10), and Lessons Learned (Slide 11). I also helped on the Project Management (slide 12) and Public Demo (slide 6).
After our final presentation, I took some time to design the enclosure for our weight tag from scratch and printed it out (bottom piece is printed but currently locked in Roboclub :P):
The enclosure’s top features a lip to snuggly secure the food bowl and a skirt to push any water or kibble that falls out of the bowl away from the electronics housed underneath. The bottom plate has mounting holes for our custom weight tag offset from the base to add further protection against water damage.
To wrap up the week, I debugged and fixed some issues with the characteristic values from the tags not being seen by the RPI over BLE.
With the weight tag just about fully finished, my goals for next week are to wrap up RFID and prepare for the final demo. Time is tight, but at this point I am confident we’ll have a solid project to show off.
This week saw some major development towards system integration. Primarily, Tag firmware was finally developed to report load cell values over BLE to the Hub RPI. The web app also saw major updates in the form of better graphs and value display. RPI Hub software was developed to better distinguish “danger levels” of eating habit disparities. Next week, we expect to have custom hardware Tags reporting weight values to our RPI hub. Next steps are to integrate RFID sensing and better data displays.
This week finally saw the completion of the full Tag to Hub pipeline. I mainly worked on the firmware required to make the DA14531 board report load cell values as a characteristic (a value sent through the bluetooth protocol to the rpi hub). I also developed the load cell weigh sensing to save values only if they surpassed a preset threshold. Next steps are to run a hardware timer that will report timestamps of when new weight values are added to the array of values – these represent individual “eating events” which the system will count and check for consistency.
Finally, I re-designed our pcb’s based around the now-available DA14531 Bluetooth module ( basically a small package consisting of the DA14531 chip, a 1 MB SPI Flash, and an antenna with a pre-made CLC filter). The schematics are fully finished and the layout is “near-done” (as in: I expected to etch it out today but it’ll have to wait until tomorrow). Making PCB’s in-house means they have to be CNC milled – i.e. they can only be single-layer boards. Not having multiple layer to route through definitely adds to the challenge of creating a complex, multi-component design, but I’m managing it.
I expect to have a functional pcb in my hands tomorrow (Sunday).
This week I mainly worked on getting the demo fully ready and then continuing to build and polish from there. I was responsible for the hardware portion of our demo, which was a bluetooth enabled weight sensor. The device featured a load cell housed in my custom enclosure connected to an HX711 breakout board, which in turn communicated with our DA14531 USB Dev Board to read out weight values. Our demo was essentially a not-yet-fully-integrated version of our weight sensor tag.
The basic functionality of the demo involved a custom driver for the HX711, which would begin pulsing a system timer upon bluetooth connection being established. The driver waits for the “value ready” signal from the HX711 and then pulses out 25 rising clock edges. In turn the HX711’s shift register shifts out a 24 bit weight value which is then interpreted by the dev board. If the value is above a preset threshold, the dev board lights an indicator led. I primarily included the indication led to demonstrate threshold values because the device’s UART does not seem to be functional. Because it cannot therefore display values it receives in real time, I used the led as an alternative.
On top of firmware development, this week also saw big strides on the hardware front. The PCB’s are almost fully finished, and I have now designed, etched, populated, and successfully tested versions 1 and 2 of our custom load cell breakout.
The breakout board has several benefits over off-the-shelf breakouts, primarily in terms of flexibility. I included a number of custom designed solder bridge pads that can be connected or disconnected to select between a number of features the HX711 chip offers. The most important of these is the RATE selection line – grounding it versus tying it to VCC selects between 10 and 80 Hz data rate. Leaving both rates as an option allows for testing which pulls less power and thus gives us more room for customization along the lines of power savings vs. speed as we polish the sensor tag design.
I also worked on getting the PCB’s finished and ordered. I finalized the parts list and finally had the order placed. Unfortunately, I encountered a silly mistake late in the design process – we needed one more GPIO than the DA14531 chip had available! Essentially, the problem came from a late decision to have the RFID sensor tag run an accelerometer which would sense vibrations caused by a cat accessing the food bowl. Upon detection, the sensor tag would turn on the RFID reader to scan the cat’s ID chip. This design decision centered on the key point that the accelerometer would be orders of magnitude less power hungry than the RFID reader (as little as 10µA versus upwards of 200mA). In order to run the accelerometer in conjunction with our RFID reader, I figured we’d only need two GPIO lines to support the I2C protocol, but it turned out that the accelerometer also had a mandatory interrupt line in order to function.
I am now spec’ing out an I2C GPIO expander to allow for the additional I/O. Once that is done, I’ll have the PCB’s fully ready and ordered.
This week, the team worked hard to get through the first steps of seriously integrating the different components of the project into a cohesive data pipeline.
MeeDm wrote scripts for the RPI Hub to connect to the BLE Tags and read in service and characteristic data from them. Tarush worked on getting the web app reading the json file MeeDm’s code will fill with the sensor tag data as it streams in. Lucas got the tag dev kit advertising out and connecting to the hub via BLE.
With information actively being read by the hub through a bluetooth connection from the sensor tags and being piped to a file the webapp reads, we finally have an actual data pipeline! This week, we’ll build on top of this basic skeleton of a system and aim to have weight data from a load cell actively being displayed on the webapp in the form of a live graph. This will involve getting weight tag firmware reading values from our custom HX711 breakout board, hub software organizing those values into a json file, and the webapp reading from the file and converting the information into a live-updated graph.
This week I focused on a combination of getting firmware rolling, wrapping up PCB part sourcing, schematics, and layouts, and working with the team on integrating the full communication pipeline from BLE tag to hub to web app.
Last week, I focused way too much on setting up the ble tag firmware development environment and finishing the PCB’s at the cost of working more on the design report – I wrote the abstract did a little bit of editing, but little more than that. Luckily, several of the system diagrams and notes on hardware tradeoffs I made before came in handy in the report, but I definitely should have actively worked on it more.
What that time went into was firmware development, hardware development, and parts sourcing. Firstly, I jumped through several painful hoops getting the Keil development environment, Dialog SDK, and SmartSnippets Toolbox all working on my Mac (after a lot of time spent on stuff not working properly, I bit the bullet, bought Parallel, and set it up on a Windows VM). The result is that I can actively develop firmware for the USB dev kit as well as our future custom tags. With the LED blinking, I have the hello world I wanted to get. The tags can actively be run from a debug build and I confirmed that permanently flashing them also works.
On the PCB front, things are not as far along as I’d hoped, but still steadily moving along. The parts are all selected for the weight and rfid sensor portions, and I have completed the design of breakouts for the main chips. This just leaves the primary tag pcb left, with just a little work left to be done on getting the SPI Flash memory chip and SWD JTag done.
Finally, I used the PCB mill at my job’s office to get the prototype breakout boards cut out:
It’s great to actually have these things physically in my hands!
I have been actively chugging through datasheets for the DA14531 ble/mcu, the spi flash, the accelerometer, the rfid chip, and the hx711 adc/amplifier. Next week, I’ll aim to have the ble usb dev kit reading values from the HX711 (connected to the load cell). In other words, next week will see the weight sensing up and running and (hopefully) displaying live data in the web app.
This week I prepped mostly for the presentation. After working on the slides I practiced many times on Tuesday to ensure I was ready for the presentation.
I also worked on implementing the bluepy module in a python script. I’m waiting for the Bluetooth module to be in the lab. I’ve also done research on what procedure I would use to send a request to the tags and what format to read them in with. I’ve found some sources online that have similar iot sensors and hubs, and I’ve started modeling my code off of those.
I’ve also set up the raspberry pi 4 in the lab. I have yet to set up exactly the bluepy on this specific pi.
I’m a little behind this week, but I hope that next week I’ll be able to work more in depth with the demo tags and get some more substantial work done. I was a little preoccupied with the presentation, but next week I hope to get more done in the progress of the project.
This week mainly saw me helping the team write the design report and develop the tag pcb schematics and layouts. With the prototype schematics just about done, I am now moving on to finishing the layouts and getting the pcb’s and parts ordered. The delays to the hardware schedule currently present a pretty large risk to the project, so I am working hard to close the gap.
I also worked on getting our prototypical RFID tag antenna built using the custom 3D printed ring.
I will primarily be working on the design report with MeeDm and Tarush throughout the first half of this week while the second half will see me getting the pcb’s ordered. If there is time, I will also be working on getting Shelley operational.
Finally, the DA14531 development boards I ordered have arrived meaning that I can get firmware development properly underway. This week I will aim to at least get a “hello world” program successfully flashed to the dev board.
This week, MeeDm presented our design review presentation. Way to go MeeDm!
The team spent most of the week working on the design report while each member also made progress in their own area. Lucas developed the schematics for the prototypical bluetooth tags, Tarush finalized the development stack for the web app and got the RPI 4 hub set up with Django, and MeeDm conducted further research on what constitutes irregular cat eating habits – to that end, she reached out to her vet but has not yet heard back.
With the demo tag hardware built, MeeDm and Tarush will begin working on integrating the full tag-to-hub pipeline, while Lucas will primarily work on getting the tag pcb layouts finished and ordered. We have also finally received our shipment of BLE module development boards, so Lucas will be able to start tag firmware development in earnest.
The primary, current project risks still mainly have to do with hardware development timing as well as parts availability and logistics. Another risk involves spending too much time on course logistics and material such as the very pressing design report rather than actual development.
