Author Topic: EMF pickup from amplifier in I2C line causing glitches. (Now with scope trace!)  (Read 40910 times)

0 Members and 1 Guest are viewing this topic.

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
Hey guys,

I've got a problem with a circuit I designed.  The circuit features this amplifier:
http://www.ti.com/lit/ds/symlink/tpa3116d2.pdf
http://www.ti.com/lit/ug/slou341a/slou341a.pdf (Evalulation module)

And this LED driver:
https://ams.com/chi/content/download/.../AS1115_Datasheet_EN_v2.pdf

As well as several other I2C parts made by TI:
http://www.ti.com.cn/cn/lit/ds/symlink/tlc59116.pdf
http://www.ti.com.cn/cn/lit/ds/symlink/tca9539.pdf

The TI parts are working great.  The AMS part however is glitching like crazy.

After many many hours looking for bugs in my code, lowering the transmission speed, and enabling the internal pullups on the I2C lines to lower the resistance somewhat from the already low 2K resistors I'm using, I've determined the issue is that the 7' CAT5 cable I'm using, where I have the I2C data lines each twisted with a return ground, is picking up EMF interference from my speaker cables.

I determined this was the case, because:
- The issue goes away if I turn the volume all the way down, and comes back if I turn it up even slightly.
- The issue persists even if I connect only one wire from the speaker to the amplifier.
- The issue goes away if I increase the length of my speaker wires, and decreasing the length also seems to affect the amount of glitching.

I suspect the issue arose because I did not include any filtering on the output of my amplifier.  I didn't do this, because I have limited PCB space and I was trying to keep costs down so I didn't want to use a couple inductors and I wasn't sure how to choose a proper ferrite bead. 

This is my current schematic:
[link removed]

But I've been looking at ferrites and I've narrowed the selection down:
http://www.digikey.com/short/347180

I should mention that I have my amplifier set up in a mono BTL configuration, with a 12V supply, so the beads must be capable of handling around 40W into a 2 ohm load, ie 2-3A max.  I see Digikey lists both a max current rating and a DC resistance.  I assume those are related to one another and there's a number of beads rated for 3A or more.

The bit I'm not sure about is what the best impedance to select is.  TI had chosen a part for their EVM that was 90 ohms at 100MHz:
http://www.digikey.com/product-search/en?keywords=EXC-ELDR35C 

I see a couple ferrites that ate 80 and 120 ohms at 100MHz.  I guess those would be fine.  But what about those rated 600-785 ohms?  Too much?

The amplifier datasheet says to select one with a resonant frequency around 10MHz but I can't see any specs indicating resonate frequency in the datasheet. 

But comparing a 120 ohm bead to the 600 ohm bead, it looks like the 600 might be better.  At the low end where my audio frequencies would be they're about the same, but the one with the higher impedance looks like it would filter out higher frequencies better:
http://katalog.we-online.de/pbs/datasheet/742792023.pdf
http://katalog.we-online.de/pbs/datasheet/742792514.pdf

On page 21 of the amplifier datasheet it also states:
Quote
Additional EMC improvements may be obtained by adding snubber networks from each of the class-D outputs to
ground. Suggested values for a simple RC series snubber network would be 18 ? in series with a 330 pF
capacitor although design of the snubber network is specific to every application and must be designed taking
into account the parasitic reactance of the printed circuit board as well as the audio amp. Take care to evaluate
the stress on the component in the snubber network especially if the amp is running at high PVCC. Also, make
sure the layout of the snubber network is tight and returns directly to the GND pins on the IC.

I'm hoping I won't need to go quite that far, and that the ferrite bead filter will be sufficient?

I was also thinking about testing this out with some through hole parts, or one or two of those little ferrite rings, if I can find one of them.  I had a few prototypes manufactured without this filter in place and I'd like to still be able to use those boards and testing before I have another prototype made to see if it will even fix the problem would be good.  If I did have one of those rings, is there some special requirement for them?  Or a specific number of turns I need to wind the cable around it?

Finally, is there any other solutions to this issue you might suggest?  Like, would it be wise to put decoupling caps from my I2C data lines to ground at each end of the cable, or would that screw up the data transmission?  I also considered the possibility of using shielded Cat5. If I did that, would I need to connect the shield to ground at both ends, or just at the main PCB where my power source is?  Should I add a resistor on series with the shield?  I'd rather not go this route because I'd have to buy new more expensive Cat5 cables and modify the design of one or both boards to add the shielded connectors, and I don't know if the shield would affect the I2C transmission.
« Last Edit: July 14, 2016, 12:04:50 pm by Starlord »
 

Offline moffy

  • Super Contributor
  • ***
  • Posts: 1734
  • Country: au
Re: EMF pickup from amplifier in I2C line causing glitches. Solutions?
« Reply #1 on: June 30, 2016, 12:12:47 am »
I2C is not meant to drive 7' of cable, it is meant for near connections of devices on a PCB. If you have got some parts working it is amazing. Because it is bidirectional and open collector I don't know how you could buffer it.
EDIT: Perhaps look at the TI chip: P82B715 I2C Bus Extender
« Last Edit: June 30, 2016, 12:32:52 am by moffy »
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
Re: EMF pickup from amplifier in I2C line causing glitches. Solutions?
« Reply #2 on: June 30, 2016, 12:34:47 am »
I2C is not meant to drive 7' of cable, it is meant for near connections of devices on a PCB. If you have got some parts working it is amazing. Because it is bidirectional and open collector I don't know how you could buffer it.

The I2C standard only specifies that cable capacitance must be below 200pF and even offers suggestions for how to run the signal through twisted pair: 
http://www.nxp.com/documents/user_manual/UM10204.pdf

A Cat5 cable is around 52pF per meter, and I have my signals twisted with ground returns, as suggested.

Also, there do exist ICs which are designed to convert it to a differential signal so that much longer runs can be achieved, but I figured as long as I kept within the specs, I was okay.  And I would be okay, if my amplifier weren't putting out ridiculous amounts of RF noise.
 

Offline moffy

  • Super Contributor
  • ***
  • Posts: 1734
  • Country: au
Re: EMF pickup from amplifier in I2C line causing glitches. Solutions?
« Reply #3 on: June 30, 2016, 12:42:01 am »
"Also, there do exist ICs which are designed to convert it to a differential signal so that much longer runs can be achieved, but I figured as long as I kept within the specs, I was okay.  And I would be okay, if my amplifier weren't putting out ridiculous amounts of RF noise."

It's because it is susceptible to noise,i.e. 2k impedance and slow edges(cable capacitance), that it really isn't suitable for long runs of cable. You can't necessarily control the noise environment, but if you use low impedance differential drivers you are much less susceptible to noise.
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
Re: EMF pickup from amplifier in I2C line causing glitches. Solutions?
« Reply #4 on: June 30, 2016, 05:01:46 am »
Where do you get 2K impedance from?  Not questioning it, I genuinely don't understand.
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
Hey guys,

I just picked up my first scope and I've got a couple scope traces here, maybe this will help diagnose the issue?

I'm pretty sure the noise is generated by the amplifier and picked up by the cat5 cable, and that putting the suggested ferrite beads on the output will resolve the issue, but I'd appreciate your input as to whether that will solve the issue before I send out for a board revision and have to wait 3 weeks to find out it didn't do anything.

This is what I see on the scope when I disconnect the speaker cable from the amp: 


The rise time obviously isn't great, but its 400KHz I2C and it appears to be within spec. At least, assuming the rise time means the time to get above 0.7V.  The spec states 300ns and it looks like its doing it in 200ns.  The fall time also appears to be in spec.

And this is with the speaker cable connected.  And if you can believe it, this is the longer speaker cable that seems to attenuate the noise enough that the system actually works.  I was pretty shocked when I saw this.  I haven't even tested with the short cable yet to see how bad IT is:



Note that when I probed this, I had the ground lead attached to the board, and I was probing the end of the cable.  I'm not sure if this matters.  It would be a bit more difficult to attach the alligator clip at the end of the cable, but I guess I should try that next and see if there is any difference.  My intuition tells me I won't see much of a difference.
 

Offline diyaudio

  • Frequent Contributor
  • **
  • !
  • Posts: 683
  • Country: za


The rise time obviously isn't great, but its 400KHz I2C and it appears to be within spec. At least, assuming the rise time means the time to get above 0.7V.  The spec states 300ns and it looks like its doing it in 200ns.  The fall time also appears to be in spec.


The rise time on your waveform results from the probe itself, at 400KHz the 1:1 ratio is acting with the compensation network of the probe, try using a 1:10 ratio and observe results again.

 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
The rise time on your waveform results from the probe itself, at 400KHz the 1:1 ratio is acting with the compensation network of the probe, try using a 1:10 ratio and observe results again.

I don't understand what you mean.  It sounds like you're saying I should use the x10 setting on my probe, but it is set to x10, and I have the channel set to x10 on the scope as well.
 

Online Kleinstein

  • Super Contributor
  • ***
  • Posts: 14195
  • Country: de
The rise time is way longer than 200 ns. Depending on what you use for the rise time (usually 10% to 90%, sometimes 0 - 70%, rarely 30-70%), the rise time is more like 500-1000ns. This low rise-time with all the noise (might not be as bad without the probe), glitches are expected.  A 1:1 probe has a considerable capacitance and thus could increase the rise time. A 1:10 probe is not a problem at this speed.

To get a shorter rise time, use a smaller pull-up. More like 1/5 the current value. At higher capacitance lower value pull-ups are needed.

There should be filters at the output of a class D amplifier, unless the amplifier is right at the speaker.
I can't imagine passing FCC limits without a filter, if a longer wire to the speaker is used without filtering.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16648
  • Country: 00
Finally, is there any other solutions to this issue you might suggest?  Like, would it be wise to put decoupling caps from my I2C data lines to ground at each end of the cable, or would that screw up the data transmission?

It would severely limit the data rate. Is that a problem?

I also considered the possibility of using shielded Cat5.
That would be the first thing I'd try. Transmitting data over long, unshielded cables simply doesn't work.

If I did that, would I need to connect the shield to ground at both ends, or just at the main PCB where my power source is?
Only at one end.

Should I add a resistor on series with the shield?  I'd rather not go this route because I'd have to buy new more expensive Cat5 cables and modify the design of one or both boards to add the shielded connectors, and I don't know if the shield would affect the I2C transmission.
As a quick test you could try wrapping the cable in tinfoil. Ground it at one end and see what happens.

« Last Edit: July 03, 2016, 09:53:39 am by Fungus »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16648
  • Country: 00


The rise time obviously isn't great

It's awful. I'd definitely use lower value pullups.

There's no lower limit on I2C pullups except what your devices can pull to ground. The lower the better.

Those TI devices can sink 20mA or more on SDA (see datasheet) so you can go much lower than 2k.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16648
  • Country: 00
Note that when I probed this, I had the ground lead attached to the board, and I was probing the end of the cable.  I'm not sure if this matters.

It matters a lot, especially on unshielded cable.

Connect the ground lead to the return ground on the line you're probing.

But remember the clip is connected to mains earth - watch this video:

 

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 6631
  • Country: hr
Hi!
Let me throw in my 2c...
I2C bus is chip interconnect...something you use on a PCB with maybe 25cm (10 inches) distance...
It is very prone to noise pickup and very sensitive to capacity of the com lines..
What are you trying to do is realm of CAN and RS485 an the likes..
I'm not saying that with enough duct tape (filters, buffers etc..) you will not be able to stabilize your prototype.. If you put enough effort you will but it will be hard to reproduce later and your product will be unreliable...

And now shortly as to why...

First, as they say devil is in details.. As you can see on your scope trace, your rise time is takes up whole signal.. It should resemble some kind of trapezoid with soft edges.. Slopes are OK, but there is no top.. :o.

What that means is that while signal raises, at one point it will reach threshold to be recognized as HIGH (I know you know all this but bear with me).. at slow speed I2C has NO hysteresis, and at fast it has 0.05V (50mV).. which means as your signal slowly rises, reaches threshold level, and at that point when it is around the right level, even 50mv (and less for slow speed) will make it go up and down the threshold many times, potentially triggering logic transitions... What it will do at that moment nobody knows... By spec it should swallow pulses shorter that  50ns, or not...  That is why you need quick, fast and clean logic transitions..

The fact that you build a shortwave radio transmitter that poses as audio amplifier doesn't help..  :o That thing is a EMI nightmare, filter everything, supplies, ground, input, output, sever pipes....

Anyways, good luck with that, that will be great learning experience...

Take care,


Sinisa
 
 
The following users thanked this post: SteveyG

Offline radar_macgyver

  • Frequent Contributor
  • **
  • Posts: 698
  • Country: us
Are you sure the I2C chip is picking up radiated interference, as opposed to conducted interference? Do they share a common power supply? Common AC power? If this is due to conducted interference being picked up through the power supply, adding ferrites there might be worthwhile.

And yes, open-collector single-ended signals with 2k pullups are good candidates for all kinds of interference. Lower pullups, maybe experiment with a small (~10-100 pF) capacitors on the lines to form an RC filter.

Note that when I probed this, I had the ground lead attached to the board, and I was probing the end of the cable.  I'm not sure if this matters.  It would be a bit more difficult to attach the alligator clip at the end of the cable, but I guess I should try that next and see if there is any difference.  My intuition tells me I won't see much of a difference.
Big difference. Please see: http://www.cbtricks.com/miscellaneous/tech_publications/scope/abcs_of_probes.pdf

Specifically the section on ground lead effects (page 26).
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
The rise time is way longer than 200 ns. Depending on what you use for the rise time (usually 10% to 90%, sometimes 0 - 70%, rarely 30-70%), the rise time is more like 500-1000ns.

Ah crud.  I just noticed that the I2C spec says 0.7Vdd.  As in 0.7 * Vdd.  I thought it was stating 0.7V is considered a high signal.

Quote
This low rise-time with all the noise (might not be as bad without the probe), glitches are expected.  A 1:1 probe has a considerable capacitance and thus could increase the rise time. A 1:10 probe is not a problem at this speed.

To get a shorter rise time, use a smaller pull-up. More like 1/5 the current value. At higher capacitance lower value pull-ups are needed.

I am already using 2K pull ups.  These should be in-spec according to the I2C spec.  And the I2C spec seems to prohibits anything less than around 1.56K for a 400KHz bus speed with 5V supply.

So I don't know if I can go much lower.  But I guess I should take a look at the datasheets for the chips I'm using and see if they all support fast mode or specify the current for those pins at 20mA.  As for the Atmega I'm using to interface with them I know that doesn't support over 400KHz, but I know most of the pins can handle 20mA including the I2C pins when they're not being used for I2C, so I suspect it can handle it.
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
Note that when I probed this, I had the ground lead attached to the board, and I was probing the end of the cable.  I'm not sure if this matters.

It matters a lot, especially on unshielded cable.

Connect the ground lead to the return ground on the line you're probing.

But remember the clip is connected to mains earth - watch this video:


The first thing I did before I used the scope was watch that video. :)  But this thing is battery powered, so no worries about blowing my scope up.
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
Are you sure the I2C chip is picking up radiated interference, as opposed to conducted interference?

I'm not sure of anything.

Quote

Do they share a common power supply? Common AC power? If this is due to conducted interference being picked up through the power supply, adding ferrites there might be worthwhile.

Yes, a battery.

But I don't believe it's a power supply issue because the noise is there regardless of whether I have the volume turned up. If the speaker is attached, the LEDs glitch, even if the volume is turned way down to where its almost inaudible.  The glitching stopped when I turned the volume down to 0 however.  In that scope capture, the volume was way down, but not off.  I will have to do another test to see how the results differ with the volume all the way off, but I believe I did test that and there was still just as much noise.

Quote
Note that when I probed this, I had the ground lead attached to the board, and I was probing the end of the cable.  I'm not sure if this matters.  It would be a bit more difficult to attach the alligator clip at the end of the cable, but I guess I should try that next and see if there is any difference.  My intuition tells me I won't see much of a difference.
Big difference. Please see: http://www.cbtricks.com/miscellaneous/tech_publications/scope/abcs_of_probes.pdf

Specifically the section on ground lead effects (page 26).

Well, I'll try that and report on what I see.
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
It would severely limit the data rate. Is that a problem?

Considering I2C is already super slow and I need to update something like 32-64 bytes worth of data 60 times a second for smooth animation?  Probably.

Quote
I also considered the possibility of using shielded Cat5.
That would be the first thing I'd try. Transmitting data over long, unshielded cables simply doesn't work.

I'd prefer to avoid that if at all possible.  As I said before, I'd be throwing away money on the cables I already purchased, and the shielded cables are more expensive and have bulky connectors.

Besides, you say it simply doesn't work yet the signal looks fine with the speaker disconnected, and the whole thing works great.  I have to assume that the speaker is only causing a problem because it is in such close proximity to the cable.  So if I can get rid of that noise, it ought to be fine.  And if it does fail in some rare circumstances, well, that's acceptable for this setup.

Quote
Should I add a resistor on series with the shield?  I'd rather not go this route because I'd have to buy new more expensive Cat5 cables and modify the design of one or both boards to add the shielded connectors, and I don't know if the shield would affect the I2C transmission.
As a quick test you could try wrapping the cable in tinfoil. Ground it at one end and see what happens.

I guess if it comes to it, I'll try that.  I don't have any tinfoil right now to test with.
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
Hi!
Let me throw in my 2c...
I2C bus is chip interconnect...something you use on a PCB with maybe 25cm (10 inches) distance...
It is very prone to noise pickup and very sensitive to capacity of the com lines..
What are you trying to do is realm of CAN and RS485 an the likes..
I'm not saying that with enough duct tape (filters, buffers etc..) you will not be able to stabilize your prototype.. If you put enough effort you will but it will be hard to reproduce later and your product will be unreliable...

I spent a year on this thing, so I've got no choice but to make it work with minimal changes.  On the upside, it doesn't matter if the thing isn't 100% reliable under all conditions.  If it works 99% of the time that's good enough.


Quote
And now shortly as to why...

First, as they say devil is in details.. As you can see on your scope trace, your rise time is takes up whole signal.. It should resemble some kind of trapezoid with soft edges.. Slopes are OK, but there is no top.. :o.

What that means is that while signal raises, at one point it will reach threshold to be recognized as HIGH (I know you know all this but bear with me).. at slow speed I2C has NO hysteresis, and at fast it has 0.05V (50mV).. which means as your signal slowly rises, reaches threshold level, and at that point when it is around the right level, even 50mv (and less for slow speed) will make it go up and down the threshold many times, potentially triggering logic transitions... What it will do at that moment nobody knows... By spec it should swallow pulses shorter that  50ns, or not...  That is why you need quick, fast and clean logic transitions..

I understand what you're saying.  It's just that the signal looks pretty clean without that amp on.  And I'm not sure I _can_ lower the value of the pullup resistors by much. I'll have to check and see if all the parts can handle lower values.  The 2K I'm using right now is really close to the 1.56K minimum the I2C spec states for 400KHz operation, but I know at least some of the chips I have support higher speeds so they should be okay with lower pull ups.  But dropping that to 1/5th... 400 ohms... that seems crazy.  At that level I'm afraid it might start acting like a voltage divider and pull the line up from 0V when it's supposed to be low.  Plus that SMT resistor is probably gonna get pretty warm.

Quote
The fact that you build a shortwave radio transmitter that poses as audio amplifier doesn't help..  :o That thing is a EMI nightmare, filter everything, supplies, ground, input, output, sever pipes....

Well, I followed TI's reference design.  They said the filter part was optional, so I took them at their word.  :/
 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us


The rise time obviously isn't great

It's awful. I'd definitely use lower value pullups.

There's no lower limit on I2C pullups except what your devices can pull to ground. The lower the better.

Those TI devices can sink 20mA or more on SDA (see datasheet) so you can go much lower than 2k.

And the AS1115?  I'm also running a MCP3021.  Looking through their datasheets I can't see any clear indication they can sink 20mA.  Though if the AS1115 is to spec for the 1MHz bus it supports, then that at least should be able to handle 20mA.  But the MCP is a 400KHz device.

And the Atmega1284P two wire serial bus electrical characteristics state the minimum pull up assuming 3mA... it's not clear if they're just referring to the minimum to remain in spec for that bus speed or if those pins have some special requirement in I2C mode.
 

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 6631
  • Country: hr
I understand...

If you just have to make it work, you should try active pullup.. It will clean up transition edges, and actually will clean up some of interference..

I also agree, what you see is probably conducted interference.. So you should play with grounding things differently...

And yeah, datasheet said it was OK...  |O I heard that one before.... Believed it too..  :palm:
As I said, that's a 20W AM transmitter... It will spray all kinds of nastiness.. And  it is doing it without any audio input, it's a PWM scheme.. It might be a bit more efficient that older chips, but it does it by keeping switching pulses short when idle... Meaning higher frequency spectra and better coupling to everything around..

But as I said, I would be suspicious about noise into ground injection, so play with the grounding setup...
Take care!
« Last Edit: July 03, 2016, 11:17:19 am by 2N3055 »
 

Offline Monkeh

  • Super Contributor
  • ***
  • Posts: 7992
  • Country: gb
Well, I followed TI's reference design.  They said the filter part was optional, so I took them at their word.  :/

It may well be optional.. if you're not attaching a fricking antenna.

A datasheet is not a step-by-step tutorial on building a device.
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4530
  • Country: au
    • send complaints here
I spent a year on this thing, so I've got no choice but to make it work with minimal changes.
Why does it have to work?

Well, I followed TI's reference design.  They said the filter part was optional, so I took them at their word.  :/
It probably works wonders if you couple it directly to a speaker without filtering.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16648
  • Country: 00
It would severely limit the data rate. Is that a problem?

Considering I2C is already super slow and I need to update something like 32-64 bytes worth of data 60 times a second for smooth animation?  Probably.

64*60*10bits=38400bits.

Back-of-the envelope math suggests you can go a lot lower than 400kbps.

Try the tinfoil wire shield first. Its quick to try it, it might be enough. If it works then you can look for something prettier.

 

Offline StarlordTopic starter

  • Frequent Contributor
  • **
  • Posts: 325
  • Country: us
I spent a year on this thing, so I've got no choice but to make it work with minimal changes.
Why does it have to work?

Because it's a product that I spent the better part of a year working on and have invested thousands of dollars into. I bet everything on it - it's a revision of an earlier design that had its own share of completely different issues but sold well enough to keep me in business, barely - and I've run out of time and money. 

I couldn't even afford to buy this scope, but last week I was in a panic when everything stopped working as soon as I moved it from the workbench, where it had been working fine for the last three months, into the final enclosure.  I spent a day running 50 different tests, mostly code changes since there wasn't much I could think to test electrically without a scope, and when I ran out of ideas for tests I ordered the scope, and the next morning I realized there were a few electrical tests I could try, like different speakers, isolating the speakers from the metal portion of the chassis, and shorter speaker wires.  It was then that I found disconnecting the speakers resolved the issue, and from there I figured out that the speakers I had on the bench worked, and then I discovered those only worked because I hadn't cut their leads short. 

Anyway, it's not like I chose I2C without being certain I could make it work over long runs.  I did my research, and if what should work in theory didn't work in practice, I could always use one of these chips:
http://www.nxp.com/documents/data_sheet/PCA9615.pdf

Of course I hadn't counted on this issue only rearing its ugly head in the 11th hour.  Probably should have invested in the scope sooner, but I was working with an extremely limited budget.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf