Can the RF230 radio be damaged with continous transmissions?

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

I've implemented a sort of sneezer mode on the RZRAVEN usb stick that puts the radio into continuous transmission, for testing CCA of other nearby radios.

I'd guess it dissipates somewhere around 17ma*3v3=50 milliwatts at full tx power. I don't really need full power, but wonder if it would be wise to limit the power to under a milliwatt so as not to overheat anything?

#if RF230_CONF_SNEEZER && JACKDAW
/* See A.2 in the datasheet for the sequence needed.
 * This version for RF230 only, hence Jackdaw.
 * A full reset seems not necessary and allows keeping the pan address, etc.
 * for an easy reset back to network mode.
 */
void rf230_start_sneeze(void) {
//write buffer with random data for uniform spectral power
//  hal_set_rst_low();
//  hal_set_slptr_low();
//  delay_us(TIME_RESET);
//  hal_set_rst_high();
    hal_register_write(0x0E, 0x01);
    hal_register_write(0x02, 0x03);
    hal_register_write(0x03, 0x10);
 // hal_register_write(0x08, 0x20+26);    //channel 26
    hal_subregister_write(SR_CCA_MODE,1); //leave channel unchanged

 // hal_register_write(0x05, 0x00);       //output power maximum
    hal_subregister_write(SR_TX_AUTO_CRC_ON, 0);  //clear AUTO_CRC, leave output power unchanged
 
    hal_register_read(0x01);             //should be trx-off state=0x08  
    hal_frame_write(buffer, 127);        //maximum length, random for spectral noise 

    hal_register_write(0x36,0x0F);       //configure continuous TX
    hal_register_write(0x3D,0x00);       //Modulated frame, other options are:
//  hal_register_write(RG_TX_2,0x10);    //CW -2MHz
//  hal_register_write(RG_TX_2,0x80);    //CW -500KHz
//  hal_register_write(RG_TX_2,0xC0);    //CW +500KHz
  
    DDRB  |= 1<<7;                       //Raven USB stick has PB7 connected to the RF230 TST pin.   
    PORTB |= 1<<7;                       //Raise it to enable continuous TX Test Mode.

    hal_register_write(0x02,0x09);       //Set TRX_STATE to PLL_ON
    delay_us(TIME_TRX_OFF_TO_PLL_ACTIVE);
    delay_us(TIME_PLL_LOCK);
    delay_us(TIME_PLL_LOCK);
    hal_register_write(0x02,0x02);       //Set TRX_STATE to TX_START
}
#endif
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have no idea if it could damage it, I cannot see why it would though, if the PCB is designed correctly, then it should be able to dissipate any excess heat. There is no amplifier on that board, so the heat build-up should not be excessive even at full TX.

But the code looks to be useful, this could come in handy for many :)

_________________________________

www.proficnc.com
_________________________________
Go Aussie Go!!!

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

The code implements exactly the procedure from the data sheet, except that
you could poll for PLL_LOCK instead of delay. I saw on some ravens that the
Lock time is longer, depending on the small XTAL they've used in the design.
Therefor it looks that you did experiment with TIME_PLL_LOCK. B.t.w. how large
is this constant ? The max. value for delay_us 255.

The good news, the chip will not get damaged if you stay
in this mode, but you will need to do from time to time a PLL recalibration, you can not stay for hours in this mode.

The RF230 Software Programming Model (AVR2009) states here:

========
If these state changes does not occur during the normal operation of the radio
transceiver frequently every 5 minutes, it is recommended to start it manually
within this period. If the operating conditions of the radio transceiver
(temperature, voltage) are nearly constant, the recalibration period may be
increased.
=======

    /* PHY_CALIBRATE_PLL  */
    trx_bit_write(SR_PLL_DCU_START, 1);
    trx_bit_write(SR_PLL_CF_START, 1);
    delay_us(150); 
    /* TRX_IRQ_PLL_LOCK occurs within this period */

Not sure if this works in this test mode, so you can also
go into TRX_OFF and restart the continous transmission.

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

My bad, I use a custom delay_us, although the delays here are <= 180 us.

//_delay_loop_2(uint16_t count) is 4 CPU cycles per iteration, up to 32 milliseconds at 8MHz
#include 
#define delay_us( us )   ( _delay_loop_2(1+(us*F_CPU)/4000000UL) ) 

I did poll for pll lock and got a 2 second watchdog reset so replaced it with the extra delay. Not sure why, maybe the interrupt routine came through and changed something.

Apart from the radio being in this mode, the rest of the code continues as usual so the next host packet would attempt to transmit and then switch to receive mode, and every 5 minutes would do the frequency recalibration. I have yet to find out what these actions would do; possibly the radio would ignore all further commands until the TST pin is lowered again (that is the first thing I do to exit the mode, then after a "warm reset" it seems to happily go back to a functioning network mode:

             case 'S':
                 if (usbstick_mode.sneeze) {
                    rf230_warm_reset();
                    PRINTF_P(PSTR("Jackdaw now behaving itself.\n\r"));
                    usbstick_mode.sneeze = 0;
                } else {
                    if (rf230_get_txpower()<3)
                        PRINTF_P(PSTR("*****WARNING Radio may overheat in this mode*******\n\r"));
                    rf230_start_sneeze();
                    PRINTF_P(PSTR("********Jackdaw is continuously broadcasting*******\n\r"));
                    PRINTF_P(PSTR("************on channel %2d with power 
%2d************\n\r"),rf230_get_channel(),rf230_get_txpower());
                    PRINTF_P(PSTR("************Press any key to stop******************\n\r"));
                    watchdog_periodic();
                    usbstick_mode.sneeze = 1;
                }
                break;
/*---------------------------------------------------------------------------*/
/* Used to reinitialize radio parameters without losing pan and mac address, channel, power, etc. */
void rf230_warm_reset(void) {
  PORTB &= ~(1<<7);
  DDRB  &= ~(1<<7);

  hal_register_write(RG_IRQ_MASK, RF230_SUPPORTED_INTERRUPT_MASK);

  /* Set up number of automatic retries 0-15 (0 implies PLL_ON sends instead of the extended TX_ARET mode */
  hal_subregister_write(SR_MAX_FRAME_RETRIES, RF230_CONF_AUTORETRIES );

/* Set up carrier sense/clear channel assesment parameters for extended operating mode */
  hal_subregister_write(SR_MAX_CSMA_RETRIES, 5 );//highest allowed retries
  hal_register_write(RG_CSMA_BE, 0x80);       //min backoff exponent 0, max 8 (highest allowed)
  hal_register_write(RG_CSMA_SEED_0,hal_register_read(RG_PHY_RSSI) );//upper two RSSI reg bits RND_VALUE are random in rf231
// hal_register_write(CSMA_SEED_1,42 );

  /* CCA Mode Mode 1=Energy above threshold  2=Carrier sense only  3=Both 0=Either (RF231 only) */
//hal_subregister_write(SR_CCA_MODE,1);  //1 is the power-on default

  /* Carrier sense threshold (not implemented in RF230 or RF231) */
// hal_subregister_write(SR_CCA_CS_THRES,1);

  /* CCA energy threshold = -91dB + 2*SR_CCA_ED_THRESH. Reset defaults to -77dB */
  /* Use RF230 base of -91;  RF231 base is -90 according to datasheet */
#if RF230_CONF_CCA_THRES < -91
#warning RF230_CONF_CCA_THRES below hardware limit, setting to -91dBm
  hal_subregister_write(SR_CCA_ED_THRES,0);
#elif RF230_CONF_CCA_THRES > -61
#warning RF230_CONF_CCA_THRES above hardware limit, setting to -61dBm
  hal_subregister_write(SR_CCA_ED_THRES,15);
#else
  hal_subregister_write(SR_CCA_ED_THRES,(RF230_CONF_CCA_THRES+91)/2);
#endif

  /* Use automatic CRC unless manual is specified */
#if RF230_CONF_CHECKSUM
  hal_subregister_write(SR_TX_AUTO_CRC_ON, 0);
#else
  hal_subregister_write(SR_TX_AUTO_CRC_ON, 1);
#endif

/* Limit tx power for testing miniature Raven mesh */
#ifdef RF230_MAX_TX_POWER
  set_txpower(RF230_MAX_TX_POWER);  //0=3dbm 15=-17.2dbm
#endif
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

... then after a "warm reset" it seems to happily go back to a
functioning network mode:

Thats exactly what the data sheet requests, step (16) TST low, step (17) reset.

If you do not want to reset the chip after sneezing/jamming, how about
downloading a long frame and permanently start a transmission (e.g. send back to back). The only difference with this method is, that with each TX_START a preamble is sent.

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

I'll try that too, but want to have the certainty that if another mote makes a transmission it's due to CCA failure, and not slipping in during a short pause. Any idea how long the back-to-back gap would be?

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

Just an update, when the RF230 is in continuous transmission mode any SPI access seems to hang the host (e.g. reading the RSSI register).

I suspect my hang when I tested polling for the PLL lock was due to an untimely router advertisement coming from the PC interface that attempted to use the radio. Commenting out the poll and increasing the delay then fortuitously worked.

If you block radio access in sneezer mode you can easily switch back to the previous network configuration by lowering the TST pin.

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

Quote:

Just an update, when the RF230 is in continuous transmission mode any SPI access seems to hang the host (e.g. reading the RSSI register).

If the RF230 continously transmits, then the Receiver is off, so therefore there can't be any RSSI update. The transceiver is either in RX or TX state, never in both at the same time.

I never enabled IRQs in this mode, maybe some underrun IRQs happen, but they
have no meaningfull information anyway , so you can turn the IRQs off.

The SPI is not blocked, you should be able to read at least PART_NUM e.t.c.

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

Truly continuous transmissions in the ISM bands is probably a violation of regulatory rules.

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

> Truly continuous transmissions in the ISM bands is probably a violation of
> regulatory rules.

Thats a good point, the intention of this mode is to enable measurements of
spectrum masks, antenna characteristics, ... e.g. for device approval,
production test or RF development. If the mode is used for debugging of
network scenarios it should be used with a high amount of carefulness.