I thought hardware timestamp gave more accuracy on synchronization. Because I'm running linux on a virtual machine I can only use software timestamp. So, I thought that was my problem on synchronization.
Is there a parameter on linux to set accuracy on synchronization? I didn't find anything.
I checked and XMOS enters in set_ascapable() function if I set PTP_NEIGHBOR_PROP_DELAY_THRESH_NS high enough (in my case is 20000000). I'm not sure I understood your problem
How to communicate with PTP linux PC? Topic is solved
-
- Active Member
- Posts: 42
- Joined: Tue Jan 07, 2020 10:35 am
-
- Active Member
- Posts: 34
- Joined: Thu Sep 05, 2019 6:49 am
Have you ever checked FCS field of PTP packet?
My PTP packet has problem at this
but I didn't touch any source code about FCS
My PTP packet has problem at this
but I didn't touch any source code about FCS
-
- Active Member
- Posts: 34
- Joined: Thu Sep 05, 2019 6:49 am
In send_ptp_sync_msg function
go to ptp_tx_timed function and
change the line like this
len = len < 60 ? 60 : len;
then SFC error will be solved
go to ptp_tx_timed function and
change the line like this
len = len < 60 ? 60 : len;
then SFC error will be solved
-
- Active Member
- Posts: 42
- Joined: Tue Jan 07, 2020 10:35 am
Sorry but lately I hadn’t time to check. I will try as you suggest as soon as possible. I’ll let you know
-
- Active Member
- Posts: 42
- Joined: Tue Jan 07, 2020 10:35 am
I modified what you said.
I also found that follow_up message was longer (TLV fields are not specified in IEEE1588).
So I modified the length of the follow_up packet in the send_ptp_sync_msg() function there:
- pComMesgHdr->messageLength = hton16(sizeof(ComMessageHdr) + sizeof(n80_t));
- ptp_tx(i_eth, buf0, (sizeof(ethernet_hdr_t) + sizeof(ComMessageHdr) + sizeof(n80_t)), port_num);
And I also changed ptp_tx():
- len = len < 60 ? 60 : len;
Don't know if this could be a problem for linux_ptp.
Now I was wondering if the function ptp_output_test_clock() could be used to synchronize a media clock. In AVB the media clock can be synchronized to an input stream.
But what happen if on the XMOS board, I run a ptp_server() and use ptp_output_test_clock() to output a clock signal to the PLL on the XMOS board?
I suppose that if the XMOS is a PTP SLAVE, this clock could be used to have a synchronized clock as in AVB. Am I correct?
Check this for ptp_output_test_clock(): viewtopic.php?t=3920
I also found that follow_up message was longer (TLV fields are not specified in IEEE1588).
So I modified the length of the follow_up packet in the send_ptp_sync_msg() function there:
- pComMesgHdr->messageLength = hton16(sizeof(ComMessageHdr) + sizeof(n80_t));
- ptp_tx(i_eth, buf0, (sizeof(ethernet_hdr_t) + sizeof(ComMessageHdr) + sizeof(n80_t)), port_num);
And I also changed ptp_tx():
- len = len < 60 ? 60 : len;
Don't know if this could be a problem for linux_ptp.
Now I was wondering if the function ptp_output_test_clock() could be used to synchronize a media clock. In AVB the media clock can be synchronized to an input stream.
But what happen if on the XMOS board, I run a ptp_server() and use ptp_output_test_clock() to output a clock signal to the PLL on the XMOS board?
I suppose that if the XMOS is a PTP SLAVE, this clock could be used to have a synchronized clock as in AVB. Am I correct?
Check this for ptp_output_test_clock(): viewtopic.php?t=3920
-
- XCore Expert
- Posts: 572
- Joined: Thu Nov 26, 2015 11:47 pm
Hi.
Yes, it is possible to use ptp_output_test_clock() to generate a media clock locked to PTP. However, the existing lib_tsn doesn't have an implementation. You'll have to go to https://raw.githubusercontent.com/xcore ... t_clock.xc
I set the ptp output clock to 160 Hz (same as used when locking to input stream) and probed FSYNC on two boards. The phase lock isn't fantastic with the existing code from github.
Yes, it is possible to use ptp_output_test_clock() to generate a media clock locked to PTP. However, the existing lib_tsn doesn't have an implementation. You'll have to go to https://raw.githubusercontent.com/xcore ... t_clock.xc
I set the ptp output clock to 160 Hz (same as used when locking to input stream) and probed FSYNC on two boards. The phase lock isn't fantastic with the existing code from github.
-
- Active Member
- Posts: 42
- Joined: Tue Jan 07, 2020 10:35 am
Sorry but I see it's the same function that is in lib_tsn. I found it in lib_tsn/src/ptp/gptp_test_clock.xc. I'm using lib_tsn version 7.0.3.
If that function is supposed to be used to recreate a media clock, I agree with you when you say that phase lock isn't fantastic.
Do you have any hint on how to improve performance?
If that function is supposed to be used to recreate a media clock, I agree with you when you say that phase lock isn't fantastic.
Do you have any hint on how to improve performance?
-
- XCore Expert
- Posts: 572
- Joined: Thu Nov 26, 2015 11:47 pm
Oh, I must have deleted it from my library. Sorry.
You'll need some kind of phase reference I suppose, either a generated FSYNC fed back or timestamps from your TDM/I2S data. Timestamps from the I2S callbacks is how the XMOS software does it I am pretty sure with the input stream derived so I suspect you could do it similarly.
You'll need some kind of phase reference I suppose, either a generated FSYNC fed back or timestamps from your TDM/I2S data. Timestamps from the I2S callbacks is how the XMOS software does it I am pretty sure with the input stream derived so I suspect you could do it similarly.
-
- Active Member
- Posts: 42
- Joined: Tue Jan 07, 2020 10:35 am
Ok thank you so much.
I'll try to understand their code first, because it is still not so clear to me.
I'll try to understand their code first, because it is still not so clear to me.
-
- XCore Expert
- Posts: 572
- Joined: Thu Nov 26, 2015 11:47 pm
Yes if you could follow the logic of the input stream derived then you should be able to use that as your feedback and use PTP time as the reference in a PLL, then you would run in local clock mode and it might work. Good luck!!