BW Broadcast FM transmitter TX1000V3

[South Coast FM Tech]

Hi Jan,

In response to your recent query about our experience with BW Broadcast transmitters & MagicRDS4....

As you may know, BWB has currently stopped trading due to tragic circumstances & their website has just been pulled down.

We have been using a BWB DSPXmini Encore Audio Processor for the last 2 years with no RDS update issues. It generates an MPX signal that is then transmitted via STL to our FM transmitter sites. (The firmware is DSPXminiFM.0.330 2019-03-19, which as far as I know is the latest).

Recently, we have introduce AoIP direct to our FM transmission sites, which means we need to send the RDS commands direct to the FM transmitters.

We are currently having problems with the BWB TX1000V3 & RDS. It initially accepts RDS radiotext updates, but stops updates after some time. (The firmware is V3.0 2019-10-14, which as far as I know is the latest).
 
The transmitter continues to allow IP access & control via its web interface & can still be pinged & monitored via SNMP.

It's just RDS comms over IP that seems to stop. The radiotext is not updated for a period. Then after what must be a transmitter timeout period, the RT text configured in the transmitter is displayed.

In MagicRDS4, I'm currently using the Readbest device model, TCP Client & Port 1000. Bidirectional unticked. 

The TX1000V3 RDS setup is Ethernet1 On, UDP Off, Port 1000, Ethernet2 Off, UDP Off, Port 1000, RS232 Off, Baud 19200. 

I haven't needed to restart the Transmitter to re-establish RDS updates.

I just log into the Transmitter web interface & then switch 'RDS Ethernet1' Off & then back On.

After that, it then works for a period, but then stops again.

cheers, Rod

[Jan]

Thanks, Rod. So this problem remains in the BW products. Of course, it is not likely that somebody will ever fix that. Our abilities in this matter are, in principle, limited.

The problem seems to be in the Ethernet port. This port is created and handled by the BW firmware and by the modified Free RTOS they used. The data is not interpreted at this level because the RDS encoder is a next stage. So any kind of data would probably lock the Ethernet after some time.

We may try a periodical TCP reconnect, maybe the socket release and establishing a new connection will have the same effect like the Ethernet Off/On in the BW menu, if that occurs before the locking. The disconnect/connect commands will be added to the Magic RDS 4 script repertoire.

[Jan]

In version 4.0.34 or later, following script command can be executed (for example by Task scheduler):

Code: [Select]

connection action:reconnect name:"connection_name_here"
Maybe this helps, or maybe not 

[South Coast FM Tech]

Hi Jan,

Thanks. I've tried reconnecting to the transmitter via the MagicRDS4 task 'connection action:reconnect name:"TX1000V3"'
Unfortunately it doesn't re-enable the TX1000V3 listening to RDS commands.

If I connect directly to the TX1000V3 via Telnet using PuTTY & switch the RDS Ethernet Off & then On, it fixes the issue until the next time it hangs.

Connect to TX1000V3 transmitter using Telnet on Port 23
Welcome to the TX-V3!
password: ****
TX-V3 > set system.rds_interface.network.0.enable off
Off
TX-V3 > set system.rds_interface.network.0.enable on
On
TX-V3 > exit

I note that MagicRDS connection "TX1000V3" changes status to 'TCP Reconnecting' whenever the transmitter stops accepting RDS text updates.

Assuming I had a Telnet script called 'TXV1000V3 fix.bat' that would send the required transmitter ethernet commands via Telnet, is there some way I can use the MagicRDS connection status change to trigger the reconnection script?

thanks, Rod