08m2 serin bug

SAborn

Senior Member
Has the 08m2 (version 4.A) got a serin problem with baud N4800 at 4 meg.

I have a Dorji wireless module sending serial data to the 08m2, and at 4M , 4800 (N4800_4) all i get is zero in the data, but at 8M (N4800_8) all works perfect with the incoming data, the Dorji module is 4800 baud.

I spent hours trying to figure out why i could no receive data until i changed to 8meg clock.

It has me stumped!
 

hippy

Technical Support
Staff member
08M2 4.A works fine with N4800_4 when I test it ...

Code:
#Picaxe 08M2
#Terminal 4800
Do
  SerIn 2, N4800_4, b0
  SerTxd( #b0, " " )
Loop
Tested with data sent from 18M2 ...

Code:
#Picaxe 18M2
Do
  Pause 1000
  SerOut C.1, N4800, (b0)
  b0 = b0 + 1 
Loop
 

SAborn

Senior Member
I expected nothing less that it would work for you Hippy, it always do, its just seems to be me who has serial data problems.

This code works......

Code:
#picaxe 08m2
setfreq m8

main:

	serin  C.4, N4800_8, (">"), #w0
	sertxd (#w0, 13,10)
	goto main
And this code wont work........

Code:
#picaxe 08m2

main:

	serin  C.4, N4800_4, (">"), #w0
	sertxd (#w0, 13,10)
	goto main
I also tried it without the qualifier and no difference to the result, i just get "0" displayed in the terminal window for a value.

Its got me stumped!
 

SAborn

Senior Member
I should add the decoupling caps and supply rail caps are fitted and its a PCB not breadboard, tried a 08m and that works fine also at 8meg (you cant have 08m under 8meg for 4800 baud), tried different input pins and no difference.

Stumped!
 

Technical

Technical Support
Staff member
This is most likely to be an issue with the the third party module sending bytes of data back to back. At 8MHz the PICAXE is working twice as quick and so can handle data bytes that are much closer together. Remember that as you are using # the PICAXE has to do mathematical equations between each byte received to convert the ascii, and hence needs time to do this. If you want to receive high frequency data use a higher resonator speed, or hserin instead.
 

SAborn

Senior Member
Thanks Technical.

That makes perfect sense to the problem, when i get a chance i will test it without the # to see if there is a difference, i have no problem working at 8meg for the project, i was just stumped to why it would not function at 4meg.

Yes i had intended to use hserin, but i also need to add a I2C RTC to the circuit, and as hserin and I2C scl share the same pin i was unable to use hserin.
 

Goeytex

Senior Member
The 08M2 also suffers from somewhat inaccurate baud rates when set to N4800_4, N9600_8, N19200_16 and N38400_32.

At N4800_4, the 08M2 serout measures 4660 baud on a calibrated scope. My tests have shown that when using serin 4800_4, that the 08M2 "center" serin baud is 4608 and that it can only reliably receive data from between 4394 and 4818 baud. If your device is sending data slightly higher than 4800 the 08M2 cannot receive it reliably. Adding inter byte spacing helps with processor overhead issues, and may cover up the inaccuracy problem to an certain extent with multiple bytes.

Using hserout set to 4600 baud on another Picaxe, I can send eight back to back bytes all day long to an 08M2 set to N4800_4. This is with no added space between sent bytes. Sending at 4800 there will be errors.

If you set the 08M2 to N4800_8, not only is the baud rate much more accurate ( 4808) , data is also processed faster, possibly allowing multiple back to back bytes to be received without expecting the sending device to add inter-byte spacing.
 
Last edited:

inglewoodpete

Senior Member
I can only assume that there is sufficient variance in the internal resonators of the PICAXEs to get the baud rate issues that Goeytex had.

I haven't used the 08M2 extensively: just 2 projects to date. One of the projects was for a simple DMX512 protocol lighting controller, which requires a 250 kbits/sec async. serial data stream. I checked the pulse width of the serial to confirm my calculation of the baud rate divider: spot on 4 uS. At least that confirms that the calibration of my digital oscilloscope is the same as my 08M2's resonator!
 

Goeytex

Senior Member
I can only assume that there is sufficient variance in the internal resonators of the PICAXEs to get the baud rate issues that Goeytex had.
Testing indicates that the internal oscillator is not the issue at all. The internal oscillator is pretty much dead on with every chip tested. The software serial baud rate accuracy issue runs across the board on all 08M2s tested and only at the settings indicated in my post . If it were an oscillator problem, the baud rate accuracy problem would also show up at N4800_8. It does not. This software accuracy problem is related to firmware and it not only affects the 08M2 but every other Picaxe that I have tested.

Again it only shows up at 4800_4 , 9600_8, 19200_16, & 38400_32. It is so bad on the 20X2 that two 20X2's cannot send / receive a single byte between each other using serin / serout when both are set to 9600_8. Rev-Ed is aware this problem but It will likely get addressed about the same time that math brackets are enabled in Picaxe Basic.
 

Technical

Technical Support
Staff member
Again it only shows up at 4800_4 , 9600_8, 19200_16, & 38400_32. It is so bad on the 20X2 that two 20X2's cannot send / receive a single byte between each other using serin / serout when both are set to 9600_8. Rev-Ed is aware this problem but It will likely get addressed about the same time that math brackets are enabled in Picaxe Basic.
As has been documented numerous times on this forum, we do not agree with Goeytex' results or testing procedures.
There was an acknowledged issue with one of the 20X2 baud rates (but was not as bad as Goeytex makes out in this quote, as we never had any problem with 20X2 to 20X2 communication). This was fixed months ago and all 20X2 chips sold for several months now do not have the same issue. This has also been well documented on the 20X2 page for even longer than the new firmware have been sold:
http://www.picaxe.com/Hardware/PICAXE-Chips/PICAXE-20X2-microcontroller/


i just get "0" displayed in the terminal window for a value.
Going back to the original post question, on the 08M2, the qualifier was obviously being processed correctly, hence it cannot be a baud rate timing only issue. If it was this problem the qualifier would never be processed at all, and nothing would ever be returned in the data.
Hence the assumption that it is a back to back data issue, not a baud timing issue. Increasing the operating frequency allows the PICAXE to 'work quicker' between bytes and hence get the processing done before the next byte arrives.
 
Last edited:

Jeremy Harris

Senior Member
My experience with interfacing to hardware serial devices 100% supports the reason given by Technical. The main issue that I've encountered has been down to the small processing overhead between signals on the software serial ports. If a device responds to a transmitted command too quickly, then it is quite possible for the Picaxe receive port to not be ready quickly enough, particularly at low clock speeds. I first encountered this when trying to get the VDrive2 to work on the pre-M2 Picaxe chips, when I found that it would work OK if I used the hardware serial port but not if I tried to use a software serial port. A bit of investigation with an FTDI USB to serial board hooked up directly to the PC, sniffing the serial data, proved this to be the cause of the problem, beyond any reasonable doubt.
 

Goeytex

Senior Member
As has been documented numerous times on this forum, we do not agree with Goeytex' results or testing procedures.
And ...has been documented numerous times on this forum, I stand by my testing procedures and the actual results of those tests.

I also challenge forum members and Picaxe users (not employed by Rev ED) to do their own (objective) testing by hooking up a scope and taking some measurements.

@Technical

Do you deny that the actual baud rate of an 08M2 when set to N4800_4 is ~ 4660 ?
Do you deny that when using the settings I indicated that multiple Picaxe chips show a baud rate error of > 3%?
Do you deny that the baud rate error at these settings can cause problems?

You are glossing over the known baud rate problem at these settings while attacking my test procedures. I have been called both unfair and deceptive in this forum by either you or hippy in regards to serial baud rate inaccuracy problems. Ad hominem. Shoot the message, then shoot the messenger.

Speaking of testing procedures, I suppose Hippie's test above and getting one valid byte is a good and valid procedure?"

While I see that the firmware problem with the 20X2 may have been fixed In C.3, you initially denied that problem in C.2, and I had to pull teeth to even get it acknowledged. Now you say you never saw a problem with 20x2s communicating with each other at 9600_8, while every with every test I did with multiple 20X2 ( Firmware C.2) not one byte was reliably received. I sir, question both your testing procedure and your objectivity.

If we listen to you, baud rate accuracy seems not to matter at all, and everything is "fixed" by adding a gap between bytes. This is simply not true.
 

neiltechspec

Senior Member
For what it's worth :-

I have half a dozen or so 08M2's running serin @ T9600_16 catching a 33byte strings over RS485 (via MAX485 chips) without any errors. Wouldn't work reliably at T9600_8.

Also a few 08M2's running serin @ T19200_32 catching 20byte strings direct from PIC chips without any errors. Wouldn't work at all with T19200_16.

I cannot add gaps between the incoming bytes as they are from external devices (Solar Inverters & Radio PIR Receivers) over which I have no control.

Oh, nearly forgot about the 08M2 using serin @ T9600_16 capturing from a HAICOM Serial GPS module, also captures without errors.

So I would only consider using T4800_8 (or N4800_8) if I wanted to receive reliably at that baud rate.

Neil.
 
Last edited:

srnet

Senior Member
I have half a dozen or so 08M2's running serin @ T9600_16 catching a 33byte strings over RS485 (via MAX485 chips) without any errors. Wouldn't work reliably at T9600_8.
That makes sense.

At higher processor clock speeds serin does have time to process incoming characters.

At lower processor clock speeds serin does NOT have time to process incoming character.

Not a bug of course.
 

Jeremy Harris

Senior Member
That makes sense.

At higher processor clock speeds serin does have time to process incoming characters.

At lower processor clock speeds serin does NOT have time to process incoming character.

Not a bug of course.
Absolutely right, this isn't bug at all, just a function of the way software serial ports work. One consequence of this is that the measured baud rate may well seem to be off when measured with some methods. For example any echo character type method will also end up measuring the latency in the software processing, rather than the true baud rate in pulse timing terms.
 

Goeytex

Senior Member
To quote yourself;

"Do you deny that the actual baud rate of an 08M2 when set to N4800_4 is ~ 4660 ?"

So what was the measured serout baud rate ?
I provided that information in post #7, about 3 lines down. I am unsure as to why you are asking that question when the answer was previously stated and also rather clearly implied in what you quoted. But, I'll play along .....

To be clear and precise.... I just measured the baud rate of serout N4800_4 of an 08M2 (Firmware 4.A) operating @ 4MHz to be between 4648 and 4652. The bit width measures 215.1 us. There is no measurable difference between a mark and a space.

And as a bonus ....I measured 4797 baud when set to N4800_8 and 4797 baud when set to N4800_16.
When set to N9600_8 the baud rate, it measures 9294 and at N9600_16 it measures 9594.
 

bpowell

Senior Member
I ran a quick test on a 08M2...I set up 4800_4 on pin C.2 (serout) and then HSERSETUP B4800_4, %00.

I sent out "UUU" both times, and measured the time between the shortest bit...I measured 208us on the hardware serial output...(1/.000208 = 4807 baud) and 216us on the software serial port (1/.000216 = 4629 baud)

This is with a un-calibrated MSO-19 USB O-scope from Sparkfun...still; good results.

T4800 HSEROUT.JPGT4800 SEROUT.JPG
 

srnet

Senior Member
I am unsure as to why you are asking that question when the answer was previously stated and also rather clearly implied in what you quoted
I am unsure, now, why I asked.

Indeed as you say the information is there in post #7, I must pay better attention.
 

Jeremy Harris

Senior Member
I ran a quick test on a 08M2...I set up 4800_4 on pin C.2 (serout) and then HSERSETUP B4800_4, %00.

I sent out "UUU" both times, and measured the time between the shortest bit...I measured 208us on the hardware serial output...(1/.000208 = 4807 baud) and 216us on the software serial port (1/.000216 = 4629 baud)

This is with a un-calibrated MSO-19 USB O-scope from Sparkfun...still; good results.

View attachment 14113View attachment 14114
This perfectly illustrates the point that the software serial ports have a small processing overhead.

It's worth bearing in mind the fundamental difference between baud rate (the number of times the signal changes state in one second) and bit rate (the number of data bits transmitted in one second). I have a feeling that this difference may be at the heart of some of the views expressed here regarding serial port timing. In particular, I have a feeling that the inherent slight processing latency delay with a software serial port might be being confused with a variation in baud rate.
 

Dippy

Moderator
Overheads on a soft serial are standard issue, it goes without saying surely.

It's interesting to see the variations in various compiler's soft asynch and compare them to hardware asynch.
I've had funnies in the past with soft comms ... and when you look at the code you can understand and be a little more 'forgiving'.

Latency/overhead discussions are interesting, but the bottom line is do they work within spec in the Real World?
Obv we have to be a little tolerant on an unbuffered soft micro.
 

Goeytex

Senior Member
I am not saying and never have said that latency/overhead is not an issue with Picaxe software comms. What I am saying is that the baud rate can cause problems as well. Consider the code posted by SABORN in post #3. It doesn't work at N4800_4 and is does work at N4800_8. What changed?

Some will say the processor clock frequency and then attribute the the problem solely to processor overhead. However the fact is that more than 1 thing changed. Both the processor clock and the baud rate changed. The clock doubled and the serin baud rate changed from ~4650 to almost dead on 4800. Should we automatically assume then that only one of the two changes was responsible for the improvement? No. That would be bad logic. Good logic would suggest that it might be because of 1. Clock speed alone. 2. Baud rate alone or 3. A combination of both. or 5. either or . Further more, we do not empirically know the actual baud rate and latency of the signal being sent from the Dorji Module, nor do we know the value of the data that was sent. (What if the Dorji module is sending data at 4950 baud?) Probably not since I imagine the controller on the Dorji is using a hardware UART.

So I set up a little test where I could change the baud rate being sent to 4650 to match the baud rate of the 08M2 at N4800_4. Guess what? It worked up to a point. When sent hserout 0, (0,"127") the 08m2 received and displayed 127. Now let me say that I do not fully understand what serin x.x, N4800_4,#w0 is actually looking for. How many bytes of data does it want to proceed? I personally have never used #variable with serin and really see no benefit in using it, except possibly to save a few bytes of program memory (at the expense of complicating serial comms)

It also worked when I set the transmitter to send at 4650 baud ( no added latency) and the receiving Picaxe to N4800_8. It also worked when the sent baud rate was 4800 and the 08M2 was set to N4800_8 ( as Saborn previously indicated). I could never get the qualifier to work properly at any combination of settings when using #Wx as the input variable with serin.

So it seems that baud rate does make a difference and so does increasing the clock speed. Folks can draw their own conclusions. You can even pooh - pooh on my testing procedures if you want. I don't really care at this point.
 
Last edited:

Technical

Technical Support
Staff member
Goeytex,
We are not attacking you in any way. However in this thread you made original statements that were simply not correct. We are trying to support the original posters of problems by giving them accurate and helpful answers to their specific problem.
The thread is about a third party radio module to an 08M2.

You confused the original post problem by moving on to discuss the known documented issue with the 20X2. This has this been fully acknowledged and corrected, but you originally stated this “had not been addressed” in your quote 7 – now actually later edited out by yourself but re-quoted in our post 10. This was simply untrue, it was fully fixed months ago and it is extremely unfair to continue implying that it is a known fault and that nothing has been done about it. It is also not relevant to the original post problem, which was using an 08M2.

When we fixed the 20X2 we extensively and comprehensively reviewed the serial in/out commands of *all* chips. They are all now what we consider to be acceptable (the 20X2 wasn’t which is why it was changed). Some are more accurate than others, but we consider them all acceptable, including the 08M2. You quote a measured baud of 4660 on the 08M2, which is a bit time of 214. As stated in our document 196 to 221 is acceptable. You might not like that or agree with our definition of ‘acceptable’ values - that is your opinion and your right - but we are happy with the tolerances. We would expect a baud of 4660 to work just fine with the radio module described in post 1.

www.picaxe.com/docs/baudratetolerance.pdf

All PICAXE chips will have some variation from the ‘ideal’ bit time, it is simply not possible in a highly compacted bit busted firmware to get every single baud accurate to the exact usecond. However, as has been explained in the serial timing document we already published this will not generally be an issue. Quite literally hundreds of thousands of 08M2 users have also found this to be the case! We won’t duplicate that info here again – it’s in the pdf document.

Our general opinion is that in forum posts you repetitively imply that it is likely to be a baud bit timing issue on any post where a user has a serial problem. In this case it simply can’t be that the bit timing is too far off to work – the OP was using a qualifier of ‘>’. If the bit timing was so bad then the qualifier would NEVER be processed at all, and the program would be permanently stuck on the serin line. This is not the case - the qualifier is being processed fine.

That is why we suggest, as we are trying to provide good technical support to the initial problem, that it is far more likely to be a ‘between byte’ processing issue that will be helped by running the PICAXE at a higher processing speed.
 

Goeytex

Senior Member
You confused the original post problem by moving on to discuss the known documented issue with the 20X2. This has this been fully acknowledged and corrected, but you originally stated this “had not been addressed” in your quote 7 – now actually later edited out by yourself but re-quoted in our post 10. This was simply untrue, it was fully fixed months ago and it is extremely unfair to continue implying that it is a known fault and that nothing has been done about it. It is also not relevant to the original post problem, which was using an 08M2.
If you look at the time stamps of the post and the edit. You will see that the edit was done within a few minutes of the original post. I think common sense would then suggest then that statement was removed because I didn't want to include it in the post. I review all of my posts after sending them to make sure it was what I wanted to say. This why the many of my posts are edited.

However, I do indeed disagree with a serial baud rate tolerance of +- 6% as being acceptable. I know of no other company that would call that acceptable and be "happy" with it.

Imagine what might happen the if the peripheral manufactures adopted such a loose standard? There would be a lot of "unhappy" micro users while the "happy" manufacturers blamed each other for comm problems.

It is better to strive for excellence than than to be "happy" with the bare minimum.
 
Last edited:

Technical

Technical Support
Staff member
4660 is about 3%, not -6% of 4800. It can be well inside the 6%, but not 0%, and still be acceptable to us.
 

Jeremy Harris

Senior Member
Worth looking long and hard at that comment about the required timing accuracy adopted by peripherals manufacturers, Goeytex. The old RS232 standard is remarkably tolerant of timing inaccuracy issues; it had to be as the transmitters and receivers were electromechanical (my first job involved working on the things!). A typical full 12 bit RS232 serial "byte" could accept something like a 5% timing error and still work OK; asynchronous serial was deliberately designed to be tolerant of such timing errors (there's a clue in the name "asynchronous"). Most hardware UARTs try to stay within around +/-2% or so timing error, but they don't actually need to as long as full RS232 type protocols are used, it's simply that they can because they use a stable clock to generate the timing signals (something that RS232 was never really designed for).

+/- 3% is absolutely fine, even for the no handshaking cut-down protocol that we typically use. After all the only real issue with timing is whether or not all transmitted bits in a single transmitted byte get through the receiver "gate" with enough spare time for each to be read correctly. As bits are (or should be) read around the centre of each bit timing window, there is a fair bit of room for timing errors built in to the protocol.
 
Last edited:

Goeytex

Senior Member
4660 is about 3%, not -6% of 4800. It can be well inside the 6%, but not 0%, and still be acceptable to us.
This is irrelevant to my post above. I can do the math just fine.

I did not state or imply that 4660 represented a -6%. error. I was referring to the document at http://www.picaxe.com/docs/baudratetolerance.pdf and where you stated:

As stated in our document 196 to 221 is acceptable.
These numbers represent an error tolerance of +- 6%. Personally I would be embarrassed to have to defend such a loose standard.

It is quite clear now what Rev-Ed considers "acceptable" and what they are "happy" with.
 

nick12ab

Senior Member
asynchronous serial was deliberately designed to be tolerant of such timing errors (there's a clue in the name "asynchronous")
Really? I thought that 'asynchronous' referred to the lack of a separate clock signal whereas 'synchronous' serial has got one so timing isn't very critical at all for synchronous serial.
 

Jeremy Harris

Senior Member
There couldn't be a clock signal for the original application that this standard was created, hence it had to be asynchronous and had to be relatively insensitive to timing errors. After all, the signal source (and the receiver detection system) used a rotating electric motor to derive it's timing, and although this was usually synchronous (locked to mains frequency) the motor speed would drift a bit from friction, load variations etc and cause some timing errors.

The serial communications protocol we still use has its roots (and baud rates) derived from those slow mechanical interface machines. Even the way that the detection window is centred on the pulse, rather than using a pulse edge, is a key to the way that this system was designed to be relatively tolerant of timing errors. The pre-RS232 system was even more tolerant, as it only used 5 bits for data, meaning that total transmitted character length (including stop and start bits) was shorter, giving it greater tolerance to timing errors (the limit being when the last transmitted bit slips outside the receiver gate).
 

Jeremy Harris

Senior Member
I suppose it is better to say the nature of asynchronous serial means it will have tolerance to timing errors, that the design of asynchronous serial takes advantage of that.
Yes, this is what I really meant.

When you look at the way the start bit engaged the clutch to start the shaft spinning, and then the bits were received over one shaft rotation by sensing whether the line was in a mark or space condition at the centre (if it was well-adjusted) of each bit, it's pretty clear that the protocol was designed from the start to be tolerant of timing errors. IIRC, some machines had a tuning fork and small window looking at a disc on the end of the motor shaft, so you could check the baud rate by strobing the tuning fork against marks on the disc. By the time I was playing with them in the early 70's things had moved on a bit and most of the switching was by relays, rather than cam driven switches...............
 

rossko57

Senior Member
Crikey having flashbacks here ... Teletype ASR33 a triumph of production engineering; cheap stamped-out parts, adjust by bending
 

bpowell

Senior Member
It's worth bearing in mind the fundamental difference between baud rate (the number of times the signal changes state in one second) and bit rate (the number of data bits transmitted in one second). I have a feeling that this difference may be at the heart of some of the views expressed here regarding serial port timing.
Please explain the difference between baud-rate and bit-rate in serial communications. I honestly thought they were one-in-the-same in a serial communication protocol where there are only two options 1 and 0 for the bits.

Can you please also tell me how to calculate the baud rate vs. bit rate of serial comms?

Thanks!
 
Last edited:

bpowell

Senior Member
It's interesting to see the variations in various compiler's soft asynch and compare them to hardware asynch.
I've had funnies in the past with soft comms ... and when you look at the code you can understand and be a little more 'forgiving'.
I imagine the PICAXE has a formula it uses to calculate the delays for baud rates...I also imagine it's just one formula that handles all the variables...and therefore, subject to being low on one end, and high on the other...I'm still HIGHLY IMPRESSED with what the PICAXE can do...I'm still learning how to program a software serial port on a PIC...it's not trivial to me...and I'm not trying to account for every possible CPU frequency and baud-rate! Like you said, I'm willing to be 'forgiving'.

Latency/overhead discussions are interesting, but the bottom line is do they work within spec in the Real World?
Obv we have to be a little tolerant on an unbuffered soft micro.
This is the bottom line...does the communication protocol work? If not, then we need to make changes. I find this thread interesting, as it's good to know the PICAXE may have some trouble with software serial at the upper-threshold of baud-rates for a given CPU frequency...I can either up the CPU frequency, or make changes to the sending device (if possible).

This is all good information, and one of the reasons I love this product and forum.
 

bpowell

Senior Member
I also challenge forum members and Picaxe users (not employed by Rev ED) to do their own (objective) testing by hooking up a scope and taking some measurements.
Hi Goeytex,

How do you test what the PICAXE actual receiving-baud rate is? I'm able to test the transmitting baud rate by simply sending data and scoping it out...but I can't figure how to test the receiving-baud...other than to have another PICAXE sending data at an ever-increasing baud rate, and seeing when it starts to work (that'll give me the low-end) and when it fails (that'll give me the high-end) and I assume the middle of that bracket is the "Receiving rate"...is that right? If you could share how you test the receiving-rate, that would be great!

Thanks!
 

westaust55

Moderator
Please explain the difference between baud-rate and bit-rate in serial communications. I honestly thought they were one-in-the-same in a serial communication protocol where there are only two options 1 and 0 for the bits.

Can you please also tell me how to calculate the baud rate vs. bit rate of serial comms?

Thanks!
Rather than me plagarising from other sources, suggest that you have a read here:
http://electronicdesign.com/communications/what-s-difference-between-bit-rate-and-baud-rate
http://www.tech-faq.com/difference-between-bit-rate-and-baud-rate.html
http://answers.yahoo.com/question/index?qid=20090701171314AAo5hAr
http://en.wikipedia.org/wiki/Baud

There are about 1.5 million hits for a Google search on this (Baud vs bit rate) topic.
 
Last edited:

bpowell

Senior Member
Thanks Westaust55...I'd already been down this road, and those links only further reinforce my idea that in Serial comms such as the PICAXE is using (only two possible bit states, 1 and 0) bit-rate = baud-rate.
 

Goeytex

Senior Member
Hi Goeytex,

How do you test what the PICAXE actual receiving-baud rate is?

Thanks!
I used 2 Picaxe Chips as you suggested. I might suggest that you use an 08M2 as the sending device with Hserout since hserout on the 08M2 matches the the 8N1 specification in that there is no extra space added between bytes. Some other Picaxe chips using hserout do not truly meet the 8N1 specification in that there is added space between bytes. This added space is generally not a problem, but will skew the testing results. Most , but not all peripheral devices will send data at a true 8N1.

I posted some code Here that might be helpful.
 
Top