Proprietary Knowledge Base

    Publish
     
      • EZRadioPro Auto Frequency Hopping #1 – What is it good / not good for?

        zopapp | 01/22/2016 | 09:28 AM

        The auto frequency hopping feature on EZRadioPro (Si4x6x) devices is an Rx feature only where the receiver autonomously scans through a predefined channel table for the expected packet.

         

        It is primarily meant for applications where the transmitter changes its frequency channel between packets but stays on the currently selected channel for the duration of the whole packet transmission. In auto frequency hopping mode the receiver has no prior knowledge where to expect the next packet so it duly keeps scanning all the possible channels until it finally “finds” the signal. This mode of frequency hopping operation may be referred to as asynchronous hopping as the Tx and Rx nodes have no knowledge which frequency channel the other is staying at at any given time.

         

        Typically in such asynchronous hopping applications the Tx node has to transmit a relatively long preamble to allow the Rx node enough time to find the right frequency channel.

        To sum it up what the auto frequency hopping feature supports is asynchronous hopping operation in the receive node.

         

        Now, if the receiver knows at what frequency and at what point in time the Tx will transmit there is no need for it to scan a wide range of frequency channels. It “simply” has to be on the right channel at the right time to receive the packet. This mode of frequency hopping operation may be referred to as synchronous hopping as the Tx and Rx nodes are moving together both in frequency and time.

         

        Now, the auto frequency hopping feature does not support synchronous frequency hopping in neither the Tx nor the Rx node.

         

        This does not mean however, that synchronous hopping systems cannot be built with EZRadioPro devices. It is, however the task of the host MCU to direct the Tx and Rx nodes to the right frequency at the right time. It is important to note, however that the auto frequency hopping feature is of no help whatsoever in synchronous hopping applications.

         

        This article is part of a series that discusses various aspects of auto frequency hopping. Find the links to the other articles below.

         

        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-1-What-is-it-good-not-good-for/ta-p/160890
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-2-Detection-of-the-absence-of/ta-p/161033
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-3-Timing/ta-p/161381
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-4-WDS-configuration-State/ta-p/161390
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-5-Frequency-Table/ta-p/161394
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-6-Debug-and-verification/ta-p/161408

      • EZRadioPro Auto Frequency Hopping #2 – Detection of the absence of a signal

        zopapp | 01/22/2016 | 09:27 AM

        As the receiver scans through a number of “empty” channels in auto frequency hop mode until it finally finds the desired signal it is apparent that it spends most of its time on determining the absence of a valid signal. (Let’s call this mechanism no signal detection!)


        The characteristics of determining the absence of a signal therefore has a significant impact on overall system performance. The two most important parameters are how fast and how accurately a no signal condition is detected. Typically these two requirements go against each other.

         

        This article goes through the mechanisms through which no signal detection is acquired and discusses the characteristics of each one.

         

        (1) No signal detection with the lack of preamble detection (LoP detection). This method simply asserts a no signal condition if a valid preamble is NOT detected with a given time period from the start of the receive process. Form the nature of method it is self-evident that the receiver has to stay at least as much time on any one channel as it needs for preamble detection. As an example if the demodulator has to see at least 40 bits of preamble for a successful detection and the observation time period expires after 30 bit times it may happen that decision prematurely yields a no signal condition.

         

        The minimum time the receiver needs for preamble detection depends on the configuration of preamble detection threshold and the configuration of the PLL feedback AFC (Automatic Frequency Control). With the recommended 20 bit preamble detection threshold the minimum required preamble length is 32 bits with the PLL feedback AFC being disabled and 40 bits with the PLL feedback AFC being enabled. It follows than that the receiver has to stay at least this much time on each channel to be able to acquire no signal detection. The accuracy of this method matches the accuracy of signal (preamble) detection therefore there will not be any sensitivity degradation with this method.

         

        (2) No signal detection with RSSI measurement. This method asserts a no signal condition if the current RSSI measurement does not exceed the RSSI threshold value before an RSSI timeout period. Compared to the 1st method this one clearly trades off detection accuracy (ultimately sensitivity and immunity) to detection time. Dependent on the averaging configuration (MODEM_RSSI_CONTROL) of the current RSSI measurement the demodulator needs to observe the signal from a fraction of a bit time (only revC2/A2) to several bit times for a valid RSSI measurement. The more averaging is applied in the measurement path the more accurate the measurement becomes. The most crucial point of this method is selecting an appropriate RSSI threshold level as it will ultimately limit overall sensitivity (i.e., valid signals that measure less RSSI will go unnoticed) and will have a great effect on the false signal detection performance (i.e., noise detected as a valid signal). This latter one could ultimately lead to packet losses as the receiver may “waste” too much time on a “false detect” channel to arrive to the wanted channel in time for a detection.

         

        So here is the ultimate trade-off: the higher the threshold the less the sensitivity, the lower the threshold the worse the false detect performance. Both might not be achieved at the same time. One has to assess the cost of false detections and degraded sensitivity to adjust the threshold to one’s specific needs. This process may as well take some experimenting on a lab bench. As a starting point have a look at the following article that elaborates on RSSI reading accuracy: http://community.silabs.com/t5/Wireless-Knowledge-Base/RSSI-accuarcy-on-SI4x6x/ta-p/127172.

         

        Another rather important aspect of this method is that the RSSI measurement cannot distinguish between desired and undesired signals in the channel. This means that detection will occur also on signals that are not meant for the receiver but are in the same channel. The implication of such detection is similar to a “false detection’s” on noise, i.e., the receiver will stay on the channel looking for preamble and may waste too much time to arrive to the wanted channel in time. Ultimately this behavior can cause a PER floor in the link. This behavior constitutes to poor co-channel rejection performance.

         

        With this method signal detection is still done via preamble detection.

         

        (3) No signal detection with the DSA (Digital Signal Arrival) detector. This option is only available on C2/A2 versions of the ICs and can only be applied to (G)FSK modulated signals (i.e., not OOK). The DSA is a feature block in the demodulator that measures some physical parameters of the signal being received and asserts valid signal / no signal conditions based on the results. This block as opposed to working on the demodulated data stream (i.e., at the bit rate as method (1) does) is part of the demodulator itself so is inherently much faster. Typically the DSA only has to observe the signal for a period of two bit times to assert a no signal condition which is a huge improvement on the 32/40 bit times method (1) is capable of. Upon the assertion of a no signal condition the DSA can trigger the receiver’s state machine for hopping to the next channel automatically. How this is done technically is that whenever the DSA block is enabled the PREAMBLE_TIMEOT signal is replaced by the DSA’s no signal detection signal internally. As you can see there is a massive improvement in no signal detection time compared to method (1). How about the accuracy? Engaging the DSA block may result in some sensitivity loss (from a faction of a dB with low FSK modulation indices (<=1) to a few dB with higher modulation indices) compared to method (1). The AFC tracking range of this method matches method (1) and (2) when the PLL feedback AFC is not engaged there. All in all this method nearly matches the performance of method (1), the speed of method (2) at a price of some restrictions on the modulation format (only (G)FSK with preferably a modulation index <= 2).

         

        This article is part of a series that discusses various aspects of auto frequency hopping. Find the links to the other articles below.

         

        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-1-What-is-it-good-not-good-for/ta-p/160890
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-2-Detection-of-the-absence-of/ta-p/161033
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-3-Timing/ta-p/161381
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-4-WDS-configuration-State/ta-p/161390
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-5-Frequency-Table/ta-p/161394
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-6-Debug-and-verification/ta-p/161408

      • EZRadioPro Auto Frequency Hopping #3 – Timing

        zopapp | 01/22/2016 | 09:26 AM

        In the previous article of this series the different schemes are discussed that qualify the absence of a signal and their performances are elaborated on. This article explains how long a preamble is required at the Tx side for each of the different schemes to work properly.


        In a way the length of the required preamble is also a crucial performance measure as it directly relates to Tx energy consumption.


        (At the time of writing this article AN633 chapter 10.13 captures some of these calculations and mechanisms wrongly, so go by this article!)


        The number of preamble bits required at the Tx side is affected by the following parameters:


        (1) The number of channels in the frequency hopping system. Let’s refer to this as #Channel.
        (2) The time the receiver needs for no signal detection. Let’s refer to this as T_NoSignal.
        (3) The time the receiver needs for signal detection. Let’s refer to this as T_Signal.
        (4) The time the receiver needs for hopping to the next channel. Let’s refer to this as T_Hop. (This is the time that elapses from initiating a hop operation until the receiver starts receiving on the next channel. This time includes amongst others the PLL synthesizer settling time.)


        On top of above input parameters there is another one that has a bearing on the final calculations. This one is related to Rx internal operation. Whenever the receiver has been settled for reception on a particular channel (that is to say all the Rx chain circuitry is up and running and fully settled) there is still some propagation delay until the signal becomes available for processing in the demodulator. (This delay is mostly picked up in the channel filter). It is important to understand that signal detection and no detection times must start ticking from the time instant the signal has reached the demodulator. In other words for a successful signal detection / no detection the receiver must dwell at least the detection / no detection time + the aforementioned propagation delay worth of time on any one channel.

         

        (5) Propagation delay through the Rx chain. Let’s refer to this as T_PropDel.

         

        For calculating the minimum required preamble length let’s consider the worst case scenario from the receiver’s point of view. Let’s suppose that the receiver just hops onto the right channel when the transmission starts but juts misses detection and duly hops on. In such a scenario it will have to hop through all the frequencies and arrive back to the same channel just in time to still be able to perform signal detection.


        This worst case thinking constitutes to a minimum preamble length calculation where the receiver does one no signal detection on each channel and one signal detection on the right channel.


        T_PreambleMin = #Channel * (T_Hop + T_PropDel + T_NoSignal) + T_Signal


        Now, that we have a general formula we “just” need to give values to the parameters. #Channel is parameter that is left for the system engineers. T_hop and T_PropDel are RFIC related parameters and have the same values regardless of signal detection schemes.


        T_hop = 138 us on revB1 silicon
        T_hop = 125 us in revC2/A2 silicon
        T_PropDel = 4 Ts, where Ts is the symbol time**


        ** Note: The 4Ts propagation delay is a worst case number. Typically it is ~ 3.5 Tb and is getting less with increasing modulation indices. So inherently there is some margin built into this number.


        The remaining two parameters are dependent on the detection scheme. Below table summarizes their values for all the three schemes discussed in the previous article.

         

        PLL FB AFC EnabledLack of Preamble DetectionRSSI measurementDSA detection
        No signal detection time [Tb]404**2
        Signal detection time [Tb]404016

         

        PLL FB AFC DisabledLack of Preamble DetectionRSSI measurementDSA detection
        No signal detection time [Tb]324**2
        Signal detection time [Tb]323216

         ** On DSA detection no signal detection time see also

         

         A few notes to the numbers in the table

         

        • The 4Tb no signal detection time at the RSSI measurement method may seem a somewhat arbitrarily number. However, it fits well into the RSSI timeout granularity which also happens to be one nibble and it also has the advantage that the RSSI measurement’s standard deviation on noise (i.e., no signal condition) will be half as much as on readings taken over 1Tb. (Note, that this averaging is not set automatically to this value from WDS, it must be set separately!)
        • As signal detection is still based on preamble detection at the RSSI measurement method the detection times will match the preamble detection times.
        • At the DSA detection the no signal / signal detection times are rather asymmetric. Even though the core detection algorithm is the same in both cases at signal detection it is performed more than once (4 times), plus at detection there is an additional 8Tb given for AFC settling.
        • The preamble detection numbers (40 and 32 Tb dependent on PLL FB AFC configuration) have ~3Tb margins built into them. This means that if you are really squeezed for preamble length minimization you may deduct this 3 Tb from the numbers. If you do this, however do evaluate your solution thoroughly! Some hints on how to do this can be found here: Not yet released KB.

        As an example consider the following input parameters:


        #Channel = 5
        DR = 9.6 kbps


        Below table summarizes the performance (including Rx) of such a system with the various no signal detection schemes.

         

         LoP Detection** RSSI measurement DSA detection 
        5 channels  9.6 kbps DRPLL FB AFC EnabledPLL FB AFC DisabledPLL FB AFC EnabledPLL FB AFC DisabledPLL FB AFC EnabledPLL FB AFC Disabled
        Min Tx Pr length [Tb]26621886785252
        Sensitivity degradation [dB]000 to 20 to 20.5 to 20.5 to 2
        AFC rangeAN734 3.6 blue traceAN734 3.6 red traceAN734 3.6 blue traceAN734 3.6 red traceAN734 3.6 green traceclose to AN734 3.6 red trace
        Co-channel rejection [dB]-10 to 0-10 to 0very poorvery poor-13 to -3-13 to -3
        IC rev supportB1/C2/A2B1/C2/A2B1/C2/A2B1/C2/A2C2/A2C2/A2

        ** LoP: Lack of Preamble

         

        Where parameters form a range they represent values over increasing modulation indexes starting from 1. This practically means that co-channel rejection becomes better with increasing indices, sensitivity degradation, however becomes worse at higher indices.


        Above table will help you take your no detection scheme pick. Generally speaking for ultimate Rx performance the best choice is lack of preamble detection, for shortest preamble the best pick is DSA detection, and finally RSSI measurement could be a viable option if you are on revB1 silicon but you are squeezed for preamble length reduction.


        Note that as there is an absolute timing value term (as opposed to Tb relative times) in the calculation of the required minimum preamble length (T_Hop) the preamble length “gain” going from LoP detection to the other schemes will vary with DR. The more dominant the absolute timing term in the equation becomes the less the “gain” will be. Below graph captures this effect in plotting the “gain” versus DR in a 5 channel auto frequency hopping system.

         

        pr_length_vs_DR_fraph.png

         

        An example of what this graph tells us: at 1 kbps DR DSA detection requires ~ 22% of the preamble length used for LoP detection (with the PLL FB AFC enabled), while at 500 kbps this measure goes up to 60%. Note that these graphs will change slightly with the number of channels used, so do plot yours should you need this data for different than 5 channels!


        As a side note here it is worthwhile mentioning that there exists another mechanism for making the receiver hop (albeit not automatically). This mechanism is referred to as manual frequency hopping. All it does is that it restarts the receiver on another frequency channel. Refer to API command RX_HOP for more details on this operation. It will not, however initiate any autonomous hopping upon no signal detections; all that will have to be handled in the host MCU. Why going for all the trouble calling up these scheme then? The answer is that this mechanism has a shorter T_hop time (as some of the parameters needed for setting the new frequency are passed to the chip as opposed to it having to calculate them). T_hop time with the Rx_HOP command is typically 82 us on revC2/A2 variants.

         

        This article is part of a series that discusses various aspects of auto frequency hopping. Find the links to the other articles below.

         

        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-1-What-is-it-good-not-good-for/ta-p/160890
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-2-Detection-of-the-absence-of/ta-p/161033
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-3-Timing/ta-p/161381
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-4-WDS-configuration-State/ta-p/161390
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-5-Frequency-Table/ta-p/161394
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-6-Debug-and-verification/ta-p/161408

         

      • EZRadioPro Auto Frequency Hopping #4 – WDS configuration: State machine and timeout

        zopapp | 01/22/2016 | 09:12 AM

        The previous articles in this series explained the various mechanisms and their performances auto frequency hopping can be achieved with.


        This article elaborates on the configuration of the various no signal detection schemes discussing the Rx state machine options and the timeout parameters for the LoP (Lack of Preamble) and RSSI measurement schemes.


        (1) Rx state machine in auto frequency hopping mode


        On the Frequency hop tab in WDS in the Auto frequency hop Rx project there are 5 options for hopping (even though we only discussed 3 before) and the DSA is not even mentioned so some explanation is due.


        The reason that we have more options than no signal detection mechanisms is that we provide for “backup” no signal detection mechanism in case the primary algorithm decides falsely on detection. With such backup mechanisms we can make the receiver “hop on” as opposed to checking (or getting stuck on) the same channel again. (These mechanisms are readily available in the form of preamble and sync word detections; we can simply opt for hopping if they are not detected.)


        The backup no signal detections that can optionally make the receiver hop for the various primary no signal detection schemes are listed below:


        Lack of preamble detection: (1) invalid sync word detection
        RSSI measurement: (1) lack of preamble detection and (2) invalid sync word detection
        DSA detection: (1) invalid sync word detection


        The combinations of these events make up the list in WDS.

         

        WDS_auto_hop_state_machine.jpg

         

        DSA detection, however does not explicitly appear in the list. The reason for this is that when the DSA is enabled it’s no signal detection event will automatically replace the preamble timeout event internally. From the hopping mechanism's point of view it does not matter what exactly the source of the preamble timeout event is, which implies that the schemes where the primary no signal detection is preamble timeout will be “reused” if the DSA is enabled (shown below).

         

        WDS_auto_hop_DSA_enable.jpg


        For the sake of clarity find the Rx state machine operation for all combinations below:

         

        (1) Hop on preamble timeout

        state_machine_with_PrTO.jpg

        (2) Hop on RSSI timeout or preamble timeout

        state_machine_with_RSSITO_and_InvPr.jpg

        (3) Hop on preamble timeout or invalid sync word

        state_machine_with_PrTO_and_InvSync.jpg

        (4) Hop on RSSI timeout or preamble timeout or invalid sync word

        state_machine_with_RSSITO_and_InvPr_and_InvSync.jpg

         

        (2)  Timeout configurations for the LoP and RSSI measurement schemes

         

        Both the LoP and RSSI measurement no signal detection algorithms need a timeout parameter. Both can be set in the red highlighted region on below WDS screenshot.

         

        WDS_auto_hop_TO_configuration.jpg


        For both of these schemes there is a maximum time needed for the receiver to make a good decision. Obviously the timeout interval must be long enough to incorporate this time period. The important consideration here is that these maximum times (captured in the tables in the Timing article) are valid from the demodulator’s perspective. As discussed in the Timing chapter by the time the signal reaches the demodulator it suffers a propagation delay through the Rx chain (T_prop_del). So to ensure the demodulator can indeed “see” the signal for the defined maximum time period the receiver must dwell T_prop_delay + T no_signal amount of time on any one channel. Now, the timeout parameters (both preamble and RSSI) do measure the whole time the receiver dwells on any one channel therefore they shall be set to T_TO = T_PropDelay + T_NoSignal, where T_TO stands for T_TimeOut.


        For example with the LoP detection scheme (when the PLL FB AFC is enabled) the demodulator has to see 40 bits of preamble for a good decision therefore the preamble timeout parameter shall be set to T_TO_pr = 40 Tb + 4 Tb = 44 Tb (11 nibble Tb).


        Similarly with RSSI measurement detection with averaging the result over 4Tb the RSSI timeout parameter shall be set to T_TO_rssi = 4Tb + 4Tb = 8 Tb (2 nibble Tb).

         

        This article is part of a series that discusses various aspects of auto frequency hopping. Find the links to the other articles below.

         

        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-1-What-is-it-good-not-good-for/ta-p/160890
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-2-Detection-of-the-absence-of/ta-p/161033
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-3-Timing/ta-p/161381
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-4-WDS-configuration-State/ta-p/161390
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-5-Frequency-Table/ta-p/161394
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-6-Debug-and-verification/ta-p/161408

         

      • EZRadioPro Auto Frequency Hopping #5 – Frequency Table Considerations

        zopapp | 01/22/2016 | 09:12 AM

        This article explains how to set up the channel plan for auto frequency hopping in WDS and also elaborates on an important concept regarding image reception.

         

        The frequency table will start at a base frequency defined on the “Frequency and Power” tab. The channel separation between adjacent channels is also set on this tab at entry “Channel spacing”. Below example configures a system with a base frequency of 916 MHz and a channel separation value of 250 kHz.

        WDS_channel_spacing.jpg

        You can build up the frequency table itself on the “Frequency hop” tab.  If you wish you can leave out channels from the table as indicated at the end of this example configuration.

         

        hopt_table.png

        Once started the receiver will duly scan the channels starting from 0 in an ascending order. You could ask the question: Can I start at any of the channels? My answer would be there is no point in doing that as you will not have any prior knowledge where the Tx is. If you do, you don’t need the auto frequency hopping feature.


        After a packet has been received hopping continuous from the reception channel.


        Now, let’s turn to the more interesting part! There is one phenomenon that may place a restriction on channel separation selection in a given system implementation. The phenomenon is reception (albeit much attenuated) on the image frequency. Whenever the Rx is tuned to a particular wanted frequency there will still be reception on its image frequency that is the mirrored wanted frequency on the Intermediate Frequency (IF). More on this phenomenon you can read in AN790:

        http://www.silabs.com/Support%20Documents/TechnicalDocs/AN790.pdf

         


        It may happen so, that at high receiver input power level a signal on the image frequency does get demodulated (even though we would only like to demodulate the signal in the wanted channel). Now, on the image frequency bits will get demodulated inverted, but this does not stop a preamble signal from looking exactly the same from the demodulator’s perspective. (I.e., a 101010 sequence will look exactly the same as a 0101010 sequence shifted by one bit).

        Therefore the receiver will detect a valid signal (with preamble detection / DSA detection / RSSI measurement) on the image frequency and it will only realize that the signal is not a desired one when it cannot detect a valid sync word. (As the inverted sync word is most likely not the same as the original.)

         

        Now, imagine we have an auto hopping channel plan where the image of a wanted channel also falls onto a valid channel entry in the hopping table. Suppose that the input power to the receiver is high enough for image reception and the image channel does get checked first. The receiver will detect the signal on the image and will stay there until it concludes that the sync word was not valid. Dependent on the sate machine configuration the receiver may start hopping again, but the packet will already be lost.


        To sum it up don’t use channel configurations where one channel falls onto the image reception region of another channel.


        The image frequency is two times the IF frequency. You can check the IF of your configuration by reading this article: http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadio-EZRadioPro-IF-frequencies/ta-p/160892

         

        Example:
        XO = 30 MHz
        Channel spacing = 1 MHz
        Rx BW = 300 kHz


        From above:
        IF = -468.75 kHz
        Image Frequency = -937.5 kHz


        The negative sign indicates that the IF and Image frequencies are below the wanted channel. The image reception band will be an Rx BW wide region centered on the image frequency: from -1087.5 kHz to -787.5 kHz. This band straddles the center frequency of the channel that is 1 MHz below the wanted channel. With this overlap we run the risk of bumping into the phenomenon described above.


        If you encounter such a situation you can either change your channel spacing in the hop table or alternatively select an XO with a different frequency.

         

        This article is part of a series that discusses various aspects of auto frequency hopping. Find the links to the other articles below.

         

        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-1-What-is-it-good-not-good-for/ta-p/160890
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-2-Detection-of-the-absence-of/ta-p/161033
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-3-Timing/ta-p/161381
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-4-WDS-configuration-State/ta-p/161390
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-5-Frequency-Table/ta-p/161394
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-6-Debug-and-verification/ta-p/161408

         

      • EZRadioPro Auto Frequency Hopping #6 – Debug and verification

        zopapp | 01/22/2016 | 09:10 AM

        Once an auto Rx frequency hopping configuration has been devised and loaded onto the chip there are a few relatively easy tests to verify functionality and performance.


        The article goes through 3 different test methods that check for (Test#1) functionality, (Test#2) preamble margin on signal detection and (Test#3) timeout configuration margin on no signal detection.


        The easiest way to test functionality is transmitting to the receiver and observe some of diagnostic signals on GPIOs. The transmitter may as well be another EZRadioPro node running a Custom packet Tx project from WDS. Make sure the length of the preamble at the Tx side is set to the recommended value based on the calculation presented earlier in this article series.
        Connect the TX_STATE signal to one of the GPIOs, this signal will serve as a trigger event for our measurements.


        At the Rx side connect the RX_DATA, HOPPED, SYNC_WORD_DETECT and HOP_TABLE_WRAP signals to GPIOs and hook them up on a scope.

         

        validation_GPIO_config.png

         

        All of the tests below can be applied to all three no signal detection schemes.


        Test#1: Transmit a packet at any of the frequencies that reside in the channel plan and observe the scope screen. You should be looking at something like the capture below. (This capture was taken with an Rx configuration of 5 channels based at 916 MHz and a modulation of 100 kbps 2GFSK with preamble timeout no signal detection scheme and a 40 byte long preamble at the Tx side.) If the packet has been successfully received you will also hear a beep from the platform.


        The trigger event (TX_STATE signal from the Tx) is marked with a full orange triangle at the 1st vertical division line from the left. This event signals the beginning of the packet in the air.

         

        revB1_11NibPrTo_40BytePr_reception.png

         

        First off the SYNC_DETECT trace tells us that there has been a successful signal detection. From the HOP_WRAP signal’s transition (that signals the beginning of the new cycle in the hopping sequence) you can count the number of hops on the HOPPED trace and tell which channel reception has occurred at (hopefully this is the same channel you transmitted at). In this particular example it is the 3rd channel. (Note that this number will also appear on the LCD display on the platform.) Try transmitting at each channel (or at least a sub-set of channels if you have too many) and check for functionality the same way!


        Test#2: Transmit many packets randomly and place the scope’s display in infinite persistence mode. You will see a screen similar to the one below. I traded the HOP_WRAP signal for VALID_PREAMBLE as it is a touch more interesting in this case. The purpose of this experiment is to make the receiver see all kind of different timing situations (including worst case scenarios discussed in the Timing article) and check for the margin in preamble length.

         

        revB1_11NibPrTo_40BytePr_sync_pos.png

         

        At this test I used a lab signal generator for transmitting packets for being able to control the power level. The test was performed at -102 dBm power level which is 3 dB above 5% PER sensitivity level. With this I not only verified functionality but also checked for performance. If you don’t have a signal generator you can keep on using the Tx node approach.


        1st off the receiver should have received all packets. You can assess this by examining the SYNC_DETECT trace; all trace instances on the display must go up at detection, if there is one that has not, that packet has got missed.


        Now, place a vertical cursor on the SYNC_DETECT rising edge and measure back the sync word length + the signal detection time. In this particular example this is 16 bits for SYNC_WORD and 40 bits for signal detection yielding 56 bits which in turn is 560 us at a 100 kbps DR. Now, replace the SYNC_DETECT cursor to the rightmost trace on the HOPPED and check the distance to the previously established timeline.

         

        revB1_11NibPrTo_40BytePr_margin.png

         

        The measured time (50us – 5Tb) is the margin on preamble length for signal detection. Now, is this number good enough? Taking into account that this number includes the propagation delay through the Rx chain (T_PropDel) that is typically 4 Tb our margin shrinks to 1 Tb that seems a bit tight. We, however did expect a tight margin as our preamble length calculation is based on worst case scenarios, scenarios we were trying to replicate at this test. The conclusion so is that this low margin is expected and is considered good enough.


        For a thorough check repeat the same test at the worst case expected frequency offset between Tx and Rx. I have done an experiment assuming 20 ppm XO specifications that resulted in 37 kHz worst case offset at my operating frequency.

         

        revB1_11NibPrTo_40BytePr_margin_20ppmOffset.png

         

        Test#3: The previous test checks for preamble length margin on signal detection, it however does not tell us much on how well we chose the timeout (in the case of LoP and RSSI measurement methods) for no signal detection. As an example we may as well have chosen a timeout value that is way higher than the minimum required (i.e., 100 Tb) with an correspondingly longer preamble at the Tx side (as per our formula) and we would still measure the margin on signal detection to be the same with the previous method. In other words the previous test checks how good the formula is for calculating the preamble length but does not tell us much on how well we estimated the input parameters (most notably the maximum no signal detection time) to the formula.


        To check the margin on no signal detection performance test a particular configuration with the recommended preamble length than keep reducing the timeout parameters nibble by nibble until the performance starts degrading. What we do with this experiment is we make the receiver decide on a no signal condition faster, which will have an implication that the receiver will start missing valid packets to premature no signal detections.


        I undertook this test by measuring PER floor with a test signal at -102 dBm and -60 kHz frequency offset. You, however can get to the same result (albeit less accurate) if you stick with the missed packet hunt on the scope.


        To make this experiment a bit more exciting I calculated the preamble length based on a 37 Tb no signal detection time (on the grounds that as I hinted before preamble detection based timings have 3Tb margin built into them.) and got 39 bytes for a revB1 chip.

         

        PrTo_meas.png

         

        From the graph you can tell that decreasing the preamble timeout from 10 nibbles immediately introduces a PER floor (however low that may be) and decreasing it even further degrades the performance dramatically. Our estimate with the 37 Tb no detection time did not leave any margin within the resolution of the preamble timeout (which is what we expected as I deliberately removed the built in 3Tb margin from the no detection times).


        Interestingly the performance starts degrading again with increasing timeout values. This is because the prolonged no signal detection times prevent the receiver from arriving to the correct channel in time to capture the preamble at extreme cases. (Essentially this is the same effect we are checking for in test#2).


        Had I stuck with the 40 Tb no signal detection time my preamble length would have come to 41 bytes and we would have seen two points on the graph (at TO 10 and 11) with 0% PER floor.
        Now you can ask the question: can I squeeze out the margin from the LoP scheme no detection times too? Answer: If you are squeezed for preamble length to fit inside a spec, yes go ahead, however it will only buy you a relatively little preamble length reduction. Stick with the recommended detection times otherwise; what this buys you is guarantee that it will never break as these are the numbers millions of tests have been performed at.


        Test#2 with DSA scheme: Generally speaking Test#2 checks for margin on signal detection whereas Test#3 checks for margin on no signal detection. With the DSA scheme however Tests#2 checks for both. The reason for this is that at the DSA scheme the no signal detection times is not a timeout driven mechanism. The receiver simply stays as much time on an empty channel as needed for a no signal detection; no more no less. It follows than that Test#2 in this case checks for the overall margin on preamble length.


        Below screenshot was taken with the DSA detection hopping scheme with the following parameters: 5 channels starting from 916 MHz, 10 kbps 2GFSK H=1 modulation, 7 byte preamble length on the Tx side.

         

        revC2_DSA_reception_10kbps_7byte_preamble_sync_pos.png

         

        On above plot I measured 32 Tb time back from sync word detection counting 16Tb for sync word and another 16Tb for worst case detection time.

         

        revC2_DSA_reception_10kbps_7byte_preamble_Pr_margin.png

         

        On this plot I replaced the sync word cursor to the rightmost HOPPED trace to measure the margin on preamble length; I got 5Tb (or 9% percent of the 7 byte long preamble); comfortable enough.


        You can see the power of the DSA detection scheme here: with preamble detection one would need 4 bytes on a single channel to detect a signal, with the DSA we can scan 5 times as many channels with less than twice the preamble length; quite attractive!

         

        This article is part of a series that discusses various aspects of auto frequency hopping. Find the links to the other articles below.

         

        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-1-What-is-it-good-not-good-for/ta-p/160890
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-2-Detection-of-the-absence-of/ta-p/161033
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-3-Timing/ta-p/161381
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-4-WDS-configuration-State/ta-p/161390
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-5-Frequency-Table/ta-p/161394
        http://community.silabs.com/t5/Wireless-Knowledge-Base/EZRadioPro-Auto-Frequency-Hopping-6-Debug-and-verification/ta-p/161408

         

      • EZRadio / EZRadioPro IF frequencies

        zopapp | 01/13/2016 | 07:41 AM

        EZRadio and EZRadioPro devices have a low injection LO architecture that downconverts to a low IF (Intermediate Frequency). In other words the LO (Local Oscillator) is always one IF below the wanted receive frequency.

         

        Knowing the IF frequency is essential for testing image rejection performance. The image frequency is located two times the IF below the wanted frequency.

         

        On EZRadio devices the IF frequency invariable equals to f_XO/64.

         

        On EZRadioPro devices above equation is still true in most of the cases. EZradioPro, however allows for IF scaling (albeit hidden under a license in WDS) so the best way to check what the IF frequency has been set to is looking at the configuration batch file.

         

        The IF frequency is listed in the batch file right above the Rx filter bandwidth numbers.

         

        batch_file_output.png