Emergency door state detector with 433Mhz

[kakolon]

Hi, I’m trying to develop a project that will have a program in a PC, to monitor the state of some doors (state is Open/Close).
The PC software is no problem. The problem is that I want to have the door sensors to send the door state wirelessly to the PC as wiring is very expensive and very hard to do.
As the distance between the computer and all the doors that will be monitored is long, I'm thinking in using the "repeaters" example that was exposed in the forum.
The normal state of all the doors is "closed". Once a door is open I have to send the "open" state to the computer that will show what door was opened. Once the door is closed, the computer will update the open state to "close".
I'm going to use the RX-TX 433Mhz modules and Picaxe 08, to transmit the door states.
One of the questions I have is, if I have 2 or more repeaters that will be waiting to receive data and then retransmit it, and two doors are open at the same time, so in the air there will be to transmissions at the same frequency, what will the repeaters get?
Will all the data get mixed up?
How can one manage numerous transmitions in the air and get them all?

Thanks in advance for any advice,

Kakakolon

 

[papaof2]

Before you get too far along in the design, some questions:

How do you know which door has been opened?

How will you know that the door sensor is still functioning if a door is not used for hours?
Consider some type of "I'm alive" message sent from each sensor every few minutes.

Expand on the "I'm alive" message and include a low battery warning.

The easiest way to ensure that a message is received is to send it several times, with a longer-than-message-length delay between messages (if a message takes 0.1 seconds to send, send 3 times with 0.2 seconds between messages). This may require some memory at the door to handle an open/close sequence that occurs in less time than is required to send the message.

The ultimate method is to also have a receiver at each door and have the central unit send a verification when it receives a message from the door transmitter. If the door receiver does not see the verification within some number of seconds, it will telll the transmitter to resend the message. This also may require that the messages have a sequence number associated with them, for those instances where doors A and B are opened and closed simultaneously several times and the messages block each other repeatedly.

I use an X10 wireless alarm system to monitor 4 entry doors, 1 garage door, 5 windows (all using magnetic switches) and 2 hallways (using motion detectors). X10 now offers PC software that can monitor the wireless alarm sensors, in addition to the dedicated alarm controllers. The X10 remotes send both the "I'm alive" and low battery messages in addition to the open/close messages. In this case, the longest distance between the dedicated alarm controller and a wireless remote is about 35 feet.

John

 

[kakolon]

Thank you John for your suggestions,
I would know witch door was opened because each door transmitter sends a unique code in the serial data to the computer receiver, ex (door01, door02, door03, etc).
I was willing to make it one way only to simplify things, so the door transmitters only send data. But I understand that a keep alive signal is very important to know, but I can send this keep alive signal from time to time from the door transmitter, so the computer knows it functioning right.
There may be up to 20 doors, so my fear is that the transmissions and retransmissions will collide in the air. Is this real or is it just my ignorance on the subject?
The other cleaner approach is the one you wrote, about being the computer the one that asks the door what is the state, that way there can only be one transmitter talking at one time, but to make this I have to work in both ways in the doors RX and TX.

 

[manuka]

Good suggestions so far! Start simply & perhaps develop the project on an incremental "learn by doing basis" however to tweak any bugs. Be particularly alert to the possibility of false triggering & noise on 433MHz as well. How mission critical are things if door status is false due to phantom signals? Stan

 

[Peter M]

Are the doors on some sort of incrimental distance from the computer ie. like a hallway. If so you could use a daisy chain, the furthest sensor sending its data the next receiving that, adding its data and sending and so on (using addresses so that only one would transmit at a time). With some sort of an indicator so if one doesn't receive data after a predtermined time allowing for easy fault finding (like the heartbeat led on smoke detectors... all the units past the one not recieving data hold a led on for example).
The PC could then raise an alarm if no data received after, say the time it should take to receive 3 sets of data?

 

[moxhamj]

This is quite a complex problem and one that I am slowly working on myself. If a door opens it transmits a signal to the computer. Simple. But what if two doors open at once? The signals clash and neither signal gets through. How does each door know its signal has got through? One answer is to send the signal several times. But this only works for a small number of doors. Very soon the airwaves are congested with lots of duplicate signals going back and forth.

I think the communications need to go both ways - from the door to the computer and back again. Ideally, when a door sends a message then all other doors stop talking for a moment. A way to do that is to send a header of lots of 01010101 (character 'U') first. Any door that hears this will not transmit for a second or two.

Then one needs to work around the Serin hanging the system. There are solutions that use two inputs - one to monitor any data (a diode, resistor and capacitor) into another pin, and only when that goes high does the serin code get activated.

Next issue is to look at an optimum path. If the transmitters all have short range then the best solution is for the signal to take the shortest path through the miinimum number of repeaters. I've looked at each unit transmitting all packets to all other units, but again, the airways get congested.

My latest experiments are looking at each unit building links with units nearby. This involves more code eg an 18X and there are subroutines that are devoted to testing links and only keeping links that are 100% reliable. Each unit thus has a list of units nearby that it can reliably talk to. This list can be sent to the computer and the computer can build a map of all the units and then work out an optimum path for a message. When a message is sent it only goes via this path.

 

[hippy]

With any asynchronous multi-source signalling expect collisions and corruption. That can be designed around.

Firstly, don't send immediately the door is opened or closed ! Regularly send a status message once every N seconds saying if the door is open or closed. The N second delay won't be catastrophic and N can be reduced later to get best response. That also provides the "I'm here" heart-beat signal.

The N period can be adjusted for each door / transmitter. Door1=1S, Door2=3S, Door4=5S, so even if there are collisions they will slowly roll out of synch and get a free slot.

For a large number of doors though you could have problems. Worse still if you have repeaters also cluttering up the airwaves.

Also, watch out for feed-back on repeaters. A hears Door1 status, sends it out, B picks it up, A listens, B sends out what A sent, A gets Door1 status again but from B !

XBee's may be a better bet than 433MHz. They can be used autonomously without a PICAXE to send status ( door opn or closed ) and apparently support mesh networking.

I'd suggest seriously looking at a wired monitoring system, at least connecting multiple doors in near vicinity together to reduce the total number of over-air-transmitters. Although it's not likely desirable to do the wiring it could well work out cheaper long term and far quicker to implement.

The $64K question is how business critical is this system ? What hapens if it doesn't work or not as well as hoped for ? Also is it essential for security purposes ? Or worse, as part of a safety critical system ?

 

[Dippy]

If range and money isn't a problem I'd get the PC to 'poll' the door transceivers. This completely removes data collision problems and makes programming a whole lot easier.

 

[kakolon]

Good suggestions so far! Start simply & perhaps develop the project on an incremental "learn by doing basis" however to tweak any bugs. Be particularly alert to the possibility of false triggering & noise on 433MHz as well. How mission critical are things if door status is false due to phantom signals? Stan

The objective of this door sensors, is to monitor if an emergency door opens. The emergency doors are exit doors that doesn't have a lock and are used only in an emergency situation (fire, etc). But as they don't have a lock, they can be used for burglary, so a guard office will have a program in a computer that will alert if any door if opened.

 

[kakolon]

If range and money isn't a problem I'd get the PC to 'poll' the door transceivers. This completely removes data collision problems and makes programming a whole lot easier.

I'm really thincking in this solution, the computer will ask each door what is the state and refresh the monitor program. This way there can only be one transmittion at a given time.

 

[kakolon]

With any asynchronous multi-source signalling expect collisions and corruption. That can be designed around.

Firstly, don't send immediately the door is opened or closed ! Regularly send a status message once every N seconds saying if the door is open or closed. The N second delay won't be catastrophic and N can be reduced later to get best response. That also provides the "I'm here" heart-beat signal.

The N period can be adjusted for each door / transmitter. Door1=1S, Door2=3S, Door4=5S, so even if there are collisions they will slowly roll out of synch and get a free slot.

For a large number of doors though you could have problems. Worse still if you have repeaters also cluttering up the airwaves.

Also, watch out for feed-back on repeaters. A hears Door1 status, sends it out, B picks it up, A listens, B sends out what A sent, A gets Door1 status again but from B !

XBee's may be a better bet than 433MHz. They can be used autonomously without a PICAXE to send status ( door opn or closed ) and apparently support mesh networking.

I'd suggest seriously looking at a wired monitoring system, at least connecting multiple doors in near vicinity together to reduce the total number of over-air-transmitters. Although it's not likely desirable to do the wiring it could well work out cheaper long term and far quicker to implement.

The $64K question is how business critical is this system ? What hapens if it doesn't work or not as well as hoped for ? Also is it essential for security purposes ? Or worse, as part of a safety critical system ?

I think the repeater loop problem can be solved, using unique preambles for every repeater, so, Repeater A sends it to repeater B, and B sends it to C, Repeater A won't receive repeater B transmission as it will have another preamble that only repeater C can accept.

 

[Dippy]

Kakalon, is a PC really required?
Why not just have a box with a display/sounder?
Then u wont have to rely on Microcrash or the PC software.
And it would be easy to have repeaters plus polling. Polling would also be easier to see if the door transceiver has failed/out of range as you won't get any possibility(?) of data collision. That would be my preferred option.

You could also make the system 'trainable' should you wish to add sensors. I've done it - so it can't be difficult

 

[BCJKiwi]

If you are monitoring for security then you need to signal immediately something happens, else the door can be opened and closed again and be missed if there are delays in the sensing/sending/retry process.

So why not a standard commecial wireless burglar alarm system? - after all, that is, in essence, what is being emulated here.

 

[kakolon]

Kakalon, is a PC really required?
Why not just have a box with a display/sounder?
Then u wont have to rely on Microcrash or the PC software.
And it would be easy to have repeaters plus polling. Polling would also be easier to see if the door transceiver has failed/out of range as you won't get any possibility(?) of data collision. That would be my preferred option.

You could also make the system 'trainable' should you wish to add sensors. I've done it - so it can't be difficult

The client wants it on a computer, besides with the computer I can give reports on all events that happend on every door, etc. The computer will just receive serial information from a master Picaxe, all the work will reside in this Picaxe.

 

[kakolon]

If you are monitoring for security then you need to signal immediately something happens, else the door can be opened and closed again and be missed if there are delays in the sensing/sending/retry process.

So why not a standard commecial wireless burglar alarm system? - after all, that is, in essence, what is being emulated here.

Yes, I could buy something already made... but that's not the idea. I wan't to develop it myself. I know its not that simple but its possible. Besides getting this working will give me plenty of know how to develop other projects that could use this.

 

[papaof2]

"The emergency doors are exit doors that doesn't have a lock and are used only in an emergency situation (fire, etc). But as they don't have a lock, they can be used for burglary, so a guard office will have a program in a computer that will alert if any door if opened."

If the doors are used only as emergency *exits*, this may be a place for a hardware solution - the "crash bar" type door latches used on emergency doors so the doors can be opened from the inside by pressing the bar, but the doors are locked on the outside.
Many of these are available with built-in audible alarm when the door is opened.

John

 

[kakolon]

"The emergency doors are exit doors that doesn't have a lock and are used only in an emergency situation (fire, etc). But as they don't have a lock, they can be used for burglary, so a guard office will have a program in a computer that will alert if any door if opened."

If the doors are used only as emergency *exits*, this may be a place for a hardware solution - the "crash bar" type door latches used on emergency doors so the doors can be opened from the inside by pressing the bar, but the doors are locked on the outside.
Many of these are available with built-in audible alarm when the door is opened.

John

Yes, the door have exactly what you said. You can only open them from the inside. And that’s where the problem is, there are employees witch use this exits doors, to steel goods, and avoid the normal employee exit door where they might get caught. So they want to monitor this doors, to avoid this. (The doors also have an audible alarm if they are open, but they also want to have it monitored

 

[BrendanP]

You're trying the reinvent the wheel

I've installed several commerical video surveilliance systems.

I sugested you get a GeoVision video card to go into the pc and get some cameras. The GeoVison cards can be configured to trigger alarms when the card detects movement in nominated areas.(such as your door way) You'll have the alarm function as well as a record of who went where at what time. The cards are cheap and work well, plus you can remote access the system on the web. The GeoVision card can be interfaced with a cash register as well so it will log into the pc the amounts entered in the register so you can see what cash in placed in the til and corresponds with what the staff actually ring up in case they're milking the till.

My brother and his wife have a retail shop in Melbourne, they bought another bussiness in Bundaberg, Qld. so they moved up there. Margs can log on and see and hear what is happening in the shop from Bundaberg when ever she likes.

You're trying the reinvent the wheel, this sort of security app is well trodden path.

 

[Dippy]

Aw Brendan, don't be cruel.
Dozens of projects that people do on this Forum are , as u say, 're-inventing the wheel' - but people want to try things for themselves.

Nothing wrong with 'building a better mousetrap' is there?

 

[BrendanP]

Why bust a gut and end up with some Heath Robinson style setup?

I didn't mean to sound cruel, apologies if I did!

As anyone knows whos taken on one of these projects it takes MUCH longer than expected,costs much more, is more difficult etc. etc.

If regulars like Dr.Acula are wrestling to get 2 way picaxe based RF comms working effectively that is indicative its a challenging project for a tyro.

Why bust a gut and end up with some Heath Robinson style setup to do what 'slave labour' in east asia has already done well for peanuts?

But having said that I understand experimenting is fun and educational so go right ahead.

 

[kakolon]

I didn't mean to sound cruel, apologies if I did!

As anyone knows whos taken on one of these projects it takes MUCH longer than expected,costs much more, is more difficult etc. etc.

If regulars like Dr.Acula are wrestling to get 2 way picaxe based RF comms working effectively that is indicative its a challenging project for a tyro.

Why bust a gut and end up with some Heath Robinson style setup to do what 'slave labour' in east asia has already done well for peanuts?

But having said that I understand experimenting is fun and educational so go right ahead.

Hi, Brendan
Im aware of what you said, before beginning to get into this project. It's a tough one! and you are right. But the good part is that the economic investment I have to put in, to test if this project would work is low. So if it ends up not working at all, I will have a few less coins in my pocket but a great deal of new expertise on something new in my head.

 

[moxhamj]

Technical questions: can the controlling PC communicate directly with each radio unit? Or does a message need to go via a repeater? Or via several repeaters?

Also, what radio units are you using and have you tested the range yet? The ranges given for most units are usually quite optimistic and assume high aerials and direct line of sight and tend to give the longest distance one can hear something with a speaker, not the distance one can send data with 100% reliability.

Also, how are each of the units going to be powered, and if by batteries, how will you know when the battery is flat?

 

[BrendanP]

No problems, if you decide you what to go the camera route at some point post and Ill tell you what to do, cameras are easy to install.

 

[Rasmus]

What about using Xbee's for this?
The new Xbee2 support meshing and routing of messages.
I'm building a project for my house with theese and they work like a charm.

R.

 

[kakolon]

Technical questions: can the controlling PC communicate directly with each radio unit? Or does a message need to go via a repeater? Or via several repeaters?

Also, what radio units are you using and have you tested the range yet? The ranges given for most units are usually quite optimistic and assume high aerials and direct line of sight and tend to give the longest distance one can hear something with a speaker, not the distance one can send data with 100% reliability.

Also, how are each of the units going to be powered, and if by batteries, how will you know when the battery is flat?

Hi,
What I was thinking, was that the computer will be dumb, in means that it wont handle any decisions, it will only receive information from a master picaxe that will do all the work and pass serially all the info to the PC.
The other question: Yes in most cases, the info will go trough repeaters before arriving to the door unit.
All the door units and repeaters will be plugged to AC, no batteries.

 

[kakolon]

What about using Xbee's for this?
The new Xbee2 support meshing and routing of messages.
I'm building a project for my house with theese and they work like a charm.

R.

Hi,
xbee is not available in my country.

 

[hippy]

Hi,
xbee is not available in my country.

Presumably though you do have a postal service ?

 

[kakolon]

Presumably though you do have a postal service ?

Yes I can buy them by a courrier (Fedex, UPS), but at the price it arrives here, if you add the price of the Xbees (they are not very cheap to start) + Fedex + import tax = very expensive devices.

 

[Mycroft2152]

One very important question, are the frequencies used bny the Xbees legal in your country?

Myc

 

[moxhamj]

Every few months I look at xbees and after about an hour end up walking away confused. I still have a couple of unused ones sitting in a parts drawer. They now list video options on their website, but it isn't clear if the video goes over the network or whether the network can just be used to turn a camera on and off. Some of the prices are a bit secret too - I had to click right through to ordering a part just to find out a price. I'm sure xbee can do this application but I don't know how it would do it. I'd still feel more confident building it up from picaxes than using xbee.

Anyone out there written up an easy how-to guide for xbee in a mesh with the routing to a LAN?

If you have power near each device then it makes things much easier. Going off on a low power tangent, there are RF modules that only use microamps and an output could go into a diode/RC network and charge up a a cap over 0.1secs and then a picaxe could come out of sleep every now and then and turn on to get the data. This would be useful if the network were battery powered. But if you have power it is much easier.

The hardware could be simple. Picaxe. Rf Tx and Rx. Sensor. Transformer and rectifier.

The software is the complicated part. If the messages are time critical then the message has to get from the door to the PC in the smallest number of jumps through repeaters. That means somewhere there needs to be a list of all nodes in the network and each node needs a list of other nodes it can talk to reliably. There would need to be a communications check (maybe once a day) where each node checks its list of buddies and that they are still in range and comms are (say) >98% reliable). These lists could be sent through to the PC and the PC could build up a list of shortest paths for each door to the destination. These shortest paths list (just a series of a few numbers) could then go back to each node. A message packet would then start off with a list of numbers (all the nodes it goes through) and each node shortens the list by one and then sends the message on to the next node. Once any node detects a message - if the message is for that node then act on it, and if not then stay silent for a few seconds so there is no unwanted RF interference for the packet. An acknowlege back from the PC to the door might be helpful too, and if no acknowledge goes back then the door resends a few times.

This is code that might fit in an 08M if the PC did all the steering, or might need an 18X if the nodes did more of the self discovery of nearby nodes.

Quite a fun project. I think this is going to be more work with pen and paper before writing any code.

 

[hippy]

Yes I can buy them by a courrier (Fedex, UPS), but at the price it arrives here, if you add the price of the Xbees (they are not very cheap to start) + Fedex + import tax = very expensive devices.

Rev-Ed sell them so you can order them whilst getting the PICAXE's you need, or ask a local PICAXE distributor to get them via Rev-Ed. They aren't that expensive when compared to normal 433MHz, especially that they are bi-directional and include error checking and re-transmission on failed message passing etc.

 

[moxhamj]

This depends on an answer to a question I've asked in a seperate thread about arrays, but I've been thinking about two solutions. The first is complex involving 18Xs with lots of self discovery about local connections. But there is another solution that might work with 08Ms that does all the clever processing in the PC. Consider a PC and a single wireless node. The node is sitting with a serin, hanging, and waiting for a data packet. The node has a number - 0 to 255. The PC knows that there are one or more nodes out there, so cycles from 0 to 255 looking for a response. When the node gets a packet it sends back a response. The PC then sends lots of packets to that node and determines the % reliability of the connection.

Now add a second node - either in range of the PC, or out of range but in range of the first node. The PC first cycles through looking for that second node as well and if it can communicate directly it stores that data. But then it sends messages via the first node looking for nodes that first node can talk to. The packet might be UUUUABC then b0 to 13 where b13 is a U (crude checksum), b0 to b10 are the sequence of nodes the message must go through and b11 to 12 are data bytes.

The first node gets this packet (first node number in b0), and forwards it on to the number in b1 etc. The second node gets this packet and stores the sequence of nodes the packet took to get there in scratchpad ram. This is now the sequence it needs to send any packet to get it to the PC. It sends back an acknowledge, and the PC then tests this link for reliability.

Any node looking for a status change (door) must not be hanging with serin so there might need to be a smart circuit (a diode/RC network fast enough to pick a sequence of U's coming in and switch to serin to get the packet, but otherwise listening to the door. Or maybe another serin hang workaround (still thinking about this one).

Now add a third node. The PC goes through the same sequence and it will take longer and longer to discover nodes but eventually they are all discovered.

If the power goes off in a node it will lose the sequence to talk back to the PC but the PC will eventually rediscover the node and program back in the sequence.

If a node wanted to send a message to another node it would send it via the PC which is slightly less efficient than direct transfer but an awful lot simpler.

Any packet will have the sequence of nodes it needs to follow, and so any node not in the sequence will ignore the packet.

At 2400 baud a packet of 14 bytes can be received and sent on in less than 0.1 seconds so the transmit time of the network is fast.

The task for each nodes are kept very simple - either turn something on or off, or sense something when the PC asks for it, or detect a change in a status of something and send it to the PC via the path programmed in ram.

I'm pretty sure this can fit in an 08M if the path sequence can be stored in an array so that values can be checked in a for/next loop efficiently.

Brainstorming ideas greatly appreciated!

 

[Dippy]

I sort of follow you Drac and the network method is nice. A drawing would be nice as there were a lot of nodes kicking around there mate.

Could you cure some of your hanging probs by selecting RF modules which have RSSI? This could be used to initiate an interrupt and reduce the probability of hanging. I have used this method when experimenting with polled RF but, I confess, i wasn't using a PICAXE. (However, it did work pretty well with un-Manchestered data).

(I was also using the RSSI for auto-squelch which is very handy on RF systems.)

 

[kakolon]

One very important question, are the frequencies used bny the Xbees legal in your country?

Myc

Yes they are legal

 

[kakolon]

This depends on an answer to a question I've asked in a seperate thread about arrays, but I've been thinking about two solutions. The first is complex involving 18Xs with lots of self discovery about local connections. But there is another solution that might work with 08Ms that does all the clever processing in the PC. Consider a PC and a single wireless node. The node is sitting with a serin, hanging, and waiting for a data packet. The node has a number - 0 to 255. The PC knows that there are one or more nodes out there, so cycles from 0 to 255 looking for a response. When the node gets a packet it sends back a response. The PC then sends lots of packets to that node and determines the % reliability of the connection.

Now add a second node - either in range of the PC, or out of range but in range of the first node. The PC first cycles through looking for that second node as well and if it can communicate directly it stores that data. But then it sends messages via the first node looking for nodes that first node can talk to. The packet might be UUUUABC then b0 to 13 where b13 is a U (crude checksum), b0 to b10 are the sequence of nodes the message must go through and b11 to 12 are data bytes.

The first node gets this packet (first node number in b0), and forwards it on to the number in b1 etc. The second node gets this packet and stores the sequence of nodes the packet took to get there in scratchpad ram. This is now the sequence it needs to send any packet to get it to the PC. It sends back an acknowledge, and the PC then tests this link for reliability.

Any node looking for a status change (door) must not be hanging with serin so there might need to be a smart circuit (a diode/RC network fast enough to pick a sequence of U's coming in and switch to serin to get the packet, but otherwise listening to the door. Or maybe another serin hang workaround (still thinking about this one).

Now add a third node. The PC goes through the same sequence and it will take longer and longer to discover nodes but eventually they are all discovered.

If the power goes off in a node it will lose the sequence to talk back to the PC but the PC will eventually rediscover the node and program back in the sequence.

If a node wanted to send a message to another node it would send it via the PC which is slightly less efficient than direct transfer but an awful lot simpler.

Any packet will have the sequence of nodes it needs to follow, and so any node not in the sequence will ignore the packet.

At 2400 baud a packet of 14 bytes can be received and sent on in less than 0.1 seconds so the transmit time of the network is fast.

The task for each nodes are kept very simple - either turn something on or off, or sense something when the PC asks for it, or detect a change in a status of something and send it to the PC via the path programmed in ram.

I'm pretty sure this can fit in an 08M if the path sequence can be stored in an array so that values can be checked in a for/next loop efficiently.

Brainstorming ideas greatly appreciated!

Drakula,
Thank you very much for your time, I really appreciated the help. I will be re-reading your suggestions slowly to digest them and answer properly.
Best regards,

 

[kakolon]

Rev-Ed sell them so you can order them whilst getting the PICAXE's you need, or ask a local PICAXE distributor to get them via Rev-Ed. They aren't that expensive when compared to normal 433MHz, especially that they are bi-directional and include error checking and re-transmission on failed message passing etc.

Hippy, You got me thinking about xbee's, I had search all the electronic market here some tieme ago,and there weren't any distributors that sold Xbee, now after your question, I searched again, and for my surprise, I found there are now. The price for the standard version of an Xbee is 29 Us dolars, and 48 for the Pro version. The standard version could fit my budget, but I don't know if the 30mts range will let me do the job. Do you know if xbee's can be used as a repeater to exapand coverage?.

 

[hippy]

The newer Mark II XBees will do automatic repeating and meshing. This was meant to be a firmware upgrade to the Mark I XBees but I believe that hasn't happened from what I've read. You can still do repeating with the Mark I's, same as one can with 433MHz but it needs a PICAXE. XBee Mark II repeaters, as I understand it, once configured can be used standalone. I haven't done that nor read the XBee spec of late.

 

[moxhamj]

It may well be worth getting a couple of xbee2's and do some experiments. Or even before that, have a read of their instruction manuals.

I'm still thinking about radio networks using $4 radio modules - not least of which is because I know they have a range of many hundreds of metres. There are a few problems to solve - one is getting all the code to fit and hippy has posted an answer to a question I posed on arrays which will certainly shrink the code a lot. I think this is now possible to get into an 08M.

Next problem is the serin hang. If a node is just at the limit of its range then it may get the 'ABC' header but the data may be corrupted and it could end up hanging forever, or at least until another packet arrives. But if the node is a door sensor then a hang is a real problem.

I think it is going to need another circuit to get it out of a hang. I have been designing 555 missing pulse circuits and these may provide a solution. But then the problem is that a reset will lose the list of nodes to send a message back to base. One answer is to store these in eeprom instead of ram, and eeprom would probably last forever in this scenario.

Another option is to think of a way of resetting without losing data. Here is a circuit idea for critiquing - take a 555 running as an astable with a 1 second high pulse every 60 seconds. Run the picaxe off 5V via a 100R resistor. Put a BC547 between the picaxe power supply and ground. When the 547 is energised via its base it shorts out the picaxe power supply for 1 second (the 100R limits the short circuit current) and resets the chip. Drive the 547 with the 555. But, here is the clever bit, use the picaxe to control the 555's reset input. Normally the reset pin is kept low and the 555 doesn't oscillate. But just before executing a serin, set the 555's reset pin high. Then after executing a serin, set it low again. If the serin hangs, then 1 minute later the 555 will reset the chip.

One could use another picaxe chip but a 555 is much cheaper than a picaxe.

What I need to test is whether pulling the reset pin low on a 555 discharges the capacitor and starts the cycle again. If it does not, then an alternative is to discharge the capacitor more directly - eg with a diode into a picaxe pin.

Is there another simpler/cheaper solution?

I might breadboard this just to check it works, but if it does then I think all the hard bits might be solved and I might see if I can get something working as a demonstration project.

Another challenge - all door nodes need to be transmitters and receivers (so they can get the path back to the PC) and so they may as well be repeaters as well, and this means that a node has to both monitor a door and monitor the airwaves for radio packets. But listening for radio data will cause a hang so the packet could have a long series of U's to start off and this goes into an RC filter and the value of this triggers listening for a pulse. The timing needs to be fairly precise and would need a CRO to set it and would need ? 3-4 Us to trigger listening.

So one can list off the pins - one for Rx, one for Tx, one to reset a 555, one to listen to the average RC value of the radio airwaves, one to monitor the door and maybe a diagnostic led/output pin. So it may or may not be possible with an 08M if an output pin is desired (output leds are very useful for debugging) and so the chip would probably be a 14M.

 

[Dippy]

Time for planning Drac. as long as as your Network actually gets around to sending data rather than talking to all the nodes all the time

I only got as far as 3 nodes with my setup and it worked pretty well I must confess, but then I used better modules with RSSI. It doesn't always save (time or money) to penny-pinch. A customer might bless you for saving him/her a quid and then curse you for not supplying a better quality product - on-the-cheap is the Chinese manufacturing motto.

(e.g. a small digression; all 7 of my Chinese made CFLs have conked within 12 months. ALL 6 of my German made OSram CFLs are still working after 5 years. You get what u pay 4.)

 

[hippy]

Although 555's are cheaper compared to an 08/08M, I'd argue the case that an 08/08M solution is easier to implement, adjust, more flexible and fewer components.

I'd consider the main PICAXE, a front-end PICAXE which only passes fully received messages to it, and a third PICAXE which resets the front-end if it looks like it may have hung.

That third PICAXE could be part of the master if the front-end indicates when it started receiving a message, so the master counts down a timeout and if it hits zero before getting passed a recieved message it simply resets the front-end. The front-end can clear the 'started receiving message flag' if it receives a complete message that was invalid so it isn't reset when it doesn't need to be.

In the real world, doing this commercially, one wouldn't choose a non-X1 PICAXE as they are not well suited to asynchronous data transfer and multi-tasking.