Repeatedly sending the same text is permissible only if the device documentation explicitly states that the device compares the content of the new text with the existing one. I do not believe that is the case here. Doing so could, for instance, lead to an unintended change in the RT Type flag, effectively triggering a restart of the existing text on the receiver.
If the port timeout cannot be extended, I recommend using the Magic RDS scheduler to send — at regular intervals — any command that does not affect any RDS service. There is even a sample preset already created for this purpose (TA status reading). Alternatively, you can send your station name at regular intervals; that causes no issues (PS=xxxxxxx). You could also ask the device manufacturer to recommend a suitable "dummy" command.
Advanced RDS encoders also feature a text timeout function. If you broadcast long segments (such as podcasts), it is advisable to include an additional text source in the loop so that the text changes at least occasionally. The additional source may point to a file with a fixed text or it may be fed by the Text Campaigns, etc.