Picaxe to Picaxe over RF (ZigBee/XStream/XTend)

Hi there,

I am trying to get a protocol going for 2 Picaxe chips exchanging data over Maxstream ZigBee/XStream/XTend RF modems. I have tried all modules and they all work fine sending messages either way but when I try to get one to respond to the others message and so on so on the serial comms gets itself hung up. Eventually I want Module 2 to ask Module 1 some data, Module 2 responds and then Module 1 asks for more data based on what it received. It sounds simple but it keeps locking up.

I have also tried a 2 wire direct input pin to output pin with the same program thus eliminating the possibility of it being the RF modules. The simple code to test the principle sends a number from Module 2 to Module 1 and Module 2 increments it then passes it back to M1. M1 then increments it and sends it back and so on and so on. Please can someone clever have a look at my code and tell me why it starts, runs for a few seconds, freezes, starts again sometimes, stops and generally doesn't seem at all reliable for what I am trying to do. I have tried T2400 as well and I have also tried adding delays in the loop of varying values.

It appears I could be getting a buffer overrun (I think I know what this means, data sent faster than it can be read). I can understand that if this were the case I might not always get consequtive numbers but what happens to the serial line to cause it to hang. I could probably work out how to put in some hardware flow control if it was a 3 wire Picaxe to Picaxe project but with RF in between I am not sure how to do it.

If anyone can help it would be fantastic.

<code><pre><font size=2 face='Courier'>
Module 1:
symbol n = b0
serout 7,T4800,(n) ' gives Module 2 something to process if it is locked waiting for input at startup
counter:
serin 0,T4800,b1
n = b1
if n &lt; 100 then
inc n
else
n = 0
endif
serout 7,T4800,(n)
'pause 100
goto counter

Module 2:
symbol n = b0
n = 0
serout 7,T4800,(n) ' gives Module 1 something to process if it is locked waiting for input at startup
counter:
serin 0,T4800,b1
n = b1
if n &lt; 100 then
inc n
else
n = 0
endif
serout 7,T4800,(n)
'pause 100
goto counter

</font></pre></code>
 

steliosm

Senior Member
Could you try to 'debug b0' on one of the modules so you can see what is going on with the serial data? If you don't want/can't debug is there any change that you could have a LED flash each time the module receives something? This way you can have an optical confirmation that the chips send and receive data.
You could also try to lower the bps to 2400 and use n2400 as a transmission.
 

hippy

Ex-Staff (retired)
This could be a hard one to debug.

If both PICAXE's started at the same time I can see the scope for some confusion as both initiate a SEROUT and there would be two sets of data bouncing in opposite direction. That you are getting some sequential numbers suggests one has started, sent its 'kicker' which went into oblivion and then waits for the 'kicker' from the other side. The other starts, sends its 'kicker', that gets incremented and sent back, everyone's happy and it should work in circles.

I cannot see why what you have would not work. It looks sound enough to me, and there's enough transmission delay and other-side processing that each should be back at the SERIN after issuing its SEROUT, so timing should not be an issue. However, try adding a PAUSE 500 between the main loop SERIN and SEROUT and see if that does make things any better,

If a SERIN gets a value it will issue a SEROUT, and the number should bounce between the two. The most likely thing to stop that from happening would be an XBee not sending a byte or an XBee not receiving a byte. Loss of signal, out of range, or data corruption could cause an XBee not to receive data sent, but then everything should jam up solid as each waits for a SERIN.

That it resumes is odd. It would be well worth putting a SERTXD and/or LED flash - Piezo beep even better - at the start of the code in each module so you can tell if a Reset is happening. Check the Reset line to the PICAXE is pulled high by 4K7 and check the PICAXE 10K/22K download circuit is correct.

Another possibility is someone else transmitting with their own XBee or other device which is jamming up the channels or creating false data which throws things out of kilter.

I've done the same as you have but using a PICAXE and a PC to do a 'ping' test and that has been very reliable. It initially had the problem of jamming up as soon as the signal was ever lost.

One thing you can try is wiring one of the XBee's so it works in loop-back mode; no PICAXE, just loop its RX to TX and see how that goes.

If I think of anything else I'll let you know.
 

moxhamj

New Member
This looks like a real challenge and I like a challenge!

Can I just clarify whether you got exactly the same circuit working with direct wires or not - I wasn't clear from the description.

In general terms, first get one module to send data to another via a wire. Then via RF. Then add a delay and send data back.

Adding qualifiers certainly helps RF reliability eg serout &quot;ABC&quot;... and serin &quot;ABC&quot;...

I'd also add 1-2 second delays in a few places and a couple of diagnostic leds - eg when serin gets some data flash one led, and when tx the data flash another.

There could also be power supply issues - are you on batt or power supply and are there regs/bypass caps etc?

I'm in the process of building a wireless mesh for reliable comms via multiple pathways and there are lots of things that can go wrong with wireless. Fundamentally there are problems with having two units using serin as there is potential for the system to lock up. One solution is to have a Tx unit sending regular signals to break a lockup situation. But even though there may be potential problems with your comms protocol I don't think this is the problem - my feeling it is something a bit more fundamental like power supply RF noise causing resets. As suggested by Hippy, a signal at startup (eg 3 led flashes) makes it easier to distinguish random resets from other faults.
 
Guys, thanks so much for your help. It is amazing to be put in touch with the 2 formost experts (as far as I can tell) on Picaxe so promptly. Your support in this forum is amazing.

Firstly you helped me by letting me know I wasn't being totally stupid. Then I used your advice and put in debug. I already had 2 serial LCDs, one on each module and I was using them for debug. It turns out they were the problem!

I was using input 6 for reading data from partner module. I was using output 6 for outputting to serial LCD. Now I expect you Picaxe experts will tell me it shouldn't be done that way and it turns out it shouldn't. See this code as an example and I will tell you what happened.

<code><pre><font size=2 face='Courier'>
init:
serout 6,N2400,(254,1) 'clear screen
pause 1000

main:
serout 6,N2400,(254,128)
serout 6,N2400,(&quot;Waiting...&quot;)
if pin1 = 1 then
pause 100
goto counter
endif
goto main
counter:
serout 0,N4800,(&quot;123456789&quot;)
serin 6,N4800,b0,b1,b2,b3,b4,b5,b6,b7,b8
sertxd(b0,b1,b2,b3,b4,b5,b6,b7,b8,13,10)
serout 6,N2400,(254,128)
serout 6,N2400,(b0,b1,b2,b3,b4,&quot;.&quot;,b5,b6,b7,b8)
pause 500
goto main

Module 2

readData:

serin 0,N4800,b0,b1,b2,b3,b4,b5,b6,b7,b8
sertxd(b0,b1,b2,b3,b4,b5,b6,b7,b8,13,10)

serout 7,N4800,(&quot;123456789&quot;)
pause 500

goto readData
</font></pre></code>

The sertxt revealed the data was totally corrupt. A few pushes of the button to raise pin1 high in order to initiate a data transfer and I got the following output on terminal.

&#204;23456789
&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;ZX&#204;234567890101&#255;123456789
&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;Z_~&#8230;34567890101123456789
&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;Z&#8230;67890101

I didn't know what to do so I decided to take all the LCD code out to simplify it for your expert opinion again. I tried it to make sure I hadn't broken the code before I sent it to forum and the problem went away. Instantly suspicious I changed the LCD to output 5 and it now works perfectly!

I don't know what causes it, I expect you do but my problem is fixed. I now use output 5 for LCD and have learned a lot about microprocessor based serial comms in my days of debugging! Sometimes it doesn't help to get life to easy!

It would be great if someone can tell me why so I can be even more educated.

Thanks again guys
Rich
 

hippy

Ex-Staff (retired)
&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;&#240;

That looks suspiciously like the PICAXE is resetting and/or attempting to enter its download mode.

Double check the Reset pull-up, the Serial In interface and have a very close look for any shorts.

If it's an 18X; Pins 6 and 7 are opposite Serial In and MCLR so you may find you've forgotten to cut a stripboard track between the two sides of the chip or there's a sliver of track left, or something similar if it's not stripboard. As moving from Pin 6 fixes the problem, Leg 15 to Leg 4 is what I'd examine closely.

Edited by - hippy on 25/07/2007 14:32:02
 
Top