Debugin problem

Hi. I am running an RF system which consists of one FM transmitter and one FM receiver. The receiver output is buffered and fed to a number of LED display boards which each have a 16f627 with a 4MHz resonator.
Each LED display board has a two byte ID which is set in the pic programme as two constants and requires two bytes of data to do it's job.
So I will send over the RF link for example:

1,1,100,200

The code line in the pic that picks (ignore the pun) this up is:

debugin 1000,main,[wait(id_byte0,id_byte1),display0,display1]

The problem is I have to wait at least 130mS before I send another set of 4 bytes, otherwise the debugin line appears to not know it has finshed and carries on with the next byte, thus corrupting the result of the data.
The RF link has a 92byte buffer so I don't think it is the RF causing the problem.

If you rely on SOFTWARE to do your Comms reception, then you will have to rely on the timeout values built-in to the software... if you use the PICs USARTs then you can play with the data a microsecond (or less) after the PIC has caught it - and I don't mean using HSERIN as an alternative either! Go access those registers directly (full step-by-step instructions in the Datasheet).

There's so much rubbish built-in to the PICBasic serial routines to give you a shed-load of features (that most folks will never use but everyone wants) and make it easy to use (because people struggle handling 'byte-at-a-time'), that something has to give... and that something is speed.

If you don't believe me how bloated the comms software is... see by how many words your program grows when you try to catch ONE BYTE using SERIN, SERIN2, DEBUGIN or HSERIN. By accessing the PICs comms hardware (assuming it's a PIC that has a USART), you can do it in less than ten instructions (that's including setup).

I take your point Melanie but unfortunately the hardware is already in existence so I am stuck with using the software routines so I need to sort them out.

Well, there's only two choices then... (i) try changing the resonator to 8MHz (or faster) and pro-rata use a faster PIC to see if your latetcy is reduced, or (ii) roll your own serial I/O routines. Have you tried simply substituting SERIN for DEBUGIN as the routines are somewhat different?

Debugin produces less code and runs faster than serin or serin2 so you can use a slower crystal.
I have used it for 9600 baud comms with a 4MHz many times without problems so I find it strange that I have the problem with this particular app.

I'm afraid I wouldn't know how to go about doing my own routines.

9600 baud is right at the limit for a 4Mhz part... I always worry about designing products to run right at the edge... simple things like changes in temperature, humidity or supply voltage and suddenly things start falling apart.

Ok. Tried it with an 8MHz crystal and I get the same problem.

Now you have an 8MHz part, have you tried SERIN rather than DEBUGIN?

You can also bypass the wireless bit and do a direct temporary cable connection to double-check that the latetcy is in PICBasic's comms software routines.