Jan Karel wrote:
> Hello Joe,
>
> I have to apology for not fully correct information in my previous e-mail.
> When I started to try MAP65-IQ I used my old laptop, AMD Turion, 512 MB RAM
> and XP. MAP65-IQ works well, no problem. Then I tried MAP65 and I have
> problem I described earlier. I notice that 512 MB RAM is not sufficient for
> MAP65 and I tried my new notebook with Intel Dual 2 Core, 4 GB and Vista. I
> started again with MAP65-IQ and it looks fine so I went to MAP65. I tried
> today again MAP65-IQ on this notebook and there is problem with MAP65-IQ as
> well. MAP65-IQ receives data from Linrad with no problem, Drop 0.00%, but
> the very first decode somehow freeze the main window, the clock stops and no
> other decode. I can open for example options etc. It only stops clock, Moon
> and Sun data and no more decode lines in In the configuration window are the
> following messages:
>
> ******************************************************************
> MAP65-IQ Version 0.9 r1116, by K1JT
> Revision date: 2009-04-10 09:28:35 -0400 (Fri, 10 Apr 2009)
> Run date: Thu Aug 27 21:06:14 2009 UTC
> Using Linrad for input, PortAudio for output.
> Will accept unicast data from Linrad.
>
> Audio Output Device Name
> Device Channels
> ----------------------------------------------------------
> 4 2 Microsoft Sound Mapper - Output
> 5 2 Speakers (Conexant High Definit
> 6 2 SPDIF Interface (Conexant High
> 7 2 Line 1 (Virtual Audio Cable)
> 8 2 Line 2 (Virtual Audio Cable)
>
> Default Output: 4
> Requested Output: 8
> Opening device 8 for output.
> Audio output stream running normally.
> ******************************************************************
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "C:\k1jt\svn\wsjt\map65iq\buildmap65\out1.pyz/Tkinter", line 1345, in
> __c
> all__
> File "C:\k1jt\svn\wsjt\map65iq\buildmap65\out1.pyz/Tkinter", line 456, in
> call
> it
> File "<string>", line 1178, in update
> File "C:\k1jt\svn\wsjt\map65iq\buildmap65\out1.pyz/Tkinter", line 1139, in
> con
> figure
> File "C:\k1jt\svn\wsjt\map65iq\buildmap65\out1.pyz/Tkinter", line 1130, in
> _co
> nfigure
> TclError: invalid command name ".38032848.38033008.38033168"
>
> Waterfall continues and every minutes show new lines, clock on waterfall
> windows shows correct time.
>
> I checked it again on old AMD Turion notebook and MAP65-IQ still works well.
> All description of problems with MAP65 were correct.
>
> vy 73 Jan
>
>
>
> On Thu, Aug 27, 2009 at 4:46 PM, Jan Karel <
ok1vao@xxxxxxxxxxxxx> wrote:
>
>> Hello Joe and others,
>>
>> I am sorry for bandwidth, but I am starting to be desperate.
>>
>> I changed the fft to MMX (16 bits) and I can set the RX level from about
>> -14 to +18 dB by volume control of a sound card. Unfortunately the problem
>> persists. Red No Rx data is irregularly flashing in about 1 second interval.
>> Meantime there is no dropped packets. It realy looks like network problem. I
>> also tried single PC configuration - local loop 127.0.0.1, but it looks very
>> similar. Windows reports CPU load bellow 30 % when both Linrad and MAP65 is
>> running on the same configuration.
>>
>> Is there a big difference in LAN load (I/O requests) between MAP65-IQ and
>> MAP65? I am asking because MAP65-IQ works fine with default par files. Can
>> you send me your par files to get some ideas if I haven't mess anything in
>> Linrad?
>>
>> Will it help if I send you the file and messages that windows show when
>> program crashed? It reports APPCRASH event in the module Audio.pyd
>>
>> 73 Jan
>>
>>
>>
>>
>>
>> On Thu, Aug 27, 2009 at 4:11 PM, Jan Karel <ok1vao@xxxxxxxxxxxxx> wrote:
>>
>>> Joe,
>>>
>>> I will try to change fft2 to MMX and see if I can get RX levels close to
>>> 0.
>>>
>>> 73 Jan
>>>
>>>
>>>
>>> On Thu, Aug 27, 2009 at 3:40 PM, Joe Taylor <joe@xxxxxxxxxxxxxxxxx> wrote:
>>>
>>>> Hi Jan,
>>>>
>>>>> Thanks for your reply. You ask if RX level that MAP65 shows is close to
>>>> 0,
>>>>> no it is not. It is very high, about 65 dB.
>>>>>
>>>>> Is this the problem?
>>>> Well, it is certainly *a* problem. Hard to say, yet,
>>>> whether it's *the* problem.
>>>>
>>>> I suspect it means that you have not chosen a fixed-point
>>>> FFT for the second FFT. Off the top of my head, I forget
>>>> the version numbers that Leif uses here; but whatever
>>>> version you are now using -- I think probably a
>>>> floating-point one -- change to another.
>>>>
>>>> When I'm home again I will check the FFT versions I'm
>>>> actually using.
>>>>
>>>> -- Joe
>>>>
>
> >
>