Hi Alan,
Absurd? I suppose you could look at it that way. But another way is to consider this a natural progression to larger and larger integration. The PC, tracker box, rotor control box, etc., are all building blocks for the final system, just as assembling a larger number of smaller integrated circuits would have been in your model. In the Web 2 world they're calling it a "Mashup" (which is probably the most visual name I could imagine for such a thing). Don't think of the PC as being a computer, but rather as a simple box that has connections to the network (for Keps), and a serial port for outputting Az/El information.
There's always a place for projects where we mine sand and make transistors, or assemble transistors and make circuit boards, or combine circuit boards to make a computer, or write software to make the computer sing and dance. This is just the next level, and it has its advantages and drawbacks, and significant potential for frustrations and feelings of accomplishment.
To Andrew's original question, my choice was similar to his, and the answer similar as well. Linux PC running Predict, spitting Az/El coordinates through a serial port to an external controller box, who's job it was to match the rotor's state with the desired direction. But lacking the original rotor control box, I had to make my controller take on that job too. Pictures and the design docs at: http://home.wavecable.com/~ko6th at the top of the page.
Have fun,
Greg KO6TH
From: ve4yz@mts.net To: amvm@skynet.be; vk4tec@tech-software.net; amsat-bb@amsat.org Date: Tue, 13 Oct 2009 10:35:14 -0500 Subject: [amsat-bb] Re: PIC rotator control
Marc, Andrew and the group...
It has always struck me as being odd that we use a PC to run a PC(PIC based tracker box), to run a rotator control box, to run a rotator. Sure it works but the absurdity of this really hits home when you disassemble your shack to take it all out for Field Day or an EmComm exercise. I don't! I leave the PC and LVBtracker at home and take my good old 1990's preprogrammed PIC based TrakBox that does the radio and rotators.
http://www.tapr.org/kits_trakbox.html
http://picasaweb.google.com/ve4yz.alan/TrakboxRebuild2004#
As I read you comments you are both querying the rotator controller, not the rotators, to find out where the AL and EL are.
With the power of today's inexpensive netbooks or the OLPC is there not a solution where the "embedded system is the netbook"? Then, all that would be required between the PC and the rotator is a black box with relays to power the rotators and a small A/D interface to take the data from the pots and pass it onto the PC? A black box easily assembled by most hams. If open source, then others can do whatever is necessary create mods for various rotator systems such as pulse counting for stepper motors instead of A/D etc
My 2 cents.... Alan
-----Original Message----- From: amsat-bb-bounces@amsat.org [mailto:amsat-bb-bounces@amsat.org] On Behalf Of Marc Vermeersch Sent: October 13, 2009 6:45 AM To: 'Andrew Rich'; amsat-bb@amsat.org Subject: [amsat-bb] Re: PIC rotator control
Hi Andrew,
I have a PIC based solution currently in the prototype stage. It uses a PIC18F4455 and drives a Yeasu AZ/EL rotor without the Yeasy control box.
The PC sends information to the PIC (RequestedAZ,RequestedEL) and the PIC sends back status information to the PC (RequestedAZ,RequestedEL,CurrentAZ,CurrentEL,Status).
Everything is done by the PIC:
- Control of the rotor motors based on either
move-every-n-seconds or move-when-error-angle-is-greater-than-n
- Measurement of the actual AZ/EL with 10-bit resolution
- Parking when no signal has been coming from the PC in x
seconds -or- an explicit park command is received
- Stall protection
- Some horizon protection: EL cannot go below x when AZ is y
to avoid pointing into my neighbors' bedroom.
- Over the top rotor control (under development)
- ...
I'm using a PIC18F4455 and it is very well capable of doing all that and more. I have chosen this path for several reasons:
- Eventually I want to run a tracking algorithm in the PIC too
- To make the control loop shorter
- To avoid dependence on the PC part specifically on safety
related aspects like stall control and horizon protection.
- To explore the capabilities of the PIC18
- (Because it's my job to do embedded HW/SW)
BR,
//\arc
-----Original Message----- From: amsat-bb-bounces@amsat.org
[mailto:amsat-bb-bounces@amsat.org]
On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: amsat-bb@amsat.org Subject: [amsat-bb] PIC rotator control
Hello
I am re-visting a rotator controller.
I am curious, should I push the processing of the "compare
and make a
decision" onto the PIC, or pull that function back into the PC ?
PC is LINUX
I/O is serial
PIC is 16F877
Andrew VK4TEC
Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
_________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/171222984/direct/01/