Proposed Driver: Armstrong Radio
2009-10-13 21:38:05 GMT
Hello,
While playing with gpredict, the following question struck me, "If I am working satellites using the armstrong method how do I know when to tune?"
I am proposing a "dummy-like" armstrong driver that can be configured to call an arbitrary executable/shell script whenever something happens. It has uses for portable satellite operation and perhaps others. There may be some issues with including this in the library that have not impressed me yet.
The portable satellite operation works as follows. For instance assume an operator is working a fm satellite using an old w32a and a handheld antenna. (the radio has no computer control.) The individual is looking at a screen to know where to point the antenna (hiding the tuning window perhaps). To make things easier, the operator configures the armstrong radio to play a beep whenever it is time to change radio to the next frequency. He hears a beep coming from his computer and he turns the tuning dial on his HT. He has two armstrong radios configured, one for the uplink and one for the downlink and each is configured for a different sound.
Other possible uses: link the armstrong radio to real radio and have it notify the operator if he crosses a band edge or mode transition.
Pros of this approach:
Most of the code is already written in the dummy radio
Code can rapidly propagate between different programs.
exec does not require many new libraries and discourages bloat.
The operator can configure it to provide visual, auditory or other cues.
Cons:
May require some internal scripting capablity to be truly useful.
May introduce portability issues in code/demos. (Thinking win32 in particular.)
May not quite work in the model of hamlib (hence this e-mail asking for input.)
Before diving into the code or depriving someone else of finishing it before me, any feedback and concerns would be appreciated.
Respectfully,
Charles
AA1VS
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
_______________________________________________ Hamlib-developer mailing list Hamlib-developer <at> lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> The radio's memories were changed. It appears that ALL of the
> memories with SSB mode stored had the bandwidth changed to 400 Hz.
When you say that "The radio's memories were changed", do you mean
they were changed by a rigmem load command?
Can you please test mode setting on a regular VFO first?
This is command 'm' and 'M' under rigctl.
For example:
Rig command: M
Mode: USB
Passband: 2400
Passband is in Hz, latest "rigctl -m 357 -u" reports available's:
Bandwidths:
AM normal: 6 kHz, narrow: 2.4 kHz, wide: 0 Hz
CW normal: 500 Hz, narrow: 50 Hz, wide: 3.6 kHz
USB normal: 2.4 kHz, narrow: 50 Hz, wide: 3.6 kHz
LSB normal: 2.4 kHz, narrow: 50 Hz, wide: 3.6 kHz
RTTY normal: 2.4 kHz, narrow: 50 Hz, wide: 3.6 kHz
FM normal: 15 kHz, narrow: 8 kHz, wide: 0 Hz
CWR normal: 500 Hz, narrow: 50 Hz, wide: 3.6 kHz
RTTYR normal: 2.4 kHz, narrow: 50 Hz, wide: 3.6 kHz
According to fine DF4OR's site[1] (thanks Ekki!), regarding Passband data
and IC756PRO*:
"...And when looking at the DSP-filter rigs like IC-756Pro ff., where the
user can define and arrange each of the three filters individually, the
settings of 'wide' or 'narrow' become meaningless. Here a filter value
of $01 corresponds to filter 1, value $02 to filter 2 and $03 to filter
3, regardless of whether filter 1 is acutally wider than filter 2 or 3."
[1] 
Regards
RSS Feed