Trying to inch my way to the finish line w/ a 16F1829.........

[HenrikOlsson]

Hi,
Please, please use the code tags when posting code

[ code ]
Paste code here but remove the spaces within brackets and you'll get:
[ / code ]

Paste code here but remove the spaces within brackets and you'll get:

1) I don't quite get it... Do you have multiple encoders all connected to a single input and if so how does that work? I thought east/west etc were individual inputs but they are clearly outputs so I'm not sure I understand.
What's the purpose of the DISABLE right before the interrupt handler? DISABLE is used with PBPs ON INTERRUPT, I don't Think you want it there when using DT-INTS. It's probably not related to the problem you're having but still....

2) That's probably because you're using SEROUT while you have interrupts stealing time away from in in the background. SEROUT is software timed, if you have interrupts firing while SEROUT is executing its timing will be off causing baudrate errors. The 16F1829 does have EUSART, you'll be MUCH better off using it (with HSEROUT for example) instead of SEROUT!

3) I'll leave this one for now.

4) I think you're doing quite good! It's a bit too much code to for me to "pick apart" right now but one thing I personally don't use much is HIGH/LOW. They are nice in that they automatically set the pin to an output (clearing TRIS) but it does so on every occurence of the command so it's quite wasteful if the pin is supposed to be an output all the time anyway. Nothing inherently wrong with HIGH/LOW though so as long as you're not suffering from speed or lack of flash then it's just fine.

/Henrik.

[thasatelliteguy]

/Henrik,

Thanks for the reply. Yes the encoders were all separate at one time. There are two right now, but there are actually 3. Elevation, Azimuth, and Skew. I'm not using the skew right now as it's not super critical to change it within reasonable driving distance ie about 12 hrs. The remaining two, as well as eventually the third, all join together to come in to the MC on one wire. I did this when my plan was to have a wired handheld device only and was trying to keep the number of wires down to 8 so I could use CAT5 between the two. I have since gone BT with the multi-MC idea, but I saw no reason to change it. If you look at my interrupt coding, I simply made it so that the program decides which encoder to add the pulse to by deciding which axis it was trying to move. Since only one axis ever needs to move at one time, it works fine. I just re-read your post... UP, DOWN, EAST, WEST are the output pin aliases. Eencoder0Pos is the variable for the elevation encoder position. Aencoder0Pos is the variable for the Azimuth. If a pulse comes in and the MC was moving the dish up, UP will be = 1 to it'll add 1 to the Eencoder0Pos. If it was moving the dish down, then DOWN will = 1 and it'll subtract 1 from Eencoder0Pos and so forth. Each encoder originally had two pulse wires with one pulse half a cycle behind so the MC could distinguish which way it was rotating. Ditching the second pulse wire from each encoder (since the MC already knows which way it was trying to move it) and combining the remaining three (since the MC also knows which encoder should be moving) was the only way I could think of to get it all on one wire.

Speaking of which, I am having a problem there too. The elevation isn't an issue. From "stowed" (down) to full travel UP, is like 3665 pulses. But the azimuth is WAY more. From "stowed" around to physical limits one way is approx 220 deg, and 109300 pulses. And that's only partial rotation. Full rotation is about 400 - 450 deg, so I have a counter that needs headroom of about 250,000. What can i use that's bigger than WORD? The 65k overflow point isnt really workin for me. When I started this project in Arduino, it wasn't an issue. If I can't get bigger than WORD, then the only other thing I can think of is to add code to the interrupt so on azimuth, it'll only -1/+1 to my var on say, every fifth pulse. I have resolution coming out my ears, but still, I'd rather not if there's another way.

The high/low issue... So if I use high/low, it sets the TRIS bytes for me? If I use high/low, it significantly adds to the program size? And if I set the TRIS bytes, how do I do it? I guess, WEST = 1?? Very interesting... I don't recall this info being in the PBP manual?

Yes, I'll kill the disable. I think it's an accidental leftover from when I started. I started using a PBP int for that and the DT-INT for a timer. Then after I understood the DT-INT a little better, it switched over to it for both. I was using velocity monitoring and a sudden slowing to calc when I hit the physical limit on azimuth. Then I found the switch yesterday, and eliminated that catastrophe of coding. I need to eliminate the timer as well since I have no use of any time-keeping anymore.

[thasatelliteguy]

Hi,
2) That's probably because you're using SEROUT while you have interrupts stealing time away from in in the background. SEROUT is software timed, if you have interrupts firing while SEROUT is executing its timing will be off causing baudrate errors. The 16F1829 does have EUSART, you'll be MUCH better off using it (with HSEROUT for example) instead of SEROUT!
/Henrik.

I figured it was something like this. I assumed it had to do with the ASM interrupts because through playing with the numbers, I found:
Faster Clock = Less errors (expected)
Faster Baud = Less errors (not expected)

I then had the hypothesis that there were "time holes" my serial info was falling thru. Faster clock = smaller holes = less char lost. And faster baud = more info makes it thru beween the holes = less char lost. It did baffle me at first, that lowering the baud made it way worse. I had to drive around at work thinking about it for several hours before it hit me what was happening... lol

[Demon]

Just wondering, why bother counting pulses?

Wouldn't you only need 360° rotation, 90° elevation and not sure for skew?

Since you haven't tackled the tracking yet, would it be simpler to just "move" as long as a button is pressed on the handheld?

Or, maybe enter a degree and go to that position (a rotary encoder on the devices can track where it's pointed).

Just tossing thoughts.

Robert

[thasatelliteguy]

Just wondering, why bother counting pulses?

Wouldn't you only need 360° rotation, 90° elevation and not sure for skew?

Since you haven't tackled the tracking yet, would it be simpler to just "move" as long as a button is pressed on the handheld?

Or, maybe enter a degree and go to that position (a rotary encoder on the devices can track where it's pointed).

Just tossing thoughts.

Robert

Well ya... that's the idea. But without an encoder, how would it have any idea where it is? The pulse counting is the only way to indicate how far the dish has travelled. When you look at the handheld, (or the phone or terminal) when I'm done, you will only see degrees or a satellite choice. You won't see the pulses anymore, but they have to be there. Maybe you misunderstood my project... This is a self-acquire satellite system, BUT I'm rebuilding the electronics from scratch. I S***canned all the stock electronics. The dish itself is VERY hearty, and well (over) built, but the electronics were way overbuilt as well, and as such, never worked reliably. Also, I am upgrading (completely changing) the satellite system that run on it as well. Totally different band even. So I have to establish a new way for it to identify and peak in on the new satellite as well.

I just re-read... OH! No, you would have to see the dish.. lol. Not small. 1 meter, on it's own trailer with an on-board box for generator, UPS, batteries, modem, router, etc. The dish only needs 360deg, (well a lil for overlap in case the user has the trailer oriented with the satellite right at the stop point) and elevation 90deg. BUT the motors are very small and geared down to hell and back. (I'm pretty sure the reason was so the motors could be de-energized and the dish stay put due to the extreme gearing) As a matter of fact, the elevation hardware is a C-band Superjack. The azimuth motor is nearly the same, but of course oriented differently. So an encoder that would only read a partial amount of a single revolution won't work. The motors turn many thousands of times to fully rotate the dish.

When I'm done, there will be a JOG mode that moves as long as the button's pressed. But I still want it tracking where it is, both for auto-stow purposes, and because the box that mounted on the trailer is in a possible path of the dish. It'll never be in the way to find the bird, but you can (and I did this morning, and ripped the mounting plate right off the trailer, something else I'll need to repair now) crash the dish into the box. Bad S*** happens. So even when jogging, I want to program in "no fly zones" that wont allow you to crash it.

As for giving it target coordinates, it'll be even easier than that. It only points to one satellite. With the addition of GPS and compass, you will be able to turn it on, and press Auto-Acquire and it'll do the rest. That's the end goal.


Make a lil more sense now?

[HenrikOlsson]

Hi,

Each encoder originally had two pulse wires with one pulse half a cycle behind so the MC could distinguish which way it was rotating. Ditching the second pulse wire from each encoder (since the MC already knows which way it was trying to move it) and combining the remaining three (since the MC also knows which encoder should be moving) was the only way I could think of to get it all on one wire.

So ordinary qudrature encoders then. Are they open collector output? I mean, if they are push-pull type output and you have several connected together there's quite a possibillity one will try to drive the line low while another tries to drive the line high.

Another option is to keep a global count for each encoder. Then you have each encoder signal connected to a timer/counter input on the PIC. When you're about to move an axis you clear the timer/counter register and run the motor. The timer/counter register will now track the relative movement which you can add or subtract from your global count for the axis moving. You'll still not have the direction information given by the quadrature nature of the encoder but it sounds as if the dish can't be backdriven anyway.

I figured it was something like this. I assumed it had to do with the ASM interrupts because through playing with the numbers, I found:
Faster Clock = Less errors (expected)
Faster Baud = Less errors (not expected)

When you increase the baudrate each "message" takes less time to send so it's less likely that an interrupt occurs while it's sending.

What can i use that's bigger than WORD?

That would be a LONG but they're only available on 18F parts. If you don't NEED the resolution then increase your count every X interrupt, that would be the easiest. Another option is to use two WORDS where the "top" one indicates degrees and the "bottom" one indicated minutes, seconds or 1/10 of degrees or whatever.

The high/low issue... So if I use high/low, it sets the TRIS bytes for me?

Yes it does. But it does every time you use HIGH/LOW.

If I use high/low, it significantly adds to the program size?

I guess it depends on how you define significantly but yes. Lets say you have WEST aliased to PortB.0, then doing HIGH WEST will basically be replaced with TRISB.0 = 0 : PortB.0 = 1. The "wasteful" part is that it does the TRISB.0 = 0 every time you do a HIGH/LOW west, even if the pin is and has been an output all the time.

And if I set the TRIS bytes, how do I do it? I guess, WEST = 1?? Very interesting... I don't recall this info being in the PBP manual?

Exactly, just clear the TRIS bit (like you're already doing). Then simple set the port register. PortB.0 = 1 or WEST = 1, if WEST is aliased to PortB.0.

/Henrik.

[thasatelliteguy]

Hi,
So ordinary qudrature encoders then. Are they open collector output? I mean, if they are push-pull type output and you have several connected together there's quite a possibillity one will try to drive the line low while another tries to drive the line high.

I thought of this when I first got rolling but one of the first things I worked on was to come up with some sort of scope. I made one from some CAT5, a stereo headphone jack from Radio Shack, and some alligator clips to use the mic jack on my laptop. Anyways, I can see the encoder signals, and from day one they have always been super clean. When I combined them I noticed no degradation or conflicts. Right now is probably the dirtiest I've seen because I have 50ft of CAT5 running in my living room window from the dish to my breadboard. (It's HOT in Texas!) But even when I say dirty, they are still really clean square waves, very little edging on the corners, if any, and no misses, dropoffs, or extra trash spikes. Just not PERFECT like you see people playing with PLL's on youtube on $1k scopes.

Another option is to keep a global count for each encoder. Then you have each encoder signal connected to a timer/counter input on the PIC. When you're about to move an axis you clear the timer/counter register and run the motor. The timer/counter register will now track the relative movement which you can add or subtract from your global count for the axis moving.

timer/counter input?? hmm, I'll have to look into this dark magic you speak of...

You'll still not have the direction information given by the quadrature nature of the encoder but it sounds as if the dish can't be backdriven anyway.

If by "backdriven", you mean you can't push it by hand and move it, then yes you are right. I think this is why the designers used regular DC motors with gearboxes and encoders instead of say, large steppers. The steppers could have been used with no gears and no encoding, but when powered down, the dish would be flapping in the wind.

When you increase the baudrate each "message" takes less time to send so it's less likely that an interrupt occurs while it's sending.

Ya but here's the rub... there was no interrupt happening. This has been happening since I put in the interrupt coding, but there was nothing hooked up. The encoder wire was just hanging off the CAT5 while I was jogging the dish manually while physically watching it (to avoid crashing) and tweaking the code for the menus and dish control. And remember, right now, there is no interrupt happening. That was the #2 subject of this post. (Which I still haven't figured out) And the way my code is written,

Eencoder0Pos = 0
HIGH UP
PAUSE 250
IF Eencoder0Pos = 0 Then goto moveerror

If I was having a float problem, it would only have to trigger ONE interrupt to avoid my error. My code doesn't require steady movement, or consistent movement, it only requires it not to still be on ZERO, which it is. So with confirmed zero triggered interrupts, it's still dropping characters from the ----- OMFG! Wow it's dark in here! Smells bad too... I just may pull my head out someday! The timer! Duh! I completely forgot the timer interrupt.... I'll get back to ya on this one..... UGH!

If you don't NEED the resolution then increase your count every X interrupt, that would be the easiest.

That's what I was figuring my factor of 5 on. If I have 250,000 pulses from limit to limit, and I count every 5th pulse, that's now 50,000 which gives me 15000 to spare.

[HenrikOlsson]

Hi,

I thought of this when I first got rolling but one of the first things I worked on was to come up with some sort of scope. I made one from some CAT5, a stereo headphone jack from Radio Shack, and some alligator clips to use the mic jack on my laptop. Anyways, I can see the encoder signals, and from day one they have always been super clean. When I combined them I noticed no degradation or conflicts. Right now is probably the dirtiest I've seen because I have 50ft of CAT5 running in my living room window from the dish to my breadboard. (It's HOT in Texas!) But even when I say dirty, they are still really clean square waves, very little edging on the corners, if any, and no misses, dropoffs, or extra trash spikes. Just not PERFECT like you see people playing with PLL's on youtube on $1k scopes

OK, soundcards generally have a capacitor in series with the input to remove any DC bias, I'm surprised that you get a clean crisp square wave but I guess it depends on at what frequency you measured. What if you remove the encoders and use a switch or whatever to simulate pulses and toggle a LED or something in ISR? That way you should be able to verify if interrupts aren't actually being generated.

timer/counter input?? hmm, I'll have to look into this dark magic you speak of...

Your PIC have two timers TMR0 and TMR1. They can be configured as timers or as counters. When configured as counters they will be "clocked" by a signal connected to T0CKI and T1CKI inputs respectively.

If by "backdriven", you mean you can't push it by hand and move it, then yes you are right. I think this is why the designers used regular DC motors with gearboxes and encoders instead of say, large steppers. The steppers could have been used with no gears and no encoding, but when powered down, the dish would be flapping in the wind.

That's exactly what I meant. If you don't get the direction information from the quadrature encoders then you must be SURE that each and every pulse from the encoder is caused by the dish moving in the desired direction. If there's any vibration etc it's going to cause "extra" pulses which eventually will cause the position to drift. Sounds like you've got it covered, just something to think about.

Ya but here's the rub... there was no interrupt happening. (snip) And remember, right now, there is no interrupt happening. That was the #2 subject of this post. (Which I still haven't figured out) And the way my code is written....(snip)....I just may pull my head out someday! The timer! Duh! I completely forgot the timer interrupt.... I'll get back to ya on this one..... UGH!... (snip)

Ya, exactly...THE TIMER.... :-)

Lets focus on one issue at the time, pick one and let us know how it goes. We'll go from there!

/Henrik.

[EarlyBird2]

Speaking of which, I am having a problem there too. The elevation isn't an issue. From "stowed" (down) to full travel UP, is like 3665 pulses. But the azimuth is WAY more. From "stowed" around to physical limits one way is approx 220 deg, and 109300 pulses. And that's only partial rotation. Full rotation is about 400 - 450 deg, so I have a counter that needs headroom of about 250,000. What can i use that's bigger than WORD?

This jogged my memory regarding a problem I had regarding time of day comparisons. I had the idea of converting time of day to seconds into day which obviously could go up to 86400 and will not fit into a byte or word variable. I resolved the issue by comparing hours, minutes and seconds into the day which was just a few more lines of code.

In your case is it possible to change pulses into second, minute and degree variables. Then again obviously your variables will have 60, 60 and 450. This will then be a clock routine of which there are many examples I am sure.

[thasatelliteguy]

I'm sorry guys. I was very very tired. I have a crazy learning curve, and sometimes when I push wide-open-throttle for too long cuz I've really bitten off too much, I burn out and crash. I've been asleep since Saturday... five weeks was just too long. I really do appreciate all the help! You all are great!

Can I use EUSART over BT HC-05? I would assume not since one is UART and one is EUSART...

If that's the case my problem is then:

1. I cant use DT's interrupts without corrupting my serin/serout. And I have to assume it'll corrupt hserin/hserout as well.
2. I can't use ON INTERRUPT cuz it'll miss pulses during even the shortest waits. This is even worse than #1 since the machine will be lost.

If I use serial interrupts and program loops, which from how arduino is structured, I assume that's what happens on that platform, wouldn't that solve my problem once and for all?