pulsin pulsout timing accuracy

[Garahbara]

I'm new here, so please be gentle with me. No yelling, OK?

Basically, a project to control the signals on my model railway layout. Each signal will be driven by a PICAXE-20M. Train detction at that signal doe by and LDR (Light Dependant Resistor) between the rails and using READADC to determine the presence of the train.

I need to indicate to the prior signal, the state of the current signal. i.e. red, yellow, or green. so the PRIOR signal can switch accordingly.

To do this, I've decided to use the PULSIN and PULSOUT. PULSOUT of different lengths to indicate what the colour is.

What sort of accuracy would I get testing the length of a PULSOUT using another processor? (PICAXE-20M)

If I PULSOUT = 300, will I get a reading of 300 on the PULSIN on the other processor? 300? Always? Everytime? Or do I need to build a bit of tolerance into it, and test for a range. i.e. >280 & < 320. for a PULSOUT of 300. If I do need some tolerance. How much tolerance?

Thanks in advance for any help.

 

[hippy]

Welcome to the PICAXE forum.

Accuracy really comes down to how close the PICAXE is running to its nominal operating clock frequency. With an internal oscillator that can vary depending upon supply voltage and temperature and it also varies between PICAXE variants and even chips of the same type.

Most internal oscillltors on the PICAXE range are accurate to +/-5% and often better, especially at normal operating voltages and room temperatures. Looking at the 16F677 datasheet there are a whole set of graphs on HFINTOSC versus other parameters, but +/-3% seems to be its general accuracy. For two PICAXE's communicating the worse case error should therefore be +/-6%, which you could call +/-10% just to be on the safe side.

In practice you may find that it tends to be a lot more accurate than that.

 

[BeanieBots]

I've done this quite a lot as a method of sending simple data just like you require.
Sending for example pulsout pin,10 could be received as anything in the range of around 8 to 12. However, there is an easier way to get the correct data rather than testing for a pulse within range.
If you multiply the 'send' number by a factor, add an offeset and then divide the received number, then it all works out nicely.
for example, to send a number in the range 1 to 10 you can do it like this.

Sender:
b0=N '(N is any number in range 1 to 10)
b0=b0+2*10 'remeber PICAXE maths will be b0=(b0+2)*10
pulsout pin,b1

Receiver:
pulsin pin,b0
b0=b0/10

The above method gives very reliable results. I've even used it with a simple (+1,/2) to send data in the range of 0 to 127 reliably with external resonator chips.

 

[Garahbara]

Thanks for that, Hippy. Much appreciated. I'll build a small tolerance into the logic.

No doubt I'll have some other questions as I go along too.

 

[Garahbara]

Ahhh. Not a bad idea, BeanieBots.

I'm quite happy to build in some tolerance, however I'd like to drop the multiple comparitors off the "if" statement. i.e. If pulsin > 180 or pulsin < 220. and just have one. i.e. if pulsin = 200.

Running short of prog space in the processor, by about 5 bytes.

But your code would only occur once, rather than the multiple comparitors on multiple "if" statements. Might get me the space I need. or I'll need to drop some functionality out like red light detection. i.e. the train goes through a red light, so I set off a piezo alarm with a few beeps.

Thanks.

 

[Garahbara]

BeanieBots,

I note in your code, that you used "byte" variable, rather than "word" varaible. The manual for PULSIN/OUT suggests "word" variable.

Is a "byte" varaible sufficient and will work just as well? (provided, or course, your pulse length is < 255).

Running short of byte and word variables too, cause, knowing me, I'll fill it up anyway, with all sorts of "nice to have" stuff if I can, like the red light detection.

I've programmed all this up, and downloaded to a PICAXE-20M, and it seems to work OK. (using a LED to show when "pulse"ing), but am yet to hook it up to another processor to see how it all interacts.

 

[hippy]

Yes, if your PULSOUT/PULSIN will only ever be sending/receiving values 0-255 you can use byte variables.

 

[Garahbara]

Sender:
b0=N '(N is any number in range 1 to 10)
b0=b0+2*10 'remeber PICAXE maths will be b0=(b0+2)*10
pulsout pin,b1

Receiver:
pulsin pin,b0
b0=b0/10

The above method gives very reliable results. I've even used it with a simple (+1,/2) to send data in the range of 0 to 127 reliably with external resonator chips.

Worked a treat, BeanieBots. But should be b0=b0*10+2 (other way round). Didn't take long to work that out, but.

That got me back quite a few bytes to do other goodies with.

Thanks.

 

[BeanieBots]

Mathematically, you are correct that it should be the other way, however, the way I wrote it is deliberate.
The objective is to add a small offset so that the sent pulse is always bigger than the actual data and never zero.
When received, the division rounds down and the offset is also divided such that it gets lost completely.

End of the day, whatever works for you.
Glad the idea helped.