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
