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
Wouldn't you like flashing the pic with the G6LVB tracker firmware and make the circuit? (google: g6lvb). I made it with an old HAMIV rotator and a pic16F877A. LVB tracker does a great job and speaks serial words Linux could understand.
Steve - Iw1RDZ
________________________________ Da: Andrew Rich [email protected] A: [email protected] Inviato: Mar 13 ottobre 2009, 12:22:15 Oggetto: [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 [email protected]. 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
__________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it
Thank you
----- Original Message ----- From: Stefano Simonetti To: Andrew Rich ; [email protected] Sent: Tuesday, October 13, 2009 9:01 PM Subject: Re: [amsat-bb] PIC rotator control
Wouldn't you like flashing the pic with the G6LVB tracker firmware and make the circuit? (google: g6lvb). I made it with an old HAMIV rotator and a pic16F877A. LVB tracker does a great job and speaks serial words Linux could understand.
Steve - Iw1RDZ
------------------------------------------------------------------------------ Da: Andrew Rich [email protected] A: [email protected] Inviato: Mar 13 ottobre 2009, 12:22:15 Oggetto: [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 [email protected]. 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
__________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it
------------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date: 10/12/09 13:01:00
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: [email protected] [mailto:[email protected]] On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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
Kewl
Do you convert
"067" from ascii to binary and then compare that to an A/D value ?
I have worked out how to do binary to ascii
Sometime I wonder if just programming in perl on the LINUX side might be just as easy
I think potentiometers are used on most rotators ?
Unless stepper motors have entered the scene ?
Andrew
----- Original Message ----- From: "Marc Vermeersch" [email protected] To: "'Andrew Rich'" [email protected]; [email protected] Sent: Tuesday, October 13, 2009 9:44 PM Subject: RE: [amsat-bb] 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: [email protected] [mailto:[email protected]] On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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
--------------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date: 10/12/09 13:01:00
Hi Andrew,
Let's take azimuth as an example. The PC sends a string containing the ascii value of the required azimuth. That value is converted to a binary value. That binary value (0-360) is converted to an "expected" 10-bit ADC value (theoretically 0-1024) for that angle.
The range I get from my rotor is not 0-1024 but roughly 100-950 on one rotor and 50-800 on the other. Therefore I use a lookup table to do the conversion. After that I drive the rotor to make the measured angle equal to the expected angle within a certain tolerance. That makes the motors run smoothly without "chasing" the desired value.
This can be done in Perl on a LINUX PC, no doubt about that. The control loop will be longer and you would have to solve some additional problems like how often do you need to communicate between the PC and the PIC to make the motors run smoothly.
Good Luck, -- //\arc
-----Original Message----- From: Andrew Rich [mailto:[email protected]] Sent: dinsdag 13 oktober 2009 13:50 To: Marc Vermeersch; [email protected] Subject: Re: [amsat-bb] PIC rotator control
Kewl
Do you convert
"067" from ascii to binary and then compare that to an A/D value ?
I have worked out how to do binary to ascii
Sometime I wonder if just programming in perl on the LINUX side might be just as easy
I think potentiometers are used on most rotators ?
Unless stepper motors have entered the scene ?
Andrew
----- Original Message ----- From: "Marc Vermeersch" [email protected] To: "'Andrew Rich'" [email protected]; [email protected] Sent: Tuesday, October 13, 2009 9:44 PM Subject: RE: [amsat-bb] 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: [email protected] [mailto:[email protected]]
On
Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date: 10/12/09 13:01:00
On Tue, 2009-10-13 at 21:50 +1000, Andrew Rich wrote:
Sometime I wonder if just programming in perl on the LINUX side might be just as easy
The PIC microcontrollers are frankly *dreadful*, without a single redeeming feature. What makes me like them even less is that you're forced to use the bloody awful Windows software to program them, and the programming hardware is extremely finicky. There is a PIC assembler that runs under Linux, but it sucks elephants through very fine mesh.
I've ditched all my PIC stuff and now use AVR, which is extremely well supported on Windows, Mac OS and Linux. It's a better product, the CPU core is generally faster clock-for-clock and it's only slightly more expensive. How much is your time worth?
If you're not convinced yet, buy an Arduino board. You probably couldn't put together an AVR board for less in onesy-twoesy quantities.
Gordon MM0YEQ
On Thu, 22 Oct 2009 10:09:22 am Gordon JC Pearce wrote:
I've ditched all my PIC stuff and now use AVR, which is extremely
well
supported on Windows, Mac OS and Linux. It's a better product,
the CPU
core is generally faster clock-for-clock and it's only slightly more expensive. How much is your time worth?
I couldn't agree more. I'm in the process of updating some of my old PIC projects which has reinvigorated my interest in amateur satellites and amateur radio in general.
Hi Steve, I replied to your email only to have Comcast reject it as spam with no way of unblocking it. Have you got an email with a non-broken provider I could forward it to?
Gordon MM0YEQ
--- On Wed, 10/21/09, Gordon JC Pearce [email protected] wrote:
The PIC microcontrollers are frankly *dreadful*, without a single redeeming feature. What makes me like them even less is that you're forced to use the bloody awful Windows software to program them,
I've used "gpasm" for assembly, and "picprog" for serial port programming, both under Linux, with excellent results.
I generally select the PIC I use in my projects based on the functions I require, and how well it is supported under the assembler and programmer indicated above.
This approach has worked extremely well for my purposes.
73, de John, KD2BD
-- Visit John on the Web at:
http://kd2bd.ham.org/ . . . .
I have used MPLAB and an imitation picstatrt programmer
I use OLIMEX development boards and my role out is very quick
I decided to use assembly because it made me think and understand how a PIC works
These days I have a code bank and just copy and paste
Cool hobby tho
----- Original Message ----- From: "John Magliacane" [email protected] To: [email protected] Sent: Friday, October 23, 2009 6:59 AM Subject: [amsat-bb] Re: PIC rotator control
--- On Wed, 10/21/09, Gordon JC Pearce [email protected] wrote:
The PIC microcontrollers are frankly *dreadful*, without a single redeeming feature. What makes me like them even less is that you're forced to use the bloody awful Windows software to program them,
I've used "gpasm" for assembly, and "picprog" for serial port programming, both under Linux, with excellent results.
I generally select the PIC I use in my projects based on the functions I require, and how well it is supported under the assembler and programmer indicated above.
This approach has worked extremely well for my purposes.
73, de John, KD2BD
-- Visit John on the Web at:
http://kd2bd.ham.org/ . . . .
_______________________________________________ Sent via [email protected]. 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
--------------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.25/2450 - Release Date: 10/21/09 16:44:00
On Fri, 2009-10-23 at 08:24 +1000, Andrew Rich wrote:
I have used MPLAB and an imitation picstatrt programmer
I use OLIMEX development boards and my role out is very quick
I decided to use assembly because it made me think and understand how a PIC works
Assembler is the right choice here. PICs are pretty interesting in that they are the only CPU that I've found that's considerably *harder* to write code for in C than assembler.
Gordon MM0YEQ
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: [email protected] [mailto:[email protected]] On Behalf Of Marc Vermeersch Sent: October 13, 2009 6:45 AM To: 'Andrew Rich'; [email protected] 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: [email protected]
[mailto:[email protected]]
On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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 [email protected]. 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
I'd like to suggest that such systems should have a compass input from a GPS too so that as I'm driving mobile, I can have such a rotator strapped in the back of my truck, and be able to have it track the pass so I can hear it, and grab the mic and talk if I need to. I'd also use this for mobile ATV work to keep a beam pointed at our ATV repeater.
Gregg Wonderly W5GGW
Alan VE4YZ wrote:
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: [email protected] [mailto:[email protected]] On Behalf Of Marc Vermeersch Sent: October 13, 2009 6:45 AM To: 'Andrew Rich'; [email protected] 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: [email protected]
[mailto:[email protected]]
On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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 [email protected]. 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 [email protected]. 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
Nice idea Gregg. We do a few near space balloons each year and I have been bugging some other folks ( because I don't write code ) to consider 2 projects:
1 - rotator control in a moving vehicle to keep a small yagi such as an Arrow pointed at the APRS signal.
2 - antenna parking based on data from a home WX station such as those commonly beaconing on APRS systems.
I will copy the 3 of you, Marc, Andrew and Gregg off list with more details.
-----Original Message----- From: Gregg Wonderly [mailto:[email protected]] Sent: October 13, 2009 11:33 AM To: Alan VE4YZ Cc: 'Marc Vermeersch'; 'Andrew Rich'; [email protected] Subject: Re: [amsat-bb] Re: PIC rotator control
I'd like to suggest that such systems should have a compass input from a GPS too so that as I'm driving mobile, I can have such a rotator strapped in the back of my truck, and be able to have it track the pass so I can hear it, and grab the mic and talk if I need to. I'd also use this for mobile ATV work to keep a beam pointed at our ATV repeater.
Gregg Wonderly W5GGW
Alan VE4YZ wrote:
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: [email protected] [mailto:[email protected]] On Behalf Of Marc Vermeersch Sent: October 13, 2009 6:45 AM To: 'Andrew Rich'; [email protected] 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: [email protected]
[mailto:[email protected]]
On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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 [email protected]. 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 [email protected]. 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
Folks
1 - rotator control in a moving vehicle to keep a small yagi such as an Arrow pointed at the APRS signal.
2 - antenna parking based on data from a home WX station such as those commonly beaconing on APRS systems.
FWIW, I did exactly that many moons ago back in 2003 when AO-40 was still with us, although it was more of a working prototype than something you'd want to let all and sundry peruse over.
http://www.g6lvb.com/images/AO40Mobile.jpg
This was based on a GPS feeding into a PC that corrected the co-ordinates in real time and fed them to an LVB Tracker, hooking up to a pan and tilt camera mount.
Since then, in 2005, the LVB Tracker 2 was developed, and that can act autonomously and take in real time GPS parameters for both position and date and time correction, although I must stress that this is not a production strength unit. The LVB Tracker 2 was developed at about the same time as the SDX back in 2005. When I presented separate papers for the Tracker 2 and the SDX at the AMSAT-UK Colloquium, there was a lot of interest in the SDX, but almost none in the Tracker 2, so further development waned I'm afraid. I worked with Gould Smith on it again quite a bit at the beginning of 2008 (see below), but I still don't believe it's really ready for prime time, although should some kind soul come up and offer to spend time developing it further I'd be delighted!
It took a lot of time and effort to get the Tracker 2 to where it is today, more so than the Tracker 1: the Tracker 2 firmware is five times the size of that in the Tracker 1. Back in 2005, there was a real limit on what you could a achieve in a tiny 28 pin device as well as the limitations of compilers at that time. The Tracker 2 certainly took to the extreme what you could achieve with the limited ROM and particularly RAM available at that time on such a device. It reminded me of the days when you used all manner of means to squeeze that last byte out of your memory map.
The Tracker 2 has two redeeming features. Firstly, it can operate as a handheld device with an integrated GPS, but since then the iPhone has come along! Secondly, Tracker 2 will work autonomously. The bad news is that if you run a desktop Tracker 2 based on the original Tracker 1 PCB without a GPS, with there being no RTC clock, you have to reset the date and time manually each time you switched it on, so that's a bit of a drawback unless you leave it on all the time. Even then, we found that the crystals drift the RTC rather too much for our liking. I think if time permitted, redesigning the LVB Tracker 2 hardware with a new PCB from scratch would be preferable, supporting a proper battery backed RTC.
FWIW, I am often asked about the choice of compiler for the LVB Tracker. Some history: the early choice of the BKND compilers for the LVB Tracker was because, way back when, they offered floating point arithmetic for a reasonable price unlike other competitive offerings, although you're heavily restricted as to the complexity of your code, so you have to manually code around those restrictions. Since then, other more heavyweight compilers have come along, in particular Microchip's own offerings for the PIC18 and above. Rewriting the code for those compilers would be 'interesting'(!) for someone with some time on their hands, and some $$$ to purchase the compiler.
But, some good news. Thanks to Gould Smith's good work testing my code back in early 2008, I do have some significantly updated Tracker 2 code since 2005, but please bear in mind this is for experimentation purposes, and current work commitments preclude me from opening this puppy up for now, but please feel free to do so yourself! See below...
18F2620 programming software: http://www.g6lvb.com/Articles/LVBTracker2/PicProg2.exe Hex file: http://www.g6lvb.com/Articles/LVBTracker2/2620test20d.hex Sources: http://www.g6lvb.com/Articles/LVBTracker2/2620test_2_0d_001.zip
By the way, while researching the content here, I came across some interesting LVB Tracker development history shots are here (if you're into that kind of thing):
http://www.g6lvb.com/images/lvbtracker1.JPG http://www.g6lvb.com/images/lvbtracker2.JPG http://www.g6lvb.com/images/lvbtracker3.JPG http://www.g6lvb.com/images/lvbtracker4.JPG http://www.g6lvb.com/images/lvbtracker5.JPG http://www.g6lvb.com/images/lvbtracker6.JPG http://www.g6lvb.com/images/lvbtracker7.JPG
Judging by the number of PCBs that have been made, I believe that there are now in excess of 1,000 LVB Trackers out there, although how many are operational and how many are sitting in pieces waiting for a rainy day I don't know!
73, Howard G6LVB
Thanks
Yes a small 10 inch laptop could do the work, predict would be used and frequent kep updates
The laptop would also make decisions like
If two sats were up, what is the priority
It is a good project because it covers off
1. Mechanical 2. Programming PERL and ASM (PIC) 3. Installing and maintaining sofware essential to the function
----- Original Message ----- From: "Alan VE4YZ" [email protected] To: "'Marc Vermeersch'" [email protected]; "'Andrew Rich'" [email protected]; [email protected] Sent: Wednesday, October 14, 2009 1:35 AM Subject: RE: [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: [email protected] [mailto:[email protected]] On Behalf Of Marc Vermeersch Sent: October 13, 2009 6:45 AM To: 'Andrew Rich'; [email protected] 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: [email protected]
[mailto:[email protected]]
On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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 [email protected]. 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
--------------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date: 10/12/09 13:01:00
On Wed, 2009-10-14 at 07:20 +1000, Andrew Rich wrote:
Thanks
Yes a small 10 inch laptop could do the work, predict would be used and frequent kep updates
I'm looking at using a mini2440 board for just such a thing - ARM9 CPU, masses of GPIO, a couple of serial lines, USB host *and* slave ports, and a 3.5" colour touchscreen ;-)
Gordon MM0YEQ
Sounds nice.
One thing I have to keep an eye on is power being drawn from the USB if I am to use any sort of relays
----- Original Message ----- From: "Gordon JC Pearce" [email protected] To: [email protected] Sent: Wednesday, October 28, 2009 5:45 PM Subject: [amsat-bb] Re: PIC rotator control
On Wed, 2009-10-14 at 07:20 +1000, Andrew Rich wrote:
Thanks
Yes a small 10 inch laptop could do the work, predict would be used and frequent kep updates
I'm looking at using a mini2440 board for just such a thing - ARM9 CPU, masses of GPIO, a couple of serial lines, USB host *and* slave ports, and a 3.5" colour touchscreen ;-)
Gordon MM0YEQ
Sent via [email protected]. 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
--------------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.34/2463 - Release Date: 10/27/09 15:50:00
Hi Guys, anybody looked at http://www.mikroe.com/ for building your controlled prototype.
I use this board for many project.... excellent kit and also excellent support.
73
J-F VA2SS
2009/10/28 Gordon JC Pearce [email protected]
On Wed, 2009-10-14 at 07:20 +1000, Andrew Rich wrote:
Thanks
Yes a small 10 inch laptop could do the work, predict would be used and frequent kep updates
I'm looking at using a mini2440 board for just such a thing - ARM9 CPU, masses of GPIO, a couple of serial lines, USB host *and* slave ports, and a 3.5" colour touchscreen ;-)
Gordon MM0YEQ
Sent via [email protected]. 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
Very expensive and complete overkill
----- Original Message ----- From: "Jean-François Ménard" [email protected] To: "Gordon JC Pearce" [email protected] Cc: [email protected] Sent: Wednesday, October 28, 2009 9:51 PM Subject: [amsat-bb] Re: PIC rotator control
Hi Guys, anybody looked at http://www.mikroe.com/ for building your controlled prototype.
I use this board for many project.... excellent kit and also excellent support.
73
J-F VA2SS
2009/10/28 Gordon JC Pearce [email protected]
On Wed, 2009-10-14 at 07:20 +1000, Andrew Rich wrote:
Thanks
Yes a small 10 inch laptop could do the work, predict would be used and frequent kep updates
I'm looking at using a mini2440 board for just such a thing - ARM9 CPU, masses of GPIO, a couple of serial lines, USB host *and* slave ports, and a 3.5" colour touchscreen ;-)
Gordon MM0YEQ
Sent via [email protected]. 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
It is a prototype board for many project... An exellent learning tool !!
2009/10/28, Andrew Rich [email protected]:
Very expensive and complete overkill
----- Original Message ----- From: "Jean-François Ménard" [email protected] To: "Gordon JC Pearce" [email protected] Cc: [email protected] Sent: Wednesday, October 28, 2009 9:51 PM Subject: [amsat-bb] Re: PIC rotator control
Hi Guys, anybody looked at http://www.mikroe.com/ for building your controlled prototype.
I use this board for many project.... excellent kit and also excellent support.
73
J-F VA2SS
2009/10/28 Gordon JC Pearce [email protected]
On Wed, 2009-10-14 at 07:20 +1000, Andrew Rich wrote:
Thanks
Yes a small 10 inch laptop could do the work, predict would be used and frequent kep updates
I'm looking at using a mini2440 board for just such a thing - ARM9 CPU, masses of GPIO, a couple of serial lines, USB host *and* slave ports, and a 3.5" colour touchscreen ;-)
Gordon MM0YEQ
Sent via [email protected]. 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
-- Jean-François Ménard VA2SS
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= AMSAT www.amsat.org / Member #37102 ARRL www.arrl.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sent via [email protected]. 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
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.34/2463 - Release Date: 10/27/09 15:50:00
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: [email protected] To: [email protected]; [email protected]; [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Marc Vermeersch Sent: October 13, 2009 6:45 AM To: 'Andrew Rich'; [email protected] 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: [email protected]
[mailto:[email protected]]
On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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 [email protected]. 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 [email protected]. 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/
Hi Alan,
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.
My setup is NOT using the rotator control box; it drives the rotator directly.
- Eventually I want to run a tracking algorithm in the PIC too
In the future I plan to run a tracking algorithm on the embedded processor to become independent from the PC.
That would result in a autonomous box for on-the-road activity. Add a GPS and a compass and you can install it on a truck.
I'm currently also experimenting with solid state AZ/EL measurement. Final goal is to stick a small box on the handle of an arrow antenna and get Up/Down and Left/Right indication by LED's.
BR, -- //\arc
-----Original Message----- From: Alan VE4YZ [mailto:[email protected]] Sent: dinsdag 13 oktober 2009 17:35 To: 'Marc Vermeersch'; 'Andrew Rich'; [email protected] Subject: RE: [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: [email protected] [mailto:[email protected]] On Behalf Of Marc Vermeersch Sent: October 13, 2009 6:45 AM To: 'Andrew Rich'; [email protected] 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: [email protected]
[mailto:[email protected]]
On Behalf Of Andrew Rich Sent: dinsdag 13 oktober 2009 12:22 To: [email protected] 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 [email protected]. 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 [email protected]. 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
participants (11)
-
Alan VE4YZ -
Andrew Rich -
Gordon JC Pearce -
Greg D. -
Gregg Wonderly -
Howard Long -
Jean-François Ménard -
John Magliacane -
Marc Vermeersch -
Phil -
Stefano Simonetti