ke2n at cs.com
Tue May 31 21:19:07 EDT 2011
I suppose there will be a phase-continuity problem at the moment of
You would have to synchronize the audio to the vicinity of 1 -10
microseconds probably - not 125 microseconds.
RF propagation might cause this much delay . hmmm, I see the problem.
The problem with decoding at the remote receivers (as I understand it) is
that, if the error exceeds the correctable number of bits, you don't know
you have an error.
If the error is correctable - well, then why switch ?
I suppose if you had zero error bits in one receiver and some small amount
in the other receiver (2 or 3 bits in a frame - something correctable) you
would want to switch the receiver that had the zero errors on the theory
that the *next* frame is less likely to be trash. But there is no guarantee
. the next good data frame might be coming from the receiver that had errors
with the current data frame.
From: Jim Duuuude [mailto:telesistant at hotmail.com]
Sent: Tuesday, May 31, 2011 7:05 PM
To: ke2n at cs.com; app_rpt mailing list
Subject: RE: Voting
Unfortunately physics does not allow (for several reasons) data to be
decoded from the audio
as a result of any type of voting system. The only way to accomplish voting
using digital audio
is to decode the digital stream (at least into digital data) at the voting
receiver site, *then* send
the decoded audio data as packets for voting etc.
From: ke2n at cs.com
To: telesistant at hotmail.com; app_rpt-users at ohnosec.org
Date: Mon, 30 May 2011 19:55:51 -0400
Jim - any chance that the voting system could have an option to run the
receiver sound conversion at a higher sampling rate (>8000)?
I am thinking it could also be used for a Dstar system - that means you need
to reproduce what is coming out of the discriminator from near 0 Hz up to
about 5.5 KHz with a relatively flat pass band.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the App_rpt-users