Making continuity (as well as sensing continuity)

[joelmaxuel]

Hi,

A while back I was gifted a couple InterfaceKits - an 8/8/8 and a 0/16/16 - the older models as they connect by standard USB B.

I apparently had some weird assumptions about the digital inputs and outputs. I am looking to (input side) check the state of a switch to see if it is open or closed (continuity). I would have code (to be written) that once that state is seen, do things including close a different circuit (make continuity) momentarily.

The example above can be simplified by a doorbell - there is a switch outdoors. When that is pressed, I want (in part) the former switch to activate.

Was a bit surprised about the continual 230 Ohm resistance the outputs provide. How can I salvage this project? Keep in mind what I wanted of the outputs is to momentarily close a connection (currently five of these, independent of each other) of circuits typically powered by CR2032's.

[mparadis]

The first thing to make note of is that the digital inputs and outputs on your 8/8/8 behave differently than the ones on your 0/16/16.

The digital inputs on the 8/8/8 are active low, meaning they will be "true" when tied to a low voltage (usually ground). On the 0/16/16, they're active high (true at 5V).

The digital outputs on the 8/8/8 are simple DC outputs: false is 0V and true is 5V. The outputs on the 0/16/16 are Open collector, or as I like to call them, "switch-to-ground" outputs. They are an open circuit when false, and are connected to the ground on the 0/16/16 when true. This makes them useful for bridging the low side of a simple DC circuit.

So in your doorbell example, the button should work with either input. If the doorbell has two wires, connect one to the ground on your 8/8/8 and one to an input. For the 0/16/16, connect one to the 5V terminal and the other to an input.

For the bell or whatever the other switch is connected to, if it's powered by 5V DC you can connect it directly to a 8/8/8 output. If it's more than that, the 0/16/16 output can be used to switch the low side of the circuit with the existing power supply.

If this isn't clear, you can draw a diagram of what wires are in your system and we can reply with a diagram of how to hook it up.

[joelmaxuel]

By the sounds of the reply, I would be better off placing my outputs on the 0/16/16.

The devices power themselves (just needed a Phidget to close the switches I had since desoldered and broken out to leads) - one is powered by 5V, that doorbell in question was powered by a tiny 12V battery.

So that 5V switch series seems straight-forward to move to the 0/16/16 and does not seem to be any issue there (upon activating it's power source earlier with the 8/8/8, all the switches were activated even with the host machine powered off). With the actual 12V doorbell, sounds like I will require something between those doorbell leads and the 0/16/16 (to protect that Phidget).

[mparadis]

The digital outputs on the 0/16/16 are capable of switching circuits of up to 30V, so I don't see any problems switching 12V to the doorbell. Just connect the positive wire of the 12V to the positive terminal of the doorbell, connect the negative wire of the doorbell to one of the 0/16/16 outputs, and connect the negative wire of the 12V to the ground of the 0/16/16.

[joelmaxuel]

I moved the leads. Doorbell is theoretically fine. However the other device (an old key fob) is still sending signals on power delivery (not yet known if it is a momentary on power delivery or if the switches are closed for the duration).

I attached a (blurry, unfortunately) photo of the fob, and of where the other end connects to the interface kit. The white wire is soldered to the fob that makes a common side for all four former button faces. Then blue, green, orange and brown populate the other side of each button face. On the kit, I used 3, 4, G, 5, 6 with the white wire in the middle.

To avoid any confusion, I disconnected the G, 7 pair (output to doorbell transmitter) and applied power to the fob again, no change. I also (in case there may have been a short that developed on the fob) disconnected the white wire from the Kit, and applied the 5V again (this time, silence from the other end). I added the white wire back to Gnd again, and have returned to the same problem. Also (to clarify), given the behaviour of the fob, with all wires attached and power applied, the noticed response is from the button corresponding with slot 6. Disconnect that wire, reapply, and then the response would be the correspond from slot 5 (and so on).

Measuring between 4 and G, I see a resistance of approx 100K. FWIW, the lines for 0, 1 and 2 to their own Gnd does not detect any resistance as of now (they are currently lines that leave the project box; do not connect to anything otherwise).

Not sure what I could try next.

[joelmaxuel]

Okay, I have finally mocked something up in C to test the behaviour. Unfortunately, the results are inconclusive.

The program (less some repeating stuff):

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include "phidget22.h"

int main(int argc, char *argv[]) {
	PhidgetReturnCode res;
	const char *errorString;
	PhidgetDigitalOutputHandle ch;
	Phidget_DeviceID deviceID;
	int state;
	double dutyCycle;
	double minDutyCycle;
	double maxDutyCycle;

	PhidgetDigitalOutput_create(&ch);

	printf("Query based on Serial %d ...\n", atoi(argv[1]));
	res = Phidget_setDeviceSerialNumber((PhidgetHandle)ch, atoi(argv[1]));
	printf("Query based on Channel %d ...\n", atoi(argv[2]));
	res = Phidget_setChannel((PhidgetHandle)ch, atoi(argv[2]));
	printf("Open and Attach ...\n");
	res = Phidget_openWaitForAttachment((PhidgetHandle)ch, 5000);
	printf("Query for State ...\n");

// Show state and duty info...
	res = PhidgetDigitalOutput_getState(ch, &state);
	PhidgetDigitalOutput_getDutyCycle(ch, &dutyCycle);
	PhidgetDigitalOutput_getMinDutyCycle(ch, &minDutyCycle);
	PhidgetDigitalOutput_getMaxDutyCycle(ch, &maxDutyCycle);
	printf("State: %d \n", state);
	printf("Duty Cycle Value/Min/Max: %4.2f/%4.2f/%4.2f \n", dutyCycle, minDutyCycle, maxDutyCycle);

	PhidgetDigitalOutput_setState(ch, 1); // Or setDutyCycle ... didn't seem to matter

// Repeat state and duty info

	res = usleep(2500000); // Am aware of the warning this causes

// Repeat state and duty info

	PhidgetDigitalOutput_setDutyCycle(ch, 0); // Or setState ... didn't seem to matter

// Repeat state and duty info

	PhidgetDigitalOutput_delete(&ch);

	return 0;
}

This results in an output of (generally - the 0/16/16 has a serial of 72253 and the current slots used are 3, 4, 5, 6, and 15):

Code: Select all

joel@phinet:~/Build $ sudo ./example 72253 3
Query based on Serial 72253 ...
Query based on Channel 3 ...
Open and Attach ...
Query for State ...
State: 0 
Message: Success (0x00)
Message: Success (0x00)
Message: Success (0x00)
Duty Cycle Value/Min/Max: 0.00/0.00/1.00 
Message: Success (0x00)
Message: Success (0x00)
Message: Success (0x00)
Message: Success (0x00)
State: 1 
Duty Cycle Value/Min/Max: 1.00/0.00/1.00 
Message: Success (0x00)
Message: Success (0x00)
Message: Success (0x00)
Message: Success (0x00)
State: 1 
Duty Cycle Value/Min/Max: 1.00/0.00/1.00 
Message: Success (0x00)
Message: Success (0x00)
Message: Success (0x00)
Message: Success (0x00)
Message: Success (0x00)
State: 0 
Duty Cycle Value/Min/Max: 0.00/0.00/1.00 
joel@phinet:~/Build $

This output is rather intended, since for when the states are checked, the values are high for when they are set high (0, 1, 1, 0).

However this seems to be the case only half the time. A third of the time, the output looks more like the high state is lost before sleep (0, 1, 0, 0), and the remaining sixth leaves the high state on after the set low (0, 1, 1, 1) - granted that value has yet to result in being set high when the program relaunches.

This does not seem to affect the ports I choose in the second parameter (aside from attach timeouts if I am not between 0 and 15, understandably). The most important note of all this however is that setting the state high momentarily for a port used by one of the fobs does not affect them. It makes me wonder if the fobs are seeing the circuits as closed regardless of what the state/dutycycle is set to.

Is this a useful addition to the issue?

EDIT: Ugh, by looking over https://www.phidgets.com/docs/Open_Coll ... put_Primer I may have realized my issue. For example with the output to doorbell (that fob is a HeathZenith SL-7393 or similar), it is independently powered by 12VDC with the former momentary switch (both sides) to the 0/16/16. The other fob operates with the same principle. Because they are independently powered, I should really check for continuity between the fob ground and each side of that switch (my previous assumption is that one side already does this). If there is none on either side, I will (likely) need to connect the DigitalOutput ground with the fob ground.

[joelmaxuel]

Based on the last edit ... my first premise was correct, but it did not help.

Since it was asked long ago to set up a wiring diagram, the `phidget-fob1-wiring.png` file (attached) is where I am now. The only functional difference is that I have the common wire (fob) also connecting to the -6v power source (fob) on top of the previously-connected GND post(s) (phidget).

FWIW, the other differences between this and the previous photo is that I shifted the leads down (now 4/5/6/7 instead of the previous 3/4/5/6) so that I can properly use two GND posts (previous photo only properly associated GND with posts 4 and 5).

Also added the doorbell fob (12v) photo as I had to disconnect it anyway. At some point continuity mode was very emphatic to both sides of the switch being closed (audible continuity result), until I disconnected it for further testing. Powering it standalone and closing the leads manually now produces no result (unsure of the cause - granted this transmitter was outdoors for a significant time until it stopped working back then - before I started soldering leads, I did have to clean up the PCB to make it functional again so it may be related to degradation instead of something else).