June 15, 2015
When using the 2015 RingBuffer library, client and server handling is performed entirely within the library. Most acquisition programs are not even aware of it. This means that any program using this library to access its Usb ring buffer can function as a server application.
The client program has no control over the Usb acquisition process. The RingBuffer library merely taps into the Usb ring buffer to get samples to transmit to the client.
Start a normal acquisition program on a Windows, Linux or OSX system. For instance, any version of ActiView, ActiView-Light, the 2015 version of RingBuffer_SyncTest or anything else that uses the 2015 RingBuffer library.
Whatever program is used, it must be paired with the 2015 version of the RingBuffer library. If the program has been using a previous version of this library (or Labview_DLL), just replace the library file with the newest version. If necessary, copy and rename the RingBuffer library to the Labview_DLL library name.
Try clients, in this order:
Note: Try only one of these client options at a time. For bandwidth reasons,the server will connect with only one client at a time.The sample Android App included in this download, BSChannel Viewer, is a client application that can be used on either a tablet or smartphone. Follow these steps:
This can usually be done using a Usb cable to connect the mobile device to the computer with the BSChannelViewer.apk file. There are plenty of web sites that describe exactly how to do this or give other ways to do this on the various mobile devices.
The choice consideration here is only to reduce bandwidth required. In either case, all channels are available for display on the client. In 32 channel mode, the App will transparently request different sets of 32 channels as needed rather than requesting all available channels from the start.
If the connection fails, there may be a Firewall problem on the Windows/Linux/OSX server system. See the Firewall Considerations section below.
Start a second acquisition on the same computer.
If you use the National Instruments (NI) LabVIEW environment a second time (e.g. to run ActiView twice, in parallel) there could be trouble. This is a restriction of the LabVIEW environment. On Windows, simply coping the executable file making a file to use with a different name seems to overcome the problem.
The 2015 version of the test program RingBuffer_SyncTest can be used as a client to test the remote client feature.
If running the client and server on the same computer works, try running the client program instead on a second computer.
The second computer needs:
The second computer could be any Windows, Linux or OSX system that can run an acquisition program that uses the 2015 version of the RingBuffer library.
The client computer doesn't need any Usb driver or Usb library because samples will come from a socket. Thus on Windows, there is no need to install the Microsoft Usb driver "WinUsb" nor on Linux or OSX, the libusb-1.0 library.
Beware when using ActiView or ActiView-Light as a remote client. Both programs have watchdog timers that will abort the connection attempt if the computers involved are slow at connecting. And when the network is heavily loaded, the current ActiView versions (705, 706, 707) and ActiView-Light (604) can be sensitive to the extra delays caused by receiving samples through the internet. If ActiView or ActiView-Light is failing during the initial connection attempt, adding a line to the client's ringbuffer.ini file with just the word "sync" sometimes helps.
A typical ringbuffer.ini parameter file is included in the download and looks like this:
# Comments start with # # # connect_node # # Used by the client computer. # The name or ip address of the computer whose ring buffer is # being filled by the BioSemi receiver via usb. This will be # the sample stream TCP server. # Any name or IPv4 address that works with ping should work. # When multiple connect_node lines are given, the last is used. # When no connect_node parameter is declared, the default is the # loopback address 127.0.0.1. # Remove the '#' to activate a parameter line. # For example: connect_node macbook-a3013c connect_node 127.0.0.1 # loopback ip address # # connect_port # # Used by the client computer. # The port number to connect on the sample stream server computer. # This must match the listen_port number in the sample stream # server's parameter file. # When multiple connect_port lines are given, the last is used. # When no connect_port is declared, the default is 3113. # Remove the '#' to activate a parameter line. # For example: connect_port 3113 # # listen_port # # Used by the server computer. # The port number to listen on for client connection requests. # This must match the connect_port number in the client's # parameter file. # When multiple listen_port lines are given, the last is used. # When listen_port is set to 0, client connections are disabled. # When no listen_port is declared, the default is 3113. # Remove the '#' to activate a parameter line. # For example: listen_port 3113
The name or IP address of the acquisition server (i.e. the one whose ring buffer is being filled from a Usb) must be set in the second computer's (the client's) ringbuffer.ini parameter file, parameter "connect_node". Any DNS or NetBios name that works with "ping" should work, or if necessary, the IPv4 address itself.
Generally the ringbuffer.ini parameter file should be in the same directory as the acquisition program being run. The file can, instead, be in the user's home directory - the library will look there if an .ini file is not found in the program directory. When running under the control of the National Instruments LabVIEW Workbench, the .ini file should be in the user's home directory because the NI Workbench doesn't report to the vi's being run the directory from which they come. On Windows, the home directory is the concatination of the environment variables HOMEDRIVE and HOMEPATH; on Linux and OSX it is the environment variable HOME.
If the connection attempt itself fails, there may be a Firewall problem on one or both of systems being used. See the Firewall Considerations section below.
To develop your own client or server program using the RingBuffer library, see RingBufferLibrary-API for a description of the API's available.
To develop a client program without using the RingBuffer library to receive samples (e.g. as a tablet or smartphone App), see RingBufferLibrary-TransferProtocol for a description of the Tcp transfer protocol used.
On most systems permission must be specifically granted for a program to communicate through the local firewall. The following are some things we found of assistance in getting through firewalls.
The procedure is outlined at
http://windows.microsoft.com/en-ca/windows/communicate-through-windows-firewall#1TC=windows-7and/or
http://windows.microsoft.com/en-ca/windows/open-port-windows-firewall#1TC=windows-7
The procedure is outlined at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.htmlin section "4.5.14.1.6. Open Ports in the Firewall".
This is a command to determine if a particular port (here 3113) is open:
firewall-cmd --zone=public --query-port=3113/tcpThe output is either "yes" or "no".
Official instructions are given here:
https://support.apple.com/en-ca/HT201642
But perhaps the easiest way to get access through the firewall is to just run your program in "server" mode, that is, with the Usb cable connected. In this mode the program will attempt to "listen" for a port connection from a client. When this happens a system query appears that asks if this "listen" request should be "Allowed" or "Denied". If you select "Allow" this choise is remembered for future use of this particular program. Allowing "listen" requests seems to clear the way for the program to also operate in "client" mode, i.e. making a "connect" request through the firewall.
The sample Android App, BSChannelViewer, reports throughput per channel per second and the number of re-syncs.
Another way to test the speed of an internet connection is to use the 2015 RingBuffer_SyncTest as the client. Each line printed by this program shows the current throughput per channel per second and the number of times a re-sync has occurred.
If re-syncs are occurring, the number of channels being transferred can be reduced by specifying a sub channel range when starting the program. For example:
RingBuffer_SyncTest r35-66 0This creates a ring buffer on the client with space for all the channels being sampled on the server, but only the sync, status and second set of 32 channels are filled. The sync and status words are always transferred. When the number of channels being transferred is reduced, the throughput per channel and the number of re-syncs should show improvement.
BSChannelViewer can request channels in a sliding group of 32 at a time.
The current ActiView versions (705, 706, 707) have no option to request a reduced set of the available channels.
Generally, wired connections are faster than wireless connections, even if only one of the computers is using a wired connection. And wired connections usually give more consistent throughput.
Another option is to skip the router altogether by setting up a direct computer-to-computer connection using an RJ45 Crossover ethernet cable. This has been used successfully for client/server operation between Windows 7 and OSX with locally assigned IP numbers. Once the cable is connected use "Network Preferences" on OSX and "ipconfig" on Windows to determine the self-assigned IP numbers and verify the connection using "ping". Then add the server's numbers into the client's ringbuffer.ini file and run the programs as normal.