Recent Posts

Pages: [1] 2 3 ... 10
1
Configuration Options and Possibilities / Re: Text Retransmission
« Last post by Jan on Today at 07:59:19 am »
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.
2
Configuration Options and Possibilities / Text Retransmission and port timeout
« Last post by wsof on Today at 06:46:04 am »
Hello,
I am currently trying to solve a problem I am having with a Deva Smartgen 6. I use Magic to send rds text to the device, but after a certain amount of time my Deva triggers an alarm that the port I am sending the text to has timed out. Bottom line is this, Magic appears to only send the text data once per change rather than continuously and after the time I have set for that port on my Deva, it triggers the timed out alarm. My question is this, is there any way to have Magic send that data repeatedly and is there a way to set the rate at which it sends it? Thanks

Steve
3
P132, P164, P232(U) and P332 RDS Encoders / Re: RVR TEX300LCD built-in RDS encoder (P232) board setup
« Last post by Jan on August 28, 2026, 06:42:59 pm »
Thanks, now everything is clear. This is not a P232 chip. I already had a feeling from the previous description that there was something completely different inside. If the board is from 2014, as can be assumed based on the label, then at that time we were still developing the P232 and it was not offered.

Unfortunately, I have no idea who made this board and what is actually inside. Based on the number of I/O connectors, I would guess that this is a multi function board and therefore there may not be a full-featured RDS encoder, but only a software component. It will be quite a problem to find some documentation and support for this.
4
P132, P164, P232(U) and P332 RDS Encoders / Re: RVR TEX300LCD built-in RDS encoder (P232) board setup
« Last post by andrew01 on August 28, 2026, 05:48:16 pm »
I was thinking that most encoders (like DEVA Broadcast, 2wcom, etc.) have exact group sequence changing options and PIRA doesn't, in my eyes it would give a "nicer touch" for those who want to customise the encoder to their most desire, and with the current legacy optimised mode and with a separate mode to change the exact group sequence, it would've been some "nice-to-haves", but that is just my 2 cents.  :D

Coming back on topic, my colleague replaced the 3V battery, we think this is what is causing the group losses and probably all other problems, BUT we haven't tested it, in the evening probably we will see if it works. Can you confirm if this is the P232 chip?
5
P132, P164, P232(U) and P332 RDS Encoders / Re: RVR TEX300LCD built-in RDS encoder (P232) board setup
« Last post by Jan on August 27, 2026, 10:41:06 pm »
It is pointless to insist on the exact group sequence. As the RDS standard says, the decoder must be able to process any stream regardless of the order of the groups anyway. The only thing that matters is the ratio of groups of a certain type. So whether you have 4x 0A and 4x 2A or 0A 2A at the output, there is no difference at all. The first case only has the specific advantage that you can rewrite the entire PS faster. For reasons of maintaining compatibility, no further changes are possible in existing system.
6
P132, P164, P232(U) and P332 RDS Encoders / Re: RVR TEX300LCD built-in RDS encoder (P232) board setup
« Last post by andrew01 on August 27, 2026, 10:27:57 pm »
It is probably a encoder from PIRA, the old sequence had 4x 0A 2x 1A 2x 2A and that 13B ODA, plus some random 0B groups, but just to be sure we will open the transmitter, when my colleague has time  :)

Unrelated to the issue we are having, but is it possible to add a option in Magic RDS to make your own RDS sequence (like 0A,2A,0A,10A,2A,etc.) aswell as PIRA's 022R... modes in the P132,232,332, etc. pages? I have only seen 0 which is 4 0As sent, we want to send something more refined, (we would like to put the sequence as 0A 2A for now) if we can finally find a way to properly send info.  ;D
7
P132, P164, P232(U) and P332 RDS Encoders / Re: RVR TEX300LCD built-in RDS encoder (P232) board setup
« Last post by Jan on August 27, 2026, 07:23:16 pm »
From what you say, I get the feeling that there is no P232 inside the device at all, but a different encoder. I probably wouldn't rely on what they have in the documentation.

I'll tell you a trick on how to find out with a relatively high degree of reliability whether the RDS encoder is from Pira.cz. If you have the opportunity to view the output RDS data in the RDS Spy program, our encoders were optimized for transmitting dynamic PS and therefore groups 0A are always transmitted in fours, and the first group always contains the first PS segment.

2A 2A 0A 0A 0A 0A 2A 2A 0A 0A 0A 0A <- this may be PIRA
2A 0A 0A 2A 0A 0A 2A 0A 0A <- this is not PIRA

If you can access the board under cover, it is possible to say more precisely what is actually inside.
8
P132, P164, P232(U) and P332 RDS Encoders / Re: RVR TEX300LCD built-in RDS encoder (P232) board setup
« Last post by andrew01 on August 27, 2026, 02:36:39 pm »
Hi Jan,

As far as our tests that we have done, only via the SERVICE/RDS port we could send PI and Radiotext commands via UECP only as mentioned, I have looked in the manual and attached a picture of the setup embedded in the transmitter. Before sending UECP, we looked at the RDS sequence that the former station had, and we observed a lot of interesting stuff, such as : Slow Labelling Codes found on Group 1A: Specific application developed by the broadcaster + Unassigned SLC + Language Identification Code + Paging identification + TMC identification + Extended Country Code + EWS channel identification , and a 13B ODA, we have also observed losses of the groups. After a successful attempt to connect, we could send a proper sequence, but we still have group losses.

I was hoping you would have their WINRDS+ software that the manual advises for this exact model with UECP, the other module that they offer advises Magic RDS 3 to be used. Sadly, their support team is not exactly useful, as my colleague contacted them in the past for another issue and they spoke a very broken english, they didn't understand what he wanted from them.
9
Release News and Tutorials / Re: Release News and Change Log
« Last post by Jan on August 27, 2026, 01:27:36 pm »
Version 4.3.1

http://pira.cz/rds/magicrds/MagicRDS_Setup.exe

External Text Sources:
  • Text replacing: New RegEx library supports lookahead and further features
  • Text replacing: New Filter column added
  • Text replacing bug fix: The %CLEAR% command finally works same way like in versions 4.2.x
  • Text replacing bug fix: %TERMINATE% keyword sometimes did not work for case-insensitive match
  • Test button now fills the RT+ preview
  • XML/JSON RT+: The "assign" setting now has priority over the "template"

We are constantly working to improve the program for you. We welcome your feedback.
10
Release News and Tutorials / Re: External Text Sources: Get "now-playing" information from RadioBOSS via HTTP API
« Last post by Jan on August 27, 2026, 12:48:07 pm »
ADVANCED TUTORIAL

The previous example was simple, because we only read simple information about the currently playing song. This information was compiled for us by RadioBOSS based on the name of the music file or the included tags.

Sometimes it can be useful to compile the text information according to your own criteria directly in the Magic RDS. However, this cannot be taken as a general recommendation, because it all depends on how carefully the songs are named in the music file database.

The following example reads the song title and the artist name separately. If these fields are empty, the name compiled in RadioBOSS is used (usually the file name). Next, we read the playback status. If playback is paused or stopped, the song title will not be displayed. Instead, a fixed text will be displayed. But it is possible to add the %GOTONEXT% command instead of this text and the text Source will be skipped in the Output loop until the music starts playing again.

Please note that this example requires the latest version of Magic RDS 4.
Pages: [1] 2 3 ... 10