At 08:18 PM 3/23/2006, Tom Thompson wrote:
I may be way off base on this, but fools often wade in where angels fear
to tread. It seems to me that the limiting factor in the latency from,
when the last character is sent and the other station is heard, is the
sampling rate of the sound card. In
I may be way off base on this, but fools often wade in where angels fear
to tread. It seems to me that the limiting factor in the latency from,
when the last character is sent and the other station is heard, is the
sampling rate of the sound card. In order for the radio to start
working on i
I am noticing a very strange phenomenon with Preview 18 (and 15 &16)
where when I am in SSB mode and not modulating the SDR1K, I have FR
output of 6-10 watts. I even unplugged the mic input from the firebox
and turned all of the preamps down to 0 and I still have 10 watts of RF
being output. If I
At 03:51 PM 3/23/2006, Eric Ellison wrote:
I think for most, the real problem is software monitoring of sidetone which
even with a few ms delay or worse, intermittent delays, will throw a high
speed cw operator off rhythm. (It really does bring tears to your eyes to
see a hs cw op respond to an
I perceive the variability in TR as well. I think the
way to think of this is to not consider QSK. The way
to think of this is to consider how to control semi
break-in very precisely. The reason designing for QSK
is a waste of time is because of the buckets and
buckets. The ability to turn arou
Folks
Just wanted to say thanks in advance to Ken N9VV for moderating tomorrow
night's forum on Teamspeak.
You will be given a reprieve from my 'fumble bumble' moderation to a fine
feller with a broadcast easygoing style, whose chuckle has always made me
feel "Glad to be alive!"
Ken wa
Jim
As usual excellent responses and very clear explanation of delays. Over the
seemingly many months, this has been discussed any number of times with no
precise resolution or measurments. (as far as I am aware).
We even invented a hardware daughter card to overcome the apparent desense
of the s
Are you setting the sample rate on the FireBox control panel?
Eric Wachsmann
FlexRadio Systems
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> radio.biz] On Behalf Of Jimmy Jones
> Sent: Thursday, March 23, 2006 4:37 PM
> To: FLexRadio@flex-radio.biz
> Subject
Look at buffers too. I had to up some buffers to eliminate drop outs,
especially using digital modes.
-Tim
---
Integrated Technical Services
"You can't close the door when the walls cave in" --Robert Hunter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Mine will only work on 48k.
Firebox and Dell Dimension 4550 2.4 gig proc with a gig of ram.
>
> Before I got a new computer, I could set the sample rate on the audio
tab
> to 96000 and widen the panadapter display. Now since downloading
version
> 18 on the new computer, when I click 96000, I
Before I got a new computer, I could set the sample rate on the audio tab to
96000 and widen the panadapter display. Now since downloading version 18 on
the new computer, when I click 96000, I lose all recieve and hear only an
oscillating swish across the audio. I have to reimport a database f
Another interesting number can be gleaned from the Orion test report...
At 60 wpm, it looks like the 'active' period of a 'dit' is 20 ms long (or,
stated another way, it's 40 ms from a dit rising edge to the rising edge of a
following dit), assuming I'm interpreting the figure correctly.
William,
This is a great point and opinions seem to vary widely in terms of how
the "VFOs" should work and what exactly a "VFO" is. Our current design
uses VFO-A for the mode and while VFO B stores the mode (for swapping),
when transmitting split, the mode of VFO A is used. This is a
consequence
At 11:07 AM 3/23/2006, Ken - N9VV wrote:
Hi Jim, I tried to find the "turnaround" time that is defined by the ARRL
tests as:
Transmit/Receive Turnaround Time
Test Description: The purpose of the Transmit/Receive turnaround test is
At 11:05 AM 3/23/2006, [EMAIL PROTECTED] wrote:
> And here's where a software radio is so nifty.. the delay through the
> electronics in the SDR1000 is very small (microseconds), and the delay
> through the signal processing is a function of what kind of filters you
> implement. Maybe the answer
Hi Jim, I tried to find the "turnaround" time that is defined by
the ARRL tests as:
Transmit/Receive Turnaround Time
Test Description: The purpose of the Transmit/Receive turnaround
test is to measure the delay required to switch f
> When in Split mode, the mode selection of VFO A overrides the mode
> selection
> of VFO B. While this may seem like a good thing, if you have just operated
> CW split mode and switch to SSB operation and forget to remove the split
> mode, you will be transmitting SSB in the CW portion of the band
At 10:36 AM 3/23/2006, Jim Lux wrote:
At 10:00 AM 3/23/2006, Ken - N9VV wrote:
>Hi Jeff, sorry, I missed what you were after. I took a brief look
>at the ARRL Test Results
>http://www.arrl.org/members-only/prodrev/bymfg.html#T
>and found:
>
>ICOM IC-780017ms
>ICOM IC-746pro 18ms
>Yaesu MK-V
> And here's where a software radio is so nifty.. the delay through the
> electronics in the SDR1000 is very small (microseconds), and the delay
> through the signal processing is a function of what kind of filters you
> implement. Maybe the answer for "fast CW" is to have different filters,
> acc
At 10:00 AM 3/23/2006, Ken - N9VV wrote:
Hi Jeff, sorry, I missed what you were after. I took a brief look
at the ARRL Test Results
http://www.arrl.org/members-only/prodrev/bymfg.html#T
and found:
ICOM IC-780017ms
ICOM IC-746pro 18ms
Yaesu MK-V 28ms
Kenwood TS870 18ms
Ten-Tec Orion
At 08:41 AM 3/23/2006, Ken - N9VV wrote:
re: has anyone characterized the T/R delay?
Y*E*S, Lee Crocker wrote extensively about the CW performance and
related T/R delays etc. Please read below and then check the
archive for Lee Crocker around March 22nd
Perhaps, though, the question is not wha
Let me hasten to add, you are STRICTLY on your own with this mod. Any
damage, spurious emissions, etc. is on your nickel.
Bob
Robert W McGwier wrote:
Bill:
Bring up the code in the MS IDE. Bring up the console.cs in DESIGN
mode. click once on the power button. In the lower right hand c
Bill:
Bring up the code in the MS IDE. Bring up the console.cs in DESIGN
mode. click once on the power button. In the lower right hand corner
you will see the limits for the Power button. Change the upper limit to
150. Have fun.
Bob
Bill Nagle wrote:
Hi Eric:
I will also post this
Hi Jeff, sorry, I missed what you were after. I took a brief look
at the ARRL Test Results
http://www.arrl.org/members-only/prodrev/bymfg.html#T
and found:
ICOM IC-780017ms
ICOM IC-746pro 18ms
Yaesu MK-V 28ms
Kenwood TS870 18ms
Ten-Tec Orion 24.6ms
SDR-1000 (October 2005)
"Receiv
Hi Ken,
I checked the archive and, although I found a number of message Lee wrote in
March, none of them discuss what T/R delays really ought to be. Perhaps I
overlooked it, but I thouht I checked all his messages.
I also took a look at other messages around that time, and, apart fro
re: has anyone characterized the T/R delay?
Y*E*S, Lee Crocker wrote extensively about the CW performance and
related T/R delays etc. Please read below and then check the
archive for Lee Crocker around March 22nd
===
[Flexradio] High
Hi Eric:
I will also post this in the requested features area in support.
If we do the following, we can have totally scaled power for those touchy
linears and also allow more output availability when using the sdr1000 as a
stand alone device:
1--In the SETUP/TRANSMIT menu add a "knob"(simila
Lee,
I have put a word in with our reflector host to inquire about the
previous email suggestions about making it searchable. I'll post here
when I find something out. It is likely that we will be adding our
archive to the mail-archive.com website.
Eric Wachsmann
FlexRadio Systems
> -Orig
Does anyone have a feeling (or knowledge) regarding how much overall delay (rcv
& xmit path combined) is acceptable for the type of CW operation being
described in this thread?
Also - I wonder how changing buffer sizes (audio, dsp,...) affects
performance. For example, if one changes the
Lee:
This is a really good point. One where we can agree completely. We
are so long between major releases, but constantly doing interim
releases, that we probably should update the documentation as we go
along with the code as it is developed.
The only reason 1.6.0 is not out today is
The recent discussion about the inevitable delay through the receiver for
CW brings up an interesting point. To a first order, the delay, through
ANY receiver, is going to be related to how steep the skirts are on the
filters (a 1 Hz bandwidth filter is going to have a delay 100 times as
long
I went to look at the website where perf resides, and
this is the authors blurb regarding that applet:
perf (download source) (download executable)
This is a simple Win32 utility I use to figure out
whether a machine has support for the high-resolution
performance counters necessary for microseco
When in Split mode, the mode selection of VFO A overrides the mode selection
of VFO B. While this may seem like a good thing, if you have just operated
CW split mode and switch to SSB operation and forget to remove the split
mode, you will be transmitting SSB in the CW portion of the band.
I wa
On 3/23/06, Lee A Crocker <[EMAIL PROTECTED]> wrote:
> and Sami Aintila telle me I will get 3,579,545 Hz even if I have ACPI 2.0
> running.
That's not exactly what I said.
I said that performance counter frequency does not NECESSARILY relate
to ACPI version. So you can get the ~3.5 MHz reading
34 matches
Mail list logo