MAGIC4 Bridge virtual port TCPIP telnet syntax

[davidmb]

Hello,

I'm trying to configure Magic RDS 4 with Bridge connection & virtual port to recive input commands from playout system via telnet, simple ascii tcp commands and route them to external text.

On my playout system telnet connection module is doing basic TCP communication without any header or protocol , just a simple TCP transportation of ASCII string which are the command used for GPIO.
 
On MAGIC 4 VP connection status I see that some RX packets do come in (packet count raises when issuing a command from playout), but after that nothing gets decoded on RX monitor. I have default allow * in filter so this should not be a problem?
If I try to connect to it with windows telnet client, the commands do get correctly reckognized and forwarded to External Text as ASCII: X

So my question is - is there any special syntax that needs to be added to "TCP communication without any header or protocol , just a simple TCP transportation of ASCII string" that my playout is doing for Magic RDS VP to correctly recieve this commands? Like adding <CR> or something?

Thanks for your help in advance and br, David

[Jan]

Yes, the <CR> is required, to identify end of the string.

[davidmb]

Hi Jan,

thank you for a fast reply.

I already tried this, but unfortionaly no luck.
I'm guessing this is added by default after each command by playout software already.
Is there anything else specific that windows telnet client does? Like some prefix maybe?
When testing with windows telnet client I saw that Magic 4 VP telnet server is also sending echo return of every recived command?
Is there like a verbose debuging mode, so i could se exactly what Magic4 Vp is Rx/doing?
Or any other idea what to check?
I'm using the same telnet client TX module of our playout Sw also with other softwares  - like  Axia Pathfinder for instance - and there it works without a problem.

Thanks and Br, David

[Jan]

The VP behaviour is simple, it collects ASCII text and passes it once the <CR> is received. If you see counting data but no text in the RX monitor, the <CR> is missing.
An exception from this rule is receiving UECP start byte 0xFE which switches the VP to UECP mode until timeout or 0xFF

[davidmb]

Hi Jan,

thanks for your feedback.
Did a bit of investigation and it seems that IO module that I'm using indeed does not support sending <CR>.
It does send <LF> at the end of each command, but not <CR>.
If I understood developers correctly this behaveiour is prefered beacuse for instance Axia ecosystem works like that.

Is there any way we could find a solution for this on your side?
Maybe you could add an optionale setting in VP telnet server - to react only to <LF>,?

Thanks for your help in advance and br, David

[Jan]

Thanks for detailed info. The <LF> currently does not act as a separator but it is completely removed from the ASCII text, because the VP now represents a RDS encoder's communication port even if it is used for general purpose. User-selectable separator is already on 'TODO' list.

[davidmb]

Hi Jan,

ok, thanks for the feedback.
 
Great info!
Any timline already in place when can we expect user-selectable separator to be implemented?

Br, David

[davidmb]

Hi Jan,

I did a bit more investigation and it seems that when my client connects to the Magic4 telnet server the first mode server is into is UECP?
If for instance i connect to server with putty - this is what I get back from it in my terminal window:
ÿśÿÿśÿ

Also in RX monitor I see this:
UECP: <FE><FF>
UECP: <FE><FF>

If I press enter in putty terminal window I see this in RX monitor:
ASCII: ÿśÿÿśÿ

And only after I initialy send first CR, then I can start sending my ASCII commands.

Is there some special type of connecting procedure to telnet server (putty settings?) or string in the beggining of command to let the server know we want ASCII?
I have a feeling that this is the problem I'm having when trying to script my telnet client...

Thanks for your help in advance and br, David

[Jan]

The VP supports terminal echo, this is the reason why you get the string back. The echo can be disabled by ECHO=0, but your case requires a more complex solution: the VP now behaves like a real port of the RDS encoder, incl. some specific characteristics which may not be useful for general purpose usage. We're working on adding options for the VP control.

[davidmb]

Ah ok, now it makes sense.

Will wait then for the additional VP options to be added.

Thanks for the feedback
Br, David