I suppose there will be a  phase-continuity problem at the moment of switchover?

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 ?

A conundrum.

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.

Sigh

Ken

KE2N

From: Jim Duuuude [mailto:telesistant@hotmail.com]
Sent: Tuesday, May 31, 2011 7:05 PM
To: ke2n@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.

JIM WB6NIL

---

From: ke2n@cs.com
To: telesistant@hotmail.com; app_rpt-users@ohnosec.org
Subject: Voting
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.

Ken