Back to the EC Circuit – What’s Going on WIth the Rectifier CIrcuit?

Tags

EC, Ladybug Shield

A few days ago (documented in this post), I was testing the Ladybug Shield Alpha 1.  Given what I wanted to test, I felt the best way was to make a test PCB.  I paid Metrix Create:Space $137 to fabricate two test PCBs.  I like to do more than one because it is not uncommon for me to remove the copper from a pin or do something else that makes the PCB useless.  Besides, there is no to just a little cost difference between doing one and two because a big chunk of the cost goes to set up.  Metrix Create:Space’s pricing can be found on this post.  The test PCBs are more easily damaged than those from Osh Park.  I submitted the Gerbers and drill files on Friday and picked up the PCBs Thursday afternoon.  This is definitely a time versus money trade-off.  I am finding making test PCBs in between Osh Park fabrications to speed up the process.  A significant reason is the shorter time between design and test means I don’t forget as much what I am trying to do.  The length of time is not long enough to clean my memory of what the heck I’m attempting to test.

I’m focusing on the part of the EC circuit that prepares the EC’s AC waveform to a DC current that is supplied into the ADC in order to convert to a digital value that an Arduino can read.

After testing the existing circuit, I agree with Dave Jones’ comment about peak detection circuits: “…it doesn’t exactly work like it does on paper.”  🙂

The Goal

The goal of this post is to understand observations I have made while testing the rectifier circuit.  This post presents what was observed, why this behavior happened, and what I will do to fix the behavior.

Open Source

The kicad schematics and layout can be found at this GitHub location. 

The code for reading the results from the ADS1015 is located here.

Thanks to Those That Went Before

As always, a huge thank you to Chris Gammell for his mentorship and excellent Contextual Electronics courses.  If expectations define what can be achieved, I received an a great gift in that Chris has expectations that we can learn electronics to a high level.  Combined with a great teaching style, My learning has jumped leaps and bounds.

Thanks to Dave Jones for his excellent “Fundamental Fridays” videos, like the one I watched several times so that I got a better idea on what the heck is going on in a rectifier circuit.

What’s Going on?

Through scope and DMM measurements, I’ve been observing two characteristics of the current rectifier design that are not right:

• The DC value that is fed into the ADC is sometimes at the right value.  But more often the DC value is higher and then drifts (slowly) downwards.
• The noise at 80mV seems high (I’m still looking into this)

The Op Amp’s Rate of Change in Voltage

Is it the Slew Rate?

Dave Jones does a great job explaining and then showing why the slew rate is an important characteristic of the op amps in this EEVBlog video.  Another good source of information is “The Art of Electronics, 2nd Edition” section 4.15.

I don’t believe the problem is the slew rate of the op amp.

 

The time it takes for one period of the shrunken waveform is about 600µS.  The frequency ~= 1/.0006S = 1.6KHz (surprise!  This is what I noted in earlier posts).  The Vpp = 216mV, with Vmax at ~100mV.  If it was the slew rate, the op amp’s voltage would slew to the negative rail – which is -2.5V in this case.  If the op amp’s voltage is -2.5V and it needs to get to 100mV in 300µS (half the period of the waveform).  The MCP6244’s datasheet notes the slew rate at .3V/µS.  This means the op amp can increase voltage by .3V/µS*300µS  = 90 V.  So I don’t think it is the slew rate.

The Maximum Follow Rate?

The Art of Electronics (p. 218) talks about the maximum follow rate.  The op amp’s follow rate is the rate at which the output can feed back to the input – the op amp’s vin- is powered by the output (i.e.: it is a voltage follower).  The MCP6244’s voltage follow rate = “output short circuit current”/C = +/-23mA/1µF = .023V/µS.  In 300 µS, the amount of voltage that can flow in is .023V/µS*300µS = 6.9V.  This is enough to accommodate 2.5V + 100mV+ the diodes (2*.6) = -3.7V. So the capacitor does not need to be smaller (although going to .1µF should work) since the follow rate is fast enough.

 

For now I’ll ignore the noise and focus o the DC value drift.  Dave’s video talks about the voltage droop caused by the capacitor leaking charge.  

If this is so, shouldn’t the values measured by the ADC go down and then back up (keep repeating down and up…)?

 

I’m still learning about capacitors, but I’m thinking the excess voltage is due to the interaction with the capacitor.

NO THANKS to the Memory

There are times when stuff should just be forgotten.  In this case, it is the capacitor holding on to a previous charge after discharge.  As pointed out in this app note from Analog Devices:

Dielectric absorption…causes a capacitor which is quickly discharged and then open-circuited to appear to recover some of its charge. 

Dave Jones’ video also explains this unwanted phenomenon in the EEVBlog #490 video.

Well dandy.  Ceramic capacitors have a high dialectic absorption.  I think this is what I was seeing when the charge was drifting up.  The ceramic capacitor was holding on to it’s charge.

Scrolling down the app note, there is a table which shows capacitors made out of polypropylene are inexpensive and have a low (0.001% – 0.02%) dialectic absorption.  Ceramic capacitors – in contrast – have a <0.1% dialectic absorption.  Polypropylene capacitors are a better fit for the rectifying circuit.

OK, Now What?

I am going to test and evolve the precision rectifier to be the simpler:.

• change the capacitor from a ceramic to a polypropylene.  I am pretty sure using a .1µF should hold enough charge.  Particularly given the second change I list (reset the rectifier)  I ordered a .1µF and a 1µF from digikey to test.  I haven’t used a polypropylene capacitor before.  It has a different footprint – much larger and with through holes.  Also, polypropylene capacitors cost more than ceramic.  I’m counting on the polypropylene capacitor to make sure readings aren’t higher than they should be (due to the dielectric absorption).
• reset the rectifier right before asking the ADC for a reading.  
• simplify the rectifier circuit from an “ultra precision” to a “precision” rectifier.  The precision rectifier is simpler – easier to understand – and given it will be reset before a reading, should work well.
• Rectify larger signals than the shrunken waveform.   200mV is too small to get accurate readings.  Realistically, given the EC signal goes through a gain loop, this should not be a problem.  However, another challenge I have been noticing is slight variances in the Vpp of the waveform created by the Wien Bridge Oscillator.  I’ll address this in a separate post.

Simplified Precision Rectifier

The first thing I did was draw out the design.  This gave me a visual I could trace the inputs and outputs to get a feel for expected results.  I’m finding figuring out the expected results prior to running tests put me into a better state when observing results with the scope or DMM.  

Reset the Rectifier

I added a MOSFET so the capacitor is reset prior to the Arduino requesting a reading from the ADC.   I remember I had some spare MOSFETs (digikey link) from the Contextual Electronics BenchBudEE project.  A YIPPEE! moment here.  I’m reusing SMTs I have used before and have on hand!

Mosfet Pin Config (Datasheet)

Since the Arduino asks for a reading, I decided to control the MOSFET’s Gate through an Arduino digital pin.  Since I want to capture the reading at a peak, I wanted to make sure the capacitor had a chance to reset the capacitor.  How long does it take to discharge a .1µF capacitor?

Recalling the formula noted in this SO answer:

 I=C*dV/dt

since I want dt: dt=C*dV/I   C = .1µF = 1 x 10-7F   I’m thinking the voltage that needs to be discharged will be a maximum of 1V so dv = 1V.  The voltage regulator  I’m using (data sheet) has a maximum output current of 100mA = .1A.  Plugging these values in:

dt = (1X10-7)(1)/.1 = 1 x 10-6 S = 1µS.

 

The Gate needs to be open for at least 1µS.

 

Is the amount of time it takes to execute a digitalWrite() longer than 1µS?  If it is, there is no reason to put in a delay() time.  Using the following code:

unsigned long start = micros();
digitalWrite(gate_pin,LOW);
unsigned long end = micros();
Serial.print(“microseconds to execute digitalWrite HIGH:”);
Serial.println(end-start);

I got 8 µS.  Actually, the granularity of the micros() function is 0-4µs, so the time it takes to execute a digitalWrite is between 4-8 µS.  I’ll use the most conservative 4µS as the amount of time.  4µS is 4 times larger than 1µS.  So there is plenty of time when the circuit is closed to discharge a .1µF capacitor.

Now that the capacitor is drained, the Gate must be open before a reading.  How long does it take to open the Gate?  According to the datasheet, it takes 19.9nS (Turn-Off Delay Time + Turn-Off Rise Time).  Given this fast time and the much slower execution time of Arduino code, I will not put in a delay function.

The code for resetting is:

digitalWrite(gate_pin,HIGH); Discharge the capacitor
digitalWrite(gate_pin,LOW); open the short circuit

Test the Circuit

After several starts, I decided to use the same parts that are in the circuit on the PCB.  This worked out quite well.  It was easier to wire up because the schematic matched the pins on the test circuit.  Since I am using the same chips as I designed for the Shield, I have more confidence the tests reflect what I will see when I order the next round of Shields from OshPark.  An additional benefit is the additions to breadboard parts!

I had gotten the ADC from Adafruit.  The benefit of buying from Adafruit is the additional effort Adafruit put into developing a library for the ADS1015.  They deserve a premium for the tutorial and library. They saved me a lot of time.  The other chips I soldered onto chip footprint -> DIP adapter PCB board, like this one on eBay.  In the future I will prioritize parts not just on price but also footprint.  If the chip uses a standard footprint, I most likely have a DIP adapter PCB board.  This means I can immediately test while I design!

Rectification

It is easiest to follow this discussion while viewing the pinouts on the kicad schematic found at this GitHub location.  This is for the test board that I discussed in a previous post.  

First Op Amp

The first op amp is used to create a VGND of +2.5V.  The VGND is used by the AWG when supplying the AC Waveform as input to the second op amp.  

Second Op Amp

I am using my trusty Gabotronics to provide the incoming waveform.  Here is the waveform I fed into the second op amp’s non-inverting input and the op amp’s output (before the diode):

The op amp is able to keep up with the voltage rise which means the slew rate is fast enough.   

Analog Results

Here are the results I got from my scope:

CH1 (Yellow) is the input waveform provided by Gabotronic’s AWG feature.  CH2 (Blue) is the output from the rectifier.

Digital Results

The results from reading the ADS1015 through the Arduino: 981.1 mV average of 100 samples +/- 1.2mV.  The standard deviation of 1.2mV points out a small range of values around 981 mV.  The scope shows a VMax of 1.04V.  This is 59mV greater than the 981mV read by the ADC.  What I don’t understand is the ground of the scope.  The Arduino and ADC share the same ground.  However, the scope is not on this ground.  Perhaps this is causing the difference?  I don’t see the difference as being something that requires further investigation because all readings would be referenced to the same ground.

The code I used is located at this GitHub location.

That’s It For Now

The rectifier circuit will be updated to reflect the drawing I detailed during testing.  While initial testing looks like this is a good choice, the shield will need more testing.  More testing will happen after I get updated PCBs from OshPark.  I first need to update the design…and there is one more thing I want to understand…which will be the subject of the next post.

 

 

Thanks for reading this far.  Please find many things to smile about.

Testing the Ladybug Shield Alpha 1 pH readings with pH Probe

I’m eager to try out the shield as part of a lettuce grow station.  Alas, I have made a D’OH error which I point out below.  While I try to avoid D’OHs…I find they are littered on my path.  I remind myself that what we do in life is always in a state of practice.

The Goal 

In  this post I solder on the BNC connector for the pH probe.  The goal is to start taking pH readings first in calibrated solutions then in lettuce grow stations.  I did not make this goal.  See D’OH below…

Thanks to Those That Went Before

I thank Chris Gammell for amplifying my electronics practice.  Chris has started a new Contextual Electronics course.  I can’t wait to learn more.  Chris has been an exceptional mentor.  Thank you. 

Adding the BNC connector

I am finding connectors to be the most difficult footprint to get right on my PCB layouts.  Many times I iterated over the footprint of the BNC connector when I was laying out the Ladybug Shield Alpha 1.  My iteration process consisted of:

• correct the location and width of the drill holes for the BNC. 
• print out the drill file and check if the BNC poles fit.

I am happy to report the fit was perfect.  A definite YIPEE moment! 

Measuring the pH With a Probe

I started like I have in the past, connecting the probe to the BNC connector and then putting the probe in pH 4 calibration solution.  Testing showed I wasn’t getting any readings.  After taking longer than it probably should…guess what?

 

That’s right – a D’OH moment.  Um… I tested the BNC connection by sticking the end of a voltage divider wire into the BNC connector. 

 

And found the problem!  Note the gold wire.  This would be the input voltage – i.e.: the voltage reading from the solution (relative to VGND): 

On the layout I got the pHV in and VGND reversed!

The image shows another D’OH moment. I added the post through holes as part of the circuit.  This mistake didn’t cause a problem because the through holes connected to the rest of the circuit.  However, I shouldn’t have done this and will update the layout to not include the posts.

Given the BNC pins are swapped and the posts are considered part of the circuit (but shouldn’t), this is also a problem with the EC BNC connector.  I fixed both in the schematic and layout.

Back to Measuring the pH Voltage

I removed the BNC connector from the shield.  I then put a BNC connector on a bread board and hooked up the probe.  I inserted the probe in pH 4 calibration solution.  As noted in this link, the pH voltage value of a pH 4 solution is 189mV.  I used a simple Arduino sketch that read the pH voltage from the ADC.  This was a differential reading using AIN0 for the pH Voltage in and AIN3 for VGND (see previous post).  I took 314 readings at 1 second intervals:

• Average: 186mV
• Standard Deviation 47mV

Until I get an updated board for more testing, this testing tells me the circuit is working correctly…although there are most likely noise issues that I will address.  A standard deviation of 47mV seems high on first glance.  Given the pH probe uses glass for a conductor and from experiments it can take time for the H+ ions to conduct best for a reading, I am not concerned with this value.  I notice a noisy behavior with other probes I have used.  In other words, I believe the standard deviation’s representation of noise is significant because of the way a pH probe works.

 

 

That’s it for now.  Thanks for reading this far.  Please find many things to smile about.

Testing Temperature Readings – Ladybug Shield Alpha 1

Tags

arduino, Ladybug Shield, pH

On to testing the temperature.

Open Source

I am using the Ladybug Shield Alpha 1 board created from the kicad files located at this GitHub repository. The Arduino Sketch I used during test is located here.

Thanks to Those That Went Before

Adafruit provides great tutorials.  I used their thermistor tutorials for this effort.

Thanks to Gerald Rectenwald for his excellent class notes on thermistors.  They were easy to read and useful.

As always – a huge thank you to Chris Gammell.  His Contextual Electronics and additional guidance has made it possible for me to even attempt this effort.

Testing the Thermistor

As noted in an earlier post,  the pH value will vary depending on the temperature.  The Ladybug Shield includes a thermistor circuit.  I detailed the thermistor circuit in this post.  I really like this circuit because it is a nice example of yet another use for a voltage divider.  Recall from this post:

The goal is to figure out the resistance of the thermistor – Rt.

Design

The circuit design for the thermistor is very simple.  

 

I labeled the known resistor (R15) on the schematic to be 1K +/- .5% Ω.  The resistor should be 10K since the thermistor’s rated resistance is 10K.  The 1K is a remnant of when I was using the MCP3901 for the ADC.

The voltage drop – Therm_AIN – is the input to the ADC.

Getting the Temperature

 

The schematic of the ADC shows the thermistor is measured off of channel AIN2 of the ADS1015.

 

 Arduino Sketch

The goal is to find Rt (the value for the thermistor which is acting as a variable resistor in the voltage divider circuit).  There are two knowns:

• R – This is R15 in the schematic.  I am using a 10K resistor that is within 1% accuracy.
• Vs – The V_Clean power.  This comes from the output of the voltage regulator.  While the voltage regulator SHOULD be 5V, I typically get a measurement of 5.06V. This is probably “close enough.”  However, the calculation for the temperature will vary by ~ 3˚ when 5V vs. 5.06V is used.  Ideally, since the ADC has a VREF and does that relative to Vs – I should be able to get Vs from the ADC.  But I can’t figure out a way to do this.  For now, I will use 5.06V for the known Vs.

 Results from Arduino

The sketch I used is located here.  I ran the sketch for awhile.  Output varied by +/- 1˚C.  Here is a typical line of output:

0:00:01 | ADC reading: 2378.00mV | Thermistor reading: 11278.39 ohms | Temperature 22.34 *C | 72.20 *F

From this small test, I have some confidence the thermistor circuit is working correctly.  The voltage reading on my DMM was within 1-2mV of the digital output I received in my Arduino sketch.  The temperature conversion was within 1˚F of a reading I made with a thermometer I had lying around.

What’s Next

It’s time to connect a probe, wrap the waterproof the thermistor and make the connecting cable from the thermistor to the shield long enough to be submersed on a nutrient bath….

Debugging the EC Circuit of the Ladybug Shield Alpha 1

Tags

EC, Ladybug Shield

Unknowns came up while I was testing the EC circuit of the Ladybug Shield Alpha 1:

• The characteristics of the shrunken AC Waveform.  My calculations have been assuming Vin doesn’t change.  Does it?  If it does, the variability will have a significant impact on the EC measurement.
• Rectification.  I’ve observed a drift in results.  Does the peak detection part of the circuit need to be reset?  I use the circuit discussed in this blog post for rectification.
• Rectification.  The Vpp I observed on the scope was around 80mV.  Is this the best I can get?  If it is, the digital values will be noisy.  Certainly it is best to go into an ADC with the cleanest DC signal.

The Goal

The Goal of this post is to investigate and understand the unknowns.  The outcome will evolve the design of the EC circuit.

The Files

The Kicad files that I used to create the test prototype is located at this GitHub location.

 

Thanks To Those That Went Before

A very grateful thank you to Chris Gammel.  He helped me with the direction to take with this prototype.  The new Contextual Electronics course is about to start.  I can’t wait to participate and continue to learn!

What to Test

As I walked through what I was observing in the EC Circuit with Chris, He broke up the circuit in a very understandable way. He also pointed out a test circuit in which switches are used to decide which circuit to test:

The AC Waveform created by the Wien Bridge Oscillator is shrunk to ~ 200mV Vpp.  The shrunken signal is Vin to the Gain loop that has the EC probe as a variable resistor.  Vout goes into a rectifier whose output is fed into an ADC.

 

Chris had a great suggestion.  Why not test the shrunken signal through the rectifier and also test the affect the Gain loop has?  Brilliant.  The unknowns I noted at the beginning can be easily tested this way.  The way I will do this is to put a SPDT switch on either side of the gain loop.

Schematics

As noted earlier, the Kicad files are located at this GitHub location.  I created a hierarchical schematic.  I’ve been thinking about how best to combine the process of drawing a block diagram (as shown in the image above) with the high level of the schematic.  Here’s what I came up with.

I liked Kicad’s ability to include an image onto a schematic.  I put the SPDT switches off to a breadboard.  This is represented by the blue drawing.  Blue text and drawing are annotations – not part of the board’s design.  It is nice to be able to do this for this prototype, since part of the functionality:

• SPDT switches
• ADC

will be on a breadboard connected by wires to the prototype board.

On To Metrix Create:Space

I am not thrilled with the layout.

 There are too many vias.  I went through the process that goes into the making of the prototype boards in a previous post.  Unlike the PCBs done at OshPark, the vias are not plated.  This means I must solder a piece of wire in a via.  What I ended up doing is making the vias the size of the wire I use in my breadboard.  This way soldering is easy.

 

Hopefully, I’ll be able to test this weekend.  

 

That’s it for now.  Please find many things to smile about.

sling sub-experience Local Alerts – Part 2 – Adding Location

Tags

sling

In a previous post, I built the first sling sub-experience prototype – local alerts.  This post continues where the last post left off, adding location information to the sling iOS app. To add to my excitement, I wrote the app in Swift – Apple’s new programming language.  So far I am a big fan of Swift.  I found it easy to get started and harder to master (this is a good thing!).  Less time is taken up dealing with the nuances of a verbose language (like Objective – C, but true of many others) since Swift makes a lot of concepts intuitive and infers my intention. My current plan is to switch my iOS programming to Swift.

The Goal

The goals of this post is to:

• document the second part of the sling sub-experience – adding location information.
• document and Swift/iOS programming tips/techniques/constraints I pick up along the way.
• understand how to go from sling background alerts prototyped in this post to foreground location information.
• explore the Swift programming language.

Open Source

The prototype iOS app is available at this GitHub location.

Thanks to Those That Went Before

Thank you to Punch Through Design for the Bean BLE peripheral.  It is a great way to prototype Arduino/iOS/Mac apps that use BLE and/or iBeacon.

Thank you to Apple for the Swift language.  While new to Swift, I believe it is a brilliant leap to more of a design driven programming environment.  I was amazed to not be boggled down in layers of methods/functions…stuff worked more like I thought it would.  

Thank you to Ray Wenderlich and the tutorial team.  I believe it was Owen Brown’s post where I found the code for their version of BTDiscovery – a Swift class for discovering BLE advertisement packets.  This work made it easy for me to evolve the code for my needs.  In the process, I learned more about Swift.  The site is an excellent resource for learning iOS programming.

Throughout this post I have linked to many great articles on BLE and iBeacon.  I lean a tremendous amount from the brilliant folks who wrote these posts.  Thank you!

The Prototype

I left the last prototype showing a notification alert to the Buddy Guard’s iPhone and playing a siren sound.  In this prototype, the assumed use case is the Buddy Guard taps on the button that opens the prototype in the foreground.  The prototype simply displays the iBeacon values for proximity, accuracy, and rssi:

The accuracy isn’t interesting for this prototype because it is used to determine among more than one iBeacon advertising the same packet, which one is the “best.”

iBeacon Gives the Prototype Proximity Info

Proximity is the important attribute.  As noted in the Apple SDK documentation:

The value in this property gives a general sense of the relative distance to the beacon. Use it to quickly identify beacons that are nearer to the user rather than farther away.

Here are the values as discussed in Apple’s iBeacon Getting Started document:

 

There is no way to get positional information, i.e.: “go right, then go left and you’ll run into the person wearing the sling device.”  Rather, iBeacon with the proximity is more like the HOT/WARM/COLD game where an item is hidden.  A person looks for the item while the other players shout “HOT”, “WARM”, or “COLD” depending if the searcher is getting closer or farther away.  This may be useful.  This may be not.

Prototype Flow

(please download and view the code to follow along)

I added to the flow of the prototype:

• a way for the View Controller to get a call back when the background app has received an alert.  The more I understand the MVC (Model-View-Controller) way of structuring an iOS app, the more sense and ease it is to separate out the model (in this case discovery of the alerts) with the View (displaying UI in the foreground)
• The View Controller sets and updates location information by setting View properties.

I used Apple’s iBeacon Core Location framework to provide location information.  A great feature of the LightBlue Bean is it can send iBeacon formatted BLE packets.  I have hopes to use an iBeacon to indicate where the person being attacked is located.  This may not be possible.  Given what I have tested, iBeacon’s main scenario is retail in which a customer walks near a display and the iOS app displays contextual ads or information about what they are looking at.  In this way, I see iBeacon as augmenting reality.  

 

I implemented two classes:

• IBeaconProximity: handles all iBeacon services.  All that is needed to get iBeacon parameters (proximity, accuracy, rssi) is to set the ViewController as a delegate of the BeaconDelegate protocol and implement the BeaconDelegate’s call back function beaconDidUpdate 
• BTDiscovery: handles BLE discovery of the Bean peripheral.

The code seems fairly simple.  Because iBeacon does not work in the background, I use BLE discovery to find a sling device.  Once the device is found, a notification alert playing a loud siren sound is played.  The Buddy Guard taps on the notification and the sling app is in the foreground.  At this point, iBeacon packets are detected through the IBeaconProximity class and labels are updated when the view controller gets a beaconDidUpdate call back.

 

iBeacon

iBeacon Packets

I got overly interested in the contents of iBeacon packets and how they fit into BLE traffic when exploring how iBeacon’s proximity technology. I wanted to gain a better understanding of what can and can’t be done with iBeacon’s proximity information.

Here is what a BLE packet looks like:

In order to intercept a BLE packet and see take a peak at these fields, I installed Apple’s Packet Logger Utility.  Apple briefly discusses Packet Logger here.  I found the easiest way on a Mac to get to this utility is to option-shift while pushing the left mouse button on the BLE symbol.  

It can also be installed as an extension to XCode as discussed in Apple’s documentation.

I used this iBeacon scanning app to scan for iBeacon advertisements on my Mac.  My Bean was turned on and advertising iBeacon packets.

BLE Packet 

Here is a BLE packet I intercepted.

 

Interesting stuff:

• event type: Scan Response
• Local name: HELP
• Mac address: D0:39:72:D3:44:19
• TXPower: 4
• RSSI: -72 dBm

What is TXPower?  As noted in this post about the Estimote iBeacon peripheral:

Broadcasting Power is the power with which the beacon broadcasts its signal, i.e. the power with which the signal leaves the beacon’s antenna. The owner of the beacon can change this setting e.g. using the Estimote app. The value ranges between -30 dBm and +4 dBm, lowest to highest power settings respectively. The higher the power, the bigger the beacon’s range and the more stable the signal, but it also shortens the battery life of the beacon—so you might want to consider lowering it to the minimum required by your use case.

 

A header file in the Bean’s iOS SDK has this enum:

 

typedef NS_ENUM(NSUInteger, PTDTxPower_dB) {

    /**

     *  -23db. Use this to maximize power savings.

     */

    PTDTxPower_neg23dB = 0,

    /**

     *  -6db

     */

    PTDTxPower_neg6dB,

    /**

     *  0db.

     */

    PTDTxPower_0dB,

    /**

     *  4db. This is the default value and maximum transmission strength.

     */

    PTDTxPower_4dB

};

So a TXPower of 4 means the Bean is transmitting at 4dB – perhaps harder on battery life, but better on signal strength.  A common trade off.

And RSSI?  From the same post:

RSSI is the strength of the beacon’s signal as seen on the receiving device, e.g. a smartphone. In general, the greater the distance between the device and the beacon, the lesser the strength of the received signal. Think: if you drop a stone into a container with water, the wave is bigger near the point of impact and smaller further away.

iBeacon Packet

In order for a peripheral to send out iBeacon packets, it has to support the iBeacon packet format.  

an iBeacon packet immediately followed the BLE Scan Response packet:

The packet shows an iBeacon is a Connectable undirected advertising packet.  What gets interesting is decoding the data.  A SO article details the meaning.  Of interest:

• ID: A4 95 12 34 C5 B1 4B 44 B5 12 13 70 F0 2D 74 DE

Aha!  Here is a line from the IBeaconProximity class within my Swift project:

let beaconUUIDString = “A4951234-C5B1-4B44-B512-1370F02D74DE”

the next two bytes are the major and minor id’s (part of the iBeacon specification).  

The last byte – 0XC5 – is the “measured power”.  Back to this post:

Measured Power is a factory-calibrated, read-only constant which indicates what’s the expected RSSI at a distance of 1 meter to the beacon.

But this calibration is only relative to what the environment was in the factory.  Note in Apple’s iBeacon Getting Started documentation:

…To provide the best user experience, it is critical to perform calibration in your deploymentenvironment. As each beacon is installed you should perform a calibration step….Combined with RSSI, this allows to estimate the actual distance between the device and the beacon…the physical surroundings can affect the signal strength. Since the surroundings will almost certainly vary between installation locations it is important to repeat these steps for each beacon that is installed.

The above is just more detail on the lack of precision in BLE/iBeacon distance/proximity prediction.

Things to Know about the XCode Environment.

I found the following tip extremely useful. At 31:10 into WWDC 2013 video session 406: Taking Control of Auto Layout in Xcode 5, the presenter shows a shortcut to getting a second window while doing a layout / working on code:

 

 

 

 

 

then do option-shift when selecting the storyboard to

About Protocols and Delegates

 This tutorial does a good job explaining coding protocols and delegates. 

Don’t Forget the Info.plist Keys!

To get Core Location code working ,  this key needs to be added to the  Info.plist file.

NSLocationAlwaysUsageDescription : "Some Description of why you want to take location"

And I’m Done…For Now…

I hope I remembered to document the important things.  The main “gotchas” I had was around keys required in info.plist….UIBackgroundModes and NSLocationAlwaysUsageDescription seem to be the most relevant for this prototype.

 

 

Thanks for reading this far.  Please find many things to smile about.

 

Testing the EC Circuit – Ladybug Shield Alpha 1

Tags

EC, Ladybug Shield

 On to testing the EC sub-circuit of the Ladybug Shield

EC Subcircuit on Ladybug Shield PCB

Testing the Wien Bridge Oscillator

Design:

Layout:

 

scope Relative to VGND

Pin 8 is the Vout for the Wien Bridge Oscillator op amp.

Results

Looks good.  In subsequent check of pin 8 relative to VGND, the Vpp seemed to vary between 800mV and 1.12V.  I do not think this affects the results of the EC measurement because Vin is back calculated from Vout (see below).

Shrink the AC Signal

The next step is to shrink the AC signal before it goes into the all important EC measurement op amp.

Design

Scope Relative to VGND

Pin 3 on the MCP6244 is input into the EC measurement op amp.  Here is the scope reading relative to VGND:

 

Measuring ECv

 Design – Getting to an EC Signal

The first part of the circuit for measuring the ECv is getting an AC waveform for the EC Signal:

 

 

 

Design – Rectifying

The second part is rectifying the EC waveform into a DC value:

Design – Conversion From Analog to Digital

The schematic for the ADC:

Testing

As I discussed in this post, I will use resistors instead of a probe for this level of testing.

I put a resistor in the BNC connector’s input through holes.  A challenge I have is making sure the connections are solid between the resistor’s wires and the EC probe’s BNC through holes.  I soldered two wires to the BNC through holes and put the resistor on a breadboard to improve this connection.

200Ω Scope Relative to VGND

Probe on pin 1 of the MCP6244 (EC_SIGNAL):

Gain = 1 + 1K/200 = 6.  Shrunken Signal(Vpp) = 220mV, Vout = 6 * Vin = 6 * Shrunken Signal(Vpp) = 6 * .22 = 1.32V.  The Vpp on the scope was 1.06V.  I have seen the Shrunken Signal(Vpp) be 200mV.  This would make Vout = 1.12V (and hence Gain = Vout/Vin = 1.06/.2 = 5.3).  A bit larger then 1.06.  I attribute the difference to measurement.  Certainly the difference could be an error in the circuit.  

Probe on pin 14 (EC_AIN, the rectified signal):

The noise (Vpp) is 100mV.  I have been seeing a range of 60-100mV.  80mV is what I was measuring on the prototype board when I measured the rectified signal.  I need to find out if this is noisier than what is acceptable.

ADC Results

Getting unexpected results.  Given the results from the scope, I expected the ADC value to be around .56V.  What I saw was a sample started at 489mV and gradually increased.  So far I have not isolated the problem, but I have noticed unexpected probe results on these pins in the past.  Thus, I do not think it is the ADC – although why would the scope show a more realistic value?  Is there something about the gain loop that would cause this discrepancy?  Something in the design of the op amps (particularly around the rectification – which is certainly fancier than just one op amp and diode!)

Time (mins) | mV

ADC Range: +/- 1.024V (1 bit = .5mV)
0:00:00 | 489.00
0:01:00 | 489.50
0:02:00 | 490.50
0:03:00 | 491.00
0:04:00 | 492.00
0:05:00 | 493.50
0:06:00 | 495.00
0:07:00 | 496.50
0:08:00 | 497.50
0:09:00 | 499.50
0:10:00 | 501.00
0:11:00 | 503.00
0:12:00 | 503.50
0:13:00 | 505.50
0:14:00 | 507.50
0:15:00 | 509.00
0:16:00 | 510.50
0:17:00 | 512.50
0:18:00 | 514.50
0:19:00 | 516.50
0:20:00 | 518.50
0:21:00 | 520.50
0:22:00 | 522.00
0:23:00 | 524.00
0:24:00 | 526.00
0:25:00 | 527.50
0:26:00 | 529.00
0:27:00 | 531.50
0:28:00 | 533.50
0:29:00 | 535.00
0:30:00 | 536.00

100Ω Scope Relative to VGND

(the resistor read 99.1Ω on my DMM).  Probe on pin 1 of the MCP6244 (EC_SIGNAL):

Gain = 1 + 1K/100 = 11. 200mV (the shrunken signal’s Vpp) * 11 (the Gain) = 2.2V.  The scope measured 1.92V Vpp.  The wave is about 10 x amplified not 11.  Perhaps I am not amplifying the measured Vout/Vin (1.92/200 = 9.6) -> Gain  -> 1 + 1K/100 (11) correctly.

Probe on pin 14 (EC_AIN, the rectified signal):

Here the noise (Vpp) is 60mV.  

ADC Results

As before, the values do not fluctuate wildly.  They seem to start high, go down, then creep back.  These values seem like an algorithm could work with them.  For example, take a sampling over a few minutes and average.  Then use the mV to the 2nd digit.  With that said, I wonder if I am seeing a problem like I noted for the previous ADC results.

Time (mins) | mV

DC Range: +/- 1.024V (1 bit = .5mV)
0:00:00 | 965.50
0:01:00 | 961.50
0:02:00 | 960.00
0:03:00 | 958.50
0:04:00 | 957.50
0:05:00 | 957.50
0:06:00 | 958.00
0:07:00 | 957.00
0:08:00 | 957.00
0:09:00 | 956.50
0:10:00 | 957.00
0:11:00 | 957.00
0:12:00 | 956.50
0:13:00 | 956.50
0:14:00 | 956.50
0:15:00 | 956.00
0:16:00 | 956.00
0:17:00 | 956.50
0:18:00 | 956.50
0:19:00 | 957.00
0:20:00 | 957.50
0:21:00 | 958.00
0:22:00 | 958.00
0:23:00 | 958.00
0:24:00 | 958.50
0:25:00 | 961.00
0:26:00 | 961.00
0:27:00 | 960.50
0:28:00 | 962.00
0:29:00 | 962.00
0:30:00 | 962.50

Findings

I was relieved to see the Wien Bridge Oscillator, Shrunken signal, EC_SIGNAL, and EC_AIN send out promising signals.  Results I questions:

• The Waveform created by the Wien Bridge Oscillations seems to vary a bit from a Vpp of 1.2 to ~800mV.  The word “oscillate” makes me leap to the thought of “unstable” however I have no idea why there is variability.  I assume this does not affect the value for EC_SIGNAL since Vin (the shrunken signal) is back calculated after measuring Vout via the ADC.
• The amplification of the waveforms for EC_SIGNAL seem to be off by a magnitude.  I need to check to see if I understand how amplification -> Gain works.
• I am not sure why the ADC value drifts over time. I noticed a drift using the scope, but have not been able to easily reproduce.  It does make me think the culprit – if there is one – is in the rectifying circuit.  I am new to this design over using a simple op amp and diode.

 

Some progress, a few questions.  That’s it for now.  Please find many things to smile about.

Validation Testing of the Ladybug Shield, Alpha 1 – Power and pH

Tags

Ladybug Shield

YIPPEE! I got the boards back from Osh Park late last PM (1/9/2015).  Time to validate the design by testing the board.  This post starts the process for the power and pH sub circuits.

At least the Ladybug came out nice!

Open Source Hardware

The kicad files for the schematics and layout are located at this GitHub location.

The Goal

The goal of this post is to test the:

• power
• pH

sub systems with a procedure that minimizes variables.  What I mean by minimizing variables:

• the pH will be tested using the method described in this post – using a DC voltage and not a probe.
• I will use wire my bench power supply to Vin and GND to ensure getting a known amount of power.

Once all the tests pass this level, I will test with probes and a pH bath.

Thanks to Those That Went Before

• I always like to stop and thank Chris Gammell.  I am thrilled to here he is starting up a new session of Contextual Electronics with a subscription model.  I will definitely sign up.   It is very rare to be blessed with as strong a teacher and mentor as Chris.  Thank you.
• Ryan at Sparky’s Widgets for open sourcing the minipH and mineC breakout boards.  I have happily bought and used these BOBs. This effort stands on the shoulder of Ryan’s work.  I spent hours pouring over the schematics he provided.  Also, when I got really stuck, Ryan was kind enough to answer my questions.  I am extremely thankful.  The most precious resource we have is time.  Thank you.
• OshPark’s fabrication service has been a very positive experience.  Thanks for the exceptional support, service, and quality fabrications at a reasonable price and turn around time (although – heck – why can’t I have it within the hour 🙂 )?
• Adafruit’s ADS1015 BOB, Arduino library, and learning material.  Adafruit saved me a significant amount of time!

The Power Section

The power section includes:

• Clean Power (VClean net on layout)
• VGND

Design

 I included images of the schematic.  It would be better to look at the kicad files:

Layout

The VClean net is noted below.  The VGND net is located where the MCP6242 is laid out.

Clean Power

the components soldered to the board.  I’m happy to see my soldering skills are improving.  Well, ok – I prefer solder paste and a hot air gun. This works best for me.  My hands shake to the point it is far easier for me to use this method with smaller chips. 

 

In a previous post, I noted power in must be greater than or equal to 7.34V.  Vin on the Arduino should provide that.  Instead of putting on the headers right now (they’d get in the way), I’m going to use my bench power supply to provide 9V to the Vin pin.

 

Worked first try:

D3 is the green LED – which is on in the image…meaning power is being supplied. DMM shows 9V coming in from Vin and 5V going on VClean (see layout) pins.

VGND

The 1K R8 and R9 as well as the first op amp of the MCP6242 are used to create the VGND.  There is a bypass capacitor at each voltage in. 

VGND worked first try!

pH

The pH circuit has two main pieces:

• analog – read probe
• digital – use ADC to convert analog reading into a digital value that can be read by an Arduino sketch.

Analog Design

The analog design is very simple.

I replaced the probe with a DC voltage created through a voltage divider.  The DC voltage on the breadboard measured .510V.

10K R and 5K POT

Following a reading:

• .510V on breadboard 
• .510V measured at BNC the connection.  
• Pin 5: .510V  Pin 6 and Pin 7: .512V of the MCP6242

So the analog size of pH reading worked for this test.  On to the digital..

Add in Digital

Adding in digital means adding in the ADC – the ADS1015:

 

I then ran the sketch I discussed in a previous post with the modified ADS1015 library.  I took a series of differential readings where pH_AIN = AIN0 – the fourth pin – of the ADS1015.  I set the LSB to .5mV ( +/- 1.024V) into AIN3 (pin 7)

 

The average of 57 readings was  .515V  STDEV: .002.  This is close enough to the analog reading of .510.  The STDEV is not noisy.

These tests were (surprisingly) successful…on to the EC circuit.

 

Thanks for reading this far.  Please find many things to smile about.

 

 

 

 

sling sub experience: local alerts

Tags

arduino, sling

In a previous post, I introduced my new project, sling, and listed prototypes I will be working on.  In the post, I noted sub-experiences to prototype.  The first one was:

• local alerts:  sling hardware sends out a BTLE alert that is picked up by iPhones within range that are running the sling iPhone app.  Through sound and UI, the sling app notifies the iPhone that an alert has been received.  At this point, the sling app is running in foreground mode.  The sling app starts updating near/far proximity information so that the person with the iPhone has a chance to come quickly to the aid of the person that set of a sling alert.

I’ll be covering this sub-experience in two posts:

• sling hardware sends out a BTLE alert that is picked up by iPhones within range that are running the sling iPhone app.  Through sound and UI, the sling app notifies the iPhone that an alert has been received.
• At this point, the sling app is running in foreground mode.  The sling app starts updating near/far proximity information so that the person with the iPhone has a chance to come quickly to the aid of the person that set of a sling alert.

Source Code Location

The source code is located at this GitHub location.

Demo

The following gif image shows 1) putting a battery in the Bean 2) the notification settings UI on an iPad 3) the iPad’s display 4) the blank foreground of the sling app 5) the alert that pops up when a sling alert is received by the iPad:

 This siren sound is played when an alert is displayed on the iOS device.

The Goal

The goal of this post is to explore and implement the first part of the first sub-experience – sling device sends out an alert.  iPhones that are running the sling app use sound and UI to notify the iPhone’s user that an attack is in progress.

Non Goals

I will not be discussing details on iOS programming.  There are great resources out there including:

• The WWDC Videos – these come out yearly after Apple’s Developers Event.
• Stanford University’s iOS development course in iTunes.
• Tutorials on Ray Wenderlich’s site.
• StackOverflow

Equally, I will not be discussing how to program a Bean.  PunchThrough’s web site has good documentation and sample applications.  

 

The resulting prototype will be able to receive sling alerts on an iPhone.  However, the quality will be more along the lines of something that is put together with rubber band, tape, and bubble gum.  The objective is to gain a good first look at the direction to go for this sub-experience.

Thanks To Those That Went Before

The ability to build these prototypes, learn, and hopefully – make a difference would not be possible even 10 years ago.  It amazes me to have the opportunity to wake up every day and use these tools.  Of course, these tools wouldn’t be possible without dedicated and talented people.  Folks at PunchThrough – thank you for the Bean.  It is an excellent way to explore Bluetooth (BLE) communications between an Arduino sketch (running on a Bean) and the iOS.  Folks at Apple – many people dedicated a lot of effort and time to the iPhone – not the least the engineers who designed and built Core Bluetooth and the XCode SDK.  Your work is powerful and polished.  And of course Chris Gammell – I keep learning from Chris and highly recommend his Contextual Electronics course.  I’m excited to learn Chris is coming out with a new format for the courses.

Parts

There are two main parts – the BLE peripheral sending out sling alerts and a smartphone app that receives the alert and notifies that there is an attack in progress.  The technologies I will use include:

• an iPhone. I use an iPhone and am an Apple Developer.  For these reasons, I will be using the iOS SDK and the XCode IDE to build the sling app on my iPhone.  I recently upgraded to an iPhone 6 and am running iOS 8.  This will be my smartphone platform for this prototype.
• After listening to an interview with the founder of Punchthrough Design on The Amp Hour podcast, I decided to use a LightBlue Bean as the BLE peripheral.

Setting Up The Bean

To keep the prototype as simple as possible, I insert the Bean’s battery when I want sling advertisements to be broadcast.  I remove the battery when I want the advertisements to stop.

Setting up the bean included:

• Enabling iBeacon advertisements using the Bean Loader (see PunchThrough’s iBeacon setup link).
• Turning down the advertising interval.  In the WWDC 2012 Video Session 705, at ~ 21:40, the presenter discusses the differences between discovering devices in the foreground versus the background in an iOS app, noting that discovery in the background takes longer.  One thing the BLE device manufacturer can do is to shorten the advertising interval. The presenter recommends to set the interval for this situation to 20ms.  Since the Bean need only be advertising when a distress activation has occurred, lowering the advertising interval should not significantly degrade the battery performance.  The Bean’s default advertisement interval is 500ms (from the FAQ).  As you see in the image below, I was able to set the advertisement interval to 60ms, but no smaller.  I am not sure why the advertisement interval cannot be set to 20ms.  Luckily 60ms was a small enough interval between advertisement packets.
• Setting the name of the Bean to SLNG using the Bean’s Arduino API.
• Setting the CBAdvertisementDataLocalNameKey to HELP.  I did this using the iOSExampleapp provided by the Bean SDK.  The Bean SDK is at this GitHub location.  The iOSExampleApp XCode project is talked about on this GitHub page under “Getting Started & Examples.”

Screen shot of Bean iOSExampleApp Showing Config Where CBAdvertisementDataLocalNameKey is Located

The iOS App

Caution – Things to Know about BLE Communications

As I learned more about Apple’s Core Bluetooth framework as well as the behavior of BLE, I found the following areas important to understand in the design of this prototype.

BLE Device -> iOS: Foreground Vs Background Communications

The challenge of using up the iPhone’s battery seems to be a major factor in why BLE communications is different when an iOS app is in the background or foreground.  Apple provides the Core Bluetooth framework  to iOS apps for interacting with BLE packets.  

Before I talk more about this, I want to point out an excellent StackOverflow post where this exceptional person tested background discovery and provided all with the results.  This post was “learning gold” for me!

The most affected area is handling BLE advertisements.  Understanding the differences became critical to receiving BLE alerts.

Apple’s Programmer’s Guide points out the states an iOS app can be in:

When launched, the app runs in the foreground.  When the app is no longer on the screen, it is running either in the background or suspended mode.  If the system gets desperate for more memory, the suspended app gets kicked out of memory.

Handling the case when then app is in the foreground is easy-peasy.  

It gets trickier when the app runs in the background or in suspended more.  After all, Apple doesn’t want the sling app to suck up all the iPhones power!   If an iOS app is running in the background:

• The Core Location Framework – which I hope to use in the next post –  of which an iBeacon packet is a member of – does not give the app advertisement packets when the app is in the background.  In order to discover the Bean while in the background, the Core Bluetooth Framework must be used.
• scanning for bluetooth packets using Core Bluetooth happens at an unpredictable and slower rate.  

iOS Apps Connecting to a BLE Peripheral

At one point in the design, I planned for the sling app to connect to the Bean peripheral.  Connecting and maintaining a connection to the Bean is a “showstopper” because the BLE 4 spec specifies only one central (in this case one iOS device) can connect to a peripheral at one time.  This means other Buddy Guards running the sling app would not be able to connect to the sling Bean.  For this reason, the sling app uses advertisement broadcasts to detect a distress alert.

The iOS App

Note: If you have looked at my code, you’ll notice I liberally sprinkle the code with debugging lines.  Why do this when XCode has a very powerful debugger? Well, I got into “bad habits” while engrossed with the Arduino IDE.  But also, peppering the code with log statements gives me a feel for the flow of the code.  It helps me to see how the methods actually work versus assumptions I made while reading about them.  This is exploratory/throw away code.  You can take out the #define LOG and #define DEBUG_LOG if you wish to remove the log statements.

If I asked 10 people to draw a picture of the sun, I will get 10 different pictures.  Likewise, there are many different ways to implement this scenario.  After many starts and stops, I decided the app will receive alerts (from the sling device) when running in the background (emphasis on not the foreground).  Why?  Core Bluetooth provides the method CBCentralManager::scanForPeripheralsWithServices. This tells Core Bluetooth the app wants to get an advertising packet for a service, many services, or all BLE services depending on the parameters passed in.  As noted in the StackOverflow post, The problem happens if the advertisement was previously discovered in the foreground and then the app is put in the background.  If this happens, the alert will never be seen by the app running in the background.   The sling app’s main feature is to discover sling alerts.  There is no UI requirement for this.  iPhone owners will be texting, running some other app in the foreground, have the phone with the display of in a pocket or bag.

After creating a new single view project in XCode:

• edit info.plist to include the UIBackgroundModes key and bluetooth-central value to the info.plist. Core Bluetooth will only send an iOS app delegate callbacks when this key/value is specified.  (so don’t forget like I kept doing! 🙂 ).
• add Core Bluetooth methods/call backs to sling’s appDelegate.  I chose the appDelegate because it reminds me of a landing field for switching between the background and foreground.  Note: a “gotcha” I ran into was how Core Bluetooth optimized its BLE cache.  If the sling app scanned in the background, found the Bean, stopped scanning, and started a scan – the second time the Bean would not be discovered.  I’m pretty sure this is because of the state management going on behind the scenes by Core Bluetooth.  This makes sense if I think about how the foreground/background scanning work.  I.e.: if the Bean is discovered when the app is in the foreground, future scans for the Bean in the background will not be received.  What ended up working was:
•  to prepare the iPhone/iPad after messing around: 1) delete previous builds of the app from the iPhone/iPad 2) turn BLE off and then back on the iPhone/iPad 3) launch the app and then put it in the background scan only in the background and when BLE is updated (usually a power on/power off).  When the alert goes off, the next step in the sling app is to move to the foreground.  Thus, the next time the app is put in the background scanning will again discover the Bean (which means Bean advertisement needs to stop after a bit – basically saying the distress call has gone out.  Time to stop advertising).
• Notifications on iPhone can be displayed in different ways.  How a notification is displayed can only be changed by the iPhone’s owner by going into Settings->Notifications.  I changed the notification style for the sling app to the Alert style.

Alert Sound

When the iPhone running the sling app gets a sling alert, the alert pops up and a sound starts.  I wanted a loud siren sound.  Before I can attach the sound to the alert, I needed a sound file.  I googled and found the sound file Siren_Noise-KevanGC-1337458893.wav.  In order to play on the iPhone, the WAV file needs to be encoded in a format that can be played on an iOS device and then put into a CAF file.  This post does a great job explaining the formats, etc. in playing sounds on an iOS device.  I converted the sound file to a Linear PCM encoded CAF file from a terminal window with the command:

afconvert -f caff -d LEI16@22100 -c 1 Siren_Noise-KevanGC-1337458893.wav Siren_Noise-KevanGC-1337458893.caf

Now all that needs to be done is attach the CAF file to the notification:

        UILocalNotification *slingNotification = [[UILocalNotificationalloc]init];

        slingNotification.soundName= @”Siren_Noise-KevanGC-1337458893.caf”;

That’s It For Now

There is a lot more to be done to get the alerts a robust and polished experience.  This prototype has taught me enough about iOS app development with Core Bluetooth and using the Bean as a prototype peripheral to feel comfortable on designing the hardware and software once the details of the experience are better understood.  For example, after seeing the notification, it became clear that the identification (name, initials,..) of the person under attack should be shown in the notification.

 

Thanks for reading this far.  Please find many things to smile about.

 

Introducing sling

Tags

arduino, sling

Happy 2015.  While I will be continuing last year’s project which evolved into the Ladybug Shield, I am starting a new project I’ve named “sling” that I am extremely passionate about.  

Thanks to Those That Went Before

I have been given so many presents.  A brand new year – still all wrapped up with the events this year will bring.  Tons of other stuff I won’t bore you with and…

• Chris Gammell – the person that provides the excellent Contextual Electronics courses.  I highly recommend these courses.  From barely being able to use a breadboard, jumper wires, and breakout boards I have been able to design and build PCBs…choose components…and SORT OF 🙂 understand the electronics and math behind the circuits.  I could not do this project without Chris’s courses and mentoring.  THANK YOU.

What Is sling?

sling is a wearable device and smartphone software that gives it’s owner a “fighting chance” to disengage from a physical attack.  The focus is on:

• React – The owner activates the sling wearable when in danger.
• Respond – Buddy Guards* at the same location get an alert on their smartphone that an attack is under way and provides proximity information so that a Buddy Guard can quickly go to the location where the attack is happening.  More distant Buddy Guards will get an alert with a map location where the attack is happening.
• Record – takes an voice recording of what is being said and sends the recording to the smartphones of Buddy Guards.

Buddy Guards are people whose smartphones are running the sling app – either in foreground or in background.  Buddy Guards may also be protectors like Campus Police or a safety team through SMS or other remote alerting technologies.  Once aware of an attack, they may also respond in other ways to increase the safety of the person being attacked.

Why This Project?

I’m a mom.  One of my children was attacked.  These attacks must not happen (although I know attacks will continue).  I thought how I could best help minimize attacks.  I could bring more awareness through activism.  I could become a counsellor.  These activities – and others – are needed but do not leverage my skill set.  I decided to build an experience that uses hardware, software, and communications technologies to design and build a wearable + smart phone app that can be quickly activated when a person is being attacked.  Combining with others whose skill sets align with activism, counseling, etc. we can team up in a united front to eliminate physical attacks from happening to our daughters, sons, sisters, brothers, parents, grandparents, friends.

Why the Name sling?

A sling was the tool David used to slay Goliath.  The story of David against Goliath is a constant reminder that there are ways for the physically less strong to defeat big, strong monsters.  

A Scenario

I thought I’d start by walking through a scenario.  The goal is to gain a common context on an experience when sling is involved. 

A group of kids go to a party.  The kids have configured the sling app so that they are all Buddy Guards of each other.  Remote Buddy Guards may include family members, people on alert to help the kids, campus police, etc.  One of the kids gets into a situation that has spun out of control to one in which they are being physically attacked.  The kid under attack activates the sling wearable (activation of the sling wearable will be one of the many things to get feedback on.  We can all think of many ways – a button, a voice command, a heart beat rate, pulse rate, a movement…).

Upon activation, the sling sends out a BTLE alert and starts loudly beeping (~ 100dB) for a few seconds. The beeping stops.  sling starts recording voices for a few minutes.  Meanwhile, the Buddy Guards whose smart phones are within range of the alert pick up the alert and send remote alerts (for example, an SMS) to other smart phones that have been set up to receive remote sling alerts.  Most likely this will mean a Buddy Guard gets multiple alerts.  The design could change.  My initial thought if there are more alerts, there is a better chance at least one gets through.  Like all aspects of the sling experience, the alert reception design will change as people start participating in the sling experience.  The alert has GPS location information.

When an alert is detected, the Buddy Guards that are within a BTLE range will start viewing the sling app UI which will be moved to the foreground if it isn’t currently running in the foreground.  The sling app will give them proximity information as an aid to getting to the person under attack as soon as possible.

In the background, the voice recording finishes processing.  Once finished, sling sends the voice recording to a sling smartphone app which then sends the recording to Buddy Guard’s phones.

The details of this scenario will evolve as I learn more and others provide feedback to get the experience to be maximally useful given the available technologies.

Proof of Concepts Prototype

I will start with building prototypes.  I find prototyping to be the best way for me to get my best thinking on the design of hardware and software.  

The Goal

The goal of the prototypes is to rapidly build the sling sub experiences using existing hardware.  The end result will be a deeper understanding of how each sub experience can best be implemented in hardware and software.  They will also inform the sub experiences, evolving them to more effectively address the goals of sling – help in deterring physical attacks.

sling Sub Experiences

sling sub experiences include:

• local alerts:  sling hardware sends out a BTLE alert that is picked up by iPhones within range that are running the sling iPhone app.  Through sound and UI, the sling app notifies the iPhone that an alert has been received.  At this point, the sling app is running in foreground mode.  The sling app starts updating near/far proximity information so that the person with the iPhone has a chance to come quickly to the aid of the person that set of a sling alert.
• loud beeping: sling hardware turns on a loud beeping sound for a few seconds and then turns the sound off.
• voice recording: sling hardware starts voice recording and storage of the voice file.  Once the recording is complete, the voice file is sent to the iPhones running the sling app.
• storage of voice recording: the sling app will use a storage mechanism (e.g.: sending over sms, dropbox…TBD) so the voice file is available when the process has begun to recount the attack.
• remote alerts:  once the iPhones that are within the BTLE range of the sling alert have been notified, the sling app sends data to iPhones outside of the BTLE range that are on the Buddy Guard list.  The data includes information that “this person” is being attacked as well as the GPS coordinates where the attack is taking place.

Constraints

Given what I know how to do, I am constraining the prototype to:

• iPhone devices.  In the past I have developed iOS apps and have an iOS developer’s account.  Given this knowledge, I will design and build the smartphone prototype on iOS.  
• BTLE.  There are many locality based wireless protocols that could be used.  BTLE has grown in use.  iOS devices have excellent support for BTLE.  I’m starting to see great support for BTLE for Arduinos.
• Arduino for sling wearable programming requirements.  I have become very familiar with the Arduino environment.  Also, there are many breakout boards, information, as well useful sketches and libraries readily available for sharp folks.
• not consider chip selection and PCB design.  The higher priority is to understand how the hardware and software can be best used to solve each sub experience.  Once understood, more detailed analyses will need to be done to design the hardware and software for use.

That’s It For Now

Please let me know if you see ways to improve the hardware/software/scenarios.  In the ideal, we build this experience together.

 

Thanks for reading this far.  A VERY HAPPY New Year.  Please find many things to smile about.