RTOS/CC1310: Time synchronization over the air

user4959119

Part Number: CC1310

Tool/software: TI-RTOS

Hi Team，

I am working on the implementation of the time synchronization feature. I want to know how to measure the value of dtx in One-way synchronization example?

over 6 years ago

0 IUsedToBeARealPerson (M-W) over 6 years ago

TI__Guru 58425 points

Hi Xiuqian,

Have you seen the User Guide chapter regarding this?

dev.ti.com/.../

dTX is basically the latency from when the command is started until it reaches the air. There is multiple ways you could try to measure this but I think one of the simpler approaches is to setup a PING-PONG example where one side receives a packet, reads out the sync found timestamp and use this timestamp plus a fixed delay (say 100ms) to send the same packet back.

You then route out RFC_GPO3 on both sides and look at the rising edge of the IO for both devices. Ideally, you should have 100ms between the two, the error here should be the delay.

As for routing out signals, please see this:

dev.ti.com/.../

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M-W，
You mean dTx is only considered for transmission, and it is the time from the starttrigger to the transmitter sending the first electromagnetic wave. Right?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

That is correct, it basically the delay from when the command is actually started to when it is sent over the air.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M-W,
I still have some confusion:
1.There will be many assignment statements before executing the send command. The timestamp content sent should be earlier. Does this error need to be considered?
2.RF_cmdPropRx.rxConf.bAppendTimestamp = 1;what time is the timestamp record? Is the moment when I just received the sync word?
3.What is the trigger condition for the RFC_GPO3 output?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

1) - Not sure what you mean here.
2) This is covered in the Radio section in the technical reference manual, it is the time when the packet start, in other words when we start to receive the packet (assuming sync found).
3) The trigger is internal in the RF Core, it should correspond to the same trigger that tells the modem to send out the data.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Why is my RFC_GPO3 not output?

PIN_Config ledPinTable[] =
{
    IOID_5 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,
    PIN_TERMINATE
};

....
....

PINCC26XX_setMux(ledPinHandle, IOID_5, PINCC26XX_MUX_RFC_GPO3);
    
    /* Open LED pins */
    ledPinHandle = PIN_open(&ledPinState, ledPinTable);
    if (ledPinHandle == NULL)
    {
        while(1);
    }

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

You should do the PIN muxing after the PIN_open() call for it to properly mux the signal.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M-W,
1.I still have no output for this, is there any other reason?Does the pin that needs to be routed must be in the ledPinTable?
2.RFC_GPO3 outputs a high level to indicate the start of transmission, then this is the preamble or synchronization word sent at this time?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

1. Having the pin in the PIN table is a good idea. You could always try the output using the LNA or PA signals (first two in the RF signal table) to see if you get them to show first to verify you have the pin setup correctly.

2. It would indicate the trigger sent to the modem, which means where it ramps up and starts to send data out (so basically, start of the transmission over the air).

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

If you follow the measurement method you said, error =2dTx?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

I believe it is just dx. Start trigger to start trigger should include the delay of the first transmission, the transmission itself plus the fixed offset given by you when rescheduling.

Think of it like this, you get a timestamp by the device saying when you started to receive the message and schedule a send back maybe 100ms into the future. You then measure the time from the first to second trigger. Ideally, this would be 100ms assuming no latency on the second TX, the error here should be your dx which would be the latency from assumed start time to actual start time.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M-W,

You are right, I understand it now.I tested RFC_GPO3 in the rfListenBeforeTalk routine to output normally, but in WOR-RX, the send command can be executed normally and the serial port can print data, GPO0 has output, GPO1 and GPO3 have no output, what is the reason?

case PROP_DONE_OK:
/* Received packet */
 worStatistics.doneOk++;               
 RF_cmdPropTxAdv.pktLen = packetLength + 1;
 RF_cmdPropTxAdv.startTime = rxstamp + RF_convertMsToRatTicks(100);               
 RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTxAdv,RF_PriorityNormal, NULL, 0);
 Display_printf(uartDisplayHandle, 0, 0, "stamp = %d",rxstamp);
 break;

0 user4959119 over 6 years ago in reply to user4959119

Expert 2215 points

Hello？

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

Have you actually verified that the device is sending out a packet, are you able to sniff the packet or receive it on the other side?

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Yes, I can confirm this, is there any other reason?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Can you share your test project here for me to test?

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Yes，I will give you tomorrow M-W.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Now that my GPO3 has output, do I need to use the two probes of the oscilloscope to connect the GPO3 pins of the two boards separately?

Let's assume that there is a situation where the nodes have been running for a few days and the concentrators are just running. The difference T of their RATs will be large. How do I synchronize them even if I calculate their time difference?

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hello?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

The RAT timers do not need to be perfectly in sync, you just need to adjust for the offset (which is the difference). You should not expect each device to have a perfectly synct RAT timer. the "time synchronization" is part of your software on top.

If you need to measure two outputs (as suggested above), two probes seems to be the right way to go as you need to know the sate of both signals.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Yes, what I thought before was the perfect synchronization on the hardware level. How do you handle this offset in software to achieve so-called synchronization? I don't have a little idea. Can you give an example?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

When you have the offset in time (or RAT ticks), you use this when calculating the start time of your commands. For example, if you want to wake up in 100 ms to listen for a packet from another device, and you know the offset, you adjust the start time to be 100ms + offset.

Say you receive a packet from one device that says "you should wake up in X amount of time for next packet". Then you can use the timestamp to figure out when to wake up (timestamp + 100ms). To this, you can also account for the offset to be sure you are ready in time.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

This situation seems to be only suitable for rfSynchronizedPacketTx/Rx.In TDM mode, all nodes receiving data at the same time means synchronization. I think I understand this question.

Sub-1 GHz

Sub-1 GHz forum

RTOS/CC1310: Time synchronization over the air