Reply
Highlighted
Posts: 3
Registered: ‎12-28-2016
Accepted Solution

EZRadioPRO and AN463

When using raw-data mode to receive in this part family, noise can reduce your effective sensitivity.  AN463 details some digital-filtering one can implement in a connected CPU to reduce that penalty.  This starts with digitally over-sampling the raw-RX stream, and then proceeds to filter that.  FIrst and foremost, that digtal-oversampling is easily accomplished in the EZR32 parts by connecting the raw RX-stream (configured to an RF-GPIO) into a USART RX, and set said USART to continuously sample  that stream in I2S mode and pack it into a circular buffer on data interrupts.

 

The digital-deglitching algorithm starts in section 3.2.1 with a 'majority voting' algorithm, wherein 5 sequential samples are evaluated, and the 'result sample' is the value of whatever binary occupies 3 or more of those 5 samples.  The sample code goes on for two pages (7 and 8).  The key to implementation efficiency in a 'modern' 32-bit processor with a single-cycle 'barrel-shifter' is to pack the binary samples!  The first part of that comes 'automatically' by using USART hardware, regularly sampling and packing the received stream in I2S mode, LSB-oldest, into 16-bit half-words (which the RX interrupt routine places in a simple circular buffer).  This immediately makes the 'bit aging' process (to toss the oldest, and move all the current data 'one older'), which in the sample code is the bottom two lines full of 'variable copy-overs' on page 8 (and duplicated on the top of page 9 for a 'second pass'), into a simple shift:

    Processing_bits >>= 1;

With that concept in place, we can add a 'whole batch' of 16 new samples from the packed (LSB oldest) halfword buffer thus:

    Processing_bits |= Raw_Data[Processed_data_ctr++] << 5;  //Tack the 'new bits' on top of 'em!!

    Processed_data_ctr &= (sizeof(Raw_Data)/2 - 1); //circular addressing of binary-sized queue

and then for the final 'magic' (made possible on a 32 bit processor with a single-cycle shifter!), for each 'result bit' we can take our 5 'oldest current bits', which are in the 5 LSBs of the in-process-word "uint32_t Processing_bits;", as a lookup into a binary-vector that contains the answer, at each bit-address, of whether that '1 of 32' bit-address has 'more 1s' or 'more 0s':

  static const uint32_t Majority3 = 0xFEE8E880; //0b1111_1110_1110_1000_1110_1000_1000_0000

                                          //'1' where 3 or more 1s in bit-address

So now taking the majority-vote for each bit, in sequence, is just these two statements (run 16 times per each halfword-full-of-bits):

    Processing_bits >>= 1;

    MajorVote = (Majority3 >> (Processing_bits & 0x1F)) & 1;   //Straight 3of5 voting

Posts: 245
Registered: ‎12-10-2013

Re: EZRadioPRO and AN463

What's the issue?

Juanyong
Posts: 3
Registered: ‎12-28-2016

Re: EZRadioPRO and AN463

Sorry, no particular 'issue', and if I knew how I would have posted directly to the Knowledge Base.  I was just implementing the filtering of AN463 and discovered that the supplied code was WAY to slow to keep up with my datarate, and had to come up with a MUCH more efficient means of doing 3of5 (or 4of7!) majority-voting, and I came up with this packed-binary solution to get it down to less than a dozen instructions.

Posts: 3
Registered: ‎12-28-2016

Re: EZRadioPRO and AN463

I was just hoping to help out other users of AN463 on EZR32 platforms.