Capturing GPIO transitions of a 4kHz signal with BLE enabled

[dj1234]

I need to capture the time between rising transition of a GPIO pin in order to integrate a Manchester decoder of an RFID reader chip. In my particular case, the reader chip emits a waveform where the minimum time between the rising edges is ~256uS. The device I'm working on is a BLE peripheral and ideally, I'd like to run both interfaces concurrently.

This is all running on an nRF52840-DK board with FreeRTOS.

I hacked together an initial prototype where

1. I linked a PPI with GPIOE and TIMER1 where the rising edge causes the timer count to be captured
2. An IRQ on the GPIO rising edge to cache the last capture (thus getting a very accurate measurement)

This all works fine when BLE is disabled, however as soon as enable it (the device starts advertising), I appear to be missing transitions.

I'm yet to really drill down to identify how/when the transitions are missed, however I thought I might check to see if anyone can suggest a better scheme to capture the timing.

Thanks.

DJ

[haakonsh]

If you know the clock frequency and length you can set up a TIMER to trigger a SAADC sample task in the middle of each positive clock period. You start the TIMER on a GPIOTE pin change. That way you can capture a waveform and store it in RAM without using the CPU at all, and then process the data whenever the CPU is available. 

Since the signal is digital it should be fairly easy to convert from analog to digital, I suppose you can right-shift the analog 16-bit integer down to msb, then XOR with 1 to get the original data bit. 

ex:
At 10-bit accuracy, say the SAADC samples yield between 512-1023dec for '1's and 0-511dec for '0's. Then right shifting the samples by 9 bits will leave you with the manchester-encoded bit. 

The samples are stored as an array, so for a 32-bit transmission, you will need a buffer size of 16bit x 32 = 64bytes

#define BufSize 32

int16_t     MyBuffer[BufSize];
uint32_t    Data = 0;

//After the data is captured:
for(uint16_t i=0; i < BufSize; i++)
{
    My_Buffer[i] &= 0x3FF;          // Remove sign bit if a '0' is registered as negative number
    
    MyBuffer[i] = (MyBuffer >> 9);  /* '9', because at 10-bit precision with signed value 
                                    the 9th bit is half of max value*/
                                    
    Data |= (MyBuffer[i] << i);        // OR-in the Manchester-encoded bit into a data buffer
}
Data ^= 0xFFFFFFFF; //XOR with the clock signal, represented by '1's. 

//Repeat for however many 32-bit words your transfers are.

.

[haakonsh]

Can you specify exactly what kind of Manchester encoding you're using?
Can you ensure that each transfer starts with a low-to-high or optionally high-to-low transition? 

[dj1234]

This is a bit tricky to answer. I'm interfacing with an HTRC110 reader chip and none of the documentation clearly states what Type of Manchester it is. The only reason I believe it's Manchester is because a sample driver found here mentions it.

I had a look at a waveform of the RF chip on an existing product (I don't have the source for it) and it's a waveform with a minimum duration of 256us between two rising edges. This tallies with the comments in the sample code.

[haakonsh]

The HTRC110 does not appear to be using a manchester encoded protocol since it has a separate clock signal. The defining attribute of a manchester encoded signal is that it's self-clocking, where the clock signal is modulated into the signal itself. 

But this does not really change much in your case, it actually makes things a lot easier since the MCU controls the SCLK and DIN lines. Now we can use the SCLK timings to trigger SAADC sampling of the DOUT line on positive clock periods. 

See "Fig 4. Serial signaling" in https://www.nxp.com/docs/en/data-sheet/037031.pdf.


What you need to do:

1. Create a clock signal with a TIMER and GPIOTE. 
   
   
2. Create a driver for the digital input line, DIN, with manual SW GPIO toggling or maybe even use the PWM peripheral for that. I'm not 100% sure we can use the PWM for this, but if we can then you will be able to send commands to the HTRC110 without using the CPU to control the GPIO for the DIN line, as the PWM peripheral can be configured to use a pre-defined 'sequence' in RAM with EasyDMA. 
   
   
3. Setup the SAADC to sample on the SCLK's positive flank changes, based on the TIMER it runs on. 
   
   
4. Run the process I described earlier on the samples to get the data. 

[haakonsh]

I just realize that you can probably use the SPIM peripheral for this as this looks like SPI without CS/SS. If this is the case then this will be the easiest solution by far. 

It looks like you'll have to find the frequency of SCLK by trial-and-error, I suggest starting at 125kHz. 

[dj1234]

haakonsh said:

The HTRC110 does not appear to be using a manchester encoded protocol since it has a separate clock signal.

That's true as long as we're talking to the reader chip. However, once the READ_TAG command is issued, the reader chip becomes a effectively a pass-through device to the RF transponder (specs for that are here).

I just realised that the CPU uses the READ_TAG and WRITE_TAG commands to communicate with the transponder which sends it's data in Manchester encoded format.

So I don't believe that I'll be able to use the SCLK as a trigger. However, SAADS with a pure timer sampling the data as you suggested I think will do the trick. i'll give that a go.

Thank you very much for your help

[haakonsh]

Aah, I see. 

FromHT2 Transponder Family Communication Protocol, page 8:
"The first bit of the transmitted data always starts with the Modulator ON (loaded) state." 

It looks like the data signal always starts with a logical high, so you can start a TIMER based on a low-to-high GPIOTE transition, as long as you've got a weak pull-down resistor on the line. 

Also, the Manchester encoding is of the G.E Thomas variety, so you don't even need to XOR the data bits with the clock, as long as you sample in the first half-period of a symbol. 

With BIPHASE decoding you'll need to sample both half-periods of each symbol and find what pair has two identical values, representing a '1', and who's got two different values, representing a '0'. 

Anyways, this looks like a fun project, let me know if you need any more help.