seabreeze-interest — Discussion of SeaBreeze architecture, API, feature proposals, code reviews, etc

[Seabreeze-interest] USB2000+ Firmware version

[Chris P. <chp...@gm...>]

I'm upgrading a project from the old OOIWinIP 32-bit driver to SeaBreeze.
So far, everything is going smoothly. SeaBreeze compiles (VS2010) and I can
get spectrums all day!

But part of our object retrieves the firmware version number and displays
it in the about box so Service can use that for debugging.

Our app supports the USB2000 and USB4000 as well. I've tried the get
revision features calls but there are none so a call to
sbapi_revisionFirmwareGet cannot be used.

I suspect that it will take some calls to the endpoints directly. Any help
would be fantastic.

Thanks,

Chris

Re: [Seabreeze-interest] simplifying the user interface by assuming only one feature ID for certain parameters.

[William K C. <kir...@ic...>]

Mark,

Although my earlier question was posed within the context of my current work, testing a rapid development tool as a multi-platform GUI for SeaBreeze, it was expressed from the perspective of future work, hence the confusion. In my limited exposure to SeaBreeze, I’ve come to see it as a testament to object paradigm, a development framework within which each entity of functionality is expressed as all others in near perfect symmetry. Rather than being written as a proprietary foundation specifically for Ocean Optics instruments, it includes provision for diverse vendors, just as it provides for protocols, devices, buses and for this discussion, features. However, that diversity comes with a price, which prompted my earlier question concerning user interface design. Given a particular instrument it is clear that the GUI should be written specifically, but when designing an internal test, or a piece of software that is intended for general use across the Ocean Optics product portfolio, what then? From my, as yet, limited experience with the Ocean Optics product portfolio, it seems that in most cases calling get_number_of_(whatever)_features() is mute. It should be safe to assume that for all instruments, (with Jaz let’s say spectrometer module) there will be only one set of nonlinearity coefficients, one set of stray light coefficients, one thermoelectric cooler per optical bench. But as a novice developer for Ocean Optics, or in the case of using the open source foundation of SeaBreeze, how is one to know? Although SeaBreeze has a high level of reusability, it comes with a the price of a high entry threshold and steep learning curve both extending or using it. To add just one feature, one must comprehend the entire framework. To build a user interface and not spend an eternity doing so, as Dirty Harray said, “A man’s got to know his limitations.”

As an engineer and programmer, I admire the elegance and beauty of SeaBreeze, however as a user of the API I dread it like a writer dreads a blank page; freedom and opportunity overridden by the need for pragmatism. What one wins in the framework is lost in the lack of documentation. Ironically, the versatility of the vendor folder has gone unnoticed by the open source community. After adding several features during my STS work, before becoming part of Ocean Optics, I finally resorted to writing a how-to guide for adding features, having chased a plethora misleading compiler errors for an inordinate amount of time due to a missing an intermediate class. Now I face the same type of omission when designing a generic user interface. When is a get_number_of_(whatever)_features() applicable? Should a nonlinearity coefficient interface be designed to support multiple sets? If every interface were designed in that way, the GUI would become unforgivably cluttered and incomprehensible. This seems to be the classic composition verses inheritance question, but back to the point.

The framework of SeaBreeze implies that one should call always get_number_of_(whatever)_features(), but is it reasonable to treat this more like a call to does_(whatever)_feature_exist() and ignore the possibility of more than one instance of certain features? 

As well, can one assume all of members of a particular feature set are the same throughout the product portfolio? For example, is the temperature sensor at index 1, always located on the optical bench and those at index three always near the processor? Probably not. In future extension of SeaBreeze, should we create device oriented introspection within the framework so there is a way to gain specificity as the feature framework is traversed from device to feature implementation? 


Regards,


-kirk-


> Just to confirm, are you talking about your proposed design for EMBED Dev Kit, Soleras, a stripped-down SeaBreeze, a Xojo wrapper...? Assuming the first, and if so full agreement.
> 
> Even in Winter Park, my first reply to most of our engineers (Doug and Goran can confirm) is, "What project are you talking about?" :-)
> 
> Thanks,
> 
> Mark
> 
> 
>> On May 23, 2015, at 3:39 PM, William K Clendinning <kir...@ic...> wrote:
>> 
>> Mark,
>> 
>> Although for completeness’ sake, when accessing something like nonlinearity coefficients or scans to average, the number of possible featureIDs should be gotten with a call to get_number_of_(whatever)_features(), then all the feature IDs retrieved with a get_(whatever)_features() call. Then for each feature ID, a collection of something like nonlinearity coefficients or a parameter like scans to average would be read or set. However, my limited knowledge of the current product line presents me with no cases where a spectrometer (or Jaz spectrometer module) would have more than one set of such a feature. Is that a reasonable assumption? It’s clear that the Seabreeze API architecture should have the capability for multiple instances of a particular feature, but pragmatically, when designing a user interface, having the capability for multiple sets of something like nonlinearity coefficients, for a particular spectrometer bench, seems to unduly complicate matters. I’m planning on only providing one set of nonlinearity coefficients, one set of stray light coefficients, one scans to average, one boxcar filter width, etc. Do you see a problem with that, which I might be missing?
>> 
>> 
>> Regards,
>> 
>> 
>> -kirk-
>> 

[Seabreeze-interest] Boxcar

[Mark Z. <mar...@oc...>]

Hi Kirk,

> Added support for boxcar filter width and scans to average in a spectrum processing family. 

Heh...those were always issues of contention at Ocean. I support your addition, and look forward to reviewing your changes when merging to trunk.

Do you anticipate being ready for a merge soon? Branches become difficult to review and merge when many unrelated changes are all done at once.

Thanks,

Mark
********************************************************

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this communication is
strictly prohibited. If you have received this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
version.

********************************************************

Re: [Seabreeze-interest] doxygen on Mac

[Mark Z. <mar...@oc...>]

Hi Kirk,

It’s always worked on my Macs, but I’ve been using the Doxygen and Dot available through MacPorts:

wpk-mac-oem.local [~/work/gforge/seabreeze] mzieg  6:43AM $ which doxygen
/opt/local/bin/doxygen
wpk-mac-oem.local [~/work/gforge/seabreeze] mzieg  6:43AM $ which dot
/opt/local/bin/dot
wpk-mac-oem.local [~/work/gforge/seabreeze] mzieg  6:43AM $ make doc
expunging old docs...
generating user docs...
generating developer docs...

Rendered documentation can be found in doc/, especially:

-rw-rw-r--  1 mzieg  staff   681K Jan 28 06:43 doc/rtf/SeaBreezeWrapper_User_Manual.rtf
-rw-rw-r--  1 mzieg  staff   2.2M Jan 28 06:51 doc/rtf/SeaBreeze_Developer_Manual.rtf

I think this isn’t a “per-OS” thing, so much as a “per user environment” thing.

Out of curiosity, does the current Makefile work on your system if you add the path to libxdot.4.dylib to these standard Mac environment variables?

export DYLD_FALLBACK_FRAMEWORK_PATH=“$DYLD_FALLBACK_FRAMEWORK_PATH:/usr/local/lib”
export DYLD_LIBRARY_PATH=“$DYLD_LIBRARY_PATH:/usr/local/lib”

I’d rather use standard variables than make up new ones if possible.

Regards,

Mark


On Jan 28, 2015, at 2:31 AM, Kirk Clendinning <ki...@cl...<mailto:ki...@cl...>> wrote:

I’ve modified the top SeaBreeze makefile to find dOxygen on OS X. A DOXYGEN_BASE may now be modified for each OS to set the file path. On OS X 10.10.2,  "dyld: Library not loaded: /usr/local/lib/libxdot.4.dylib” is output by the build. Using graphviz-2.36.0.pkg<http://www.graphviz.org/pub/graphviz/stable/macos/mountainlion/graphviz-2.36.0.pkg> seems to fix the problem.

-kirk-

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________
Seabreeze-interest mailing list
Sea...@li...<mailto:Sea...@li...>
https://lists.sourceforge.net/lists/listinfo/seabreeze-interest

********************************************************

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this communication is
strictly prohibited. If you have received this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
version.

********************************************************

[Seabreeze-interest] doxygen on Mac

[Kirk C. <ki...@cl...>]

I’ve modified the top SeaBreeze makefile to find dOxygen on OS X. A DOXYGEN_BASE may now be modified for each OS to set the file path. On OS X 10.10.2,  "dyld: Library not loaded: /usr/local/lib/libxdot.4.dylib” is output by the build. Using graphviz-2.36.0.pkg <http://www.graphviz.org/pub/graphviz/stable/macos/mountainlion/graphviz-2.36.0.pkg> seems to fix the problem. 

-kirk-

Re: [Seabreeze-interest] sts temperature feature development

[Mark Z. <mar...@oc...>]

Hi Kirk,

 I purchased Cornerstone for OSX to connect conveniently to the SeaBreeze repository.

Let me know how that works.

If you’re comfortable from shell, the ‘svn’ client available as part of MacPorts<https://www.macports.org/> works well too.  This is how I checked-out my branch:

OEM-MacPro.local [~/work/tmp] mzieg  6:38PM $ which svn
/opt/local/bin/svn

OEM-MacPro.local [~/work/tmp] mzieg  6:38PM $ svn --version
svn, version 1.8.8 (r1568071)
   compiled Feb 20 2014, 14:13:36 on x86_64-apple-darwin13.0.0

Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - using serf 1.3.4
  - handles 'http' scheme
  - handles 'https' scheme

OEM-MacPro.local [~/work/tmp] mzieg  6:38PM $ svn co --username=mzieg svn+ssh://mz...@sv.../p/seabreeze/code/branches/mvz-lsl

Cheers,

Mark

On Jan 27, 2015, at 1:33 PM, Kirk Clendinning <ki...@cl...<mailto:ki...@cl...>> wrote:

Mark and Aaron,

I had a reasonable amount of time to program today and will probably have something put into my branch soon. I’m used to git and mercurial rather than subversion. I purchased Cornerstone for OSX to connect conveniently to the SeaBreeze repository. If all goes well, I assume that I can commit _only_ my branch and you should soon be able to see it.

I’ve implemented a new temperature feature family with:

a TemperatureFeature
a TemperatureFeatureAdapter
an OBPGetAllTemperaturesExchange
an OBPGetTemperatureExchange
an OBPGetTemperatureCountExchange
an OBPTemperatureProtocol
a TemperatureProtocolInterface

in support of the TemperatureFeatures
vector<double> *readAllTemperatures(const Protocol &protocol, const Bus &bus)
double readTemperature(const Protocol &protocol, const Bus &bus, int index)

I also added getCPUTemperatureCelsius(const Protocol &protocol, const Bus &bus) and getDetectorTemperatureCelsius(const Protocol &protocol, const Bus &bus) to the STSSpectrometerFeature.

I’ve tested the general readAllTemperatures and readTemperature functions in the test_api; they work as expected. I think I’m going to do a seabreeze_sts_test program based on the test_api to exercise my STS and allow me to test new functionality.


Regards,


-kirk-
On Jan 26, 2015, at 11:33, Mark Zieg <mar...@oc...<mailto:mar...@oc...>> wrote:

Hi all,

Great thread :-)

Adding sea...@li...<mailto:sea...@li...> to the distro for retention.

Thanks for diving in so quickly!

Regards,

Mark

On Jan 25, 2015, at 4:20 PM, Aaron Gage <ra...@gm...<mailto:ra...@gm...>> wrote:

Kirk --

That sounds good.  The protocol layer on up through the feature layer may already be the way we need it to be; it's just the API layer where I'm likely to rework things.  I can handle the details there -- don't worry about spending more time on it -- so feel free to push what you have to a branch when you're ready.  It may take me a little while to get my part done, but I do intend to do it.

If you work with the STS a bit you may find that the baseline does not drift.  While it isn't exactly electric dark correction at work, it locks in pretty well.  However, keeping the baseline appearing constant in effect pulls the saturation level down as the temperature rises.  The saturation value is always the same (16383) but you may find things jumping there before you'd expect them to in case this compensation has had to pull it too far.  If you didn't already know this, there is a way to read out the raw spectrum (without this compensation) which should be used when adjusting the integration time against a reference light level.  This ensures that you have some margin on the dynamic range, regardless of what the temperature was at the time.  I haven't checked to see if SeaBreeze supports the raw spectrum for the STS, but if it does not, I think it is something we should add.  It's certainly recommended for experiments that may occur with wide temperature variations for that particular device.

Regards,
Aaron

On Sun, Jan 25, 2015 at 3:32 PM, Kirk Clendinning <ki...@cl...<mailto:ki...@cl...>> wrote:

Here’s the test code results. It works the same as the nonlinearity test.

Testing temperature features:
Getting number of temperature features:
Result is 1 [Success]
Getting temperature feature IDs...
Result is 1 [Success]
0: Testing device 0x02, temperatures 0xE0000
Attempting to get temperatures...
Result is 3 [Success]
Temperature(0): 22.18
Temperature(1): -34.04
Temperature(2): 38.34
0: Finished testing device 0x02, temperatures 0xE0000
Finished testing temperature capabilities.


void test_temperature_feature(long deviceID) {
    int error = 0;
    int number_of_temperature_features;
    long *temperature_feature_ids = 0;
    double buffer[10];  // how many temperatures could there be on _any_ given spectrometer
    int i;
    int length;

    printf("\n\tTesting temperature features:\n");

    printf("\t\tGetting number of temperature features:\n");
    number_of_temperature_features =
        sbapi_get_number_of_temperature_features(deviceID, &error);
    printf("\t\t\tResult is %d [%s]\n", number_of_temperature_features,
            sbapi_get_error_string(error));

    if(0 == number_of_temperature_features) {
        printf("\tNo temperature capabilities found.\n");
        return;
    }

    temperature_feature_ids =
        (long *)calloc(number_of_temperature_features, sizeof(long));
    printf("\t\tGetting temperature feature IDs...\n");
    number_of_temperature_features = sbapi_get_temperature_features(
            deviceID, &error, temperature_feature_ids,
            number_of_temperature_features);
    printf("\t\t\tResult is %d [%s]\n", number_of_temperature_features,
            sbapi_get_error_string(error));

    for(i = 0; i < number_of_temperature_features; i++) {
        printf("\t\t%d: Testing device 0x%02lX, temperatures 0x%02lX\n",
                i, deviceID, temperature_feature_ids[i]);

        printf("\t\t\tAttempting to get temperatures...\n");
        memset(buffer, (int)0, sizeof(buffer));
        length = sbapi_temperature_get(deviceID,
            temperature_feature_ids[i], &error, buffer, 10);
        printf("\t\t\t\tResult is %d [%s]\n", length, sbapi_get_error_string(error));
        for(int t_index=0; t_index<length; t_index++) {
        if(0 == error && length > 0) {
            printf("\t\t\t\tTemperature(%d): %2.2f\n", t_index, buffer[t_index]);
        }
}
        printf("\t\t%d: Finished testing device 0x%02lX, temperatures 0x%02lX\n",
                i, deviceID, temperature_feature_ids[i]);
    }
    free(temperature_feature_ids);

    printf("\tFinished testing temperature capabilities.\n");
}


-kirk-



On Jan 25, 2015, at 16:24, Aaron Gage <ra...@gm...<mailto:ra...@gm...>> wrote:

Mark --

Yes, I'm willing (time permitting).  However, I don't know if I'll need test hardware.  Most of the changes I want to make are at the API layer, so as long as the protocol layer works, I can probably get pretty far without running on a real device.  It sounded like Kirk would be providing the protocol layer for the STS features and I should be able to just use that (and all of the existing TEC code) as a starting point.  The other devices can have those features filled in later (basically just plugging in features once a suitable protocol implementation exists).  If I were to get test hardware, I'm not sure which device(s) would be most appropriate, and I don't know what conditions there would be for that.  If I did the coding, would you be able to do the testing?

If you wanted this to extend to all devices, not just the STS (with Kirk's patch) and the devices that currently support the TEC, then it might help me to have a summary of how this was done in next-gen OmniDriver (which devices have TEC or standalone temperature sensor features, what the op-code and format in the protocol-layer exchanges were, and possibly whether the protocol implementation was firmware-version-dependent).  I don't entirely trust the datasheets to capture all of the nuances.

--Aaron


On Sun, Jan 25, 2015 at 8:53 AM, Mark Zieg <mar...@oc...<mailto:mar...@oc...>> wrote:
Hi Aaron,

I fully support everything you’ve described (and yes I’m familiar with the analogous changes to OmnIDriver), but I’m not able to resource it at this time.

Are you indicating willingness to make some of these changes yourself?  If so, can I provide test hardware?

I will say that Kirk is not the only customer interested in seeing temperature functions added to SeaBreeze.

Regards,

Mark

On Jan 25, 2015, at 8:44 AM, Aaron Gage <ra...@gm...<mailto:ra...@gm...>> wrote:

Greetings Kirk --

It will be nice to have more of the STS functions brought out in SeaBreeze.  I think that you'll find that adding support for new commands in its protocol is straightforward.  Many commands for the STS will also work as-is for the QEPro which is nice.  I am a little curious as to how you are using the temperature with regards to checking whether a dark spectrum is valid, since the STS uniquely keeps its own baseline pretty flat over temperature, but your experience may indicate this is not enough.

That said, there are some changes I want to make to the SeaBreeze API relating to temperature.  I wanted to float this idea well ahead of any actual changes, so that (A) you would know these changes might be coming and (B) we can all discuss any change to the API that may have widespread effects on users.  I don't want to discourage you from contributing what you have, but I want to make sure you're aware that there may be architectural changes that affect it afterwards.

The STS has two temperature sensors: one in the microcontroller itself (which reads about 10-20C above ambient) and one on the detector board (which reads much closer to ambient).  Some other spectrometers have one (TEC on QE?) or the other (USB2000+?) or both (QEPro?).  I propose that the API should be designed as follows:

* New BoardTemperature interface with getBoardTemperatureCelsius() function
* New DetectorTemperature interface with getDetectorTemperatureCelsius() function
* Rename instances of ThermoElectricCooler to ThermoElectric or ThermoElectricController (since on some devices this can be used to heat above ambient).  This is a change to the API that might break existing code, so this might wait until a major version change.
* Refactor ThermoElectric class to derive from DetectorTemperature.  This would also break existing code (replacing readTECTemperature() with getDetectorTemperatureCelsius()).
* Separate getting the TEC setpoint and getting the actual TEC temperature into two functions.  The latter (getDetectorTemperatureCelsius()) would be inherited from DetectorTemperature, the former would be new.  There should be explicit support to read the setpoint out of at least the QEPro if not the older devices, and if all else fails, this can be cached (and maybe throw an exception/set the error code if read before being set the first time).

Mark -- I believe that the next-gen OmniDriver already takes this approach in case you want to see how it looks in practice.  I think that this would be cleaner than putting all of the temperature sensor capabilities into a single class, given the overlap with the TEC.  It may also be that the BoardTemperature and DetectorTemperature classes would derive from a single TemperatureSensor class, as long as we don't end up with confusion due to diagonal inheritance of interfaces.

Thoughts?

Regards,
Aaron


On Sun, Jan 25, 2015 at 5:29 AM, Mark Zieg <mar...@oc...<mailto:mar...@oc...>> wrote:
Hi Kirk,

I’ve added you as a developer on the SeaBreeze project.  Your addition of the ability to read the STS PCB temperature sounds helpful, along with the missing free() in the test code.

Rather than you trying to keep your repository in sync with SourceForge, would you be willing to simply make your changes on a branch of the public SourceForge project?  I would ask you not to commit to trunk directly, but we could merge your changes after an informal review process.

Thanks,

Mark Zieg

To: <mz...@us...<mailto:mz...@us...>>
From: <cle...@us...<mailto:cle...@us...>>
Reply-To: <cle...@us...<mailto:cle...@us...>>
Subject: Working with SeaBreeze
Cc: <cle...@us...<mailto:cle...@us...>>
Date: January 25, 2015 at 3:54:51 AM EST


Mark,

I hope your holidays were good. I'm glancing out the window at the snow that fell yesterday, looking forward to my move to the USA when my wife gets her green card. In the mean time, I've been doing some work with a couple STS spectrometers.

I've had to do a bit of tinkering in SeaBreeze to work around the missing shutter in the STS. Namely, it's nice to have detector temperature to know if a Dark Reference is valid. I simply used the nonlinearity coefficient family as a template, created a Temperature family and did some cutting and pasting to provide a facility to read temperatures. If I have time, I'll put in an indexed get to fully support the STS USB command set for temperature.

I did a read only check out of the latest SeaBreeze (wouldn't you know it... y'all did work at the same time I did) and set up a local repository. Would you like a patch after I'm done modifying for my purposes? I thought I'd offer. It would be nice to have those changes included in future versions so I don't have to redo them to update.

Oh, I fixed the missing free() in the sts test code. There was an 'if' section with a malloc and no free. I guess that was what your comment referenced.

Regards,

-kirk-


********************************************************

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this communication is
strictly prohibited. If you have received this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
version.

********************************************************


********************************************************

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this communication is
strictly prohibited. If you have received this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
version.

********************************************************

[Seabreeze-interest] sts temperature feature development

[Kirk C. <ki...@cl...>]

Mark and Aaron,

I had a reasonable amount of time to program today and will probably have something put into my branch soon. I’m used to git and mercurial rather than subversion. I purchased Cornerstone for OSX to connect conveniently to the SeaBreeze repository. If all goes well, I assume that I can commit _only_ my branch and you should soon be able to see it. 

I’ve implemented a new temperature feature family with:

a TemperatureFeature
a TemperatureFeatureAdapter
an OBPGetAllTemperaturesExchange
an OBPGetTemperatureExchange
an OBPGetTemperatureCountExchange
an OBPTemperatureProtocol
a TemperatureProtocolInterface

in support of the TemperatureFeatures 
vector<double> *readAllTemperatures(const Protocol &protocol, const Bus &bus)
double readTemperature(const Protocol &protocol, const Bus &bus, int index)

I also added getCPUTemperatureCelsius(const Protocol &protocol, const Bus &bus) and getDetectorTemperatureCelsius(const Protocol &protocol, const Bus &bus) to the STSSpectrometerFeature.

I’ve tested the general readAllTemperatures and readTemperature functions in the test_api; they work as expected. I think I’m going to do a seabreeze_sts_test program based on the test_api to exercise my STS and allow me to test new functionality.


Regards,


-kirk-
> On Jan 26, 2015, at 11:33, Mark Zieg <mar...@oc...> wrote:
> 
> Hi all,
> 
> Great thread :-)
> 
> Adding sea...@li... <mailto:sea...@li...> to the distro for retention.
> 
> Thanks for diving in so quickly!
> 
> Regards,
> 
> Mark
> 
>> On Jan 25, 2015, at 4:20 PM, Aaron Gage <ra...@gm... <mailto:ra...@gm...>> wrote:
>> 
>> Kirk --
>> 
>> That sounds good.  The protocol layer on up through the feature layer may already be the way we need it to be; it's just the API layer where I'm likely to rework things.  I can handle the details there -- don't worry about spending more time on it -- so feel free to push what you have to a branch when you're ready.  It may take me a little while to get my part done, but I do intend to do it.
>> 
>> If you work with the STS a bit you may find that the baseline does not drift.  While it isn't exactly electric dark correction at work, it locks in pretty well.  However, keeping the baseline appearing constant in effect pulls the saturation level down as the temperature rises.  The saturation value is always the same (16383) but you may find things jumping there before you'd expect them to in case this compensation has had to pull it too far.  If you didn't already know this, there is a way to read out the raw spectrum (without this compensation) which should be used when adjusting the integration time against a reference light level.  This ensures that you have some margin on the dynamic range, regardless of what the temperature was at the time.  I haven't checked to see if SeaBreeze supports the raw spectrum for the STS, but if it does not, I think it is something we should add.  It's certainly recommended for experiments that may occur with wide temperature variations for that particular device.
>> 
>> Regards,
>> Aaron
>> 
>> On Sun, Jan 25, 2015 at 3:32 PM, Kirk Clendinning <ki...@cl... <mailto:ki...@cl...>> wrote:
>> 
>> Here’s the test code results. It works the same as the nonlinearity test.
>> 
>> Testing temperature features:
>> Getting number of temperature features:
>> Result is 1 [Success]
>> Getting temperature feature IDs...
>> Result is 1 [Success]
>> 0: Testing device 0x02, temperatures 0xE0000
>> Attempting to get temperatures...
>> Result is 3 [Success]
>> Temperature(0): 22.18
>> Temperature(1): -34.04
>> Temperature(2): 38.34
>> 0: Finished testing device 0x02, temperatures 0xE0000
>> Finished testing temperature capabilities.
>> 
>> 
>> void test_temperature_feature(long deviceID) {
>>     int error = 0;
>>     int number_of_temperature_features;
>>     long *temperature_feature_ids = 0;
>>     double buffer[10];  // how many temperatures could there be on _any_ given spectrometer
>>     int i;
>>     int length;
>> 
>>     printf("\n\tTesting temperature features:\n");
>> 
>>     printf("\t\tGetting number of temperature features:\n");
>>     number_of_temperature_features =
>>         sbapi_get_number_of_temperature_features(deviceID, &error);
>>     printf("\t\t\tResult is %d [%s]\n", number_of_temperature_features,
>>             sbapi_get_error_string(error));
>> 
>>     if(0 == number_of_temperature_features) {
>>         printf("\tNo temperature capabilities found.\n");
>>         return;
>>     }
>> 
>>     temperature_feature_ids =
>>         (long *)calloc(number_of_temperature_features, sizeof(long));
>>     printf("\t\tGetting temperature feature IDs...\n");
>>     number_of_temperature_features = sbapi_get_temperature_features(
>>             deviceID, &error, temperature_feature_ids,
>>             number_of_temperature_features);
>>     printf("\t\t\tResult is %d [%s]\n", number_of_temperature_features,
>>             sbapi_get_error_string(error));
>> 
>>     for(i = 0; i < number_of_temperature_features; i++) {
>>         printf("\t\t%d: Testing device 0x%02lX, temperatures 0x%02lX\n",
>>                 i, deviceID, temperature_feature_ids[i]);
>> 
>>         printf("\t\t\tAttempting to get temperatures...\n");
>>         memset(buffer, (int)0, sizeof(buffer));
>>         length = sbapi_temperature_get(deviceID,
>>             temperature_feature_ids[i], &error, buffer, 10);
>>         printf("\t\t\t\tResult is %d [%s]\n", length, sbapi_get_error_string(error));
>>         for(int t_index=0; t_index<length; t_index++) {
>>         if(0 == error && length > 0) {
>>             printf("\t\t\t\tTemperature(%d): %2.2f\n", t_index, buffer[t_index]);
>>         }
>> }
>>         printf("\t\t%d: Finished testing device 0x%02lX, temperatures 0x%02lX\n",
>>                 i, deviceID, temperature_feature_ids[i]);
>>     }
>>     free(temperature_feature_ids);
>> 
>>     printf("\tFinished testing temperature capabilities.\n");
>> }
>> 
>> 
>> -kirk-
>> 
>> 
>> 
>>> On Jan 25, 2015, at 16:24, Aaron Gage <ra...@gm... <mailto:ra...@gm...>> wrote:
>>> 
>>> Mark --
>>> 
>>> Yes, I'm willing (time permitting).  However, I don't know if I'll need test hardware.  Most of the changes I want to make are at the API layer, so as long as the protocol layer works, I can probably get pretty far without running on a real device.  It sounded like Kirk would be providing the protocol layer for the STS features and I should be able to just use that (and all of the existing TEC code) as a starting point.  The other devices can have those features filled in later (basically just plugging in features once a suitable protocol implementation exists).  If I were to get test hardware, I'm not sure which device(s) would be most appropriate, and I don't know what conditions there would be for that.  If I did the coding, would you be able to do the testing?
>>> 
>>> If you wanted this to extend to all devices, not just the STS (with Kirk's patch) and the devices that currently support the TEC, then it might help me to have a summary of how this was done in next-gen OmniDriver (which devices have TEC or standalone temperature sensor features, what the op-code and format in the protocol-layer exchanges were, and possibly whether the protocol implementation was firmware-version-dependent).  I don't entirely trust the datasheets to capture all of the nuances.
>>> 
>>> --Aaron
>>> 
>>> 
>>> On Sun, Jan 25, 2015 at 8:53 AM, Mark Zieg <mar...@oc... <mailto:mar...@oc...>> wrote:
>>> Hi Aaron,
>>> 
>>> I fully support everything you’ve described (and yes I’m familiar with the analogous changes to OmnIDriver), but I’m not able to resource it at this time.
>>> 
>>> Are you indicating willingness to make some of these changes yourself?  If so, can I provide test hardware?
>>> 
>>> I will say that Kirk is not the only customer interested in seeing temperature functions added to SeaBreeze.
>>> 
>>> Regards,
>>> 
>>> Mark
>>> 
>>>> On Jan 25, 2015, at 8:44 AM, Aaron Gage <ra...@gm... <mailto:ra...@gm...>> wrote:
>>>> 
>>>> Greetings Kirk --
>>>> 
>>>> It will be nice to have more of the STS functions brought out in SeaBreeze.  I think that you'll find that adding support for new commands in its protocol is straightforward.  Many commands for the STS will also work as-is for the QEPro which is nice.  I am a little curious as to how you are using the temperature with regards to checking whether a dark spectrum is valid, since the STS uniquely keeps its own baseline pretty flat over temperature, but your experience may indicate this is not enough.
>>>> 
>>>> That said, there are some changes I want to make to the SeaBreeze API relating to temperature.  I wanted to float this idea well ahead of any actual changes, so that (A) you would know these changes might be coming and (B) we can all discuss any change to the API that may have widespread effects on users.  I don't want to discourage you from contributing what you have, but I want to make sure you're aware that there may be architectural changes that affect it afterwards.
>>>> 
>>>> The STS has two temperature sensors: one in the microcontroller itself (which reads about 10-20C above ambient) and one on the detector board (which reads much closer to ambient).  Some other spectrometers have one (TEC on QE?) or the other (USB2000+?) or both (QEPro?).  I propose that the API should be designed as follows:
>>>> 
>>>> * New BoardTemperature interface with getBoardTemperatureCelsius() function
>>>> * New DetectorTemperature interface with getDetectorTemperatureCelsius() function
>>>> * Rename instances of ThermoElectricCooler to ThermoElectric or ThermoElectricController (since on some devices this can be used to heat above ambient).  This is a change to the API that might break existing code, so this might wait until a major version change.
>>>> * Refactor ThermoElectric class to derive from DetectorTemperature.  This would also break existing code (replacing readTECTemperature() with getDetectorTemperatureCelsius()).
>>>> * Separate getting the TEC setpoint and getting the actual TEC temperature into two functions.  The latter (getDetectorTemperatureCelsius()) would be inherited from DetectorTemperature, the former would be new.  There should be explicit support to read the setpoint out of at least the QEPro if not the older devices, and if all else fails, this can be cached (and maybe throw an exception/set the error code if read before being set the first time).
>>>> 
>>>> Mark -- I believe that the next-gen OmniDriver already takes this approach in case you want to see how it looks in practice.  I think that this would be cleaner than putting all of the temperature sensor capabilities into a single class, given the overlap with the TEC.  It may also be that the BoardTemperature and DetectorTemperature classes would derive from a single TemperatureSensor class, as long as we don't end up with confusion due to diagonal inheritance of interfaces.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Regards,
>>>> Aaron
>>>> 
>>>> 
>>>> On Sun, Jan 25, 2015 at 5:29 AM, Mark Zieg <mar...@oc... <mailto:mar...@oc...>> wrote:
>>>> Hi Kirk,
>>>> 
>>>> I’ve added you as a developer on the SeaBreeze project.  Your addition of the ability to read the STS PCB temperature sounds helpful, along with the missing free() in the test code.
>>>> 
>>>> Rather than you trying to keep your repository in sync with SourceForge, would you be willing to simply make your changes on a branch of the public SourceForge project?  I would ask you not to commit to trunk directly, but we could merge your changes after an informal review process.
>>>> 
>>>> Thanks,
>>>> 
>>>> Mark Zieg
>>>> 
>>>>> To: <mz...@us... <mailto:mz...@us...>>
>>>>> From: <cle...@us... <mailto:cle...@us...>>
>>>>> Reply-To: <cle...@us... <mailto:cle...@us...>>
>>>>> Subject: Working with SeaBreeze
>>>>> Cc: <cle...@us... <mailto:cle...@us...>>
>>>>> Date: January 25, 2015 at 3:54:51 AM EST
>>>>> 
>>>>> Mark,
>>>>> 
>>>>> I hope your holidays were good. I'm glancing out the window at the snow that fell yesterday, looking forward to my move to the USA when my wife gets her green card. In the mean time, I've been doing some work with a couple STS spectrometers.
>>>>> 
>>>>> I've had to do a bit of tinkering in SeaBreeze to work around the missing shutter in the STS. Namely, it's nice to have detector temperature to know if a Dark Reference is valid. I simply used the nonlinearity coefficient family as a template, created a Temperature family and did some cutting and pasting to provide a facility to read temperatures. If I have time, I'll put in an indexed get to fully support the STS USB command set for temperature.
>>>>> 
>>>>> I did a read only check out of the latest SeaBreeze (wouldn't you know it... y'all did work at the same time I did) and set up a local repository. Would you like a patch after I'm done modifying for my purposes? I thought I'd offer. It would be nice to have those changes included in future versions so I don't have to redo them to update.
>>>>> 
>>>>> Oh, I fixed the missing free() in the sts test code. There was an 'if' section with a malloc and no free. I guess that was what your comment referenced.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> -kirk-
>>>>> 
> 
> ********************************************************
> 
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. If you are not the addressee, any disclosure, reproduction,
> copying, distribution, or other dissemination or use of this communication is
> strictly prohibited. If you have received this transmission in
> error please notify the sender immediately and then delete this e-mail.
> E-mail transmission cannot be guaranteed to be secure or error free as
> information could be intercepted, corrupted lost, destroyed, arrive late or
> incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message which arise as a result of e-mail
> transmission. If verification is required please request a hard copy
> version.
> 
> ********************************************************
> 

Re: [Seabreeze-interest] SeaBreeze access

[Mark Z. <mar...@oc...>]

Hi all,

Great thread :-)

Adding sea...@li...<mailto:sea...@li...> to the distro for retention.

Thanks for diving in so quickly!

Regards,

Mark

On Jan 25, 2015, at 4:20 PM, Aaron Gage <ra...@gm...<mailto:ra...@gm...>> wrote:

Kirk --

That sounds good.  The protocol layer on up through the feature layer may already be the way we need it to be; it's just the API layer where I'm likely to rework things.  I can handle the details there -- don't worry about spending more time on it -- so feel free to push what you have to a branch when you're ready.  It may take me a little while to get my part done, but I do intend to do it.

If you work with the STS a bit you may find that the baseline does not drift.  While it isn't exactly electric dark correction at work, it locks in pretty well.  However, keeping the baseline appearing constant in effect pulls the saturation level down as the temperature rises.  The saturation value is always the same (16383) but you may find things jumping there before you'd expect them to in case this compensation has had to pull it too far.  If you didn't already know this, there is a way to read out the raw spectrum (without this compensation) which should be used when adjusting the integration time against a reference light level.  This ensures that you have some margin on the dynamic range, regardless of what the temperature was at the time.  I haven't checked to see if SeaBreeze supports the raw spectrum for the STS, but if it does not, I think it is something we should add.  It's certainly recommended for experiments that may occur with wide temperature variations for that particular device.

Regards,
Aaron

On Sun, Jan 25, 2015 at 3:32 PM, Kirk Clendinning <ki...@cl...<mailto:ki...@cl...>> wrote:

Here’s the test code results. It works the same as the nonlinearity test.

Testing temperature features:
Getting number of temperature features:
Result is 1 [Success]
Getting temperature feature IDs...
Result is 1 [Success]
0: Testing device 0x02, temperatures 0xE0000
Attempting to get temperatures...
Result is 3 [Success]
Temperature(0): 22.18
Temperature(1): -34.04
Temperature(2): 38.34
0: Finished testing device 0x02, temperatures 0xE0000
Finished testing temperature capabilities.


void test_temperature_feature(long deviceID) {
    int error = 0;
    int number_of_temperature_features;
    long *temperature_feature_ids = 0;
    double buffer[10];  // how many temperatures could there be on _any_ given spectrometer
    int i;
    int length;

    printf("\n\tTesting temperature features:\n");

    printf("\t\tGetting number of temperature features:\n");
    number_of_temperature_features =
        sbapi_get_number_of_temperature_features(deviceID, &error);
    printf("\t\t\tResult is %d [%s]\n", number_of_temperature_features,
            sbapi_get_error_string(error));

    if(0 == number_of_temperature_features) {
        printf("\tNo temperature capabilities found.\n");
        return;
    }

    temperature_feature_ids =
        (long *)calloc(number_of_temperature_features, sizeof(long));
    printf("\t\tGetting temperature feature IDs...\n");
    number_of_temperature_features = sbapi_get_temperature_features(
            deviceID, &error, temperature_feature_ids,
            number_of_temperature_features);
    printf("\t\t\tResult is %d [%s]\n", number_of_temperature_features,
            sbapi_get_error_string(error));

    for(i = 0; i < number_of_temperature_features; i++) {
        printf("\t\t%d: Testing device 0x%02lX, temperatures 0x%02lX\n",
                i, deviceID, temperature_feature_ids[i]);

        printf("\t\t\tAttempting to get temperatures...\n");
        memset(buffer, (int)0, sizeof(buffer));
        length = sbapi_temperature_get(deviceID,
            temperature_feature_ids[i], &error, buffer, 10);
        printf("\t\t\t\tResult is %d [%s]\n", length, sbapi_get_error_string(error));
        for(int t_index=0; t_index<length; t_index++) {
        if(0 == error && length > 0) {
            printf("\t\t\t\tTemperature(%d): %2.2f\n", t_index, buffer[t_index]);
        }
}
        printf("\t\t%d: Finished testing device 0x%02lX, temperatures 0x%02lX\n",
                i, deviceID, temperature_feature_ids[i]);
    }
    free(temperature_feature_ids);

    printf("\tFinished testing temperature capabilities.\n");
}


-kirk-



On Jan 25, 2015, at 16:24, Aaron Gage <ra...@gm...<mailto:ra...@gm...>> wrote:

Mark --

Yes, I'm willing (time permitting).  However, I don't know if I'll need test hardware.  Most of the changes I want to make are at the API layer, so as long as the protocol layer works, I can probably get pretty far without running on a real device.  It sounded like Kirk would be providing the protocol layer for the STS features and I should be able to just use that (and all of the existing TEC code) as a starting point.  The other devices can have those features filled in later (basically just plugging in features once a suitable protocol implementation exists).  If I were to get test hardware, I'm not sure which device(s) would be most appropriate, and I don't know what conditions there would be for that.  If I did the coding, would you be able to do the testing?

If you wanted this to extend to all devices, not just the STS (with Kirk's patch) and the devices that currently support the TEC, then it might help me to have a summary of how this was done in next-gen OmniDriver (which devices have TEC or standalone temperature sensor features, what the op-code and format in the protocol-layer exchanges were, and possibly whether the protocol implementation was firmware-version-dependent).  I don't entirely trust the datasheets to capture all of the nuances.

--Aaron


On Sun, Jan 25, 2015 at 8:53 AM, Mark Zieg <mar...@oc...<mailto:mar...@oc...>> wrote:
Hi Aaron,

I fully support everything you’ve described (and yes I’m familiar with the analogous changes to OmnIDriver), but I’m not able to resource it at this time.

Are you indicating willingness to make some of these changes yourself?  If so, can I provide test hardware?

I will say that Kirk is not the only customer interested in seeing temperature functions added to SeaBreeze.

Regards,

Mark

On Jan 25, 2015, at 8:44 AM, Aaron Gage <ra...@gm...<mailto:ra...@gm...>> wrote:

Greetings Kirk --

It will be nice to have more of the STS functions brought out in SeaBreeze.  I think that you'll find that adding support for new commands in its protocol is straightforward.  Many commands for the STS will also work as-is for the QEPro which is nice.  I am a little curious as to how you are using the temperature with regards to checking whether a dark spectrum is valid, since the STS uniquely keeps its own baseline pretty flat over temperature, but your experience may indicate this is not enough.

That said, there are some changes I want to make to the SeaBreeze API relating to temperature.  I wanted to float this idea well ahead of any actual changes, so that (A) you would know these changes might be coming and (B) we can all discuss any change to the API that may have widespread effects on users.  I don't want to discourage you from contributing what you have, but I want to make sure you're aware that there may be architectural changes that affect it afterwards.

The STS has two temperature sensors: one in the microcontroller itself (which reads about 10-20C above ambient) and one on the detector board (which reads much closer to ambient).  Some other spectrometers have one (TEC on QE?) or the other (USB2000+?) or both (QEPro?).  I propose that the API should be designed as follows:

* New BoardTemperature interface with getBoardTemperatureCelsius() function
* New DetectorTemperature interface with getDetectorTemperatureCelsius() function
* Rename instances of ThermoElectricCooler to ThermoElectric or ThermoElectricController (since on some devices this can be used to heat above ambient).  This is a change to the API that might break existing code, so this might wait until a major version change.
* Refactor ThermoElectric class to derive from DetectorTemperature.  This would also break existing code (replacing readTECTemperature() with getDetectorTemperatureCelsius()).
* Separate getting the TEC setpoint and getting the actual TEC temperature into two functions.  The latter (getDetectorTemperatureCelsius()) would be inherited from DetectorTemperature, the former would be new.  There should be explicit support to read the setpoint out of at least the QEPro if not the older devices, and if all else fails, this can be cached (and maybe throw an exception/set the error code if read before being set the first time).

Mark -- I believe that the next-gen OmniDriver already takes this approach in case you want to see how it looks in practice.  I think that this would be cleaner than putting all of the temperature sensor capabilities into a single class, given the overlap with the TEC.  It may also be that the BoardTemperature and DetectorTemperature classes would derive from a single TemperatureSensor class, as long as we don't end up with confusion due to diagonal inheritance of interfaces.

Thoughts?

Regards,
Aaron


On Sun, Jan 25, 2015 at 5:29 AM, Mark Zieg <mar...@oc...<mailto:mar...@oc...>> wrote:
Hi Kirk,

I’ve added you as a developer on the SeaBreeze project.  Your addition of the ability to read the STS PCB temperature sounds helpful, along with the missing free() in the test code.

Rather than you trying to keep your repository in sync with SourceForge, would you be willing to simply make your changes on a branch of the public SourceForge project?  I would ask you not to commit to trunk directly, but we could merge your changes after an informal review process.

Thanks,

Mark Zieg

To: <mz...@us...<mailto:mz...@us...>>
From: <cle...@us...<mailto:cle...@us...>>
Reply-To: <cle...@us...<mailto:cle...@us...>>
Subject: Working with SeaBreeze
Cc: <cle...@us...<mailto:cle...@us...>>
Date: January 25, 2015 at 3:54:51 AM EST


Mark,

I hope your holidays were good. I'm glancing out the window at the snow that fell yesterday, looking forward to my move to the USA when my wife gets her green card. In the mean time, I've been doing some work with a couple STS spectrometers.

I've had to do a bit of tinkering in SeaBreeze to work around the missing shutter in the STS. Namely, it's nice to have detector temperature to know if a Dark Reference is valid. I simply used the nonlinearity coefficient family as a template, created a Temperature family and did some cutting and pasting to provide a facility to read temperatures. If I have time, I'll put in an indexed get to fully support the STS USB command set for temperature.

I did a read only check out of the latest SeaBreeze (wouldn't you know it... y'all did work at the same time I did) and set up a local repository. Would you like a patch after I'm done modifying for my purposes? I thought I'd offer. It would be nice to have those changes included in future versions so I don't have to redo them to update.

Oh, I fixed the missing free() in the sts test code. There was an 'if' section with a malloc and no free. I guess that was what your comment referenced.

Regards,

-kirk-

********************************************************

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this communication is
strictly prohibited. If you have received this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
version.

********************************************************