Hi Per,
If the current version can run on the RPI 3, could you check the CPU load
of the Java modem, especially with the Thor modes. In my experience there
is a big difference in CPU load between the C and Java versions.
Regards,
John (VK2ETA)
On Wed, Jun 15, 2016 at 5:37 PM, Pär Crusefalk <per@xxxxxxxxxxxx> wrote:
Hi,
I'm running the server on a raspberry pi 3 and it seems to run pretty
good. That is everything but fldigi is running fine. I'm using ubuntu mate
16.04 and that has fldigi 3.23.01 on its mirrors. So I started out by
trying that version and it had the PSKR inverted squelch problem so was
basically useless.
I briefly considered going for the safe choice of fldigi 3.21.83 but that
would not give me any hope for the future. For the future we really need
the version that comes with the distro to work out of the box, 3.21.83 will
at some point have too old requirements to compile. So, I compiled 3.23.09
and it worked fine on PSKR and seemed ok. I use that with pulseaudio btw.
But, after a day fldigi will lock up. I often come to the shack and find
the rig stuck in tx. I just restarted fldigi and 15 mins later it had the
transceiver stuck in tx again. So, 3.23.09 is no good either.
So, I've come back to the old conclusion that we need to do something
about the modem. Fldigi is fine for a QSO here and there but its not fit
for this use. I would like to go back and have another look at the
javamodem. Perhaps we should compile a few requirements for that and make a
dedicated effort to get that modem really work well. It does work now but
I'd like to get rid of the GUI as much as possible etc.
I'd like it to have a tx watchdog, settings for the US hf speed jail etc.
Or, is the javamodem already good enough?
73, Per
sm0rwo
