First I think that you are mistaken about the 5khz. The DSP functions can pick out noise with out the "high frequency noise". And you don't need any thing involved with signal strength measurement or, noise measurements. A audio "quality" detect routine will work fine.
There is no problem running more than one sound card. As a matter of fact my Echolink machine has 2 right now. 73 AC0Y --- In [email protected], Matt Krick <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > > > > > > > > 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/
