This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SimpliciTi with PA/LNA

Other Parts Discussed in Thread: SIMPLICITI, CC1190

I am using SimpliciTi in a design with a PA/LNA (cc1190). I would like to know what the suggested best practice is to handle the PA/LNA power switching in context of SimpliciTi. From looking at the SimpliciTi code, it seems that one way to do it is to add code in mrfi_radio.c at the apropriate places to turn on the LNA or PA before the radio is put in RX/TX.

 

is there a higher level where this can be handled instead of messing around in mrfi_radio.c?

 

thanks,

-r

  • This is a question I would also like to see an answer to.  Any TI  SimpliciTI/CC1190 gurus out there willing to chime in?

     

    Thanks,

    BB

  • This question is answered (at least from the CC430 perspective) here http://e2e.ti.com/support/low_power_rf/f/156/t/64838.aspx.  If you are asking for a different radio configuration, please indicate which one.

    Jim

  • Jim,

    Thanks for the very detailed reply.  That seems to clear up what is needed hardware wise.  The question I have, which I believe is what the OP was asking, is that in the mrfi_radio.c module, specifically in the MRFI_Transmit function, that seems to me is where we would drive the LNA_PD line high at the beginning of the function and then back low at the end of the function.  I've searched and it seems that all transmissions go through this function.

    Thanks and regards,

    Barry

  • Barry,

    Yes, all transmissions go through the MRFI_Transmit function.  Setting the LNA_PD signal low at the beginning of this function and high at the end of this function should work fine for transmissions in general but you may end up disabling the receive mode inadvertently.  There are a couple of things that yet need clarifying.

    The RX_ISR is active anytime the radio is in receive mode, i.e. Mrfi_RxModeOn has been called either directly or indirectly.  In these cases, Setting the LNA_PD signal high at the end of the transmission may disable the receiver as the LNA will be powered down.  Probably not what you are looking for.  You should add an else clause to the if statement at the end of MRFI_Transmit to set LNA_PD high only if the radio was not in RX mode when the transmission was started.  This also doesn't manage the question of where to turn on the LNA when Mrfi_RxModeOn is called to enable the receiver.

    One answer would be to put the controls for LNA_PD in Mrfi_RxModeOn and Mrfi_RxModeOff so they are enabled and disabled appropriately but then the LNA would be turned off when you enter MRFI_Transmit as Mrfi_RxModeOff is called to turn off the receive ISR interrupt (actually this is considered a side effect of strobing the radio to IDLE but whose arguing semantics).  This will disable the CCA as described in the other post referenced above.

    So, there are two options as I see them.  Both have advantages and disadvantages.

    1) Create small wrapper functions to all calls which result in transmit operations or turning on/off the receiver from the application level API.  These functions can be made inline or as macros if you really want.  In either case, this is the most portable as it should work for future versions of SimpliciTI without the need for you to dig through code to make your changes once again and also to make sure they should be in the same places and... and... and...  This form is generally considered better from the standpoint of code maintenence and risk avoidance.  This form also will cause the LNA to be powered on longer than required (by a few 10's of micro seconds) thus your power budget will have to manage that.  Unfortunately, the IOCTL function wrapper will need to test what object and action are being done to know whether on not to set/clear the LNA_PD signal.  Another unfortunate effect of this form is that existing code structure i.e. nwk_join, etc. will still be calling the functions directly instead of using your newly created ones.  So it seems that the library will require at least some modifications in the end.

    2) Modify the mrfi_radio.c file to optimize the time the LNA is on.  This of course optimizes for the power budget.  It also causes you a code maintenence nightmare for any updates to the SimpliciTI library as you most likely will not be consulted as to what changes are specific to your existing products so future SimpliTI implementation are, by defalut, compatible with your code set.  Obviously every customer would want this but, alas, reality.

    ////////////////////////////////////////////////////////////////////////////////////////////

    The choice is yours.  If you want choice 2, then I would advise the following

    1) Add code which sets the LNA_PD signal low just before exiting Mrfi_RxModeOn.

    2) Add code which sets the LNA_PD signal high just after entering Mrfi_RxModeOff.

    3) In MRFI_Transmit in the CCA transmit section (we don't need to manage the LNA signal in the forced transmit section) set the LNA_PD signal low just before the radio is strobed into RX mode to begin the CCA test.  This allows the LNA to be active during the time the RSSI signal is validated.

    4) In MRFI_Transmit in the CCA transmit section, set the LNA_PD signal high just after the strobe to TX mode.  Once the radio has been strobed, the CCA test will happen so we can immediately turn off the LNA.  This has the added advantage that there will be no LNA_PD glitch should the CCA test fail and before we turn off the radio to wait for the random backoff period.

    The above steps should optimize the power usage of the PA/LNA to almost as good as being able to bring out the LNA_PD signal on another GDO.  Make sure you write down what you did in your product design documentation so when you come back with an updated version of SimpliciTI, you know what needs to be done to get it operational.

    Note also that this will need to be done for each radio family you are (or could be) using with an LNA/PA.  You don't want to forget this when you upgrade from a CC1110 to a CC430 for example.

    Regards,

    Jim

  • Jim,

    thanks so much for your latest post. very useful and practical info. i have just one follow up question:

     

    in your detailled explanation of the how to implement choice #2 (modify SimpliciTi), you specifically mention how to handle the LNA. could you also please go into detail as to how and where the PA should be powered on and off?

     

    thanks so much,

    -r

  • R,

    As per the description of managing the PA_PD signal in this link http://e2e.ti.com/support/low_power_rf/f/156/t/64838.aspx, it is my position that the PA_PD signal not be managed directly by software but rather via a GDO signal from the radio hardware.  This is mainly due to the timing resolution issues of software.  However, I recognize there are those designs where using the GDO signal is, for whatever reason, not achievable or desirable.  In those cases, the software approach becomes the only resort so I'll describe what I would do in that case.

    Please keep in mind; I consider this to be an UNSATISFACTORY CHOICE and its implementation for production systems SHOULD BE AVOIDED if at all possible.

    Ok, now that my objections have been attended to...

    You should be capable of managing the PA_PD signal entirely within the MRFI_Transmit function.  This function is effectively split into to two as it manages both the forced and CCA versions of transmissions.  This is evident where the if statement checks the mode of operation.

    In the section of code for the forced transmit, I would set low the PA_PD signal just before the line of code which strobes the radio state machine into transmit and then set it high just after the while loop which waits for transmit to be completed.  Since there is no CCA attempt here, there really isn't any timing resolution issues to concern yourself with that would impact the transmission, testing could still be problematic.

    In the CCA section of the code, set the PA_PD signal low immediately AFTER the strobe to transmit.  This is because we need the radio to make the CCA assessment before we turn on the PA.  Also, if you are also implementing the LNA_PD signal, set it high before setting the PA_PD signal low.  i.e. the process would be 1) strobe to TX; 2) set LNA_PD high; 3) set PA_PD low.  Make sure you do this after the TX strobe and not after the RX strobe or you will invalidate the CCA operation effectively making all transmissions forced.

    After the strobe to transmit, there is a test in code to determine if we passed or failed the CCA.  If we passed it, then the transmission is underway.  In this section, set the PA_PD signal high immediately after the while loop waiting for transmission to complete.

    In the section where we failed CCA, set the PA_PD signal high immediately upon entering this section (i.e. right after the opening brace) and before setting the LNA_PD signal low.  This will cause a small glitch on the PA_PD signal when CCA fails but I believe it is the best option.

    From a straight forward sense of coding, this will work for the most part but the issue with timing resolution comes into play when we realize that an ISR could interrupt us at just the wrong time, like after we strobe the radio to TX but before we turn on the PA.  Depending on the latency this ISR produces, you may loose a significant amount of your preamble being sent out over the air.  You can certainly manage this by wrapping the section where the transmit is strobed with critical section macros.  In this case the process would be 1) BSP_ENTER_CRITICAL_SECTION; 2) strobe to TX; 3) set LNA_PD high; 4) set PA_PD low; 5) BSP_EXIT_CRITICAL_SECTION;  Note: the BSP_XXX_CRITICAL_SECTION statements are macros which require a bspIState_t variable type to be passed to them.  Now you have practically eliminated the timing resolution issues, at least with corrupting your preamble.

    Other timing issues still exist which mainly have to do with leaving the PA on for significant lengths of time without any data being transmitted.  This could create problems for you when you enter FCC (or your regions regulatory body) testing process.  Technically this could fail FCC testing as there is no guarantee you wil not be generating signal outside of the intended frequency bands when the PA is on and the radio is not transmitting.  You may be able to mitigate this somewhat with AC coupling in your RF path but there are no guarantees.  Remember, when the PA is on, you have a high gain amplifier which is susceptible to oscillation if not properly driven, i.e. like when the transmitter is off.  You may be able to avoid this by wrapping the entire transmission period and the subsequent PA_PD going high statements in critical section macros but this will lock out interrupts for a significant amount of time if you are using a low baud rate or have significant amounts of data to transmit.  The ability to do this is dependent upon the entire system and what it can afford in this regard.

    The other issue is the small glitch generated when CCA fails.  This can also generate out of band signals which would be an issue for FCC testing as well.

    Finally, you will need to guarantee that any ISR doesn't recursively call the transmit function as that could leave the PA_PD signal in an invalid state and not enable both the LNA and PA at the same time as this can be an invalid state for some.

    As you can see, controlling the PA_PD signal via software becomes truly dependent on what the system in whole is designed to do.  Some systems simply are not compatible with this type of control where others may work quite well.  Because of this, modifying the SimpliciTI library files for PA_PD control should be done on a project by project basis and not on the library base.  It is this reason more than any other that we are having difficulty in determining the most correct approach for generalized support of PA/LNA systems in SimpliciTI.

    Finally, I will re-iterate my position of controlling the PA_PD signal in software is a sub-optimal approach at this time and with respect to the current SimpliciTI library.

    Good luck,

    Jim

     

  • first of all, thanks everyone who contributed to this thread so far. this is all very valuable information.

    i don't want to change the subject too much, but i have a semi-related problem which i would love some input on. as indicated before, i am working on a project which uses a CC40 + CC1190 combination. im getting close to spec raw RF output of +27dB when i do a simple unmodulated carrier signal test. based on this test, i assume that my signal path is ok.
    however, once in SimpliciTi/packet land, i get unacceptable range of only 50m with this system. i am trying to figure out whats going on. i have tried different datarates (915MHz band) but the range issue remains. i would love to use SmartRFStudio and or the packet sniffer to evaluate the RF part of this project, but the tricky thing is that SMartRFStudio doesn't allow me to toggle the pins of the CC430 and therefore i have no control over the PS/LNA state of the CC1190. 
    i assume that SmartRFStudio is uploading some kind of firmware to the CC430 when i do things like continuous RF/TX? is there a way to customize that FW to toggle GPIO pins?
    in a simple test i tried to use MRFI_Rssi() to read the Rssi before and after the LNA was turned on/off, but i don't see a difference in rssi value. i always get readings in the -105dB range.
    i am looking for some suggestions of how i can measure sensitivity of my system, considering it involves a CC1190 which needs to be tuned on/off actively. any suggestions?
    thanks so much,
    -r

  • rl,

    According to the spec sheet (at least for the 6137 version), the GDOx signals are output by default on pins P1.0, P1.1, and P3.6.  The spec sheet also claims the radio is in control of the direction.  Since SmartRF Studio uses GDO0 and GDO2 to do at least some communications between the processor and the radio, that leaves GDO1 available for generation of signals from the radio.  Unfortunately, it appears the ports are set as inputs and not controlled directly by the radio and since SmartRF Studio doesn't provide any means to access the MSP430 registers, we're basically out of luck to generate control signals for the PA/LNA.

    However, I'll assume you are in a lab environment and thus you can toggle the PA/LNA enable signals manually.  In this case, you should be able to jumper the PA_EN signal on the transmitting side to VCC and the LNA_EN signal on the receiving side to VCC and the other pins vice versa.  Then you should be able to run your tests and validate operation.

    I know this is a sub-optimal solution but for the moment, it's all I can think of.  At least it should allow you to make believable measurements for now.

    Regards,

    Jim

     

  • Dear Jim,

    I wrote your SW solution and I am having problems with simpliciTI auto ACKs. (I can't do it with GDOs in my hardware).

    I receive my data sms from the ampified peer at -20dBm. However when they are simpliciTI auto ACKs I receive them 60dB less powefull. The sender does not receive the ACK and it triggers my fordward mechanism.

    Is there anywhere else in the code I can modify to make the simpliciTI auto ack amplified?

    Regards,

    Jorge