Re: Vernier CO2 sensor support

[Scott Cytacki]

Hmm. I'll try to write more later. But quickly.

The CO2 sensor had an issue before with power. The old version required too much power to run from usb power alone so it didn't work with the golink. The newer version was supposed to fix that.

You might not be able to use the old one unless the labquest is plugged into the wall. We looked for the wall blob for the labquest adam sent but couldn't find it. You can probably pick up some cheap thing a electronics store that will work.

The sensor id's you are looking at in our code are the Vernier specific ones right, not the geneirc abstracted ids.  They should match up pretty well with the files. I do remember a few differences, but I'd expect there to be notes about them in the code somewhere. If I remember right there are actually a few duplicates in the xml file.

I thought the GoIO dylib already supported 64bit, it was working for me on a 10.7 with Java 1.7 running in 64bit mode.

A useful thing to do is to download vernier's loggerlite and test things out in there so you can see if it is our software or a hardware problem.

On Thu, Nov 15, 2012 at 4:19 PM, Aaron Unger <aun...@concord.org> wrote:

Hi Scott-

I was trying to test the sensor applet with the CO2 sensor, to make sure it was working since that was one of the sensors that InquirySpace was specifically interested in supporting. It's not going so well.

I was sent 2 different CO2 sensors.
One is this (I'll call this the newer style): http://www.vernier.com/products/sensors/co2-bta/
One has that same part code, but looks like this (I'll call this the older style): https://github.com/concord-consortium/vernier-sensor-map/blob/master/Sensor%20Images/sensor_CO2.bmp?raw=true

The newer one works with the LabQuest. It reports sensor id of 75 or 76, depending if the toggle switch is in low or high mode respectively.

The newer one does not work with the GoLink, however. When open() gets called on the GoLink, it throws a RuntimeException complaining that the device can't be opened (GoIOSensor.java, line 47). The online product page for it implies that GoLink is supported.

The old one isn't working either place. On the LabQuest, it reports a sensor-id of 14, which in our code (and also according to the xml maps that Stephen just posted) corresponds to a Raw Voltage device. At that point, the config doesn't match the request, so it won't collect data from it.

On the GoLink, it reports as id 11, which is mapped to TEMPERATURE_F in our code (and is explicitly unsupported in the code), and id 11 isn't even a device according to those xml maps. Same problem with the config not matching the request.

So... what's the story on the CO2 sensors? What should I worry about trying to support, and what should I just punt on?

Looking into this, I also encountered a couple of other things:
 - Some of our low-level (< 20) sensor ids don't match up with what's in the xml file Stephen posted. Do we want to try to get updated versions of those maps and update our code to match?
 - There's an updated GoIO dll/dylib that supports 64-bit. Any interest in updating? I didn't see any mention of supporting the newer CO2 sensor, unfortunately...

-- Aaron

--

Scott Cytacki

The Concord Consortium

http://concord.org

[Scott Cytacki]

This page had some useful info:
http://www.vernier.com/til/1664/
Perhaps you are experiencing one of those problems.

--
excuse my brevity, this is from my phone

[Aaron Unger]

[Aaron Unger]

Ok, so I downloaded Logger Lite onto my Mac (10.6.8) and the only sensor that the GoLink seems to work with is the surface/fast response temp sensor. None of the other sensor work with this GoLink.

I'm plugging it straight into the Mac, so it shouldn't be a hub/power issue. And if Logger Lite isn't seeing the sensors, then it's probably something with this GoLink and not something I can fix. So I think I'll just punt on GoLink testing, unless you've got another thing I can try...

I'll see if I can round up a wall power adapter for the LabQuest and see if that makes the old-style CO2 sensor work.

And for the other topics:
  - The IDs I was looking at were the ones in the sensor-vernier project, org/concord/sensor/vernier/SensorID.java. The comments next to the IDs are a bit cryptic.

  - The 64-bit comment just stemmed from the SDK's readme -- the version checked into the goio-jna project implies version 2.28. The latest is 2.41 and it includes these notes, which made me wonder if 64-bit was supported:

Version 2.39
GoIO_DLL sources generally use int instead of long internally so that code behaves similarly for 32 and 64 bit builds.
Released 64 bit version of GoIO DLL library for the Mac.

Version 2.37
Add sensor map data for non smart sensors so DDS records are descriptive for all known sensors.
GoIO_Sensor_CalibrateData() supports non linear calibrations now, so stainless steel temperature is supported.
The Windows version of GoIO DLL can be built as a 64 bit binary.

-- Aaron

[Scott Cytacki]

Regarding the GoIO versions. I'm guessing the version of the native library we have in the project was built by Stephen, I think he was the one that original added 64bit support. So in other words the version of the built file didn't match the documentation.

Regarding the IDs, yes the comments are not very clear. The original 0-18 ids came from an original GoIO sdk. Based on what you saw in the xml files, I'd guess they have repurposed some of these ids. The best solution would be to have the code start using the xml file. This way we could simplify the big switch in VernierSensor.java so it is just a mapping of one id to another and the rest of the properties are filled in from the xml file. If we find using the xml file is slow, then we could generating java code from it, so it ends up being just another class file.

That is strange about the GoLink It does sound like it is bad. Have you tried it on windows? Or tried it with a powered hub? Perhaps your mac is the problem.