# Error in sampling rate of laptop sound card?

I've been using the sound card on my laptop -somewhat unconventionally- to record a radio signal from a remote control (433.92 Mhz). The receiver is a small Arduino-type card called MX-05V and is hooked to the sound card through a power supply and jack plug.

The signal is a digital series of on/off pulses that control a home automation mains socket. Se below image for a typical pulse recorded in Audacity at a sampling rate of 176,4 khz.
My aim was to determine the exact pulse length (in microseconds) of the remote control signal by counting the number of samples "N" in each pulse width and dividing this number by the sampling frequency.

My results were somewhat surprising....

For a specific recording, the width "N" of all pulses was constant, no matter how long the recording was, i.e. how many pulses I had recorded.
When I made a new recording of same signal, with the same sampling rate, the pulse width ("N") had changed significantly.
All pulses in the new recording were identical, but they had a new value for the pulse width "N" as compared to the previous recording. A third recording yielded a third pulse width, etc. The maximum variation span was in the order of 10% and appeared to be stochastic, i.e. there was no discernible pattern. It also happens for all the sampling frequencies I've tried, ranging from 44kHz to 384kHz.

I'm convinced that the signal from the remote itself is very stable, i.e. there should be no significant variations in pulse width. My theory is that this is caused by the sound card and/or computer. Does anyone have similar experience?

Grateful for any help.

Br,
Einar
###### Who is Participating?

x

Commented:
Try to make a table of discretisation frequencies and observed pulse lengths. I suspect you will dig the right frequencies quickly. I'd bet top frequency is not polluted, and just go down and drop bad ones.
0

Commented:
i believe the sound card uses a fixed frequency for sampling :
"throughout the years, soundcards have evolved in terms of digital audio sampling rate (starting from 8-bit 11 025 Hz, to 32-bit, 192 kHz that the latest solutions support). "   from :  http://en.wikipedia.org/wiki/Sound_card
0

Commented:
There is some induction in analogue wire. So the adjusted pulse length is in picture attached.
According to widows HCL requirements all sound card clocks are super accurate and ADC/DAC circuitry with low noise, including those included in chipsets, and even more those on video cards for hdmi.
0

Senior EngineerAuthor Commented:
@gheist: Interesting point, but shouldn't the error due to inductance be identical/consistent for all recordings since the wires are the same?
And: Was there supposed to be a picture attached to your post or did you refer to the one in my own post?

@nobus: This is good information, it probably means that the sound card is not the culprit. The remaining candidate is the receiver card & wiring. I'll try to adjust the Vcc; it might have been too low (used 3.3V instead of 5V).

I aslo used a resistor in series with the data pin of the receiver. It had a somewhat low value, so the signal was quite strong. Could the frequency be affected if the signal is close to the saturation level?

Br,
Einar
0

Commented:
>>  Could the frequency be affected if the signal is close to the saturation level?  <<  sure; deformed signals can cause weird things
0

Commented:
Here the picture
0

Senior EngineerAuthor Commented:
@gheist: I agree that your picture is a more correct representation of the absolute pulse width. The reason I posted the question was that the pulse widths differed between recordings, and this should be independent of how you define the pulse width provided you use the same code and equipment each time.

I've also tried to reproduce and transmit the signal with an Arduino and transmitter break-out board.
The original equipment setup included a breadbord and quarter-wave antenna made of wire. Since then, I've stuffed the whole thing into a project box with a proper telescopic antenna for the transmitter and receiver. This had yet another significant effect on the signals. It seems even the ratio between duration of HIGH and LOW states have changed compared to recordings from the old setup.

This finally made me give up and I started tweaking the variuos delays in the code by trial and error until I achieved a reasonable resemblance to the original remote control signal within the accuracy mentioned in my original post. Thankfully, the RC mains sockets aren't that picky and the whole thing works now, but I would prefer to have a little more insight and confidence in the whole thing.

I'll give you all an update if I should find out more.

Br.
Einar
0

Commented:
Might be that sound card supports just couple of discrete clocks, say 44100,48000, but driver emulates couple more, though at quality not suitable for your purpose. Thats just my wild guess....
0

Commented:
you would have tyo look into the specs of that card - and it's chips, in order to find that out
0

Senior EngineerAuthor Commented:
Difficult question to answer, and there might not be a clear-cut solution to such a vague problem Still valuable input was received.
0

Senior EngineerAuthor Commented:
@gheist: Thanks! I'll give it a try
0

Commented:
i started by saying the card uses fixed frequency - but  nothing foer me here it seems
0

Senior EngineerAuthor Commented:
@nobus: Not sure what you mean...?
0

Commented:
I'd say it uses couple of fixed high frequencies
Dividers of top frequency have good chance to be good, rest may be interpolated too badly.
0

Commented:
eist o - what it comes down to, did you look in the help files for how to properly accept  solutions, and grading?
i think you did not - it is a good time now to look at them
0

Senior EngineerAuthor Commented:
Well, thanks to everyone for your contributions. Having found a work-around for the problem (the trial-and-error mentioned earlier) the issue is temporarily settled. As soon as I have time I will have a look at your suggestions for testing the sound card. In the meantime, I will close this thread.

Br,
Einar
0

Commented:
Eisto - not sure where you find any sarcasm ?
stating what is obvious is no sarcasm imo
btw - i'm not looking for points - i have enough, i just try to point you to  correct closing habits
that's all i want to say about that
0

Senior EngineerAuthor Commented:
Ended up manually adjusting pulse lengths,  i.e. duration of on/off signals from Arduino to the transmitter in an iterative manner until it matched the sampled signal from the remote control. I did this for a specific sampling frequency of 384kHz and although the 10% error mentioned earlier still remains, I now have a working  setup and have had some suggestions on how to investigate this further.
0

Commented:
tx for feedback; it is good to know that the sound card can  be used this way!
0

Senior EngineerAuthor Commented:
@nobus: I agree :-). It's a very elegant poor-man's sampling system, but I can't claim credit for the method myself. Du credit should be given to Geoff Johnson. Have a look at:

Safe automated mains sockets
0

Commented:
That's a very interesting project, i like it
0

Senior EngineerAuthor Commented:
Closed with refererende to my last post. The  input from gheist & nobus pointed out a good way forward for investigating this further and thus hopefully find a new explanation for the phenomenon.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.