This is my first post here. I am eagerly awaiting my quad beta - ETA March.
On the subject of using an external display, I have to say this has some merit. But it’s probably smarter still to walk before running.
What we need is an “Interface Design spec” for two files.
Output file - where parameters which have been sampled go; and
Input file - parameters to control the Quad go.
Initially the files can both be accessed externally using the USB. The external host just needs to be able to access the USB file system, so it could be any garden variety Linux, Mac, or MS based PC. Latter on you could add on bluetooth access to the file system if you want, though this may be a bit more tricky.
both files could be a really simple format CSV, eg:
output:
time, a-value, b-value, c-value, d-value
input:
time-scale, a-scale ,b-scale, c-scale, d-scale, sample-rate, etc
These files are very simple because at least in principle the host is doing all the hard work to display the data, and the quad just needs to write the nearly raw output from the A/Ds. Obviously the file formats will need to be adjusted when doing signal generation.
The output is continually written to by the quad during normal operation and read continually by the host. Input is normally written by the host when the user selects a new scale or whatever. The quad could poll the input file or more efficiently - just read it when the saved date/time changes.
As file accesses is handled on the host by the host OS, the quad application (running on the host) is really just a gui for displaying the data and controlling how it is displayed. Potentially it could be written as a Java application which can run on anything.
The only issue is that this approach has already been done. Just google “digital oscilloscope computer”, but not at a price that competes with the quad. It least if the quad approach is kept open source.
