How many bytes can hserin on 20x2 read?

Is there a limit to the number of bytes that hserin can read at one time using a 20x2?

I have a system that sends an 82 byte string @ 9600 baud. It was set up to send to a BS2 and so transmits fairly slowly with 20 milliseconds between bytes. A 20x2 reads the data fine up to about 55 bytes, but it either ignores or garbles anything further. Test code below, what am I doing wrong?

I always assumed it could read up to 128 characters, although to be honest I have never tried that many. Perhaps there is a small timing error that begins to cause framing errors after 55 bytes. Maybe you could try to calibrate the internal clock.

Thanks for the suggestion. Adjusting the clock I can get to around 70 bytes, but with errors in the data, with the unadjusted clock the number of bytes is limited but the data is solid. I also tried clocking at M16 and M32 without significant improvement.

The fifo has space for two characters, so if your getting data drop out, then your spending too long in your programme before the next HERSIN.

When you switched to M32 did you use 9600_32 instead of 9600_8 ?

g6ejd said:

The fifo has space for two characters, so if your getting data drop out, then your spending too long in your programme before the next HERSIN.

Click to expand...

Sorry, I don't understand, could you explain that? Doesn't hserin discard chars until it sees the next qualifier?

When you switched to M32 did you use 9600_32 instead of 9600_8 ?

Click to expand...

Oh yes, m32 + 9600_8 = garbage. (I appropriately changed the terminal command too.)

-.-

FWIW I can reliably receive all 82 bytes using M32, serin, and reading/putting the data into the scratchpad byte by byte.

I hooked up an 08M2 to a 20X2 and sent 100 bytes from the 08m2. The 20X2 receives all 100 bytes perfectly. The 20X2 code is identical to yours, except for Hserin looks for 100 bytes and I am using sertxd (#@ptr) instead of sertxd @ptr so that all bytes are displayed.

My guess is that the timing between the sending device and the BASIC Code is off. Could be that the sending device starts sending data while the basic code has just timed out.

I cannot imagine that the frame rate ( baud rate?) of the sending device is that far off. The accuracy of the Picaxe hserin command is excellent, being very tolerant of high and low baud rates. However, if you have a scope it may be a good idea to look at the baud rate of the sending device.

Below is the code I used for the 08M2 as the sending device

I don't think the baud rate is inaccurate, otherwise I would see more garbles in the data and in my testing I only saw garbling when trimming the clock frequency. The data received is good, it just seems to choke after 50 or so characters.

As to the "sending device starts sending data while the basic code has just timed out", sure, there are timeouts, but it just waits around until it sees the qualifier again - doesn't it?

I'll certainly try the test you suggest and report back.

I did see an old thread of yours discussing inaccuracy of the 20x2 baud rate and wondered if that might be the cause, but based on your comments I guess that is all resolved now?

I have used hSerial on a 20X2 to receive up to about 40 bytes at 115200 baud with the PICAXE running at 64MHz. The code is documented here. Admittedly, the serial data was being transmitted by another 20X2, so the speed match should have been good. 9600 baud should be a doddle.

I notice that you're using a SerTxd command. You can't use SerTxd during hSerial reception. The SerTxd is a bit-banged output so, during transmission, kills off the hSerial port interrupts, resulting in lost data.

Edit: I've just noticed that you're using foreground hSerial reception, so my comments above are not that relevant. I always use background hSerial, to ensure that no data is lost due to the code execution being somewhere else when data arrives.

inglewoodpete said:

Edit: I've just noticed that you're using foreground hSerial reception, so my comments above are not that relevant. I always use background hSerial, to ensure that no data is lost due to the code execution being somewhere else when data arrives.

Click to expand...

The frequency of data packet transmission is somewhat variable since the PC may have other things on its mind, and the picaxe will spend time handling the received data before it's ready for more, so I decided to have the receiver just loop waiting until it catches the qualifier at the start of a packet. I'm not worried about losing packets, they are sent redundantly and it's only driving a max7219 display.

I looked at background hserial but it doesn't appear to take a qualifier, but maybe I'm wrong.

Since my slower(?) executing serin solution works I'm wondering if it's the intercharacter delay that's causing a problem.

I did see an old thread of yours discussing inaccuracy of the 20x2 baud ...

Click to expand...

That only applied to software serout /serin and only at particular settings. Hserin has no problems that I am aware of. I use it quite a bit at up to 115K baud with no issues.

Whats up with the qualifier ? Why do you need one ? Perhaps if you explain what the sent data packet actually contains ,ie where the qualifier is located in the packet ....etc ... Are you picking 65 bytes starting after a "W" from a larger stream of data ?

I can tell you that there is nothing wrong with your code or with hserin on the 20X2. There is either something wrong with the hardware, board layout, grounding, etc, or there is something wrong with the quality of the data being sent. There is a remote possibility that you have a duff 20X2. Do you have a scope or a logic analyzer ?

I looked at background hserial but it doesn't appear to take a qualifier, but maybe I'm wrong.

Click to expand...

While background hserial does not have a qualifier, there are certainly ways to qualify the received data.

Goeytex said:

I can tell you that there is nothing wrong with your code or with hserin on the 20X2.

Click to expand...

I agree completely, I did a similar test to yours and had no problem getting >80 bytes.

There is either something wrong with the hardware, board layout, grounding, etc, or there is something wrong with the quality of the data being sent. There is a remote possibility that you have a duff 20X2. Do you have a scope or a logic analyzer ?

Click to expand...

I think it has to be a data/timing issue, anything else and I doubt it would be receiving 50 bytes correctly. For some reason only the picaxe hserin cares about it, my serin code is rock solid, as is a bs2. Yes, I do have a scope, not a digital/storage though so it's of limited use for this.

Whats up with the qualifier ? Why do you need one ? Perhaps if you explain what the sent data packet actually contains ,ie where the qualifier is located in the packet ....etc ... Are you picking 65 bytes starting after a "W" from a larger stream of data ?

Click to expand...

The packet has a three byte preamble "WXD" (multi byte qualifier for a bs2) followed by 80 bytes of data and validation. Since I can't guarantee that the receiving end is going to be listening when the PC starts sending a packet I decided to just keep banging the packets out each few seconds and use the qualifier to pick up the start of the next packet. It's worked fine for quite a while with the bs2 and I would prefer not to change the system, just be able to use a 20x2 instead.

Pongo said:

starts sending a packet I decided to just keep banging the packets out each few seconds and use the qualifier to pick up the start of the next packet.

Click to expand...

How do you know the data doesn't contain a 'W' and hence sync is starting in the wrong place?

Technical beat me to it. For example if there is a "W" 20 bytes deep into the data packet and the timing is off, then it what might happen?

Why not use background hserial with the hserial interrupt set. Receive the entire packet into the scratchpad. Then look for the WXD sequence at the beginning of the scratchpad and process the bytes that follow. The following code shows how it can be done.

Goeytex said:

Technical beat me to it. For example if there is a "W" 20 bytes deep into the data packet and the timing is off, then it what might happen?

Click to expand...

That's covered two ways, a) by design the packet only contains delimited numerics after the qualifier, and b) if the receiver misreads a byte as a "W" and grabs a malformed packet the validation step will fail and it will loop back to listening for the next "W". The packets are sent redundantly so missing some is not an issue. (The qualifier is really "WXD" which is more robust than a single character but as we know picaxe hserin doesn't support that.)

Why not use background hserial with the hserial interrupt set. Receive the entire packet into the scratchpad. Then look for the WXD sequence at the beginning of the scratchpad and process the bytes that follow. The following code shows how it can be done.

Click to expand...

I will certainly take a close look at this method later and reply.

Goeytex said:

Why not use background hserial with the hserial interrupt set. Receive the entire packet into the scratchpad. Then look for the WXD sequence at the beginning of the scratchpad and process the bytes that follow. The following code shows how it can be done.

Click to expand...

Thank you very much for all your help and that example code. I made a test and (of course) it works very well. Now I need to hit the books and understand exactly what it is doing...