Hi Bill, Steve, and all,
On 8/29/2015 9:44 AM, Bill Somerville wrote:
> On 29/08/2015 13:59, Steven Franke wrote:
> Hi Steve,
>> Attemptimg to play with jtmsk here using r5824.
>>
>> I am seeing the following:
>>
>> $ ./wsjtx
>> At line 65 of file /home/radio/Builds/wsjtx_exp/lib/jtmsk.f90
>> Fortran runtime error: Index '-8543' of dimension 1 of array 'c' outside of
>> expected range (1:524288)
>> Segmentation fault (core dumped)
> The bounds error is probably best addressed by Joe, I can't see an
> obvious issue but I suspect an uninitialized variable may be the culprit.
r5826 has a (temporary?) fix that will avoid this crash.
>> Also, the frequency selection dropdown does not work. Should it?
> This is an area that needs addressing with respect to fast modes. Due to
> the wider bandwidths spot working frequencies are not necessarily
> appropriate. The drop down list can be added to for each mode in
> "Settings->Frequencies" by right clicking the working frequencies table
> and selecting "Insert ...". Whether we supply default frequencies for
> fast modes is debatable and other than for logging purposes the whole
> issue of rig control may not be relevant to most VHF& up users except
> for the Doppler correction facility for slow modes off the Moon.
Actually I think mode-specific spot frequencies for the fast modes
probably do make sense. In NA, for example, we have been using 50.280
for JT9H and now also JTMSK. You can leave the program running all day,
and PSKreporter shows your spots in the usual way. With meteor scatter
propagation, a single frequency is effectively shared with "time
division multiple access" rather than "frequency division multiple access".
On another matter: as you have probably noticed, all these modes have
produced a lot of special cases (mostly in mainwindow.cpp) of the form
if(m_mode == "JTMSK") do this...
To keep the main window GUI from getting too complicated, I've been
making irrelevant controls invisible.
Most likely there are better ways to do some of these necessary things.
Ways that a real programmer would know about.
We talked once about using a QStateMachine for handling mode-specific
behavior. And maybe tabs or layers of controls? Anyway, I'm sure these
things could be much improved, and the GUI made cleaner.
I've been concentrating mostly on making the new modes work.
-- Joe, K1JT
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
