[hpsdr] Step 1 Question

[Phil Harman]

Hi Ed,

Perhaps one of the features the Server could offer is to make I @ Q data
available if requested.  That way the user could write their own DSP code
as required.

73's Phil...VK6APH






> I think VAC on the client (user interface) side is really the only way to
> go.  Having a "virtual sound card" on the network would still require some
> sort of driver on the client end, to take that virtual sound card and turn
> it into a device that fldigi (or any sound card app) could take advantage
> of.  Since VAC is well-known and well-used, we might as well just use
> that.
>
> BTW, I do still think that the interface specs should allow for DSP
> processing to happen somewhere besides the server end.  Even if that's not
> implemented in the first pass, I'd hate to write off that possibility so
> early.  I may very well be in the minority, though, and will certainly go
> with whatever the whole group decides.
>
> -Ed-
>
>> -----Original Message-----
>> From: hpsdr-bounces at lists.openhpsdr.org [mailto:hpsdr-
>> bounces at lists.openhpsdr.org] On Behalf Of Graham / KE9H
>> Sent: Monday, August 09, 2010 9:43 AM
>> To: phil at pharman.org
>> Cc: hpsdr at lists.openhpsdr.org
>> Subject: Re: [hpsdr] Step 1 Question
>>
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> Phil:
>>
>> This is what VAC is all about.
>>
>> FLdigi expects to hook to a sound card and receive 16 bit audio from
>> the jack that that sound card is hooked to.  It puts out 16 bit audio
>> to be given to a sound card for transmission to a radio input.
>>
>> PowerSDR puts out 16 bit audio for output through a sound card
>> equivalent.
>> Also accepts digital audio.
>>
>> VAC takes the 16 bits from PowerSDR, and hands it to FLDigi, so that
>> FLdigi thinks it is talking to a sound card.  The fun begins if PowerSDR
>> and
>> FLdigi are running in two different time domains, so VAC also has the
>> ability to resample the audio in both directions and cross time domains
>> if necessary.
>>
>> So either build VAC functionality into the new software, or have an
>> interface that looks like a soundcard.  Could be at the GUI, or
>> at the signal processing server.
>>
>> Or, define a "plug-in" interface so a PSK-31 modem module can
>> plug directly into the GUI, or the signal processing server, so that you
>> get to recreate/re-write every kind of digital modem software in the
>> world, too.
>>
>> Many ways to skin this cat, architecturally.  Suggest that openHPSDR
>> stick to the radio signal processing until things are under control
>> there.
>>
>> --- Graham / KE9H
>>
>> ==
>>
>> Phil Harman wrote:
>> > ***** High Performance Software Defined Radio Discussion List *****
>> >
>> > All,
>> >
>> > Just received this interesting and thought provoking question from the
>> > dttsp-linux reflector regarding our digital data plans.
>> >
>> > Comments and suggestions welcome.
>> >
>> > 73's Phil...VK6APH
>> >
>> >
>> > Phil
>> >
>> > Interesting - as a data mode ham, I have a couple of questions:
>> >
>> > "All DSP on the server" - now how does this split work for say PSK-31?
>> On
>> > my current
>> > setup I take raw I/Q audio via jack from the softrock, dttsp does the
>> hard
>> > work of
>> > selecting an chunk of spectrum, and this reappears (again in jack) as
>> an
>> > audio
>> > signal. FLdigi is connected to this, and does not know it wasn't
>> connected
>> > to the
>> > headphone socket of a 'real' radio.
>> >
>> > Would your design export the intermediate audio (realtime across the
>> > network), or
>> > would you split fldigi to run its modem(s) on the server, and export
>> > decoded text
>> > (plus non-realtime waterfall data) to the client?
>> >
>> > One other detail - is this work GPL v3 or GPL v2?
>> >
>> > 73
>> >
>> > --David G8SQH
>> >
>> >
>> > ___
>>
>> _______________________________________________
>> 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/
>
>



 1281404246.0