Pira.cz Technical Forum
Magic RDS 4 => Feature Requests => Topic started by: zvykov on June 02, 2023, 03:55:48 pm
-
Hi Jan, I've been using your app for a long time, it's good and flexible. But i ran into a coder who understands uecp commands very badly.
UECP support is declared by the manufacturer and the original encoder control program also sends via uecp, but the syntax is slightly different. I give a log from the original application. Is it possible to connect them somehow?
log:
-> "0A01004105444A20534D4153482026204E495645535441202D20506F7A766F6E69202020202020202020202020202020202020202020202020202020202020202020202020"
-> /RT (01,00) # 05 "Clear,2,Tgl" 'DJ SMASH & NIVESTA - Pozvoni ' ;
-> Port: COM1(19200, NO, 1000)
-> 0000 09 45 0A01004105444A20534D4153482026204E495645535441202D20506F7A766F6E69202020202020202020202020202020202020202020202020202020202020202020202020 3B1D
-> FE000009450A01004105444A20534D4153482026204E495645535441202D20506F7A766F6E692020202020202020202020202020202020202020202020202020202020202020202020203B1DFF
-
I tried to add various initial commands, but also did not achieve a result, any ideas? I really want to set up this system.
-
[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
-
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.
-
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.
-
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.
-
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.
-
I'll add the field edit into the nearest update.
-
Thank you for your responsiveness.
Is there an estimated release date?
-
Updates are usually released in 1 to 2 months periods.
-
Okay, I will be waiting.
-
Everything works in the new version, thanks :D
-
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.
-
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.
-
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".
-
Unfortunately, the original program works via RS232.
-
Are there solutions to this problem using only MagicRDS?
An example of the required synchronization command is available.
-
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.
-
Yes, that's what I did. It seems to have worked, even though it's a "workaround."
Thanks.
-
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.