Phidgets Forums

I am starting to update from phidgets 2.1.8 to the current phidget22. In many places I see that things look the same (just name differences). In other places, I don't find things in phidget22. For example, with the single probe temperature gauge, there used to be functions like:

• CPhidgetTemperatureSensor_getTemperatureInputCount
  CPhidgetTemperatureSensor_getPotentialMax
  CPhidgetTemperatureSensor_getPotentialMin
  CPhidgetTemperatureSensor_getAmbientTemperatureMax
  CPhidgetTemperatureSensor_getAmbientTemperatureMin

and so on. I do not recognize the new functions, if they exist. Also, there were some information functions that I no longer see. For example:

• CPhidget_getDeviceType

I did see one document that told a bit about the changes in phidget22. But I did not see where it discussed these kinds of changes.

Is there information on this sort of thing?

I have a humidity gauge as well. I don't know what changes I may encounter there.

Programming in C on Linux. One reason I am updating from phidget21 is that I can't seem to get phidget21 to work in a 64-bit OS. The open call fails. So I thought this is a good time to update to phidget22.

The main differences that occurred in Phidget 22 are:
* Objects that used to represent multiple channels (i.e an "InterfaceKit" object) are now broken up into separate objects, where each object represents one channel.
* In some cases, this also extends even further; a single channel might have multiple options of what kind of object to open it as. For example, an analog input on a 1018 can be opened as a VoltageRatioInput or VoltageInput depending on how you want to use it.

As you mentioned, there is an "Upgrading from Phidget21 to Phidget22" page, and the new API documentation can also help find the new naming and structure. There's also a list of channels for each device in the "API" tab on that devices' product page.

I'll run through each of the functions you mentioned:

CPhidgetTemperatureSensor_getTemperatureInputCount
This function no longer exists because the TemperatureSensor object which used to have multiple TemperatureInputs is now simply broken into a number of TemperatureSensor objects. So a 1048 now has four TemperatureSensor objects that refer to its thermocouple inputs and one TemperatureSensor object that refers to the temperature of the board (for temperature error correction). If you want to find out how many channels a Phidget has, you can use the Phidget Manager class to launch an event whenever a channel is attached. By comparing their device serial numbers, you can tell if they all belong to the same board or not.

CPhidgetTemperatureSensor_getPotentialMax
CPhidgetTemperatureSensor_getPotentialMin
"Potential" is a property that described the electrical signal (in volts) from an attached thermocouple. If you want this number, you should open the channel as a VoltageInput instead of a TemperatureSensor, and use the "getVoltage" or the Voltage change event.

CPhidgetTemperatureSensor_getAmbientTemperatureMax
CPhidgetTemperatureSensor_getAmbientTemperatureMin
Boards with ambient temperature chips on them have their own TemperatureSensor object now. This can be confusing for products like the 1048 which have their own TemperatureSensor objects already. If you go to the API tab on the product's page, you can see a list of which channel numbers refer to which objects. In the case of the 1048, TemperatureSensors 0,1,2, and 3 are the thermocouple inputs, and 4 is the ambient temperature sensor.

CPhidget_getDeviceType
DeviceType no longer exists because devices like "InterfaceKit" have been broken up into channels instead. So when plugging in a 1048 in Phidget21, you'll see a single PhidgetTemperatureSensor 4-input device connect, but in Phidget22 you'll simply see 5 TemperatureSensor objects and 4 VoltageInput objects attach. If you open up a channel, you can determine information like the channel's class, or the name of the device it belongs to with getChannelClass and getDeviceName respectively.

I doubt you'll have as much trouble with the humidity sensor, it just happens that the 1048 is the most confusing because of it's multiple types of TemperatureSensor channels.

Thanks for that info. I have the temperature gauge sorted. My gauge is the 1051. So there is just the thermocouple and the board. I am guessing the board is what used to be called ambient temperature.

The 'easier' humidity gauge is not as obvious to me. I have it connected via the 1019 Interface Kit. It is connected to analog input connector 7. I am calling:

PhidgetHumiditySensor_create PhidgetHumiditySensor_setOnHumidityChangeHandler
Phidget_setOnAttachHandler
Phidget_setOnDetachHandler
Phidget_setOnErrorHandler
Phidget_setChannel
Phidget_openWaitForAttachment

None of my handlers are called. The Phidget_openWaitForAttachment does not return an error.

Unlike the temperature gauge, calls to Phidget_getDeviceSerialNumber and Phidget_getDeviceVersion do not return expected values. I would expect the Interface Kit serial number to be returned.

Is Phidget_setChannel how I tell it which analog connector the sensor is connected to? The C example for the Humidity sensor does not, as far as I can see, tell which connector the humidity gauge is connected to. I think it needs a bit of fleshing out...

After a change to the code, I see that the open does fail. It does the same for the sample HumiditySensor_Example C program. That program reports:

INFO [_phidget22usb][2017-09-26T10:45:07]:Initializing libusb
INFO [_phidget22usb][2017-09-26T10:45:07]:New Phidget found in PhidgetUSBBuildList: 2/10
INFO [_phidget22usb][2017-09-26T10:45:07]:New Phidget found in PhidgetUSBBuildList: 2/9
INFO [_phidget22usb][2017-09-26T10:45:07]:New Phidget found in PhidgetUSBBuildList: 2/8
Channel did not attach after 5 seconds: please check that the device is attached

The device is detected by the USB sub-system as I report these as they are detected (a udev rule). The device, like the functioning temperature gauge, has access permissions that should allow this user to access the device.

The three items in the PhidgetUSBBuildList are most likely the three that I have connected (1019, 1043, 1051). I expect to be accessing 1019.

Seems I got off on the wrong foot with the humidity sensor. Ignore my two previous posts. I am using one of these: https://www.phidgets.com/?tier=3&prodid=222

So, I should use the VoltageInput class. I have now done this via:

PhidgetVoltageInput_create
PhidgetVoltageInput_setOnVoltageChangeHandler
PhidgetVoltageInput_setSensorType(, SENSOR_TYPE_VOLTAGE);
Phidget_setChannel((_PhidgetHandle) instance->humiditySensor, 6);
PhidgetVoltageInput_setVoltageChangeTrigger(, 0.2);

On the log, I see:

PhidgetVoltageInput_setSensorType()]: PhidgetVoltageInput is not attached

I get this no matter what channel I use in PhidgetVoltageInput_setSensorType.

You can't set the sensor type until the channel has been opened. The only properties that you can set before calling open are the ones that help narrow down which channel it is you're trying to open (such as DeviceSerialNumber, isRemote, Channel, etc).

Also, can use SENSOR_TYPE_3130 as the sensor type if you want to get the value back in %RH instead of volts.

CPhidget_getDeviceType is called Phidget_getDeviceClassName in phidget22

-Patrick

mparadis wrote:Also, can use SENSOR_TYPE_3130 as the sensor type if you want to get the value back in %RH instead of volts.

I have set it to this, but I always get the same value in the change handler: 0.291900. The value should be between 5 and 95 with this sensor. And if setting the type should result in a report of %RH, something seems odd.

It does not change at all when I do things like wrap the sensor in a moist towel. It should.

I have been suspicious of how to select the analog port to which the sensor is connected. The InterfaceKit has 8 analog ports numbered 0 to 7 on the board. The sensor is attached to the one labeled 7. I have used Phidget_setChannel(id, 7) to specify this. In fact, I have tried various numbers. But I get the same value. Which is mysterious. I set this value after the open, as that is how it appears to be done in the sample programs.

Do you still get the 0.29% value when you try to read the sensor using the Phidget Control Panel? This will narrow down whether it's a problem with the sensor or the code in your program.

I'm doing this on Linux. So, unfortunately, no control panel. There could be if it had been written in a portable GUI. But there you have it. Having a second opinion would be great so I could eliminate hardware failure.