approximately 1.5 to 2.0 ms with a period of 28 ms or about 51
Microcontrollers don't understand approximately or about.
Since the original system operated at 4.0 mega Hz I figure there is a reason like the number of instructions per second. When I tried arduino I could not get a slow enough speed on the motors...
As I've told you a couple of times, the Propeller is a different beast. One of its [many] fantastic features is timing via the CNT register, which means we don't have to count program cycles, and timing requirements can be independent of the system clock. The Propeller was designed to be different from standard micro architectures -- this is one of those differences that I really like best.
(6) the buttons are not contiguous because on the first Flip that was used I had a problem with pin # 6.
Then select a different set of pins -- don't penalize yourself on the programming end with weird IO. Don't allow yourself to say, "I'll fix it in code."
I saw no need for the Tx group since there is no two way comm.
You don't have to use all features of any object -- we rarely do. But blindly using copy-and-paste doesn't work, either. What you didn't understand in your bludgeoning of FDS is that you neglected to copy the actual serial engine. Lesson: Don't rip up working object code -- write a new object if you have to (e.g., I have an RX-only serial object and a TX-only serial object, but rarely use either). Again, it doesn't hurt to use FDS in receive-only mode. You can -- and usually should -- have a second copy of FDS running so that you can do debugging to a terminal during program development. By using the same object you only duplicate the variables; only one copy of the object's interface code is in memory.
I have little program experience. I am also 71 years old.
No experience, no problem -- unless you continue to refuse to provide good information (it's still lacking). That you're 71 only means that you still want to learn which is a good thing. Your age (which is not old) is not a license to be obstinate. You've been getting solid advice in the forums for a long time but refuse to accept it.
Back to the details...
You say that with no buttons pressed there is a pulse (need exact width and period), but you don't say which output gets that pulse. Why is there a pulse anywhere when NO buttons are pressed?
What does "75% pulse" mean to you? Is this 75% duty cycle?
The two flip programs each work well but the problem stems from the communication between the two devises. We tried to use the prop.c fdserial but couldn't get to work. Question is will the two fdserials work together.
Yes. I have done it hundreds of times. Have you ever used PST (Parallax Serial Terminal) for debugging? If yes, you were using serial. In fact, if your mysterious serial messages are simple (e.g., direction letters), you can test you remote device using PST. I do this all the time with Propeller projects that will end up using text commands over Bluetooth. When the code is wrung out, I change the pins from the terminal output to the Bluetooth radio.
And why in the world do you refuse answer questions that could help you get your project working with reliable code?
my guess why serial comm's are not working is the unusual clock frequence.
Most Propeller Objects default to 80Mhz, some adjust by them self, others use hard coded values you would need to adapt.
As Jon stated the goal of objects in Spin is to use them as is, not to rip them apart. Think of them as ready made building blocks with the intention to be plugged together like Lego blocks.
Need serial, plug in some serial object, need I2C plug in a I2C object, need TV plug in a TV object...
In the PropTool there are two folders, Library and Demos. (Accessible in the Dropdown on the left side). Usually the Demo Folder contains a small Example how to use the Library Object.
There are some common practices, so most objects have a start and stop method, some (like FullDuplexSerial) will start a PASM driver in a different COG.
In the Arduino World you have Hardware for I2C, serial, SPI whatever, but depending on your needs you might need different Versions of the Arduino's, say one HW serial else you need Softserial, sometimes the Hardware shares Pins, so you can either have SPI or yo can have whatever, CAN bus.
In the Propeller World things are different. besides Counters and some TV related HW everything else is done by Software loaded drivers (objects). So you are not bound to "this chip has two UARTS, one I2C, 3 SPI if you need something else buy another version".
On the same FLIP module you have you could do say 12 UARTS and TV composite, or 6 SPI and so forth.
So every pin can basically be used by any COG (aka driver aka object) with some restriction because there is a EEPROM on pins 28/29 and usually a FDTI USB on 30/31.
What I would do is to basically start from the scratch by using the USB from the FLIP's as DEBUG output. Just USE FullDuplexSerial (or Jon's Version) with standard settings at 80Mhz on pins 30/31.
Now you can simply print stuff out to see what your programs are doing.
Use a second FullDuplexSerial Object on different pins for Flip2Flip comms.
Bbrien, thanks for taking the time to restate your requirements. I (and others) understand the problem a little better now.
I have done some googling to broaden my knowledge, and below is my understanding of your problem;
1) You have a Meade LX50 telescope. Your photos are a little confusing because it is partially dismantled. Photos below are of a perfect LX50 telescope presented for sale.
2) The Meade LX50 telescope comes with a simple Handbox which connects to the Handbox socket of the control panel. Handbox photo below.
3) You wish to emulate the Handbox using the Prop. This seems very possible as this post from an internet telescope forum suggests;
The LX50 is quite usable without a Hand Control by simply powering on for RA tracking and then using the slow motion knobs on the mount to tweak position. The original Hand Control was a very simple device. It was little more than a keypad that is scanned by a simple micro-controller which in turn sends an encoded command data stream to the microprocessor in the base unit. It only served to perform slow motion adjustments to the base tracking rate of the mount. I would hazard a guess that somewhere someone has designed a replacement DIY based off of two Arduino (or similar) boards to perform the function of the Hand Control and base motor drive electronics. While I have not seen such a project, a deep search of the net might turn up something
4) Browsing the internet, I became confused between Handbox and Computer control of the telescope, then I realized it was beyond your scope. For Computer control you obtain a computer package like Magellan, which then connects to the Handbox connector. You also need the encoders connected to their socket on the control panel. A post on Computer control from an internet forum; Meade never intended the Magellan I to be used on the LX50; the Magellan II was to be the thing, since, as I mentioned, it would offer Semi-goto. Unfortunately, they never quite got the firmware in the LX50 (required) correct, so it didn't work right--well, I recall that the last of the LX50s finally cured the incompatibility problems. The LX50 Magellan connections are normally as follows: There is an RJ45 to RJ45 (8 pin / 8 wire) encoder cable that connects from the socket on the fork arm to the Encoders socket on the control panel. The Magellan connects in place of the normal handset to the Handbox socket on the control panel using an RJ22 (4 pin / 4 wire). There is an optional RJ12 (6 pin / 6 wire) socket on the Magellan Handbox that can be used to connect to a computer via RS232. Normally, you would connect the encoder cable from the fork arm to the control panel and then simply plug in the Magellan's RJ22 to the Handbox socket on the control panel. That's all that is required.
5) Back to emulating the Handbox using the Prop. This should be quite easy. All we need is the pinout of the Handbox cable and the Handbox protocol. You have provided some information; (1) if no buttons are pushed their should be only a pulse of approximately 1.5 to 2.0 ms with a period of 28 ms or about 51 Hz. Since the original system operated at 4.0 mega Hz I figure there is a reason like the number of instructions per second. When I tried arduino I could not get a slow enough speed on the motors , and if I used less than 22/255 the motors would not turn. the speed of the processor might be too fast. Using the flip at 5MHz I am able to get about 1.8 ms. I also wrote in prop.C and the input to the second Flip showed a very quick set of pulses but not continuous.
(2) When the 'N' button is pressed the M2_NS output should read a pulse of 75% and the M2_Dir output should be a HIGH. (3) When the 'E' button is pressed the M1_EW output should show a pulse of 75% and the M1_Dir output should be High.(4) When the 'S' button is pressed, the M2_NS output puts out the 75% pulse and the M2_Dir output sends a Low. (5) When the 'W' button is pressed the M1_EW output sends out a 75% pulse and theM1_Dir output sends a Low.
6) That is the limit of my knowledge. It seems to me the protocol is very similar to RC model servos PWM of 50Hz with pulse widths of 1 – 2 mS. (I stated this in one of the early posts)– I cannot find any LX50 Handbox pinouts or protocol details on the internet. I attach data I did find on the internet. Your SCH documents attached on a previous post might help. Please can you reformate them on pdf because I cannot read them.
More research on telescope internet forums has uncovered the LX50 control box schematic and LX50 operating manaual for control panel and handbox.
Now can anyone come up with the LX50 handbox protocol?
Well that throws a bit of light on things. The pin out of the hand controller won't do much good unless someone out there in prop land has a hand controller and is willing to attempt to capture the stream for each button press. Now, where does the information regarding the pulse rates etc. come from? The only reason I can think of for seeing any activity on the signal pins of the controller connector when no buttons are pressed would be either a keep-alive/I'm connected or the main PIC polling for or to reporting changes in the hand controller. Pressing buttons probably results in a single pulse train followed by a delay and then either the same again or a repeat code in the manner of an IR remote controller. Do you have the original controller and is it live or dead? If it is live, can you capture the pulse train for each single and held button press?
As to PWM, I may be wrong, but this does not look like the method of servo control the way RC servos work. Rather, it appears that the PWM method is being used to move the motors at the various speeds that the telescope requires (as laid out in the user doc). Curiously, the makers appear unconcerned with Dec motor movements since there is no feedback from it. Not being into telescopes, maybe Dec direction is not as important as RA. On the RA axis, there is if I understand the diagram correctly, an encoder of sorts, but it only sends a pulse back to count and the since the PIC should know which direction it wanted to go, a quadrature encoder was overkill and not used. But RA is still more controlled than the Dec axis. Apparently there was an option to mount (implying they do not currently exist in the scope) a set of encoders, likely quadrature encoders for both RA and Dec movements for fine control by a device (Magellan II). The logic and code for this is likely already built into the PIC, but only accessible if you paid for that option. Hey, just like medical devices!
Given the above conjecture, what is dead or alive? Or maybe what functions work and what does not? Guess this would be where your requirements start. Do you need to reinvent the whole system, or only the hand controller? Do you need to make it look the same, that is two controller and brain box as exist or can you make a single box with the controls on it and power in and a cable out to the scope with motor drive and (if any) encoders?
I don't know if this was the instructible https://instructables.com/id/Control-Your-Telescope-Using-Stellarium-Arduino/ that made you chose to try the arduino first or not, but if you master the prop, you will likely be able to get better performance. If this was the article that made your motors too fast or what, you needed to understand how to set timing and delays as Jon presented. Possibly this is hidden in the guts of arduino, don't know. Have a couple, never got much urge to do much with them. Prop is fully transparent. What you write is what you get provided your logic is correct. You are not dependent on anybodys hidden code.
But the question really comes down to what do you want to do? Write your requirements from there. Then break it down into small parts, each defining a small function or part of a larger function needed to meet the goals set out in your requirements specification. Without this map you will be right where you have been for quite some time. Plan first code last or you will waste lots of time coming up with code that will not be used or not advance the project as you would expect costing more time in rewrites and more testing. Coding on the fly is great when just experimenting with a function or two, coming up with ways to talk to a chip, etc. but for a useful project, better plan it first. Just a minor digression...........
This document details a serial protocol, but I don't know if it's compatible with the LX50. The section called Telescope Motion seems to have commands that would be employed by the the hand controller.
It would be fun to have access to a working unit to reverse-engineer the protocol between the hand unit and telescope.
There is very patchy information on these telescope controllers.
bbrien talks a lot about 50/60Hz signals with varying pulsewidth for control from for the LX50 handbox.
However, the the L200 handbox interface seems to be fully serial.
The only good information I can find is for a LX3 handbox, which is a really old telescope, as attached below.
The circuit shows a 60Hz 555 based circuit, with buttons and speed control. I suspect this is similar to RC servo control.
Maybe the LX50 handbox is a hybrid, somewhere between LX3 and LX200. It might use the 60Hz pulse method for speed control, but the operating manual suggests it may also have some sort of serial interface.
Unless we can get the specific circuit and protocol for the LX50 we cannot really progress this further.
Here is my current program that I am using for the hand controller. It seams to work with the Flip. The mode Pin creates four different pulses and lights one of four leds to indicate the speed. What I am trying to do here is , in the slave or the mount board is (1) setup a test to see if there is a pulse on the serial input and if so turn off cog 0 and send the serial to the individual output pins and when no pulses are detected restart cog0. Of course that means the serial will be in cog1. In cog 0 we will read the camera inputs and if they are not active then we output a pulse of about 1.5 to 2.0 ms in length to the R.A. motor(M1_EW). If any of the camera control pin (N, E, W, S) are active then a set of signals will be sent to the output pins(M1_EW, M1_Dir, M2_NS, M2_Dir). I hope this helps some. Also there are no hand controllers available and I never had one, A used devise when purchased.
The four switches from the guide camera only operate for a matter of a few milli seconds when they are in operation. They only operate when the target star moves from one pixel to a nearby pixel. usually one direction at a time. I use both counters just in case two happen to move at the same time.
....In cog 0 we will read the camera inputs and if they are not active then we output a pulse of about 1.5 to 2.0 ms in length to the R.A. motor(M1_EW). If any of the camera control pin (N, E, W, S) are active then a set of signals will be sent to the output pins(M1_EW, M1_Dir, M2_NS, M2_Dir). I hope this helps some. ...
Not a servo system but a small dc clock motor attached to a gear box consisting of a worm gear and a ring gear.
Maybe the heading needs to change, as this is not PWM in the normal sense, but a single direction clock stepper motor driver.
It's a bit unclear just what the camera outputs, and how that is initially set up ? - does the camera include the pixel decode, and gives 'clean contact' type switching outputs ?
I would expect a Telescope Tracking system to need a carefully calculated pulse rate, that would depend on where it was pointing.
Ideally, no corrections would be needed, but it sounds like the camera can give fix-up requests in an imperfect system.
Less clear is how "only operate for a matter of a few milli seconds when they are in operation" can be used as a correction - do you have a scope capture of those inputs, and required output waveforms.
I could imagine a smarter Prop based system that used the camera pixel-offset signals to calculate a steps-per-pixel rate, for that sky location.
The Prop could then use that, to give a better fit track system. ie it could effectively learn what the average step rates needed were, and reduce the physical jitter as a result.
Please, could you confirm that, when the telescope is fully assembled and operational, there is a single brushless DC stepper motor, that connects to the controller board (very unlikely, I presume) or, (a little more "logically") TWO plain brushed DC motors, with (108-slit?) stainles-steel discs, attached to their axles?
I'm asking the above because of something I'd found, by querying Google with the following:
"UDN2993B" AND "Meade"
Only eight results, in four idioms (if I'm not wrong), but a lot of good information.
There are two motors on the LX50 unit that are basic motors as stated. By PWM we are using variable length pulses to energize the motors so they rotate in a given direction at a given speed. He wants to replace the control hardware to the motors with some no longer available UDN2993B chips that he has laying around. In any case they are like all the current FET drive units out there and should work to drive the motors.
The guide camera or an external unit that plugs into the LX50 is a unit that can control these motors so that if you want to take pictures of what the telescope is looking at or position the scope more accurately. The guide camera using a laptop computer and and a camera attached to the scope to send pulses to the motors through a interface designed to move the telescope. The guide camera interface uses opto isolated interface so that there is no feed back of power to it. The telescope motors run at 18 volts.
Since He wants to replace the hardware that drives the motors he has to build both the Guide camera interface and the user remote interface to the motors.
So far the issue left was being able to send serial data from the Guide camera FLIP interface to the base FLIP interface to pulse these motors. Don't know why serial does not work other than it is wired incorrectly such and not providing a common ground in the cable he is using to send the serial data over. The cable is 2 meters in length.
One other problem is that at low pulses these motors do not turn. This could be just a problem of mass. To get the motors to start to move you may have to send longer pulses to get the motors started and then reduce the pulse to get that smooth movement that is need to position the telescope. Don't know, never worked with a telescope.
The other issue seems to be that he thinks that an Arduino processor is to fast and is not able to produce a PWM pulse long enough to move the motors at a low rate. As far as I know PWM has nothing to do with processor speed and is just a duty cycle applied to the motors.
It also seem that there are a lot of SPIN people that are following this and more history can be gained by looking at this thread flip and propeller c language which has working C code in it. It also has a pictures of the scope and of the FLIP chips wired up on a bread board attached to some test motors.
Dual brushed dc motors with gear boxes and the voltage is 9.0 dc. Next question is will the fdserial .C talk with fdserial.spin . The program for the hand controller is working like I want. I will look into using the single cog setup.
I found an object (I think) for 'Full Duplex Serial' in a project called "Home Automation".Do I call the object and uuse complete or can I break it and use only the parts that I need and do I need Two of the same objects to read the pins for the serial from the hand controller and display the input data. I shall include the object files.
You cannot do this. FDS requires a PASM cog to create the UART. The Spin interpreter for the foreground code requires its own cog. If ..you're going to do traditional PWM, it would be best to do it in its own cog, too. Yes, I've demonstrated that it can be done in one cog (sans serial), but that was unnecessarily difficult and caused by your ignorance of how microcontrollers, the Propeller in particular, operate.
Break the object up? That would be like asking to cut off pins or perform laser surgery on a uart to eliminate unneeded functions. It takes one cog no matter the functions it uses. The object has all the functions; you need to examine the object to know which one and how to call a function of the object for an action you require.
You have EIGHT individual cogs/processors inside the Prop. Use them up. No sense sparing them, no real savings in your application. Spin takes the first cog (0). Use one for comms, one for each motor, and you still have 4 cogs left for other features/goodies you may think up like position readout, battery monitoring, time, etc., provided you take the time to really master the prop chip. Start with the chapters 4-6 in the prop ed manual and do/build the exercises at the end of each chapter. Stop doing for a bit and go back to learning. Then you will be able to roll your own objects or modify others to your purposes without reinventing the wheel.
As to "finding the Full Duplex Serial object", why were you still searching for it. Jon gave you an entire project framework including an enhanced version of this likely same object you just found. But again, using that will require knowing how to program the prop to be able to effectively Jon's (or anyone's) framework or objects.
(Just my heretical viewpoint, I see no need to use C on the Prop1)
If I use a second cog , I have to stop the main cog to use the outputs and restart the main cog.
This statement is false. When it comes to the Propeller, you are still very much in the dark -- despite all the light being cast your direction from fellow forum members....
BTW... that C program that you claim works? It's using at least two cogs, one of them for the fdserial driver, the other for your control code.
Whoa,
This thread is really driving me crazy.
Thanks to this explanation from iseries, I may (and I suspect many others) may totally misunderstood what is going on here;
"Let me inject some history here.
There are two motors on the LX50 unit that are basic motors as stated. By PWM we are using variable length pulses to energize the motors so they rotate in a given direction at a given speed. He wants to replace the control hardware to the motors with some no longer available UDN2993B chips that he has laying around. In any case they are like all the current FET drive units out there and should work to drive the motors."
I had assumed bbrien was trying to emulate the LX50 handbox protocol through the existing LX50 control panel.
If iseries is correct then bbrien is actually bypassing the entire LX50 control panel altogether and driving the two motors directly using an old UDN2993B H bridge chip.
If this is true then this problem is ridiculously simple. There are many examples and code around for robots with a H bridge driving two motors bi-directionally.
The LX50 control schematic (attached) indicates the motors are simple brushed motors, so any H bridge should do. I would use a cheap modern H bridge module as used in so many robots.
If this is true then this problem is ridiculously simple. There are many examples and code around for robots with a H bridge driving two motors bi-directionally.
No kidding. I've demonstrated this more than once. The OP's obstinate behavior is what's preventing this should-be simple project from being concluded.
I set up the "Telescope controller.spin in slave Flip and am testing. I want to increase the duty cycle to about 80%
. what lines do I need to change to achieve this and the same goes for the period.
I succeeded in resetting the period and pulse width but I need to have a fifth option on the nav switch(case) of about 1500 to 2000 us. I tried adding a statement called track but nothing happened . I need the motor to turn (about 1.5 ms) when none of the nav switches are pressed.
Looking at the original schematic it's based on the PIC16C57 (older pic) I think the BS2(PIC16F57) would be a good replacement and use pbasic or assy. Why reinvent the wheel.
Just out of curiosity, are there any label plates on the motors? if so, can you post a picture of the same? Including any gear information if on an different label.
no labels available all data owned by meade as far as I know. How about a default statement for the case statements.
Also what does "longfill (@nspulse, STOP, 2)" mean and doe's.
Comments
As I've told you a couple of times, the Propeller is a different beast. One of its [many] fantastic features is timing via the CNT register, which means we don't have to count program cycles, and timing requirements can be independent of the system clock. The Propeller was designed to be different from standard micro architectures -- this is one of those differences that I really like best.
Then select a different set of pins -- don't penalize yourself on the programming end with weird IO. Don't allow yourself to say, "I'll fix it in code."
You don't have to use all features of any object -- we rarely do. But blindly using copy-and-paste doesn't work, either. What you didn't understand in your bludgeoning of FDS is that you neglected to copy the actual serial engine. Lesson: Don't rip up working object code -- write a new object if you have to (e.g., I have an RX-only serial object and a TX-only serial object, but rarely use either). Again, it doesn't hurt to use FDS in receive-only mode. You can -- and usually should -- have a second copy of FDS running so that you can do debugging to a terminal during program development. By using the same object you only duplicate the variables; only one copy of the object's interface code is in memory.
No experience, no problem -- unless you continue to refuse to provide good information (it's still lacking). That you're 71 only means that you still want to learn which is a good thing. Your age (which is not old) is not a license to be obstinate. You've been getting solid advice in the forums for a long time but refuse to accept it.
Back to the details...
You say that with no buttons pressed there is a pulse (need exact width and period), but you don't say which output gets that pulse. Why is there a pulse anywhere when NO buttons are pressed?
What does "75% pulse" mean to you? Is this 75% duty cycle?
Yes. I have done it hundreds of times. Have you ever used PST (Parallax Serial Terminal) for debugging? If yes, you were using serial. In fact, if your mysterious serial messages are simple (e.g., direction letters), you can test you remote device using PST. I do this all the time with Propeller projects that will end up using text commands over Bluetooth. When the code is wrung out, I change the pins from the terminal output to the Bluetooth radio.
And why in the world do you refuse answer questions that could help you get your project working with reliable code?
Most Propeller Objects default to 80Mhz, some adjust by them self, others use hard coded values you would need to adapt.
As Jon stated the goal of objects in Spin is to use them as is, not to rip them apart. Think of them as ready made building blocks with the intention to be plugged together like Lego blocks.
Need serial, plug in some serial object, need I2C plug in a I2C object, need TV plug in a TV object...
In the PropTool there are two folders, Library and Demos. (Accessible in the Dropdown on the left side). Usually the Demo Folder contains a small Example how to use the Library Object.
There are some common practices, so most objects have a start and stop method, some (like FullDuplexSerial) will start a PASM driver in a different COG.
In the Arduino World you have Hardware for I2C, serial, SPI whatever, but depending on your needs you might need different Versions of the Arduino's, say one HW serial else you need Softserial, sometimes the Hardware shares Pins, so you can either have SPI or yo can have whatever, CAN bus.
In the Propeller World things are different. besides Counters and some TV related HW everything else is done by Software loaded drivers (objects). So you are not bound to "this chip has two UARTS, one I2C, 3 SPI if you need something else buy another version".
On the same FLIP module you have you could do say 12 UARTS and TV composite, or 6 SPI and so forth.
So every pin can basically be used by any COG (aka driver aka object) with some restriction because there is a EEPROM on pins 28/29 and usually a FDTI USB on 30/31.
What I would do is to basically start from the scratch by using the USB from the FLIP's as DEBUG output. Just USE FullDuplexSerial (or Jon's Version) with standard settings at 80Mhz on pins 30/31.
Now you can simply print stuff out to see what your programs are doing.
Use a second FullDuplexSerial Object on different pins for Flip2Flip comms.
my 2 cents,
Mike
I have done some googling to broaden my knowledge, and below is my understanding of your problem;
1) You have a Meade LX50 telescope. Your photos are a little confusing because it is partially dismantled. Photos below are of a perfect LX50 telescope presented for sale.
2) The Meade LX50 telescope comes with a simple Handbox which connects to the Handbox socket of the control panel. Handbox photo below.
3) You wish to emulate the Handbox using the Prop. This seems very possible as this post from an internet telescope forum suggests;
The LX50 is quite usable without a Hand Control by simply powering on for RA tracking and then using the slow motion knobs on the mount to tweak position. The original Hand Control was a very simple device. It was little more than a keypad that is scanned by a simple micro-controller which in turn sends an encoded command data stream to the microprocessor in the base unit. It only served to perform slow motion adjustments to the base tracking rate of the mount. I would hazard a guess that somewhere someone has designed a replacement DIY based off of two Arduino (or similar) boards to perform the function of the Hand Control and base motor drive electronics. While I have not seen such a project, a deep search of the net might turn up something
4) Browsing the internet, I became confused between Handbox and Computer control of the telescope, then I realized it was beyond your scope. For Computer control you obtain a computer package like Magellan, which then connects to the Handbox connector. You also need the encoders connected to their socket on the control panel. A post on Computer control from an internet forum; Meade never intended the Magellan I to be used on the LX50; the Magellan II was to be the thing, since, as I mentioned, it would offer Semi-goto. Unfortunately, they never quite got the firmware in the LX50 (required) correct, so it didn't work right--well, I recall that the last of the LX50s finally cured the incompatibility problems. The LX50 Magellan connections are normally as follows: There is an RJ45 to RJ45 (8 pin / 8 wire) encoder cable that connects from the socket on the fork arm to the Encoders socket on the control panel. The Magellan connects in place of the normal handset to the Handbox socket on the control panel using an RJ22 (4 pin / 4 wire). There is an optional RJ12 (6 pin / 6 wire) socket on the Magellan Handbox that can be used to connect to a computer via RS232. Normally, you would connect the encoder cable from the fork arm to the control panel and then simply plug in the Magellan's RJ22 to the Handbox socket on the control panel. That's all that is required.
5) Back to emulating the Handbox using the Prop. This should be quite easy. All we need is the pinout of the Handbox cable and the Handbox protocol. You have provided some information; (1) if no buttons are pushed their should be only a pulse of approximately 1.5 to 2.0 ms with a period of 28 ms or about 51 Hz. Since the original system operated at 4.0 mega Hz I figure there is a reason like the number of instructions per second. When I tried arduino I could not get a slow enough speed on the motors , and if I used less than 22/255 the motors would not turn. the speed of the processor might be too fast. Using the flip at 5MHz I am able to get about 1.8 ms. I also wrote in prop.C and the input to the second Flip showed a very quick set of pulses but not continuous.
(2) When the 'N' button is pressed the M2_NS output should read a pulse of 75% and the M2_Dir output should be a HIGH. (3) When the 'E' button is pressed the M1_EW output should show a pulse of 75% and the M1_Dir output should be High.(4) When the 'S' button is pressed, the M2_NS output puts out the 75% pulse and the M2_Dir output sends a Low. (5) When the 'W' button is pressed the M1_EW output sends out a 75% pulse and theM1_Dir output sends a Low.
6) That is the limit of my knowledge. It seems to me the protocol is very similar to RC model servos PWM of 50Hz with pulse widths of 1 – 2 mS. (I stated this in one of the early posts)– I cannot find any LX50 Handbox pinouts or protocol details on the internet. I attach data I did find on the internet. Your SCH documents attached on a previous post might help. Please can you reformate them on pdf because I cannot read them.
Now can anyone come up with the LX50 handbox protocol?
As to PWM, I may be wrong, but this does not look like the method of servo control the way RC servos work. Rather, it appears that the PWM method is being used to move the motors at the various speeds that the telescope requires (as laid out in the user doc). Curiously, the makers appear unconcerned with Dec motor movements since there is no feedback from it. Not being into telescopes, maybe Dec direction is not as important as RA. On the RA axis, there is if I understand the diagram correctly, an encoder of sorts, but it only sends a pulse back to count and the since the PIC should know which direction it wanted to go, a quadrature encoder was overkill and not used. But RA is still more controlled than the Dec axis. Apparently there was an option to mount (implying they do not currently exist in the scope) a set of encoders, likely quadrature encoders for both RA and Dec movements for fine control by a device (Magellan II). The logic and code for this is likely already built into the PIC, but only accessible if you paid for that option. Hey, just like medical devices!
Given the above conjecture, what is dead or alive? Or maybe what functions work and what does not? Guess this would be where your requirements start. Do you need to reinvent the whole system, or only the hand controller? Do you need to make it look the same, that is two controller and brain box as exist or can you make a single box with the controls on it and power in and a cable out to the scope with motor drive and (if any) encoders?
I don't know if this was the instructible https://instructables.com/id/Control-Your-Telescope-Using-Stellarium-Arduino/ that made you chose to try the arduino first or not, but if you master the prop, you will likely be able to get better performance. If this was the article that made your motors too fast or what, you needed to understand how to set timing and delays as Jon presented. Possibly this is hidden in the guts of arduino, don't know. Have a couple, never got much urge to do much with them. Prop is fully transparent. What you write is what you get provided your logic is correct. You are not dependent on anybodys hidden code.
But the question really comes down to what do you want to do? Write your requirements from there. Then break it down into small parts, each defining a small function or part of a larger function needed to meet the goals set out in your requirements specification. Without this map you will be right where you have been for quite some time. Plan first code last or you will waste lots of time coming up with code that will not be used or not advance the project as you would expect costing more time in rewrites and more testing. Coding on the fly is great when just experimenting with a function or two, coming up with ways to talk to a chip, etc. but for a useful project, better plan it first. Just a minor digression...........
This document details a serial protocol, but I don't know if it's compatible with the LX50. The section called Telescope Motion seems to have commands that would be employed by the the hand controller.
It would be fun to have access to a working unit to reverse-engineer the protocol between the hand unit and telescope.
bbrien talks a lot about 50/60Hz signals with varying pulsewidth for control from for the LX50 handbox.
However, the the L200 handbox interface seems to be fully serial.
The only good information I can find is for a LX3 handbox, which is a really old telescope, as attached below.
The circuit shows a 60Hz 555 based circuit, with buttons and speed control. I suspect this is similar to RC servo control.
Maybe the LX50 handbox is a hybrid, somewhere between LX3 and LX200. It might use the 60Hz pulse method for speed control, but the operating manual suggests it may also have some sort of serial interface.
Unless we can get the specific circuit and protocol for the LX50 we cannot really progress this further.
And this one for the autoguider input plug.... https://astro.caltech.edu/~lah/ay105/pdf/expt_ccd2_Pictorspecs
Usually you run your main program in COG0 and the objects you use get loaded once at startup and may or may not need another COG.
I know getting used to parallel processing is mind bending, because you have to unlearn practices you are used to on single processor systems.
Just run a main loop in COG0
and check for serial input.
if found send your pulses
and return to the top of your loop
no need to restart any COG.
Enjoy!
Mike
Maybe the heading needs to change, as this is not PWM in the normal sense, but a single direction clock stepper motor driver.
It's a bit unclear just what the camera outputs, and how that is initially set up ? - does the camera include the pixel decode, and gives 'clean contact' type switching outputs ?
I would expect a Telescope Tracking system to need a carefully calculated pulse rate, that would depend on where it was pointing.
Ideally, no corrections would be needed, but it sounds like the camera can give fix-up requests in an imperfect system.
Less clear is how "only operate for a matter of a few milli seconds when they are in operation" can be used as a correction - do you have a scope capture of those inputs, and required output waveforms.
I could imagine a smarter Prop based system that used the camera pixel-offset signals to calculate a steps-per-pixel rate, for that sky location.
The Prop could then use that, to give a better fit track system. ie it could effectively learn what the average step rates needed were, and reduce the physical jitter as a result.
Please, could you confirm that, when the telescope is fully assembled and operational, there is a single brushless DC stepper motor, that connects to the controller board (very unlikely, I presume) or, (a little more "logically") TWO plain brushed DC motors, with (108-slit?) stainles-steel discs, attached to their axles?
I'm asking the above because of something I'd found, by querying Google with the following:
"UDN2993B" AND "Meade"
Only eight results, in four idioms (if I'm not wrong), but a lot of good information.
Hint: please, check (and save) "http://jlv.duhamel.free.fr/lx50/lx50pec_.htm" first; perhaps it'll not last much longer...
Hope it helps a bit
Henrique
P.S.:jlv.duhamel.free.fr/index.htm
P.S. II:"UDN2993B" AND "astronomy" also provides lots of useful information.
There are two motors on the LX50 unit that are basic motors as stated. By PWM we are using variable length pulses to energize the motors so they rotate in a given direction at a given speed. He wants to replace the control hardware to the motors with some no longer available UDN2993B chips that he has laying around. In any case they are like all the current FET drive units out there and should work to drive the motors.
The guide camera or an external unit that plugs into the LX50 is a unit that can control these motors so that if you want to take pictures of what the telescope is looking at or position the scope more accurately. The guide camera using a laptop computer and and a camera attached to the scope to send pulses to the motors through a interface designed to move the telescope. The guide camera interface uses opto isolated interface so that there is no feed back of power to it. The telescope motors run at 18 volts.
Since He wants to replace the hardware that drives the motors he has to build both the Guide camera interface and the user remote interface to the motors.
So far the issue left was being able to send serial data from the Guide camera FLIP interface to the base FLIP interface to pulse these motors. Don't know why serial does not work other than it is wired incorrectly such and not providing a common ground in the cable he is using to send the serial data over. The cable is 2 meters in length.
One other problem is that at low pulses these motors do not turn. This could be just a problem of mass. To get the motors to start to move you may have to send longer pulses to get the motors started and then reduce the pulse to get that smooth movement that is need to position the telescope. Don't know, never worked with a telescope.
The other issue seems to be that he thinks that an Arduino processor is to fast and is not able to produce a PWM pulse long enough to move the motors at a low rate. As far as I know PWM has nothing to do with processor speed and is just a duty cycle applied to the motors.
It also seem that there are a lot of SPIN people that are following this and more history can be gained by looking at this thread flip and propeller c language which has working C code in it. It also has a pictures of the scope and of the FLIP chips wired up on a bread board attached to some test motors.
Mike
Break the object up? That would be like asking to cut off pins or perform laser surgery on a uart to eliminate unneeded functions. It takes one cog no matter the functions it uses. The object has all the functions; you need to examine the object to know which one and how to call a function of the object for an action you require.
You have EIGHT individual cogs/processors inside the Prop. Use them up. No sense sparing them, no real savings in your application. Spin takes the first cog (0). Use one for comms, one for each motor, and you still have 4 cogs left for other features/goodies you may think up like position readout, battery monitoring, time, etc., provided you take the time to really master the prop chip. Start with the chapters 4-6 in the prop ed manual and do/build the exercises at the end of each chapter. Stop doing for a bit and go back to learning. Then you will be able to roll your own objects or modify others to your purposes without reinventing the wheel.
As to "finding the Full Duplex Serial object", why were you still searching for it. Jon gave you an entire project framework including an enhanced version of this likely same object you just found. But again, using that will require knowing how to program the prop to be able to effectively Jon's (or anyone's) framework or objects.
(Just my heretical viewpoint, I see no need to use C on the Prop1)
BTW... that C program that you claim works? It's using at least two cogs, one of them for the fdserial driver, the other for your control code.
This thread is really driving me crazy.
Thanks to this explanation from iseries, I may (and I suspect many others) may totally misunderstood what is going on here;
"Let me inject some history here.
There are two motors on the LX50 unit that are basic motors as stated. By PWM we are using variable length pulses to energize the motors so they rotate in a given direction at a given speed. He wants to replace the control hardware to the motors with some no longer available UDN2993B chips that he has laying around. In any case they are like all the current FET drive units out there and should work to drive the motors."
I had assumed bbrien was trying to emulate the LX50 handbox protocol through the existing LX50 control panel.
If iseries is correct then bbrien is actually bypassing the entire LX50 control panel altogether and driving the two motors directly using an old UDN2993B H bridge chip.
If this is true then this problem is ridiculously simple. There are many examples and code around for robots with a H bridge driving two motors bi-directionally.
The LX50 control schematic (attached) indicates the motors are simple brushed motors, so any H bridge should do. I would use a cheap modern H bridge module as used in so many robots.
. what lines do I need to change to achieve this and the same goes for the period.
Also what does "longfill (@nspulse, STOP, 2)" mean and doe's.