Well, the problem is that I have an input signal that I would like to filter. The input is a 50Hz PWM - erm, strange PWM as the period is at 50Hz (around 20ms) but the duty cycle is between 1-2ms. That is used for controlling servos used for modelling and robotics. The receiver is a dumb thing, demultiplexes whatever it gets to several channels and puts the signal out whatever it was -- even if it is not a PWM signal. From outside the radio you just see square signals, and that's where you have to decide whenever it is a valid or a not valid. What you can do basically is that see if the signal is in between 1-2ms, that's no problem. The other thing I thought is that you can see if the signal arrives in time (every 20ms). Also no problem finding out whenever the signal arrives. Now the problem is that, I do not know why but it seems that 20ms is not always kept -- it sometimes extends to longer, which is seems that depends on the noise comming in. Also sometimes a noise could produce duty cycles 1-2ms so you have to do additional measurements. Avareging not always works and also slows down the reaction time, but it's already in, anyway. Comparing to 'left and right' is not always works and also slows down a bit the reaction time, but it is also already in. My basic problem is to determine if the signal is so bad it has to go to a safe position and wait until good signal can be received. Interestingly when I switch off the thransmitter it knows trait away that there is no signal so shuts down the system after a couple of moments. But when just noise comming in or the received signal is too weak it just do not want to realize that the signal is too bad. It is very interesting to me as I could still see strange duty cycles when the transmitter is off. Maybe there is a good method for dealing with such a problem, but I thought it is very specific, that't why did not want to bother you with the details. Tamas On 01/09/06, Jinx wrote: > > > My problem is that as far as I know there is no way to track > > down what's going on even using a hardware debug station > > What exactly is the problem ? Maybe we can sort it out logically. > So often things look hopeless, but a few fresh eyes and brains > can do wonders. Sometimes ;-) > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- unPIC -- The PIC Disassembler http://unpic.sourceforge.net -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist