Other platforms
Other platforms
I would like to know whether it is possible to use the BioSemi device under Linux. This would be a key point in the choice of the system because we need a device working with Real Time Linux. Is there already a Linux port of the Labview_DLL.dll? Are functions in Labview_DLL.dll "standard prototypes" to access a USB device or there is no hope to find similar ones in a Linux kernel or module?
Thank you,
Luca Citi
Thank you,
Luca Citi
Luca Citi
PhD student in "Biorobotic science and engineering"
IMT - Institutions, Markets, Technologies
Lucca Institute for Advanced Studies - Italy
PhD student in "Biorobotic science and engineering"
IMT - Institutions, Markets, Technologies
Lucca Institute for Advanced Studies - Italy
-
- Site Admin
- Posts: 1152
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
BioSemi only provides drivers for Windows XP, drivers for use under Linux are not available.
The ActiveTwo system can be used under Mac by using a National Instruments PCI-DIO32HS interface card (with NI drivers) with old style BioSemi receiver, instead of the current USB interface (use ActiView 4.09, see http://www.biosemi.com/download_actiview.htm). A third-party (www.comedi.org/) driver for the PCIO-DIO32-HS card is available to allow it to work under Linux, although this apparently is not entirely without problems, see for example http://lists.suse.com/archive/suse-prog ... /0107.html.
As an alternative, you can use the new TCP/IP option in ActiView to stream ActiveTwo data from a Windows PC to other platforms, see viewtopic.php?t=64. However, the variable timing delays caused by Windows and by the TCP/IP protocol of course compromise the real-time functioning in this case.
Best regards, Coen (BioSemi)
The ActiveTwo system can be used under Mac by using a National Instruments PCI-DIO32HS interface card (with NI drivers) with old style BioSemi receiver, instead of the current USB interface (use ActiView 4.09, see http://www.biosemi.com/download_actiview.htm). A third-party (www.comedi.org/) driver for the PCIO-DIO32-HS card is available to allow it to work under Linux, although this apparently is not entirely without problems, see for example http://lists.suse.com/archive/suse-prog ... /0107.html.
As an alternative, you can use the new TCP/IP option in ActiView to stream ActiveTwo data from a Windows PC to other platforms, see viewtopic.php?t=64. However, the variable timing delays caused by Windows and by the TCP/IP protocol of course compromise the real-time functioning in this case.
Best regards, Coen (BioSemi)
It seems quite hard. I thought it would have been easier. I thought the Labview_DLL.dll was a compiled form of the LabView VI and I thought it could be easily recompiled with LabVIEW Development System for Linux and accessed by a C program in a system running the free LabView runtime for Linux. I have read that if you have VIs that don't use ActiveX, other DLLs or registry VIs you can compile it in LabView for Linux. What is the problem with Labview_DLL.dll?
Thank you again
Luca
Thank you again
Luca
Luca Citi
PhD student in "Biorobotic science and engineering"
IMT - Institutions, Markets, Technologies
Lucca Institute for Advanced Studies - Italy
PhD student in "Biorobotic science and engineering"
IMT - Institutions, Markets, Technologies
Lucca Institute for Advanced Studies - Italy
-
- Site Admin
- Posts: 1152
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
The Labview_DLL.dll does not contain LabVIEW VI's. The dll contains function calls for the initialization and readout of a ringbuffer. The ringbuffer is then filled with data from the USB receiver, see http://www.biosemi.com/faq/make_own_acq ... ftware.htm. These functions and the USB driver only work under Windows XP.
Best regards, Coen (BioSemi)
Best regards, Coen (BioSemi)
Given that the last traffic in this thread is from 2005, I have the faint hope that the situation might have changed in the meantime. So, can the ActiveTwo be used with OSX, for example? Or is Windows still the only platform that can interface the USB ringbuffer? I know that BioSemi propagates TCP data streaming to solve the platform issue, but this requires two computers. This is impractical for field usage, however.
My understanding is that the ActiveView client itself should run out of the box on any platform supported by LabVIEW, and the only critical part is the labview.dll for reading out the ringbuffered data from the USB port. From the FAQ I conclude that this DLL comprises only about half a dozen of functions. So what is the reason not to port them to *NIX platforms? And if BioSemi does not want to do it for whatever reason, would it be possible for an experienced programmer from the user community?
My understanding is that the ActiveView client itself should run out of the box on any platform supported by LabVIEW, and the only critical part is the labview.dll for reading out the ringbuffered data from the USB port. From the FAQ I conclude that this DLL comprises only about half a dozen of functions. So what is the reason not to port them to *NIX platforms? And if BioSemi does not want to do it for whatever reason, would it be possible for an experienced programmer from the user community?
Yes, I know. And I do know that it is available for Windows only. My question is, if it would be possible to write a USB driver for other OSs. Or is there any technical or political reason for not trying? If not, would BioSemi support attempts to port the driver? E.g. by making the source of the existing (Windows) driver available?
Best,
ALEX.
Best,
ALEX.
Open - Source
[quote]
We do not plan to make the source code of the Windows driver available because of competitive reasons. [/quote]
I think then your mission statement should change on your home page. Since you state:
They are optimized for this specific application by offering features like: freely configurable hardware and completely open-source software,......
Although you offer the source code for the Actiview and some other pieces of software you do not provide the source for the driver.
Thanks
Mathew
We do not plan to make the source code of the Windows driver available because of competitive reasons. [/quote]
I think then your mission statement should change on your home page. Since you state:
They are optimized for this specific application by offering features like: freely configurable hardware and completely open-source software,......
Although you offer the source code for the Actiview and some other pieces of software you do not provide the source for the driver.
Thanks
Mathew
-
- Site Admin
- Posts: 1152
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
Our policy is actually a bit more subtle than stated in my previous message. We are prepared to share the source code of the Windows driver (and have done so in the past), under the following conditions:
- you will have to convince us that you actually have the knowledge to do anything useful with it.
- you will have to convince us that the development and distribution of alternative drivers will not increase our workload with respect to service and support.
- you will have to reassure us that our source code will not be shared with any commercial competitor.
I look forward to receive well-founded plans for the development of alternative drivers from the BioSemi user community.
Best regards, Coen (BioSemi)
- you will have to convince us that you actually have the knowledge to do anything useful with it.
- you will have to convince us that the development and distribution of alternative drivers will not increase our workload with respect to service and support.
- you will have to reassure us that our source code will not be shared with any commercial competitor.
I look forward to receive well-founded plans for the development of alternative drivers from the BioSemi user community.
Best regards, Coen (BioSemi)
I am running new iMAC's with both, VMWare and also Bootcamp. VMWare running Windows XP under the OSX system booted, does not run the ActiView Software properly, since it handles memory a bit quirky.
However, I have been running Windows XP booted under Bootcamp for many months now, and ActiView (all versions) runs extremly nicely on my 24" 3.06Ghz iMAC! I get all the trigger information, and subsequently do my analysis using BESA 5.20 on the same iMAC.
Hoping this makes sense, let me know if not.
Kind regards, Marc Mosimann
However, I have been running Windows XP booted under Bootcamp for many months now, and ActiView (all versions) runs extremly nicely on my 24" 3.06Ghz iMAC! I get all the trigger information, and subsequently do my analysis using BESA 5.20 on the same iMAC.
Hoping this makes sense, let me know if not.
Kind regards, Marc Mosimann
drivers for linux
I am very interested in working on developing drivers for Linux to interface with the BioSemi system via USB2. Has anyone started (or finished
) working on this?

Windows 32&64 and Linux drivers beta version.
A new generation of drivers is now available for evaluation.
The below link has both the new Windows 64 bit and Linux drivers.
http://www.biosemi.com/download/USB%20drivers%20beta/
For the Linux drivers note the following:
1. The 64 bit version was developed and tested on 64 CentOS 5
(Linux 2.6.18 ) which is similar to RedHat AS5.
2. The 32 bit version was tested on RedHat AS4 (Linux 2.6.9).
3. The install procedure uses a Makefile to adapt as much as possible
to the host system's installed libraries.
4. The download file can be unpacked using the command:
tar xvjf USB_driver_Linux_beta.tar.bz2
Please note that the current ActiView (version 6.05) is not yet suitable for Vista64, only for Vista32 and XP32. An upgrade of Actiview (made with LabVIEW 8.6.1) will be available on our regular website within a week.
Please post any experience when using these new beta drivers on this forum.
Robert, Biosemi
The below link has both the new Windows 64 bit and Linux drivers.
http://www.biosemi.com/download/USB%20drivers%20beta/
For the Linux drivers note the following:
1. The 64 bit version was developed and tested on 64 CentOS 5
(Linux 2.6.18 ) which is similar to RedHat AS5.
2. The 32 bit version was tested on RedHat AS4 (Linux 2.6.9).
3. The install procedure uses a Makefile to adapt as much as possible
to the host system's installed libraries.
4. The download file can be unpacked using the command:
tar xvjf USB_driver_Linux_beta.tar.bz2
Please note that the current ActiView (version 6.05) is not yet suitable for Vista64, only for Vista32 and XP32. An upgrade of Actiview (made with LabVIEW 8.6.1) will be available on our regular website within a week.
Please post any experience when using these new beta drivers on this forum.
Robert, Biosemi
Windows 7 runtime engine and driver for the USB Receiver!
Dear Forum Members,
Glad to report the following achievement from the BioSemi side:
I have purchased an ACER Aspire 5538 with Windows 7 64-bit Ultimate, downloaded the VISTA 64-bit USB driver posted above (May 12th, 2009), along with getting the Runtime Engine 8.6.1 from NI (http://ftp.ni.com/support/softlib/labvi ... 861STD.exe) and am running a preliminary version of the ActiView-700 with full functionality!
This again proves, and along with a very shortly to be released MAC OS 10.6.1 Snow Leopard Version, that BioSemi is very active in getting their acquisition programs running across most platforms available today!!
Regards, Marc Mosimann - NEUROSPEC AG Switzerland
Glad to report the following achievement from the BioSemi side:
I have purchased an ACER Aspire 5538 with Windows 7 64-bit Ultimate, downloaded the VISTA 64-bit USB driver posted above (May 12th, 2009), along with getting the Runtime Engine 8.6.1 from NI (http://ftp.ni.com/support/softlib/labvi ... 861STD.exe) and am running a preliminary version of the ActiView-700 with full functionality!
This again proves, and along with a very shortly to be released MAC OS 10.6.1 Snow Leopard Version, that BioSemi is very active in getting their acquisition programs running across most platforms available today!!
Regards, Marc Mosimann - NEUROSPEC AG Switzerland
I confirm that the drivers works on Ubuntu Karmic 9.10 64 bits machine.
However the test program gives segfault when the device is not powered up with transfer_1 status 2 error. putting in debug mode fixes it though.
EDIT: it seems that I cannot use the same code within another environment and the maximum info on the error that I can get is " transfer_1 status 2/transfer_2 status 2". Do you have any idea where this can come from ?
Thank you
Nicolas
However the test program gives segfault when the device is not powered up with transfer_1 status 2 error. putting in debug mode fixes it though.
EDIT: it seems that I cannot use the same code within another environment and the maximum info on the error that I can get is " transfer_1 status 2/transfer_2 status 2". Do you have any idea where this can come from ?
Thank you
Nicolas
Last edited by narsil on Thu Jan 21, 2010 5:54 am, edited 1 time in total.
Ok the problem seems to be coming from a multithreaded environment (I use pthread). There is no concurrent access though. The problem seems to lie in the bsif_libusb.o
To reproduce just use a new main, and modify oldMain to receive void* and return void* (pthread requirement).
This works:
int main(int nargs, char **NULL){
oldMain(0);
return 0;
}
whereas this does not:
int main(int nargs, char **NULL){
pthread_t thread;
pthread_create(&thread,NULL, &oldMain,NULL);
pthread_join(thread,NULL);
return 0;
}
To reproduce just use a new main, and modify oldMain to receive void* and return void* (pthread requirement).
This works:
int main(int nargs, char **NULL){
oldMain(0);
return 0;
}
whereas this does not:
int main(int nargs, char **NULL){
pthread_t thread;
pthread_create(&thread,NULL, &oldMain,NULL);
pthread_join(thread,NULL);
return 0;
}
[quote="narsil"]I confirm that the drivers works on Ubuntu Karmic 9.10 64 bits machine.
However the test program gives segfault when the device is not powered up with transfer_1 status 2 error. putting in debug mode fixes it though.
EDIT: it seems that I cannot use the same code within another environment and the maximum info on the error that I can get is " transfer_1 status 2/transfer_2 status 2". Do you have any idea where this can come from ?
Thank you
Nicolas[/quote]
Hi Nicolas,
I guess in all our testing on Linux we'd never tried acquisition when there was no power to the device!
The segfault occurs in the Labview_DLL_SyncTest test program.
When the acquisition is running READ_POINTER returns TRUE and when it's not running it returns FALSE.
The test program was not checking this returned value! This has now been fixed.
I've made a new version for the Biosemi download site that incorporates this fix and a number of other
changes that have been made since May 2009. Look for a version with today's date, or perhaps later by the
time it gets posted there.
The "transfer_1 status 2" message is a hint that a transfer timeout has occured. Normally, when each libusb
transfer request returns, the status of the transfer is 0. When it's not 0, something unusual has happened.
It could be that the transfer timed out, either because the power is off or the timeout value isn't long
enough for the amount of data and sample rate. Regardless, any status other than 0 stops further transfer
requests, the buffer stops filling and READ_POINTER starts returning FALSE.
Thanks for the feedback - finally someone else using Linux!
I hope this helps,
Paul
P.S. I think the pthread problem that you described in another post is fixed in this new download.
However the test program gives segfault when the device is not powered up with transfer_1 status 2 error. putting in debug mode fixes it though.
EDIT: it seems that I cannot use the same code within another environment and the maximum info on the error that I can get is " transfer_1 status 2/transfer_2 status 2". Do you have any idea where this can come from ?
Thank you
Nicolas[/quote]
Hi Nicolas,
I guess in all our testing on Linux we'd never tried acquisition when there was no power to the device!
The segfault occurs in the Labview_DLL_SyncTest test program.
When the acquisition is running READ_POINTER returns TRUE and when it's not running it returns FALSE.
The test program was not checking this returned value! This has now been fixed.
I've made a new version for the Biosemi download site that incorporates this fix and a number of other
changes that have been made since May 2009. Look for a version with today's date, or perhaps later by the
time it gets posted there.
The "transfer_1 status 2" message is a hint that a transfer timeout has occured. Normally, when each libusb
transfer request returns, the status of the transfer is 0. When it's not 0, something unusual has happened.
It could be that the transfer timed out, either because the power is off or the timeout value isn't long
enough for the amount of data and sample rate. Regardless, any status other than 0 stops further transfer
requests, the buffer stops filling and READ_POINTER starts returning FALSE.
Thanks for the feedback - finally someone else using Linux!
I hope this helps,
Paul
P.S. I think the pthread problem that you described in another post is fixed in this new download.
The newest updated Linux driver developed by PCMac is available here:
http://www.biosemi.com/download/USB%20d ... x1.tar.bz2
http://www.biosemi.com/download/USB%20d ... x1.tar.bz2
MATLAB API
If you are interested in an open source MATLAB API for ActiveTwo, see this topic viewtopic.php?p=2049#2049. Thanks.
Lloyd Smith
lsmith@cortechsolutions.com
lsmith@cortechsolutions.com