cmonr-ssd447-blog

[cmonr-ssd447-blog]

The code on the spy bear

[cmonr-ssd447-blog]

Final project poster

A link to my completed poster. If there is no problems from my professor, this is what I will submit as a final draft.

https://drive.google.com/open?id=0By-bsqwiA81LNDFsX2hzWHZJWlU

[cmonr-ssd447-blog]

The touch sensor itself (from behind). The 1010 chip is at the bottom, right in the center. There’s an LED built into it at the top to indicate a touch, and a few resistors scattered around it (i think). There’s also a pin connector that can be used to connect the sensor to another external touch sensor... though I don’t intend to use that.

[cmonr-ssd447-blog]

The breakout schematic of the QT1010

[cmonr-ssd447-blog]

The configuration of the AT42QT1010 chip, which is the driving logic controller behind the capacitive touch sensor. When I create my poster, I will be going over what each of these pins is for, and how they relate to the project.

[cmonr-ssd447-blog]

Final Project plan

My final project will be combining the raspberry pi with a pi camera, a capacitive touch sensor, and a teddy bear, to create an interesting piece for our open house. Specifically, the pi, camera, and sensor will be placed into the bear- with the sensor acting as an interface- when someone touches it (i.e. picks up the bear), the camera will begin to record video- which will then be uploaded to a twitter account. Putting the bear down (and removing your finger/hand from the capacitive sensor) will stop the video and make the actual upload.

I plan to focus mostly on the capacitive sensor than anything else, however, if time allows I will be able to include some in depth work on the camera as well. I also hope to include the ability to switch between video or a single snapshot if I can... but I may scrap that if I run out of time. We will have to see for that part.

The supplies I will be using:

https://www.adafruit.com/product/1374

https://www.adafruit.com/product/3100

https://swag.raspberrypi.org/products/babbage-bear

I found the basic tutorial for the setup here: https://www.raspberrypi.org/blog/make-a-tweeting-babbage/

Please note-I will be focusing more on the touch sensor (and possibly camera!) and how it works electronically, more than the code- since the code is very minor in this project. However, I do plan to explain all of the code with comments so that i can post an image of it and show what each line of code is doing (and how it is using all of its libraries to take the video, and then upload to the bear’s twitter account).

The final poster will have detail on the touch sensor, the project itself- i.e how it works and what it does- as well as a diagram on the bear and the pi within it, the code, and if I can fit it, some technical information on the camera as well. I will go over the electronic components of the sensor, with focus on the chip, and how the chip works. I will also show the connections from the chip to the pi, and how the pi reads those values from the chip (i.e switches going from low to high and back). 

Pictures of diagrams that I have located from the datasheets will be in the next few posts. I will also be updating this tumblr with more info and pictures as I find them, do research, and get code done.

[cmonr-ssd447-blog]

Screenshots of my browsing the pi in accordance with the questions. The first screenshot covers questions 1-6, the second screenshot is me running a ‘less’ command on a file, for question 8, and the last screenshot covers questions 9-12, which involve using VNC to get into the pi from windows.

To specifically answer questions- 

for #5, the file bit size appears to be 420.

for #6, the file appears to be an ASCII text executable

for #15, ‘grep’ is a search function in linux. The statement here, ‘cat koch* | grep range’, will look through all files that begin with the letters ‘koch’ (i.e the snowflakes) then return any lines of code in them that contain the word ‘range’.

[cmonr-ssd447-blog]

Midterm part 2

Arrgh! I did my calculations for this and thought it would work, but something was amiss when I uploaded it and tried to tap it. I would love to go over this in class to see where I went wrong- but hopefully my calculations at least were close. Additionally, I couldn’t get cool term to run at all on either of the computers I have... so this is really my best shot.

First, here’s the post to the code: https://developer.mbed.org/users/CKMonroe/code/CKM_midterm_pt2/

but more importantly, here are my calculations for how I got my answers:

==============================================================

Set to double tap detection

-This means reconfiguring PULSE_CFG to use the double tap value for our axis.

Again, our PULSE_CFG register looks like this:

DPA ELE ZD ZS YD YS XD XS

we want to enable the ZD bit this time in order to switch to double tap detection. This means that our axis data changes from bit 4 to bit 5, which is 00100000 in binary. Converted to hex, and placed in the new code, we get:

uint8_t axisData = 0x20;

at the beginning of main(), to replace the current declaration

==============================================================

Set to use INT2 interrupt

-using the INT2 interrupt means that we need to set our CTRL_REG_4(0x2D) and CTRL_REG_5 (0x2E) data to use INT2 instead of INT1. As per the documentation, this means we still need to set our device here to allow for interrupts- so we need to set bit 3 with 0x08 once again. That part remains unchanged.

However, we now need to set the controller to route to INT2, which means clearing bit 3 in CTRL_REG_5.

I read online that in order to clear a bit, you have to use bitwise-AND to compare it with a value that is 1 everywhere except the bit in question. That should clear the bit but leave everything else the same.

if CTRL_REG_5, bit 3 is our target, we need to compare it to 11110111 as a mask. That value is 0xF7 in hex.

Therefore, we use the value of (0x2E & 0xF7) with a regwrite statement to clear the bit... I think this means we can call the setRegisterInStandBy function. I don't think the device needs to be in standby for this, but the function already has the ability to write to a register.

setRegisterInStandby(CTRL_REG_5, (CTRL_REG_5 | 0xF7) ) would do the trick, but since our setResgisterInStandby function will do this for us, I think we can just change our code as such:

#define SET_INT_LINE 0x2E & 0xF7

==============================================================

Set time of transient to 35ms

-to set the time of the transient to 35ms, we need to look back at the documentation to see what our time step is for 400Hz with no LPF. That number is 0.625 once again. This means that we take 35ms/0.625, giving us a result of 56...in hex, that number is 0x38, which will need to be loaded into our REG_PULSE_TMLT:

#define REG_PULSE_TMLT 0x38

==============================================================Set magnitude of pulses to 2.5 g (or close as possible).

-okay, so this will require some more math and changing of a threshold value. since we are still using 0.63g per count, then we divide 2.5/0.063, for an answer of 39.68, which i will round up to 40 counts. Converting it to hex means that we need to change our new pulse threshold to 0x28.

#define SET_THZ 0x28

==============================================================

Set data rate to 400 Hz.

-this will require us setting our CTRL_REG_1 to 400 hz. It will also require us to put the device in standby first (since we have to do that in order to modify CTRL_REG_1)

The documentation tells us that for 400 Hz, we need to set... DR2=0 DR1=0 DR0=1 which correspond to bit5  bit4  bit3 respectively.

if the default value here is 000 for all three bits, then I think it would be safe to only worry about bit 3... so we can use a simple mask for it.

To change bit 3 to 1, while leaving Bit5 and Bit4 at 0, we should use a bitwise-OR operator on the current data in CTRL_REG_1, with values that are zero everywhere except in the bit that we want (bit3). This would be... 00001000, which translates into 0x08 in hex.

So, we would need to call 'setRegisterInStandby', and pass REG_CTRL_REG_1, and (CTRL_REG_1 | 0x08) to it, which would look like:

setRegisterInStandby(REG_CTRL_REG_1, (CTRL_REG_1 | 0x08) );

[cmonr-ssd447-blog]

My Notes for how I got my answers. If I have gotten any of these incorrect, you will at least be able to see my train of thought!

1. A single tap event on the Z-axis only

Single tap means that our PULSE_CFG(0x21) needs to look like: 01010101 in order to read a single tap on all of the axises. in the code, the PULSE_CFG is modified on line 122, with 'regData' being written to it.

If RegWrite(0x21,0x55) will enable the PULSE_CFG for single tapping on all axises, then perhaps a regWrite with just the Z variables will set it to a z-axis only event? Looking over the PULSE_CFG register, I notice that the tap enabling is named either ZD/YD/XD-something, or ZS/YS/XS something. the singles all have the S value as 1, while the doubles all have the D value as one... if we are going only for the Z axis, with single tap value, then I think we just want Bit 4 of the PULSE_CFG register (ZS). bit 4 would be 00010000, or 0x10 in hexidecimal. That has got to be our axis data.

But then what does 'latch' mean? Looking it up in the documentation says that its the ELE value that controls the tap event in PULSE_CFG. In that case, my money goes to the latch data being the hex value for the ELE bit, which is bit 6. The binary value for the latch would be 01000000, or 0x40. I'm going to guess that 0x40 is therefore the LATCH_DATA in the code.

2. The interrupt line to use is INT1 setting up pulse interrupt to INT1 pin registry address(address_index below) is REG_CTRL_4(0x2D) or REG_CTRL_5(Ox2E).

It looks like SET_INTERRUPT goes to REG_CTRL_4 and SET_INT_LINE goes to REG_CTRL_5.

According to all of the examples i've seen, since we are using INT1 as our interrupt line, we enable it in CTRL_REG4, and also route the interrupt to CTRL_REG_5, then SET_INTERRUPT and SET_INT_LINE should be the same... whatever they are.

AN4071.pdf tells us in 6.5 that to set bit 5(0x20 is hex for bit 5) in CTRL_REG4(0x2D) we use RegWrite(0x2D,0x20) to change pin 5. It also says that the CTRL_REG_4 is what enables the interrupt, while CTRL_REG_5 routes it. This seems in line with what I've read in the examples previously.

On the example that was given to students in 8.2.4 (which is from AN4072.pdf), the documentation says that to set up the system to route to a hardware interrupt pin (which is what we want- to route it to PTC5, which is INT1), we need to enable the interrupt in the REG_CTRL_4(0x2D). The documentation here says that the first register, CTRL_REG_4, just enables the rerouting (again, this makes sense) while the second register, CTRL_REG_5, actually specifies which interrupt pin that gets selected (again, we want INT1). This makes sense given that the variable for it is called 'SET_INT_LINE'. The documentation tells us that to enable the interrupt in 0x2D, we set it to 0x08- that makes sense since that's the hex code location for bit 3., and according to the documentation, setting bit 3 in CTRL_REG_5 to 1 (set) routes it to INT1, while clearing it routes it to INT2. Therefore our SET_INTERRUPT and SET_INT_LINE should both be 0x08. 3. Data rate = 800Hz

4. The maximum g sensitivity is 4g

5. Set threshold of pulse to be 2g I am guessing that this has to do with our THSZ value, or SET_THZ, since that appears to be short for 'Threshold Z'.

Example 6.1 in AN4072 shows that each step for the threshold is .063g per count. It uses 42 counts (.063*42) to reach a threshold of 2.65. If we are going for a threshold of 2, then we need to use the equation 2.00g/0.063g, which gives us a result of 31.75 (roughly) counts. I will round this to 32 counts, and convert it to hex, giving us an answer of 0x20. That's the value that needs to be set into 0x25 (our REG_PULSE_THSZ, or register pulse threshold for Z) value. Thus,our SET_THZ is 0x20.

6. Set the length of the pulse to be 15 ms

In the code, SET_THZ gets set into REG_PULSE_THSZ(0x25), and SET_TMLT gets set into REG_PULSE_TMLT(0x26). According to the documentation, the value that gets written to 0x26 is the count, which is gained by dividing the latency time by the time step. We want 15ms to be set into the 0x26 registry, so we need to figure out the Hz for the math for a latency of 15ms.

NOTE: according to 4.3 in AN4072.pdf, the LPF(low pass filter) changes the time step. If the LPF is enabled, the time step doubles... so 400Hz (which is normally 2.5ms) would become 5ms insead.

Pulse_LPF_EN=1 (pulse LPF enabled) 800Hz = 1.25 time step Pulse LPF_EN=0 (pulse LPF disabled) 800Hz = 0.625 time step

I am going to assume that the pulse_LPF IS NOT enabled, because Stan has pointed us to table 51 (which has LPF_EN set to 0). Thus, 800Hz has a 0.625 time step, and we want a limit (our PULSE_TMLT value) to be 15 ms. It looks like the equation would therefore be 15 ms / .625 , which equals 24. That would be 0x18 in hex value for SET_TMLT.

NOTE: lets do the math for LPF_EN=1 out of curiosity (and in case LPF is enabled) If that's the case, with a rate of 800Hz, and a time step of 1.25ms, we use this calculation: 15 ms / 1.25 ms = our count value. This comes out to 12. Therefore, the value we would need to send to the REG_PULSE_TMLT would be 0x0C.

[cmonr-ssd447-blog]

A screenshot of my KL board in 8g mode. This was after a good, hard shake.

I have the code posted here:

https://developer.mbed.org/users/CKMonroe/code/CKM_HW_8_1/

along with comments in the class to prove that I understand what is going on.

[cmonr-ssd447-blog]

Homework 5.1

My question regarding the KL accelerometer involves something i keep reading about in the instructions but don’t understand: What are ‘interrupts’ on this piece of hardware? I keep seeing things about interrupt pins and registers, but I couldn’t find anything that explains them in detail.

[cmonr-ssd447-blog]

Solution for HW 4.2.1 - calculating SAR output for a 4 bit register with Vmax = 3.3v and Vin = 1.45v. Also shown here is the program output for the ADC program written in python.

[cmonr-ssd447-blog]

My answer for HW 4.1.

Interestingly enough, the loading resistor on the new light sensor is stronger than the KL’s resistor by a factor of 10, while the lux sensitivity is weaker by a factor of 10, making the answer to the first part the same as the class example! Using a 20k ohm resistor instead of the 100k ohm resistor changes things by quite a bit though, as shown above.

[cmonr-ssd447-blog]

My answers for HW 3.2

1. Color temperature is a characteristic of visible light. The higher temperature of the light (measured in kelvins), the 'cooler' the light appears. That is, 'warm' light temperatures tend to fall in the ranges of temperatures of 3000K and below, while 'cool' light temperatures tend to fall in the ranges of 5000K and above.

2. According to Wien's displacement law, the peak of a wavelength of any temperature is equal to the 'constant of proportionality' (2.8977729 x 10^-3 mk) over the temperature in kelvin.

For a temperature of 3300K, the peak wavelength is about 0.878x10^-6 meters, or 878.18 nm, or .87818 microns.

3. Lumens are a measurement of light- such as an amount of light eminated from a flashlight or a lightbulb (many modern flashlight manufacturers boast about how many lumens their flashlights can put out).

Lux takes the area of light into account- basically a single lux is equal to 1 lumen per square meter. It's used to measure the amount of light present and the intensity of the illumination on a surface.

4. In figure 2, there are actually no relationships to color temperature. The figure shows three seperate resistors. There is still an important relationship between the resistor and the output of voltage though. According to the notes following the data table, the output voltage is the product of the photocurrent(Iph) and the loading resistor (Rl). Therefore, the larger the loading resistor, the more voltage that is output, until sauturation. figure 2 shows this with 3 seperate loading resistors, uall sing the same (increasing) level of illuminance.

The specific formula math that the datasheet gives is Vout= Iph x Rl. This is located in the 'notes' section under the charts.

5. The sensor can definately see in 1000 lux conditions. It's ability to see is determined by the loading resistor, as mentioned in question 4 and shown in figure 2.

6. I had a little bit of an issue here, since I couldn't find the documentation on how the lightsensor's read() function gathers data. Since the homework added to simply not show any numbers past a decimal point, i just changed the program to multiply the readout by 1000 and display it in non decimal form. The link can be found here:

https://developer.mbed.org/users/CKMonroe/code/CKM_SSD447_HW_3_2/

[cmonr-ssd447-blog]

To answer 2.4, we can have a look at this pdf for the light sensor, obtained via a link from the KL46Z site.

2.4.1 The peak wavelength of light that the sensor sees is 630nm.

2.4.2 The lowest brightness that the sensor can see is 390nm.

2.4.2a The highest brightness that it can see is 700nm.

2.4.3 The peak wavelength of the human eye during the daytime is about 555nm, and 507nm at night according to wikipedia. (source: https://en.wikipedia.org/wiki/Spectral_sensitivity)

[cmonr-ssd447-blog]

A screencap of my homework for questions 2.2 and 2.3, involving binary fraction conversions (2.1 was just to set up the excel sheet)

[cmonr-ssd447-blog]

HW 2.1.2 - A question for classmates

I have had one question on my mind as I have read these articles and done research... and it actually splits into two smaller questions:

Firstly- what jobs exist that you think could NEVER be automated?

Secondly... why?

I have a few potential ideas, but would love to hear/debate with others on their own.