The rest of the code does similar initialization code, including some of the USB hub status (0xFFF05050).

If we check the output of the camera exec we can correlate some of that output with where we are above.

We reset our gpio port1,4, at this point usually the unit makes a click sound.It then spits out no support (after some checks I need to throw into something like IDA, as I'm not working out what its pointing at from the BIC and other bits), then resets the USB.

Though, it rather looks like from a hardware point of view that the GPIO we've identified is going to turn out to be for something else.

If we look at the board, we have JP5 (labelled Left), JP8 which connects to our stepper motor, and lest we not forget, the alarm ports in green at the back.

If we take a look at the connection for JP5, we see an arm and 3 wires, so this is more likely to be a position sensor for our left/right.I'll bet this is tied into port 4 (which is 1 i/o, and probably does our where is the camera rotated to right now).

I'll have to make a quick program to read those values from Port4 and then play with that arm and see what happens.

Our other gpio also doesn't feel like its running the PTZ either, its probably tied into the green i/o at the back.

I'm pretty much done with what I need to find out for everything else, this was really the last piece.

I have my own custom kernel with drivers running, I have the necessary bits and bobs to grab video etc already running.Next up is integration, and as you keep pushing me on it, motion detection.

I also want to look at a packaging system - eg opkg.

I spoke today at length to someone at Maygion and had a chat about what I'm doing etc, they're doing the motion sensing manually also; they also don't have a datasheet for the camera. Their code runs slower than real time, which is what I was thinking might happen given cpu and other limits (small cache size, floating point etc)

If someone wants to work on a simple algorithm for that, wouldn't be a bad idea. I think my proposed method is probably the fastest. Its either that, or base off the luminance changes in an image.

To turn a stepper motor, we need to pulse our 4 pins connected to the stepper motor in serieseg

Stepper Motor Wire1 2 3 4On Off Off OffOff On Off OffOff Off On OffOff Off Off On

So, which pins are we using on the ULN2803 Chip?

According to my trusty multimeter on the stepper motorPin1 is 5vPin2 is connected to pin 14 (out 5)pin3 is connected to pin 13 (out 6)pin4 is connected to pin 12 (out 7)pin5 is connected to pin 11 (out

So, our inputs are on 5,6,7,8 on the ULN2803, but what drives those pins?

Hi,may I remid you of one important fact in the "addressable latch mode"?

it outputs the state of data input (D, pin13) on the addressed output.

So to be able to output H and L you have to be able to change pin 13.

at the moment you are asuming it is fixed to H, since you only give examples for pulling output high.How exactly are you going to set them to L?

your example is more like 3-8 decoder mode since it will only drive exactly the adressed pin to H if pin13=H, seting all others to L (forever inhibiting halfstep mode). This would be the worst example of engineering but wouldn't surprise me, having seen lots of chinatech.

I hope that at least pin13 (data) is connected to a gpio too, more favourably pin14 (latch) also, to enable changing of the states without having "glitches" on the outputs.

if the second motor is on the other half of the '259 outputs, this design wouldn't allow for h and v movement at the same time (or only with very complex logic), because you can't have power to two coils at the same time....

schufti

P.S.: on my cam, pin14'259 (LE) has a cap to vcc and resistor to gnd, what I would expect at the reset pin...the reset pin seems to be floating and looks like it has originaly been connected to gnd and only the film has been corrected. So somehow it looks like someone during design miexd up the pins....

so it could be that we are operating in addressable latch instead of demux mode. This shouldn't make any difference for the simple code above, but may make it easier to operate both motors at the same time.

changosurf

February 14, 2012, 08:09:24 pm

any progress on this yet???

Logged

Guest

changosurf

February 26, 2012, 06:47:39 pm

bump...did anyone manage to get a test program going to try getting the GPI/Pan-tilt motors to work?if not, can someone at least provide some (pseudo) code or some tips on how to go about coding something? please help, thanks...

changosurf

March 07, 2012, 08:37:34 pm

uhhh huh???

Ive gone over the posts in this thread a bunch of times, and I still cant figure out exactly what needs to be done... I see the example where gpio pins 7-10 are pulled high&low in sequence, but this doesnt explain clearly how to control a single motor (or both), or how to change the direction the motor is spinning.

Also, I struggled to get the gpio lib loaded into my 3.1 kernel. I managed to get it to load through /sys/class/gpio interface (built sysfs support into my kernel), but the examples above seem to use some other (older?) method to interface the gpio pins.

can you please help by elaborating on what should be done in order to get this to work?thanks