Joe,
Yep, r5833 seems to transmit fine here. Regarding your earlier question, I
received your CQ using my Cushcraft WARC dipole at 20m height. It happens to
present a low reflecction coefficient on 6m. The pattern is probably “lobe-y”
on 6m. In any case, the dipole is broadside NE/SW.
Steve, k9an
> On Aug 30, 2015, at 7:20 PM, Joe Taylor <j...@princeton.edu> wrote:
>
> 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
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
