Re: [Hamlib-developer] Fun with RotorEZ

[Nate B. <n0...@ne...>]

Thanks, Orv, for testing things out.

* Orv Beach <w6...@pa...> [2003 Feb 12 06:06 -0600]:
> I got my RotorEZ card assembled into my Ham IV this evening, and
> exercised Nate's virgin code.  Some observations:
> 
> The P <az> <el> command appears to work properly.  Giving rotctl the P
> command results in
> 
> Azimuth?  (type in 3 digits here)
> Elevation? (000) <Enter>
> 
> And the rotor obediently turns to 030 degrees.
> 
> That's the good news.

Fortunately, half of it works!

> The bad news is that the p command doesn't return consistent azimuth
> results.  
> 
> With the rotor at 030 degrees, successive 'p's returned the following
> byte strings:
> 
> String     Rotctl interpretation
> =======    =======================
> 33 33 3b   33; degrees
> 30 32 39   29.0 degrees (? might have the degrees wrong)
> 3b 30 32   ;02 degrees
> 39 3b 30   9;0 degrees
> 
> Rotating the rotor to 330 degrees, and typing 'p' four times resulted
> in:
> 
> 31 35 3b   15;
> 33 33 33   333
> 3b 33 33   ;33
> 33 3b 33   3;3
> 
> So, there's an offset or a typo someplace, I suspect.  Hope this
> debugging helps.  Let me know if there's other tests you'd like me to
> do.

Are these strings copied verbatim from the output of running rotctl
-vvvvv?  Just do a copy and paste of the screen output from an XTerm
as that would be the most helpful. 

Without looking at the code, my guess is that the code is only looking
for 3 characters and the Idiom card is sending 4.  So I need to compare
the raw sequences against the RX code.  If so, one byte is still in the
serial buffer.  Fortunately this shouldn't break the DCU-1 as it doesn't
have position query support. 

I won't be able to get to looking at things until this evening after
work.

> 
> Good start, though!  I'm excited!   

Thanks!

> One wish - on a rotor with no elevation, can we suppress the query and
> printout on rotctl?   It's distracting and a bit annoying..

rotctl is a test program, but I suppose it can be written to obey the
backend rotor caps.  That would be good for general use, but for a
simple test interface, it may just get in the way and hinder debugging.
Such a feature would probably be best enabled by an option rather than
by default.

> Are there any GUI front ends extant for rotor control?

Look on the apps page of http://hamlib.sourceforge.net I think there is
a gnome front-end to Predict that may incorporate rotor control.  Joop
has a better idea of this than I do as he's also authoring a general
purpose logging program.

Thanks again, Orv.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto