Although I said the Java client works well, what I should have said is that it starts and shows the GUI. I haven't been able to use it with a modem yet as I haven't a working FLDigi 3.10 yet. What I'm doing now is compiling FLDigi 3.10 in the ASUS SDK (The SDK is based on the same old Xandros distro as found in the EeePC's).
When I have a working binary, I will make it available here.I've done this with other software (including older versions of FLDigi), but I'm getting a few compile errors this time. Give me until this afternoon (Australian time) before throwing your EeePC out the window ;-)
Steve. Rein Couperus wrote:
Steve,how did you get fldigi-3.10 to work on xandros? I get the message GLIBC_2.4 not found....I have been messing with my eee 901 now for 2 hours, and have given up... Xandros really seems to be 15 years behind. Rein PA0R-----Ursprüngliche Nachricht----- Von: "Steve" <stevez@xxxxxxxxxx> Gesendet: 22.03.09 00:41:25 An: pskmail@xxxxxxxxxxxxx Betreff: [pskmail] Re: Mirrors updatedHello John,Before you go and do anything "rash" (such as going to Windows), please have a look at the instructions on installing the official Sun Java VM at :-Give it a go and keep that 18 second boot time ;-) Steve Z. John Douyere wrote:Rein,Great progress. With V0.30 I noticed one little thing when using it under Mandriva 2007: when I click on other modes, it changes the fldigi modem correctly, but the radio buttons on the UI do not always reflect the proper mode selected (sometimes it shows two modes selected).In fact since I can run the client under Windows I have decided to change my eeePC to Window$ (I know, I know...), since I can't run the java client without doing an upgrade anyway and my wife is having difficulties handling the Linux OS (we both use it when going away). The good new is that I still keep a Puppy Linux version on the SD card so that I can still boot Linux and "have a real computer" :)Rein and Per please keep up the great work on the java client.I am also progressing on the THOR mode issue I had here and I will be sending a log extract, analysis and proposed code change for your review. In short I believe (and I am testing that now) that the second <EOT> added by THOR at the end of the blocks is creating an issue: the receiving of the blocks is not stateless in ARQ.PM <http://ARQ.PM> and therefore it gets confused believing it has a complete block, but the unpacking routine interprets it as a block in waiting, resulting in the server not timing out and not transmitting.Regards, John