I nailed down the 180° issue to the satnogs client. The strange thing is, that in worker.py the data is processed right in send_to_socket(). Even the debug logging looks fine in LOGGER.debug(‘Rotctld msg: %s’, msg). BUT if the AZ is larger then 180° then the message is not transmitted to the rotctld-implementation on the ESP32 any more.
Unfortunately I am not able to find the code “behind” sock.position = msg. I am not very experienced in Phyton. I want to add debug logging there to see what happens with the msg if AZ is larger then 180.
half true, it does not currently support controlling rotator hardware, as in running rotctld.
but it still can speak to a rotctld that is running somewhere outside the stack, like in it’s own stack or on other hosts.
Thank you. Found it. Indeed the NETROTCTL is defined to rotate from -180 to 180 degrees, while my implementation sends 0 - 360 degree. So i assume that setting the Rotator to NETROTCTL will trigger the sock to filter inside the boundaries.
This is kind of bad. The satnogs client creates valid coordinates between 0 and 360 deg in Azimuth. But there is no chance to send them using NETROTCTL in hamlib as this will need -180 to 180 coords. I took a look at the source code of gpredict and they simply reimplemented the send code and do not use hamlib. The send trivial “P ” statments and do not care about the boundaries.
So I can now add a rotator backend to hamlib which compares to NETROTCTL but accepts 0-360 in AZ and 0-180 in EV. Or I can patch satnogs-client to deliver -180 to 180 coords instead. But I would need to adapt the rotator code, too. Just to convert it back into 0-360.
Did I miss something? I think I’ll opt for a corresponding hamlib backend. But I have to figure out how to do that first.
I’m not sure where the filtering takes place. But the client only generates 0-360 az as you found.
the \dump_caps is run on connect, and gets the max/min values. this needs to be specified for many rotator models as it cannot be detected or inferred.
Thank you. This is a very good pointer. I thought the \dump_state is from satnogs but in fact it is from the hamlib itself. Unfortunately it is not documented well but I red the source and there is a good chance that it might work. Hamlib is polling, parsing and evaluating the data returned by \dump_state. I’ll now set up a rotctld to do some tcpdump to see what a response to \dump_state should look like.
This works! The solution was to implement something like this for the “\dump_state” command. Of course it needs some more testing. But the last two passes with Az larger the 180 worked. Unfortunately I glued a nice looking dish to my rotator and now it is too heavy for the steppers and won’t move any more I am already building something stronger.
Serial.println("Send rotator info");
toSendString = String("1"); // Protocol v1
toSendString += "\n";
toSendString += String("2"); // Rotator Type NETROTCTL
toSendString += "\n";
toSendString += String("min_az=0.000000"); // Azimuth min
toSendString += "\n";
toSendString += String("max_az=360.000000"); // Azimuth max
toSendString += "\n";
toSendString += String("min_el=0.000000"); // Elevation min
toSendString += "\n";
toSendString += String("max_el=180.000000"); // Elevation max
toSendString += "\n";
toSendString += String("south_zero=0"); // South Zero Setting
toSendString += "\n";
toSendString += String("rot_type=Other"); // Rotator Type
toSendString += "\n";
toSendString += String("done"); // End
toSendString += "\n";
Serial.println(toSendString);
New rotator build with NEMA17 @work. Based on this project.
Not ideal for an antenna, but I already had all the necessary parts. I printed the large ball bearing and used airsoft ammo for the balls. It should be sufficient for software development, and it’s
significantly more powerful than the smaller version.
My son wasn’t so happy that the small desktop version of the tracker was no longer available. So I started a redesign. The elevation part is now finished. I’ve incorporated a 1:2 gear ratio, which makes it possible to use an even larger dish. In any case, maintaining the position is no longer a problem. Since I don’t have the CAD data for the previous dish and printing it with the supports on the back was difficult, I created a new low-poly version. The azimuth part is already in progress. Unfortunately, with the 28BYJ-48 steppers, you really only get what you pay for. These things wobble in every axis and direction. But if you have a 3D printer, you can build an ESP32 Wifi desktop rotor for around €50.
We’re still waiting for the RG58 cable for our base station, which seems to be having delivery problems at the moment. We’re filling the time with our desktop rotor project.
I usually recommend rg316 for routing on small rotators, then hook it up to a lna and then rg58 or better back down to the rx/sdr.
rg58 is usually fine for ~5-15m runs if you have a lna up at the antenna.
Finished the first prototype It looks like I’ll need a gearbox in the base as well. The printed bearing is very stiff. The designer suggests to run it for some hours to sleeve it in. Using counter weight is very important if you have weak steppers. I ordered adhesive wheel weights, they are perfect for such a small setup.
I finished the second prototype. It will not work for reception but it is a nice project to study all the problems you could face with a rotator. Like bearings, counter weight, transmission. The software seems to work fine. Any AccelStepper supported stepper drivers and motors can be used. It is directly fed from Satnogs Docker using the ESP32 Wifi. The dish is now a calculated Paraboloid with a focal point 5cm above the dish.
Finally, there’s progress with the antenna. I’ve received all the parts and printed a holder for both antennas that fits onto a suitable wooden post. I’m currently designing and printing a waterproof box for the LNA and the filters. I hope to be able to assemble everything in the next few days and then finally test it.
I am already building something stronger.
It looks like I’ll need a gearbox in the base as well. The printed bearing is very stiff. The designer suggests to run it for some hours to sleeve it in. Using counter weight is very important if you have weak steppers. I ordered adhesive wheel weights, they are perfect for such a small setup.
