Re: Digest Number 5174

Not only were the microprocessors quite powerful with respect to the demands 
of the job described below, but amateur radio operators were communicating 
via packet radio (AX25 protocol), with sophisticated collision arbitration, 
in 1980.

Jim




Received from Onestone [email protected] [msp430] at 06/10/2015 
13:11  Wednesday UTC:

>well lots of us here are quite ancient! Single Chip Microprocessors have 
>been around since 1971, multi-chip even longer, and microcontrollers since 
>1974 (TMS 1000), although they were probably popularised by the 8048 
>becoming commercially available in 1977, and by the mid 80's there were 
>probably billions of them hiding in keyboards. I think the micros were not 
>as limited as you might think. Simple first generation PICs, for example ran 
>one of the most sophisticated robotic semiconductor furnace robotic transfer 
>systems in the world, you could build an engine management computer on an 8 
>pin PIC, etc. I think one huge limiting factor compared to today was the 
>cost of memory, the lack of reliable non-volatile memory that was in system 
>programmable, and the lack of advanced sensor and RF technologies that were 
>suitably small.
>
>Al
>
>
>On 10/06/2015 8:01 PM, Stephen Farthing 
><mailto:[email protected]>[email protected] [msp430] wrote:
>>
>>Hi,
>>
>>Before most of you were born I used a LAN product, called Planet, by RACAL 
>>to connect 2 mainframes and a few minicomputers to a Cambridge Ring fibre 
>>optic network of a couple of hundred terminals. The problem you face is 
>>similar to the one that Planet had to overcome in that it was possible for 
>>"packets" from two stations could collide on the network. The planet system 
>>implemented a system called "exponential back off" . Now I am pretty rusty 
>>now however I seem to recall it worked a bit like this. The system 
>>monitored the time it took from a packet to be transmitted to the receipt 
>>of an acknowledgement that the packet was received. If the system did not 
>>receive the acknowledgement within the expected time it assumed that the 
>>packet was corrupted. So it knew it needed to re transmit it. But it did 
>>not do this immediately, it waited a little before sending it again. If the 
>>system did not receive an acknowledgement, it waited a longer time before 
>>retransmitting it. And so on. There would come a point at which the system 
>>would decide that the "receiver" was not there, record some sort of error 
>>message and give up.
>>
>>Given that this technology was used in the mid 1980s, when micro 
>>controllers were not really around and microprocessors were mostly 8 bit 
>>with limited capabilities compared with what we have now I am pretty sure 
>>this would be quite easy to implement on an MSP430 system.
>>
>>Hope this helps,
>>
>>Steve G0XAR



------------------------------------
Posted by: Jim Higgins <[email protected]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[email protected]