2016-03-11 (F) Weekly Summary

Last week hardware was picked out for the cyborg pulse sensor and this week it was integrated with mixed results. A couple components were destroyed but replacements were stocked an inexpensive. Ultimately it was a productive week. Design has been changing and improving from the simple sensor→controller→magnet design to include a modified program and switching hardware and a version anyone can use, not just cyborgs. Maybe.

There was small success immediately and a pulse sensor was built using hand-wound coils and the stock pulse sensor program. This was encouraging and probably made me the first cyborg to sense a pulse through electrical stimulation of an implanted magnet. Unfortunately the sensation from the coil was weak.

First known cyborg pulse sense

Outputs from these controllers is inherently limited and I failed to protect it from voltage spikes which are part of the package when using inductors like these coils. One way to pass more power through the coil was a transistor. Also, a transistor was one of the simplest methods and I had a couple hundred stocked. Transistor theory is not a small subject but simple.wikipedia does a pretty good job. A 2N3904 transistor was added to the circuit to increase the power going through the coil.

Transistor added to circuit for more power

Since the device was getting bulky and this was an early prototype the components were separated into two module. The larger module was the controller and battery. The battery was easily the largest part of this project and will likely continue to be the case. Not just with this project, batteries are big. For the second component I combined the coil and the pulse sensor. This part was meant to go at the fingertip where the user would touch a patient. DuPont wires were used to link the halves but long headers could also link the halves so it was versatile as a prototype. Neither of these linking methods would be good for a finished product but they allowed for easy testing.

Tether to make sensor and controller separate

I broke a controller. It could have been a couple of things or a combination of them. The two most likely problems were the lack of a flyback or snubbing diode and the second was the limits on the controller. Either way, too much strain was put on the controller and it stopped working. A replacement was installed and the project moved on. After that a snubbing diode was added to the circuit.

Snubbing diode soldered across terminals

Speaking of passing too much power through a component the diode began heating up. A lot. When the pulse sensing circuit was attached the transistor would quickly heat up to dangerous levels. This was measured with a contactless IR thermometer. The thermometer showed the device got over 60º Celsius (140º Fahrenheit) but the transistor burned my finger once so it had to have gotten even hotter. That was the second component I burned up. More transistors were stocked so it was replaced and the project continued.

Overheating transistor

I thought the overheating transistor was a problem with the coil I had wound so I wound one with more wire. Nearly six meters were used for the new, and largest, coil. A power drill was used for the winding process, which worked well. This coil performed very well and after comparing it to the other coils was probably larger than necessary. While thinking about it I realized the problem was not the coil itself but rather the way I was powering it. Inductors, coils, allow direct current to pass with very little trouble but alternating current can’t pass so easily. Basically, the problem was that I was supplying the coil with direct current and effectively creating a short between the power and transistor. Hence the destructive heating. A better testing program was written, simple oscillation rather than direct current, and all the coils were ranked according to sensation strength. Fortunately the coil already soldered to the sensor was powerful enough.

Five coil prototypes

A second version was started with all new hardware that used a vibrator motor instead of a coil. Vibrator motors expect direct current instead of an oscillating signal. In fact, the motor won’t work well with an oscillating waveform especially because I had chosen a low duty cycle. The quick explanation of duty cycle is the percentage of time a signal is on. Regular DC is 100% duty cycle while the tone() wave generated by Arduinos (a simple square wave) is 50% duty cycle. This concept is very important in digital outputs and the basis for the PWM generated on the analog output of controllers like Arduino.

Vibrator motor version

The vibrating motor version of the pulse sensor wasn’t working as quickly as I had hoped. Powering the motor off of an output pin has worked in the past but that was when the controller was a large ATmega328P. This time the controller was an ATtiny85 so I assumed the problem was insufficient power and added a transistor like last time. There was still no reaction so debugging commenced. An LED with a limiting resistor was put on the outputs to confirm it was receiving power and it was. Blink, Arduino’s version of Hello World, was loaded and that confirmed that the motor was receiving power. Hopefully the issue is that the signal from the stock pulse sensor program is just too short to run the motor. More testing to come.

Testing vibrator version with LED

This blog has been going for two whole years. Almost 800 posts. I tell people that I blog incessantly and that’s why. Today’s post was 1 000 words long and was written in a single sitting without copy-pasting from previous posts. This blog has been a lot of work and I’ve enjoyed it. I ramble on and on about all this in a post right on the two year mark, maybe you’ll go there and say something in the comments.


The rest of the weekly summaries have been arranged by date.

First time here?

Completed projects from year 1
Completed projects from year 2


Disclaimer for http://24hourengineer.blogspot.com/

This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.

All information in this blog, or linked by this blog, are not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.

All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by  Brian McEvoy, cannot be used to claim property or assets.

Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim claim property or assets based on their post.

This blog, including pictures and text, is copyright to Brian McEvoy.