[hpsdr] hpsdrServer?

[Daniel Quigley]

This is a great example of where standards/conventions could benefit projects that move along similar courses.  I am convinced that SDR is dead center in the future of amateur radio.  The successful advancement of these two (and other) projects provide compelling evidence of that conviction.  No matter where people fall on the curve of their own course of investigation, I am sure that everyone can agree that SDR is territory for vigorous experimentation and has stellar potential in the advancement of our art.   It also represents (IMO) the necessity for additional effort and conversation (agreement) on standards or conventions that can more easily allow for interoperability and progress along separate lines of effort. I am not big on throwing down a veil of process on artful investigations like these.  But I do see substantial benefits in applying thought into conventions that can be leveraged at large.  I don't consider myself an organizer of standards, but I can say that with my brief experience in developing a USB driver for HPSDR, I personally have run aground on technical and architectural concerns that will have downstream implications for the relative agility and adoption of what we are experimenting with here.  I am very interested in hearing other views on this. Best,Dan (N7HQ)

Date: Wed, 28 Jan 2009 17:45:58 -0500From: dgibbs at ix.netcom.comTo: wa0rse at gmail.comCC: hpsdr at hpsdr.orgSubject: Re: [hpsdr] hpsdrServer?Hi Paul,I have been looking at trying to interface Ozy and Janus or Mercury to QS1R Server and SDRMAX-II for a couple of months.  I started, toward the end of last year, evaluating various approaches and finally decided that the cleanest way for me would be to have Ozy emulate the QS1R interface.  I have been an embedded hardware/software designer since the dawn of the microprocessor/microcomputer but have never been too savvy as far as PC Systems are concerned, so I don't feel comfortable trying to develop an 'Ozy Server' to do the job.I needed to know the interface format but couldn't find much in the way of documentation so I started reverse engineering the QS1R Server code, the FX2 firmware code and the FPGA verilog code to try to determine what was going on.  Sometime in December I was about there when my Mercury board arrived.  Of course I immediately dropped everything else to play with it and haven't got back into the QS1R interface until recently.  I think I have it figured out but the proof is in the implementation.There are several issue to be dealt with, such as the fact, as has been mentioned here, that Mercury talks to Ozy/FPGA in a serial format rather than in parallel, as in QS1R.  This will limit maximum bandwidth to less than the 2 MHz max  presently achieved by QS1R.  Also, Ozy/Janus/Mercury embed Sync and Control bytes in the USB data stream.  QS1R uses separate channels for data and control info.  In fact, QS1R has two data channels and the control channel.The change to Ozy requires revised FX2 firmware code, revised Ozy FPGA verilog code and revised Ozy EEPROM code.  It should not require any changes to Mercury (or Janus, if desired).  As I indicated, I think I know how to do it, but I am sure once I get started there will be some surprises.  I have Eclipse setup and have successfully compiled/linked/loaded the FX2 8051 original code and I have Quartus running and have compiled and successfully loaded the original FPGA file.  One thing I need to pursue, but haven't yet, is what is necessary to debug the code in both the 8051 core in FX2 and the FPGA code.I don't know if I will get there with this approach, but it has been fun, so far, trying to figure out what it would take.  If I get anything working I will let you know.73,Doug GibbsW8NFT
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20090128/30e9139a/attachment-0003.htm>