[hpsdr] Multiple Rx -- ghpsdr3 on Windows - Success for the most part

[Richard Stasiak]

GM Dave

I shorted out FU2 (5V regulator) fuse on LPU and all is now well on  
the hardware front.  No more sudden darkness on the LED's on the HPSDR  
boards.

Have ghpsdr3-windows server and 3 instances of dspserver running on  
the shack computer (XP 32 bit, 3.2 Mhz. P4).  CPU running at ~70%.

I am listening to four receivers in my living room on a MacBook Pro  
running four instances of jmonitor in OSX 10.6.2. Connected on a  
wireless network.  It has been stable for the past hour.

Once I loaded the second instance of dspserver on my XP machine the  
audio on the first monitor became distorted.  The audio continues to  
be distorted on all instances of jmonitor with four receivers running.

Should I decrease the sampling rates to 48 khz. to reduce the load on  
the XP machine?

Thanks to you Dave, John G0ORX, Bruce W1BW, Kirk KD7IRS and all of the  
HPSDR community who have helped, for all of your hard work on this  
code.  It is really neat to be able to play with 4 RX's at the same  
time, especially remotely.

73

Rick ve3mm


On 4-Jul-10, at 4:50 AM, David McQuate wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
> Yes, Mercury 3.0 does draw significantly more current.  Ozy 18 +  
> Mercury 3.0 draws about 1.43 amps from the 5V supply.   Looks like  
> users of the LPU will need to replace the resettable fuse with a  
> higher current fuse, or jumper across it.
>
> I see I omitted the file msecsleep.exe from the LoadMercuryFirmware  
> folder.  Without the required waits,  re-programming of Ozy as a  
> Byte-Blaster fails, and quartus_pgm doesn't find a USB Blaster.
>
> I've added that file to the LoadMercuryFirmware folder on the SVN.
> 73,
> Dave
> wa8ywq
>
> Richard Stasiak wrote:
>> Hi Dave and Dave
>>
>> Thanks for the heads up on the drive designation.  I should have  
>> picked that one up myself.
>>
>> Anyway there is still something missing in that directory for  
>> updating the Mercury FPGA.  I'm not sure what it is.  The update  
>> still crashed, this time looking for a hardware cable (?).
>>
>> I was able to get the FPGA loaded by moving your revised update  
>> batch file and the two mercury4receiver files into Phil's Update  
>> blaster directory and running the update from there.
>>
>> With the code loaded I now have another issue, hardware this time.   
>> The radio is shutting down just after I start the first receiver.   
>> I haven't started troubleshooting yet, but I suspect the thermal  
>> fuse in the LPU is not happy.  The new Mercury code must be drawing  
>> a lot more current in the FPGA.  I will check it out tomorrow.
>>
>> 73
>>
>> Rick ve3mm
>>>>
>>>>
>>> _______________________________________________
>>> HPSDR Discussion List
>>> To post msg: hpsdr at openhpsdr.org
>>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
>>> HPSDR web page: http://openhpsdr.org
>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>>>
>>
>>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>


 1278255491.0