Picaxe network

edmunds

Senior Member
Dear all,

I know the question has been around a million times and there is lots on it in the forum. Exactly because of this, I would be thankful for some educated pointers on what to look for and where to start.

I need to set up a network of environmental and some other sensor nodes that would contain a picaxe each controlling its own sensor. Then, it would have to relay the data to a wired master picaxe up to 20m away. I'm thinking two + power would suffice, but actually this is not a case where this is a major limitation. Some units would also work like remote switches, so they would have to be able to listen to the "bus" and figure out if that was actually a command from the master for them and do something about it. I cannot think of any current or possible future node that would require the "bus" to be fast - updates once a second would probably be plenty and for most data even that is too often. On the other hand, there is no reason to make it slower than it has to be. Data packets could range from a single byte to quite many (GPS data would be some 6-8 bytes at least, I think).

There is CANbus and its derivative NMEA for marine world, but from the glimpse I had at the documentation, it seems an over-complication for what I need.

Some high level thinking I have done so far is the most difficult part is managing conflicts of the devices trying to talk on the bus at the same time. I would imagine each device broadcasting whatever it has to say and master trying to listen to everybody while in listening mode. Each packet of data would be preceded by a header, so the master knows if it is wind speed or compass direction or whatever it is receiving. When the master wants to say something, it acts like a remote node for a while and broadcasts the message until it receives acknowledge from the remote node. The fact some of the devices did not get to send their stuff in the meantime or any other time is not a problem - they should time out and try again. Reasonable? How can I handle "the bus is busy" situation?


Thank you for your inputs,

Edmunds
 

Buzby

Senior Member
Hi Edmunds,

As we say, there's always more than one way to skin a cat. ( Don't ask me why we say that, I don't know. )

The two most popular network management methods are (1) collision detection, as used by Ethernet. and (2) token passing, as used by ProfiBUS.

My view would be to use token passing, then there is no conflict management at all.

Cheers,

Buzby
 

techElder

Well-known member
Token passing would allow you to use both wired and wireless networking. My little network is also polled, but there aren't very many nodes. HC-12 wireless fits well.
 

Buzby

Senior Member
As Tex says, there is also polling, where the master does all the asking and the slaves respond when asked. Dead easy to code and troubleshoot.

Token passing is really just an extension to polling, but with better bandwidth use. It's a bit more complex, so if you don't need the bells and whistles you won't really need it.

Cheers,

Buzby
 

rossko57

Senior Member
... a master/slave polling network ...
polling Modbus wired serial is well established, capable of distance (1km). A large selection of ready-made products and DIY designs of environmental devices available to save work - temp/humidity sensors, relays, digital in/outs for use with switches, motion sensors, blah.

Modbus-TCP variant over ethernet/wifi exists but would be outside the scope of a Picaxe project.
 

edmunds

Senior Member
For simplicity and reliability, a master/slave polling network is a very good system.

Cheers to All
Maybe that is even better. Since my master is always a master and there are no slaves in sight that would require to relay some "immediate" message, master can just poll every device it knows there could be, time out if it is not responding in a set time and move on to polling the next one. Repeat the circle every loop and update the display accordingly. The slave device then would mainly wait to be polled. On suitable command received, it would relay the data of the last measurement and do a new measurement to go into waiting (maybe even low power) state again.

Adding a new, unknown device would require updating the master software, but in this case it is not a problem, since a new device would introduce new type of data the master would have no idea what to do with anyway.

As for the physical connections, a "Data Out" pin on the master would be "Data In" pin on the slaves and "Data In on master - "Data Out" on slaves. No external components needed. Since what is input and what is output would be clearly defined and fixed at both ends, no pull-up/pull-down resistors are required. 1k series resistors could be added on both ends to reduce damage if something unexpected happens, right?

The software would be simple SerIn/SerOut commands.


Thank you all for your input,

Edmunds
 

rossko57

Senior Member
Remember your 20 metre requirement. Simple 5V TTL unbalanced serial is not good over distance (why other choices have been invented) and gets worse with increasing speed. If you can live with low speed like 2400 you can certainly try - much depends on the environment.

Have error checking (CRC) in your invented protocol to deal with glitches. Polling method practically takes care of retries by itself.
 

edmunds

Senior Member
Remember your 20 metre requirement. Simple 5V TTL unbalanced serial is not good over distance (why other choices have been invented) and gets worse with increasing speed. If you can live with low speed like 2400 you can certainly try - much depends on the environment.

Have error checking (CRC) in your invented protocol to deal with glitches. Polling method practically takes care of retries by itself.
Dear @rossko57,

What do you mean with "unbalanced" as opposed to balanced? Would adding pull-up resistors make it balanced and thus more reliable? Some error checking is inevitable and as you say, polling should take care of retries.

EDIT: I found a good explanation on balanced/unbalanced interfaces in Digital Interface Handbook available through google books. Forget my silly question. I will try to avoid having to design a balanced network first :).


Thank you for your input,

Edmunds
 
Last edited:

edmunds

Senior Member
Dear Phil,

Thank you for your input, I have looked at that some time ago and studying it has its part in building my confidence to attempt building something like this. I'm put off by the complexity that I think I can avoid and the hardware solution. I feel it is more complex to build than RS485 network that would be better suited for my application. By now I have built a simple communicating pair that works on my desk, but it all goes bullocks over ~30m of wire. Some number of first transmissions/receives work, but then crazy things happen. I'm also put off by copyright as I would not design the solution for one project and I don't know if some application becomes commercial with time. On top of that, I'm not a great fan of software patents in principle.

Anyway, I have a couple of different 485 transceivers on their way, lets see if that helps and if I can come up with an efficient way to communicate over those. I would post the code I have so far and maybe I will try to do that later, but for now it is on a machine I don't have access to.

Edmunds
 
Top