Replacing existing pic

[Freman]

G'day there.

I'm sure what I have is a very simple problem, but I'm having a bit of trouble working out the back side to it.

Back story - I'm upgrading my home theater (if it can be called that) to be operated from a single remote through my media PC. I've already gotten most of the other stuff working (with help from here with the comparator stuff I was having problems with before)

I've pulled apart the receiver/controller for my motorized projection screen. Imagin my delight to see it's driven by a PIC chip - unfortunatly the chip that's existing has code protect so I can't just reverse engineer the chip and add my new feature (a 1 wire serial port). I'm forced to try and replicate the code.

I've got a fair understanding of most of it, but the input buttons have me lost.

Attached is a very very basic overview of the circuit that my new pic has to slot into.

How on earth can I tell what button is pushed?

Things I know.

Pin 6 to Pin 7 is 4.7v (it varies a little), pin 6 to gnd is 0.2v (it also varies a little) Pin 7 to gnd is 5v

Can you think of any way they might have been reading the 3 buttons in the original circuit?

Ideally I'd love keep the original RF remote working as well, but as I have no idea what signals it's using (And don't have a scope) I don't know how I can do that

[falingtrea]

If a pin varies a little, it may be changing state faster than the device you are trying to measure it with. I would think the code is doing something with the weak pull-ups on the pins. Fiddling with the weak pull-ups would allow the chip to scan the buttons, and the code may even use the ADC to read pin levels.

[mister_e]

Sure enough they use internal pull-ups. Make sure you disable the ADCs and comparators before.

Now how to know which push button.. Are you sure of the current schematic? Any way it miss some resistors and/or diode in that?

[Freman]

I'm positive there's no missed resistors or diodes in relation to the push buttons - as much as it's a very abbreviated schematic, the circuit really doesn't have much more - I can upload some scans of the board if you like, but I've actually decided to approach this a different way.

Originally I was going to sacrafice the remote control function to gain a serial interface, but what I've since decided to do is take the two outputs from the original pic and feed it into another pic - this will give me my serial interface and keep the remote control - without having to deal

Now I have a problem with frightfully slow interrupts - I've tested this in PIC Simulator and it works reasonably quickly there. In real life tho, this code interrupts 'eventually' usually 5-20 seconds later. I can't see why, I'm only tying it up for 10 ms then I've inserted an extra pauseus so it's got something to interrupt before/after before returning to serin.

Anyway I can speed up the interrupt to... between 11 and 100 ms?



' Configure the pic
@ device pic12F675, INTRC_OSC_NOCLKOUT, WDT_ON, PWRT_ON, MCLR_OFF, BOD_ON, CPD_OFF, PROTECT_OFF

N9600 CON 6

CMCON = 7
ANSEL = 0

Relay1 VAR GPIO.5
Relay2 VAR GPIO.4

SlavePower VAR GPIO.2
SlaveRelay1 VAR GPIO.0
SlaveRelay2 VAR GPIO.1

Serial VAR GPIO.3

B0 var BYTE

INPUT SlaveRelay1
INPUT SlaveRelay2
INPUT Serial

OUTPUT Relay1
OUTPUT Relay2
OUTPUT SlavePower

ON INTERRUPT GOTO slaveSpeaks
IOC = %00000011
INTCON = %10001000

' Turn on the original PIC
HIGH SlavePower

main:
B0 = 0
PAUSEUS 1

SERIN Serial, N9600, 10, main, [1], B0

' The original PIC latches it's output, we want to reboot the original pic if we get something from the serial port to force it's outputs low
IF B0 > 1 THEN LOW SlavePower
if B0 = 2 THEN GOSUB subUp
IF B0 = 3 THEN GOSUB subDown
IF B0 = 4 THEN GOSUB subStop
IF B0 > 1 THEN
PAUSEUS 1000
HIGH SlavePower
ENDIF
GOTO main

DISABLE
subUp:
LOW Relay2
HIGH Relay1
RETURN
subDown:
LOW RELAY1
HIGH Relay2
RETURN
subStop:
LOW Relay1
LOW Relay2
RETURN

slaveSpeaks:
if SlaveRelay1 THEN
GOSUB subUp
ELSE
IF SlaveRelay2 THEN
GOSUB subDown
ELSE
GOSUB subStop
ENDIF
ENDIF
INTCON = %10001000
RESUME
ENABLE

[mister_e]

I would probably skip the interrupt and perform everything in a tight loop instead. As the Relay check is done pretty quick. Not a fan of using GOSUBs in a ISR.

From what i feel, S2 should have dual contacts attach to GPIO<1:0>

To know which relay is activated, i would bet that...


WhichRelay VAR BYTE
'
'
'
'
WhichRelay=GPIO & 3
Select case WhichRelay
CASE 0 ' Relay 2
' do stuff for relay 2

CASE 1 ' Relay 1
' do stuff for relay 1

CASE 2 ' Relay 3
' do stuff for relay 3
END SELECT

If you still want to use Ints, don't re-enable the GIE bit, the PIC will do it for you. Just clear the offending INT flag and get out of there.

If you play with GIE bit, you will run into problems, that's for sure.

[Freman]

Heh, never even thought about SELECT CASE

So something more like this then.



' Configure the pic
@ device pic12F675, INTRC_OSC_NOCLKOUT, WDT_ON, PWRT_ON, MCLR_OFF, BOD_ON, CPD_OFF, PROTECT_OFF

N9600 con 6

CMCON = 7
ANSEL = 0

Relay1 VAR GPIO.5
Relay2 VAR GPIO.4

SlavePower VAR GPIO.2
SlaveRelay1 VAR GPIO.0
SlaveRelay2 VAR GPIO.1

Serial VAR GPIO.3

B0 var BYTE
SlaveState VAR BYTE
WhichRelay VAR BYTE

INPUT SlaveRelay1
INPUT SlaveRelay2
INPUT Serial

OUTPUT Relay1
OUTPUT Relay2
OUTPUT SlavePower

restart:
SlaveState = 0
PAUSEUS 1000
HIGH SlavePower

main:
B0 = 0
pauseus 1
SERIN Serial, N9600, 10, main, [1], B0
IF B0 > 1 THEN LOW SlavePower
if B0 == 2 THEN GOSUB subUp
IF B0 == 3 THEN GOSUB subDown
IF B0 == 4 THEN GOSUB subStop
IF B0 > 1 THEN GOTO restart

WhichRelay = GPIO & 3
IF SlaveState <> WhichRelay THEN
SlaveState = WhichRelay
SELECT CASE WhichRelay
CASE 0
GOSUB subStop
CASE 1
GOSUB SubUp
Case 2
GOSUB subDown
END SELECT
ENDIF
goto main

subUp:
LOW Relay2
HIGH Relay1
RETURN
subDown:
LOW RELAY1
HIGH Relay2
RETURN
subStop:
LOW Relay1
LOW Relay2
RETURN

[Freman]

Oh I feel like such an idiot - Note to self, double check the label in 'serin' if you change your code substantially...



' Configure the pic
@ device pic12F675, INTRC_OSC_NOCLKOUT, WDT_ON, PWRT_ON, MCLR_OFF, BOD_ON, CPD_OFF, PROTECT_OFF

N9600 con 6

CMCON = 7
ANSEL = 0

Relay1 VAR GPIO.5
Relay2 VAR GPIO.4

SlavePower VAR GPIO.2
SlaveRelay1 VAR GPIO.0
SlaveRelay2 VAR GPIO.1

Serial VAR GPIO.3

B0 var BYTE
SlaveState VAR BYTE
WhichRelay VAR BYTE

INPUT SlaveRelay1
INPUT SlaveRelay2
INPUT Serial

OUTPUT Relay1
OUTPUT Relay2
OUTPUT SlavePower

restart:
SlaveState = 0
PAUSEUS 1000
HIGH SlavePower

main:
B0 = 0
SERIN Serial, N9600, 15, testSlave, [1], B0
LOW SlavePower
SELECT CASE B0
CASE 2
GOSUB subUp
CASE 3
GOSUB subDown
CASE 4
GOSUB subStop
END SELECT
GOTO restart

testSlave:
WhichRelay = GPIO & 3
IF SlaveState <> WhichRelay THEN
SlaveState = WhichRelay
SELECT CASE WhichRelay
CASE 0
GOSUB subStop
CASE 1
GOSUB SubUp
Case 2
GOSUB subDown
END SELECT
ENDIF
goto main

subUp:
LOW Relay2
HIGH Relay1
RETURN
subDown:
LOW RELAY1
HIGH Relay2
RETURN
subStop:
LOW Relay1
LOW Relay2
RETURN

[Freman]

Nope, that isn't working either.

It's working in the simulator but not in the real life.

Should I set up pulldown resistors on the inputs of the new pic from the outputs of the old pic?

[mister_e]

This should work. The only thing i would suggest you, is to use a slower baudrate, check the manual for that. They suggest higher speed OSC for 9600 bauds.

Maybe not a bad idea to call the OSCCAL value to make sure you use the factory calibration for the internal OSC.

DEFINE OSCCAL_1K 1

Your code don't enable the internal pull-up :o

OPTION_REG.7=0

[Freman]

I'm not actually using the serial at the moment, I'm just trying to get to the "other" part of the code, but I'll try 2400 bps, I'll also try the osccal

So you're telling me I should set that bit to 0 in my code?


Nope still no go :( This is the code and attached is the schematic

I know the slave is bringing the pins high (multi-meter and beep confirms it)

Edit: One clue I have is.... if I comment out the serial routine and tell it to goto the 'testSlave' label, it works fine



' Configure the pic
@ device pic12F675, INTRC_OSC_NOCLKOUT, WDT_ON, PWRT_ON, MCLR_OFF, BOD_ON, CPD_OFF, PROTECT_OFF

DEFINE OSCCAL_1K 1
N2400 con 4

CMCON = 7
ANSEL = 0
OPTION_REG.7 = 0

Relay1 VAR GPIO.5
Relay2 VAR GPIO.4

SlavePower VAR GPIO.2
SlaveRelay1 VAR GPIO.0
SlaveRelay2 VAR GPIO.1

Serial VAR GPIO.3

B0 var BYTE
SlaveState VAR BYTE
WhichRelay VAR BYTE

INPUT SlaveRelay1
INPUT SlaveRelay2
INPUT Serial

OUTPUT Relay1
OUTPUT Relay2
OUTPUT SlavePower

LOW Relay1
LOW Relay2

restart:
SlaveState = 0
PAUSEUS 1000
HIGH SlavePower

main:
B0 = 0
SERIN Serial, N2400, 20, testSlave, [1], B0
LOW SlavePower
SELECT CASE B0
CASE 2
GOSUB subUp
CASE 3
GOSUB subDown
CASE 4
GOSUB subStop
END SELECT
GOTO restart

testSlave:
WhichRelay = GPIO & 3
IF SlaveState <> WhichRelay THEN
SlaveState = WhichRelay
SELECT CASE WhichRelay
CASE 0
GOSUB subStop
CASE 1
GOSUB SubUp
Case 2
GOSUB subDown
END SELECT
ENDIF
goto main

subUp:
LOW Relay2
HIGH Relay1
RETURN
subDown:
LOW RELAY1
HIGH Relay2
RETURN
subStop:
LOW Relay1
LOW Relay2
RETURN

[Freman]

SOLVED

I think :)

Throw a 10k resistor from the serial pin to ground. The question now is, should that resistor remain even after I actually hook up the serial signal from the other device?

[PC - USB > serial] ---> [Main Board (PCCLD)] ---> {1 way serial} ---> [New/Master PIC]

Should that resistor remain, or can I turf it once I hook up the serial?

[mister_e]

As you're using the Timeout, the serial pin must Idle at the right level. Not a bad idea to leave this resistor.

http://www.picbasic.co.uk/forum/showpost.php?p=9786&postcount=5

[Freman]

Well, all in all it works - most of the time.... well half of the time

The PCCLD pic is a PIC16F628A running at 20 Mhz
The Master pic is a PIC16F675 running on internal clock at 4Mhz

I'm pretty sure my programmer has fried the CALIB so DEFINE OSCCAL_1K 1 breaks the serial function.

The ONLY baud of those I've tried (1200, 2400 and 9600) that works (somewhat randomly) is 9600 - none of the others work.

Not sure if that's more a function of the PCCLD pic or the Master pic

[Freman]

I'm about ready to give up on serial ports

It shouldn't work at 9600 yet it does randomly...

It should work at 2400 but it doesn't at all

[mister_e]

IF the DEFINE OSCCAL break the serial comm and almost everything, it's a good sign your device programmer screwed the internal calibration, that's for sure. If you have a PICKIT2, you can recover it in few seconds with the OSCCAL Auto regenerate utility.

Acetronics also posted something here.

Lost your OSCCAL Value ???
http://www.picbasic.co.uk/forum/showthread.php?t=7588&

One thing is sure, you're using a BitBanging Serial communication, you may miss some bytes here and there. Using a Hardware USART provide a 2 bytes buffer and Interrupt capability... which are handy.

For a simple test, remove the relay check and keep only the serial part, without timeout. See if it works better.

[Freman]

Given up, moving up to the pic16f628a - Means I can do more as well.
Another consideration I had was using maxim one wire components to free up 4 of the pins, I could have put a crystal on it then.

Still can't really use the hardware uart on the pic16f628a because the pic it's talking to is already using it's hardware uart.

I'll keep a note on that recovery source, that will come in useful :)

But here's my new schematic - http://users.on.net/freman/images/electronics/receiverplus.png

I used the interrupt pin for serial communication, so I could interrupt by sending it high, then send bytes :)
The other option is to use the hardware uart but it'd be connected to software serial at the other end...

I'm not set on that yet, this one's still on the breadboard.

[Freman]

Gone completely back to the idea of replacing the pic.

I think I'll be best served by hooking up my soundcard scope and seeing if it is indeed scanning the input buttons.

[Freman]

Ok guys, I've replicated the functionality of the original 8 pin chip, here's the code - any thoughts?

This is why there's pin fiddling on BUTTONA and BUTTONB
2617

Thanks some more :)



' Configure the FUSE options for the compiler
@ device pic16F628A, hs_osc, wdt_off, pwrt_on, lvp_off, protect_off, bod_on, cpd_off, pwrt_off, mclr_off

' Running a 20Mhz clock
DEFINE OSC 20
DEFINE PULSIN_MAX 3000

CMCON = 7
VRCON = 0

ALL_DIGITAL

' Setup the USART
DEFINE HSER_RCSTA 90h ' Receive register to receiver enabled
DEFINE HSER_TXSTA 20h ' Transmit register to transmitter enabled
DEFINE HSER_BAUD 19200 ' Set baud rate

' Alias our pins
BEEP VAR PORTA.0 ' Buzzer
RFIN VAR PORTA.1 ' Remote input
RELAY1 VAR PORTB.4 ' Relay 1 output
RELAY2 VAR PORTB.5 ' Relay 2 output
BUTTONA VAR PORTB.6 ' Primary panel button input
BUTTONB VAR PORTB.7 ' Secondary panel button input

' Set the pin directions
INPUT RFIN
INPUT BUTTONA
INPUT BUTTONB

OUTPUT BEEP
OUTPUT RELAY1
OUTPUT RELAY2

' Configure the output pins as low
LOW BEEP
LOW RELAY1
LOW RELAY2

' Turn on weak pull-ups - IMPORTANT: After making relays and beepers low...
OPTION_REG.7 = 0

' Set us up some variables
PBITS VAR BYTE[24] ' The bits we've read
RAW VAR WORD ' The raw pulsin value
ADDRESS VAR WORD ' Storage for the address
DBYTE VAR BYTE ' Storage for the data
LOOPADDRESS VAR WORD ' Second loop storage of first loop addres
LOOPDBYTE VAR BYTE ' Second loop storage of first loop data byte
X VAR BYTE ' Loop/TMP var
Y VAR BYTE ' Loop/TMP var
STATE VAR BYTE ' Current state of the device

' Constants
STATE_STOPPED CON 0 ' Screen is stopped
STATE_GOING_UP CON 1 ' Screen is going up
STATE_GOING_DOWN CON 2 ' Screen is going down

' Default state
STATE = STATE_STOPPED

' Reset all the primary RF variables
TOP:
ADDRESS = 0 : RAW = 0 : DBYTE = 0

' This is the real main - almost all the looping comes back here
MAIN:
' Set both buttons for input
INPUT BUTTONA
INPUT BUTTONB
' Check to see if the individual buttons are toggled
IF NOT BUTTONA THEN GOSUB subDown
IF NOT BUTTONB Then GOSUB subUp
' Fiddle with the inputs to see if the middle button is pushed
LOW BUTTONB
X = BUTTONA ' If it's LOW then there's a good chance the middle button is down
HIGH BUTTONB
INPUT BUTTONB
LOW BUTTONA
Y = BUTTONB ' If it's LOW then there's a good chance the middle button is down
HIGH BUTTONA
INPUT BUTTONB
INPUT BUTTONA
IF NOT Y AND NOT X THEN GOSUB subStop ' Both register as LOW then the middle button is down!

' Look for one huge low pulse
PULSIN RFIN, 0, RAW
' 2350 is about mean average
IF RAW < 2340 OR RAW > 2360 THEN MAIN

' Read 16 address bits and 8 data bits
FOR X = 0 TO 23
PULSIN RFIN, 0, RAW
' Check the pulse parameters
IF RAW < 30 OR RAW > 240 THEN MAIN
PBITS[x] = NCD RAW
NEXT X

' Gather the address
ADDRESS = 65535 ' Maxmimum known ID
FOR X = 0 to 15
IF PBITS[x] > 7 THEN ADDRESS.0[X] = 0
NEXT X

' Gather the data
DBYTE = 255 ' Maximum known data value
Y=0
FOR X = 16 TO 23
IF PBITS[X] > 7 THEN DBYTE.0[Y] = 0
Y = Y + 1
NEXT X

' If we've done a loop...
IF ADDRESS == LOOPADDRESS AND DBYTE == LOOPDBYTE THEN
SELECT CASE DBYTE
CASE 3
GOSUB subUp
CASE 12
GOSUB subStop
CASE 192
GOSUB subDown
END SELECT
LOOPDBYTE = 0
LOOPADDRESS = 0
ELSE
' Start a loop
LOOPDBYTE = DBYTE
LOOPADDRESS = ADDRESS
ENDIF

GOTO TOP
END

subUp:
IF STATE != STATE_GOING_UP THEN
HIGH BEEP ' Start making noise
HSEROUT ["UP",10,13] ' DEBUG
LOW RELAY1 ' Make sure the down relay is off (Don't know what happens otherwise, don't want to know!)
PAUSEUS 65355 ' Wait a bit
HIGH RELAY2 ' Turn the up relay on
LOW BEEP ' STFU :)
STATE = STATE_GOING_UP
ENDIF
RETURN

subStop:
IF STATE != STATE_STOPPED THEN
HIGH BEEP ' Start making noise
HSEROUT ["STOP", 10, 13] ' DEBUG
LOW RELAY1 ' Turn off the down relay
LOW RELAY2 ' Turn off the up relay
PAUSEUS 65355 ' Wait a bit
LOW BEEP ' STFU :)
STATE = STATE_STOPPED
ENDIF
RETURN

subDown:
IF STATE != STATE_GOING_DOWN THEN
HIGH BEEP ' Start making noise
HSEROUT ["DOWN",10,13] ' DEBUG
LOW RELAY2 ' Make sure the up relay is off (Don't know what happens otherwise, don't want to know!)
PAUSEUS 65355 ' Wait a bit
HIGH RELAY1 ' Turn the down relay on
LOW BEEP ' STFU :)
STATE = STATE_GOING_DOWN
ENDIF
RETURN

[Freman]

He guys.

Is there any way (other then DarrelTaylor's elapsed timer) to work out how many seconds have passed?

Darrel's method K/O's my pulsin code.

I was looking to time the descent of the screen and stop it at 44 seconds - which is the right height for viewing.

My fall back method is a reed switch - but that'll mean that there's an ugly reed switch visible to the naked eye when the screen is up.

For the record the screen takes 49 seconds to fully descend but that leaves it about a foot too long.

[mackrackit]

Search the forum for Mel's Olympic Timer and RTC. The might do the trick.

Paul has one also.

[mackrackit]

http://www.picbasic.co.uk/forum/showthread.php?t=2129&highlight=real+time+clock

http://www.picbasic.co.uk/forum/showthread.php?t=632&highlight=olympic+timer

[Freman]

Thanks mackrackit, I'll have a look at these.

I've already worked out I can't rely simply on adding 1 to a word (while in theory this works, in reality there's quite a deviation)

I am prepared to fall back on pullies, string, and a piece of pvc with a magnet/reed switches if I have to - this will allow me to put the sensors out of sight... hopefully

[skimask]

I am prepared to fall back on pullies, string, and a piece of pvc with a magnet/reed switches if I have to - this will allow me to put the sensors out of sight... hopefully

Haven't read the whole thread..but...
Couldn't you put a small piece of something reflective on the back of the screen, have an IR led/detector module or similar mounted in the wall behind the screen, if even a few feet behind the screen, and use the detector output as the start/stop sensor? One gets set up so when the beam is there (i.e. reflective piece is bouncing back the light), the screen is all the way down, the other is set up at the top so when the beam is there, the screen isn't quite all the way up. You really wouldn't even need the beam on continuously, just a quick blip every second or so might tell you what you want to know.

[Freman]

I did consider that - and it's not off the drawing board.

I was concerned with the amount of bending anything reflective attached to the back of the screen might suffer - I was also worried about possible damage of the front facing screen (it's a glass beaded screen).

I suppose if it came down to it, I could drill a small hole in the support behind the screen (it's held free-standing from the wall/ceiling by two large timber towers - full of dvd's :)) and stick something reflective to the backside of the felt side strips.

I've looked at http://www.rentron.com/PicBasic/infrared_object_detection.htm for the basic idea - I just need to find something that's reflective, sticky, and can handle being rolled and unrolled over and over again.

[skimask]

Bending - well, you really wouldn't need anything crazy. I'd bet just a piece of scotch tape would reflect well enough. Or maybe a piece of black electrical tape...the inverse of what I was thinking earlier...it DOESN'T reflect.

As far as sticky and reflective, why even use any tape at all? The white screen itself should be reflective enough to bounce some light back into a sensor. Then it would be a matter of 'dialing out' the ambient light.

[Freman]

It would be mounted behind the screen - the back side of the screen is a flat black - haven't tested it's reflectivity.

The other alternative is to use one piece of shiny 'something' on the back of the screen at the bottom (where it doesn't bend) and use 2 detectors.

Which of these would you use?
* Phototransistor (Say: http://tinyurl.com/5bspbk for example)
* Photodiode (Say: http://tinyurl.com/58wuwp for example)
* or a full on IR Receiver (Like: http://tinyurl.com/54vqs6) and PWM the IR led(s) to the right frequency.

Edit: Oooh, just found the Sharp IS471F proximity detector... that could be nice - cept for shipping - I can pick the other options up locally...

[skimask]

Which of these would you use?
* Phototransistor (Say: http://tinyurl.com/5bspbk for example)
* Photodiode (Say: http://tinyurl.com/58wuwp for example)
* or a full on IR Receiver (Like: http://tinyurl.com/54vqs6) and PWM the IR led(s) to the right frequency.
Can't really say for sure. Phototransistor/diode would probably require a bit of 'lensing' to aim to light right, but you wouldn't need to be really accurate or anything. But...you might trip the sensor with the ambient light in the room, so you'd need to throw a bit of 'fuzzy logic' in the program, maybe a counter that say counts 10 times in a row it senses the light and kicks out whatever it is you want to kick out.
An IR TX/RX may have it's advantages...relatively easy to do, one obvious one being that you'd only be looking for the signal that you're sending out, fewer false triggers.
Either way you go, if you know when the IR is on, then you can sense if the IR is really being reflected vs. with ambient light, if you know the IR is off, and you're sensing the signal, then you know the room light is getting in the way.

[Jumper]

Hi,

Why not attach a sensor with encoder from an old PC mouse on the end of the rotating axis. Then you can count how many pulses and position your screen within mm from where it should be.

You might even have a pin on your pic to a hardware counter and then it will more or less count by itself.

/me

[skimask]

Why not attach a sensor with encoder from an old PC mouse on the end of the rotating axis. Then you can count how many pulses and position your screen within mm from where it should be.
You might even have a pin on your pic to a hardware counter and then it will more or less count by itself.
I thought about that too...but, if that count goes off by one this time, one the next time, and so on, one of those times, the motor is gonna drive too far, burn out, the screen is going to fall off, whatever. Still need some sort of end of travel sensor to reset the counter to zero (or 100 or whatever) once in awhile to keep things straight.

[Freman]

Actually the motor has it's own cut-out

When the screen is fully extended it kills the motor, and when it's fully retracted it does the same. That's built in the head end. The worse that'll happen is it'll extend to far for my use and knock something off the TV unit :)

I did consider it, and still haven't ruled it out (as a mouse is cheaper then my parts order ;) - and I should have one laying around)

But I have questions like - how do I count without causing the remote to fail, or while still being able to respond on the serial port. - If I remember right
one of these timer/pwm/things/ works as a counter also - perhaps I can let it do the counting in the background and interrupt when it overflows.

I suppose it's one of those things I'd have to experiment with.

The option is open for a combination of the two.

A sensor at the top to tell it when it's fully retracted, and using the mouse sensor to count the way down.

But, just knowing absolutely whether the screen is UP or DOWN will be so much easier.

My biggest problem now comes from being completely broke and not being able to afford the parts I need to make sensors.