What jitter? What chipset? Are you trying to measure jitter in the transported signal, or in the carrier? The jitter of the RF generator? Then we get to: Long term jitter (drift), cycle to cycle jitter (much more difficult but do-able, depending on the frequency of the signal you are measuring), deterministic jitter (predictable using a network analyzer or even a diff TDR) - the list goes on.
Please try and be more precise as to what it is you are trying to measure.
Cheers
PeteS
How can I measure jitter?
I have to measure Bluetooth jitter, could you please advice the device and method...
Best regards, Boki.
That's what I figure. As you note, Boki has a hard time formulating a decent question. I consider it my teaching duty to nag him ;)
Cheers
PeteS
I'll bet he means jitter on an audio signal transported over Bluetooth but Boki likes to evade asking a question directly.
Graham
There is no "audio signal" transported on Bluetooth.
Boki likes to make cryptic posts, which are best ignored.
Don
Clock jitter. : )
It is using a 48 MHz internal clock; this gives a jitter of ~21ns. Using a 4 MHz internal clock and have a higher jitter of 250 ns.
Please advice the clock jitter measure method.
Best regards, Boki.
Nice smell.
= =
...................
= =
no your business...
There is if you happen to use Bluetooth to do that.
Bluetooth is multi-function.
Graham
I agree on the cryptic posts.
Bluetooth does, in a way, carry audio. It is designed to pass PCM, 8k frame rate - standard telecom style digitised audio. Indeed, I am using bluetooth links with this specifically in mind (amongst other things) in commercial products. Certainly one could pass any arbitrary data on this (SCO) link with decent QoS, but it was designed specifically for audio. The data are retimed at each end, so any jitter analysis would be pretty meaningless from a pure signalling perspective, without knowing the limits of retiming.
Boki does seem to reply further down, but has yet to specify clearly the question :)
Cheers
PeteS
If you are asking how to measure the jitter, how do you know you have the jitter you have stated?
Where, in the system, are you measuring this jitter? Against what reference? On what signal? As I said above, state the problem more clearly, please
Cheers
PeteS
"Don Bowey" wrote
Really? Are you sure about that?
The bluetooth data exchange has some delay, I am confused that is software problem or hardware problem, I consider both
For hardware, I think I have to check jitter, or DSP will request to retry the data communication.
Best regards, Boki
They use something like that for wireless headsets.
Bye. Jasen
"Something like that" gets used for lots of things. But maybe what you are thinking of is something like Bluetooth transporting a digital bit-stream of encoded audio.
Bluetooth has two data channels.
The ACL (Asynchronous) channel is usually operated in a serial port style (especially when used as a cable replacement). The SCO (Synchronous) channel is nominally designed for audio (and meets ISDN data rate specs for that, as well as the normal audio rate PCM highway for both 8 and 16 bit samples).
The data rates and latency are usually dependent on the software stack for ACL. The SCo channel is buried deep to give a guaranteed data rate. I have achieved up to 19k2 fairly simply on the ACL channel. I use the SCO channel for digitised audio with 16 bit samples, and it works just fine. The ACL channel is also active at that time (indeed, it needs to be in most applications as commands such as volume controls are passed over the ACL link).
So Boki needs to tell us which channel he is using.
Cheers
PeteS
Have something to add? Share your thoughts — no account required.
Ask the community — no account required