QCN for Linux was compiled using Debian4 running under VMWare on my Mac, which is a 2.6.18 version kernel using gcc/g++ v. I have gotten the external USB JoyWarrior sensor to work, and have compiled support for the MotionNode Accel USB sensor (but haven't been able to test the latter as it "freezes" up my Linux session).
For JoyWarrior -- you will need Linux joystick support installed, which you can probably load as a module. when you plug in the JW to the USB port, it should show up as a joystick device such as /dev/js0 or /dev/input/js0 etc (I scan for js0 to js2 assuming that's enough).
For graphics to show (either the interactive QCNLive or 'Show Graphics' under BOINC) -- you will need an assortment of OpenGL libraries support for your video card. Typical this is the Mesa3D OpenGL extensions, to provide GLUT & OpenGL, as well as X11 font support etc. See http://mesa3d.org if your Linux distro does not have this already.
/ 
Reply
Quote
I've just received and installed a Code Mercenaries JW24F8-QCK USB acceleration sensor on a Linux-x86_64 system - SUSE 11.0 + patches to current SVN stable - kernel 2.6.25 running on an Intel Q6600@3.3GHz. The running QCN 4.40 was aborted and the latest 4.52 release downloaded whilst the sensor was attached.
The sensor appeared as /dev/input/js1 and is functional with outputs about +/-15000 for 1G on all 3 axes (I've got another joystick on js0 - a Logitech Rumblepad 2). However QCN 4.52 reported "No motion sensor found!" in the the slot directory stderr.txt file. Once I removed the other joystick, which is USB interfaced, QCN picked up the sensor and ran OK reporting "Motion sensor initialized of type 7 - JoyWarrior 24F8 USB." in stderr. It looks as if the sensor recognition code does not scan past the first joystick found in /dev/input. Once it has found the sensor it is happy to continue running even if the other joystick plugged back in as js0.
The graphics works OK on my setup (nVidia 7600GS with 177.82 drivers) but the Z and Significance graphs and text are near enough invisible due to very low contrast between the black background and the low saturation red and blue colours used for the foreground. Possibly you could brighten then up or make the background paler next time you have to fiddle with the graphics code.
Another minor glitch is that the 3D axes seem to be scaled on the value of the positive axis only. This can lead to overdrawing when large negative values are seen.
Andrew
/ Reply
Quote
Just installed my grey usb on Ubuntu 8.10 AMD64. No error messages.Boincmgr seems happy. However, graphics show flatline on X and Y. Z and significance show data. Is that OK? Also, I dual boot same pc between Vista and Ubuntu. Does it matter if I don't complete workunits for this? Thanks.
Clarence
/ Reply
Quote
Also, I dual boot same pc between Vista and Ubuntu. Does it matter if I don't complete workunits for this? Thanks.
It does not. The WUs are just something like a channel between your sensor and QCN site. They get usally "refreshed" once daily (or after 24 hours of uninterrupted runtime), but for the functionality of the system (observing and reporting shakes) it is not necessary at all. On some day your Vista task will get replaced, on other day the Ubuntu one...
Peter
/ Reply
Quote
On Ubuntu 8.10 AMD64. my usb joywarrior sensor shows no data on X and Y. Yet, Z and significance show data. Is this normal? How can I check to see if all the data is getting to BOIC QCN. As far as I can tell, no error message. Thanks.
/ Reply
Quote
... my usb joywarrior sensor shows no data on X and Y. Yet, Z and significance show data. Is this normal? How can I check to see if all the data is getting to BOIC QCN....
I see the same display problem under Linux (SUSE 11.0 x86_64).
I think there may be a problem when an axis has a long term average value of zero, which is the case when the accelerometer is in its normal orientation. You can test the display by rotating the JoyWarrior so that all axes are at +/-45degrees to the vertical. After a settling period whilst the average converges to the new orientation you should see that all axes are jiggling in the 3D display. This should prove out the sensor but unless Carl publishes the format of the .sac files in the trigger directory we can't be sure if the data is being captured correctly.
Andrew
/ Reply
Quote
... my usb joywarrior sensor shows no data on X and Y. Yet, Z and significance show data. Is this normal? How can I check to see if all the data is getting to BOIC QCN....
I see the same display problem under Linux (SUSE 11.0 x86_64).
You can test the display by rotating the JoyWarrior so that all axes are at +/-45degrees to the vertical. After a settling period whilst the average converges to the new orientation you should see that all axes are jiggling in the 3D display. This should prove out the sensor but unless Carl publishes the format of the .sac files in the trigger directory we can't be sure if the data is being captured correctly.
Andrew
I moved the sensor as you suggested, and the axes reflected that movement. Hopefully then QCN is getting all the right info from the sensor. Am leaving my pc on 24x7 for this so a bit more comfortable for now am not wasting electricity. Thanks for the suggestion.
/ Reply
Quote
I've been doing some more digging into the zero outputs displayed in the 3D graphics for the X & Y axes on a JoyWarrior accelerometer under Linux.
I think the problem is in the set up of the device within QCN. On Suse 11.0 Linux the joystick appears to be running with inappropriate calibration in the kernel driver. The USB device will output binary values of 0 to 1023 for the range -2g to +2g. Whilst the user values expected from a joystick device normally lie in the range -32767 to + 32767 with a dead zone about zero.
To convert from actual to the user coordinates the kernel driver holds a set of scaling coefficients, which scale the +ve and -ve axes independently about a central dead band. The calibration coefficients being used by QCN (probably SUSE defaults) were set up for a dead band for USB sensor values of 482 to 542, then linear scaling to the limits. This would suit most uses of a joystick which need the dead band to compensate for the lack of precision in the mechanical centring of the joystick levers.
However this is not what is wanted for QCN where the values of the X & Y axes from the sensor hover about 512 (representing 0g) which lies within the dead band. This causes the scaled values to be clamped to 0 until quite a substantial g force is applied to any of the X or Y axes. The Z axis works OK because it has a standing load of 1g represented by values around 775 from the sensor. This lies outside the dead band so this axis displays in the 3D display although its scaling is affected by the offset caused by the dead band.
I have tried changing the kernel driver calibration method to be "none (raw)" which does no scaling at all. The command is of the form :-
providing you have the relevant joystick utilities installed.
This causes the display of all three 3D axes to spring into life tracking the 1 or 2 bit jitter which can be seen in the raw data from the sensor.
Perhaps Carl can confirm if he expects any particular calibration of the sensor and I can then fix my joystick drivers to correspond.
Andrew
/ Reply
Quote
yeah I just want the raw values, it seems the basic linux joystick driver does some sort of pseudo-calibration. I guess it's a problem due to using the joystick driver although on Windows & Mac I can communicate fine to get this "raw" data. Since there can be various flavors of Linux and people may not have the jscal I'm not sure how to do this from within the software, other than just note it in a QCN Linux manual (if we ever write one).
/ Reply
Quote
yeah I just want the raw values,....Since there can be various flavors of Linux and people may not have the jscal I'm not sure how to do this from within the software....
Carl,
Any recent (last 7-8 years) kernel should have the joydev driver available and most end-user distributions will package this. I guess you are already using calls to this device driver to get the joystick data within the Linux version of QCN. Unfortunately the driver defaults to a broken_line style of calibration when it opens. However it has several 'ioctl' calls available which can control the calibration. The jscal utility is just a wrapper around these ioctl functions. The following snippets of C indicate one way to set a joystick to raw mode...
#include <linux/joystick.h>
#define MAX_AXES 16
int i,j;
int fd;
struct js_corr corr[MAX_AXES]
/*
* Example device open
*/
fd = open ("/dev/input/js0", O_RDONLY);
/*
* Zero correction coefficient structure and set all axes to Raw mode
*/
for (i=0; i<MAX_AXES; i++) {
corr[i].type = JS_CORR_NONE;
corr[i].prec = 0;
for (j=0; j<8; j++) {
corr[i].coeff[j] = 0;
}
}
if (ioctl(fd, JSIOCSCORR, &corr)) {
perror("error setting correction");
exit(1);
}
close(fd);
I'm sure you already open and close the device in your existing implementation, so all you need to add is the ioctl call and data structure initialisation. There is a lot more detail in the kernel sources see :-
...include/linux/joystick.h
Hope this helps
Andrew
/ Reply
Quote
thanks, I'll try that out!
update -- it seems to work, at least on my VMWare Debian image I don't see "flatlines" so I assume the raw data is coming in. I also jiggled around the detection logic so you can have a "real" joystick attached and it will still continue on to look for the JoyWarrior. This new version (4.53 or 4.54) should be up live within a day.
/ Reply
Quote
I also jiggled around the detection logic so you can have a "real" joystick attached and it will still continue on to look for the JoyWarrior. This new version (4.53 or 4.54) should be up live within a day.
This sounds promising - Windows too? The app 4.54 was there within 30 minutes :-) so let's see tomorrow.
Peter
/ Reply
Quote
.... it seems to work, at least on my VMWare Debian image....
QCN V4.54 works with my 2 joystick setup on SUSE 11.0 running natively on Intel hardware. Thanks for the quick fix.
Andrew
/ Reply
Quote
I also jiggled around the detection logic so you can have a "real" joystick attached and it will still continue on to look for the JoyWarrior. This new version (4.53 or 4.54) should be up live within a day.
This sounds promising - Windows too? [...] let's see tomorrow.
Unfortunately it did not work. I've then aborted it and had to re-attach the mouse receiver.
Peter
/ Reply
Quote
QCN V4.54 works with my 2 joystick setup on SUSE 11.0 running natively on Intel hardware. Thanks for the quick fix.
Andrew
Am running BOINC 6.4.5 and don't see anything to update QCN to QCN4.54. Is this going to appear in my Ubuntu 8.10 AMD64 update, or is there another way to update it? Thanks.
Clarence
/ Reply
Quote
Am running BOINC 6.4.5 and don't see anything to update QCN to QCN4.54. Is this going to appear in my Ubuntu 8.10 AMD64 update, or is there another way to update it? Thanks.Clarence
Your Linux host 4565 is already running a QCN 4.54 task (since 15:11:20 UTC?), the Windows host 4557 does not seem to have the sensor attached, you can abort the currently running task and it will download a newer one, including the 4.54 application.
Peter
/ Reply
Quote
My linux is now showing all axes with data. Thanks. PS you guys are smart.
/ Reply
Quote
The usb joywarrior is running with full graphics on my amd64 upgraded from ubuntu 8.10 to ubuntu jackalope 9.04 alpha 4.
/ Reply
Quote
great, do you get the globe view, on my VMWare Ubuntu (running on my Mac) my globe view is all white, as if it can't find the map image/jpeg file.
/ Reply
Quote
Carl,
Artifacts like that can also happen if the virtualization software does not have a good video driver or there is a mismatch between screen sizes. It is not supposed to happen ... but it does ...
Have you tried varying the screen size of the VM?
What I mean is that it may work at 800x600 but not at 1024x768 ... or versa vicea ...
/ Reply
Quote