Setting up DJB Zones automation with a Pira P164 and Magic RDS4

[Tom McGinley]

I am asking a very basic setup question here. I have a brand new PIRA P164 encoder that can receive RDS data via serial or TCP/IP. I have it connected to receive RDS data from our DJB Air server via an ethernet switch that handles our DJB subnet. The Magic RDS4 app is loaded for now on a separate DJB file server. The P164 pulled a DHCP IP on the DJB subnet at 192.168.91.211.  I've tried to get it configured to receive the RDS text data being generated from the DJB Air server which we see scrolling on the Hercules data capture app on a connected DJB production machine. I added the PIRA P164 IP as the target device in the DJB Air server Metadata setup screen: 192.64.91.211:10001. The Magic RDS4 tool allows setting up the P164 encoder as either a TCP client or TCP server. I have it set as a TCP server.  I presume other DJB machines with the Magic RDS4 app loaded and running will be TCP clients and can show the RDS scrolling data as air events change. The P164 shows as connected to the Magic RDS4 Tool but I am not seeing any text data coming into that app's Viewer from DJB. Perhaps I don't have the TCP setup or ports assigned correctly.

I am quite familiar with the older PIRA RDS ethernet connected encoders without any middleware with good success. Those models had a much easier web UI to do the IP setup plus static PS and RT messages with windows that scrolled the RDS PS and RT data as it updated from the automation. It didn't need the Magic RDS4 tool. The P164 web UI (port 80) does not offer that and only shows the static ethernet setup parameters.   What am I missing to get this configuration corrected before I try connecting the P164 to my transmitters SCA input to see RDS texting on car radios?

[Jan]

Compared to older models, the P164 is more robust and easy to set up if you follow the instruction. Some functions, like the RDS web UI or additional TCP ports, were moved to the Magic RDS 4 middleware. Although this change does not seem to bring many advantages for a station with a single transmitter, for larger broadcasting networks the benefit is quite significant as such network needs some kind of middleware in any case and all RDS encoders are now accessible from one place, one IP address and under one login.

For example: Need to change PS name on all 40 encoders in the network? You need no more than 30 seconds for such task:
Menu Script/Execute: send connection:* command:"PS=New PS" command:"*PS"
You are done. Imagine how long does this take if you need to log into each encoder individually. Or how to feed "now-playing" data or TMC data to each encoder individually, how many public IP addresses you need etc.

Back to your question: The P164 allows both modes of operation, either with or without the Magic RDS 4 middleware. If you don't need the benefits of the middleware, you can connect your broadcast automation system directly. The broadcast automation system must support some of the common data formats, like ASCII, UECP or XCMD.

In your case, if you specified the RDS encoder's IP address in your system, the encoder needs to be set up as TCP server. The easiest way how to make initial TCP setup is to use the Magic RDS 4 and USB connection, as described in the manual, section 'Ethernet Connection'. You may keep the Magic RDS 4 connected to the USB, click on the RDS Spy button to verify that your system sends the data correctly. Then you may close the Magic RDS 4 as the setup is done.

If you decide the use the Magic RDS 4 middleware, your broadcast automation system will not connect to the RDS encoder(s) but to the Magic RDS 4. For this purpose the Magic RDS 4 supports the Virtual Ports. They operate the same way like any other TCP ports and they represent common data inputs for particular encoders or for all encoders, with data visualization feature included. See the m4vp.pdf help file for details and examples.