Y-Box: sending a constant wave

Werner Almesberger werner at almesberger.net
Tue Apr 22 09:28:37 EDT 2014


Felix wrote:
> I've found a thread on ti forum with a very similar question, and guess
> what? You're right! [1]. That time is for the 'auto' model (proprietary
> mode as you said).

Oh, that thread is great, thanks ! This confirms a lot of things:
- the "XOSC OFF" condition is indeed bogus,
- the transceiver can turn around in < 100 us,
- the code example I found is a reference also TI trust (and
  apparently the only "official document" with that sort of data).

> I've also found a page with info about TI BTLE stack and perhaps with
> software[2]. I say "perhaps" because of this:

Yeah, they make it easy to "just say no", don't they ? :)

Alas, what they can pull off on the CC2541 doesn't say much about
the limitations of the CC2543, because there may very well be some
hidden features in the CC2541 that work around such limitations
and that only get activated when switching to the undocumented BLE
mode.

But things are looking good so far:
- the modem does seem to support the modulation we need (GFSK,
  1 Mbps +/- 250 kHz),
- preamble and sync word both look compatible in terms of length,
  content, and use,
- the PN7 whitener appears to be compatible with what BTLE
  specifies,
- the incompatible length field can be ignored when using a fixed
  length,
- turn-around times seem to be short enough, too.

The correctly using the length information in received packets
appears to be the main obstacle so far. I can think of the
following ways to deal with it:

1) set to maximum length, have CPU (8051) interpret the data as it
   arrives, cut off when reaching the real length, calculate CRC
   in software;

2) like 1) but cut off quickly enough (*) that hardware-provided
   CRC will still be valid;

3) set to maximum length, have CPU interpret the data as it
   arrives, tweak length while packet is being received (*) to
   make transfer stop at real end;

4) set to minimum length corresponding to use (that may differ
   depending on whether we're looking for advertizing packets or
   for data), if received packet's length differs, ignore packet
   and use its length for new fixed length, wait for
   retransmission. (**)

(*) that may or may not be possible
(**) depends on how much we can rely on BTLE to not send any other
     packets we'd want to receive before retransmitting the packet
     we've prepared the receiver for.

There is also the possibility of using the Bit Stream Processor
(BSP) from the CPU to do whitening and CRC calculation, but since
the manual says one can only do this when the LLE is not running,
that may not offer any performance benefit over scenario 1).

Anyway, many possibilities for dealing with the length. One of
them ought to work :-)

- Werner



More information about the discussion mailing list


interactive