71
Feature Requests / Re: MagicRDS4 UECP
« Last post by zvykov on April 22, 2026, 08:48:08 am »Yes, that's what I did. It seems to have worked, even though it's a "workaround."
Thanks.
Thanks.
News:
Thank you for using this forum as the technical support base for your device.
● You can format the text and attach screenshots, photos and RDS Spy records
● Faster reply: 50 % of questions are answered within 30 minutes
● You don't need to register (but registration is possible)
● The members represent a wide range of experts
● The resolution will be helpful to other users
● You'll be notified by email about new post
Recent Posts
72
Control Software / Re: 0x0D issue in Magic RDS
« Last post by mrandrew01 on April 19, 2026, 11:33:12 am »Definetly. Change is one of the hardest things to do, even outside of radio. New car multimedia systems are a huge (and buggy) mess, software developers don't care about these technical details regarding radio (such asa proper RDS implementation, proper AF, etc.) as much as they did maybe 15 or 20 years ago, when radio was the most popular way to find new music. Many people now who will listen to music in their new cars would choose streaming platforms via Android Auto and Apple Carplay, the shift has moved to making sure those have full compatibilty and can seamlessly work.
I have my fair share of experiences with stations, last year I have mailed the technical department of a national broadcast chain to add dynamic info in their stations' RT via UECP, I was only met with the fact that "they are marketing their RT" (by showing static KISS FM in RT, and dynamic PS cycling station name and frequency), and that such info is useless. Many technicians here in Romania care only if the station has audio. Using your RDS to the maximum, or even properly setting up PI codes is sadly optional :'(
Looking forward for the change regarding 0x0D, hopefully including both the old and new ways as a toggle like "Reverse CR character 0x0D assignment order", for whoever likes having one way or the other.
Thank you for your fast answers!
I have my fair share of experiences with stations, last year I have mailed the technical department of a national broadcast chain to add dynamic info in their stations' RT via UECP, I was only met with the fact that "they are marketing their RT" (by showing static KISS FM in RT, and dynamic PS cycling station name and frequency), and that such info is useless. Many technicians here in Romania care only if the station has audio. Using your RDS to the maximum, or even properly setting up PI codes is sadly optional :'(
Looking forward for the change regarding 0x0D, hopefully including both the old and new ways as a toggle like "Reverse CR character 0x0D assignment order", for whoever likes having one way or the other.
Thank you for your fast answers!
73
Control Software / Re: 0x0D issue in Magic RDS
« Last post by Jan on April 19, 2026, 09:51:45 am »I completely understand your point of view and we will take your comment into consideration at the earliest opportunity. But there are other points of view as well.
With all due respect, these systems are designed for other use than hobby DX reception. By the way, it's a nice hobby that I also pursued. Various incompatibilities and proprietary solutions of commercial FM receivers are a long-term problem which is an obstacle to development of new RDS services. Some "features", such as the completely unexpected truncation of Radiotext on some new car radios, prove that the developers have probably gone completely crazy.
We introduced the RT+ service, Long PS or broadcasting of diacritical marks (ěščřžý etc.) here in the Czech republic. Although majority of stations here can use these options today, only a small portion of them actually do it. They could simply turn it on with a few clicks, but they won't. I say this just to illustrate who is actually stuck in a time decades ago. Many stations incl. the public service radio still rely on deprecated dynamic PS. They are still convinced that they have reasons for this. Change is usually met with great displeasure. I don't blame anyone, it's just a fact.
With all due respect, these systems are designed for other use than hobby DX reception. By the way, it's a nice hobby that I also pursued. Various incompatibilities and proprietary solutions of commercial FM receivers are a long-term problem which is an obstacle to development of new RDS services. Some "features", such as the completely unexpected truncation of Radiotext on some new car radios, prove that the developers have probably gone completely crazy.
We introduced the RT+ service, Long PS or broadcasting of diacritical marks (ěščřžý etc.) here in the Czech republic. Although majority of stations here can use these options today, only a small portion of them actually do it. They could simply turn it on with a few clicks, but they won't. I say this just to illustrate who is actually stuck in a time decades ago. Many stations incl. the public service radio still rely on deprecated dynamic PS. They are still convinced that they have reasons for this. Change is usually met with great displeasure. I don't blame anyone, it's just a fact.
74
Control Software / Re: 0x0D issue in Magic RDS
« Last post by Rían Mac Guinneál (fmdx.ie) on April 19, 2026, 01:21:34 am »Perhaps, it can be a separate option on how the end user wants the CR character to function, 0x0D then spaces, or spaces then 0x0D bit, also... there are many users who probably don't have the latest firmware (example offline broadcast sites, etc.)
Also, unrelated to car tuners, but on the fm-dx webserver platform, when 0x0D is detected, the radiotext field gets centered, adding spaces "ruins" that spacing.
Now, related to car tuners, many have their own "way" of implementing the RDS spec, some maunfacturers don't account if the RT field even properly ends with 64 characters, or 0x0D,they will show the text that was decoded (skoda,vw), or DPS not being accounted sometimes for safety... etc. There are many examples of DOs and DON'Ts, but if we had to account for all old tuners, with outdated specs, or careless implementation... we would have been removing 99% of features
I second this. 💯
75
Control Software / Re: 0x0D issue in Magic RDS
« Last post by mrandrew01 on April 19, 2026, 12:41:33 am »Perhaps, it can be a separate option on how the end user wants the CR character to function, 0x0D then spaces, or spaces then 0x0D bit , also... there are many users who probably don't have the latest firmware (example offline broadcast sites, etc.)
Also, unrelated to car tuners, but on the fm-dx webserver platform, when 0x0D is detected, the radiotext field gets centered, adding spaces "ruins" that spacing.
Now, related to car tuners, many have their own "way" of implementing the RDS spec, some maunfacturers don't account if the RT field even properly ends with 64 characters, or 0x0D,they will show the text that was decoded (skoda,vw), or DPS not being accounted sometimes for safety... etc. There are many examples of DOs and DON'Ts, but if we had to account for all old tuners, with outdated specs, or careless implementation... we would have been removing 99% of features
, also... there are many users who probably don't have the latest firmware (example offline broadcast sites, etc.)Also, unrelated to car tuners, but on the fm-dx webserver platform, when 0x0D is detected, the radiotext field gets centered, adding spaces "ruins" that spacing.
Now, related to car tuners, many have their own "way" of implementing the RDS spec, some maunfacturers don't account if the RT field even properly ends with 64 characters, or 0x0D,they will show the text that was decoded (skoda,vw), or DPS not being accounted sometimes for safety... etc. There are many examples of DOs and DON'Ts, but if we had to account for all old tuners, with outdated specs, or careless implementation... we would have been removing 99% of features
76
Control Software / Re: 0x0D issue in Magic RDS
« Last post by Jan on April 19, 2026, 12:09:25 am »You have a great observation. This is not a fault, it is an implementation from a time when it was more convenient to do it this way for compatibility with some old receivers. Receiver support for shortened text has not always been very good in the past. You are right that today there is probably no reason to place the CR character always at the end of a segment.
Given that today the most widely used RDS encoders are probably from our production, we are reluctant to change any detail that has been set in some way for 20 years, so as not to unintentionally influence something. However, if a different opinion prevails, a change is of course possible.
Given that today the most widely used RDS encoders are probably from our production, we are reluctant to change any detail that has been set in some way for 20 years, so as not to unintentionally influence something. However, if a different opinion prevails, a change is of course possible.
77
Control Software / 0x0D issue in Magic RDS
« Last post by mrandrew01 on April 18, 2026, 11:40:02 pm »Hello! I have noticed a very small "fault" if you could say with the carriage return character 0x0D, that being the addition of spaces before the 0x0D character. Implementation from other known brands include 0x0D as the first character in the 2A group, and afterwards how many spaces are needed to fill the group.
EXAMPLE : Benassi_Bros._Feat._Dhany_-_Hit_My_Heart___<0D> could be : Benassi_Bros._Feat._Dhany_-_Hit_My_Heart<0D>___
with the carriage return character 0x0D, that being the addition of spaces before the 0x0D character. Implementation from other known brands include 0x0D as the first character in the 2A group, and afterwards how many spaces are needed to fill the group.EXAMPLE : Benassi_Bros._Feat._Dhany_-_Hit_My_Heart___<0D> could be : Benassi_Bros._Feat._Dhany_-_Hit_My_Heart<0D>___
78
Control Software / Linux CLI tool for RDS encoder control
« Last post by Jan on April 15, 2026, 09:30:51 pm »https://github.com/tuxikcz/pira_rds
Supports mRDS1322, PIRA32 and all compatible models.
Thanks to Tuxik
Supports mRDS1322, PIRA32 and all compatible models.
Thanks to Tuxik
79
P275 FM Analyzer / Re: P275E
« Last post by Jan on April 15, 2026, 11:57:39 am »Okay, so the cause has been found and it was a faulty power adapter. If anyone experiences a similar problem in the future, we will replace the power adapter with another one free of charge. We no longer supply power adapters from the mentioned series.
The P275E documentation has been updated (section Recovery, added instructions for resetting the password).
The P275E documentation has been updated (section Recovery, added instructions for resetting the password).
80
Feature Requests / Re: MagicRDS4 UECP
« Last post by Jan on April 14, 2026, 06:43:12 pm »Unfortunately, direct implementation in Magic RDS is not possible at the moment. I recommend choosing the virtual port method I suggested earlier.
Since the old program does not support TCP or UDP, use the com0com utility according to this procedure:
To allow communication between Magic RDS and third-party software that supports only serial (COM) ports, you can use a virtual serial port pair (also known as a "virtual null-modem cable").
I recommend using the free utility com0com, which creates two interconnected virtual COM ports.
Setup procedure:
Download and install the com0com package from:
https://sourceforge.net/projects/com0com/
After installation, open the setup command prompt (included with com0com) or use the graphical setup if available.
Create a virtual port pair. For example:
COM10
COM11
These two ports are internally connected – any data sent to COM10 will appear on COM11 and vice versa.
Configure the third-party application to use one port (e.g. COM10).
Configure Magic RDS application (Virtual Port) to use the other port (e.g. COM11).
Notes:
Both ports behave like standard hardware serial ports.
Baud rate and other serial settings should match on both sides.
If a port number is already in use, choose a different one.
Administrator privileges may be required during installation.
Since the old program does not support TCP or UDP, use the com0com utility according to this procedure:
To allow communication between Magic RDS and third-party software that supports only serial (COM) ports, you can use a virtual serial port pair (also known as a "virtual null-modem cable").
I recommend using the free utility com0com, which creates two interconnected virtual COM ports.
Setup procedure:
Download and install the com0com package from:
https://sourceforge.net/projects/com0com/
After installation, open the setup command prompt (included with com0com) or use the graphical setup if available.
Create a virtual port pair. For example:
COM10
COM11
These two ports are internally connected – any data sent to COM10 will appear on COM11 and vice versa.
Configure the third-party application to use one port (e.g. COM10).
Configure Magic RDS application (Virtual Port) to use the other port (e.g. COM11).
Notes:
Both ports behave like standard hardware serial ports.
Baud rate and other serial settings should match on both sides.
If a port number is already in use, choose a different one.
Administrator privileges may be required during installation.