I have pulled down the datasheet on the RPC and now understand what your problem is. The error handling of the RPC consists of eliminating packets with errors. You have two separate problems. 1. Packet flow control over the radio link. The data you put into the RPC packet consists of a serial number and data. The PIC at the receiving end (you are using a PIC at that end of the radio link as well aren't you 8-)) uses the Serial number to reassemble the data in the correct order and sends a packet back to the transmit end consisting of the serial number and an ACK (acknowledge) when the packet has been received or the serial number and a NACK (Negative Acknowledge) if it detects that a number in the sequence is missing. I'll let you work out the rest. 2. Do you handle the flow control of the packets being received on the UART in the 877 or do you pass the whole packet unprocessed across the radio link to be handled by the terminal device? In other words despite the impression that the datasheet of the RPC may give on cursory examination, it does not remove from you the need to understand how packet systems work, their strengths and weaknesses, so you can implement either a standard scheme or one of your own. My suggestion is to look at the Grand-daddy of them all, Aloha. Use your Search Engine. 60's technology which makes it easy to implement on a PIC. Regards Chris Carr ----- Original Message ----- From: "Laurence Evans" To: Sent: Monday, November 05, 2001 10:03 AM Subject: Re: [PIC]: 16F877 for Serial Data packet transfer > the data is being sent Via a radio data link with a bandwidth of > aroung 40kbps. i am using a radio packet controller that i have got > from RadioMetrix.co.uk. This RPC only accepts 4 bit nibbles and > up to a 27byte packet. my problem lies in that the PPP data i wish > to send over this link is a minimum of a 64 byte packet. > > thanks > > Laurence Evans wrote > > > > > > I am trying to develop a programme the takes packetized data from > > > the inbuilt UART of the 16F877 which can be anything up to 100 > > > bytes long and then re-packetize it to be sent using a four bit > > > nibble to another PIC but these packets can be up to 27 bytes long. > > > I have to re-assemble the origonal packets at the other end of the > > > link as well. > > > > > > Does anyone know the easiest way to re-format packetized data?? > > > > > The approach I would take is to not bother re-format the data but to > > wrap the packetised data in another packet (or in your case several > > packets). Reassemble the original packet at the end of the link and > > then disassemble that packet which will then reveal the data. > > Of course it's not the most efficient use of bandwidth but then > > bandwidth is cheap and virtually unlimited these days. > > > > Two things. You fail to define the characteristics of your Physical Layer > > and the minimum end-to-end performance expected from the system. > > This of course has more than a slight bearing on the best approach. > > > > Secondly, why are you breaking up your byte formatted packets into nibbles > > to put them into byte formatted packets ? It seems an unnecessary overhead > > I can understand you breaking them up to put them into nibble orientated > > packets. > > > > Regards > > > > Chris Carr > > > > -- > > http://www.piclist.com hint: The list server can filter out subtopics > > (like ads or off topics) for you. See http://www.piclist.com/#topics > > > > > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body