Thoughts on networking the smaller PICAXES

[boriz]

(Just untried ideas.)

Two ‘bus’ lines: ATTN and DATA. All the AXEs get on with their own business intermittently checking the ATTN line within their main loop. When the ATTN line goes high, they suspend processing and go to a data-receive subroutine. In that routine they receive four bytes: a TO address byte, a FROM address byte, a function byte, then a data byte. The TO address byte is compared with the local ID of the AXE and if not matched, the AXE returns to it’s main processing loop, ignoring the data. If there is a match, then based upon the value of the function byte, the data byte is stored/processed by that AXE.

The function byte is for routing the data once it has arrived at the intended AXE. EG. One AXE driving 3 servos, or one AXE reading three temperature sensors.

The FROM address byte is to enable two-way chatting/hand shaking for exchanging data. EG “Hey AXE5, AXE2 here, send me the low byte of your ADC1” – “Hey AXE2, AXE5 here, low byte for ADC1 is 44” – “Hey AXE5, AXE2 here, send me your high byte for ADC1” – “Hey AXE2, AXE5 here, high byte for ADC1 is 3” etc.

Whenever an AXE need’s to send data, it first does a small loop, polling the ATTN line, waiting until ATTN is low, then takes the ATTN line high, then a short pause* to make sure all the AXEs have stopped processing and are listening, then sends four bytes (TO address, FROM address, Function, Data), then takes the ATTN line low, then returns to processing.

After each AXE has received it’s 4 bytes, it performs a small loop, polling ATTN, waiting until ATTN=low to ensure it does not try to receive the same data twice.

The data could be expanded to two or more bytes as required.

*The pause needs to be chosen based upon the slowest AXE in the network. IE the AXE whose main processing loop takes the longest to perform.

Potential problems:

-Two AXEs trying to send data at exactly the same time.
-Noise effecting the data stream or the ATTN line.
-An AXE missing the data coz it’s main processing loop was slow.
-?

This is all just theory. I’m soliciting comments/ideas.

 

[leftyretro]

-Two AXEs trying to send data at exactly the same time.
-Noise effecting the data stream or the ATTN line.
-An AXE missing the data coz it’s main processing loop was slow.
-?

1. Yes, collisions are still possible. Possibly the sender should wait for an acknowlegement message from the 'TO' address and if not received after a certain period, resend the prior message.

2. Depends on the distance and data speed used in sending. If longer distances were sought then one of the several bi-directional driver chips used in RS-422 type applications would work well.

3. Again a required acknowlgement from every 'TO' picaxe would help this.

Good luck, several good examples of picaxe network ideas and projects have been posted here in the past. Do a search and see if any of them would help your applications.

I would like someday to see a Picaxe I2C 'network' attempted using X1 chips. One X1 would have to act as the master and poll all the slaves X1s for traffic, in order and reroute messages from slaves to slaves. The master X1 would mostly likely have to be dedicated to network controller duty only, but the slaves could run independent applications freely.

Lefty

 

[moxhamj]

I'm on my 4th iteration of boards and extensive testing trying to solve this problem. It all comes down to the serin hang problem. If you send a packet and it gets corrupted in some way or only partially gets there, then the receiving picaxe(s) will go into serin hang forever. If they were doing any other jobs then processing will stop.

You can get around this partially by having one picaxe put dummy packets on the network every 30 secs or so - at least that can kick any hanging picaxes out of serin.

If a picaxe is just sensing, then the serin hang is not a problem - the worst case scenario is that you don't get a reply packet back. If that picaxe were also controlling something, or running some more complex code that needed to keep running, then there is a problem.

You can use the X2 chips with serin timeout but networks of these chips can get a bit expensive.

I needed a circuit where the main processor can never stop working (an 18X), so I've gone for a system where any serial data coming in is translated by an 08 from 2400 baud to about 5 baud, using a hand coded "slow serial" protocol. This replicates the RS232 protocol but it uses picaxe commands "if pinx = high then..." which just timeout if the packet doesn't come through. RS232 uses a start bit and you then test for highs or lows in the middle of the bits coming through. I've had a system sending data down my fence wires for the last 2 years using relays at either end. It is 100% reliable and it is easy to test it is working because you can hear the relays switching. http://drvernacula.topcities.com/slow_serial_data_transmission.htm

The disadvantage, of course, is that it is really slow. An advantage is that you can be polling 3 or 4 input lines and reading in packets from all lines at the same time, and so packets are less likely to be dropped, but you need a picaxe like an 18X with lots of code space to do this.

I2C sounds interesting.

Picaxe networking is not a trivial problem. Sometimes there are other solutions that are better - eg if you want to sense lots of analog inputs, use an 18X with some support chips eg HC373s to expand the number of outputs and 4051s to expand the number of analog inputs. eg 20-30 inputs and 20-30 outputs.

 

[BCJKiwi]

@Retro

The i2c 'network' should be standard fare. It has been discussed recently for a 1 master, 2 slave setup (no reports on results as far as I recall). http://www.picaxeforum.co.uk/showthread.php?t=10076

One master and as many slaves as you want each with their own ID.
Each slave reads/writes to it's own eeprom/scratchpad
The master polls each slave in turn picking up whatever is in the scratchpad, checking to see if it's different, If so, deciding what to do with it and writing it to the relevant slave or acting on it itself.

To simplify things, a structured arrangement for the eeprom/scratchpad in all slaves would probably be a good thing.
i.e. destination ID, and data types always in the same eeprom/scratchpad location in all slaves.
Some decisions to be made regarding what needs to go into eeprom and what can be left in scratchpad.

Obvious limitation is bus length but that can be extended with careful cable selection/shielding, and if necessary, line extenders. Should easily get a few metres with proper cable selection.

Look foward to seeing your application!

 

[boriz]

Thanks for the replies.

The application MIGHT be a home automation/information network in a friends house. He is rewiring the house and has decided to add an additional 12v system with sockets in every room. The plug/socket type he has chosen has spare pins for just such a network.

The idea is that there is no master/slave relationship. Any unit you plug in to any socket in any room can interrogate/control any other, using only two signal lines (ATTN and DATA). The network wiring would have two internal wires and a shield as ground. Unit’s to be powered by the local 12v socket.

Just tossing up some ideas to see where they land.

 

[BCJKiwi]

That ideal becomes very complex, very quickly.

Every device has to know about every other device, including the one's that haven't even been thought of yet.

The code to manage all bus contention issues, timing, overlaps, intelligence etc has to be running in every device. As devices are added, the interconnection matrix becomes swamped with the overhead of all the possible interconnections.

A central unit can act as the clearing house and can interrogate any unit on demand from any other. The central unit does not have to be a controller or a unit that has to be interacted with by the user, it just sits in the background managing the interconnections.

 

[Jeremy Leach]

Maybe a Time Division Multiplexing idea? ....

Each slave picaxe has a timeslot and can send messages on the data bus ONLY in that timeslot to avoid any collisions. Each picaxe can listen to everything on the bus, and can hear what's relevant to itself by picking out the TO identifier. All slaves are connected by picaxe pins that can act as input or outputs.


Message format something like : ¦Sender ID¦ Recipient ID¦ Message (up to agreed max bytes)

On the same bus is a master picaxe. It's job is just to synchronise all slaves. Slaves will only speak when asked to do so by the master. All the master does is send out 'invitations to speak' , cycling round all slaves in turn at regular intervals. Like this ...

¦InvToSpeak¦S1¦.......................................¦InvToSpeak¦S2¦................etc

So the master switches it's pin to output to send the InvToSpeak message, then switches pin to input.

When a slave wants to send data it waits until it hears the invitation to speak string relating to itself. It then switches it's pin to an output, sends it's data, then returns the pin to an input.

Picking out relevant messages from the bus could be easy using serin qualifiers, and by using unique strings (e.g the master actually sending "InvToSpeakS1" etc) the chances of getting the commands mixed up with stuff in the data is pretty small.

I'm not saying this is the fastest method, but I think it could work. ?

 

[Dippy]

Timing sounds like an issue there. Even with a master clock you could still have problems as the PICAXE isn't terribley quick. The above sounds OK. Looking at the line before sending etc. Maybe have another wire for 'I am just about to send' That could pop the devices into Serin mode.

If you don't want Master/Slave/poll then you are going to have to live with collisions and do a data parity check to make sure the lump of data is valid. All very feasible.

 

[boriz]

“…Every device has to know about every other device, including the one's that haven't even been thought of yet….As devices are added, the interconnection matrix becomes swamped with the overhead of all the possible interconnections…”

I’m not sure I understand that. There are no interconnections. There is only one, two wire bus, and all the units tap that bus at any location. They all share a bus, they all read any data on the bus, but each only responds to data addressed specifically to itself, ignoring everything else.

Say I have 4 units: a temperature sensor in room 1, a humidity sensor in room 2, a temperature display in room 3, a humidity display in room 4. The display unit polls its sensor unit at intervals, displaying the results.

Why does the temperature sensing unit need to know about the humidity sensing unit or it’s display unit?
Why does the humidity display unit need to know about the temperature sensor or its display unit? Etc.

 

[Dippy]

Wasn't Dracs system a radio thing where range issues came into it?
I can't see that Boriz's app requires that much complexity(?)

Oh hang on, Boriz with his display... do we have a master now? Can it poll? Or is it just a receiver? If its just a receiver then a 'parity' check would sense collisions. Keep it simple.

 

[Jeremy Leach]

Yes, the idea I gave would need a bit of tolerance adding in, but still think it's a workable one bus solution, and pretty easy to code up.

 

[kranenborg]

Hi Boriz & others,

Have you taken into consideration my SerialPower network concept already?
It is described in the User Projects / Communication section of this forum
Here is the link: http://www.picaxeforum.co.uk/showthread.php?t=7694

I think it basically addresses all of your issues.

See also http://www.bramblyhill.com/Picaxe/serialPower.aspx for an example implemented by somebody else

Note that the network concept can also be used for separate communication and power lines, this option is described in the PDF document as well, and corresponding example files are included on the site

Regards,

Jurjen

 

[jmumby]

I have implemented a picaxe type network but might be a bit messy for what you want to do.

Basically I had a two pole relay one pole spoke to the serin line of all the picaxes and the other spoke via a daisy chain across the picaxes. When the circuit booted up it was in the daisy chain mode the master axe would send a 1 to the next picaxe which added 1 to that and passed it on till the end (only nine 08m's here) once the last picaxe got it's 'address' the relay switched over to the other pole and went in to broadcast mode. When the Picaxe heard it's name with something like....

serin RXPin,BAUD,(addres_byte)

It would accept the rest of the data. You would have to make up some obsure mask I guess like #$%_address so as not send data that would accidentally trigger one to listen. I was controlling RGB leds so didn't need to worry to much about this.

The beauty of this was you could pull out the modules and mix and match them and it wouldn't matter a brass razoo.

 

[BCJKiwi]

@ Boriz;
Shifting goal posts?

Requirements were;
"The idea is that there is no master/slave relationship. Any unit you plug in to any socket in any room can interrogate/control any other" Post #5.
To me that means interconnections (in the sense of communications paths between any and all individual units).

If there is a display unit for humidity and it polls a humidity sensor unit, then wouldn't the display unit be considered a master to the sensor unit?

@ Jurjen;
Was going to recommend your circuit but Boriz was insisting that there should be no master!

 

[Dippy]

That's what I asked in post#10

 

[kranenborg]

The point with the SerialPower network is that - from a hardware viewpoint - there is a "hardware master" purely for providing the timeslots. This node enables the networking facility by providing timeslots. From a functional point of view though (i.e. how messages are sent and received), any other slave node can be a functional master (and the hardware master does not play any functional role at all, i.e. it is invisible - and independent - of the application), or you can define to have no functional master at all, i.e. all nodes are equal. This depends completely on how you distribute your processes since it is processes that communicate, not nodes (there can be multiple processes on one node, and one process can be distributed over several nodes). Thus, Boriz requirement on all processes being equal is very well feasible (and is in fact the default assumption in SerialPower).

Regards,
Jurjen

 

[Jeremy Leach]

I couldn't resist trying to think of a minimal networking solution, so I'm throwing this code in. Untested in real life, but might work.

Jurgen's one-wire work is excellent and this is at the opposite end of the spectrum - very crude, trying to use minimal code and components, and each picaxe still needing common power rails.

#rem
****************************
** SIMPLE NETWORKING IDEA **
****************************

This attempts to give a very simple, workable solution for basic comms between multiple picaxes.
 
- Picaxes share same power rails. 
- Communication between picaxes is over a single Data bus wire.  
- Each picaxe connects an I/O pin to this wire.
- A Master picaxe controls transmissions, and each picaxe only talks when the master invites it to.

NOTES: 
1. The Data Bus wire should have one resistor going to either power rail.
2. The 'Hi' in the serial comms messages is purely to help avoid incorrect message detection.
3. Handshaking schemes would need to be developed on top of this code.

#endrem

#picaxe08m

'MASTER CODE (20 bytes) IN THE MASTER PICAXE
'===========================================
'NOTE: This code could be incorporated into other code that runs on the master, so the master doesn't have
'to be dumb - it could send/receive just liike other slaves.

Symbol ID			= b0
Symbol MaxID		= 5	'Set to maximum ID of slaves on the network.
Symbol MasterIOPin	= 1

Do
	For ID = 1 to MaxID
		'Send Invite To Talk to a slave
		Serout MasterIOPin,N2400_4,("Hi",0,ID,0,0,0,0)
		Pause 100 'The best value will depend on the number of slaves, the baud etc.
	Next
Loop


'08M SLAVE COMMS CODE (51 bytes) IN EACH SLAVE PICAXE
'====================================================
Symbol MyID 		= 1	'Each picaxe in the network has a unique ID. The master ID is fixed as 0.
Symbol SlaveIOPin 	= 1	'A picaxe pin that functions as both input and output.
Symbol RAM_TxBufferLSW 	= 80 	'&81
Symbol RAM_TxBufferMSW 	= 82 	'&83
Symbol RAM_RxBufferLSW 	= 84 	'&85
Symbol RAM_RxBufferMSW 	= 86 	'&87

TxMessage:
	'Transmits the 4 bytes in the TxBuffer. The message format is: <SourceID>,<DestID>,<4 bytes of data>
	'ON ENTRY: b5 holds the ID of the destination picaxe that this message is being sent to.
	
	Gosub WaitForMasterInvite
	
	'Send message
	Peek RAM_TxBufferLSW,Word w0,Word w1
	Output SlaveIOPin
	Serout SlaveIOPin,N2400_4,("Hi",MyID,b5,#b0,#b1,#b2,#b3)
	Input SlaveIOPin
Return

WaitForMasterInvite:
	b4 = 0

RxMessage:
	'Receives 4 bytes into the RxBuffer.
	'ON ENTRY: b4 holds the ID of the sending picaxe that the message will be coming from.

	'Wait for message
	Serin SlaveIOPin,N2400_4,("Hi",b4,MyID),#b0,#b1,#b2,#b3
Return

 

[moxhamj]

If you want no master/slave relationship then it does get complicated. You will need some breadboards, a few picaxes and lots of testing. I'm still working on this, but where I am up to is a generic node board that can be configured as a sensor or a relay board or a router depending on which components are installed. For testing, I've got boards with everything installed just to prove it works.

Each board has 4 analog inputs and 4 analog outputs and 4 digital outputs (relays). It also runs a 20x4 display as I've found you need lots of information about what is going on. Boards communicate via either radio or via a two wire link (Tx/Rx) or both.

The software is written on an 18X, and when you first turn on a board it is configured as a generic router. Messages come in, and are forwarded on. Message headers are stored so a message only gets forwarded on once and doesn't end up going round and round the network.

The network can run with a PC or it can run standalone.

Once some nodes are installed, a PC can talk to the network via any node, and the PC can be used to set up links between nodes. These settings are sent via the network and stored in the appropriate node's eeprom. So a node x can be programmed to link to node y. This is done with an easy to use graphical program written in vb.net which starts with an aerial photo (borrowed from google earth) and then draws on this with node numbers and links etc. What happens is that any analog input to node x appears on the outputs of node y, as if they are connected together. But the message might have gone via any number of intermediate nodes, via wireless or wired links. The user doesn't have to worrry about that though. So you could have a tank monitor, and somewhere else you could have a 5V panel meter that indicates the level.

The PC can also send out messages or get values and can upload them or whatever, but one of the key design parameters is that the system will keep working even if the PC crashes.

There are no "master" or "slave" nodes as such as all nodes always act as routers. They can also be configured to be sensors and receivers of data on the fly, and this sort of flexibility is very useful. You can even have one link setup and then have another completely seperate link that senses the voltage got to the other end, and sends it back to really check the status of a pump etc.

If you are wiring up a friends house, 12V would be great but I'd do the comms with wireless. Pull some cat6 through to every room while you are at it. Indeed, if you are pulling cat6 through, then cat 6 has 4 unused wires and you could always use those in some way.

All the above is an *almost* working system. I'd seriously look at Kranenborg's system as his is proven and working.

 

[boriz]

Thanks all.

@BCJKiwi
“Shifting goal posts?”
Indeed, the essence of this system. The goalposts can be shifted at will. Sometimes their may be an obvious master-slave relationship, sometimes not. And each unit can change it’s relationship on the fly. I should have said no dedicated master/slave relationships. Should the temperature display unit become disconnected, moved to another room for example, the temperature sensing unit is not bothered or effected in any way. And the same works the other way around. At the press of a button (which may reside on either, or a third unit), the polling (by the display unit) can stop and the sensing unit can begin sending temperature information at intervals to any display device(s), making it the master?

“communications paths between any and all individual units”
Yes. When any data gets transmitted by any unit, all units exit their primary processing loop briefly to receive it. But only one unit uses it. (The addressee)

@Jeremy
Nice. That looks potentially workable, but while waiting for an invite, no processing is possible. All the units on the network spend almost all of their time just waiting. This is exactly the situation I am trying to avoid by using the ATTN line.

@All
I was already aware of Kranenborg's system. Excellent though it is, I have decided for the moment to work out a different system (no offence!). I just don’t like to copy other peoples work, and it seems more complicated/expensive than I need.

 

[Jeremy Leach]

Take your point, although could get clever and have each picaxe roughly know when their timeslot is going to arrive, so they can go off and do other stuff in the meantime. Lots of solutions really, and depends on the application.

 

[moxhamj]

You don't necessarily need the "attn" line. Just put a line high for 1 second before sending the serial data, and make sure each picaxe polls the line more often than once a second. Then you can be getting on with other tasks.

Also what topology are you going to use. A star - like cat5 with routers? A token ring? A common bus (like ethernet)? Are you ever likely to want to add radio at any stage, and if so, would you design this in now?

If you are going to use a common bus, how many messages per minute are you expecting, and what is the probability of a data collision?

And how far is the longest run, and at what baud rate, because that may determine the need to go to RS232 signal levels -12 to +12V rather than 0 and 5V.

How will you cope with the resistance of a long run where a picaxe has a local 0V but it ends up being 0.8V with respect to another picaxe? Or worse, 3V and a low becomes a high? What is the highest current consumption of a node?

Just a few questions to keep you awake tonight

 

[boriz]

@Jeremy
“…roughly know when their timeslot is going to arrive…”
This sort of synchronisation is only possible with a ‘mother’ controller, similar to the system you describe. I would like to avoid that if possible, and for each unit to feel free to TX, as and when it needs to. (Assuming the ATTN line is low at the time.)

@Dr
That might work, but surely it would slow things down an awful lot, tying up the data line for a second each time any unit wants to TX. Add a little backchat/handshaking and it could take many seconds just to communicate a few bytes of data, tying up the network for that duration. Over 4 seconds for the AXE5/AXE2 example in post #1 where all that is communicated is a two byte number.

I don’t know the technical term for it. Just two signal wires and a shield. I’m sure I can find a suitable cable. One very long cable that passes from room to room with ‘taps’ at convenient places: Wall sockets where the 12v and the PICAXE units connect, through the same connector. Come to think of it, there is a pound shop near by that sells 5M lengths of stereo AV cable with audio plugs on each end. (Like the composite video plugs)

Packets per second? Unknown. The maximum possible figure will have to be determined by experiment after installation. The unit’s subsequently designed based upon that. But in theory… At 4800 Baud it takes about 1mS per 5-byte-packet. Add a pause as mentioned in post #1. Call it a maximum of 40mS for a complete TX/RX and return to ‘processing+polling ATTN’ cycle. That’s an estimated 25 packets per second minimum. I’m more than happy if it works out that way. Even 2400 Baud would be enough.

Longest run? Hmmm. It’s a small house, but with the cable zigzagging around the walls, maybe 20m? It could end up being a main trunk cable, with shorter tapped cables off that.

The 12v power ring supplies the current, each unit having it’s own 5v regulator. 30 Amp twin-and-earth should be fine. Very little voltage drop on the ground wire I suspect. Since 12v DC only requires two conductors, the third could be a separate signal earth maybe. Don’t think it will come to that though.

Great responses guys. You are really helping me crystallise my thoughts.

 

[Jeremy Leach]

It's getting me thinking too. The way I look at this topic is that it's nice to try to create generic networking solutions, but in practice picaxes have limited resources, plus so much depends on system requirements - how much data, waiting times, how fast, distances etc etc (like Drac says).

If it was me I'd get my requirements clear - down to how many milliseconds wait etc - and then build a custom solution optimised for these requirements. If using 08Ms then code size is likely to be critical and the simpler the better.

What's interesting me at the moment is the challenge of getting a workable (not fast), short distance solution for some 08Ms, using the bare minimum of code, able to communicate 4 bytes at a time (although that's just an arbitrary figure that could be 'useful'). I'm thinking of perhaps ditching serin and serout in favour of bit-banging. I've not got any real idea in mind but just for fun and the interest of seeing how simple you can go. Would be interesting if other people have got ideas for a very minimal solution too.

 

[moxhamj]

One second was just for testing. You could make it 10 milliseconds if you like. It all depends on the speed of your main: ...goto main loop.

Maybe write out the specs for your system. It will help define what you want. Personally, I think cat6 is the way to go, as it happens to be one of the cheapest cables around per metre. And it is a bit of a secret that PCs only use 4 of the 8 wires. You can do what you want with the other 4 - they are not connected. Just thinking aloud about when I built my house and thought I would have a computer in the study. Now each of the 3 kids has a computer. And 2 in the shed. A cat6 wired house is an asset. Cat6 is twisted pair too so you don't have to worry about interference.

How much power is each node going to take? If just a picaxe doing some sensing, maybe 10ma. But if you are running relays and emergency lights etc, maybe amps? If amps, then cat6 won't be enough. But copper and thick copper wire is expensive.

What are all these sensors for? What might you decide to add in the future? If you really did need to power something that needed watts rather than milliwatts, would you run that device off a mains transformer rather than from the 12V supply?

Lots of questions!

 

[boriz]

Dunno, dunno, and dunno. I'm making all this up as I go. It might end here or it might end up running my mates house.

Just trying to create a framework for a simple asynchronous PICAXE network based upon all nodes being equal. I don’t have enough 08s to build a network ATM. So for the time being at least, my main question is: In theory, why could this system not work.

The main problems as I see it, are:

- 1. Two units attempting to talk at exactly the same moment.

Unlikely to ever be a problem because the ATTN=low check is only one instruction before setting ATTN high. For this sort of collision, two AXEs would have to both try and send data within a time period equivalent to the execution of one instruction. (Whatever that is). When this does happen, hopefully all it means is that one of the packets will be corrupted so none of the other units will respond. A simple solution would be to use simple handshaking like a ‘data received ok’ response.

- 2.One or more units missing data or slowing down the network by taking a long time to pass through it’s main processing loop.

This also is unlikely to cause any real problems. The TX unit needs to know the address of the RX unit. So it could also know how slow is it’s main loop. The TX unit includes an appropriate delay between taking ATTN high and sending the packet. This slow relationship will only exist for sending data to known slow units, so the rest of the network can continue to work at higher speeds. Each relationship being unique and customised during programming, presetting any required delays.

- 3. RX stalling due to corrupt/incomplete packets.

This has potential to be the worst problem I think. But even if RX units stall on the SERIN program line, they will be kicked out of it next time a packet is sent. Simple handshaking as indicated above might solve this problem too.

The FUNCTION byte could be exploited as a simple checksum in addition to it’s routing role. The first 4 bits being the router, the next 4 bits being a basic checksum. Or maybe 3-5 or 2-6, whatever.

@Dr.
Hopefully twisted pairs will not be necessary. It requires extra discrete electronics at both the TX and the RX. I’m trying to keep this simple.

 

[Jeremy Leach]

To me, collision detection is just a headache (plus code) that can be avoided if you have a master. I see you want to have no 'dedicated' master', so another idea would be to have every node capable of being a master, and a local agreement on who will take the role:

For instance, on power-up all picaxes are powered up at same time. Each picaxe has a different start up delay programmed in, and each listens to the line for this initial delay. After this delay if no other picaxe has set the line high then the picaxe assumes master role and sets the line high (for a time long enough to account for the longest start up delay), then has to perform master-duties of invites etc.

Yes, it might be difficult to get all nodes to be capable of being a master ...but it's just an idea ;-)

 

[Dippy]

I would have thought if you have a separate wire for ATTN then this is relatively easy and no need for masters/time slots etc. Easy job for interrupts.
I can't see that you would have problems with data packets lost causing Serin to get stuck. Send your packets twice - its only going to be a few bytes isn't it? Or use PICAXEs with timeouts.

Like I said before, a parity (or checksum if that sounds better) check would be easy to do surely. Even if you were doing synchronous/master arrangement I still think parity checking would be needed especially over long cable runs (corrupted/lost bytes), so I think Jeremy's headache would exist in either case.

Is this going to be a 3 wire system? (Tx, Rx, ATTN). Or 2 wire (Tx/Rx, ATTN). Or 1 wire?
I don't know which PICAXEs you are planning on using but I would suggest chucking in some transistors to make it an open drain for prevention-of-embarrassment.

Anyway, it appears that everyone knows best. If I were you Boriz I'd start experimenting. Thank everyone for their suggestions and get on with what you want to do. It will be a great learning process and you may change tack during development.

And I'm sure DrAc has had quite a few customers having problems with twisted pairs
Maybe even Manchester code the data - just kidding.

 

[Jeremy Leach]

Yep I'm sure you're right about cable runs and parity Dippy.

Can see you need to be careful with interrupts .... ie if subA is reading received data from RAM etc then the interrupt routine fires and overwrites the RAM and then you return to subA and it finishes reading the RAM ...but doesn't know that the data has changed. So could get corruption. Just need to think about this scenario too.

 

[Dippy]

This is where a pencil, a piece of paper and a sober cerebellum comes into play...
Can't beat planning it out on a clean sheet.

 

[ciseco]

Hiya,

I'm reading this with great interest as it's a problem I saw some time ago but couldn't begin to solve (even visualise), you guys are doing sterling stuff, if it can be cracked it would be a really inexpensive automation system. Rewiring the house might not be though and my misses wouldnt stand for it

I went in a different direction, most of the issues faced are overcome by using XBees as the transport instead. A PC master to poll them and reissue any failed commands (not done yet, but it hardly ever misses a beat on the first command). I've currently got 17 devices - 7 light switches, 1 boiler switch, 1 battery monitor, 2 solar powered PIR's with onboard battery monitoring, 4 temp sensors, 1 hand held remote and 1 PC interface. They all co-exist with no decernable issues running at 115Kbps. Any problems I've had are usually weak signal related as you'd expect.

I'm having to use wifi style rubber duck antennas on anything over about 20ft and through our 200 year old solid walls, with a PRO in the interface and a 5db duckie on the PIR it's going through 2 x 9 inches of brick and across maybe 60 ft to the PIR on the front gate, in open space I can get hundreds of meteres but's thats hardly typical.

How can I get some of your collective grey matter in making this even better???

Miles
________
video reviews

 

[Dippy]

Is the final brains-trust product going to be sold by your company?
If so, there's a charge

 

[ciseco]

Hi Dippy,

Yes we share profits on designs, it's only fair to, we also publish everything openly so give back in this way also. Anyone can download our circuits and build them for free if they so chose, we just draw thew line at commercial products where we'd like a very small licence fee per device. We may never be rich but I hope we can make a living

Cheers

Miles
________
health store

 

[Dippy]

I was only joking...

 

[moxhamj]

Re Dippy "This is where a pencil, a piece of paper and a sober cerebellum comes into play..."

Hmm - I probably can manage two out of those three..

Nothing fancy about twisted pair. It is just two wires twisted together so they pick up less interference and the data goes further. Cat6 is made this way so the twisting comes for free. It is still just some wires at either end.

Biggest problem I found is that the network worked fine with 2 or 3 units. Each one resent if the data didn't get there. But when you get to 10 units and each one is resending and suddenly there are data clashes and the resends spawn more resends and the whole network has an epileptic fit. So this network is suited to infrequent data - maybe a packet every 5 or 10 mins.

The xbee network sounds fast! Much faster than a wired network. Any chance of writing it up and publishing it on the net?

 

[ciseco]

Hi James,

Already is available on my website, there's lots that needs finishing but I get a bit more done day by day, all on my jack jones with this at the moment, feel free to pick it apart and reassemble into something more meaningful

There's 3 parts I'm covering, PC side software, protocol and end device (both circuit and code) so is a complete wireless network solution, if rather basic at the moment, have come from nothing to having it working and dev boards/interfaces available in 7 months so things change really rapidly.

As a test I built a hotwater sensor the other day, bit of solder and cut and paste of code and 7 mins later, as ramsey would say DONE

Hardly plug and play but I was happy. When funds allow we hope to make nice pretty boxed products that will be plug and play, thats months away for me at the moment but am starting to canvass designers for quotes to speed things up.

Take a look www.ciseco.co.uk, docs are in the forum

Hope to have a real time electricity monitor done in the next few days, so really busy, too busy infact

Cheers

Miles



Oh just a thought, it's a compatible with the AXE210 boards some of us have bought from tech supplies, I'm not going to support them directly as our dev board has different pinouts and a 28x1 + other mods, but they work fine (except for the XCTU software) which our interface supports.
________
Mazda AZ-Offroad

 

[boriz]

“…each one is resending and suddenly there are data clashes and the resends spawn more resends and the whole network has an epileptic fit…”

EEK. That sound scary. I think that was at the back of my mind and I was desperately trying not to think about it. Bugger. Thanks Doc. That’s exactly the sort of feedback that’s gonna help make this project.

Twisted pair provides noise rejection thus:

The digital 0v-5v signal, is converted into a differential signal by a pair of op-amps. One of the op-amps is a buffer, the other an inverter. The two op-amp outputs are connected to each of the twisted pair wires. Call the wires TP1 and TP2. A digital HIGH is represented by one of the op-amps going HIGH and the other going LOW. Digital HIGH = TP1@HIGH, TP2@LOW. Digital LOW is the opposite, TP1@LOW, TP2@HIGH.

At the receiving end, another op-amp takes TP1 and TP2 as its inputs. Since one of the inputs is INVERTING, it is essentially subtracting one signal from the other. If you subtract LOW from HIGH you get HIGH, and if you subtract HIGH from LOW you get LOW. The output of the RX op-amp can be used directly as a TTL signal for the digital receiver.

The way this system defeats noise is by the subtraction. Any electrically induced noise picked up by the twisted pair on it’s route will be the same polarity, amplitude, wave shape, phase etc. in both wires because of their intimate proximity. So when one signal is subtracted from the other, the additional noise disappears. (If you subtract 1v from 1v you get zero)

The system I have described uses a single wire for TX and RX. Separating these functions would be complicated indeed. Each AXEs RX would have to be wired to all the other AXEs TX and the vice versa. A real rats nest.

 

[moxhamj]

Hi Miles,

Had a look through your website - very interesting.

My nodes are all working - I just have a minor bug where one in 100 packets causes a serin hang and then the analog outputs reset to zero. All the rest is working. But I'm a bit of a perfectionist and so I've got some more boards on the way with a design that ended up using a few less chips anyway.

I'll publish it all when it is stable and perfect.

Like this post, I started by trying to do it with 08 chips and very simple protocols. The problem is that things grow in complexity! If you are sending one packet every 10 mins between two nodes, that works fine. But when you have 10 nodes all chatting, the airwaves (or the common wire bus) gets a little crowded. So then you need to route the messages more efficiently, and that takes more code, and you need a different picaxe etc.

I've got two projects i'm building. An 18X node system. And a hybrid Z80/picaxe system that uses picaxe as a wakeup and then the Z80 to send much larger files. Both would be working in less than a week if this was my full time job!

Re cabling a house - it could be quite handy to have 12V available anyway in each room. You could use it for emergency lighting, night lights and to power all sorts of low voltage things. A single 10W transformer is a lot more efficient than 10 1w wallwarts.

Re op amps and differential signals - have a read of this http://www.rs485.com/rs485spec.html

If you want a range up to 50 feet, RS232 will do. If you want to go further RS422 etc. These interface chips are cheap and they work well. They also "robustify" the picaxe output signals - eg if you short the pins or accidentally stick minus 10V up a line. Round a house, I would doubt you would need twisted pair and I think RS232 using max232 chips would be the practical option. 4 core alarm cable is pretty cheap if no device is going to draw more than 50mA. Or a thicker twin flex for 12V and a thin twin flex for data.

The only catch with RS232 etc is how do you do the wire-or thing - eg several nodes talking at once. This is not such a trivial problem to solve - now you are getting into the realms of RS232 routers. And if you don't use RS232, you will limit the range or bandwidth.

Having said that, you might get away with direct picaxe to picaxe comms in a house using a wire or network with diodes. Try 300 baud and work up.

 

[boriz]

Thanks for the link Doc. On that page it refers to Drivers and Receivers. That is what I was trying to describe. It makes things much more complicated.

 

[Dippy]

Whilst it isn't difficult to MAX232 your system, why don't you try it simple first?
Maybe leave a little space on your PCB where you can insert a Max/caps block if needed. It certainly would add a nice buffer and probably help. Sounds like a good idea, though I'm not sure how MAX232s behave when a few of them are connected together in network. Thats a breadboard experiment. But whatever you choose, you should have a buffer of some type. A couple of transitors is the easiest route for a 2 data wire setup.

Your system is surely much less complex than Drac's setup in terms of data. Dracs is potentially dozens of times busier. And I wouldn't get too bogged down with tales of meltdown. Its not a digital TMI.
If I were you I'd have a pile of PICAXEs and wires hanging out of breadboards and start banging away right now. And get back here in a week's time saying "Job Done!".

 

[boriz]

Of course. Now where’s that checkbook…