When I read the Kernel Log of my RUTX50 there are indications of PTP Protocol support in the kernel.
- Are there any hardware limitations in RUTX50 that would prevent PTP timestamping of packets?
- Are there any hardware limitations in RUTX50 that would prevent such timestamping to be disciplined by the PPS output of the GNSS receiver in RUTX50?
- Are there any limitations that would prevent the GNSS receiver in RUTX50 to provide Major Time for PTP timestamping?
1 Like
Hi, Teltonika staff might be able to correct me here, but I think even if there’s software support for PTP due to kernel module being loaded, hardware wise it is not supported. PTP (aka IEEE1588) would have to be supported by the modem and if I’m not wrong RUTX50 uses a variant of Quectel RG50xQ Series. However, it seems that there is no PTP/IEEE1588 support within the modem itself according to this modem datasheets and HW design information. It might be a hidden feature though, or perhaps Quectel is still working on its implementation for this particular modem series.
Software wise it might be possible to implement, but software-based PTP is not as accurate as hardware-based PTP and your network might not be compatible with software-based PTP protocol. It does seem that there is a PTP daemon for OpenWRT devices so perhaps you could try to install it on a test using CLI (opkg update ; opkg install ptpd
), but I’m not sure if the install would be successful, let alone if PTP functionality would be correct. If you do manage to install it, this doc might be useful to test if ptpd
works.
https://www.ibm.com/docs/en/aix/7.3?topic=p-ptpd-daemon
When you are referring to “the modem”, do you then mean the 5G mobile network modem? I’m strictly after PTP stamping packets on the LAN side, and this being diciplined by the built in GNSS receiver. Not after fetching PTP from the 5g network (although a nice feature in itself).
Yeah, I meant the 5G module itself. What sort of PTP configuration do you run in your network? How much precision do you need? Maybe this is doable using software-based PTP timestamping in this case, but if your entire network supports hardware based PTP then it’ll probably be incompatible. And on top of that we’ve also got a question of PTP daemon support on current OpenWRT release (which Teltonika runs)…
Just my 2 cents - the reason I’m saying it might not be possible to get proper timestamping working without hardware-based PTP timestamping is because I recall testing regular equipment in the middle without hardware (4 out of 6 devices didn’t support PTP at all in lab topology) and already there was an issue with clock remaining in uncalibrated state permanently, even though PTP packets were being tunneled using Juniper’s L2PT as transport. It was working while only 2/4 devices did not support PTP, but timestamps were already going into negative values and due to large amount of delay being introduced using software-based PTP your clocks might never go into a master/slave mode and instead would remain in uncalibrated state.
But in any case, if you do perform any tests I would be very interested in the result