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 _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
