Weekly Update 9-20-16 to 9-26-16

I started this week by playing with some inductive charging stuff. I got a couple different pre-made inductive charging sets and took them out for a spin. This first set was a sketchy pair of coils with no schematic online. It worked well and had pretty good tolerances for both distance between coils and off set between the center of the coils. The second set I played with used the Qi standard. These coils had a lot less tolerance for being misaligned, but they were different sizes. They also have more documentation online which is helpful. Overall right now the inductive charging looks promising and I will continue to work to integrate it into the existing sharkduino.

I also worked on figuring out why the LiPo charging circuity on the existing sharkduino does not work. After poking around it for a while with the multimeter and looking at the schematic I realized I have been putting the LEDs on backwards. This is sort of an amateur error, but in my defense polarized surface mount components are hard. What’s important is that I know how to avoid it in the future, and I will assemble new layer 2 boards soon with the LEDs on properly. Fingers crossed that it will work.

Finally the rest of my week into PCB design. I finished up the PCB for the RTC I talked about last week, and sent it off to be made. I am trying a kind of risky routing on it so hopefully it will work. I also spent a lot of time working on making a board that will turn into Sharkduino v2. It features an all new form factor, the new RTC, and is smaller than the previous version. It’s not quite done now but it is close. Unfortunately I can not order it to test it out for quite a while. I have to get the new RTC boards in and test them before I can send these boards out to be made, this is because I want to find out if the RTC works before buying more stuff using it. The reason I went ahead and designed this new board with the RTC now is first I’m pretty confident in the RTC, and second is that I was sick for the latter part of the week and PCB design is really good to do while sick. It requires you to think a little, but not to much, and it takes a lot of time so you can just curl up and go for it while you can’t get out of bed.

Weekly Update 9-13-16 to 9-19-16

Posting on Tuesdays is feeling pretty good for these updates so expect this to continue during the semester.

I began this week by finally getting prototype 5 operational. This is not as exciting as it sounds because I only fixed some of the problems it was having. The other problems seem to have gone away on there own, this is very troubling as any problem you don’t fix isn’t fixed. I tried to recreate the problem I was having but I couldn’t so the only thing to do now is to use it and pay close attention to see when it will fail again.

In addition to this I began work on a design overhaul of the sharkduino layout. I am working on putting the existing sharklion components onto a single board. This board will be larger than the stackable boards but since there is only one I am working with a slight decrease in overall surface area to populate. This new board currently has a trapezoidal shape to hopefully mirror the shape of the fin it will be attached to.

Finally I began work on finding a new RTC chip. The chip we have right now is physically large, expensive, and uses SPI, which is has been hard to work with because the uSD uses a different mode of SPI. Switching between these modes has been a problem for us in the past. Because of this I am looking for a RTC that uses I2C, is more power efficient, is physically small, and cheaper. Now this sounds like a lot but our current chip has a lot of features we are not using so we can make a lot of concessions to achieve these goals. I thought I had found a chip that satisfied all these criteria, and I got as far as completing a PCB design schematic for it before I realized that it uses slightly more power than our current RTC. It does fulfill the other criteria we were looking for, but our current chip already uses a fair bit of power and increasing the power even for the other gains does not seem like a good deal right now. Established since there seem to be a fair number of other chips on the market that can fulfill all the goals, they just have fewer publicly available PCB designs associated with them. I spending so much time with a chip that ultimately will not work is a screw up but I have learned what to do to keep it from happening so hopefully I won’t waste a big chunk of time this way again.

Update
I’m making this update because I feel I was being a little down about the RTC thing when I wrote this post. I have actually done more research into RTC chips, and while the one I designed for may not have been the best chose, it isn’t the worst. So I’ve decided to go forward using it. I will probably replace it again at some point in the future but it gives us enough gains to use for now.

Weekly Update 9-2-16 to 9-12-16

First off I still haven’t figured out where I want to fit these updates into the week. Right now I am thinking either Tuesday or Thursday, but we will see. Now that we have the housekeeping out of the way let’s move on to what I did since my last post.

I started this week by working on prototype 5. It is still not fully working, but it’s getting better and I’m narrowing down the problems. I have been going through the connections with the logic analyzer and have found a bunch of the connections seem very noisy and kind of bad. I have been doing my best to tighten these up but I’m not sure why this happened. I have done this a lot and have not had this sort of overall connections that transfer data but do it poorly. I do not know if I got sloppy connecting things or if I soldered poorly, or if the solder itself is being weird. It doesn’t matter too much though. I know the problem and not it’s all about fixing it. Right now the only non working component is the RTC, and I hope to get that sorted this week.

In addition to building prototype 5 I have been doing battery tests on the sharkduino. I have found that the device can run for about 43 hours at 2Hz and about 64 hours at 12Hz on a 400mAh LiPo. These time are much lower than we want, but not out of the realm of what we expected about the device. One of the big goals going forward is to increase these times. The first and most obvious is to just use a bigger battery, and we can do this to a point. We will probably use a battery at least twice the size of the one we did these initial tests on in deployment. The problem with just increasing the battery however is it does make the device larger, heavier, and more expensive. We are also going to look into ways of making the device more efficient. We need to check that there is nothing in the hardware or code that draining current unnecessarily. We are also exploring the idea of changing the integrated chips we’re using for some of the sensor to possibly find some lower power options.

Finally this week I have been doing a lot of research and planning for the semester. Due to budget reasons we need to buy a lot of what we want to use for the semester soon. Because of this I have been coming up chips sets I want to try for the wireless charging in addition to looking at kits to prototype NFC and BLE with. Additionally I have been thinking about the hardware I want for any other improvements or changes to board. This is all kind of difficult because I am essentially guessing what I am going to want to use in designs I haven’t made yet. In addition to this I have been doing general planning for the goals and focus for the semester.

I will outline some of the hardware choose and research I have done in a later post once the I have done more of it and the dust has settled a little.

Weekly Update 8-26-16 to 9-1-16

I spent most of this week doing research for the project. Currently we want to look into the feasibility of removing all ports from the device. This would make waterproofing the tag significantly easier, and cut down the chance of the tag being destroyed on deployment. Currently there are only two ports that are needed once code is uploaded to the device. The first is the microSD port and the second is the USB charging port. What this means is that we need to develop ways to wirelessly charge the device and get data off of it. The power problem is the easer on to solve, we do it with inductive charging. This technology is common in all sorts of technologies from electric toothbrushes to high end smartphones and smartwatches. Inductive charging works by placing two coils of wire near each other and allowing the electromagnetic field produced to transfer energy. The problem with this technology is that it can be slow, especially if the charging coils being used are small. However for the lower power usage and small batteries we are working with we think that this should not be a problem even with the small footprint, and thus small coil for the tag.

For the wireless data transfer these is less of a clear cut solution. We all transfer data wirelessly all the time every day through Wifi, bluetooth, cellular networks, etc. The problem with these methods is that they are power intensive, and complex. We do not want to add a lot of hardware to the device that will draw a lot of power, even if the power is only drawn while the device is charging we might still not be able to power it. Lucky people have already developed solutions to this problem. The first is called bluetooth low energy (BLE) which is in fairly common use today. It was released as part of bluetooth 4.0 and is similar to bluetooth but uses far less power. It does this by having a slower data rate, working over a shorter range (~50m), having fewer channels to advertise over, and a series of other differences to cut power usage. The goal of this standard is run bluetooth off a watch battery. Bluetooth lower energy devices are pretty common, things like step trackers and other wearables, along with bluetooth mice and keyboards use this standard. One problem with this standard though it pairing the devices.

The other technology we are currently looking at is peer-to-peer near field communication (NFC). NFC is another common technology in modern cell phones, and is used for things like touch pay. It is also used whenever you touch your phone to something to get it to react. This technology is not in super common use in phones outside of payment systems though because Apple does not give outside developers access to the iPhones NFC capabilities. For NFC in electronics the most common use is not peer-to-peer, often on one device is powered and it is reading data off some sort of passive tag. Peer-to-peer NFC has however been used for data transfer by android in the mostly failed android bump feature. This feature transfer photos, music, or other information between android phone by touching the back of the phones together. The benefit of NFC over BLE is that NFC does not have pairing problems, and I think it may have a little less hardware overhead, but I’m not sure. The problem is that it has a relatively slow data rate, this may be okay though because we are working with relatively small files and have time to transfer them while the device is charging. Also NFC has a very short range of communication, maybe a couple centimeters at most.

Overall for the data transfer problem I have not done nearly enough research or experimentation to come to any type of conclusion at all.

In addition to all the research I spent some time this week working on assembling Prototype 5. This prototype is going to replace the destroyed prototype 4, and use one of the gyroscope chips I made. Unlike prototype 4 however the gyroscope is not stacked on to of the accelerometer, but placed next to it. This makes the device longer but narrower. Currently the prototype is assembled, but only partially working. I need to do a little trouble shooting on it. A picture of it can be seen below.

Prototype 5

Prototype 5

Finally on Monday I submitted my final report from the REU program. If you want to read it, you can find it here.