Hi Steve,
You were one step too quick for me. Subroutine genmsk(), which
generates the JTMSK channel symbols, also calls the Fortran wrapper for
nhash(). The wrapper requires the second argument to be an 8-byte
integer. This has now been done, in revision 5833.
-- Joe
On 8/30/2015 2:41 PM, Steven Franke wrote:
> Joe -
> Now trying to TX. The rig is a TS480 keyed using CAT. WSPR mode works fine.
> The Tune function in jtmsk also seems to work - the TX is keyed up and a tone
> is emitted - but the tone frequency sounds lower than the selected 1500 Hz.
> After disabling Tune, I then selected Enable TX (with CQ selected as the
> message). The transmitter is keyed and the program segfaults, leaving the rig
> keyed. I re-compiled with all Debugging enabled. The trace does not show
> anything obviously wrong. The last few lines in the trace are included below:
>
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:49)Debug: Hamlib:
> kenwood_get_ptt called
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:49)Debug: Hamlib:
> kenwood_get_if called
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:49)Debug: Hamlib:
> kenwood_safe_transaction called
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:49)Debug: Hamlib:
> kenwood_transaction called
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:743)Debug: virtual
> void HamlibTransceiver::poll() rig_get_ptt PTT = 0
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/Configuration.cpp:643)Debug:
> Configuration::transceiver_online: open_if_closed: false
> Transceiver::TransceiverState(online: yes Frequency {50280000Hz, 0Hz} USB;
> SPLIT: off; PTT: off)
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/Configuration.cpp:689)Debug:
> Configuration::transceiver_ptt: true Transceiver::TransceiverState(online:
> yes Frequency {50280000Hz, 0Hz} USB; SPLIT: off; PTT: off)
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:765)Debug: virtual
> void HamlibTransceiver::do_ptt(bool) true
> Transceiver::TransceiverState(online: yes Frequency {50280000Hz, 0Hz} USB;
> SPLIT: off; PTT: off) reversed = false
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:770)Debug: virtual
> void HamlibTransceiver::do_ptt(bool) rig_set_ptt PTT = true
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:49)Debug: Hamlib:
> kenwood_set_ptt called
> Sun Aug 30 18:32:11 2015
> GMT(/home/radio/Builds/wsjtx_exp/HamlibTransceiver.cpp:49)Debug: Hamlib:
> kenwood_transaction called
>
> Steve k9an
>
>> On Aug 30, 2015, at 5:53 PM, Steven Franke<s.j.fra...@icloud.com> wrote:
>>
>> Hi Joe -
>> I went back outside to finish mowing the lawn, so I missed this:
>>
>> 162015 4 6.1 1500& CQ K1JT FN20
>> 162015 4 6.1 1500& CQ K1JT FN20
>>
>> Thanks!
>>
>> Steve k9an
>>
>>> On Aug 30, 2015, at 4:10 PM, Joe Taylor<j...@princeton.edu> wrote:
>>>
>>> Steve --
>>>
>>> I'll CQ with JTMSK, 50.280 in your direction for the next 10-15 minutes.
>>> (This is not a good time of day for meteors, though.)
>>>
>>> -- Joe
>>>
>>> On 8/30/2015 12:02 PM, Steven Franke wrote:
>>>> That seems to have fixed it Joe. Neither file causes it to crash now. I
>>>> have not yet decoded any pings though. I will let it run on 50.280 for
>>>> awhile to see if I can decode anything.
>>>> Thanks!
>>>> Steve k9an
>>>>
>>>>> On Aug 30, 2015, at 2:47 PM, Joe Taylor<j...@princeton.edu> wrote:
>>>>>
>>>>> Hi Steve,
>>>>>
>>>>> I was about to write to you along the same lines. The copies of nhash.h
>>>>> and nhash.c in .../wsjtx_exp/lib have been used only for building the
>>>>> executable testmsk, not for wsprx. I was clearly on the wrong track
>>>>> yesterday.
>>>>>
>>>>> It turns out, I believe, that the problem is entirely elsewhere. Under
>>>>> certain conditions an undefined value for TRperiod could be passed to
>>>>> function getfile(), which is used to read *.wav files from disk. As a
>>>>> consequence a big memory segment could be zeroed when this statement
>>>>> (line 56 of getfile.cpp) was executed:
>>>>>
>>>>> memset(jt9com_.d2,0,2*npts);
>>>>>
>>>>> I have now protected against this occurrence. Please try building and
>>>>> testing revision 5831.
>>>>>
>>>>> -- Joe, K1JT
>>>>>
>>>>> On 8/30/2015 10:15 AM, Steven Franke wrote:
>>>>>> Joe -
>>>>>>
>>>>>> In perusing the wsjtx_exp code this morning, I noticed two things:
>>>>>>
>>>>>> 1. All references to nhash.c in CMakeLists.txt are to the version in
>>>>>> /lib/wsprd - so it seems that changes in /lib/nhash.c are not going to
>>>>>> make any difference. If this is working for you, then perhaps we can
>>>>>> just delete the nhash.c/nhash.h in /lib?
>>>>>>
>>>>>> 2. in /lib/nhash.h, length is declared size_t in nhash and uint32_t in
>>>>>> nhash_, whereas in /lib/nhash.c is it uint32_t in nhash.c and uint32_t
>>>>>> in nhash_
>>>>>>
>>>>>> I’m guessing that item 2 is not the problem due to item 1?
>>>>>>
>>>>>> I think that we need to resolve the differences between the two
>>>>>> nhash.c’s and get rid of one of them.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> wsjt-devel mailing list
>>>>>> wsjt-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> wsjt-devel mailing list
>>>>> wsjt-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> wsjt-devel mailing list
>>>> wsjt-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
