I'm sorry you're disappointed. We would welcome any suggestion on how to improve the product's online documentation, as in my opinion all the characteristics you're mentioning are listed explicitly and are known before buy.
Both the P332 and the P164 were originally custom developed for specific big broadcasters. The difference between the units is ~10 years. In 2010 the requirement was RS-232 port and individual control of each box. In 2020, the requirement was single access point for entire network and low costs. This is in line with the general trend. After the ConnectOne company has closed in 2018, we haven't found any equivalent Ethernet controller for the P332 encoder. Since the FM broadcasting is entering end-of-life period and the market prefers all-in-one FM exciters, developing any new encoder similar to the P332 makes no sense.
I fully agree that the P332 was a great unit, as well as that two ports are more than single port. On the other hand, there's no solution based on individual hardware boxes which can cover typical needs of today's radio stations. The P332 users are running the Magic RDS software 24/7 as well because it provides single access point for the data, unlimited number of data ports tied to any group of encoders, RDS scheduling, text processing, data filtering... You may change any parameter on all encoders at once using a single-line script, you can enable data monitor on any port and see the data in real time. Once we finish the WEB API for the Magic RDS 4, the remote control will finally be complete, without need a table of IP addresses and locations, by the way.
Compared to the P332, the P164 supports UDP broadcast for basic Ethernet configuration so using the ConfigTool you can simply configure a temporary session for TCP connection even if the network configuration has previously changed (for example the subnet IP address). Compared to the P332, the P164 supports alternative data source, it automatically connects to another IP address and port if there is no data for specified time, for example due to network failure or data source failure. Is it still so bad?
In conclusion, I would like to point out that our RDS encoders never lock up. It is because they do not use any operating system, the functional core is low level coded, continuously monitored by advanced watch dog timer and absolutely stable. That's one of the reasons why our RDS chipsets are so popular and can be found in various 3rd party products. If you cannot reach the device via TCP connection after some time, it is because the device was not configured according to the manual. The phenomena is called "Dropped TCP connection" which occurs for example in large networks which change their topology or if some network component reboots. Once you enable the Inactivity timeout or Fail-Safe Monitor or both, the unit always releases the port resources and will accept new connection. Similar solution was present in the P332 as well. The difference is that in the P164 the timeout is not enabled from factory.
I fully understand that the P164 cannot replace the old P332 in all applications, for example if the user is not permitted to install any software on the radio server. Such situation however does not characterise the RDS encoder.
