Advice Required for Connecting multiple picaxe over radio link.

the old fart

Senior Member
Hi Guys,

With reference to my project, large miniature railway.

http://www.picaxeforum.co.uk/showthread.php?28328-help-needed-with-I2C&highlight=railway

I've been asked if the signals can be controlled by radio link, ie xbee.

I have read the Xbee tutorial and datasheets.

So I have a few questions that I hope will help me to decide which direction to go, or not, as the case may be.

A. Due to distance and a building I would need to use Xbee Pro, with additional aerial. Would this work up to 60M distance.

B. About 10 remote locations, Can I use 1 master Picaxe to talk to all remote picaxes?

C. What effect would Radio Controlled Trucks, on 2.4gh, have on the Xbee signal?


Thanks.

TOF
 

neiltechspec

Senior Member
With Cluttered Airwaves at 2.4 Ghz, e.g. 2.4G R/C, 2.4G WiFi, 2.4G Microwave Ovens.

Would 868.3 Mhz ERF Modules be a better option.
Good for 500m LOS, so 60m should be no problem.
£11.99 from the UK manufacturer.

I should add, Rev Ed of course sell custom versions of these ERF modules.
They have custom firmware that allows PICAXE remote programming.
At £17.99 ea, with 10 required, that's an extra £60 for a facility you don't need.

Neil.
 
Last edited:

the old fart

Senior Member
Am I going in the right direction with the ERF modules.

Send update from master to all slaves.

master requests data from slave 1

master receives data from slave 1

master updates all slaves

master requests data from slave 2

master receives data from slave 2

master updates all slaves

etc to slave 10 then repeats.




serout c.1, n9600_8, ("slave99",b3,b4,b5,b6,b7 )
master send update to all slaves.

serout c.1, n9600_8, ("slave1go", )
so only slave1 transmits back


serout c.1, n9600_8, ("slave2go", )
so only slave2 transmits back

If that makes sense.
 

inglewoodpete

Senior Member
Remember that, because all transmitters and receivers are using the same frequency, all receivers within range will have to process all data. This includes the device that sends the data, since it too will have a receiver.
 

hippy

Technical Support
Staff member
Looks about right, though you probably have to use Txxxx baud rates for an ERF. Also you need to take some care in choice of qualifier naming. As every slave will receive everything sent.

I would choose "SLAVEx"for master to slave, where x is "*" for all, a digit or alpha character to identify slaves, 0-9, A-Z. The slaves have to be able to determine if it's a request or an update so it's probably easier to send the update in two parts ...

Code:
SerOut C.1 T9600_8, ( "SLAVE", "*" ) 
Pause ...
SerOut C.1 T9600_8, ( "UPDATE", b3,b4,b5,b6,b7 )
The PAUSE has to be long enough for the ERF to have sent the "SLAVE*" part and the slave to be ready for the next data before that is sent.

And you can request slave data with ...

Code:
SerOut C.1 T9600_8, ( "SLAVE",  "0" )
SerIn  C.2 T9600_8, ( "RESULT", "0", ), b0, b1 ...
It's probably best to add a timeout to the SERIN.

Then each slave can run the same code with only the 'ME' definition changed for whichever slave it is ...

Code:
Symbol ME = "0"
Do
  SerIn C.x, T9600_8, ( "SLAVE" ), b0
  Select Case b0
    Case "*"
      SerIn C.x, T9600_8, ( "UPDATE" ), b3,b4,b5,b6,b7
      Gosub UseUpdatedData
    Case ME
      Gosub GetDataToReplyWith
      SerOut C.y, T9600_8, ( "RESULT", ME, b0, b1 ... ) 
  End Select
Loop
 

the old fart

Senior Member
Thank you for that bit of code Hippy.

Looks a lot easier than I thought it would be.

I'll get a list of modules and chips together and place an order.

expect I'll be back with a few more questions later.

TOF
 

srnet

Senior Member
For my own various 434Mhz projects, I have been driving the radio modules direct, however they way that packets are sent and received could be used for serial systems too.

Each packet is preceded by three bytes,

Byte 1 - Described the content of the packet or is an instruction or command to the receiver
Byte 2 - The destination node number, * for a broadcast.
Byte 3 - The source node number.

Then follows the data, this can be bytes, or comma separated data such as that a GPS would put out.

Now if the packet type byte and nodes are as ASCII characters A-Z, 0-9, a-z etc they can be sent and received via serial out and serial in commands.

For instance you want to know the battery voltage for node B. The master is node M. Assume the request for battery voltage is packet type V, the transmission of battery voltage is v.

So the master sends;

VBM

This is received by node B which recognizes the packet is for it and replies;

vMB,3900

3900 is the battery voltage in mV.

I have had this simple packet addressing working well at the 250km mark.

These are the packet types used by my tracker;

ACK = 'A';
LinkReport = 'B';
ClearToSend = 'C';
ClearToSendCommand = 'c';
Error = 'E';
NoFix = 'F';
NoGPS = 'G';
PowerUp = 'P';
LongPayload = 'L';
Memory = 'M';
NACK = 'N';
NACKCommand = 'n';
Repeated = 'R';
ShortPayload = 'S';
Test = 'T';
Wakeup = 'W';
ResetTracker = 'X';
Config1 = 'Y';
Config0 = 'Z';
 

hippy

Technical Support
Staff member
It's probably best to add a timeout to the SERIN.
Won't you run into the issue that SERIN with wireless, even with qualifier, doesn't time out because of the noise which the wireless receiver picks up?
Dumb 433MHz modules will put noise on the serial line which will derail the timeout mechanism, but the ERF and other smart modules only put out clean data and are silent when they have none.
 

the old fart

Senior Member
Hi Guys,

now the questions begin.

I have one unit transmitting data, ref rfa020.pdf

the other unit as a receiver.
using ERF with picaxe firmware, data received correctly.
using a standard ERF, and changing baud from n9600_8 to t9600_8, I get the occasional correct data, but mainly rubbish.
if I remove the timeout I get data in the wrong order.
tried the ERF_configeration_wizard and URF_SRF_XRF_ERF_Wizard, but no change.

test program:
Code:
#picaxe 20m2	;chip type


#terminal 9600	;terminal baud

setfreq m8		;chip freq

low c.1		;transmit pulled low

main:

SerIn [1500], c.2, n9600_8, b0,b1,b2,b3,b4,b5 ; t9600_8 for non picaxe ERF modual

sertxd( b0,b1,b2,b3,b4,b5, cr, lf ) ; to terminal display

;============================================================
; inputs and outputs on pcb.

if pinb.0=0 or pinb.1=0 or pinb.2=0 or pinb.3=0 then
	high b.5
	high b.4
	low b.6
	high b.7
	high c.0
	high c.7
goto main
endif





; looks at chr$ in b4, b5

if b4=49 then high b.5: else low b.5:endif

if b5=49 then high b.4: else low b.4:endif

if b5=48 then low b.7 high b.6:endif

if b5=53 then low b.6 high b.7:endif

if b5=54 then high c.0: else low c.0:endif

if b5=56 then high c.7: else low c.7:endif


;clear 
b0=255
b1=255
b2=255
b3=255
b4=255
b5=255

goto main

TOF
 

hippy

Technical Support
Staff member
Start with something simple ...

Code:
Transmitter:
  Do
    SerOut TX_PIN, TX_BAUD, ( #w0, "X" )
    Pause 1000
    w0 = w0 + 1
  Loop
Code:
Receiver:
  Do
    SerIn RX_PIN, RX_BAUD, #w0
    SerTxd( "Received ", #w0, CR, LF )
  Loop
 

the old fart

Senior Member
Thanks Hippy,

Thanks for the demo program.

Have traced it to pulling the transmit line low, c.1.

when used in RX only mode.
the picaxe ERF requires the TX line to be pulled low.
the standard ERF stops working if the TX line is pulled low.

will see what happens later when I get to 2 way communications.



Also, I tried reinstalling the driver for the axe207 usb download cable.
Windows 10 64bit comes back with error,

The drivers for this device are not installed. (Code 28)
This operation requires an interactive window station.

Is there a win10 driver?

TOF
 

hippy

Technical Support
Staff member
Have traced it to pulling the transmit line low, c.1.

when used in RX only mode.
the picaxe ERF requires the TX line to be pulled low.
the standard ERF stops working if the TX line is pulled low.
Ah, yes; that makes sense. The serial polarity is opposite on the standard ERF to the PICAXE ERF so it would be idle high.

The drivers for this device are not installed. (Code 28)
This operation requires an interactive window station.
I recall someone else seeing the same and it seems it is a Windows issue from other reports on the web so it is not just our drivers which cause it to appear. If that error doesn't occur then the drivers should install and work on Windows 10.

I cannot recall off-hand what the suggested solution for overcoming that is but will look to see if I can find that.
 

the old fart

Senior Member
I recall someone else seeing the same and it seems it is a Windows issue from other reports on the web so it is not just our drivers which cause it to appear. If that error doesn't occur then the drivers should install and work on Windows 10.

I cannot recall off-hand what the suggested solution for overcoming that is but will look to see if I can find that.
I've search forum, but none of the post solve the problem.

I tried Safe Mode, disable signed driver check, but still not working.

I see that FTDI Ltd, which picaxe download cable is based on, have win10 64bit drivers. But can't get them to see the cable.
 

the old fart

Senior Member

grim_reaper

Senior Member
If I remember correctly, I had to force the install of the older drivers on my Window 10 PC. I haven't used it in months though, so it's a bit foggy.

When I get home I can check the version of the driver I installed if you like?
 

the old fart

Senior Member
Lets keep on track chaps, I believe it's a driver/win10 issue.

Back to my questions.

I have 3 boards on test, 2 with 20M2 and 1 with 40X2.

all set to 8Mhz, 9600baud.

the 40X2 shows a lot more errors than the others.
swapped ERF modules around.
I seem to remember that I had a timing issue with a past project, Needed to nudge processor frequency a tad..
I have an led bargraph on the 40X2 which proves that the error is from ERF to 40X2 and not 40X2 to Terminal.
20% of received data is affected.
corruption is usually from 3rd character received onwards.
Thoughts please.
 

neiltechspec

Senior Member
Run them at 16Mhz.

That's what I do for 9600 Baud, capturing 23 bytes every 15 secs from my Solar Inverter.
Never had an issue in over 2 years, running on a 14m2 (master display) and two 08m2's (slave displays).

(I send 5 bytes, get 31 bytes back but only capture a selected 23)

Neil.
 

the old fart

Senior Member
Run them at 16Mhz.

That's what I do for 9600 Baud, capturing 23 bytes every 15 secs from my Solar Inverter.
Never had an issue in over 2 years, running on a 14m2 (master display) and two 08m2's (slave displays).

(I send 5 bytes, get 31 bytes back but only capture a selected 23)



Neil.
I'll try that, thanks.

Dave
 

srnet

Senior Member
All our AXE027 cables use genuine FTDI components.

This is specifically a Microsoft / Windows issue.
I have great sympathy for companies like Rev Ed who sell stuff that depends on Windows drivers.

Windows and USB just dont get on well at all these days and it seems to get worse with every new version of Windows. For no apparent reason a serial cable or memory stick will work one day and the next Windows will throw a hissy fit and refuse to load the drivers.

One of the better behaved setups is the AXE027, although even that is occasionally thrown out by Windows. Going away, having a coffee, sacrificing an animal to the God of Microsoft, and plugging it out\in usually cures that.
 

neiltechspec

Senior Member
I have to say, since I started with PICAXE (must be well over 3 years now), the AXE027 is about the only USB device I have NOT had a problem with in Windoze.
 

the old fart

Senior Member
Run them at 16Mhz.

That's what I do for 9600 Baud, capturing 23 bytes every 15 secs from my Solar Inverter.
Never had an issue in over 2 years, running on a 14m2 (master display) and two 08m2's (slave displays).

(I send 5 bytes, get 31 bytes back but only capture a selected 23)

Neil.
What command are you using on serin?

Serin c.1, n9600_16, b0,b1,b2,b3 etc ?
 

hippy

Technical Support
Staff member
corruption is usually from 3rd character received onwards.
Thoughts please.
The ERF sends the bytes it receives to the PICAXE with only a short inter-byte gap. It could be that the PICAXE is not processing recieved bytes quickly enough to have read one byte and be ready for the next. That is usually overcome by using a lower baud rate, increasing PICAXE operating speed, or using background receive.
 

the old fart

Senior Member
Update:

I have one 'master' and two 'slaves'.

both slaves communicate to/from master.

if received data is incorrect then it's ignored.

failure to communicate will be taken care off by 'master'.
 

neiltechspec

Senior Member
This is what I capture with.

serout T485,baud2,($aa,$05,$02,$00,$00)

serin [800],R485,baud2,b0,b1,b2,b3,b4,b5,b6,b6,b7,b7,b7,b8,b9,b10,b10,b10,b10,b11,b12,b13,b14,b15,b16,b17,b18,b19,b20,b20,b21,b22,b23

baud2 = T9600_16
T485 & R485 just define the I/O pins used.

Neil
 

the old fart

Senior Member
Update:-
visited site today, took 1 'master' board, 2 'slave' boards and a portable test, read only, oled display board.
All ERF modules. unboxed in free air,

Site is surrounded by fields, so no interference from outside. but trees on site.

Line of site, 100M at the most. Buildings, fences, even people knocked the signal down even further.

Any suggestions to get better coverage.

Could use the alternate frequencies to split into sections.


thanks for code Neil, most useful.
 

neiltechspec

Senior Member
Is there any way you can mount just the ERF modules in a separate box up on a pole for example to get more height ?.

Don't know if there are any higher gain antennas available for those modules, or even if they have that capability. Might be worth looking into.

The ARF module may be better suited with its external antenna, but it is 2.5 X the price.

Neil
 

the old fart

Senior Member
Is there any way you can mount just the ERF modules in a separate box up on a pole for example to get more height ?.

Don't know if there are any higher gain antennas available for those modules, or even if they have that capability. Might be worth looking into.

The ARF module may be better suited with its external antenna, but it is 2.5 X the price.

Neil
Thanks for info Neil.

Rapid have ARF at £29.30 each, free P&P over £30.
comes with antenna.
 

the old fart

Senior Member
from openmicros.org,

The ERF and URF, these two are very similar in size and construction. The chip antenna works very well for it's reduced size. It however cannot match the wire whip of the XRF. You can add a wire whip if you wish.

has anyone tried adding a wire whip?
 

srnet

Senior Member
from openmicros.org,

The ERF and URF, these two are very similar in size and construction. The chip antenna works very well for it's reduced size. It however cannot match the wire whip of the XRF. You can add a wire whip if you wish.

has anyone tried adding a wire whip?
When you say "chip antenna works very well for it's reduced size" have you measured the actual difference with these modules between the chip antennas and a simple 1/4 wave vertical with base radials ?
 

the old fart

Senior Member
it's not me saying it, quoted from suppliers site.

a 'urf expansion kit' is £1.00, but all sources are out of stock.

using the 'whip aerial' is supposed to increase the range by 2-3 times.

the arp module has a much greater range.

the picaxe store has neither of these items listed.
 

srnet

Senior Member
it's not me saying it, quoted from suppliers site.
Well, I would say that the small ceramic antennas are just about acceptable where compact size is most important, bu they are poor performers compared to simple wire antennas.

But do run a range test in a large open area.

First with a ceramic antenna, and then remove it and replace with a 1/4 wave bit of wire, whats the affect on range ?

The World needs to know.
 
Top