Y-Box: sending a constant wave

Werner Almesberger werner at almesberger.net
Tue Apr 22 04:07:31 EDT 2014


Felix wrote:
> Vorbis is the only audio codec supported by the webm creators[1].

Perfect, thanks !

> Normally TI documentation tends to be great, but there is almost nothing
> about BTLE support :S The only thing I've found is this extract
> from swru318b documentation:

Yeah, TI do this at times: if they have a vaguely competing product,
they may simply not tell you how to make what you have work in that
way.

> About the round trip time, at least in paper it should match :P

Yes, that 130 us figure is the great mystery. What does it mean ?
My XOSC would of course be running at that time. Is the "OFF" a
typo ? Or are they documenting a weird and, as far as I can tell,
not very relevant corner case ? Also, is this only RX-to-TX or
also TX-to-RX ?

130 us seems rather slow, e.g., the AT86RF231 can go RX->TX in
about 17 us and TX->RX in about 33 us (in basic mode), but there
seems to be a general tendency for recent transceivers to take a
lot of time.

The ancient CC2400 of Ubertooth fame wouldn't have that problem,
with a "PLL lock time" (which I suppose translates roughly to RX/TX
turn-around) of a mere 40 us. Of course, it's "not recomended for
new designs" and the suggested replacement (CC2500) isn't quite in
the same ballpark.

There is an oblique hint in "C254x Proprietary Mode Packet Error
Rate Test (Rev. B)", http://www.ti.com/lit/zip/swrc251

The file swrc251b/source/components/devices/cc254x/hal_rf_proprietary.c
has functions halRfSetTurnaroundRx and halRfSetTurnaroundTx that
calculate what extra delay the chip needs (on top of turning the RF
circuit around) to meet certain turn-around times, and the base
values there are in the order of 60-80 us.

Interestingly, the examples set total turn-around times for RX->TX
and TX->RX of 130 us (meaning the chip gets to twiddle its digits
quite a bit) which happens to be just the mystery value from the
data sheet.

However, all this is for "auto" mode which assumes a weird packet
format that's not compatible with BTLE. E.g., there's a mandatory
header field of 9-10 bits that is guaranteed to derail any attempt
to shoehorn any byte-based protocol into working with this.

The CC2541 (i.e., TI's chip that officially supports BTLE) probably
has a configuration bit somwhere that TI's closed stack uses to set
things to a BTLE-friendly packet format, but that's of course not
documented.

Using "basic" mode for BTLE will cause problems with the length
field, which isn't at the place that "basic" packet format
expects, but it should be possible to tweak things around this
issue.

- Werner



More information about the discussion mailing list


interactive