Not retrieving data

5 posts / 0 new
Log in or register to post comments
Last post
Fri, 09/25/2020 - 02:26
#1
rpajuelo
Offline
Last seen: 4 years 1 week ago
Joined: 09/25/2020
Posts: 5
Not retrieving data

Hi,

I have a problem sending and receiving information between 2 terminals in the same local area. I have a publisher on one terminal and a subscriber on the other. Everything works fine with the terminals working at the same machine datatime but if I change this, for example I put the publisher terminal 1 hour up (future) ... the subscriber does not work (it does not show me data) and I would like to find out a kind of QoS to fix it, because I cannot assure that in the future I will not have any problem with synchronism.

Note: With RTI DDS Spy I can see all the information no matter what time is it.

Thanks.

Top
Fri, 09/25/2020 - 04:32
Mike Partington
Offline
Last seen: 3 years 4 months ago
Joined: 08/09/2017
Posts: 25

Hi,

Can you provide the QoS of the subscriber? Any chance you are configuring the DESTINATION_ORDER QoS?

Top
Fri, 09/25/2020 - 05:05
rpajuelo
Offline
Last seen: 4 years 1 week ago
Joined: 09/25/2020
Posts: 5

Yes, this is a piece of the QoS XML code

             <topic_qos>
                <destination_order>
                    <kind>BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS</kind>
                </destination_order>
                <durability>
                    <kind>PERSISTENT_DURABILITY_QOS</kind>
                </durability>
                <reliability>
                    <kind>RELIABLE_RELIABILITY_QOS</kind>
                </reliability>
            </topic_qos>
 
Publisher and subscribes uses the same QoS.
Top
Fri, 09/25/2020 - 05:53
Mike Partington
Offline
Last seen: 3 years 4 months ago
Joined: 08/09/2017
Posts: 25

Thank you.

The behavior is caused by setting the destination_order to BY_SOURCE_TIMESTAMP. If you change this to DDS_BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS, the problem should go away.

More information about this QoS is available in the documentation.  The basic idea is that if the subscriber is using the source timestamp, and it receives a time stamp in the future, it concludes the sample is invalid due to the source_timestamp_tolerance setting. Using BY_SOURCE_TIMESTAMP is only intended for systems where clocks are closely synchronized. It is not expected to work in systems where clocks can vary widely, such as the 1-hour difference that you tested.

Hope this helps,

- Mike

Top
Mon, 09/28/2020 - 23:35
rpajuelo
Offline
Last seen: 4 years 1 week ago
Joined: 09/25/2020
Posts: 5

Hello again,

I´m sorry for not responding before but it worked fine.

Thank you very much for all!

 

Top