>>>   Are you seriously expecting people to understand what's going on 
>>> there,
>>> without any kind of explanation?
>>>
>>>   I'm a programmer and I haven't the slightest idea.
>>
>> encode <key> <data> gives you a bunch of stuff. decode <key> <stuff> 
>> gives you back the original data.
>>
>> Which isn't that surprising. What's surprising is that if you add 
>> several of these together, the decode function still works. (Provided 
>> each data stream has a different key - or, more exactly, an 
>> "orthoganol" key.)
>>
>> Apparently this is how mobile phones manage to all transmit at the 
>> same time yet not screw up each other's transmissions.
>>
>> This much I would have thought would be vaguely intuitive from the 
>> program's output. Of course, to comprehend how I've implemented the 
>> encode/decode functions, you'd need to understand Haskell...
> 
> No wonder cell phones keep cutting out.
> 
> All it takes for a bit to be lost is for one analog "chip" to be
> a little outside of it's intended magnitude and then it misses
> the whole bit.

No.

Each signal bit is encoded by several analog "chips". If one such chip 
is lost (a very likely occurance, given that others are using the same 
chip frequencies concurrently), the remaining chips still allow the 
signal to be recovered. (This is precisely _why_ there are several chips 
to each signal bit.)

Add error-detecting and correcting codes on top of that and you have... 
well personally I find it fairly unusual for *my* phone to cut out. But 
then, my network seems to have unusually good coverage.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message