Cailbfreq on a 20x2

SAborn

Senior Member
The 20x2 has a common problem (never had one yet that has not) of needing the calibfreq adjusted to eliminate errors in data from sertxd or serout commands.

My question is the manual says from +15 to -15 is the range set able on calibfreq, but i have a chip that requires -30 on calibfreq to get a consistent serial data reading, can someone explain why the manual says -15 is the limit when i need to load -30 to get the thing to work correctly.
From what i can determine from the pic data sheet is a calibfreq of -32 (or +32) should be able to be achieved.
So why is +/- 15 listed as the limits.
 

srnet

Senior Member
Strange, I have used 3 20X2s now.

Never had a problem with sertxd that I recall, never needed Calibfreq.

And if you need to adjust it to get consistent results from sertxd, how do you download programs ?
 

Goeytex

Senior Member
Strange, I have used 3 20X2s now.

Never had a problem with sertxd that I recall, never needed Calibfreq.

And if you need to adjust it to get consistent results from sertxd, how do you download programs ?
Same here, I have done quite a bit with 2 20x2's communicating with each other an have never needed to use
calibfreq.

Found this in the snippits section and may be useful.

http://www.picaxeforum.co.uk/showthread.php?19603-Automatic-frequency-calibration-finetuning-of-internal-PICAXE-resonators


So I tried the calibration technique above using an 18m2 as the master and then ran it on 2 20x2's. One indicated a calibration factor of 1 and the other a calibration factor of 2. Very close.
 
Last edited:

Technical

Technical Support
Staff member
As stated above, if you really need to calibrate sertxd you should also have never been able to download a BASIC program to the PICAXE chip start with... so something in your system is not quite right. What are you trying to communicate with?
 

SAborn

Senior Member
If i run a loop of sertxd and send "U" every so often i get corrupt data and by adjusting the calibfreq this solves the corrupt data.

Now it is also worth pointing out this appears to only be the case when used with usb to serial cables, namely the Ritmo cables, if a direct com port is used no need for calibfreq, but it is only the 20x2 chip that gives problems here and never had problems with 08m, 08m2, 18x, 18m2 that required calibfreq, regardless of what clock speed used.

Programs download regardless of what calibfreq is set from my testing, as i have set from -30 to +15 and downloads still function.
 

nick12ab

Senior Member
Programs download regardless of what calibfreq is set from my testing, as i have set from -30 to +15 and downloads still function.
The PICAXE automatically resets calibfreq for downloads so that you don't make the PICAXE non-reprogrammable by issuing the command.

I've previously made a small 28X1 program giving the user a calibfreq control and showing output on a AXE033 serial LCD - the value can be changed to +-5 before the characters get corrupted.
 

srnet

Senior Member
It seems odd that sertxd output is corrupt 'every so ofen' (whatever that means) whcich suggests a marginal timing problem.

You would expect then that only a small change in calibfreq was needed to make a significant differance .......
 

SAborn

Senior Member
On average the adjustment is around -13 for reliable data, but one chip needs -30 to get data without any errors, which is what i found strange considering the manual says -15 is the limit.
 

inglewoodpete

Senior Member
Do you have something that you can measure the width of the pulsing for a "U" character: Like a half-decent oscilloscope? From memory, asynch receive can handle errors of up to about 8%.

I've used 3 PICAXE 20X2s and never had any comms problems (ie had to use CalibFreq with 20X2). In fact, I've just downloaded the EEPROM of my temperature logger into a csv file for MS Excel: 109,000 bytes via serial at 9600 baud with no errors.

Peter
 
Last edited:

Dippy

Moderator
I had a few occasions where the Sertxd to PC was 100% perfect, yet soft-serial comms to a downstream PIC+xtal+USART was unreliable.
A bit of Calibfreqing sorted it. Too much Freqing around messed up Sertxd.
As an aside, I have always found PC serial to be far more timing-tolerant than PIC.

Maybe it's the circuit if it was a 'special' for the 20X in question. I have never had to twiddle as much as SAborn, maybe this usb cable has introduced something into the signal. So I will be avoiding that manufacturer (not that I've ever heard of them) for my own projects.
 

SAborn

Senior Member
I just checked a couple of 20x2 chips from my latest batch i have and they all work ok without needing calibration, so i went back to an earlier 20x2 and run a couple of different calibration settings and took some screen shots of the terminal window.

See attached pdf.

the first test was at calibfreq 0, then calibfreq -10, calibfreq -13, calibfreq -15, the last setting shows no corrupt data in the serial.

Perhaps it was just a bad batch of chips some time back but all i have bought prior to this last batch has had this problem.

When i have time i will check all 10 of the latest batch to confirm if it was just luck the 2 i tested didnt need calibrating.


View attachment 20x2 Calibfreq.pdf
 

inglewoodpete

Senior Member
Hmm. That's quite definitive. Do you have an oscilloscope to show the width and quality of the pulsing? Also, what are the different firmware versions?
 

srnet

Senior Member
Indeed it is.

You would think with it that bad, the program downloads would fail.

I had always assumed that the soft UART routines used by the program download were the same as those used for sertxd ......
 

SAborn

Senior Member
The firmware version of the chip used for the screen shots is version C.0 or version 0.

Yes i do have a scope and will check it out later.

My main question was about going to -30 when the manual only quotes -15 as the limit in calibfreq.

The problem only occurs with the 20x2 chip and not the other chips so its rather bizarre.

@Dippy, Ritmo is the manufacture of the no brand name usb/serial cables that use the HL340 chip set and are often sold from China and else where, i have used them for years without problems other than this with the 20x2, i understand that Stan also now uses them too without problems.

Its not a huge issue but more of a pain when you do multiples of the same circuit but need to calibrate each chip before it can be programmed for use if sertxt is needed in the program.
 

srnet

Senior Member
Yes i do have a scope and will check it out later.
Mine was on the bench, I had been playing with the QRSS on my 20X2 lost model thing, firmware c.2.

Sertxd output, 9600 baud gives me a bit time of 109.38mS

Program download, appears to be at 4800 baud and has a bit time of 206.25uS.

That gives a baudrate accuracy differance of 6% between program download and sertxd ........ quite a lot really
 
Last edited:

inglewoodpete

Senior Member
Aha. Firmware C.0 in the 20X2 had quite a few problems, including the timing of serial.

Have a look at C:\Program Files\Programming Editor\firmware.txt
 

hippy

Ex-Staff (retired)
Aha. Firmware C.0 in the 20X2 had quite a few problems, including the timing of serial.

Have a look at C:\Program Files\Programming Editor\firmware.txt
The only serial timing issue noted in firmware.txt is for the AXE033 and this related to inter-byte gaps rather than baud rates.
 

Technical

Technical Support
Staff member
Firmware revisions are available on the chip's page at picaxe.com
http://www.picaxe.com/Hardware/PICAXE-Chips/PICAXE-20X2-microcontroller/

The firmware C.1 serial timing changes were to the gap between bytes, not the actual bit timing. That should make no difference here.

The tolerance of all different baud rates from the PICAXE chips will all vary slightly due to the various firmware requirements and features, but will all be within normally accepted limits. Different baud rates will have different +- tolerances.

Practically thinking, the issue actually seems to be this brand of USB adapter does not work within normal expected tolerance limits whilst real ports/prolific/FTDI ones do. We would therefore recommend the best solution is to actually use a better quality adapter rather than anything else.

You could also try using a different 'sertxd' baud rate - on M2/X2 chips there is actually no such thing as a 'sertxd' command, the compiler just parses a serout on that pin at the appropriate baud rate. So for instance try and use a 'serout A.0, N4800,' or 'serout A.0, N2400,' instead of the 'sertxd' command.

Older PICAXE chips had a range of +-15, newer ones +-31, we'll make a note of that typo in the manual. But we would never expect to have to use a -30 for anything, and would be surprised if the PICAXE chip could still download at such a large oscillator change.
 

SAborn

Senior Member
Practically thinking, the issue actually seems to be this brand of USB adapter does not work within normal expected tolerance limits whilst real ports/prolific/FTDI ones do. We would therefore recommend the best solution is to actually use a better quality adapter rather than anything else.
That might be true, but why is it only the 20x2 that has this problem with the cable used and no other picaxe chip in the range appears effected, also the different baud rates also make no difference to the problem, or have an effect when used on the other chips.

FYI, the chip downloads just fine at -30, but it was surgested that the frequency is reset when a download is commenced, as it would appear to be the case as the frequency needs to be reset to -30 again after a download or corrupt data is transmitted again.
 

SAborn

Senior Member
If i drop the baud rate to 2400 or below the data looks to be clean, although this is of little use when in use with a VB6 program needing data at 9600 baud.
If i go to a 18m2 and up the baud to 9600 all works fine with clean data, even a 08m at 9600 works fine when over clocked.
 

BillBWann

Member
My experience is very similar to SAborn’s – the need for calibfreq -30 for sertxd to function, only with the Ritmo cable, only with the 20X2, no problems with download. When I analysed the signal using the Saleae protocol analyser, the timing was very marginal without the calibfreq -30 command with the dot of the serial protocol analyser falling right on the edge of the stop bit.
 
Top