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: zvykov
« on: Yesterday at 02:55:51 pm »

Unfortunately, the original program works via RS232.
Posted by: Jan
« on: Yesterday at 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: Yesterday at 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.
Posted by: zvykov
« on: June 14, 2023, 09:38:45 am »

The encoder has the ability to read what is loaded into it.

Here is from the original app:

RT[01](64) Clr, 2, Tgl, 'Egor Kann - Se lya Vi                                          '   0A0101410545676F72204B616E6E202D205365206C7961205669202020202020202020202020202020202020202020202020202020202020202020202020202020202020                             


here is from magicrds:

RT[01](64) Clr, 0, Tgl, 'Egor Kann - Se Lya Vi                                         '   0A0101410145676F72204B616E6E202D205365204C79612056692020202020202020202020202020202020202020202020202020202020202020202020202020202020

Conducted an experiment, the problem is in the marked.
Posted by: zvykov
« on: June 14, 2023, 09:09:21 am »

Hi Jan. Tried your method, no change. The encoder behavior remains the same: normally accepts the first command, then stops. From the original, too, no longer accepts after that. Reset helps, and after that another message pops up from magicrds, which was not shown, but, apparently, got into the encoder memory. It works fine with the native app, but it's terribly inconvenient.
Posted by: Jan
« on: June 13, 2023, 09:09:13 pm »

[FE 00 00 09 45 0A 01 00 41 05 44 4A 20 53 4D 41 53 48 20 26 20 4E 49 56 45 53 54 41 20 2D 20 50 6F 7A 76 6F 6E 69 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 3B 1D FF]
 Site address (0), Encoder address (0)
 MEC 0A - RT: DSN (1); PSN (0); MEL (65); '00000101' "DJ SMASH & NIVESTA - Pozvoni                                    "

I do not see anything non-standard, except the DSN field which they send with a value of 1, usually the value is 0 (current data set), effectively covering any data set. Maybe the coder does not understand the value of 0? You can specify the value of 1 in the External text tool for that coder:

sendto "Connection xxx" dsn:1
Posted by: zvykov
« on: June 13, 2023, 10:20:36 am »

I tried to add various initial commands, but also did not achieve a result, any ideas? I really want to set up this system.