> I suspect I'm being thickheaded here, but how does TRLog send commands to a
> Yaesu rig? Hex makes my head hurt! I've gotten fairly comfortable with
> the ASCII strings one sends to a Kenwood radio, but the Yaesu CAT system
> stops me cold. Say, for example, I want to tell my Yaesu Mark V to turn
> off the DSP audio peaking filter after each QSO (to make it easier to hear
> off-frequency callers). The radio needs to see 5 bytes --40H/00/00/00/75H,
> I think. How do I put that in an "SRS=" statement for storage as part of
> my QSL Message, for example?
No - Yaesu is the one that caused this problem. And they make it
worse by having different command sets for each of their radios.
Kenwood made the right choice - using a command set that was very
efficient, using ASCII characters that appear on your keyboard.
However, I have added the ability to put hex values into the
RTTY send/stop strings, and this will also work for function key
memories that are in the .cfg file. This will be in the 6.59
which I hope to have out in the next couple of weeks. I am way
behind in my e-mail and need to plow through it before I can
send out a release.
Down to 250 saved messages - going back over a year.
You will put <>'s around the hex value. So, <75> will put a hex
value 75 character (or 7 x 16 + 5 in decimal) into the string.
You can put as many of these as you need.
If you are going to start programming Yaesu radios, you will need
to learn that the first byte (the op code) gets sent LAST. For
some reason, they made the software work in reverse order, but
didn't change the documentation. If you read the fine print,
it mentions it.
Tree
--
FAQ on WWW: http://www.contesting.com/FAQ/trlog
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|