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.