On Sat, 2006-09-02 at 19:14 +0100, Bob Cowdery wrote:
I think there is a very strong clue here. The architecture is aimed at
supporting a radio factory. The major motivation to my mind therefore
comes from the idea of a virtual radio or radio kernel architecture to
support 10's or 100's of
It works just fine here.
You have to start up 2 instances of erlang. Here's how I do it under
cygwin.
(1) Start up 1 instance like this:
werl -sname pong
then compile the tutorial
c(tut17).
and run it
tut17:start_pong().
(2) Start up the other instance:
Thought that might be it.
If you get a chance, look at the 'Behavior' documentation. Part of OTP
(as beyond just the Erlang language) is a fairly complete set of server,
state machine, task supervisor, and application frameworks for which you
need to supply only callbacks.
The pattern-matching
Bob --
A little short on time now so I can't really respond fully. Just a
couple points.
On Fri, 2006-09-01 at 23:20 +0100, Bob Cowdery wrote:
I don't know what advantage is
gained from an FP language (in this environment).
Process concurrency can be proved correct when expressed in an FP,
One more thing.
Message passing. It's one way for processes to talk but may not be
appropriate in all cases.
It's more than just talking.
There are lots of different schema for synchronizing concurrent
processes. You can easily show that any one of them (mutexes, monitors,
barriers,
On Fri, 2006-09-01 at 23:37 -0400, Robert McGwier wrote:
The history of Erlang reveals its parentage tree contains Prolog. They
wanted to use Prolog but could not and give reasons.
Not sure whether Bob or Eric remembers this, but a couple of years ago
when we were first talking about the
On Fri, 2006-09-01 at 21:51 -0400, Robert McGwier wrote:
I really hope after we stress this it holds up to
the buffeting we must give it in tests.
Oh, there's no doubt we can break it. The question is whether it's our
fault or theirs...based on previous experience, we can probably guess...
Bob --
If it's OK with you I'm taking the conversation public again, for the
time being anyway.
Could we for example agree that there is a distributed infrastructure
(regardless of language, protocol or encoding formats) in which services
are hosted and that services communicate with each
On Sun, 2006-08-27 at 16:13 +0100, Bob Cowdery wrote:
2 I don't know if this is a real difference in topology or not. I
didn't envisage a central service but more a peer-to-peer network where
the VR is just a node even if that node is 'hidden' in the sense that
all commands from other nodes
On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:
I've done a bit more digging. There seems to be three options for
integration:
1. The arms length pipes (I think this can be TCP/IP as well and
possibly some others (according to some papers I read)). Pipes only work
for *nix so it means
On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:
I can't see how you move that back to the UI
without having duplicate data and a lot of issues.
To expand on the last point just a little, the UI also has a much more
complex idea of what the VFO wants to be (VFO A+B, switching, RIT, XIT,
On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:
I haven't seen anything for Python apart from the ports tutorial that
uses pipes.
Have a look at py_interface, which is an all-native-Python
implementation of an Erlang node, linked to from
http://www.erlang.org/user.html
73
Frank
AB2KT
On Sun, 2006-08-27 at 23:10 +0100, Bob Cowdery wrote:
Ok. But something in this system has to be *the* application.
Yes, we're on very different wavelengths, because I don't see this at
all, not at all. I see the system as a collection of services, and the
VR is merely a convenient way of
Bob --
It's very good you brought this up, because the issues are truly
important.
I have an onion skin model of what I want to do...
I think we're imagining different topologies. The model we've been
assuming is a graph. The various different processing components (DSP,
hardware control, UI,
OK, Jim. You keep writing specs. We'll keep writing radios.
It's hard to avoid the impression you haven't been keeping up with
developments.
To echo the end of your previous note, 'nuff said.
73
Frank
AB2KT
On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:
And when will those specs be
On Wed, 2006-08-23 at 08:37 +0100, Bob Cowdery wrote:
On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:
I've been waiting for the long
anticipated UI/backend split with a well defined interface, as announced,
gosh, several times over the past couple years...
Am I the only one that
On Wed, 2006-08-23 at 08:06 -0700, Jim Lux wrote:
But is this in PowerSDR (which is my frame of reference/context) or in the
Linux fork?
Strange as this may seem, it's the Windows version that's the fork. It's
intended that there will be no difference in the future.
And, I assume this
On Wed, 2006-08-23 at 18:16 +0100, James Courtier-Dutton wrote:
So, a typical reason for NOT using erlang is signal processing. Why is
dttsp therefore using erlang?
The kernel is not doing signal processing. That, the DSP, is in
sdr-core, in C. The kernel implements the virtual radio -- the
PowerSDR is a strawman.
To date -- not counting the PowerSDR console or variants, or completely
independent projects like Rocky -- there have about a half-dozen
alternate, working consoles cooperating with either sdr-core (the DttSP
SDR core) or its predecessor, jsdr. Two of them have appeared in
On Wed, 2006-08-23 at 15:12 -0700, Jim Lux wrote:
Is there any preliminary description of this development?
Among the developers, yes.
Would this description be suitable to see the light of day, or will we wait
for it to be revealed at some time in the future?
We will answer no whine
On Wed, 2006-08-23 at 16:54 -0700, Jim Lux wrote:
But, what of the planned V1.7 of PowerSDR?
Gerald, Eric, Flex officialdom, is this true?
There's no news here. This has been the official position since before
1.6. The next Windows incarnation will be a thorough rewrite, deserving
the name
On Wed, 2006-08-23 at 21:23 -0700, Jim Lux wrote:
Hmmm.. The document on the Flex-radio website (referenced on the What's
coming page) entititled:
SDR-1000 Enhancement Plan – First Half of 2006
The major-rewrite decision preceded the release of 1.6. After much
subsequent discussion, it
On Tue, 2006-08-22 at 17:25 -0700, Jim Lux wrote:
The problem I see is that since there is no current specification (or even
preliminary detailed sketches) of a published UI/Radio interface, everyone
is sort of working on modifying what's there now.
Jim, I have nothing but respect and
Jim Lux wrote:
And when will those specs be published? RSN?
As soon as you've finished them, Jim.
73
Frank
AB2KT
___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link:
Paul Shaffer wrote:
Perhaps it's a case of tweaking the UI drawing code, but inadvertently
affecting the DSP audio chain.
Not the DSP audio chain, but rather the analog audio chain, I suspect.
You can get all sorts of crosstalk trash in your audio output from
the display or the mouse. When the
the question Frank... I described my delima the
best could. If I leave 160 meters at 1945 by clicking on the 80
meter band button ONE time, then decide to return to 160 by clicking
on the 160 meter band button ONE time, it returns me to 1990 instead
of 1945.
On 7/25/06, Frank Brickle
Radio Station W5AMI wrote:
My question is; why would it not default to the last freq. I sat on
before going to another band if I decide to click 160 again? Whew!
Hope that makes sense!
Let me guess -- the band select button cycles the stacking
registers regardless, even when there's been an
Pete wrote:
I'm hoping that the imminent split of DSP engine and
GUI will ultimately lead to a totally Linux SDR-1000 platform - what's
happening on this front - for instance, are there soon to be published
APIs for developing a GUI that talks to the DSP? What else is
happening?
Lots.
Is the product something besides packet shaping under another name?
Another one of those things you get so used to having
automatically under Linux...
73
Frank
AB2KT
Tim Ellison wrote:
Doesn't sound like open source to me! Also, I was all my bandwidth and
CPU cycles to go to PowerSDR
Jeff Anderson wrote:
I have absolutely no problem with a public discussion
of users' concerns regarding my Console and Flex's
desire to incorporate some of my features into their
Console...
Jeff --
Your work with the console is as clear an indication as you could
ask for of a couple of
Sounds like a mode-by-mode carrier offset variable. The trick
might not be so much providing the feature as reminding the user
that it's in effect :-) (Why is my radio off frequency?!?)
73
Frank
AB2KT
Eric Wachsmann wrote:
Jerry,
Unfortunately, this is not a 1 line fix. It takes some
Where is the value of top.swch.fade -- that's essentially the TRX
crossfade time, in samples -- being set? In the PowerSDR code I
can trace it back through setup_switching() to setup() but haven't
been able to find the call to setup() :-)
73
Frank
AB2KT
Tom Thompson wrote:
Bob and Eric,
in SSB, you can notice the last sylable of spoken words into
the mic, if you keep talking past exact point when you toggle off the PTT..
So something isn't quite right there..
-Dan
- Original Message -
From: Frank Brickle [EMAIL PROTECTED]
To: flexradio@flex-radio.biz
Sent: Tuesday, June 27
Eric Wachsmann - FlexRadio wrote:
1. CW Performance
We have seen unanimous praise regarding the improvement in CW
performance in alpha test versions of this software...
2. Click 'n' Drag
...This feature
also works to tune signals...
Maybe this would be a good time to enable in the console
:
Errr uhhh, that might be a nice idea. MEA CULPA.
Bob
Frank Brickle wrote:
Eric Wachsmann - FlexRadio wrote:
1. CW Performance
We have seen unanimous praise regarding the improvement in CW
performance in alpha test versions of this software...
2. Click 'n' Drag
Larry Gadallah wrote:
How practical/likely is it to develop a syllabic rate squelch for the
SDR-1000?
You might say it already exists. You can get Voice Activity
Detection out of Speex already. It's good and it's free.
The place to start is by making an app that runs with jack, that
can be
Lee A Crocker wrote:
...simply be a check box on the menu Casual User...X
...
The thing that will propel flex into the future is its
flexibility. For example I have a vision of one day
being able to deploy 16 receivers in a 192khz
bandwidth that can do automatic CW decoding...
A few
Lee A Crocker wrote:
I need a knob on my radio
I need a knob on my radio
I need a knob on my radio...
Bob N4HY and I both worked for a long time with a legendary
linguistic researcher named Ned Neuburg. One of his (lesser)
claims to fame was a discovery he made during a study of methods
Nicholas Bastin wrote:
You would have to sync to GPS. You can't accurately measure network
delay and compensate, because congestion and network delay are
dynamic. Even then it would be odd, because you'd have to introduce
delay to allow for all the stations to receive the source signal
Steve --
Sorry for the overly brief reply, as this deserves a more-detailed
answer. For the moment, though, maybe you ought to look at gnuradio
http://www.gnu.org/software/gnuradio/
It will provide all of the infrastructure you'll need to do this
problem, lots of good examples, and a few other
referring to hardware or software
implementation?
73,
Steve - K5FR
-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]
Sent: Monday, May 29, 2006 10:50 AM
To: Steve Nance
Cc: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] DSP Question
BTW one more thing
John Denson wrote:
Couldn't the software do that for us? My that I mean have the software
command a PTT first and delay the dots and dashed a predefined number of
milliseconds before sending them?
This would be an enhancement in MixW, rather than in the SDR-1000
software, wouldn't it?
73
Peter Martinez wrote:
...poor (or missing) DC coupling...really is not a problem...
As a generalization, I believe this is untrue.
73
Frank
AB2KT
___
FlexRadio mailing list
FlexRadio@flex-radio.biz
mode.
There are no skips on transmit or recieve.
I know a few people that wont buy the flex just because of that. What a shame.
I guess there will be a few cw geeks...uh freaks that won't buy the radio for
the same reasons.(latency)
From: Frank Brickle
To: FlexRadio@flex-radio.biz
The DSP software is already capable of 0 Hz IF, and has been since its
earliest version. IIRC the 11025 Hz IF is primarily a consequence of the
frequency response of typical soundcards, which start rolling off
somewhere in the vicinity of 200-300 Hz.
73
Frank
AB2KT
Peter Martinez wrote:
From
Jimmy Jones wrote:
I wish some of brain - o's could solve the monitor latency problem.
Well, according to Science Today magazine this week, some string
theorists are speculating that time travel may actually be feasible.
With that solved the monitor latency problem won't be far behind. Till
Often (as with ALSA) the option exists to dither samples with random
bits drawn from various distributions, to ameliorate quantization noise.
In any case there isn't much to do about the low bits inside the SDR
software. The samples are delivered as floats. Masking would need to be
done
44100 is the CD data rate (48000 is the DAT rate)
44100 complex samples/sec - +/-22050Hz passband
22050/2 = 11025 - center of positive freqs
You want IF (11025) rather than baseband because soundcards roll off
towards 0Hz.
That jog it?
73
Frank
AB2KT
richard allen wrote:
Would someone
James P Lux wrote:
The DSP chain is also currently
structured in a way that is sort of Tx or Rx, but not both, at
one time, with transitions between Tx/Rx only occuring on
block/buffer boundaries.
It's half duplex and necessarily so under the current Windows
incarnation, where the DSP
Guy Olinger, K2AV wrote:
How can SDR make use of dual core processors, which are becoming quite
affordable?
Bear in mind that none of the problems currently experienced with CW on
the SDR1K should be attributed to a lack of CPU resources. There are
plenty of cycles to go around for *many*
Dale Boresz wrote:
The MS recommendation is to use the Convert.To() methods such as:
int ix100 = Convert.ToInt32(x100)
...
If you're doing this in the C language, I think the ceiling function
(don't remember the exact syntax of the function - it may be ceil())
will do the trick
Probably
Bill Tracey wrote:
OK -- I'll take a look at adding support for handling +/- 1 sample
offset in the DttSP audio callbacks...
FB. Not sure how you want to handle this, and I'm absolutely certain you
don't need to be reminded of it, but there should surely be some
mechanism for
Robert McGwier wrote:
Couple of typos here.
The next line would be something like
if (offset 0) for(i=0;ioffset; --i)
^^^^
ringb_float_write(top.jack.ring.i.l, zero,1);
else for(i=0;ioffset;i++) ringb_float_write(top.jack.ring.i.r, zero,1);
Bill --
...Anyone have an opinion on the right place to implement
such an option - ie on the C# side of the world, or should it be down in
the DttSP code?...
It's a good bet the skew problem, if that is indeed the problem, is not
unique to the Audigy and thus deserves a general solution. It
FWIW what originally sent me to Ubuntu was trying to dual-boot XP and
Linux by installing the new OS to an external USB2 drive. It's hopeless
under SuSE. Clunky with Knoppix. Elementary with Ubuntu.
Nevertheless it's a little safer all around, if you want to play with
beta OS releases, to do
Too late. The decision's made already: Ubuntu.
73
Frank
AB2KT
Jim Lux wrote:
I'm going to leap right into the middle of a religious war here..
As all the linux-o-philes know, there are probably 200 different distros
out there, each having some unique properties that at least one person
Jim Lux wrote:
Ah, yes.. but, then, are all Linux users of the SDR1000 going to be
building gnuradio from scratch?
No, but it's a good standard of comparison. Try it sometime on a
different distro.
This goes back to choosing a target distro based on the developers'
preference or the
[EMAIL PROTECTED] wrote:
(If you don't plan to really enforce it but
merely say that's what we'll officially support, then there is no
decision, really, just a preferred pathway, which is much different).
That's all it ever meant. I don't see why this discussion is even taking
place.
73
Lars E. Pettersson wrote:
I will try to make a spec-file and rpm for Fedora, probably usable on
the other rpm-specific distros. Mainly for my own use, but I imagine
that others could be interested in it also.
Lars, that would be very useful for everybody. Thank you. One of the
things I hope
No, you were right on the money about the lawyers, which was really the
only important part.
73
Frank
AB2KT
Robert McGwier wrote:
TRUE. Sorry, I misspoke.
Frank Brickle wrote:
Robert McGwier [EMAIL PROTECTED] wrote:
The copyright in the code says that you may not sell it without
Ross Stenberg wrote:
Well, I downloaded and installed release v1.6.0. As soon as I ran it, my
radio went into oscillation and started the house on fire, the cat lost all
of its hair, and my wife left me for another woman. At least the S meter is
accurate and the preamp allows me to receive 27
Bill Nagle wrote:
Perhaps we should start a thread on the forum and get other pinions?
Presumably this issue is not a matter of opinion. Either there's a solid
technical argument behind it or there isn't.
As a general rule I'd suggest that (A) engineering errors get fixed in
the official
Dale Richardson wrote:
The delay of the signal through the receiver is noticeable. I
put a Yaesu FT-920 next to the SDR on receive and transmitted cw with
another transmitter and the SDR is always a few milliseconds behind. The
lag is noticeable enough that it is easy to lose the sync of a dx
Craig Roberts wrote:
Has anyone transitioned from a Ten Tec Pegasus to a FlexRadio? If so,
what are your comparative impressions, please?
Or, for that matter, from the combination of Ham Radio DeLuxe and a more
convetional, high-end modern transceiver?
73
Frank
AB2KT
Willi Reppel wrote:
The reflector is no recycling plant for obsolete elec-tronic appliances.
Anyhow, who wants to trade in a bleeding edge for a leading edge of
technology.
My IC-746 (not Pro) does QSK...
;-)
73
Frank
AB2KT
Hmm. Makes me think about bored firemen becoming arsonists...be careful,
you might just be tempted to commit programming.
73
Frank
AB2KT
Tim Ellison wrote:
I hate to admit it, but I am experiencing SVN withdrawals today. It has
been over 24 hours since Bob posted the last fix. Not even a
Eric Ellison wrote:
As a Linux neophyte and I am still a little confused by all the jargon, and
the seeming complexity of getting all the parts to play together nicely...
Wimps! Go off and try to get soundcard packet running on your Linux
machines, and then come back and tell me about
KD5NWA wrote:
The CPU that burps today, may not function at all tomorrow.
All this talk of motherboards, I would get something with extra gas
in the tank.
The basic SDR DSP and audio run fine on a 533MHz machine. What you need
the extra power for are (1) the graphical display (2) short
Just to throw in another incompatible opinion, I'm not sure there *is*
such a thing as proper VOX. I couldn't get it to work right on my rig in
1966 and I can't get it to work right on any rig today. By that standard
the current SDR1K VOX is doing fine ;-)
73
Frank
AB2KT
Bob McGwier N4HY
Jim Lux wrote:
What the meaning and implications of the basic states:
run_mute
As the name implies, continue running normally, but produce no audio output.
run_pass
Continue running but pass input to output unchanged; literal copy from
input to output.
run_play
The ordinary mode,
Jim Lux wrote:
WIth reference to dttsp
A start of some of the flow of control in sdr.c may be found at
http://home.earthlink.net/~w6rmk/sdr1000/index.htm
I'm starting to diagram the flow of control in main/winmain (i.e. the
various parallel threads)
The data structure file I'd start with is
Bob, I think this deserves the John Lennon accolade:
Luuuve-ly, simply lvely.
73
Frank
AB2KT
[EMAIL PROTECTED] wrote:
The Smalltalk based SDR-Breadboard radio is coming along. This release is
primarily aimed at Windows although the Linux functionality is still intact.
Have a look on
All,
Just wondering. Is it a good idea to expand the group to take in BSD and
Mac OSX potential users?
73
Frank
AB2KT
Subject:Re: [Flexradio] snap_meter? snap_spectrum?
Date: Tue, 21 Feb 2006 13:24:33 -0500
From: Frank Brickle [EMAIL PROTECTED]
To: Jim Lux [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Jim Lux wrote:
Where are they defined?
How do they work?
meter.c and spectrum.c
to be on
the way to becoming, we should certainly make every attempt to include
them. Both the java and Qt code will run on the Mac. I know from my
WSJT development experience the *BSD's will run the c, p-threads,
python stuff without a lot of hacking.
Bob
Frank Brickle wrote:
All,
Just
All,
Yesterday Jim made some observations about errors and error trapping in
the update command processing in jsdr. This was coming sooner or later
but, being very lazy, I wasn't going to do anything about it until
somebody complained. If it ain't broke etc. However it *is* somewhat
broke so
Bill Tracey wrote:
With the FPGA based sound I/O work we're doing, independent D/A channels
are fairly easy, just instantiate a PWM decoder in the FPGA and an R and
C in hardware can be used as an output channel.
Can I have one *now*, please? ;-)
If that's the case, then it's probably time
Jim Lux wrote:
Actually, it would be an extremely common configuration these days, what
with standard 5.1 audio on most consumer oriented PCs.
Right, although I honestly don't know how common a 5.1 audio gadget is
that also lives up to the performance standards people are demanding
from
Jim Lux wrote:
Not in the command processor, at least as far as the parsing of the
command strings go. But, I think you DO want strong typing when passing
a parsed token (i.e. it's been converted into a enumerated value) to a
routine, especially if the destination routine might be compiled
Jim Lux wrote:
I would qualify that and say that in *amateur oriented* SDR
implementations, error recovery (or detection) in commanding is given
short shrift.
If you're talking about JTRS, who knows? Literally.
And, at least for would-be developers of a generator of commands, it's
nice to
Jim Lux wrote:
At 12:04 PM 2/20/2006, Frank Brickle wrote:
Would it be possible to render the diagrams as PDFs?
how about ps?
That's fine too. No Visio here unfortunately.
Many thanks
Frank
AB2KT
Larry Loen wrote:
Of course. It's all about latency. But, you reduce the general load
and that helps latency. Even if it is at the margins. A CPU that is
idle more often will service an interrupt faster than one that is busier.
This is nonsense. The latency is imposed by the buffer sizes
Larry Loen wrote:
If you'd care to explain the glitches I'm already experiencing, it would
be tremendously confidence building. Are you not experiencing any?
No.
And, you haven't addressed word one about the lower level
infrastructure.
That is incorrect.
To my
knowledge, XML level
Jim Lux wrote:
update.[ch]. The list of commands is in command-vocabulary.
I think we need a bit more help here, Frank. Is there a list of
commands and their syntax, anywhere?
It's in the file command-vocabulary.
A bit of explanation of how
do_update works might also be useful. What
Jim Lux wrote:
OK, here's what I've figured out sofar. Anyone (Frank, Bob,?) who can
confirm or deny, please pitch in.
Looks good so far.
updates.c contains a whole raft of small routines which execute various
commands. The main smarts of this is a routine called do_update, which
parses a
Jim Lux wrote:
Do you mean splitfields.c?
Can you elaborate (or point to where you drew it form) on what split,
splitonto, spliton do and how they fit together? I assume that
newSplit,delSplit are constructors and destructors for SPLIT objects,
and NF, Fptr, and F are helper functions that
The .h files are all written in such a way that any .c file can just
#include common.h
or
#include the-dot-h-of-its-own-type
without worrying about multiple definitions. As a side effect, common.h
is a canonical list of data type definitions, in the order in which they
have to be known to compile
From the article:
Lessons Learned
So the risk is that a well-funded open source team that is
NOT led by someone with a personal interest in shipping the
project will get distracted by other shiny tech toys and
fail to actually ship
Eric --
You are one of the great magicians at getting people moving in the same
direction on amateur radio projects. I hate to disagree with you, to
some degree out of the fear of being wrong. In this case however it's
only a little afraid.
Eric Ellison wrote:
Therefore we will probably
Why not try Linux from a live CD? Knoppix http://www.knoppix.org is
very good and very popular. It's a little cluttered for my taste. The
Ubuntu live CD http://www.ubuntu.com is excellent too. At the moment
I'm favoring Ubuntu as the distribution of choice.
73
Frank
AB2KT
Philip Covington
Eric Ellison wrote:
Yep, it should form the basis for a specification, for the product, not the
product itself. Once a team has the spec, then the project can move forward.
I really urge anybody interested in this project to look through
http://www.paulgraham.com/articles.html. Most
Eric Wachsmann - FlexRadio wrote:
Just to throw another wrench into the mix, you could buy a hard drive
with plenty of room to add to your windows box for a dual boot system
for a similar price. Lots of options.
I recently got an external USB2 drive, 100GB 7200RPM $100, for just
this
Robert McGwier wrote:
Frank and I will be able to easily extend the DttSP supported hardware
by a factor of 2 :-P by running it behind the GnuRadio with portaudio.
It's only 3/2! Or even less if you count the SoftRock 4 and 5 as
different hardware.
Anyway it's the portaudio part that's
Hey Bob --
Wonder if you really need it. All the artificial ground is, is a series
LC and a relative current indicator. Hard to believe you couldn't put
one together out of your junkbox in a few minutes.
73
Frank
AB2KT
Bob Tracy wrote:
Anyone have any experience with the MFJ-931
The software could easily handle diversity reception, but you'd need to
provide a separate, independent RF path and A/D conversion input pair
for each channel. In short, another whole SDR1K hardware box.
73
Frank
AB2KT
Lee A Crocker wrote:
I have an interest in diversity reception.
The DSP code currently supports up to four receivers within the passband
that are completely independent with respect to tuning, filtering, mode,
and panning between the output audio channels.
These multiple receivers are not yet supported by the Windows user
interface, however.
In fact,
Cowdery, Bob [UK] wrote:
I don't know about others but I for one would really appreciate a
statement on the direction of the Linux jsdr. In the beginning Linux was
the master source which was then ported to Windows...
The Linux and Windows versions have officially forked.
None of the recent
[EMAIL PROTECTED] wrote:
Ok guys. I think a bit of real information is called for here.
You're too modest, Bob. This is exactly what I (personally, from a very
jaundiced point of view) want an SDR to be.
73
Frank
AB2KT
You can see it got a *lot* bigger when we started including all the spyware.
(Just kidding)
73
Frank
AB2KT
Joe - AB1DO wrote:
Hi all,
Yesterday I got a great birthday present - a new radio (Preview 9)! And
it was the biggest one yet, which prompted me to look at size (in kB)
over time.
I
wonder if two sets of buffers need to be sent back - one to be sent to the
transmit hardware and one to be used for sidetone.
This is approximately what happens under Linux. Generating sidetone
within jsdr (as opposed to an outboard keyer) requires 4 audio output
ports. (The keyer is
201 - 300 of 353 matches
Mail list logo
