Actiview beta for linux is avalable

Post Reply
Gerben
Posts: 23
Joined: Fri Sep 24, 2010 4:36 pm

Actiview beta for linux is avalable

Post by Gerben »

Actiview has successfully been ported to Linux.
The beta version of actiview for linux will be available for download later today.
This version of actiview is build and tested on 32 bit ubuntu maverick (10.10), Linux kernel 2.6.35-22-generic using LabVIEW version 8.5

gr Gerben
Last edited by Gerben on Fri Sep 24, 2010 6:19 pm, edited 1 time in total.

Gerben
Posts: 23
Joined: Fri Sep 24, 2010 4:36 pm

Post by Gerben »

Here is the link to download Actiview beta for Linux.
http://www.biosemi.com/download/LatestActiView/Linux/

To run the VI complete with source, you will need LabVIEW full development, version 8.5 or higher.

To use the Actiview stand-alone application you have to install the LabVIEW runtime engine version 8.5, see the link below to download the RTE:
http://ftp.ni.com/support/softlib/labvi ... 8.5/linux/

gr Gerben

Gerben
Posts: 23
Joined: Fri Sep 24, 2010 4:36 pm

Post by Gerben »

actiview for linux still contains some known bugs for now you can use these workarounds.

1. This package is build for 32 bit Linux so it won't work with the 64 bit version of libusb.
for now you can work around this by copying libusb-1.0.so.0 from a 32 bit linux os and put it in the data directory of actiview.

2. If the loader can't find either liblabview_dll or libusb you need to add the path for the data directory to the environment variable LD_LIBRARY_PATH.

gr Gerben

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Post by pmac »

If you are running 64 bit Linux and need 32 bit versions of the libraries liblabview_dll and libusb
(for instance, to run 32 bit Labview and Actiview), use the following procedure to generate them:

1. In the Biosemi driver download package for Linux, use the Linux32 directory.

2. In the INSTALL-LINUX text file follow steps 3B, 4B, 5B, and 6 except:

a) for step 3B use:
./configure --prefix=$LIBUSB_PREFIX --target=x86_32-unknown-linux-gnu CFLAGS=-m32 LDFLAGS=-m32

b) for step 6, use:
make ARCH='-m32'

mirek
Posts: 1
Joined: Sun Jan 29, 2012 11:37 pm
Location: Jagiellonian Univ, Krakow PL

Post by mirek »

I've been using the Linux version of Actiview for some time and I can confirm it works flawlessly on my Mandriva 2010.2 x64 with 2.6.36.2 kernel.

I used 32-bit libusb-1.0 (1.0.7) already present in the system (also available from the official repository), so there was no need to compile it. I pointed to this library when compiling Biosemi drivers:

[code]export PKG_CONFIG_PATH=/lib:$PKG_CONFIG_PATH[/code]

I use standalone, compiled Linux version of the Actiview (for using together with LabView Runtime Environment) which is available to download from Biosemi.

Mirek

afirpi
Posts: 12
Joined: Wed Aug 01, 2012 10:14 pm

Re: Actiview beta for linux is avalable

Post by afirpi »

Hi Paul

I've trying to make ActiveView works but to know avail yet.

I have a Linux 64 and it seems ActiveView/Labview (in 2012) still just run on 32bit.

I was trying to do what you said and this is what I've done so far. I wasn't 100% sure what they mean by below your current directory and then cite examples like ./include or .lib. Those directories don't exist in my home directory so created one ./lib. While on ~

$ mkdir ./lib
$ cp * ~/Downloads/USB_drivers_Linux/Linux32/libusb-1.0.8 ~./lib
$ cd ./lib
$ export LIBUSB_PREFIX=`pwd`
$ ./configure --prefix=$LIBUSB_PREFIX --target=x86_32-unknown-linux-gnu CFLAGS=-m32 LDFLAGS=-m32
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/firpiha1/.lib':
configure: error: C compiler cannot create executables
See `config.log' for more details.

Ideas? Thanks, Alex


======> CONFIG.LOG OUTPUT <===========

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by libusb configure 1.0.8, which was
generated by GNU Autoconf 2.65. Invocation command line was

$ ./configure --prefix= --target=x86_32-unknown-linux-gnu CFLAGS=-m32 LDFLAGS=-m32

## --------- ##
## Platform. ##
## --------- ##

hostname = localhost.localdomain
uname -m = x86_64
uname -r = 3.5.0-2.fc17.x86_64
uname -s = Linux
uname -v = #1 SMP Mon Jul 30 14:48:59 UTC 2012

/usr/bin/uname -p = x86_64
/bin/uname -X = unknown

/bin/arch = x86_64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/local/sbin
PATH: /usr/sbin
PATH: /home/firpiha1/.local/bin
PATH: /home/firpiha1/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2399: checking for a BSD-compatible install
configure:2467: result: /usr/bin/install -c
configure:2478: checking whether build environment is sane
configure:2528: result: yes
configure:2669: checking for a thread-safe mkdir -p
configure:2708: result: /usr/bin/mkdir -p
configure:2721: checking for gawk
configure:2737: found /usr/bin/gawk
configure:2748: result: gawk
configure:2759: checking whether make sets $(MAKE)
configure:2781: result: yes
configure:2927: checking for gcc
configure:2943: found /usr/bin/gcc
configure:2954: result: gcc
configure:3183: checking for C compiler version
configure:3192: gcc --version >&5
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3203: $? = 0
configure:3192: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)
configure:3203: $? = 0
configure:3192: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3203: $? = 4
configure:3192: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3203: $? = 4
configure:3223: checking whether the C compiler works
configure:3245: gcc -m32 -m32 conftest.c >&5
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
configure:3249: $? = 1
configure:3287: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libusb"
| #define PACKAGE_TARNAME "libusb"
| #define PACKAGE_VERSION "1.0.8"
| #define PACKAGE_STRING "libusb 1.0.8"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define PACKAGE "libusb"
| #define VERSION "1.0.8"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3292: error: in `/home/firpiha1/.lib':
configure:3296: error: C compiler cannot create executables
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value=-m32
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value=-m32
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=set
ac_cv_env_target_alias_value=x86_32-unknown-linux-gnu
ac_cv_path_install='/usr/bin/install -c'
ac_cv_path_mkdir=/usr/bin/mkdir
ac_cv_prog_AWK=gawk
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_make_make_set=yes

## ----------------- ##
## Output variables. ##
## ----------------- ##

ACLOCAL='${SHELL} /home/firpiha1/.lib/missing --run aclocal-1.11'
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='${SHELL} /home/firpiha1/.lib/missing --run tar'
AM_BACKSLASH='\'
AM_CFLAGS=''
AM_DEFAULT_VERBOSITY='0'
AM_LDFLAGS=''
AR=''
AUTOCONF='${SHELL} /home/firpiha1/.lib/missing --run autoconf'
AUTOHEADER='${SHELL} /home/firpiha1/.lib/missing --run autoheader'
AUTOMAKE='${SHELL} /home/firpiha1/.lib/missing --run automake-1.11'
AWK='gawk'
BUILD_EXAMPLES_FALSE=''
BUILD_EXAMPLES_TRUE=''
CC='gcc'
CCDEPMODE=''
CFLAGS='-m32'
CPP=''
CPPFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR=''
DSYMUTIL=''
DUMPBIN=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
FGREP=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LD=''
LDFLAGS='-m32'
LIBOBJS=''
LIBS=''
LIBTOOL=''
LIPO=''
LN_S=''
LTLIBOBJS=''
MAKEINFO='${SHELL} /home/firpiha1/.lib/missing --run makeinfo'
MKDIR_P='/usr/bin/mkdir -p'
NM=''
NMEDIT=''
OBJDUMP=''
OBJEXT=''
OS_DARWIN=''
OS_DARWIN_FALSE=''
OS_DARWIN_TRUE=''
OS_LINUX=''
OS_LINUX_FALSE=''
OS_LINUX_TRUE=''
OTOOL64=''
OTOOL=''
PACKAGE='libusb'
PACKAGE_BUGREPORT=''
PACKAGE_NAME='libusb'
PACKAGE_STRING='libusb 1.0.8'
PACKAGE_TARNAME='libusb'
PACKAGE_URL=''
PACKAGE_VERSION='1.0.8'
PATH_SEPARATOR=':'
RANLIB=''
SED=''
SET_MAKE=''
SHELL='/bin/sh'
STRIP=''
VERSION='1.0.8'
VISIBILITY_CFLAGS=''
ac_ct_CC='gcc'
ac_ct_DUMPBIN=''
am__EXEEXT_FALSE=''
am__EXEEXT_TRUE=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include=''
am__isrc=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - "$$tardir"'
am__untar='${AMTAR} xf -'
bindir='${exec_prefix}/bin'
build=''
build_alias=''
build_cpu=''
build_os=''
build_vendor=''
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
host=''
host_alias=''
host_cpu=''
host_os=''
host_vendor=''
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh='${SHELL} /home/firpiha1/.lib/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
lt_ECHO='echo'
lt_age=''
lt_major=''
lt_revision=''
mandir='${datarootdir}/man'
mkdir_p='/usr/bin/mkdir -p'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix=''
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias='x86_32-unknown-linux-gnu'

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME "libusb"
#define PACKAGE_TARNAME "libusb"
#define PACKAGE_VERSION "1.0.8"
#define PACKAGE_STRING "libusb 1.0.8"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define PACKAGE "libusb"
#define VERSION "1.0.8"

configure: exit 77

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Re: Actiview beta for linux is avalable

Post by pmac »

Alex,

Your problem seems to be that your version of RedHat 64 doesn't have the 32 bit libraries and development support packages installed.
To compile and/or run 32 software you will need them. They can probably by added using "yum". It could be tedious adding what you
need one-by-one. Perhaps there is a 32 bit development package that can be installed with a single yum command. I haven't encountered
this before. Check out the RedHat support forums.

Paul

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Re: Actiview beta for linux is avalable

Post by pmac »

Alex,

Perhaps this is what you need to install: glibc-devel.i686

Taken from: http://stackoverflow.com/questions/7412 ... -directory

Paul

afirpi
Posts: 12
Joined: Wed Aug 01, 2012 10:14 pm

Re: Actiview beta for linux is avalable

Post by afirpi »

Hi Paul

Thanks. Just in case you want to know:

yum install glibc-devel.i686 libgcc.i686

There you go. Presto.

Best,
Alex

afirpi
Posts: 12
Joined: Wed Aug 01, 2012 10:14 pm

Re: Actiview beta for linux is avalable

Post by afirpi »

Paul

Oh, I didn't realize you posted a similar answer 3 mins before!! =) It worked. At least the making and installing the file.

Many thanks!!

What city in Canada?

Have a great weekend,
Alex

afirpi
Posts: 12
Joined: Wed Aug 01, 2012 10:14 pm

Re: Actiview beta for linux is avalable

Post by afirpi »

Paul or Gerben

By any chance, do you have the bsif_libusb.c(pp)? I have the executable (.o) but I'll like to see the .cpp.

Thank

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Re: Actiview beta for linux is avalable

Post by pmac »

Alex,

Are you still having trouble with the library?

Paul

afirpi
Posts: 12
Joined: Wed Aug 01, 2012 10:14 pm

Re: Actiview beta for linux is avalable

Post by afirpi »

Paul

Sort of. It's a bit messy. I was able to do a make install for the Linux32 files. But when I try to compile the labview libraries for the Linux32 version, I have the following error.

$ make ARCH='-m32'
g++ -o liblabview_dll.so.0.0.1 -fPIC -lc -shared -Wl,-soname,liblabview_dll.so.0 \
labview_dll.o bsif_libusb.o `pkg-config --libs libusb-1.0`
/usr/bin/ld: i386 architecture of input file `bsif_libusb.o' is incompatible with i386:x86-64 output
bsif_libusb.o: In function `AcquisitionThread(void*)':
bsif_libusb.cpp:(.text+0x17d3): undefined reference to `pthread_sigmask'
bsif_libusb.cpp:(.text+0x187c): undefined reference to `pthread_sigmask'
bsif_libusb.o: In function `BSIF_CLOSE_DRIVER':
bsif_libusb.cpp:(.text+0x2c1b): undefined reference to `pthread_join'
bsif_libusb.o: In function `BSIF_READ_MULTIPLE_SWEEPS':
bsif_libusb.cpp:(.text+0x37db): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
make: *** [liblabview_dll.so.0.0.1] Error 1

I think I know what's the problem but I don't know the solution. I installed the libusb for Linux64 under /usr/local/lib (I need this for my Matlab project). Paths were added and all that. Now I also installed the libusb for Linux32 but under MY directory (under ~./lib). I don't know how to add the libusb 32bit paths in a way that doesn't get the compiler confused. I have the same names for libusb 32 and 64. The compiler is calling the libusb64 and not the 32, for the obvious reasson that I haven't added it. Ideas?

Also, when I run the test ./Labview_DLL_SyncTest using the 64bit version, this is the output I get:

$ ./Labview_DLL_SyncTest 0
****************************************
Parameters can be, in any order:
Time to run, in seconds:
default is 600 seconds (10 minutes)
0=unlimited

Ring buffer size, in 512 byte units,
must have a 'b' or 'B' prefix:
default is B65536 for 32 MBytes


Hit ctrl-c to quit
****************************************
sizeof long = 8
ring buffer size = 33554432
at second 0, buffer 0, #bytes 524288, seam 524288, word throughput/channel/sec 0
number of channels = 34
missing sync 1: buffer 0, [136] = 8158f500
sync found again at [146] = ffffff00
missing sync 2: buffer 0, [180] = 0
sync found again at [610] = ffffff00
missing sync 3: buffer 0, [746] = 8158e500
sync found again at [756] = ffffff00
missing sync 4: buffer 0, [790] = 0
sync found again at [1220] = ffffff00
missing sync 5: buffer 0, [1356] = 81591600
sync found again at [1366] = ffffff00
missing sync 6: buffer 0, [1400] = 0
more than 5 missing syncs in 1 buffer
stopping ...
Done, hit ctrl-c to exit

I am asking because the Ctrl+C just doesn't work.

Thanks,
Alex

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Re: Actiview beta for linux is avalable

Post by pmac »

Alex,

1. My guess is that you have the environment variable "PKG_CONFIG_PATH" defined and
that is causing the mixing of the 32 and 64 bit objects. You may have defined this variable
if you built the 64 bit software in the same login session that you are using to build the
32 bit software. Try building the 32 bit software using a fresh login shell and be sure to
use steps 3B, 4B and 5B in INSTALL-LINUX rather than 3A, 4A and 5A.

2. I think your Labview_DLL_SyncTest problem is the same as the one described in this
thread:
http://www.biosemi.nl/forum/viewtopic.php?f=7&t=666
My guess is that you have new Biosemi hardware that requires a new sync detection logic
in the sync test program. I have a new version of this program but it hasn't been tested
because I don't have any new hardware here.

3. The CTRL-C doesn't work because the program has already stopped by itself.

Paul

afirpi
Posts: 12
Joined: Wed Aug 01, 2012 10:14 pm

Re: Actiview beta for linux is avalable

Post by afirpi »

Hi Paul

Sorry I didn't get back to you sooner. I've been busy. We all are.

1. I fixed the problem with the Ctrl+C. It works now. It had to do with the settings on the terminal.

2. Do you have that new version of Labview_DLL_SyncTest you mentioned (and on the webside as well)? Is it possible you could share it?

3. I stopped working on ActiView (for the moment) and went back to my Matlab API. I know I am capable of "talking" to the EEG box from Matlab but I am having some synch problem and I was wondering if that new version of the code you mentioned might give me some insight into what is wrong.

Thank you!
Alex

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Re: Actiview beta for linux is avalable

Post by pmac »

Alex,

The modified labview_dll_synctest.cpp is needed only if you have the newest
Biosemi hardware. Again, it hasn't been tested with the new hardware but it
does still work with the older hardware. The program can be used on Windows,
Linux or Mac, in place of the version included in official packages on the BioSemi
download site.

In the morning I'll put the new version on a download site and e-mail you details
about how to get it.

Paul

afirpi
Posts: 12
Joined: Wed Aug 01, 2012 10:14 pm

Re: Actiview beta for linux is avalable

Post by afirpi »

Hi Paul

Thank you for the code. I am still experiencing synch problems, though. Below is the output of the code (for the new Synch version). What exactly was the difference between the old version and the new one? I am asking because I almost got to work that Biosemi API for Matlab I was working on except for the fact that I am experiencing synch problems as well.

Suggestions?

Thanks in advance,
Alex

sizeof long = 8
ring buffer size = 33554432
at second 0, buffer 0, #bytes 262144, seam 262144, word throughput/channel/sec 0
number of channels = 34
missing sync 1: buffer 0, [272] = 85570d00
sync found again at [274] = ffffff00
missing sync 2: buffer 0, [308] = 814e8100
sync found again at [316] = ffffff00
missing sync 3: buffer 0, [554] = 85574400
sync found again at [556] = ffffff00
missing sync 4: buffer 0, [590] = 814e8e00
sync found again at [598] = ffffff00
missing sync 5: buffer 0, [836] = 85573a00
sync found again at [838] = ffffff00
missing sync 6: buffer 0, [872] = 814e9a00
more than 5 missing syncs in 1 buffer
stopping ...
Aborted, hit ctrl-c to exit
^Cgot signal 2
Done!!!

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Re: Actiview beta for linux is avalable

Post by pmac »

Hi Alex,

A delayed reply - I was away from the internet last week.

My understanding of the situation is this:
A set of samples from one sweep of all channels is always preceeded by a sync word and a
status word. The sync word has the hexidecimal value ffffff00 and the status word contains,
among other things, the speed mode setting.

When sampling starts, the first word transferred into the ring buffer is the sync word,
followed by the status word and then one set of samples. This sequence of words repeats for
each new set of samples.

The synctest program searches for the first 2 sync words, takes the distance between them as the
size of a packet (nch) and then proceeds to check that the word at each multiple of that size
from the start of sampling is a sync word.

The problem with the new hardware is that words that look like sync words are now generated for
channels where no modules are installed. The older hardware generated 00000000, the new hardware
ffffff00.

This means that the synctest program's initial logic to determine the number of channels (i.e.
the size of a packet) doesn't work - it comes up short.

One solution is to decode the speed mode from the status word (the second word that appears in
the ring buffer) and use this to determine the number of channels. This would work for a
particular piece of hardware where you know the meaning of each speed mode setting.

But apparently, from time to time, the the meaning of the speed mode settings change in hardware
build for specific applications or customer requests. With the synctest program I'm trying to
write a general test program that runs with all hardware. I'm trying to avoid attaching any
meaning to the speed mode setting.

The program version that I gave you last week was my first attempt with the newest hardware.
I tried to scan the first buffer for an occurances of a sync word followed by a status word
with the same speed mode bits as the second word in the buffer. Since I don't have the new
hardware here, this logic wasn't tested. From your results I see that this is not a
sufficient check - sometimes a false sync can be followed by a real channel whose sample bits
match the real status word's speed mode bits! I assumed this would be a rare occurance.

I have modified the program to use a more complicated logic to determine packet size and,
if that fails, to allow the user to specify the size as a parameter when starting the program.
I could make this new version available if you want to try again.

I hope this explanation helps,
Paul

afirpi
Posts: 12
Joined: Wed Aug 01, 2012 10:14 pm

Re: Actiview beta for linux is avalable

Post by afirpi »

Hi Paul

The latest version is working! Below is the output.

I'll be around here in case I experience new issues. I still need to fix the problem with the ActiView (I'll be doing that in the next few days). I also have to install the Real-Time Linux patch. A lot of work!

Let me know if you ever need anything..... in Matlab. :-)

Best,
Alex

$ ./Labview_DLL_SyncTest 0
****************************************
Parameters can be, in any order:
Time to run, in seconds:
default is 600 seconds (10 minutes)
0=unlimited

Expected number of input channels,
must have a 'c' or 'C' prefix:
default is to let program determined it;
needed only if program gets it wrong

Ring buffer size, in 512 byte units,
must have a 'b' or 'B' prefix:
default is B65536 for 32 MBytes


Hit ctrl-c to quit
****************************************
sizeof long = 8
ring buffer size = 33554432
at second 0, buffer 0, #bytes 262144, seam 262144, word throughput/channel/sec 0
number of channels = 282
V20111015 using: Linux/Mac libusb library, 56.69 msec stride, not sync'ing pointer calls
at second 1, buffer 10, #bytes 262144, seam 3145728, word throughput/channel/sec 2047
at second 1, buffer 11, #bytes 131072, seam 3276800, word throughput/channel/sec 2051
at second 2, buffer 22, #bytes 131072, seam 4718592, word throughput/channel/sec 2038
at second 2, buffer 33, #bytes 131072, seam 6160384, word throughput/channel/sec 2051
at second 3, buffer 44, #bytes 131072, seam 7602176, word throughput/channel/sec 2047
at second 4, buffer 55, #bytes 131072, seam 9043968, word throughput/channel/sec 2052
at second 4, buffer 66, #bytes 131072, seam 10485760, word throughput/channel/sec 2047
at second 5, buffer 77, #bytes 131072, seam 11927552, word throughput/channel/sec 2038
at second 5, buffer 88, #bytes 131072, seam 13369344, word throughput/channel/sec 2052
at second 6, buffer 99, #bytes 131072, seam 14811136, word throughput/channel/sec 2047
at second 7, buffer 110, #bytes 131072, seam 16252928, word throughput/channel/sec 2052
at second 7, buffer 121, #bytes 131072, seam 17694720, word throughput/channel/sec 2047
at second 8, buffer 132, #bytes 131072, seam 19136512, word throughput/channel/sec 2052
at second 9, buffer 143, #bytes 131072, seam 20578304, word throughput/channel/sec 2038
^Cgot signal 2
stopping ...
V20111015 using: Linux/Mac libusb library, 56.69 msec stride, not sync'ing pointer calls
Done, hit ctrl-c to exit

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Re: Actiview beta for linux is avalable

Post by pmac »

Hi Alex,

The new sync detection logic used to determine the number of channels (size of a
single packet of samples) in the latest version of the synctest program (to
avoid attaching meaning to the speed mode setting) is as follows:

When sampling starts the first two words dropped into the ring buffer are the old
sync word (hex ffffff0) and a status word. During a single acquisition run,
some bits of the status word shouldn't change: the Mark1/Mark2 bit and the speed
mode bits. Save these bits for later comparisons. In C, this will do the save:

staticStatusBits = ((int *)samBuffer)[1] & 0xae000000;

Scan forward word-by-word looking for a word containing 0xffffff00 followed immediately
by a word whose masked bits match the status bits in word 2, saved above. In C,

if ((((int *)samBuffer)[nxtSync] == 0xffffff00) &&
((((int *)samBuffer)[nxtSync+1] & 0xae000000) == staticStatusBits))

At this point the value of 'nxtSync' MAY be the number of channels (size of a
block of samples).

To confirm this, do the same 2 word test at all indices in the first buffer that are
multiples of 'nxtSync', i.e.
[nxtSync*2] and [nxtSync*2+1]
[nxtSync*3] and [nxtSync*3+1]
...

If at some multiple of 'nxtSync' this 2 word test fails, continue the word-by-word
search described above, resuming the search at index 'nxtSync'+2.

Some background:

The first buffer returned by READ_POINTER will always be at least 262144 bytes
long - this is the stride that the ring buffer support routines use to get
sampling started. This is 262144/4=65536 words.

Using a large number of channels such as 282 means there will be at least 65536/282
232 blocks of samples in the first buffer to be checked. With fewer channels there
will be more blocks.

To accept the value of 'nxtSync' as the number of channels there have to be several
hundred blocks of samples each starting with 0xffffff00 and the saved status bits in
that first buffer. This seems unlikely, unless 'nxtSync' is the correct value.

As a final guard against choosing a value that is too small, the program allows the
user to specify as a parameter a minimum acceptable number of channels. The first
value above this minimum that satisfies all the above checks will be chosen.
Hopefully this parameter would rarely need to be used.

I hope this helps you,
Paul

pmac
Posts: 70
Joined: Thu Jan 21, 2010 2:51 pm
Location: Canada

Re: Actiview beta for linux is avalable

Post by pmac »

Hi Alex,

MISINFORMATION ALERT!!!

In yesterday's post I said that the first buffer returned by READ_POINTER is at least
262144 bytes in size.

This should have been the half of that: 131072. I have to learn to check the code
BEFORE posting rather than AFTER!!! This value changed several times during development
but has been stable now for several years.

The effect of this change is that when the number of channels is 282, the minimum number
of sample blocks in the first buffer returned to the user is 116 rather than 232 - still
more than enough to determine the actual number of channels being sampled. And when the
first user buffer is 131072*2 or 131072*3 (depending upon how quickly the first READ_POINTER
follows the start of sampling), the number of sample blocks will be double or triple.

Sorry about this mistake,
Paul

Post Reply