Making a Digital Oscilloscope UI

March 09, 2015 | 10 Minute Read

I previously setup a way for C / C++ programs to communicate to a JS client using Thrift. Now, I want to use that framework to actually build a nice frontend for the Digilent Analog Discovery. My friend Sam Oliver helped me by building the frontend part of this using D3.

Since Thrift autogenerated all of the code to handle the remote procedure calls, all I had to do was implement the functionalities that I provided. One of the annoying aspects was that my C++ server couldn’t initialize any communications, it could only respond to JS requests, but I was able to work around that without too much of a hassle.

C++ Server to communicate between JS GUI and DWF Library

I first tried using ScanShift acquisition mode with the idea of sending the most recently updated buffer every time a request is made. This makes it seem like it may be convenient to use a thread to handle the consistent discovery polling actions, but we’ll try it without first. Also, note that the dwf.h file declares some constants, which causes some nasty multiple definition errors when compiling, so be careful.

Throughput Testing

Enabling quick communication between the JS and C++ over Thrift was necessary to ensure a good UI on the frontend. Sam did a great job on the charting side of things and was able to create a chart of 5000 data points in 15 ms, which is about 50X faster than Google Charts, which probably spends a fair amount of time making server queries and adding unecessary information. So, I focused on the Thrift communication to assess the bandwidth. Here is a chart I created from assessing the latency of several payloads of varying sizes:

Test Performed Using JSON Protocol and HttpServerTransport

The linear fit had parameters:

m = 9.277 * 10^-4 ms / Byte
b = 13.325 ms

One strange thing I noticed was that at 128989 bytes, the transactions got ridiculously slow, like 9.155 S. I’m not really sure why it so precipitously declines at that precise point, but it seems like it would be interesting to look into. I can only assume that this could be some sort of paging issue, but that’s just a guess.

So, it looks like it would be quite worthwhile to attempt to optimize my payload size. I will be sending at most 8200 ADC values at a time. Currently, I am sending double values which are easy to represent our situation, but are quite inneficient in space, each taking up 8 bytes as opposed to 2 (the Analog Discovery has a 14-bit ADC). I’ve also been sending a 32-bit integer as a timestamp along with the values, so I think I could take my 12 bytes of representation and use only 2.

Upon further inspection I noticed that by sending an list of objects as opposed to a list of values I was incurring a fair amount of overhead, so I switched to just sending a list of double values.

The question is whether the conversion from double to int16 and back again will be efficient enough. I am almost certain that it will be. Also, note that by basically encoding our ADC values, we have decreased the portability of this data, however since we have closed loop control of the entire system that seems like a fairly trivial problem. I compared the difference between sending an array of 16-bit integers and doubles and here are the results:

This seems strange, since the double’s time increases about twice as fast, even though it should be increasing 4 times as fast since doubles are typically represented as 64 bits, perhaps there is some compression going on.

For the max data output of the AnalogIn Signal (8192 points), here are the median latencies in milliseconds using various datatypes in testThroughput.

The interesting thing to note here is that the pair of a timestamp with a double incurs more overhead than that due to just the added i32 timestamp. The conversion back and forth between ADC values incurs a slight overhead, but definitely seems to be worth it in terms of performance, almost halving transmission time.

I then setup a test to get the difference in transmission of actual data between sending a double and sending a i16 w/ the conversion. These are the results:

So, using the ADC value seems to shave a meaningful 10ms off, but it seems like some overhead is introduced when viewing the difference between these results and the ones viewed above. There is a total of ~16ms added to the transmission when just querying the Discovery, which I discovered by doing all of the normal things and then returning an empty array. So, we should be able to get to a transmission time of about 17ms by using threads.

Boost Threads

In the past I’ve used pthreads with great success, but since Thrift seems to already use Boost, I thought now would be as good of a time as any to try out Boost threads. The idea I have is to use the RPC functions to merely copy from an array that is populated by a continually running device thread.

I got started using Boost threads here. I had a little run in with linking issues and ended up finding help here. There was an interesting compiler option that I used which looked like:

-Wl,-rpath=${path_to_libs}

I believe it invokes the linker partially during compilation and uses the lib in rpath.

After I created the device handling thread i was able to get the runtime back to just involve the transaction overhead, so ~17ms!

Creating Interfaces for Analog Discovery Measurements

The first thing that I had to do was actually fix the header file that digilent provides people with. It’s located at usr/local/include/digilent/waveforms/dwf.h. I modified all of their const variables which they were initializing to be static const, otherwise when you include it more than once you’d get a multiple definition error on linking.

I hope to follow this with updates on future additions and improvements to the project.

« Making a Simple UI for C Programs First Travel Entry / Getting to Taiwan »