Re: [uracoli-devel] radio_set_state(): how long to wait?

[Joerg Wunsch]

As Axel Wachtler wrote:

> Generally the huge waiting times for low data rates are the issue.
> The Symbol time in BPSK20 is 50us where 8 Symbols are used to
> transfer one byte, which means 400us for one byte, while OQPSK250
> needs 32us to transfer 1 byte.

Yes, that's the first issue here.  The 400 µs per octet are only the
worst case (BPSK-20, on European 868 MHz bands), but could probably be
used as a compile-time constant for 700/800/900 MHz radios anyway.  If
the user has chosen a better datarate (BPSK-40 on North American 915
MHz ISM band, or OQPSK-100/OQPSK-250), the operation simply terminates
earlier.

However, there's a second issue with the current code: while the code
is aware of waiting for approximately one frame transmission
(including the time required for the preamble), this only covers the
basic operation mode of the transceiver.  In case the transceiver is
currently in extended operation mode (in particular, in STATE_TXAUTO
where the entire operation might involve several CSMA-CA backoffs and
frame retries), it will still wait much too short.

I was in error though in my assumption that my timeouts were caused by
the library returning to the configured idle state: this step is not
attempted immediately after the frame download finished, but it is
done by the time the TRX_END interrupt arrives.  In that case,
entering the new state should be possible immediately (or within short
time in case of STATE_RXAUTO, where the ACK transmission must still be
accomplished).

> One idea to this issue is, to add a "bool force_change" parameter to
> radio_set_state(), which does FORCE_TRX_OFF before a state change
> and guarantees to be in the desired sate, when the function exits
> (if force_change = true).

That's already what radio_force_state() is good for. ;-)

> For a non-forced operation radio_set_state() should initialize the
> transaction by writing the command word to the TRX_STATE register
> and return STATE_CHANGE_IN_PROGRESS.

That might be an idea.

I also thought about adding a timeout parameter to the function
itself, so the user can select how long to wait.  But first, this
would change the API, and second, it doesn't help in case of a
library-initiated state change (in order to turn the transceiver into
the configured "idle state").

> Two questions now arises:
>  - How do deal with radio_set_state(SLEEP, 0); ?

Another return value indicating a state transition failure in case the
transceiver was currently busy, i.e. could not turned into TRX_OFF
state before trying to go asleep?

Thinking more about it, I think usr_radio_error() should probably not
called by radio_set_state() itself, because the user always can verify
the result.  usr_radio_error() is only needed for a library-initiated
state transition.

>  - Does  an awake state change should wait until TRX_OFF is reached?

Well, it depends...  For more modern transceivers, the CPU could sleep
until the AWAKE interrupt occurs.  However, I wouldn't want to have
radio_set_state() itself make the CPU sleep.  I've got no real idea
for an ideal solution here.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)