Nav-Lights Variation Project Help
Posted 02 March 2004 - 02:55 PM
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.
Posted 03 March 2004 - 11:44 AM
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.
Posted 03 March 2004 - 12:48 PM
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.
In other words, if I don't get a pulse within 40ms, should I consider that a stuck output?
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.
Posted 03 March 2004 - 02:06 PM
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.
Posted 03 March 2004 - 02:28 PM
Yes. The framerate is typically 35Hz to 60Hz, so 40mS is long enough.
Is 40ms long enough to wait to consider a lost frame then?
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.
but I don't happen to have an o-scope sitting at home where I could measure this type of thing.
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.
In your opinion should I also debounce the pulses that are coming in, before actually comparing with my limit values?
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.
Posted 03 March 2004 - 03:08 PM
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.
Posted 03 March 2004 - 03:21 PM
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.
Do you have any recommendations for an o-scope in the $200-300 range?
Posted 04 March 2004 - 02:53 AM
[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.
Posted 04 March 2004 - 06:30 AM
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.
Posted 04 March 2004 - 07:40 AM
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).
...just wait until Timer 1 overflowed (although it would be 65.5ms)
Posted 04 March 2004 - 10:55 AM
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)
(Overflow) Timer 1 sets overflow interrupt. Reset Timer 1 to preset and start again.
(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?
Posted 04 March 2004 - 11:16 AM
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.
Posted 04 March 2004 - 11:45 AM
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.
Posted 04 March 2004 - 12:04 PM
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.
Posted 04 March 2004 - 12:41 PM
Edited by geogecko, 04 March 2004 - 12:42 PM.
Posted 05 March 2004 - 01:13 AM
A BEC should give out 5V, as it normally consists in a simple 5V linear reg.
Posted 05 March 2004 - 07:11 AM
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?
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.
Posted 05 March 2004 - 07:55 AM
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 guess if you have a glow plane, and use a 5 cell pack?
Good thing! Sometimes you think everything is OK and then you spend hours debugging...
I finally removed all the pulse checking (etc) from the ISR, and put it into the main routine (and yes, it still works!)
Posted 05 March 2004 - 08:04 AM
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.
What that has to do with R/C, I do not know, but okay.
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
Because the Cal Osc value is already programmed by the factory.
Why do I get the pop-up message box while programming the part that says, "Calibration Memory Already Programmed?"
Posted 05 March 2004 - 08:18 AM
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?
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
ORG 0x3FF RETLW 0x60
That is the proper way to do it, is it not?
Edited by geogecko, 05 March 2004 - 08:19 AM.