CC1310: using the GPT to measure time between RAT_GPO0 and RAT_GPO1 falling and rising edges

Hi,

each IO pin on the CC1310 can be routed to one special function. Since you have already routed it to RFC_GPOx, it cannot be used as an event input for GPTx. But the edge detector unit is an independent functionality, so you could set the pin up as an output, enable edge detection with the PIN driver and register a callback for both pins:

PIN_Config pinTable[] = {
    IOID_XX1 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW  | PIN_PUSHPULL | PIN_DRVSTR_MAX | PIN_IRQ_POSEDGE,
    IOID_XX2 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH  | PIN_PUSHPULL | PIN_DRVSTR_MAX | PIN_IRQ_NEGEDGE,
    PIN_TERMINATE
};
PIN_Handle pinHandle = PIN_open(&pinState, pinTable);
PIN_registerIntCb(pinHandle, &onPinValueChanged);

// Route to special function RFC_GPOx
PINCC26XX_setMux(pinHandle, IOID_XX1, ...);
PINCC26XX_setMux(pinHandle, IOID_XX2, ...);

Then you could just read a timestamp from the RTC. But you would have to deal with interrupt jitter.

If you want to use the GPT for direct time measurement, you would end up with 4 IO pins where 2 are the RAT_GPO outputs and 2 are the GPT event inputs.

But if you just want to measure the round-trip time, you can achieve that with on-board tools of the RF core. Have a look at this two-way synchronization example. Could you maybe use that one for your measurements? The time from TX start trigger until the first bit on air is somehow deterministic and so is the RX timestamp. There is also a synchronized packet example in the SDK which also shows how to deal with timestamps on the RF core.

Both links from above use the proprietary API directly, but it is actually much simpler to use the EasyLink API. See this post. You don't have to deal with proprietary commands directly and could still leverage the precise timing.

i have seen the various examples that append a (RAT) timestamp to a packet....  my concern was that a RAT timer tick is 250ns, whereas a GPT timer tick is 41.67ns....  with radio waves traveling 1 foot / ns the difference seems significant....

i've been experimenting with an approach described here as well as variants found in the WSN literature....  in trying to achieve (say) accuracy within several feet, the amount of oversampling on a clock in which one tick equals 250 feet seems like a lot....  almost every description of this approach for TOF uses a much faster clock....

incidentally, there are variations on this approach that (easily) account for differences in each node's clock without having to synchronize them....

i'll continue to explore, though welcome any suggestions on techniques to capture TOF with reasonable precision....

thanks, bob

Hi,

let's assume you send with 500 kBd symbol rate and the proprietary PHY. The demodulator output is oversampled 4x the symbol rate before estimation. That means, sync word correlation and everything else might be off by 1/4 symbol. At 500 kBd this is 500 ns.

In addition, in order to get a deterministic round-trip time, both, TX and RX would have to execute autonomously on the RF core. This is impossible with the proprietary PHY implementation on the CC1310. Even if you chain a TX to an RX command and use absolute triggers, there would still be some non-deterministic parts that ruin the timing.

bios.bob said:

back to controlling the GPT, is there someway i could use a pair of uDMA channels to effectively turn-on/turn-off the GPT in response to TX-done and RX-sync GPIOs going low??? given that all of the GPT registers are memory mapped, can't i have uDMA that writes a particular value into some GPT control register????

Should be possible. I guess you want to invoke the DMA via a GPIO?

However, I am fairly pessimistic that you can achieve what you want. We have implemented ToF using the BLE PHY at 2.4 Ghz, but for that some parts of the RF core firmware have been carefully rewritten. This is not going to happen for Sub-1Ghz.

after some quick experiments on the cc1310, i'm fairly pessimistic as well!!!!   but still, have a look at this paper as a point of reference....  though they over-sample quite a bit , the results are quite impressive; and they use MSP-430 + CC2500 hardware....  it would appear that this technique would apply to cc1310....

popping up a level, this raises a broader question for TI:  the cc1310 using something like SL-LRM is a great solution for outdoor applications, with sensors potentially "scattered" over a square mile and transmitting readings up to the cloud via some gateway....  imagine, for example, that they are attached to livestock in a field; being able to roughly locate an individual animal is quite valuable....  but pairing a cc1310 with a GPS chip costing 5x-10x the price is not really feasible in use-cases requiring a large number of sensors....

in many of these applications, it is feasible to install a relatively small number of "anchor" nodes at known locations that essentially cover the area of interest....  others have talked about techniques such calculating "angle-of-arrival" using multiple antennas and measuring phase-difference....  is that even possible with the cc1310 (or perhaps the new cc1312)???

any thoughts would be much appreciated....

It's not impossible hardware-wise, but the RF core firmware on the CC1310 is the limiting factor and that's closed source. ToF has been implemented for the CC2640 at 2.4 Ghz at least as a demo. I guess it will be released to market any time soon.