Baud rates below 600?

#1
I can't see anything in the manual or the online help about slowing the clock further (say, setfreq M2) and whether this then allows 300 baud as the minimum, rather than 600 baud with a 4MHz clock which is as slow as I can go according to the manual.

I'm not in a position to do a quick and dirty test right now, with things screwed to the wall, but I'm getting very occasional data errors at 600 baud and reckon that slowing to 300 baud may well fix it.

Can anyone confirm that changing the clock to, say, setfreq M2 and then changing the baud rate to T600_2, would be valid, please?

EDITED TO ADD:

I've found the answer - it's NO, there doesn't seem to be a way to go below 600 baud as PE throws up a syntax error if you do (I'm using M2 Picaxes).
 
Last edited:

Technical

Technical Support
Staff member
#2
It's unusual to do, but should work. Simply using T1200_4 constant at m2 would be the same equivalent value as using T600_2

If you study the numbers in the baud rates constants you can also work out / use a number direct instead e.g.

b1 = T1200_4
b2 = T1200_8
debug
 
#3
Thanks very much indeed for that answer and work-around. It means I can "spoof" things to work at a lower baud rate, from the sound of things. It was finding out the syntax error in PE that made me think it wasn't possible.

So, if I set the clock to 2MHz (these are M2 devices both ends, 14M2s one end, 20M2 the other, with two links) and use T600_4, then in reality it should Rx/Tx at 300 baud?

I'm near 100% certain that I can get these links to be rock-solid at 300 baud, as the cable lengths are only modest. Sadly I can't change one cable, as it's a bit of 4 core plain cable that was built in to the house, but one thing I have changed that's improved things a bit (apparently - hard to be sure as I have no proper test gear over here) is to remove 4m of screened cable and replace it with a bit of unscreened. I strongly suspect that the the additional capacitance of the screened cable was slugging things down, with the limited drive available from a Picaxe pin running at 5V.

I know that these pins are fairly well protected, but I have got back to back diodes between the pins and the supply rails to provide a modicum of extra protection. I couldn't risk adding series resistors to protect the pins better, for fear of slugging the edges down even more than the cable R, L and C will do.

If I was at our other house right now I could breadboard this up - I'm trying to work on the finished and installed kit at the moment, so my experimentation capabilities are limited!
 
#4
Just to close this off, I re-programmed all three units so that the comms_baudrate was set to T600_6 and the clock slowed to 2MHz using setfreq M2. I also increased the 10 second "no data" time out numbers so they are still 10 seconds (this give a crude comms error display by putting hypens instead of digits on the remote display).

This has been running now for a few minutes and works OK, I just need a longer test period to see if slowing the comms to 300 baud will completely eliminate the occasional data transmission errors I was getting before. I'm confident it will, as one of the links was working OK over about 10m of cable at 2400 baud, so at 300 baud it should be significantly better. There's no nearby electrical noise to worry about, as these cable runs are all well away from any other electrical equipment in the house (more by luck than judgement!).

If doing this again I'd have put more Cat 6 cable in and run RS485 drivers at either end, but I am re-using a 4 core cable that used to be connected the the ventilation controller (also using some kind of bi-directional serial format - the cable is labelled "+, -, data+ and data-"). I moved that ventilation controller and wired it with some spare Cat 6 I'd already run to near enough where I wanted to relocate it, rather than the cable it came with, and that seems to work fine.

Here's a code snippet of the code for the remote sensor and display in the hall. The variable comms_baudrate is set to T600_4, to give 300 baud at the reduced clock speed of 2MHz for the data transmission part of the code:

Code:
;______________________________________________________________________________________________________________________________________________________________________

	;slow clock speed down to 2MHz to allow 300 baud transmit and receive
	
	setfreq M2
;______________________________________________________________________________________________________________________________________________________________________

transmit_logger_data:

	high serout_data_logger

	serout serout_data_logger, comms_baudrate, (thousands, hundreds, tens, units)
	
	;retrieve room temperature
	
	peek room_tens, tens
	peek room_units, units
	peek room_decimal, decimal
	
	;transmit data to logger
	
	serout serout_data_logger, comms_baudrate, (tens, units, decimal)
	
	;retrieve room humidity
	
	peek hum_hundreds, hundreds
	peek hum_tens, tens
	peek hum_units, units
	
	;transmit data to logger
	
	serout serout_data_logger, comms_baudrate, (hundreds, tens, units)
	


read_logger_data:

	;received outside temperature, date and time in ASCII (DoW1, DoW2, DoW3, hours, hours1, mins, mins1, day, day1, month, month1, year, year1)
	;where hours = tens, hours1 = units, etc, etc
	
	serin [20000, timed_out], serin_data_logger, comms_baudrate, sign, tens, units, decimal, DoW1, Dow2, DoW3, hours, hours1, mins, mins1, day, day1, month, month1, year, year1
	
	goto save_data
	
;______________________________________________________________________________________________________________________________________________________________________

	;speed clock back up again to 16MHz
	
	setfreq M16
;______________________________________________________________________________________________________________________________________________________________________	
	
timed_out:	
	
	;jump here if serial recieve times out and save "-" in all values so that display shows data receive error
	
	poke outside_sign, "-"
	poke outside_tens, "-"
	poke outside_units, "-"
	poke outside_decimal, "-"
	poke day_of_week1, "-"
	poke day_of_week2, "-"
	poke day_of_week3, "-"
	poke hours_tens, "-"
	poke hours_units, "-"
	poke date_tens, "-"
	poke date_units, "-"
	poke month_tens, "-"
	poke month_units, "-"
	poke year_tens, "-"
	poke year_units, "-"
		
	
save_data:
	
	;jump here if serial receive OK and store data in GP RAM, except for minutes - use the "live" version
		
	poke outside_sign, sign
	poke outside_tens, tens
	poke outside_units, units
	poke outside_decimal, decimal
	poke day_of_week1, DoW1
	poke day_of_week2, DoW2
	poke day_of_week3, DoW3
	poke hours_tens, hours
	poke hours_units, hours1
	poke date_tens, day
	poke date_units, day1
	poke month_tens, month
	poke month_units, month1
	poke year_tens, year
	poke year_units, year1
 

AllyCat

Senior Member
#5
Hi,

There should be no problems at 2 MHz, but as the title is "baud rates below 600" maybe it's worth commenting that at 1 MHz (and below) there are a few PICaxe commands that can allow the Watchdog timer to spontaneously Reset the PICaxe. Mainly commands that have a "timeout" capability, and there are various work-arounds, but not many users are expecting the PICaxe to reset "for no obvious reason", so they don't put in any code to trap/avoid it.

Cheers, Alan.
 
#6
Thanks for the additional advice.

Having now done a fair bit of testing, in-situ, I've realised that I made a fundamental error - I forgot to terminate the cables at the receive end! I can't believe I was so stupid as to forget to do this, as it's a pretty fundamental error - you need to drive current down a data transmission cable to reduce the risk of interference. The daft arrangement I had was a Picaxe output at the transmitter end and a (very high impedance) Picaxe input at the receive end (albeit with back to back signal diodes to the ground and supply lines).

I had no idea of the sort of impedance of the wires I was using, but guessed that driving a few mA down them, rather than maybe a µA at most, should improve things. I terminated the Picaxe receive ends with 1k resistors (so around 5mA maximum for transmit high, well within the Picaxe source limit) and now I get reliable data transmission at 2400 baud through all the wires.

Clearly this is a less than ideal set up, as I should have used twisted pair cable and a protocol like RS485 really, but the cables were all in place inside the house structure and were just plain multicore cable, and they were not going to be easy to replace without ripping holes in walls and ceilings.

The maximum cable run is around 12m, as a part of my testing I did a loop back test on the multicore cable, with data verification at the receive end, using a 26 byte data stream. So I was testing around 24m of this cable with just 5V TTL level serial data at 2400 baud, with no cable drivers, just a 1k termination resistor at the receive end. I left it running overnight, with continuous data packets being transmitted as fast as the Picaxe would go and didn't get a single error, so I'm confident that 12m runs will be pretty robust.

This may help others, as its nice to know that something this simple, using ordinary multicore cable and no proper cable drivers, can work reliably over modest cable lengths.
 

PhilHornby

Senior Member
#8
I had no idea of the sort of impedance of the wires I was using, but guessed that driving a few mA down them, rather than maybe a µA at most, should improve things. I terminated the Picaxe receive ends with 1k resistors (so around 5mA maximum for transmit high, well within the Picaxe source limit) and now I get reliable data transmission at 2400 baud through all the wires.
This just rang a bell - I recall spending many (un)happy hours back in the '80s embroiled in a similar problem. The answer turned out to be 4k7, rather than 1k ... and was the basis of a hardware fix that I supplied to the (then) mighty Digital Equipment Corporation (thanks to something I spotted in the Maplin catalogue of the time :)).

I found an interesting little chart here: https://www.lammertbies.nl/comm/info/RS-485.html#char that gives the answer as 3 to 7k for RS232.
 
#9
This just rang a bell - I recall spending many (un)happy hours back in the '80s embroiled in a similar problem. The answer turned out to be 4k7, rather than 1k ... and was the basis of a hardware fix that I supplied to the (then) mighty Digital Equipment Corporation (thanks to something I spotted in the Maplin catalogue of the time :)).

I found an interesting little chart here: https://www.lammertbies.nl/comm/info/RS-485.html#char that gives the answer as 3 to 7k for RS232.
That is interesting. My experience goes back to sending data low baud rates over GPO wires (think teleprinter era!), where I seem to remember the termination resistance (or more accurately, the line impedance was 600 ohms). My hypothesis was that if a twisted pair was around 600 ohms, then plain wires would probably be a bit higher, hence the choice of 1k, as much on the basis that sending a bit more current down the wire, and running at a lower overall impedance, seemed better in terms of reducing interference.

It's easy to change the termination resistors, as the Picaxe circuit boards I made up all have screw terminal blocks soldered in for the connections, and I just poked the 1k resistors across the ground and data connections at each receive end. I may lug the 'scope over there and have a look at the signals and see what shape they are in, and if upping the termination resistance improves the margin at the receive end. I think the main thing is to make sure that the voltage level is well above the "high" detection threshold for the mid-third of each byte, where I assume the level is detected (not sure about this with the Picaxe software serial ports - again my memory goes back to adjusting teletype motor speeds to detect at the mid point of each bit!). It could be that increasing the termination resistance reduces the leading edge rise time, and so widens the plateau where detection takes place.

It's been working without fault for a couple of days now, so my inclination is to leave well alone, especially as my 'scope is a bit of a heavy beast to lug around!
 

AllyCat

Senior Member
#10
Hi,

The 600 ohm impedance is typical of a pair of (uninsulated?) wires many inches apart on insulators at the top of a telegraph pole! The highest characteristic impedance you might normally encounter (but probably not in UK) is 300 ohm balanced antenna cable which has two parallel wires spaced about 1 cm apart. Twisted pairs are nearer to 100 ohms and coaxial 50 ohms. Here is a nice link to confirm that I didn't dream all of that. ;) BTW I believe that Oscilloscope probes use a special helical-wound core coaxial cable to give an impeadance nearer 1 kohm.

But the "Characteristic Impedance" is mainly important when the signal wavelength is significant compared with the cable length. That generally implies Megahertz and/or hundreds of meters of cable. Which is just as well, because terminating a cable with 100 ohms at each end when carrying a 5 volt "TTL" signal (let alone say +/- 15 volts of RS232) would dissipate a lot of power. So I can't really explain why your 1k (or 5k) resistors improve the signal integrity (but I don't dispute that they do). I guess it may be damping some high frequency ringing on the pulse edges, or perhaps by just improving the input switching threshold level. The PIC(axe) chip's UART input does detect an initial rising edge and then "looks" at the middle of where it expects each data bit to be located.

Cheers, Alan.
 
#11
I think that one problem is that with the receive end unterminated you're relying on the transmit end to hold the wire high or low, with a reasonably low resistance. I know that issuing a high command early on, before any serial transmission, should fix things, by setting that pin to an output and holding it at 5V ready for the start bit, and after any serial transmission the pin "should" then remain an output.

My feeling is that having a very high impedance at the receive end of the wire, even though the transmit end is terminated via the Picaxe output, seems to have been the cause of interference problems, that were then causing me to believe that the cable was the problem, in not supporting a reasonable baud rate (and, to be fair, the cable IS the problem, as it's not a "proper" data cable).

The only way to prove this would be to take the 'scope over there and have a good look at the receive end, with and without termination resistors. Experience, plus my instinctive feeling, is that terminating the receive end such that the transmit end has to drive a few mA down the wire, is the reason it now works OK.
 
Top