You still have the problem of VoIP not passing audio above 5 kHz

Instead of taking a S-Meter reading you need to convert the amount of high frequency noise to a PL tone. Basicly build a SuperSquelch-IIIB and use a 9400 voltage to frequency converter on the "S-Meter" pin. Remember this is not a true S-Meter read but rather a voltage between 0 and 5 volts which rises as the noise on the carrier does. Any squelch circuit that can spit out a voltage to represent the noise on channel will do the trick but it has to be done at the RX site. 

I like the rest of your plan and feel that is the way it should be done.  I could experiment but I am no good when it comes to writing software. Letting the computer sound card handle the noise determination could be a good idea, But you would have to sample at 22kHz or 44kHz to get the audio where youd need it and this may not be possible as the VoIP is going to run the sound card at the rate it wants to, But if running two sound cards doesnt bother you... Other wise you need the Noise to PL converter.



ac0y5 wrote:
Okay Nate, I sent most of the posts about this Thursday or Friday 
before the theoretical stuff started it was posted by the moderator  
late Saturday as the time stamp states.

   Now, Any good software is created in modules or subroutines and 
the main program just calls the routines as needed. You don't think 
someone just jumped in and wrote Win2000 or XP I'm sure. AS a 
HARDWARE and SOFTWARE ENGINEER and Visual Basic Instructor this is 
the first thing that I teach in class FIRST CLASS and I have my 
students re site it back in every class. If they only learn one 
thing it MUST be this. It sounds like a great project for a group. 
There is a add on package to visual Basic called VB VOICE, I've just 
started to play with it AND, It has great potential even for this 
project.

  What one would have to do is get a group togeather to work on the 
PROJECT. break it up into tasks and assign each person with in the 
group a task to write after the modules is written it must be 
integrated into one piece of workable code. This is a job with in 
it's self.

 Now, to the practical. On the receiver end it's pretty much simple 
to create the VOIP packets if you use computers at each site that 
has is's clock synched with a NIST standard by using (NET TIME) 
command. set the TTL ( time to live) which sets the maximum time 
that the packet will live on the network. To what ever you like. 
That will take care of the that problem. Each site sends it's VOIP 
packet to the TX computer. Each packet has a numerical sequence if 
the packet arrives out of sequence the machine still can reassemble 
it in order with out anyone the wiser. All of this is built into 
TCP/IP. Simple so far aye? 

  Now comes the hard part. Deciding what approach to take in 
evaluating the received audio. First, as I said in my other post 
Signal strength is a VERY BAY way of determining which receiver to 
select. Even Motorola gave up on it. Their second generation voting 
systems used the basic approach that GE originally used that of 
evaluating the audio not the signal strength. This should be done in 
the DSP on the sound board, Maybe, maybe not.

  Like I said, It would be a neat project to attack but not very use 
full. After all a lot of repeater owners just want's to get 
something on the air with out knowing how a repeater works much less 
caring about how it sounds. After all look at how many posts that 
show up here asking how to put a repeater together or where they can 
buy the parts or one already built, most likely not having given a 
thought about having to get a repeater pair coordinated much less 
knowing ANYTHING about how one works.....Repeater owners should be 
tested separately. OOPS, I have to hop down off my soap box. I got a 
glance the other evening after a VE session and one of the 
candidates that PASSED the GENERAL exam said:, " I don't know shit 
about electronics or radios and I passed". IT's a sad state that our 
hobby is in. ....OOPS, Hopping down again.
 73 for now,
AC0Y


--- In [email protected], Nate Duehr <[EMAIL PROTECTED]> 
wrote:
  
On Mar 5, 2004, at 8:52 PM, ac0y5 wrote:

    
  The main problem stated in previous posts with DELAY is mostly
caused by TCP/IP packet delay, other delays are Analog to Digital
and Digital to Analog conversion along the path at the Echolink
ends. Another problem is the TCP/IP packets do not take a 
      
constant
  
path .... this is caused by packet path switching on the internet
there fore it would be very difficult to create a set delay for 
      
each
  
path. Now having said that, the same problem exists with
Echolink.......IT works pretty well in spite of the problems 
      
that It
  
has to overcome. Jonathan Has created a pretty great system AND 
      
it
  
works very well !!!!!
      
Coy,

You sound like you've missed some stuff in the conversation.  
    
Those of 
  
us interested in it were no longer talking about using EchoLink or 
    
IRLP 
  
as-is, but in the theoretical... in theory a system *could* be 
    
created 
  
that could factor out the variable delay of the Internet 
    
connection in 
  
software.

First requirement... all audio is delayed -- let's say for 
    
simplicity 
  
sake you pick 500ms - 1/2 a second.  That's probably too high to 
    
be 
  
practical, but an easy number to use in conversation.

The "master" computer at the repeater site then gets packets from 
remote receivers that are time stamped.  It also feeds itself a 
    
delayed 
  
version of the main receiver there on-site.

One person recommended using something like GPS for the timing.  I 
recommended using a relative timestamp of the "slave" in relation 
    
to 
  
the "master" to keep from having maintenance issues with something 
    
like 
  
NTP or a local GPS clock.  Both have positives and negatives, but 
    
the 
  
important part is that all packets from remote receivers arrive at 
    
the 
  
main site with a timestamp of some sort on them for when they were 
*created*.

Packets older than 500ms are of course, thrown away -- that IP 
    
path is 
  
too messed up to use real-time.  A really good programmer would 
    
also 
  
set an "alarm" state for that receiver and notify the system owner 
    
that 
  
it's not being used, but anyway... on with the explanation...

Packets younger than 500ms are synchronized to the other inbound 
streams.  Actually, the system just keeps track of pointers to the 
"500ms mark" in the incoming buffers.  As long as you know 
    
what "now" 
  
is (always a challenge in itself), you can point to the starting 
    
point 
  
of where packets in each buffer that are 500ms old.  Now you have 
    
audio 
  
streams you can jump back and forth between that are all in time-
    
domain 
  
synchronization.

If you want to listen to the main receiver you play packets 
    
forward of 
  
the 500ms pointer.  If you need to jump to receiver 2 (or 3, or 4) 
    
you 
  
take your next packet to play from the 500ms pointer into that 
    
buffer.  
  
At this point in software you don't pay any attention at all to 
    
the 
  
variable delay on the front-end, you've removed it using software 
    
and 
  
large packet buffers in RAM.

Then... and here's where my knowledge falls down -- you do some 
    
sort of 
  
voting magic in software -- be it RSSI embedded along with the 
    
signal 
  
or something more CPU-intensive like an algorithm to look at noise 
levels.

So the basic concepts we're talking about here are that first you 
    
sync 
  
the digitized audio and get rid of the problem of the Internet -- 
    
the 
  
variable delay -- then you do whatever "voting" you want.

The main problems for a Ham implementation?  Time and effort to 
    
create 
  
the software.  Probably the only way for hobbyists to attack this 
problem would be to break it in to bite-sized pieces and work at 
    
each 
  
of them one at a time.  Of course, a large engineering outfit 
    
would 
  
just have some whiz kid do the whole mess in a DSP in about a week 
worth of coding.   ;-)

To me, the pieces individually sure seem "do-able" over time -- 
    
I'm not 
  
sure anyone here has the time or motivation to do it though.  
    
Saying 
  
over and over again that it's "not possible" doesn't make it so.  
    
I 
  
believe it is possible in software -- just not software we have 
available "off the shelf" today.

Certainly 100% NOT possible with Jonathan's software -- because 
    
it's 
  
closed-source.  Why start with that headache and have to reinvent 
    
the 
  
wheel?  Taking something like SpeakFreely for Unix which is in the 
Public Domain and starting with already working code would be much 
    
much 
  
easier.

I envision that you'd need to do all this buffer manipulation in 
    
C, so 
  
IRLP's shells-scripts-wrapped-around-SpeakFreely design isn't very 
useful as a starting point either.  You'd have to just dive into 
    
the 
  
SpeakFreely code.

Another interesting possibility would be to dive into some of the 
    
newer 
  
(and better supported) true-VoIP code like the Asterisk software 
    
PBX 
  
project and/or SIP Phone code in Kphone or similar software and 
    
tear 
  
out the guts of the packet handlers and remove all the user-
    
interface 
  
GUI code.

Nate WY0X
    






 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/Repeater-Builder/

<*> To unsubscribe from this group, send an email to:
     [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
 



  








Yahoo! Groups Links

Reply via email to