Ok, need some help with this for my setup. Currently the station is as follows:
Yaesu G5400b (-180/0/180 degree travel) with GS232 protocol. Gpredict and Hamlib installed and working as expected.
Problem: Hamlib (rotctl for sure, not sure of rotctld) seems to want azimuth in absolute degrees (N is 0 or 360, E is 90, S is 180, W is 270), but gpredict seems to be sending position of +/- 0 to 180 degrees. So if Gpredict is seeking West pointing antenna, it is showing “-90 degrees”, however using “-90” as a rotctl command gives an error.
So in practicing tracking a satellite this afternoon, I found that if Gpredict is following a satellite that crosses into the west, the rotator stops and then I have do various shenanigans (turning off tracking and moving azimuth back to a “good” position). Can anybody suggest what the Gpredict setup should be?
Controlling the system from the Fox Delta ST2, all controls work. The ST2 clearly shows that as you pass through 0 deg (north, from east to west), the position indicates “5…4…3…2…1…0…359…358…357…etc”.
Also, controlling from the ST2, the azimuth rotator will automatically stop at 180deg (S) regardless of which direction you are turning from (all of this is what I expect to be normal).
I’ve tried the following two settings in Gpredict, with no luck (both with -180 -> 0 -> 180 Az type):
Okay, we have a similar setup at OZ7SAT with a G6LVB controller. As far as I recall, we tested the setup with Gpredict some time ago, but I will check again tomorrow.
It’s the advantage of sticking to low-level coding
I’ll forward more in response to this item later however just to clarify - HAMLIB’s ROTCTL(d) does not require azimuth position to be between 0 and 360. In fact, according to the man-pages, P/p command (Set/get position) are double precision floating point values. What DOES require 000-360/000-450 command range is the GS-232 protocol (this is required to be a three digit integer). You may also want to check if using rotctl model 601(GS-232A) helps resolves some of your issues, if you happen to be using rotctl model 602 (GS-232). The issue is known for GPredict when used with these rotators/controllers with the end stops in the South Position (refer https://sourceforge.net/p/gpredict/mailman/message/35182191/ where this behaviour is detailed). Yaesu addressed the ‘end stop in the south position’ in their controllers by use of the ‘Z’ command within the protocol. I’m not sure if the ‘Z’ command has been implemented within the Hamlib GS-232 code (will check tonight).
@vk2ckp, Thank you very much for pointing this out to me. I was worried it might be something like this.
Is there any hack that I can do to get the rotators functioning at all (on western passes, or at least passes that “cross” the south? For example, turning the az rotator 180°, and re-calibrating the ST2 for 0 -> 180 -> 360? (and of course using this option in GPredict with a 0° azimuth stop?)
–Roy
K3RLD
[edit] forgot to mention that I tried using GS-232A, but I believe I got some sort of communication error when using the “P” command in rotctl, so didn’t even bother trying rotctld.
Roy,
This particular issue is multi-fold in my opinion. Part of the issue (in my opinion) is that GPredict does differentiate between ‘command set’ azimuth degrees and the physical installation of the rotator (i.e. where the end-stops are). These are two distinct concepts that have been collapsed into one within the code.
On the other hand, the hamlib library doesn’t appear to check the command range and apply translation prior to parsing into commands to the controllers in accordance with the relevant protocol documents. To this end, I have written to the author of the GS232 hamlib modules with a suggestion that will at least allow the rotators to function (although there may still be an issue with GPredict). I will keep this thread posted with any updates. As for your issue with the GS-232A, I’d check again… the protocol command set appears identical (at least for W and C2 commands) for GS232 and GS232A, however they both differ from the GS-232B for the response provided to a C2 request.
The ‘quick fix’ would be to physically rotate your rotator so that end stops were ‘North facing’ and use the 0-180-360 command set in GPredict. To do this, it would appear you would have to make a small calibration change to your ST2 (step 11 in the setup manual https://www.foxdelta.com/products/st2-rs232/st2-config.pdf).
I hadn’t picked up you were using the ST2. This interface appears to allow for use of either the GS232 command set or the EasyComm command set. I’ll have a look at the EasyComm hamlib module tomorrow and see if perhaps it addresses these issues (the protocol appears to require positive degree commands but does allow for a single digit after the decimal place, i.e. the command supports 0.1degree command increments).
Ok, GS-232A (option 601) does in fact work, although it gives me a “cannot read position” error after each “P” command. The “p” command returns position successefully, though. Behavior under Gpredict is exactly the same as GS-232 (option 602).
None of the easycomm options work under rigctl, didn’t try rigctld.
When Gpredict is set up as a -180 to 0 to 180 degree Az rotator, with 0min to 360max and 180 deg az stop, I can turn CCW until 0deg in Gpredict and then the rotor stops and won’t move into “negative” numbers (ie, past 0 deg north in CCW direction). Same issue if I set it up as a -180min to 180max with 180 az stop.
Too rainy today to play with the stop position, but I figured I’d leave an update.
Roy,
Suggest you don’t play with the stop position. I think I’ve got an ‘easy fix’ for the HAMLIB library backend.
As for the GS-232A can not read position issue - this is an interesting one. I would have expected (based on the protocols) that the return response to the C2 request was coded identically - but it isn’t. GS232.c and GS232A.c handle this quite differently (in fact, it would appear that GS232 is not compliant with the protocol definitions) and the GS232A should be used for the LVB Tracker (although the LVB/ST2 also appears to simultaneously support the Easycomm Protocols).
I’m looking at the HAMLIB libraries (3 of in fact) but I don’t have access to a ST2 controller. (Note: You may have to disconnect/stop rotctl(d) prior).
I was wondering if you might be able to do the following and report back.
Using a terminal programme connected directly to the ST2 tracker, run the following commands (note: is for you to press ENTER to execute the command:
The above commands tell the rotators to move, and then request their position. Execute the C2 command once the rotators have stopped moving.
Then, establish rotctl using model 601. Then run the following commands:
P 000.0 000.0
p
P 090.0 000.0
p
P 180.0 090.0
p
P 270.0 180.0
p
P 360.0 180.0
p
Repeat the above using rotctl model 602.
I’ve prepared changes to the three model files which will be tested tonight before putting forward a pull request on the HAMLIB libraries which should fix this issue in terms of controls but may still need some fixing around the position reporting back to GPredict.
I’ll be running an identical set of tests on my two rotator interfaces to ensure that we can replicate behaviour. All going well, it may be that will be able to compile an updated version of HAMLIB from my clone tomorrow for testing, if not - it will probably be sometime over the weekend.
Managed to get some investigations done tonight. Have been able to determine the key issues.
The Yaesu/KenPro documents for the GS232 protocols state that 0Dh should be sent back after every command received. Both model 601 and 603 codes look for this 0Dh when they write a command § to the controller however model 602 code does not do this check (but it probably should). If fact, I think I’ll write to the authors offering to build a new model (605) for the AMSAT LVB / FoxDelta ST2 GS232-Generic Model and ‘fix’ model 602. So, no need to run the tests above. Now off to rebuild HAMLIB to test negative azimuth angles fixes.
Good news. My changes to HAMLIB have now been merged into the MASTER file at Sourceforge. If you grab that code and compile you will find new models in the 6xx series of rotators including specifically the ST2. Two key issues addressed with these updates as follows:
I’ve noted that some implementations of the GS232 protocol are incorrect which results in the read errors when a P command is issued. These implementations are addressed now by individual model numbers and a ‘GS232 Generic’ model type.
All GS232 type models have been modified to accept Azimuth commands in the range of -180 to 0 degrees. These are then translated ‘on the fly’ by the backend into the ‘GS232 correct range’ of 180-360 degrees and issued onto the GS232 hardware. This will allow GPredict to command the rotator using -180->0->180 command set and should fix the flip issue people have with rotators in this orientation.
I suspect I’ll do some more tidying up of the GS232 libraries shortly with a view of trying to get them all to a 1.0 STABLE issue.
Please do let me know if there are any issues and I’ll see what I can do. I’ve got a clone of the HAMLIB source sitting in my Sourceforge user account with a local clone of that on a RPi3B+ which I used to do all the development and testing.
Ok, after some amount of time trying to get the master branch to compile (had to use autoreconf), and some additional time figuring out that I had to use ldconfig after the install, I’ve finally got it running!
I am able to move the antenna anywhere I want it in Gpredict (manually), and I have a CAS-4B pass in about 20 minutes that passes over the 180degree stop, which will be the ultimate test. I will update in about 30 minutes!
Well, it sure seemed to work correctly! The azimuth values displayed by Gpredict are totally wacky (seem to be based on S rather than N?!?!), but what really matters is that the rotator set up in the proper orientation and then tracked the satellite across 180deg actual azimuth! I’ll have to do some more testing this evening, but it looks like we have a winner! I will keep this thread updated with my continued findings.
