Raven RF230 radio excessive wakeup time

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Waking the Raven radio in the contiki webserver I get a timeout error using the 880 microsecond TIME_SLEEP_TO_TRX_OFF from the RF230 data sheet. 1280 us works, 1200 gives occasional timeouts. I don't have an accurate oscope but rs232 debug ticks show that delay_us is accurate to a couple percent.

AVR2002 (RESRaven) uses the 880us delay during the DC test:

tat_status_t tat_leave_sleep_mode( void ){

    //Check if the radio transceiver is actually sleeping.
    if (is_sleeping( ) == false) { return TAT_SUCCESS; }

    hal_set_slptr_low( );
    delay_us( TIME_SLEEP_TO_TRX_OFF );

    tat_status_t leave_sleep_status = TAT_TIMED_OUT;

    //Ensure that the radio transceiver is in the TRX_OFF state.
    if (tat_get_trx_state( ) == TRX_OFF) {
        leave_sleep_status = TAT_SUCCESS;
    }

    return leave_sleep_status;
}

However the calling routine doesn't actually look at the return result.

I'd be surprised if Atmel got the time wrong as fast wake is a selling point for low power radio. From the datasheet I get the impression the wake time is independent of Vcc or clock, but maybe the Raven is peculiar in some respect.

Has anyone else run into this problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the value for F_CPU match the fuse/clock settings?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, -DF_CPU=8000000UL and internal RC osc of 8 MHz with no CKDIV8. I don't think the 1280p can run any faster than this so if anything such errors would lead to longer delays than specified.

delay_us(1280) uses _delay_loop_2 and expands to

+00001823:   E080        LDI     R24,0x00         Load immediate
+00001824:   E09A        LDI     R25,0x0A         Load immediate
+00001825:   9701        SBIW    R24,0x01         Subtract immediate from word
+00001826:   F7F1        BRNE    PC-0x01          Branch if not equal

which is supposed to take 4 clocks per iteration. And it seems, to, enabling :

//    for (i=0;i<20;i++) {
//	    for (j=0;j<1000;j++) {
//          delay_us(1000);
//    	}
//    	printf_P(PSTR("\nTick!"));
//    }

    hal_set_slptr_low();
    delay_us(TIME_SLEEP_TO_TRX_OFF);

    radio_status_t leave_sleep_status = RADIO_TIMED_OUT;

    /* Ensure that the radio transceiver is in the TRX_OFF state. */
    if (radio_get_trx_state() == TRX_OFF){
        leave_sleep_status = RADIO_SUCCESS;
    }

    return leave_sleep_status;
}

gives 20 ticks in 20 seconds before getting the wake timeout.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are some other points:
- Does this effect occur on other boards too (is the Raven with LCD suffered or the stick)?
- Which value do you get when you read back the transceiver state (register TRX_STATUS)?
- Is there a background task messing with the SLP_TR pin ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried two more Ravens, one was the same and the other a little faster but still timing out using 880us.
The point about background tasks messing with SLP_TR is a good one, so I disabled interrupts. Here was the test:

radio_status_t
radio_leave_sleep_mode(void)
{
    int i,j;
    /* Check if the radio transceiver is actually sleeping. */
    if (radio_is_sleeping() == false){
        return RADIO_SUCCESS;
    }

    printf_P(PSTR("10 seconds..."));
    for (i=0;i<10;i++) {
        for (j=0;j<1000;j++) delay_us(1000);
    }
    printf_P(PSTR("Mark!\n"));
    for (j=0;j<1000;j++) delay_us(1000);
    cli();

    hal_set_slptr_low();
    delay_us(TIME_SLEEP_TO_TRX_OFF);

    radio_status_t leave_sleep_status = RADIO_TIMED_OUT;

    /* Ensure that the radio transceiver is in the TRX_OFF state. */
    if (radio_get_trx_state() == TRX_OFF){
        leave_sleep_status = RADIO_SUCCESS;
    }
    sei();
    return leave_sleep_status;
}

with this result using 1200 us (on two boards)

********BOOTING CONTIKI*********
System online.
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
Wake error 67 with trx state 8
10 seconds... Mark!
10 seconds... Mark!
10 seconds... Mark!
10 seconds... Mark!
Wake error 67 with trx state 8
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
10 seconds... Mark!
Wake error 67 with trx state 8
10 seconds... Mark!
Wake error 67 with trx state 8
10 seconds... Mark!
Wake error 67 with trx state 31
10 seconds... Mark!
Wake error 67 with trx state 31

Error 67 is the timeout, state 31 is transitioning, state 8 is awake (TRX_OFF). So the wake is taking ~1200 us with some variance.
The RF230 datasheet says the 880 us wake time

Quote:

Depends on external bypass capacitor at DVDD (1 μF nom) and crystal oscillator setup (CL = 10 pF)
CL = 0.5•(CX+CTRIM+CPAR)

The Raven uses the datasheet values for bypass and CX of 1 μF and 12 pF. The program uses the default of the internal CTRIM disconnected. Vcc is 5 volts from the STK500 board, regulated down to 3.3 volts. Could the ribbon cable be adding parasitic capacitance? Here is the setup (the connections are to Vcc, 0V, TXD1, SCL, SDA):

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This sounds really strange. Does the software calibrate OSCCAL? Maybe the RC oscilator
is tuned away from the 8 MHz, so the number counted in SW says 1200us but thats just a value.
Do you can organize a scope ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well OSCCAL values are in the 0x40 range and the 10 second comparison to my external clock says it is certainly accurate to <10 percent. There may be something odd about OSCCAL, the radio initialize routine disables calibration against the Raven's 32768 Hz clock crystal with the comment

 /** \todo: this screws up if calosc is set to TRUE, find out why? */
  return_value = radio_init(false, NULL, NULL, NULL);

So maybe it's time to find out why :)

Enjoyable as I might find it, it would take too long to fix the power supply in my Tek 465B. Wonder how accurate is the timebase in these newfangled AVR USB scopes?

Can the JTAG ICE mkII give timing information between breakpoints?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, since the UART works, OSCCAL seems not to be the issue.

I had a look at the photo. Do you power the Raven from the STK500 ? What voltage is set?
Is VTARG=3.3V or below ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Dragon reports VTARG=3.2 volts.

Good news, my Tektronix 465B just had a shorted electrolytic on the trigger board +15 so it's working again. Don't know how accurate the calibration is but it agrees closely with the software timings, that my Raven radios take ~1200 us from sleep to TRX_OFF. Here is the test program, output and trace:

    cli();
    
    DDRA|= (1<<PINA0);        //Set PA0 output
    for (j=0;j<30000;j++) {   //Scope loop
        PORTA|= (1<<PINA0);   //Blip it
        delay_us(900);
        PORTA&=~(1<<PINA0);
    }
    //This one's for real

    hal_set_slptr_low();
    delay_us(900);
//  delay_us(TIME_SLEEP_TO_TRX_OFF);

    radio_status_t leave_sleep_status = RADIO_TIMED_OUT;

    /* Ensure that the radio transceiver is in the TRX_OFF state. */
    if (radio_get_trx_state() == TRX_OFF){
        leave_sleep_status = RADIO_SUCCESS;
    }
    sei();
    return leave_sleep_status;
********BOOTING CONTIKI*********
System online.
Wake error 67 with trx state 31
Wake error 67 with trx state 31
Wake error 67 with trx state 31
Wake error 67 with trx state 31
Wake error 67 with trx state 31
Wake error 67 with trx state 31
Wake error 67 with trx state 31
....

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hm, I've still no more idea what is the reason for the wakeup issue. I think it is time to ask Atmel support.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

my Raven radios take ~1200 us from sleep to TRX_OFF.

Quote:

wakeup issue

You mentioned erlier that wakeup time is important and I won't disagree. For the RF modules that I've worked with, 1200us is an admirable time, not an "issue". But surely if advertised and important to you, follow up.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
wakeup issue

:oops: ... I'm not a native speaker, probably I did choose the wrong wording.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I scanned the XTAL_TRIM register from 0x0 to 0xF while looking at the wake time. Didn't see much difference between STK500 power or internal battery power. My reading of the datasheet is that the typical 880 us wake time is when
CL =0.5•(CX+CTRIM+CPAR)= 10 pF
The board CX caps are a nominal 12 pF each, the 880us intercept extrapolates to -12 or CTRIM=-3.6 pF, so all would make sense if the existing CPAR is 11.6 pF. Does that seem a reasonable value for parasitic capacitance?

Here's the code and graph:
[Odd, the freaks server won't accept % d without the space between, even in a code block]

{
u8_t ctrim,j,k;
u16_t delay;
    if (hal_get_bat_low_flag()) {
        printf_P(PSTR("Battery low!\n"));
        hal_clear_bat_low_flag();
    }
    //Wake timing study
    //With XTAL_MODE=0xf0 (internal oscillator), scan XTAL_TRIM from 0 to 0xf (0 to 4.5pF)
    printf_P(PSTR("XTAL_TRIM,WAKE_TIME\n"));
    for (ctrim=0;ctrim<16;ctrim++) {
        hal_register_write(RG_XOSC_CTRL,0xf0+ctrim);
        for (j=0;j<10;j++) {
            delay=1600;                  //Start with long delay
            do {
                delay-=5;                //decrement delay
                hal_set_slptr_high();    //Sleep Radio
                for (k=0;k<10;k++) delay_us(10000);  //for 0.1 second
                hal_set_slptr_low();     //Start wake
                delay_us(delay);         //Exit when wait too short
            } while (radio_get_trx_state()==TRX_OFF);
            sei();
            printf_P(PSTR("[ascii percent]d,[ascii percent]d\n"),ctrim,delay);
            for (k=0;k<100;k++) delay_us(10000);   //wait for full wake and rs232 output
            cli();
        }
    }
}

Attachment(s):