Subject:
|
Re: A Generic Idea
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 5 Jan 2003 07:33:46 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail.netAVOIDSPAM>
|
Viewed:
|
883 times
|
| |
|
|
Nick Tarleton wrote:
> I don't know how fast the speaker can change frequency
> or how soon it can be reacted to, so I can't get a bandwidth estimate.
The telephone system can (at best) transmit at 56Kbaud (that's the speed
of the fastest possible PC modem). However, the handset is generally only
GUARANTEED to provide audio up to 4KHz. That's why modems 'negotiate'
a baud rate by testing the line at the start of every call. They frequently
have to drop back to 19200 baud - or lower - when they happen to get a poor
circuit. A cell phone is on the lower end of that range...but I don't know
how bad. When I last used modems at home, I'd rarely get better than 9600
baud - even with a 56Kbaud modem at both ends of the link. It's worse still
over long distance phone lines because the telecom people 'reserve' some
tones for their own purposes and filter them out in the telephone exchange.
Some countries are worse than others though. Here in the US, all long
distance lines are now fully digital - so generally, long distance calls
are no worse than local calls.
Phones don't just fail to send the higher frequencies either. Some of the
low end of the audio spectrum is alsp cut off.
(One study done by British Telecom looked into the reasons why women
talk longer on the phone than men do. It turns out that male voices
suffer worse acoustic degradation than higher pitched female voices
do when put though a standard phone line - and that means that men
tend to get the message through as fast as they can and then get off
the line.)
> Do cellphones have echo (sound going into the microphone comes back,
> muffled, out of the speaker)?
All telephones do - it's a deliberate part of their design. This feedback
is called 'side-tone' and people find it hard to conduct conversations
without it. (You can tell that the line has 'gone dead' even when you are
the one doing the talking because the side-tone goes away).
Telephones are *NASTY* and have lots of weird quirks. You'd be far
better off buying a modem chip and taking advantage of all the hard
work the modem developers have put into working around the quirks of
real-world telephony.
> If so, then some sophisticated filtering
> code, or else just half duplex, will be needed. I don't notice it on mine
> in digital mode, but it's definitely there in analog. Weird. Or personal
> radios - are they half or full duplex? (I would assume half.)
Personal radio's that have a 'press-to-talk' button - are definitely
not duplex. Some others have automatic talk circuits - kinda like
a speaker-phone - that cut off the incoming line whenever they hear
you talking.
I don't know much about digital personal radio's though...maybe they
are more sophisticated.
> A half duplex conversation might look something like this:
> > 1>2: DATA1 DATA2 DATA3 CKSUM
> > 2<1: OK DATAA DATAB DATAC CKSUM
> > 1>2: OK DATA4 DATA5 ATD6A CKSUM
> > 2<1: BAD
> > 1>2: DATA4 DATA5 DATA6 CKSUM
> > 2<1: OK DATAD DATAE DATAF CKSUM
> > 1>2: OK DATA7 DATA8 DATA9 CKSUM
> > 2<1 OK DATAG DATAH DATAI CKSUM
>
These protocols are NOTORIOUSLY hard to get right. You have
to have a much higher level of paranoia than you are currently
exhibiting!
What happens if the message that comes back saying "OK" or "BAD" is
corrupted? That's just as likely as a data block being corrupt - yet
your proposed protocol fails miserably when that happens.
Think about that for a moment. The sender doesn't know whether or
not the message was recieved - all he knows is that the acknowlegement
that was sent back is screwed up somehow.
If he re-transmits the data block - then the reciever (who doesn't
know his acknowledgement didn't get through) gets the data twice
and will not know to reject the second copy.
The OK/BAD message must therefore have a CKSUM too. And all messages
have to have some kind of unique number on them so that the reciever
can tell when a message has been retransmitted.
Then - what happens if the response message is so badly corrupted that
it's not recognised as a message at all? The transmitter is waiting
for the ACK - but the reciever doesn't know that it's last ACK didn't
get through - so everyone is locked up. It's tempting to just time-out
and try again - but how do you know whether it was YOUR last transmission
that was erased or the other guy's response to it?
> OK and BAD would probably be special non-data tones.
That's a waste of bandwidth though. For your protocol to work, the
two computers have to know who is the 'transmitter' and who is the
'reciever' - and since the transmitter never sends the OK/BAD tones
and the reciever never sends the 'DATA' tones - they don't need to be
kept separate. You'd be better off using the data tones for 0 and 1
instead of the special OK/BAD tones. Fewer tones makes for better
noise rejection - which is definitely A GOOD THING.
Personally, I'd stick with just two tones and sending everything
in binary. With the two frequencies being better separated than
in the 20 tone case, you'll need a shorter burst of tone to
recognise them cleanly - and the probability of some noise being
mistaken for a tone is much smaller.
Computer modems use different tones for the computers at the
two ends of the link - because that makes it easier to reject
tones reflected back to the sender by the crappy phone system.
> Needless to say, full-duplex is faster.
...not necessarily! If you send data - and DON'T wait for the acknowlegement
before going on to the next block of data - then when you eventually hear
a "BAD" reply, you'll already have sent the NEXT block. Now, you have to
re-transmit the block that was lost - and the guy at the other end may
well recieve them out of order.
That means that he has to hold on to any incoming data just in case it
eventually turns out to be an out-of-order data block. Even if he gets
all of his data correctly and in order, there is still the risk that the
sender may have missed an "OK" reply - and therefore has to retransmit
that first block!
Now you have to number every block of data to ensure that things can be
re-ordered and stripped of duplication at the far end.
Remember that now that the acknowledgements are coming back after the
NEXT block is sent - so if an acknowledgement gets corrupted, you'll
hear the acknowledgement of the NEXT block next instead.
Since you are now sending a fairly large serial number with every block
of data, your data blocks have to be quite large or the cost of all those
serial numbers will eat into your bandwidth - big time!
Increasing the size of a block also increases the probability of it
being corrupted - which increases the number of retransmissions - and
the amount of memory the reciever has to use for holding out-of-order
blocks. Note also that because acknowledgements are coming back out
of sync, they also need to have a serial number and checksum.
The transmitter also has to store all the blocks he's ever transmitted
that have not yet been acknowledged.
All of this can mean that duplex links are actually something of a
mixed blessing.
There is a saying in the 'error-correction of unreliable communications'
business - which is that when you've solved ALL the problems in your
system, you'll have implemented something that's more complicated and
less effective than a full-blown TCP/IP stack.
You would probably do best to use a proper (but ancient) 1200 baud
acoustic coupler (these were *HORRIBLE* and didn't work worth a
damn - but they'll be better than anything you could build)...and
then use something like 'ppp' (point-to-point Internet protocol)
to deal with the handshaking.
It would be well-neigh impossible to do that with an RCX though.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
|
|
Message has 1 Reply:
 | | Re: A Generic Idea
|
| (...) There's a caveat you miss, it is limited using the forms of modulation that modems use (ie FSK derived). For example ISDN uses a different sort of modulation (ie Q-modulation) and it does 128k over the same phone lines. I use ISDN to connect (...) (22 years ago, 5-Jan-03, to lugnet.robotics)
|
Message is in Reply To:
| | Re: A Generic Idea
|
| (...) You could use an alternate firmware that can generate any tone, a custom modulation-demodulation protocol, and a condenser microphone soldered onto a sensor wire to send at reasonable bitrates for robot communication. Of course, it would take (...) (22 years ago, 5-Jan-03, to lugnet.robotics)
|
38 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
