RaspberryPi-2024

Jan 22, 2024
to read values from ADXL372 accelerometer: 
sudo pip3 install spidev
went into raspberry PI configuration and turned on spidev by running "python3 Accelerometer/ADXL372/adxl372_test.py"
in folder sensor-tests

Jan 31, 2024
trying to use spidev library for python
sudo pip3 install adafruit-circuitpython-adxl37x 
sudo apt-get update
Decided to switch to c since python won't be fast enough to read at the frequency we need.
Had ChatGPT generate a script to start reading values. The script is running but not recieving values. Will look more into
how the script is working and what registers it is using. 

Feb 5
The python script is receiving (mostly correct) values. Anthony ran Matlab tests to plot the data and found that we have
perfect harmonics in the data. Tried running the c code and didn't get any values. Changed the library to 
https://github.com/LdB-ECM/linux_device_access/blob/master/spi.c (stored in accessLibs) and rewrote the code to use the 
library.

Feb 7
Fixed a bunch of compilation errors in the code written on Feb 5. Then got a seg fault, most likely becuase the library wasn't
being compiled with the c code. Used command "g++ -pthread -shared adxl372_withSPIlib.c accessLibs/spi.c" to compile c code
and library in the same folder

Feb 9, 2024
Worked on precompiling the library so we don't have to recompile it each time. Made a .a file following 
https://www.cs.dartmouth.edu/~campbell/cs50/buildlib.html and moved it into ADXL372. Will try to find a way to move it back to
accessLibs without getting errors. Ran command "g++ -pthread adxl372_withSPIlib.c" to compile c code. 
Code ran but the values weren't correct. x was always 160 and y and z 0, and the status register was empty. We switched the order
that x and y were getting read in (in case one reading was messing up others) but recieved the same values. Tried all 4 spi modes
and they returned different values for x but nothing else changed. Settled on mode 2 as detailed in the data sheet. 

Feb 10
Worked on reading values from the ADXL1001. 
Setup with DAQ:  (ADXL1001 -> DAQ)
  Vou -> C0
  GND -> AGND
  Vdd -> 5V
Downloaded library from https://mccdaq.github.io/daqhats/install.html#creating-a-c-program but made the library a submodule in
Git. Tried running the sample file (single_value_read) which gave values!

Feb 14
Recorded data from ADXL1001 to analyze
ADXL372 doesn't read data at all when connected to the DaqHat
Ran C code adxl372_withSPIlib.c and got some y values
  status reg was 00000010, so we are in buffer mode
  must set FIFO reg (0x3A) to 0b00 to turn off buffer mode
ran into library problems again :(

Feb 21
Worked on ADXL372
Attempted to turn on the buffer mode, was unsuccessful in SPI
Tried using i2c but was also unsuccessful
Most likely using ADXL1001 now

Feb 25
Started wrapper for daqHat based off of continuous_scan.py in the examples folder
Started profiling batteries
  Attempted to use current measurement circuit (like Ashcroft G2) but resistors couldn't handle load
  Using HiTec RDX1 in discharge mode with charge master software to get curves
    takes about 50 minutes per battery
    did one battery today


Feb 29
Continued working on wrapper
Profiled the rest of the batteries - they are good!

Mar 4
Worked on daqhat wrapper (csv formatting, closing files correctly)

Mar 18
Writes to file in csv format but timing is off
  Need to make code more efficient
Did math for conversion values of voltage to acceleration
Started work on filters




Mar 24
Timing stuff:
  whole buffer is being read, so either we're losing data or it makes sure that when it 
  finishes its call that EVERTYHING is in buffer
time once we're at the start point is getting calculated correctly - including jumpback

  

TODO
MCC128 code for python
make wrapper for it. should be instantiable by main script, call function to get buffer from certain channel
  parameters: channel
  return: buffer in CSV form (no headers) 
communicate w/ SPI, or I2C but SPI preferred

should be SPI code in python for daq hat

When the RBF wire is connected and the reset button is in the off position, or if the system was just powered and the reset
button was flipped to the out position, if the reset button is then pushed back in the in position within 2-3 seconds, there's 
enough trickle current to re-engage the system without the RBF wires connected.
Trickle current persists for around 2 seconds. Need to wait at least three seconds for the system to not be re-engaged without
the RBF wires connected when the reset button is pushed.

April 20
Tests to complete today:
 - S.1.SYS.1
 - 15 minutes of vibration
 - 

MCC connection error

4 options:
1. continuous open/closing of GPIO 9,10,11
  pros: no harware changes
  cons: difficulty writing and testing code, ~50s time delay each time we switch pin ownership
2. new PCB
  pros: no software changes (pretty much)
  cons: more parts needed to buy (RTC out of stock), more solder time after May 26
3. Fix daqhat library
  pros: no hardware changes, no main code change
  cons: fork library and change the pins it uses from 9,10,11 over SPI
    might be firmware on PI that makes it so you have to use 9,10,11
    hardcoding connection
4. Directly solder valves 1-3 to new pins
    take each pin connected to the resistors and do a jump wire over to other GPIO pins
  pros: no rewriting code, fastest
  cons: dodgy at best, prone to disconnections. Connection strength depends entirely on soldering 
    metal strength