Redesigned RIB?

[Tishers]

Since it appears that the RxD line on many moto products is very sensitive to timing; eg: issues with fast computers would a redesign of the RIB be a worthwhile project?

Right now it is all asynchronous from computer, through RIB to radio. When we run a faster computer or an OS that plays the middleman with serial communications we get what amounts to "slips" in bit timing that can corrupt a codeplug.

It seems that the radio would rather be synchronous. Eg, a data stream locked into a very specific baud rate with clocking skew.

It would not be that hard to make a RIB device that takes our wobbly, asynch data from the computer and lock it down into a very rigid baud rate. It could be done with a pair of UART's (6402), a FIFO buffer, clock reference and the associated EIA-232 converter circuitry for the computer side.

The first UART that is attached to the computer would run free-wheeling and take the serial data stream and convert it into parallel. I could even tie handshaking into the serial port (RTS/CTS) (DSR/DTR). The converted parallel bit stream would be fed into a FIFO device with just a few bytes of storage. On the other side of the FIFO the parallel bits are "clocked" into another UART that is also clocked at a data rate that the radio would love. The serial stream would go through some associated drive circuity and into the radio.

Once I get my test bench back together again I may experiment with how much the serial stream slips. I have a Navtel serial protocol analyzer and a TBERT where I can really get into the nitty-gritty of what the computer can do and what the radio can do. (as a comparison between clocking and slips).

It would be a hardware converter with no PIC or microprocessor to be found. Essentially it is a baud rate converter with just enough memory to account for slight differences.

Offer your opinions, this will be a good fall project.
AA4HA

[Will]

Most of the Motorola RIB / RSS issues are the fault of the p.. poor Radio Interface BoX design. I have been keeping up with this since 1988.
Lots of engineering changes in the RIB were made by our shop and some are available that correct the timing problems and incompatibility with the computer's RS232 interface..

A new road map of the latest changes is due on here very soon..

Even a new design from us for anyone to build... soon.

Also see: http://batboard.batlabs.com/viewtopic.p ... 11#p410211

[Tishers]

I took a look at the schematics for a Maxtrac and see where they have a bi-directional buffer chip between the programming interface and the CPU. In theory this should be able to cope with a little bit of jitter.

Now if the stinkin computer serial port just inserts large pauses into the data stream the buffer chip may interpret those as 1's or 0's and corrupt what is going into the CPU. My FIFO idea would eliminate those pauses but in turn, may add latency that could cause RSS or the radio to timeout the connection (if the FIFO buffer was too big).

In my paying gig I deal with these sorts of issues, timing sensitive serial protocols and the problems of pushing those across a radio network or in interconnecting different systems with what both vendors loosely interpret as a standard.