Oscillator stops when touching with a wire

[Wilbert Ingels]

Hey Skimask,

Thanks for your reply !

I'm still struggling how to do it. If i use a tight loop with timeout which receives character by character, i'm afraid if only one bit is send (my famous glitch ), the timeout statement won't work and the endless loop will start (untill additional information is received)

I'm going to try it and will keep you in touch. If you remember you other suggestion, you're more than welcome

Take care

Wilbert

[Wilbert Ingels]

If i look in the manuel on page 135 (serin2) "if the serial input pin stays in the idle state during the timeout time, the program will exit the SERIN2 command and jump to label". In my case, the input pin doesn't stay idle because it received one glitch ...

Same for Debugin on page 58 ...

Hum, i don't see it yet how i can solve it

[mister_e]

Pull-up or pull-down resistor is an easy to test Solution?

[Ron Marcus]

It sounds like static electricity is the culprit here. I understand touching an input, but the ground should be somewhat immune to the phenomena. It sounds like there is a ground loop in the connections. Look for multiple lines connected to ground in the same run of cable. Touching one will cause an imbalance. So if the shield is connected to ground, and another line in the cable is, this could cause a problem. The simplest fix is to not connect the shield on one end of the cable. While it sounds counter intuitive, it might be the cause, or one of them.
Ron

[skimask]

If i look in the manuel on page 135 (serin2) "if the serial input pin stays in the idle state during the timeout time, the program will exit the SERIN2 command and jump to label". In my case, the input pin doesn't stay idle because it received one glitch ...

The fix might be something as simple as:

loop:
datagood = 0
SERIN2 (((your code here with the shortest timeout possible, timeoutlabel, etc.etc....)))
datagood = 1
goto overtimeoutlabel
timeoutlabel: if datagood = 0 then goto loop  'data was bad, try again
overtimeoutlabel: continue code here....

if it does glitch, you check 'datagood'. If datagood is 0, then it glitched or didn't receive what you wanted and try again

Aside from that, I agree with the other guys, ya gotta find the root cause of the glitches...

[Wilbert Ingels]

Hey Guys,

Thanks for the feedback !

Yesterday, i've changed the RS485 chips. I was using SN75176 and i've changed them for MAX481 and the glitched are gone. It seems that SN75176 is more sensible and thus in my case less usable in my application. The MAX481 untill now never gave one glitch. I'm working now on the timing aspects because these seems different between SN75176 and MAX481.

I've also went into more detail in how PBP works. I understand the little drawbacks (in terms of serial communication) of the language better now but i must say that, the longer i work with PBP, the more enthusiastic i am. It is a great language and a fantastic tool.

Take care

Wilbert