Hi Hamish.
>>> Just looking at what I did about this for Debian; I think you
>>> need to add
>>> #include <asm/ioctls.h>
>>> in sattrack.c.
>> If you have a look, you'll see that that's included by
>> <sys/ioctl.h> which is #ifdef'd out by the fact that IOCTL isn't
>> defined, so all it needs is for the surrounding #ifdef-#endif pair
>> to be deleted and that happens...
> You're right. I never bothered to look into it much, I just
> added the above #include. Changing the Makefile to add -DIOCTL
> to the CFLAGS is the best fix.
I wondered if that was valid, hence my post...thanks for confirming
that it is...
>> Whilst I'm thinking, was it you that made the rpm I grabbed? If
>> so, you may wish to know that maketles and satfilter are missing
>> from it, and I needed them...
> I know that the other tools are not included; I intended to get
> something usable available for people to test, then to add the
> other stuff as it was needed. I'll look in to include maketles
> and satfilter soon then. There is some other work that needs to
> be done too.
I finally located the source tarball, and have it installed and
working on my system now as well...and I've made a couple of what I
regard as essential tweaks to it in the process...
1. Whilst the current setting of showing three orbits works fine
for both short period satellites and near-geostationary ones,
it isn't so useful for satellites with periods between 6 and
18 hours, for which a three-orbit track is in my opinion more
than a little confusing. I found that a five orbit track makes
what's going on much easier to visualise in this case.
The code to implement this consisted of two extra defines and
modifying one existing define in one of the header files, and
an extra if statement around one other statement that caused
it to be called with one of two different values for one of
its parameters.
2. If sattrack was started up with the satellite at either the
northernmost or southernmost part of its orbit, it was often
difficult to determine from inspection where the ends of the
displayed ground track are. This was cured by extending the
displayed track by a quarter of an orbit, thus ensuring that
one end is always visible.
The code to implement this consisted of one extra define and
modifying two existing defines in one of the header files.
3. My laptop has a 256-level greyscale LCD display, and all of
the current 'fill' mode world maps display as black on black
and, as a result aren't easy to see. However, defining one of
them as being a 'line' mode map resulted in a map that works
on this display.
I'm currently looking into the tweaks necessary to add one
extra command to select the colours to use on the display.
If I get this last patch working, I plan on packaging the whole lot up
as a pair of RPM's (one .i386.rpm and the other .src.rpm) in standard
RedHat style (ie, the source as an unadultered tarball together with
the patch showing all my tweaks) for use by those interested...
Comments?
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.Amush.cx/pub/rhw/Linux
* http://www.Amush.cx/~rhw/kernel.versions.html
