The following image shows the browser presentation.
|Chrome with AdcHttpd on a BeagleBone Black with 16 bit DDC data from a LX9|
The browser tab consumes about 10% of a CPU core on an older PC (AMD 1.8GHz quad core) and about 1% load on the Ethernet interface. The BeagleBone is at 98% running the http server. The BBB limits the update rate based on its ability to process the samples (fftw for ARM is used for best performance).
There are several components to the internals of the browser code, http server code, hardware model, and device code on the BeagleBone Black. The basic model is that the server is the definitive controller of state and operations while the browser code simply requests changes and conducts presentation. At the highest level the following sequence diagram summarizes the interactions of the application.
|Browser-AdcHttpd Summary Sequence Diagram|
The server is more involved and is responsible for not only acquiring the data and processing it but also presenting it in JSON format to the client. The following sequence diagram summarizes the key server components and interactions.
|Summary Sequence Diagram of AdcHttpd Internals|
There are only two autonomous lifelines here by design. The first is the http server thread that interacts directly with the client and processes the http GET requests. The second is the hardware model thread which drives processing of data and hardware interactions. The only point the two threads interact is the hardware data model. The interactions are designed to require minimal locking and interaction between the two autonomous threads. This keeps things conceptually simple and decouples the browser client and its interactions and requests from the core hardware servicing and operations. The hardware object model contains the current and desired operation parameters along with the most recent XY data to be presented in the browser application.
The hardware model thread checks various operating parameters based on their current value in the memory shared with the http thread. If changes have occurred, the hardware model thread calls the appropriate device object methods to change the operating parameters. Examples include which channel is being processed/exported by the hardware and the frequency of the downconversion local oscillator. After a check on current parameters the hardware model thread invokes the ProcessCoherentInterval() on one of the processing objects. There are processing objects for each of the main types of processing: power spectral estimation, time series, and histogram. The product of processing a coherent interval is a set of XY points which is updated in the hardware model (and can then be accessed by the remote client via the main http thread). The hardware model thread continually loops on this processing until a reset is conducted.
Each of the processing objects deals with a coherent interval a little differently. The key one is the power spectral estimation processing. Since the data rates of the selected ADC channel can exceed the processing capability (indeed the network transport capacity), a processing interval is treated as a flush of current ADC data followed by the acquisition of one or more sets of 2k samples. The collected data is treated as a coherent set and in the case of spectral estimation has a window applied along with an FFT and magnitude and normalization applied to produce the XY results. In the case of low sample rate channels, 16k or more samples can be treated coherently since successive Get2k calls retrieves contiguously sampled data. For streams with high bandwidth, the user simply has to not configure power spectra estimates greater than 2k (if you do you just get phase discontinuities across 2k sample sets and see spectrum broadening).
The device object encapsulates different boards. There are a common set of C++ ADC and Mixer interfaces required that each board exports. The startup method for the device object selects which boards and interfacing software to use. This can be done by configuration file, code changes or reasoning on which device tree(s) are currently installed.