All BitScopes now networked !
2013-12-17
Recently we announced BitScope Server, a light weight server for Linux, Windows, Mac OS X and ARM (Raspberry Pi) that makes any BitScope available via IP based networks, just like our network models.
All BitScopes now networked !
In a nutshell it means any BitScope, whether it has built-in networking like BS445N or is a USB connected model like BS10 can now be accessed via a network when connected to a host running BitScope Server (even a tiny host like Raspberry Pi).
The server supports 22 BitScope Models, is compatible with existing BitScope software and libraries and comes with built-in device simulators for offline use. It can serve network BitScopes (like Sydney) or work as a proxy for other instances of itself allowing BitScopes connected to private networks to be published on the Internet (via a gateway) without exposing the private network.
Today we've published packages for Linux and Raspberry Pi (click Download Server and choose the correct deb or rpm package for your system). The server is in development so these beta packages may have bugs but our in-house testing has been very successful so far.
We welcome your feedback if you try BitScope Server remotely using our online demo or with your own BitScope connected to a Linux PC or Raspberry Pi (Windows and Mac coming soon). Please see our earlier post for more information about the benefits of using BitScope Server and details about how server based networking works.
BitScope Server is currently a command line program with built-in help:
alex@anna:~$ bitscope-server --help Usage: bitscope-server <options> -h,-?,--help | print this help -v,--verbose | verbose output, for debugging -c,--count N | open up to N devices (default:1) -p,--port P | open starting at port P (default:16385) -l,--latency L | assign server latency L in ms (default:8) -d,--daemon | start in daemon mode (from command line) -i,--install | register the daemon. This has no effect under unix. -u,--uninstall | unregister the daemon. This has no effect under unix. -r,--run | start the daemon. Windows does this. Do not do it manually. Assign a larger latency for lower CPU load if necessary. Use verbose from command line only. Note that only -h and -v are implemented in this beta release. alex@anna:~$
We recommend you run it with the --verbose option so you can see what it's doing as it executes. By default it opens network port 16385 on the server host. This is the standard port used by BitScope. Any BitScope software application running on the same host may then connect to the server simply by using the link specification localhost.
BitScope Server, localhost connection from DSO.
For example, using DSO SETUP BitScope DSO can be configured to connect to the server as shown here. All BitScope software applications may be configured similarly.
When run on one PC, the server allows multiple software applications to share the same BitScope at the same time.
More interestingly it allows the BitScope to be accessed and shared from other hosts on the same network or even via the Internet if the IP address is publicly visible (or when proxied via a gateway instance of the server).
This means any number of users on different PCs, Macs or other computers can use any supported BitScope application to share access to one or more BitScopes. Even custom applications built with the BitScope Library (for example, Proto Scope) can transparently share devices via BitScope Server because network connectivity is built into the library itself.
BitScope Server uses the same configuration system as other BitScope software. It uses a probe file.
The default probe file is a text file called BitScope.prb which is normally managed automatically by BitScope software (via the SETUP dialog) or the library. For full information please see the BitScope Library probe file reference.
In the case of BitScope Server the probe file is called BitServe.prb and it has the same format and lives in the same directory as BitScope.prb. The server consults this file when it starts to know which (of possibly many) BitScopes it is to serve. If the probe file does not exist BitScope Server attempts to open BitScopes it finds at several standard locations.
At present there are no tools to create BitServe.prb but the easiest way is simply to copy BitScope.prb to BitServe.prb (to have the server connect with the same devices the BitScope software uses) or not create it at all and let the default values kick in (which works in most cases). When the server is installed, configured and running you can then simply select localhost (as above) via the SETUP to connect to the BitScope via the server (instead of connecting directly).
BitScope Server running on Raspberry Pi.
Our favorite host for BitScope Server is of course a Raspberry Pi! In fact it's one of the primary reasons we developed the server because unlike other networking solutions, BitScope Server is a very light weight process that can run multiple instances on low power hosts like Raspberry Pi without breaking a sweat :-)
Shown here is the server start up with verbose output. It opens a USB BitScope that it finds connected to /dev/ttyUSB0 and serves it on UDP port 16385 on host "raspberrypi".
The server process is 3986 and comprises two server threads, one for downstream data (B60D5470) and the other for upstream (B64D5470). It starts with an idle/start latency of 8ms which is a parameter that allows the server CPU load to be balanced against server responsiveness; when running many instances you can increase this to avoid overloading the CPU. In the case of Raspberry Pi this becomes useful when running more than 6 ot 7 instances but for a typical x86 host it's really only needed when you push beyond about 20 (based on preliminary testing on an i3).
Once the server is listening for connections it will report each time a new client connection is received (in this case from host 59.167.160.189, our office NAT gateway address) and normally that's all there is to it!
When run in verbose mode and a problem occurs (e.g. cannot find a BitScope) the server will report in detail why it cannot start and what steps to take to resolve the problem. If there are operational problems (e.g. packet loss on a flakey WiFi network or the Internet) it will report this too. For example, here's the startup log with no BitScope:
pi@raspberrypi:~$ bitscope-server -v Server: BitScope Server 1.0 DL10A starting... Server: NO DEVICE AVAILABLE 1. Check an instance of the server is not already running. 2. Delete any stale lock file for the device (in /var/lock) 3. Check your USB BitScope is connected, working and powered on. 4. Confirm the device descriptor exists (e.g. COM4, /dev/ttyUSB0 etc) 5. Connection is normally automatic (if the descriptor exists). However, you may need to create a server probe file if the descriptor does exist but the server still fails to connect. This appears to be what has happened here so create a probe file called "bitserve.prb" and put it anywhere in the path "/home/pi/.config/bitscope:/home/pi/.bitscope/config:/etc/bitscope". 6. Ensure the server process has permission to access the server probe file. 7. Ensure the probe file lists your device (e.g. USB:COM4, USB:/dev/ttyUSB0 etc) 8. For more troubleshooting information see http://bitscope.com/software/driver pi@raspberrypi:~$
Alternatively, if the server probe file does exist it may contain a fall-back simulation option in which case you might see:
pi@raspberrypi:~$ bitscope-server -v Server: BitScope Server 1.0 DL10A starting... Server: opened device NIL:BS001003:SIMULATE:METACHIP Server: opened UDP socket on "raspberrypi" port 16385 Server: starting server process 10392 Server: server idle/start latency 8 ms Server: downstream thread B6473470 running Server: upstream thread B689B470 running Server: listening for connections (press <ENTER> to terminate).
which means the server has started but not found a BitScope so it has fallen back to simulating one. If you don't want this to happen, delete the NIL: entry from the default probe file.
We plan to make BitScope Server available for Windows and Mac OS X with access for control via a graphical user interface soon and we're adding support for TCP/IP (and possibly SSL) down the track. At present the server can connect to a single BitScope per server instance but we will be adding support for multiple BitScopes per instance (i.e. it will open all BitScopes listed in the probe file) to allow arrays of BitScopes to be used in larger multi-channel data acquisition applications using the BitScope Library.