An initial version of the reworked cockpit is here. This page describes how to get that reworked cockpit going on ISFS servers and optionally on user systems.
The current conventional installation puts all the required jar files into a single directory. Basically, on Linux copy cockpit_linux64.jar and the two 4.8.7 qtjambi jar files to the same directory on your local system. On mac, copy cockpit_macosx.jar and the two 4.8.6 qtjambi jars. I plan to package it and make it easier to update, so this is a temporary location for the jar files.
There is a script
install.sh which does the same thing more conveniently. For example, on the ISFS server ustar, there is a git clone of the cockpit source tree in
~/isfs/src/java. Here are the steps to update the installation in
cd ~/isfs/src/java/edu/ucar/nidas/apps/cockpit/deploy ./makejar ./install.sh ~/cockpit
The cockpit script runs the jar file, optionally with a default server. Run `cockpit -h` to see the usage. So on ustar or eddy, run cockpit like this:
The actual jar command can be run explicitly like this:
java -jar cockpit_linux64.jar
java -XstartOnFirstThread -jar cockpit_macosx.jar
Running on User Systems
The instructions above are enough to get cockpit running on someone's personal system also. However, in Perdigao, to receive the data, they would need to be on the tower network, so really at the moment that's not an option. If we were to support that, then it would be convenient to create zip archives with the Mac and Linux jar files, and then distribute those through the ustar web server.
Options can be appended to the java runstring. Add a "-h" option to the above to see the options.
No data feed
Sometimes it happens that all the UDP data stop flowing from the dsm_server running on ustar. If the sorters run out of memory, then they start dropping samples. The solution is to try restarting dsm_server on ustar:
systemctl --user restart dsm_server
If cockpit won't connect to the server, the firewalls on the server or your machine could be blocking transmissions. Enabling "Log connection debug messages" in the connection dialog may help determine what is going on.
The firewall on the server should allow incoming connections on TCP port 30007, and UDP port 30005.
The UDP port that receives data packets on the client will vary on each connection unless you set it with the "-u" runstring option. Pick a value above 1024, below 49152. For example "-u 30050".
If you're using multicast, the UDP port is 30002, and you don't need the -u option.
This is built from the master branch on https://github.com/ncareol/isfs in src/java/edu/ucar/nidas
Let me know of the inevitable bugs. A version for windows can be created if there is a need.
You will likely see warning messages like this:
modalSession has been exited prematurely - check for a reentrant call to endModalSession
Reports on the web indicate that this is a bug in Qt4 on Macs. In my limited testing it didn't seem to cause any problems.