Post reply

Name:
Email:
Subject:
Message icon:
Verification:
Unregistered users must pass a verification:



Please enter the number from the picture above which is showing FM broadcast antenna:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Jan
« on: Yesterday at 07:29:49 pm »

Sure, it’s not your fault that we all got so confused by this. But it wasn’t intentional, either. It is actually possible that the final series of this transmitter model really did contain the P232 chip, meaning the documentation is valid — it just doesn’t apply to every single variant they used to manufacture. Unfortunately, this isn't an isolated case; some users of transmitters from brands like BW, for example, have had similar experiences.
Posted by: andrew01
« on: Yesterday at 07:12:59 pm »

Quote from: Jan on Yesterday at 06:50:11 am
Please, let us not mislead other users with incorrect information. This device does not contain a P232 chip or any other encoder manufactured by us.

Unfortunately, RVR has caused us harm — not only through unpaid debts but also by including misleading information in their documentation.

If the built-in encoder does not meet your needs, we can offer you an external encoder; however, we certainly cannot provide support or software for unknown legacy products.
Thank you for offering your encoders as an option, I have already recommended a model (P164) from your production line to another station that wants to ditch their old 90's AEV RDS encoder and take their RDS setup to the next level ;D , although, in this case, the people with this RVR transmitter already have recent RDS solutions from DEVA Broadcast, and we mostly wanted to test that this function embedded in the transmitter does work.

It's honestly shocking for a "respected" company to fake their documentations, as these are usually the most trustworthy (or should be), pieces of information you can have for the transmitter you own, especially from the manufacturer!  :-[

In this case, it would probably be a good idea to update the debtors page on your site, adding RVR and other companies alike that have unpaid debts, just so people are aware when choosing to collaborate with them.  ;)

Thanks again for the support through this messy "trip" with the built-in RDS encoder!  :)
Posted by: Jan
« on: Yesterday at 06:50:11 am »

Please, let us not mislead other users with incorrect information. This device does not contain a P232 chip or any other encoder manufactured by us.

Unfortunately, RVR has caused us harm — not only through unpaid debts but also by including misleading information in their documentation.

If the built-in encoder does not meet your needs, we can offer you an external encoder; however, we certainly cannot provide support or software for unknown legacy products.
Posted by: andrew01
« on: Yesterday at 12:22:07 am »

Hi!
Sorry for the late response, we forgot to check on the transmitter for a while, but, after the battery replacement I have mentioned, the encoder was reset to it's default settings,there are no more group losses, and the group sequence indicated seems is the same as Pira encoders, so there definetly is a P232 chip!
We have contacted RVR's support team for the original control software, and we will see how the embedded RDS chip will perform from now on.

Also, I know I have said it before, but, it's quite weird seeing a external application that controls chips from your production line have an extra function to set a custom exact group sequence, while Magic RDS, the original control application doesn't have this function, while I understand the legacy logic behind the current group sequence, something to coexist with the legacy Dynamic PS oriented mode, and the "modern" exact group function, would be the final touch that makes the software more... to the liking of the user.  ;)

Posted 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.
Posted 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?
Posted 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.
Posted 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
Posted 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.
Posted 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.
Posted by: Jan
« on: August 27, 2026, 09:57:33 am »

It is true that we have supplied a certain amount of P232 chips to R.V.R. in the past, but the cooperation was terminated because they violated the terms of business and subsequently stopped communicating.

Unfortunately, I do not know the technical details of their implementation. If your device really has a P232 chip and UECP communication works for you, then the P232 model must also work. Unless someone blocked ASCII commands using the PAC function. However, this is normally not possible to do from the port on which communication is being carried out, it would have to be done from the other communication port. Moreover, this blocking cannot be performed at all on one of the ports. I do not know which communication ports are accessible in this device.

Try both communication ports, if possible. Communication must always work on one of the ports, it cannot be blocked by any setting. If only one port is accessible on the panel and it is the blocked one, you can also solve the situation by replacing the EEPROM (24LC512/M24512). But it's quite possible that there's a completely different type of encoder inside that doesn't come from us.

See also Magic RDS 4 Help - devices.pdf
Posted by: andrew01
« on: August 26, 2026, 10:43:51 pm »

Hi!
I have been recently helping a fellow colleague with his "new-old" secondhand RVR TEX300LCD (/RDS-TEX2HE) with a integrated P232 RDS Encoder (from the schematics)
We don't have the original WINRDS+ software CD, so we are using Magic RDS 4 configured as a Generic UECP encoder (as we have tried to set it up as an P232 and it would not send anything at all).

UECP communication is working. We can successfully read/write data, and any changes I make to the PI code and Radiotext update perfectly.
However, we cannot get rid of the old Dynamic PS.  :(

Whatever scrolling text was programmed into this board years ago (presumably using WINRDS+) from the old broadcaster is stuck looping. Even though Magic RDS 4 shows the new PS as being "sent", the board does not want to comply and just keeps on sending the old text that was programmed before...

Any help is appreciated, but mostly, is there any mode to fully flush the EEPROM from that old dynamic PS?
Thank you  :)