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: April 22, 2026, 08:54:49 am »

It's nice to hear that it is working  ;D

Unfortunately, a better solution cannot be provided for these old devices unless the complete communication protocol specification is available. The process of reverse engineering is expensive, with no guaranteed result, and never worth it if it just extends the life of a few pieces of old hardware.
Posted 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.
Posted 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.
Posted by: zvykov
« on: April 14, 2026, 02:24:02 pm »

Are there solutions to this problem using only MagicRDS?
An example of the required synchronization command is available.
Posted by: zvykov
« on: April 13, 2026, 02:55:51 pm »

Unfortunately, the original program works via RS232.
Posted by: Jan
« on: April 13, 2026, 10:07:50 am »

If an RDS encoder requires data reception using a non-standard protocol, this can be handled using a virtual port in the Magic RDS 4. You connect the proprietary applications to this port and there, the redirection will be performed directly to the encoder Connection(s). The condition for using this procedure is, of course, that the proprietary application supports TCP or UDP connection.

For complete setup see m4vp.pdf, section "Data Splitter for RDS Encoders".
Posted by: zvykov
« on: April 13, 2026, 09:49:22 am »

I think I've come up with a way to implement time synchronization on the problematic encoder.
My idea is to use the MagicRDS scheduler itself and, say, send a time command (e.g., 00:00) to the encoder every midnight. The command (code) itself, given the "original" application, would need to be calculated.
What do you think of this implementation? Or are there more correct and logical approaches?
...
But it is unclear what to do with the date in this case.
Posted by: zvykov
« on: April 10, 2026, 06:12:25 pm »

Hi, Jan!
It's been a while, but I'm still actively using MagicRDS4 and never cease to be amazed by its flexibility and reliability.
I encountered another issue with the fora600k encoder, the nuances of which were previously discussed in this thread.
I wanted to expand the functionality and transmit precise time, but the control instructions for this encoder are clearly written in a non-standard way. If I enable time synchronization in MagicRDS4, it accepts it, but displays a completely incorrect date/time.
As far as I understand, the encoder's native software contains a small program that captures the time and immediately sends it to the encoder. The code it sends is below:
:> 2026.04.10 19:08:11.929
-> "19010D7E040A10080B0006"
-> /RTCON 01 ;/RTC 7E040A10080B0006 "10.04.2026 16:08:11 +3"  ;
Is it possible to send something similar from MagicRDS or is there a way to solve this problem?
As always, thanks in advance.
Posted by: zvykov
« on: August 04, 2023, 06:53:01 pm »

Everything works in the new version, thanks  :D
Posted by: zvykov
« on: June 14, 2023, 01:16:06 pm »

Okay, I will be waiting.
Posted by: Jan
« on: June 14, 2023, 12:15:38 pm »

Updates are usually released in 1 to 2 months periods.
Posted by: zvykov
« on: June 14, 2023, 12:04:58 pm »

Thank you for your responsiveness.
Is there an estimated release date?
Posted by: Jan
« on: June 14, 2023, 11:59:52 am »

I'll add the field edit into the nearest update.
Posted by: zvykov
« on: June 14, 2023, 11:43:35 am »

Thanks,  I just really want to work normally with this encoder from magicrds  8)
I suppose there is a chance to see this tweak in future releases?
Encoder model fora600k.
Posted by: Jan
« on: June 14, 2023, 11:09:09 am »

You made a great analysis  8)

So the coder does not meet the UECP specs at this point:

5th byte:
Bits 4..1: 0 Indefinite transmissions

Instead of infinite loop of such RT, the RT is never transmitted. Very treasonable, making the coder almost useless in many cases. On the other hand, it must be mentioned that the UECP document is not written well in some aspects.

The Magic RDS 4 needs to be updated because this field is currently not user configurable. Please let us know the coder model and manufacturer, as this may be useful to know for other users.