Shared and remote network access for any BitScope!

We have long supported direct network access for remote data acquisition and diagnostic work with our network BitScope models such as BS325N or BS445N. It's how the SYDNEY online demo works across the Internet.

Network BitScope connection model.

These models can be used remotely without the need for a server because they are LAN connected devices that use the UDP/IP stack to transport BitScope Packets directly between BitScope and the host. They can do this because they have a built-in LAN Interface Adapter (called LIA).

However, we have received many requests to do the same thing with USB BitScopes so in a recent blog post we demonstrated how to connect USB BitScope models like BitScope Mini to a network using tools such as VNC and X.

In that case we used a Raspberry Pi as the VNC server or X client with off-the-shelf hardware and software solutions to connect USB BitScope via a network. While these solutions work in many cases they are not always ideal; not everyone has an X server based host and VNC can be tricky to use in some situations.

The BitScope Server Solution

We set to work to replicate the functionality of BitScope LIA as a server that can run on any host, even the PC on which the BitScope software is run. This solution has the following benefits:

Network BitScope Command Packet Format.

1. Uses the same simple and open UDP/IP based protocol that Network BitScopes already use.
2. Is very light-weight and efficient making it suited to low power hosts like the ARM based Raspberry Pi.
3. Allows USB, Network and Serial BitScopes to be accessed the same way (i.e. as network devices).
4. Allows one or more BitScopes to be shared between multiple software applications simultaneously by one or more users on one or more PCs.
5. Allows custom software written with the BitScope Programming Library or written to the native VM programming API to be used with any BitScope. The protcol is simple and published so you can even write your own if you want.

The figure above shows the command packet format used by Network BitScopes and the BitScope Server.

It is simply a command token (Cmd_ID which is just a sequence number) followed by 1 to 64 bytes of data. In the case of the BitScope Server (as opposed to LIA) the packet size can be much larger; up to the MTU payload size supported by the network. However in practice it's rarely necessary because BitScope command packets are typically very small.

Network BitScope Reply Packet Format.

Command packets can be this simple because BitScope's native byte-code protocol is atomic and stateless; handshakes are implicit. The Cmd_ID allows the server to reorder packets and to detect dropped packets and recover if necessary.

The reply packets are similar. In this case there are additional header fields which include the LIA_ID and Data_Seq. The most recently received Cmd_ID is also returned.

The Data_Seq performs the same function for reply packets as the Cmd_ID does for command packets; it allows out of order or dropped packet detection. The LIA_ID identifies the LIA adapter itself but is normally unused by the server. The reply packet payload data size can also be much larger than the 95 byte limit of LIA.

And that's all there is to it! All the existing BitScope software and any software written using the BitScope Library can use the Server "out of the box" and because it's encapsulated in UDP/IP it can be used via Intranets or the Internet to form the basis of powerful low cost remote access test, measurement and data acquisition solutions.

Using BitScope Server

BitScope Server can be invoked from the command line as:

			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:~$ 
		

When run on the local host it opens a network port (16385 by default) which may connected using the link specification UDP:localhost. When used this way it allows multiple applications on that host to share the BitScope simultaneously.

It may also be run remotely on a different PC or on an embedded system like Raspberry Pi.

We will post the initial beta release of BitScope Server along with documentation for its use shortly. First up it will be available for x86 based Linux systems and ARM platforms (Raspberry Pi) and we'll set up a remote demo system you can use to connect via the Internet to see how it works from the end-use software perspective.

We also plan to make BitScope Server available for Windows and Mac OS X with access for control via a graphical user interface in this case and we're adding support for TCP/IP (and possibly SSL) down the track.

Stay tuned, more soon...