Meta Question

FukYou's avatar

Can I capture data with a sound card?

Asked by FukYou (21points) May 25th, 2009

Can my computer’s sound card be used to capture a raw data stream over a wire (Any data, TCP packets, Voice, My cars scantool) ? I mean after all data is “sound” although its square. A data stream should theoretically be able to drive an audio speaker or a lightbulb(although discrete).

With that being said, can a computer’s sound card be used to capture this noise, if physically spliced into the line. Something like this:
———-Mic In——Software————Mic Out
>>>>>>|>>>Data Stream>>>|>>>>
Where the data stream is physically broken and retransmited by the headphones (“sound” output)

or
—-Mic In
>>|>>>>>>>DataStream>>>>>>>>>
Where the line is just spliced into.

Is this even physically possible? If so how would I go about wiring it up (In the second one, dont signals have to be grounded?) How would I go about wiring this up.

Im trying to capture tap my cars cam\crank sensor output. This will be analog obviously.
I am also trying to tap the signal from the Chrysler DRB III to the OBD port to capture the raw data stream

HELP ME FLUTHER!.

Observing members: 0 Composing members: 0

8 Answers

jrpowell's avatar

Maybe something like this could help. It turns your mic-in on the soundcard in into a oscilloscope (sort of).. But I’m not sure how you would convert that into useful data.

FukYou's avatar

Well the scope thing would be tight for my sensors. I can see a glitch in the signal. For the digital, well data has a structure

On On On On Off Off Off On (11110001).....On On Off…...

You could parse the packet if you know its structure (first two bytes represent some value, next 8 bytes represent something else… etc).

Thanks. Mad lurve.

pikipupiba's avatar

Yes, use any recording software to record the data through the card, then change the extension to the proper type. (i use audacity)

The above method could theoretically work if you could find a way to transmit the data as a sound. I would use audacity’s “import raw data” function, then play the sound and record on another system.

FukYou's avatar

Damn I forgot theres a problem. Sound (mic input) is ac, and the data I am trying to reference is DC (Hall effect sensor + OBD II stream). That ocilloscope site says sound cards can only accept AC.

Do you think it would be possible to use a switch inverter to replicate the DC signal as AC (High Low High Low….. = +5volts -5volts +5volts -5volts, or whatever amplitude\voltage the sound card will accept). I believe a switch can be used as an inverter making simple square waves (which is what I want anyway). It would simply switch the polarity of the circut in response to the High Low High Low DC signal. Would the inverter replicate the signal bit by bit (seems theoretically possible, but does anyone know for sure?).

I think a rectifier will work for the transmitting side. Just rectify the output AC sound at the appropriate volume, amplitude, or voltage (same thing, right?).

Can anyone shed some light on this

IchtheosaurusRex's avatar

In general, no. Your sound card has an analog to digital converter that samples the input waveform at 44.1 KHz. Because of the Nyquist limit, you would never be able to capture data with a bitstream exceeding 22.05 kb/s, which is less than half the speed of an old 56K dial-up modem.

If you’re interested in capturing sensor output from your OBD port, get yourself an Autotap. This is a dongle and software that works with a PC or PDA to capture, analyze, and store sensor information. It would be much easier in the long run to use something like this.than try to lash up something with your sound card and write your own software to analyze it.

http://www.autotap.com/

TheWeedMan's avatar

Yup I actually have one of those. I use PCMSCAN w an ELM interface. The program allows custom OBD II commands to be sent. It’s kind of hard to know those commands off hand, unless a scan tool we take output from a scantool. OBD II has a VERY low bitrate. Tools like Autotap do not let you see the protocol and its structure. I might be able to see my current RPM reading, but I want to see the raw data structure, and the command to request that reading (well OBD II sends everything all at once, so there is no “request” for individual sensor data, but you know what I mean)

The thing is I am not trying to analize generic OBD II at all. I am trying to analize the commands from the Chrysler DRB III, the $3000 scantool that dealers keep to themselves. If we could capture simple commands from the DRB and replicate them (cycle ABS or reprogram VIN), we could stop HAVING to go to the dealer for these things (this is a project for dodgeforum.com).

I can not stand that the only way to access my car is via a $3000 tool or through the dealership. There must be a better way.

@IchtheosaurusRex Hmm I have seen 32-bit sound cards with a higher sampling rate than that. Hell there are even 128 bit sound cards out there. Is this limit universal to all DtoA devices, or does it depend on the sampling rate (higher sampling rate = higher bitrate) as I would think

Ohh I couldent log into my account that I just made. I just found it easier to make a new one. Is fluther down?

IchtheosaurusRex's avatar

@TheWeedMan , the Nyquist limit varies with the sampling rate of the ADC. It basically states that, if you want to preserve all of the information in an analog signal, you have to sample it at twice the rate of the highest harmonic frequency it contains. For audible sound, the 44.1 KHz sampling rate conforms to what’s more or less agreed to as the limits of human hearing (22 KHz), although there are some arguments that it isn’t good enough to preserve phase information in multi-channel recordings. That could be the reason a sound card would have a higher sampling rate. I think SACDs have a sampling rate in the megahertz range, as well as a higher bit density.

For reference, audio CDs have a 44.1 KHz sampling rate and 16-bit PCM. That allows for 65,536 discrete variations in volume. Advocates of higher sampling rate point out correctly that at low sound pressure levels, 16-bit ADCs tend to distort, which is why there is dither added to the signal.

That doesn’t have anything to do with your application, but it’s interesting trivia.

And no, Fluther was not down. I believe the moderators objected to the screen name you had originally chosen for yourself, and took your account down.

Shuttle128's avatar

Technically yes. A sound file is simply a vector. If you record the incoming signal (it will most likely be digital) it will register as a vector of amplitudes. There’s a lot that goes into collecting data like this. You need to know the sampling rate, sample size, and some other stuff. You can run the wav file you recorded into MATLAB or many other data analysis programs and convert the audio into a vector of zeros and ones.

Can’t really say much from there. You’d need to know the hardware and possibly encryption protocols used by whatever device you’re trying to capture from.

Ichthy’s right though, sound cards sample at a rate of 44kHz so the data you’d have would be painfully distorted and unlikely useful. I use high rate A/D converters in some experiments here at school that sample on the order of 10 MHz.

Answer this question

Login

or

Join

to answer.
Your answer will be saved while you login or join.

Have a question? Ask Fluther!

What do you know more about?
or
Knowledge Networking @ Fluther