Tech Notes from the Field

So here’s the deal with Padapult. After talking with Audemat regarding sending RDS updates via Ethernet it was decided to go with a TCP connection using Port 23, Telnet. We are on a closed, so no problem. Send the PS_Text= to the IP address of the FMB80 using port 23 and all is good. It works. All is better. BUT WAIT! Nothing after a day, or half day, or random time. Shoot a whole weekend without issue and then nothing? What up?

We run a packet capture on the monitor port for the Padapult computer. We document that the RDS is being sent properly. As it works we see the data is spit out. Shoot, it’s only ASCII text. Then we notice that it stops. The Padapult software says it sends the data. The packet capture shows nothing from the source IP, Padapult computer. So the application shows it sends the data, but the computer is not sending the data. Now what? We restart the application and all is good to go again. Something is up with Padapult, that is certain. Enco does it again!

We run 3 instances of Padapult on one computer. We send PSD (formerly PAD) data to the HD Exporters, we send RDS data to the FMB80’s, and we send twitter updates. The PSD and twitter updates work continuously, but that RDS data is flakey. If we check the initialize connection on each send the RDS data does not fly at all, so that option is a wash.

We will continue to bash it until we find something tangible. It is annoying and we may go back to a serial transport which seemed to work just fine.