Wireless options

[Jamster]

Hello all!

I've recently started work on designing a series of devices which I then thought would be neat if they could talk to each other and acheive a basic system of artificial intelligence. The main projects for this are: tiles with a 4x4 grid of buttons and RGB LEDs that can be stacked to form basic pictures/games/randomness but also held separatly and moved about around the room and small robots that so far are just going to wander round aimlessly but may have a purpose later...

Thus I would like suggestions on which wireless modules would be suitable, they preferably need

• to be networkable (most important here) so are able to talk to any of the other devices on that network with an identifier or name of somekind.
• Must be bidirectional
• to not take up too much code space when interfacing.
• be resonably cheap (£15 top price if not pushing it)
• to have an operating voltage of 3v - 5v (although i can use regulators if needed)

Searches come up with some sugestions like:

• manuka's suggestion
• The formidable Xbee which is seeming like the best idea.

Any help or suggestions apreciated, after all I have zero experience...
Jamster

 

[Technical]

Sounds like you do need the XRF/ERF/URFs - they can all talk to each other exactly as described.

from www.ciseco.co.uk

 

[Haku]

I second the Ciseco modules, low price, low power, dead easy to use with Picaxes, from out-of-the-box if you feed a serial signal into one then all other out-of-the-box modules in range will receive it.

Tip: Buy 1 more than you think you'll need, probably a URF, that way when you've got two or more modules in communication with each other you can use the URF on a PC running a terminal program (I like Digi's free X-CTU for that purpose) to snoop on the messages being sent/received, making it very useful for debugging.

I've written some code for XRF's (which should work fine on the ERF) that allows the Picaxe to confirm the XRF is connected and to also configure it with AT commands.

 

[Jamster]

Thanks Techical & Haku,

They look like they'll do exactly what I need and definataly look easy to use. And I think buying an extra is a good idea.

ADDED: Also intrigued as to what the "heartbeat" pin on the one module does...

Jamster
P.S. Technical: the favicon's reset...

 

[Haku]

The heartbeat pin puts out a 1hz signal to tell you it's alive and working, simply connect an LED to it and it'll blink.

I'm working on some code that will display LLAP messages (easy to use 12 character control code system) on the AXE133Y (serial display with 18m2 backpack) with an XRF/ERF connected to help with debugging. Got the code working but want to want to enhance it to be a bit more useful.

 

[Jamster]

One of the uses mentioned above is hopefully going to be a series of displays made of 4x4 grids of RGB LED buttons, using these and 40X2s to work together as a large expandable display (ie 20x20 buttons) which can be dismantled to the individual 4x4 displays and control various things on the network. They may also include accelerometers and other sensors in the future to control them, although not sure how they are to know which part of the display is where when working as the larger display...

Going to be a chalenge...

Jamster

 

[Haku]

There's probably more than one way to achieve how each identical block knows its position in the grid, this is what I've come up with.

Each module listens to the IR photodiode for a signal, if after X milliseconds it doesn't receive anything it sends a pulse through the IR LED, if it receives anything then it counts the pulses and adds one then send that amount of pulses through the LED.
In this example:

module D receives no pulses so sends 1 pulse.
module B receives 1 pulse so sends 2 pulses.
module A receives 2 pulses so sends 3 pulses.
module C receives 3 pulses so sends 4 pulses.

So each module knows its position in the line by how many pulses it sends. For a grid instead of a line just add IR LEDs and photodiodes on the top/bottom of the blocks.

 

[srnet]

The module with probably the biggest feature sets are the Hope RFM devices. Cheap, small and powerfull. Wide frequency range etc etc.

They have a built in packet handler, you spool the header bytes and packet data into a FIFO, and the packet is sent. You can have directed packets, pointed at individual, or a group or all receivers.

However, they are not the easiest of devices to get on with, and probably best avoided unless thay have specific features that you need.

 

[Buzby]

Hi Jamster,

How to find your position on the grid ?

One off-the-wall idea that I had was a "Reverse 1-Wire Address" mechanism.

Do you know about 1-Wire devices ?. ( There's some good posts in the forum somewhere. )

Basically, they are devices such as memory, clocks, thermometers, etc. which communicate over a single wire bidirectional bus.

Multiple devices can be addressed individually on the 1-wire bus because each device has a unique factory set ID number.

One clever thing about the 1-Wire protocol is that a master device, PC or micro-controller etc., can automatically learn the IDs of all the devices on the bus, without knowing beforehand anything about how many there are or what type they are. It learns by using a very clever bit-by-bit discovery algorithm to determine each unique address.

My idea, which I've not put a lot of thought into, is - Could the 'Learn the IDs' be turned around into 'Teach the IDs' ?

Imagine multiple PICAXEs on a 'sort of' 1-wire bus, with no unique identity for any PICAXE.

Could a 'bit by bit' teaching algorithm be implemented in a similar way ?.

As I said, I've not put a lot of thought into this, and it's very late here, and I've quite a lot of celebratory wine, so it might be a bonkers idea, but I'm sure by the morning there will be some comments.

Cheers,

Buzby

 

[westaust55]

Some of my past work using 1-Wire networks with the PICAXE is provided in this thread: http://www.picaxeforum.co.uk/showthread.php?15306-One-Wire-Devices-Networks

One clever thing about the 1-Wire protocol is that a master device, PC or micro-controller etc., can automatically learn the IDs of all the devices on the bus, without knowing beforehand anything about how many there are or what type they are. It learns by using a very clever bit-by-bit discovery algorithm to determine each unique address.

My idea, which I've not put a lot of thought into, is - Could the 'Learn the IDs' be turned around into 'Teach the IDs' ?

Imagine multiple PICAXEs on a 'sort of' 1-wire bus, with no unique identity for any PICAXE.

Could a 'bit by bit' teaching algorithm be implemented in a similar way ?.

Even if you use bit-bashed code at extremely slow through rates PICAXE chips (X1 and X2 parts only have general 1-Wire capability and then as Masters only),
I doubt you could impliment a system to teach "slave" PICAXEs an ID. How would you select the slave device to tell it what its Device number was to be?
somewhat akin to putting the cart before the horse.

In industry there are devices where they come from the factory with a defaul address. Then you set up the ID for each device on you network. If a device fails, you drop in a replacement with the default address and the master will detect the new device, ascertain which device is no longer present and then configure the new device accordingly. But you still have to set up each initial device one at a time.

 

[hippy]

My idea, which I've not put a lot of thought into, is - Could the 'Learn the IDs' be turned around into 'Teach the IDs' ?

I'm not sure what the difference is; teach and learn could be considered the same but seen from different perspectives. In Haku's system there's a chain of devices in series so each can teach the next, each learns from the previous. Once all have an ID the system can then work in parallel / multi-drop rather than in series.

It is possible to have a completely parallel / multi-drop system and all nodes determine a unique ID by random selection and checking no one else has the same ID but it's complicated and can be time consuming. More simply you can throw out ID's, retrieve them if two grab the same, repeat until done. At the end of it all though, each node has a unique ID but you don't know which nodes are which ID, where an ID is physically located. A house full of temperature sensors without knowing in which room an ID is won't be much practical use.

 

[Jamster]

Wow... I didn't expect this many replies....

Thanks all for the suggestions, Haku seems to be thinking along the same lines as me in using IR, but my method involved using a PC to allocate each ID and then leave it as fixed and stored in EEPROM. That way they can use minimal code yet still perform advanced functions like detecting their place and rotation in the displays. I'm going to be using a PC anyway to dowload different 'app' like things to the different slots on the 40X2 so having to set one-off IDs isn't a problem.

The onewire idea looks interesting so may look into that as well. Also Hippy's random ID ideas my be useful as well.

My original thought 'app' wise was to have each grid storing master code for the apps in slots 1-4 and then generic slave code stored in slot 0 which will respond to messages about switch states or LED colour from the master, although I'm now having second thoughts about the speed it would run at with that method. The 'apps' are, however, going to be my last thoughts; I'm going to start at the hardware first then slowly develop the software from that which is why I need plenty of code space.

Thanks again for the replies,
Jamster