All -
During the WPX CW test, I was using the SO2R mini all weekend. I found one
or two small issues with it and those have been root caused and fixed.
They weren't show stoppers by any means.
At this point, I am pretty much done with the firmware - although a few
extra features might be added at some point. For example, "tune with dits"
isn't implement and neither is "bug mode". The footswitch code hasn't been
used in a contest - but otherwise seems to function. The auto start send
feature and dual CQs on CW were well exercised and seem to be solid.
I am not going to make an official release of this firmware yet - as I am
not aware that anybody really needs it. This keeps the window open for new
features to be added without having to worry about version control.
However, if you want to play with what I have - send me a note and I will
send you the binary via email.
I am interested in any input about headphone control. I did not try to use
it for that this weekend. However, I have implemented some commands you
can put into a CW message (or SSB one) to change the headphone mode. So -
for example, you can switch to the inactive mode whenever you are calling
CQ or sending an exchange - and then into either stereo or mono as you want
after the message is done. I haven't yet implemented the "latch" mode
where things are more automated - but might look at that soon. I guess my
question is - does anybody actually use that?
At some point, I might do some kind of 2BSIQ implementation that takes the
"dualing CQ" feature to the next level. I guess most people do 2BSIQ with
two computers - but I am thinking of seeing I can come up with an
implementation using just one. It is obvious that for me personally, in
order to keep up with the big kids, I am going to have to employ this
feature to some extent. Now that I have a canvas that is no longer limited
in size (640KB), I can let my imagination run wild. One possible idea here
is to actually rewrite the very top level of the program from the ground
up. Thanks to the modular way the source code is mostly structured, this
might be a fairly easy thing to do.
My thought is to implement a state machine - where the QSO process (or
processes if more than one QSO) go through various states. The program is
basically written that way now - but not structured in an easy to
understand way. Each "state" would have a definition of what is happening
- and how it will respond to an event (such as a CW message being finished,
a key struck or footswitch being pressed). This structure could easily be
added to as we get more sophisticated with the process. My vision is to
have a small display of the "state number" showing up at all times in the
software - and when someone has an idea or rough edge that needs attention
- we can jump to that specific part of the code - and address it.
Likely - there are already other programs implementing a similar
architecture - but who knows. I initially discovered state machines back
in 1976 when working on a piece of equipment that monitored phone lines and
used a state machine to decode pulse dialing. I actually was hooking up
scopes to various "bits" and watching how they moved around as I did
things... and reverse engineered how the state machine was working.
Any comments or input appreciated.
I know my audience is pretty small - but my goal is to make this program as
competitive as I can for my own use - but those of you who are still here
will be able to benefit from it as well - and have a hand in shaping how it
will work.
It was great using the program pretty much as is from Kevin's efforts. The
scoreboard function was a blast to use (first time for me).
It's really great to open up the pascal source code in one window and have
the Arduino code in another - and look at how they interact. Having
control of both sides of the USB cable is really nice for me. I don't have
to limit what I can do with what someone else has implemented.
Tree
_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog
|