Please note: unlike the other pages on this website this is in the form of a blog style to show weekly research done
making the pattern control
getting two half drivers to control an led
Today I figured out how to blink an led with two half driver chips (since I will obviously need to use two half drivers to create the matrix). I first attempted to make one chip have an output set to a high side and the other set to a low side turning the low side on and off but this created an underload detection response that I didn't want. So I changed the code to have the high side on consistently for one of the chips and the other chip changing from low side to high side fixing my underload detection problem (see code below)
design + schematic
today I started to think about the way I want to design my garment, I know that I want to embrace the technology, and not hide it. I choose to make a schematic on eagle so that I could play around with the layout on where things go. I made the drivers, teensy and micro led boards for the schematic so they are not reliable for actual pcb development purely for schematic reference. note the led's are a replacment for hte nitinol just for the schematic. see schematic below
my theory is that clothing is the greatest type of pcb. each layer of fabric can be used to separate electronics from shorting and to allow to optimal capacity of placement of devices. If I choose to work in this manner I can use layer one to put the teensy closer to the drivers and then another layer of clothing on top to place the fabric changing. see video and pictures for reference
code to operate OLED and LED's via halfdriver
issue 1: figuring out how to make drivers from both output 1-6 and output 7-8 work
Since I moved to using a teensy as appose to the arduino the first thing i needed to fix was the speed that the SPISettings was at. I wanted to view the incoming bytes from the driver properly so I needed to change the speed, I tested a few out and notices that a speed at either 2MHZ or 4MHZ worked well. Next I figured out that I can use SPI.transfer16() as appose to SPI.transfer() so I no longer needed to pad the rest of the transfer ( code not listed but can if needed). I figured out that the way to make the two driver sides to work was to do spi.beginTransaction() and spi.endTrasnation() unfortunatily this would cause issues for other devices if I wanted to run SPI because it would be stopping them as well so I then figured out how to run the code without these two functions by releasing that the chip actually is delayed between transactions so if I put a small delay between the two transfers going to the chip, the chip can understand thw two SPI commands otherwise it won't understand the last one sent.
code without SPI.endTransaction() and using a delay below:
issue 2: figuring out why the driver was giving me an underload protection.
It had been concerning me since the begining of working with the driver chip and trying to make an led blink on and off that I was getting a response that an underload protection was on. I finally figured out that this was because when I was turning off HIGH-SIDE dirver I was then in turn turning on the low-side driver, grounding the current making the underload protection turn on. I fixed this by turning off the the half-bridge driver that i enabled through an spi command
issue 3: getting a response back for an led output that was related to the other led.
Another strange thing I noticed was that my responses from the chip would match the previous transfer and not the current one. I realized this is because the chip is a "frame behind" so it outputs the previous command and not the current one, hence why in the code below I changed the print statement to match the previous one.
Adding the display
I got the micro oled display from sparkfun https://www.sparkfun.com/products/13003?_ga=2.168573986.269507858.1521563021-1173196642.1514748465
I am very glad that I got this one that could operate on SPI or I2C because I soon learned that the SPI was a problem
issue 4: using SPI on the micro oled at the same time as the drivers
I'm not sure why but It appeared that using the micro oled spi interfered with the spi on the driver chip, I noticed that when I would do oled.begin() it wouldn't allow me to use the output drivers of 7-8 and really just in general I would get a wanky response from the leds running off the driver. I then switched to I2C (which you should be warned is definitely slower on the micro oled, and will slow down the leds a little ). NOTE: when using I2C with the teensy 3.2 external pullup resistors (see here https://www.pjrc.com/teensy/td_libs_Wire.html) must be put in place for the buses to run properly, without the pullup resistors the bus will run MUCH slower. I followed the micro oled hookup guied for setting up the I2C (https://learn.sparkfun.com/tutorials/micro-oled-breakout-hookup-guide) so you just need to short some connections on the breakout bread (See picture below)
I shorted 0 instead of 1 on D/C , but it doesn't matter , you just need to change the code they have written to 1 if you short it at 1
with the micro oled finally connected in I2C with the drivers in SPI I started making a code that seams pretty promising on properly running the driver while alsoe running the micro Oled, The code is below. I used a finite state machine process to switch between the intro and pattern1
Video of what code does:
creating a clock
I ordered a teensy 3.2 because I heard there are alot of great features. including capacitive touch sensors, serial monitor without ftdi cable needed, a boat load of of extra pins, and an onboard clock
A hard wear comparison of the different teensy products can be found here https://www.pjrc.com/teensy/techspecs.html
To set up the teensy the pjrc has thorough documention starting with this page
followed by https://www.pjrc.com/teensy/td_download.html
followed by https://www.pjrc.com/teensy/loader.html
next I worked on setting up the clock on the teensy
documentation for that is here https://www.pjrc.com/teensy/td_libs_Time.html
I followed the TimeTeensy3 Example Program so I went into File > Examples > Time > TimeTeensy3. and opened up my serial monitor, and what do ya knwo the time on my computer is already being dispalyed!
Now to make this portable:
First the CRYSTAL 32.7680KHZ 12.5PF T/H needs to be soldered on , it can be found here at digikey https://www.digikey.com/products/en?keywords=300-1002-ND
After that if you wnat to retain the time that you are going to set to the CRYSTAL 32.7680KHZ you need to add a 3V coin cell battery to the teensy ( as shown on https://www.pjrc.com/teensy/td_libs_Time.html)
Now run the TimeTeensy3 and open the serial monitor to have the time updated. Now I wanted to make this portable and I also didn't like how the time was in military so I went in and edited the code , here is the code I created.
I got rid of the part where the program needs you to open the serial monitor to get the time and where it grabs the time from the pc. That section needs the computer attached because thats how its getting the time, but since we already put the time in the teensy by using the TimeTeensy3 we just want to get the time it has ie Teensy3Clock.get(), this value though is a Unix epoch time (https://www.epochconverter.com/)
(not possitive but I bleieve time_t converts the unix epoch time to a single number so we can use it in the 'basic usage' mode)
I got rid of the date and year because I'm not going to be displaying these values. I then added a convertto12hours function so that I wasn't viewing things in military time anymore. Now the clock is portable and in 12 hour time!
working on pattern matrix
In this video each of the fabric patches is treaded the way a regular matrix is. The nitinol was crimped to regular conductive trhead to make sewing connections easily. For some reason the voltage on each patch increased by about double so I will try and explore why this is the case
checking battery life for project :
Since this is a wearable one of the things i want to make possible is knowing wether the garment needs to be recharged or not. one of the ways to do this is doing a voltage divider
2 images above show how the voltage divider looks on the arduino. The Vin pin powers the arudino and can take between 7-12V as stated here (https://arduino.stackexchange.com/questions/4458/what-are-the-5v-and-vin-pins-for) .A0 takes in the voltage range from resistor 2 and then in the arudino code we mutliply this value by 2 (Because the resistors are the same so have the save votlage drop) to find the value of the battery. It should be noted that the voltage read is between .05 to .15V off compared to the battery itself.
Reference to voltage divider and instructable for idea here
understanding half bridge
Rising edge occurring at the serial communication output
Falling edge occurring at the serial communication input
Serial monitor from chip. This is what the chip is telling us which is saying that bit 10 ie H-bridge 4 is enabled and bit 1 ie High side on NOTE for some reason arudino cuts off bits that are transferred out from the chip that have a zero ie why we aren't reading in 16 bits so what this really is is 0000010000010000 but the serial monitor ignore the last 5 zeros that are transferred
These measurments were taken after frequent use of sending current through out the nitinol and conductive thread. Please note that conduvtive thread is alot slower when current has not been sent through it for a prolonged period of time. See video1 for reference PLEASE NOTE: these measurements are off of one test
for more accurate results many more tests would need to be done and an average of the tests taken place , unfortunitly time for this wasn't possible
Figure1 of Nitinol vs conductive thread of two different lengths, voltage vs current
Figure2 of Nitinol vs conductive thread of two different lengths, periodically sent current flowing through the systems. transistion time vs current
Conductive Thread 1.1cm
Conductive Thread 1.9cm
Video1 of Nitinol vs conductive thread both same size (1.1cm x .5cm)same stitch after 12 hours of no current flowing through the systems