71 replies to this topic

[geogecko]

Mr.RC-Cam.

Thanks for the input. Basically, I need to then check for short pulses (glitches) pulses longer than 2ms (typ), and no pulses at all, high or low, correct? I hope that this will work, however, I just need to code it up and see what happens.

Right now, I'm using Timer 1, which is 2 bytes in length to time the pulse using a 4MHz clock. I'm just going to use the upper byte in order to simplify coding for the time being, then, once I've got that working, I can include the lower byte for better accuracy.

I'll report back once I've tested the code.

Jason.

[geogecko]

Okay. Another problem. I'm using Timer 1 to time the pulses. I turn it on at the rising edge of the pulse, off at the falling edge. Now, the problem with that is that I do all my pulse checking (to compare it with set limits) after the falling edge is received.

I want to be able to detect when the Rx output is stuck high or low. If it's stuck high, then I'll never check the pulse value (since I don't get a falling edge), and eventually, Timer 1 will overflow (after about 65ms+). After I get a completed pulse, and check the pulse value, if it gets stuck low, I would never check it again, and Timer 1 will always be stopped.

Now, I do have Timer 0 which is set up to provide a 20ms delay. I could use a variable to count the number of 20ms delays that have gone by since I did the last value checking on the Rx pulse. Currently, the 20ms overflow is just done with a flag, not an interrupt, so if I waited 3 20ms pulses, that would give me somewhere between 40-60ms from the time I checked the last pulse value. Is this a long enough time to wait (is the 40ms long enough) when checking for a stuck output? In other words, if I don't get a pulse within 40ms, should I consider that a stuck output? I could probably get more accurate if I used Timer 0 overflow, which would get me a lot closer to 60ms, or I could wait even longer, like say, 100ms, however, I was going to try and keep Timer 1 from overflowing, and in the case of 100ms, this would happen.

I'm thinking out loud (or, out typing), so if this is hard to understand, just let me know and I'll try and explain it better.

[Mr.RC-Cam]

In other words, if I don't get a pulse within 40ms, should I consider that a stuck output?

You should consider that state to represent a lost frame. It is good to debounce this further so that short duration hits do not invoke a full failsafe response; several consecutive missing frames would indicate a total signal loss.

As far as coding goes, there are several ways to do it. It is all a matter of trying out your ideas and going from there.

[geogecko]

Is 40ms long enough to wait to consider a lost frame then? I agree with you about the "debounce" technique, so maybe like 5 or 10 lost frames at 40ms each? I'm sorry I'm being so technical here, but I don't happen to have an o-scope sitting at home where I could measure this type of thing.

In your opinion should I also debounce the pulses that are coming in, before actually comparing with my limit values? I guess if I was doing it for the failsafe, I should kind of do an average for the pulse? Kind of like a running average, always using 5-10 pulses for each compare.

Thanks for the help.

[Mr.RC-Cam]

Is 40ms long enough to wait to consider a lost frame then?

Yes. The framerate is typically 35Hz to 60Hz, so 40mS is long enough.

but I don't happen to have an o-scope sitting at home where I could measure this type of thing.

An o-scope is sorely needed to perform in-depth testing for these sort of apps. Try to borrow one or go the eBay route. It shouldn't cost much to get a used low end scope.

In your opinion should I also debounce the pulses that are coming in, before actually comparing with my limit values?

For the full failsafe detection, the answer is often Yes. But, on a pulse-by-pulse basis, out of tolerance values are handled immediately. I output the last known good value instead. This bad pulse replacement emulates failsafe hold and helps prevent glitches.

My PIC based R/C designs have evolved over the years and now use pretty sophisticated pulse error testing. But, for your first project attempts you shouldn't try to incorporate more than you need to. Success is not measured by byte count.

[geogecko]

Great, thanks for the info. You know, I've been thinking I need an o-scope for a while now, maybe I can convince my wife to let me buy one...I'm sure I could convince her that I can fix something of hers with it...

I must certainly agree with you about this project. It has been a lot more involved than I first thought it would be. I had a class in college that was based on the 16C73A, and that is where I got most of my learning on the PICs. However, most of those projects weren't real-world applications. I will heed your advice and not make the project too complex. Basically, I keep several versions as I add more functions, in case I really mess things up, I can go back to a working version.

This bad pulse replacement emulates failsafe hold and helps prevent glitches.

I assume that you mean cover up glitches? Yes, that would be handled immediately, as you could just keep sending the last known good pulse, as you indicated. I enjoyed looking at your landing gear "slower" project. Very nice. I had my project more like your Nav-Lights project for setting up low ATV and servo reverse, however, after reading your article, I have decided to go with a setup pin, and store setup values in EEPROM like you are doing. Very good idea. Haven't got that far yet, but should be there in a few weeks. That at least gives me an extra pin to use for something else.

Do you have any recommendations for an o-scope in the $200-300 range? I'm sure that one that went up to 1MHz would be enough for anything I'd need to do, well, actually maybe 100MHz would be better, considering clocks are running around 4MHz, and others can have up to 20MHz.

[Mr.RC-Cam]

Do you have any recommendations for an o-scope in the $200-300 range?

You should be able to get a used/tested Tek 465B for about that. It is an old product, but excellent otherwise. Look for one that has been recently calibrated.

[Kilrah]

Oops I'm getting late with my holiday..
[quote]After I get a completed pulse, and check the pulse value, if it gets stuck low, I would never check it again, and Timer 1 will always be stopped./quote]
When you've finished measuring a pulse (after the falling edge), you could start Timer1 with an initial value calculated to overflow when wanted. Enable the interrupt, so if the signal is low for too long the timer will overflow and you will get an interrupt.
This means that at the rising edge you also have to reset the timer to measure the pulse.

[geogecko]

Hi Kilrah.

Hey, that's a great idea. I could also use that if the pulse was stuck high, just wait until Timer 1 overflowed (although it would be 65.5ms), and determine from that, that I had a stuck output. I'm thinking that's a better solution than using Timer 0.

Well, there are plenty of 465B's out there on ebay, I just wish people took better pictures. A lot of them are not coming with probes, but I guess if I got a good one that didn't have a probe, I could probably search for one on ebay as well. Maybe I need to go to a surplus store or a company reduction somewhere, at least I could see it, and possibly see it working...

Thanks for all the help.

[Mr.RC-Cam]

...just wait until Timer 1 overflowed (although it would be 65.5ms)

The overflow time value can be ANYTHING you want, up to the max 65mS. It certainly can be less (hint: preload the counter with a value instead of just clearing it).

[geogecko]

But the only problem with a stuck high pulse is that I'd be trying to measure a valid pulse, which what I do when I get an IOC (rising edge), is clear Timer 1 and start timing the pulse until I get a falling edge, which then I stop Timer 1 and store off the value. I could preload after a completed pulse and then if I got an overflow, that would indicate a missed pulse, or no pulse.

I guess what I could do, is preload a value on the rising edge (so that I could get the overflow time I wanted) but then remember that value when I actually got a valid pulse, and subtract it off. Something like this...

(Rising Edge) Timer 1 = 0x63C0 (on overflow, this would give me 40ms)

Case 1:
(Overflow) Timer 1 sets overflow interrupt. Reset Timer 1 to preset and start again.

Case 2:
(Falling Edge) Timer 1 = 0x699C (a 1.5ms pulse was received)

Any time I get an overflow or a completed pulse, I would then reset Timer 1 to the preset value to either wait for another pulse, or wait until another overflow... Cool.

So, is that kind of what you mean?

[Mr.RC-Cam]

Yes, you would need to observe the loaded value later on. Subtract if necessary, or just compare the latched timer values to constants that are offset in size to include the preloaded value.

Again, there are several ways to accomplish the task. Just start coding and go from there. If something does not work out, solve it another way.

[geogecko]

Great. I'll give that a shot and see what happens. Right now I have all this in my ISR, so I really need to take it out, and only leave just the basic stuff to handle interrups in there, and put the rest in the main routine. I think I'll use a flag register, that way, the ISR can kind of talk to the main routine.

BTW, what does BEC put out with a battery that is greater than 6V. I haven't measured it yet to check...

What the heck is a Gaffer anyway?

Edited by geogecko, 04 March 2004 - 11:47 AM.

[mikep]

>What the heck is a Gaffer anyway?

Mostly they hang around the catering table and hit on makeup artists.
;-)

Also ... they are in charge of anything electric on a movie set.
Chief Electrician if you prefer.

Edited by mikep, 04 March 2004 - 12:04 PM.

[geogecko]

LOL. I guess that is a good thing to be, except my wife might not like the whole hitting on makeup artists thing... =)

Edited by geogecko, 04 March 2004 - 12:42 PM.

[Kilrah]

Hehe
A BEC should give out 5V, as it normally consists in a simple 5V linear reg.

[geogecko]

Okay, I was starting to think that it was 5V. I wonder why they spec servos with 6V (I guess if you have a glow plane, and use a 5 cell pack?).

Interesting. I went to see The Passion of the Christ last night with my wife, and as I was watching the trivia questions before the movie, there it was. What is a Gaffer?

"It said a person in charge of the lighting for a scene." Guess it depends on where you are coming from. What that has to do with R/C, I do not know, but okay.

Have you noticed how many posts this thread has gotten? Interesting, huh? I finally removed all the pulse checking (etc) from the ISR, and put it into the main routine (and yes, it still works!). I ordered the parts for the project this morning, so I hope to have a prototype up and working within a couple weeks. I feel like I've reached the point where I need to start actually using an Rx to further test the project. I've been using the strobe LED as an input for the pulse for the time being, and I realize that is probably too perfect of a pulse to expect. (Since I can control it exactly as I want it to be.)

Anyone have any experience with the buzzer used in the landing gear slower project? How loud is it? I was thinking of using it in another project (as just like a timer alarm), is it too loud for that?

Edited:
Oh, and one last thing. Why do I get the pop-up message box while programming the part that says, "Calibration Memory Already Programmed?"

Edited by geogecko, 05 March 2004 - 07:57 AM.

[Kilrah]

I guess if you have a glow plane, and use a 5 cell pack?

Certainly, and I know quite a few people who use that setup, especially for helis where it's good to have your servos going faster.

I finally removed all the pulse checking (etc) from the ISR, and put it into the main routine (and yes, it still works!)

Good thing! Sometimes you think everything is OK and then you spend hours debugging...

[Mr.RC-Cam]

What that has to do with R/C, I do not know, but okay.

The RC-CAM site was formed to help promote R/C model based wireless video applications. So, members of the forum are given names that represent the sort of folks that would produce movies.

Gaffers are the professional guys/gals that setup the scene lighting and manage the electrical distribution duties (I like mikep's description). http://www.newenglan...mber/gaffer.htm

Why do I get the pop-up message box while programming the part that says, "Calibration Memory Already Programmed?"

Because the Cal Osc value is already programmed by the factory.

[geogecko]

I now see. So, would a "Stage Hand" also be considered a Grip? That's cool. I should have put 2 and 2 together (maybe for me, I should have put 1 and 1 together).

I was a little worried about moving the code to the main routine, but knew it had to be done, since it wasn't really part of the interrupt servicing. I'm glad it worked out so nicely. Just a couple more added instructions checking flags, and that was all that was needed.

So, basically, if I leave the code in that programs the OSCCAL value, then I will always get that message? I have noticed that on accident I programmed the wrong value in (after changing to a new PIC), but upon reading the program memory back, the value was still the original value. Is it write protected or something?

CALL CAL_INTOSC

CAL_INTOSC
BSF	BANK_SW;Switch to BANK 1
CALL	0x3FF;Get the Cal Value
MOVWF	OSCCAL;Calibrate
BCF	BANK_SW;Switch to BANK 0
RETURN

And then...

ORG	0x3FF
RETLW	0x60

That is the proper way to do it, is it not?

Edited by geogecko, 05 March 2004 - 08:19 AM.