Day 16

Topics

• Fingertip Program

Fingertip Program

   The first three questions were all involving counting the number of types of whirls, loops, and arches in a new print. While these were each given separatly and then integrated, I figured I could simply integrate them all together from the start. I thought the programming was screaming easier to do that way anyways.

   Then we were supposed to modify the program to output the categories as a percentage of fingers. I could initialize new variables but I think it would be easier to redefine the ones I already have. Instead of using integers for my counts, I will use doubles. 

   I also realized I could avoid using any new variables, at all, if I redefined the ones I already had. It worked just fine.

Day 17

Topics

• Tsunami prgramming
• Hardware and Software interrupts

Tsunami programming

   The first task being to count the number of events in the same year as the max height event meant adding a few variables to keep track of such data. 

   The simplest solution for finding the year, in my view, was to add to the same structure that finds the max height.

Then it was a matter of cycling through the data once it has all been attributed from the file.

   And printing what I had found.

   The second problem was decidedly more gruesome. I started that same by creating a few variables to be used.

   Then I used an if statement to find the grim event. 

   Then it was simple to print what I wanted with some style. 

   For the third problem I had to find the events with a minimum kills. I first defines the number I was going to have to use with my check. 

  Then I just cycled though the program at the end and printed the ones that met the minimum number. I did some formatting for it would look nice. I added the year because it seems like relevant information. 

   Finding The number of hits in July was straightforward as well. I feel I am getting much better at thinking of a program as a searchable thing instead of thinking in terms of directing each event.

   Then it was a matter of using a for loop to find those bad boys. 

   Finding the Peru hits was a little more tricky. After thinking about strings I realized they are an array of individual characters for I for a nested for loop to do it. 

   I also added the or part so I could find the case differences part.

Hardward and software interrupts

   This is a way I can control the speed of something even before I could get interrupt going.

The hardware interrupts was a little more interesting. The button setup also meant we didn't have to debounce the button like we would normally have to.

Day 18

Music Machine

   We can take charge of the time clock and blink lights with the l

Setting up the circuit wasn't too difficult. I used the same manual button debounce we had put together the day before.

   I changed the multiplier to 2 so that's why it jumps be even numbers each time I git the button . 

Day 12

Topics

• Lecture Notes
• Eye Squared See
• Gradient Programming

Lecture Notes

Eye Squared See

   The setup for this program was the same the I2C device with a few lines to take care of the speaker. One part that did need to change was the tone, who's frequence had to scale the F values in order to tell the difference from one degree to another. 

Gradient Programming

   I ended up seperating the two functions of finding peaks and valleys. I am sure there is a more effectient way to do this all with nested for loops but I will have to spend a little more time with this to work of the logic of that. I also decided to leave all the parts on one page and comment out the funtionallity while sperating the parts by commenting extensivly. This way I have an entire history of the iterations to compare easily.

   The lowest value gave me some pause. I thought for a little while and realized that I could set the lowest point as staring as the heighest point instead because I couldn't start with 0 and I didn't want to assume a maximum height. This way I can treat it as a general 7 by 7 array.

   I calculated the position from the bottom by using the distance formula with my x-naught/y-naught positions being the array elements of [6][0]

   These are the results at each stage of my programming. 

Day 21

Topics

• EEProm
• MPU9255

EEprom

    I setup the component as was outlined in the lab. 

    I ran the first program after making the changes in code to account for a the changes in the library over time. 

   I am not entirely certain what this was actually doing.  OOOOOO; now I see. It's writing random numbers to the EEprom at the specific address and then telling me what the address has.  I loaded the next part of the lab but didn't get the same thing I got during class. I am trying to remember what I had to do during class to fix it. 

   I must have been mistaken. As I reviewed the code, it appears "DATA READ" is the only thing sent to the serial monitor. I added some Serialprints to satisfy my mind, as to the efficacy of the loops. Not a problem.

MPU9255

   I could attempt lying (conduct unbefitting a gentleman) but that seems needless. We were instructed to break up these labs between the group members. I worked on logging data and getting the sweeper working while Ed go this sensor to work. I now shamelessly report on what sense I can make of it, post hoc. Clearly this sensor needed some header files, I suppose another library would also work.  There also an object made from the MPU9255 class.

   Then we have some class specific function that are initialize the sensors on the board. I can see at the end there is a reference between the millis() count and an myIMU.count. possibly has it's own crystal. I wonder what the the difference between the two clocks gives? 

    Wait! the line before! I think it's grabbing the millis time in the timerupdata and then using that to mark change. Then, the line after the counter one has a change in time being half a second.  I could change that number if i wanted to increase collection rate, I bet. Lets check.

   That worked! The next part is a straightforward printing of data. Adapting this or the project shouldn't be difficult. 

Day 20

Topic

• Setting time
• Logging Time
• Logging Time vs Sensor Data

Setting Time

   The first step was to simply the time on the real time clock. I was able to do this without any hitch. 

Logging Time

   Then I had to log the time as I changed. Again, an easy task. 

Logging Time vs Sensor Data

   Then we are to connect a sweeper and use that to collect data on who is entering the room. The setup was nice. We could actually arrange this one without a breadboard which brought a new concept. We can use any pin as a ground. I have to remember that for the future. Define it was a ground and then write it now. 

 

   I am still trying to format the serial monitor. Having all the data on one line is hard to follow. 

There we go. 

Day 19

Topics

• SD Card Reader
• Logging Temp Data
• Collection Rate with Hardware Debounce

SD Card Reader

 I setup my SD card reader on the board. I have confidence in this part completely.

   Then I wrote a simple program to test opening a file and writing to the card. I looked up the SD library and  tried working with the commands rather than to use the file you had given us. I prefer working as c lose to  first principles as I can. Helps me to gain a more intuitive understanding of the material. 

   What I expect to see when I run this program is the phrase "Test Poops 2!" in the serial monitor. Although I was bit unsure about reading from the SD card in this way, I don't know why I got what I did.

   For some reason I got a -1 in the serial monitor. I will have to try to rework the read function I believe. Let me check the card without the arduino and see what I get. 

   Hmm....it was a complete failure, it would appear. I made a little test bit. This is good news because I am getting closer to finding my problem. My pin isn't being initialized. 

   I couldn't get mine to work. Switching over to the program you made and I had the same problem. 

   After much frustration, I turns out that using 32fat can mess with this particular library. I got a smaller SD card and used 16 fat. I was able to create the log after this.

   

Logging Temp Data

   For the lab I was supposed to connect my temp sensor and record the data I got. The stipulation was that I needed data collection for a minute without using delays. To do this I used the millis command and a variable to compare the passage of time to. 

   The compare didn't always work and I'm not exactly sure why. I was thinking there might be something wrong with the place I am setting the currentTime variable at the end. 

   After all the stuff in the loop I have this. If I follow correctly, as my while loop first encounters millis being a 1000 beyond zero, the loops runs. After which, the current time becomes the millis time and then the function doesn't run until millis is again 1000 beyond the current time. Effectively creating a collection rate of one per second. The entire structure stops when millis reaches a minute. For some reason, I don't get this to work that way. I get some recording but not the full 60 samples I expect. 

   I continue to have the problem of data collection not doing what I think i should do. I tried to force a limit on the data collection and something is still haywire.  There shouldn't be any way for more that 60 data points but I am getting this endless stream. EHHHHH! I WILL HAVE TO TRY SOMETHING NEW. I THINK THIS IS SOMETHING TO WITH THE WHILE WIREAVVAILIBLE PART OF THE PROGRAM. 

   I got rid of all the complicated things in my loop that might be causing problems and replaced it with a simple serial print. What i got was the same problem as when I had the full problem (twenty or so printings then the end). What was interesting was that the numbers happened much more quickly than then I had the complicated which leads me to believe that the nondelay delay wasn't actually doing anthing. Rather, I was pushing the SD card as fast as it could go. 

    My debug was not effective. I declared "int I = 0;" outside of the while and then I got this...

   I now know that my while loop idea of how to do the delay will work but I still don't get what I want when I have the "complicated stuff". My problem has to be in the "COMPLICATED STUFF"

I added the brackets around the else statement. I ran it and got the right number but tried running it again before documenting it. 

   The second test gave me this. I am beginning to feel that something in the hardware starts to fail and my current knowledge is not sophisticated enough to solve that type of problem. 

   I reran the program a few times and got different numbers until I eventually got what I had aim at. Since I had changed no code I believe the evidence points to a hardware fault. I consider this part done.  

Collection Rate with Hardware Debounce

   I setup a second button in the same way I had done previously. 

   I setup the button to pins 2 and 3 to be used as interrupts. I also wrote programs that allowed me to control the collection rate. Before I started I made sure the inverter worked. I do indeed get the inverted values I want and I can see that a raising voltage does signify a new button press. 

   The program I wrote in order to control the collection rate was simple. I added an extra check to the decreasing rate in order to limit the max rate to once ever .5 seconds.  I can also see that the functions work by the serialprints I have inside the functions. I had to do some debugging when I first started because I kept getting this problem with the way my attach parts were working. I thought it was the rising part. I found out I could use 0 and 1 to refer to the pins 2 and 3. It turned out the way I was calling my functions in the attach was a problem. I had been keeping the () that we normally use. Removing those cleared it up. There was still a problem with my down function.

   I have no idea why my down function doesn't work.

   I thought, "Perhaps, the pins are the problem?" Swapping the two pins had no effect on my data. Calling down still does nothing while up works. Both functions have the same structure, an exceedingly simple one. Must be something else.

   This is was odd. I couldn't see any problem with the function itself, so I made down a copy of up and then tried running the program. still it didn't work. There is something going on here. I have to find this problem. 

   Inside the code, I switched the pins to watch for the interrupt and this completely broke it. I'll try to call the pins by their variable names.

   It worked! That is strange. If it was the variable name problem then why did my up function work but not my down function. I think I might be that up is higher up in the code and that means it has some strange priority to work when I use 0 and 1 to watch the pins. I'll test quickly and confirm or reject this hypothesis. 

   Now I am really lost! IT WORKED WHEN IT HADN'T BEEN DOING ANYTHING AT ALL FOR AN HOUR! Why this sudden change I have no idea.