Recording signal from an inductor coil

[inuyasha10121]

Hello everyone,

So I've hit a real stumbling block with this new project I've taken on, given that this is my first "major" dive into analog/AC circuits.  My setup so far is that I have just a basic, hand-wound coil of wire attached to my oscilloscope probe.  I am using this to try and read data that's coming from a wireless source (bits are 5 microseconds in length).  My Rigol does a great job of showing me that I am indeed seeing the data in the coil, but unfortunatly it does not have a fast enough record rate to record all of the data, so now I need to make a DAQ that is capable of recording this info.  My biggest problem is that, since this is an inducting reader, the signal spans -1.5V to 1.5V, and I've never really dealt with anything other than DC signals.  My first thought was to use everyone's favorite, an Arduino, to try and read the signal.  I had no real idea how to hook coil up to the Arduino, but decided  that I should probably test my max read speed, not including sending the data.  Finally breaking down into asm code and setting the analog-read prescaler to 2, I wasn't incredibly confident that it would do what I want.  My next thought was to use a comparator (another component I'm not familiar with) to simply convert the signal into a digital one, which I can then either hookup up to my Arduino or my Altera-DE2 to do the acquisition without having to worry about an ADC MUX to cycle through.  My big problem with that is I have no real idea how to hook up the coil to the comparator.  I first thought to pass it through an amplifier.  First chip that came to mind was a LM324, but I have no idea what to hook up to the V- terminal.  I read that it needs to be negative voltage, which can be generated with a 555 timer charge pump, but negative voltage sourcing is even more alien to me than AC signals.

In short: What would be the best way to go about recording a signal that is being captured using a inductor coil probe?  How would one go about hooking a coil probe up to a comparator(I feel this is probably my best bet), or to an op amp?

If I get some free time later from research, I will try to hunt down a mouse to draw a semi-decent picture of what I'm trying to do.

Sorry for the lack of experience, thanks for your time!

-Jon

[AG6QR]

You don't say which Rigol you have, but even the DS1052E, the least expensive model, records at 1GSa/s, more than fast enough to see bits going by at 5 microseconds in length.  If you can see it on the display screen, the scope has recorded it, so I'm not sure what you mean by, "My Rigol does a great job of showing me that I am indeed seeing the data in the coil, but unfortunately it does not have a fast enough record rate to record all of the data".

If the problem is that the scope doesn't capture data for a long enough time period, make sure you have long memory turned on.  And choose a sample rate sufficiently slow to fit your data into 1 Mpts of memory.  If you need more than a million data points at a shot, then yes, you do have a problem that the scope will have difficulty solving for you.

Building a data recorder is an interesting exercise, and you'll surely learn something from it, but you'll have a hard time building your own Arduino data recorder to outperform your scope.

[inuyasha10121]

I am using the Rigol DS1052E firmware hacked to be a DS1100E.  I try to use the "Record" feature under Utilities, but the minimum time interval is 1ms per frame.  I have my scope set at 20uS time division when I try to do scans, so 240us per snapshot.  As such, I'm missing a ~3 frames of data per interval, because the interval time is too high.  At least, that's what I think is happening.  This is the first time I've tried to do data recording with my Rigol, so it could very well be I'm missing a setting somewhere.  Long memory turned on when I do these scans. 

-Jon

[inuyasha10121]

I actually got a chance to take some screenshots of the data that I'm looking at.  The first screenshot is just showing how long the interval of data I want to be recording is.  The second shot is a zoom in of what the actual data stream looks like.

-Jon

[AG6QR]

I haven't played much with the "record" menu under utilities.  But it's not the only way to record data.

If you can set the scope up to long memory, set the trigger to "single", and capture your frame in a single waveform with sufficient resolution to read it, and sufficient length go hold the whole thing, then you can save it to a USB drive by pushing the "Storage" button and saving the waveform as a CSV data file.

[inuyasha10121]

But what I'm saying is that I can't capture my entire frame with enough resolution to see the individual bits.  if I set my time division to 500us, I can barely make out the bits that are being received.  This is still way too small to capture the almost 1 second data frame.  If I zoom out where I can see the whole frame (say, 100 or 200ms division), and zoom all the way in, it just looks like a big sin wave at 10us division. 

[AG6QR]

And what I'm saying is you don't need to see it on the screen all at once.  Just capture it in a waveform. 

You said that the bits are five microseconds long.  I can see from the screen shot that the entire frame is around 1600 mS long.  If you sample at one point every two microseconds, you'll have 2.5 samples per bit, which should be enough to see the bits.  A million of those samples is a total length of two seconds, longer than your frame length.

Example 3 on page 3-3 in the manual tells how to capture a single shot event.  Once it's captured, you can use the horizontal position and scale knobs to pan and zoom through the captured waveform to see if you've got it in sufficient resolution for your purposes.  Then you can save it as a .csv file to a USB drive using the "storage" menu.

[AG6QR]

I wrote the previous reply while I was at work, away from my scope.  After playing with it a bit, I see that it's not easy to set the sample rate precisely, but I think it's doable.    If you press the Horizontal Menu button, you'll see the sample rate displayed.  When long memory is turned on, in normal Y-T mode, two rates that are in the right ballpark are 873.8kSa or 436.9kSa.  In Roll mode, you have a 512.0kSa rate available, but no triggering, so you'd have to manually push the stop button when your data is complete on the screen.

The idea is, get the full packet of data captured in a waveform, with the Run/Stop button lit up in red and the scope stopped.  The easiest way is probably to be in Y-T mode, with the trigger sweep set in single mode.  Put the trigger point over toward the left side of the screen (about 1.000s) and set it to trigger at the start of your data.

You'll end up with the scope in a stopped mode, and your screen will display something almost as bad as your first posted screen capture, where you can't resolve the bits.  But you can turn the horizontal scale knob to zoom in and resolve a lot more detail than was initially shown on the screen.  And all of that data will be saved in a .csv file when you save the waveform.

[inuyasha10121]

Sorry, I forgot to mention earlier that this is NFC protocol.  Sorry.

My equipment is on campus and I won't be back until tomorrow or the day after, but I'd like to see if I have the basic process down.  Set the trigger level in the range of the main signal (say, 300mV), set the H-scale to 100ms, ensure long memory is on, check to make sure sample rate is around 800kSa, run a scan so that it is captured in full on the display, use the Storage menu to export said .csv data to a flash drive, post processing on a computer (For finding the bits, I plan on writing a little java program that basically goes "Is the number greater than this?  Then its a 1, else its a 0").  If that doesn't work, I'll start looking into circuit options I think, unless there are other scope tricks that might help the data come out with better resolution. 

-Jon

[inuyasha10121]

Well I got back to my bench, hopefully I can devote most of my day to this project.  I decided to do some investigation on the short packets that come before my packet of interest.  Attached are pictures that I got.  I got a really weird result though.  When I scan at 100ms div, and zoom in, I get the sin waves seen below, but when I do my overall scan at 10ms (which, I assumed, would mean my zoom in would have more resolution), I get way less resolution.  No idea what is causing that.  What I'm aiming to see is what is shown in the "Ideal" image attached.  If I do scans at a far out range, it doesn't appear that I see the data with enough resolution to make out the bits (Which I learned actually span ~10us, but high-low or low-high within that area determines if its a 0 or 1, so I actually need 5us resolution.)  Also, I was bored during a colloquium and wrote up a circuit based on a evb149's post.  Does this look like it would work, or did I mess up something?  I was thinking about using a 6V battery power supply regulated to 5V for the source to try and eliminate as much power noise as I can, and then setting the comparator threshold to 900mV to scan for bits.  I don't know of LM339s have a max frequency of operation or not, but if anyone could suggest a better common comparator, I can drop by my local specialty chip supplier and see if hes got any. 

[inuyasha10121]

Finally got around to figuring it out and getting a data dump.  For those that might be interested in taking on something like this in the future, here is what I did to finally acquire the data:
1) Build the level shift circuit described by evb149, and hook the output up to the comparator (If you intend to use my circuit drawing, flip the + and - input on the comparator to get a non-inverted signal.)  I was having some noise issues with my external power supply, so I made a little 7805 circuit with filter caps and a 9V battery to help knock the supply noise out.
2) To the other input, hook up a dual potentiometer setup (one for course adjustment, the other for fine), and use a scope to set the threshold to the bottom peaks.  I also put filter caps on this line, but that was more than was probably needed.  Wire positioning and length did seem to play a role in how accurate the comparator would be/trigger at.
3) Initiate a NFC read/write, with one scope probe hooked to the reading coil and the other to the output of the comparator, to see if the comparator output matches.  Make sure that you go to an appropriate horizontal division (20 us was plenty to see what was going on), and have the trigger set to the coil probe channel.  Ideally, the trigger level should be in the range where it triggers when data comes through, not just the base oscillation wave. 
4) If you signal is small, you can use an Arduino using asm commands to get  a really fast read/storage rate.  As my signal was long (was going to need about 200k scans), I was planning on building a second circuit to dump the binary data into memory chips and then read it back via serial communication.  Implementing serial communication during the actual scan process delays the scan points by too much, even on 115200 baud.
5) I eventually remembered that I had a USBee SX logic analyzer laying around from a long long time ago.  I used that to finally record all of the data and export it as a .bin file.  Currently going through the oh-so-fun process of analyzing the 35MB file.

Hope that helps anyone out who may be trying to get into this sort of project!

-Jon