I want to hook up a number of boolean signals (pressure mat, door/window sensor, PIR, etc) wirelessly as part of my home automation. I am aware I can buy prebuilt sensors[2][3] inexpensively, but I want to drop down a level to understand the deeper concepts. Basically what I want is:
- each device has a unique (within my house) identifier
- when a device transitions low to high it sends a signal HIGH
- when a device transitions high to low it sends a signal LOW
- (optional) when the device first comes online it sends relevant signal
- most devices need their own transmitter. Some can share a transmitter between ~4 devices if necessary - these devices would still need different ids
the signal as far as the soft/firmware cares could be just [identifier][high/low]. I'm not worried about the security implications of this at this time (though feel free to detail them if you want to).
I understand that 433.92MHz and 868(.something?)MHz are favourite frequencies for this kind of thing.
So what I want to know is: what's the cheapest/simplest circuit I could make to do this sort of thing, so I could pepper these sensors all over my house? What RF transmitters/receivers are the cool kids using these days?
The Nanode Gateway[1] looks like a useful RF receiver I could use to hook these up to my LAN (and this would also allow my to hook up a few wired sensors too) though I'm (very) open to other suggestions. I notice that JeeLabs have a JeeNode[4] that is great for transmitting a few signals, but it's massively over-engineered for what I need. I don't need an Atmel processor, for instance - just unique IDs (could even be set manually via a small number of jumpers (e.g. 8 jumpers would allow 256 ids)) and some kind or RF transmitter[5] and some circuit/chip to hook 'em together.
On Monday, October 29, 2012 10:54:11 AM UTC, Benjie Gillam wrote:
> I want to hook up a number of boolean signals (pressure mat, door/window > sensor, PIR, etc) wirelessly as part of my home automation. I am aware I > can buy prebuilt sensors[2][3] inexpensively, but I want to drop down a > level to understand the deeper concepts. Basically what I want is:
> - each device has a unique (within my house) identifier
> - when a device transitions low to high it sends a signal HIGH
> - when a device transitions high to low it sends a signal LOW
> - (optional) when the device first comes online it sends relevant signal
> - most devices need their own transmitter. Some can share a transmitter > between ~4 devices if necessary - these devices would still need different > ids
> the signal as far as the soft/firmware cares could be just > [identifier][high/low]. I'm not worried about the security implications of > this at this time (though feel free to detail them if you want to).
> I understand that 433.92MHz and 868(.something?)MHz are favourite > frequencies for this kind of thing.
> So what I want to know is: what's the cheapest/simplest circuit I could > make to do this sort of thing, so I could pepper these sensors all over my > house? What RF transmitters/receivers are the cool kids using these days?
> The Nanode Gateway[1] looks like a useful RF receiver I could use to hook > these up to my LAN (and this would also allow my to hook up a few wired > sensors too) though I'm (very) open to other suggestions. I notice that > JeeLabs have a JeeNode[4] that is great for transmitting a few signals, but > it's massively over-engineered for what I need. I don't need an Atmel > processor, for instance - just unique IDs (could even be set manually via a > small number of jumpers (e.g. 8 jumpers would allow 256 ids)) and some kind > or RF transmitter[5] and some circuit/chip to hook 'em together.
I guess this would work - I could send ID/signal by holding the transmit button and pulsing the microphone. What circuit would I use to send this data though? I guess some kind of multiplexer - e.g. 8 bits would give me 7 bits for ID (128 devices) and 1 bit for signal (high/low). Probably need some kind of padding/disambiguation, plus the need to avoid RF collisions and various other things I know very little about.
I think kids walkie talkies might be a bit bulky for what I want to make, plus I'd need 10-20 of them... I was hoping more for a breadboard-able circuit I could later make into a PCB.
> On Monday, October 29, 2012 10:54:11 AM UTC, Benjie Gillam wrote:
> I want to hook up a number of boolean signals (pressure mat, door/window sensor, PIR, etc) wirelessly as part of my home automation. I am aware I can buy prebuilt sensors[2][3] inexpensively, but I want to drop down a level to understand the deeper concepts. Basically what I want is:
> - each device has a unique (within my house) identifier
> - when a device transitions low to high it sends a signal HIGH
> - when a device transitions high to low it sends a signal LOW
> - (optional) when the device first comes online it sends relevant signal
> - most devices need their own transmitter. Some can share a transmitter between ~4 devices if necessary - these devices would still need different ids
> the signal as far as the soft/firmware cares could be just [identifier][high/low]. I'm not worried about the security implications of this at this time (though feel free to detail them if you want to).
> I understand that 433.92MHz and 868(.something?)MHz are favourite frequencies for this kind of thing.
> So what I want to know is: what's the cheapest/simplest circuit I could make to do this sort of thing, so I could pepper these sensors all over my house? What RF transmitters/receivers are the cool kids using these days?
> The Nanode Gateway[1] looks like a useful RF receiver I could use to hook these up to my LAN (and this would also allow my to hook up a few wired sensors too) though I'm (very) open to other suggestions. I notice that JeeLabs have a JeeNode[4] that is great for transmitting a few signals, but it's massively over-engineered for what I need. I don't need an Atmel processor, for instance - just unique IDs (could even be set manually via a small number of jumpers (e.g. 8 jumpers would allow 256 ids)) and some kind or RF transmitter[5] and some circuit/chip to hook 'em together.
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
On 29 Oct 2012 11:18, "Bracken Dawson" <abdaw...@gmail.com> wrote:
I would look at some of the 315 or 433MHz modules, though to ensure you don't see random noise trigger state changes you would probably need to devise a simple protocol (which could also addresses your need to address the sensors) which would necessitate the use of a micro-controller.
> I want to hook up a number of boolean signals (pressure mat,
> door/window sensor, PIR, etc) wirelessly as part of my home
> automation. I am aware I can buy prebuilt sensors[2][3] > inexpensively,
> but I want to drop down a level to understand the deeper concepts.
> Basically what I want is:
> - each device has a unique (within my house) identifier
> - when a device transitions low to high it sends a signal HIGH
> - when a device transitions high to low it sends a signal LOW
> - (optional) when the device first comes online it sends relevant
> signal
> - most devices need their own transmitter. Some can share a
> transmitter between ~4 devices if necessary - these devices would
> still need different ids
> the signal as far as the soft/firmware cares could be just
> [identifier][high/low]. I'm not worried about the security
> implications of this at this time (though feel free to detail them if
> you want to).
> I understand that 433.92MHz and 868(.something?)MHz are favourite
> frequencies for this kind of thing.
> So what I want to know is: what's the cheapest/simplest circuit I
> could make to do this sort of thing, so I could pepper these sensors
> all over my house? What RF transmitters/receivers are the cool kids
> using these days?
> The Nanode Gateway[1] looks like a useful RF receiver I could use to
> hook these up to my LAN (and this would also allow my to hook up a > few
> wired sensors too) though I'm (very) open to other suggestions. I
> notice that JeeLabs have a JeeNode[4] that is great for transmitting > a
> few signals, but it's massively over-engineered for what I need. I
> don't need an Atmel processor, for instance - just unique IDs (could
> even be set manually via a small number of jumpers (e.g. 8 jumpers
> would allow 256 ids)) and some kind or RF transmitter[5] and some
> circuit/chip to hook 'em together.
This is basically what my third year project is at uni, I will be
using Arduinos/Raspberry Pis hooked up to XBee[1] modules. XBees have
the following advantages:
* up to about 100m indoor range (300m outdoor)
* each have their own address and auto associate with other XBees on
the same network id.
* contain some gpio pins which can be read and set by other XBee modules
* can communicate to devices via a serial connection
* operate on 3.3v so can be directly connected to Raspberry Pis or
3.3v Arduinos (such as the 3.3 pro mini)
* api and transparent mode (transparent mode echos what is received on
the serial ports over the wireless)
* python library (for api mode)
* arduino library (for api mode)
The downside is they cost about £20 per XBee but could be connected to
several near by sensors to lower the overall cost.
My plan was to use a Raspberry Pi + XBee as a central
controller/bridge to the physical network and then a bunch of Arduino
+ XBees to interface with the sensors and the project is mostly
focused on the messaging framework rather then the devices them
selves.
I cannot say that I looked into other wireless solutions as money
isn't really a big issue for this project (I only need a few devices
to develop on and prove it works) and my supervisor suggested the
XBees.
I would be very interested in knowing how you get along with this
project and what you decide to use for it.
FYI, I will be posting updates about how I get along on this project
on my blog[2] if you are interested (currently not much there yet :)
).
> I would look at some of the 315 or 433MHz modules, though to ensure you
> don't see random noise trigger state changes you would probably need to
> devise a simple protocol (which could also addresses your need to address
> the sensors) which would necessitate the use of a micro-controller.
>> I want to hook up a number of boolean signals (pressure mat,
>> door/window sensor, PIR, etc) wirelessly as part of my home
>> automation. I am aware I can buy prebuilt sensors[2][3] inexpensively,
>> but I want to drop down a level to understand the deeper concepts.
>> Basically what I want is:
>> - each device has a unique (within my house) identifier
>> - when a device transitions low to high it sends a signal HIGH
>> - when a device transitions high to low it sends a signal LOW
>> - (optional) when the device first comes online it sends relevant
>> signal
>> - most devices need their own transmitter. Some can share a
>> transmitter between ~4 devices if necessary - these devices would
>> still need different ids
>> the signal as far as the soft/firmware cares could be just
>> [identifier][high/low]. I'm not worried about the security
>> implications of this at this time (though feel free to detail them if
>> you want to).
>> I understand that 433.92MHz and 868(.something?)MHz are favourite
>> frequencies for this kind of thing.
>> So what I want to know is: what's the cheapest/simplest circuit I
>> could make to do this sort of thing, so I could pepper these sensors
>> all over my house? What RF transmitters/receivers are the cool kids
>> using these days?
>> The Nanode Gateway[1] looks like a useful RF receiver I could use to
>> hook these up to my LAN (and this would also allow my to hook up a few
>> wired sensors too) though I'm (very) open to other suggestions. I
>> notice that JeeLabs have a JeeNode[4] that is great for transmitting a
>> few signals, but it's massively over-engineered for what I need. I
>> don't need an Atmel processor, for instance - just unique IDs (could
>> even be set manually via a small number of jumpers (e.g. 8 jumpers
>> would allow 256 ids)) and some kind or RF transmitter[5] and some
>> circuit/chip to hook 'em together.
Michael: I think it was you I was talking to at the last SoHa meet about XBee's? They're great little chips but they're a bit overkill for my needs (and expensive!). If I want a door sensor for every door in my house (overkill, admittedly) then that's £200 before I even worry about the door sensor and the electronics between them! The off-the-shelf sensors work out at about £8-10 each, I was hoping to match or even beat this. There's a good chance I might use some XBee's for some other projects in future though.
Mark: I've been looking at some of these modules on eBay, thanks for the UK shop link - £2.75 per transmitter seems reasonable. Hooking this up to a TI MSP430 (recommended by Bracken[1], ~ £2.68) would give me a complete solution (less the sensor itself and a power supply) for little more than £5.
One of the many things I don't understand is whether any 433MHz transmitter can talk to any 433MHz receiver. From what I've seen so far there's at least 2 "modulations" (ASK/OOK - whatever these are) and presumably there's different rates and various other things. Do the receiver modules "read" the "airwaves" and just pass through the signal for me to read and decode, or do they do decoding too (e.g. detecting how long a low/high pulse is), or is something in between going on? From what I understand (at least some of) the protocols use varying lengths of high/low signal to signify zeros/ones, but this is all new territory for me! Is the Arduino/MSP430/similar fast enough to read these pulses that are in the order of a hundred nano-seconds long in order to decode them reliably? Can they still do other stuff?
> This is basically what my third year project is at uni, I will be
> using Arduinos/Raspberry Pis hooked up to XBee[1] modules. XBees have
> the following advantages:
> * up to about 100m indoor range (300m outdoor)
> * each have their own address and auto associate with other XBees on
> the same network id.
> * contain some gpio pins which can be read and set by other XBee modules
> * can communicate to devices via a serial connection
> * operate on 3.3v so can be directly connected to Raspberry Pis or
> 3.3v Arduinos (such as the 3.3 pro mini)
> * api and transparent mode (transparent mode echos what is received on
> the serial ports over the wireless)
> * python library (for api mode)
> * arduino library (for api mode)
> The downside is they cost about £20 per XBee but could be connected to
> several near by sensors to lower the overall cost.
> My plan was to use a Raspberry Pi + XBee as a central
> controller/bridge to the physical network and then a bunch of Arduino
> + XBees to interface with the sensors and the project is mostly
> focused on the messaging framework rather then the devices them
> selves.
> I cannot say that I looked into other wireless solutions as money
> isn't really a big issue for this project (I only need a few devices
> to develop on and prove it works) and my supervisor suggested the
> XBees.
> I would be very interested in knowing how you get along with this
> project and what you decide to use for it.
> FYI, I will be posting updates about how I get along on this project
> on my blog[2] if you are interested (currently not much there yet :)
> ).
> On 29 October 2012 12:12, Mark Benson <m...@sub-design.co.uk> wrote:
>> I would look at some of the 315 or 433MHz modules, though to ensure you
>> don't see random noise trigger state changes you would probably need to
>> devise a simple protocol (which could also addresses your need to address
>> the sensors) which would necessitate the use of a micro-controller.
>>> I want to hook up a number of boolean signals (pressure mat,
>>> door/window sensor, PIR, etc) wirelessly as part of my home
>>> automation. I am aware I can buy prebuilt sensors[2][3] inexpensively,
>>> but I want to drop down a level to understand the deeper concepts.
>>> Basically what I want is:
>>> - each device has a unique (within my house) identifier
>>> - when a device transitions low to high it sends a signal HIGH
>>> - when a device transitions high to low it sends a signal LOW
>>> - (optional) when the device first comes online it sends relevant
>>> signal
>>> - most devices need their own transmitter. Some can share a
>>> transmitter between ~4 devices if necessary - these devices would
>>> still need different ids
>>> the signal as far as the soft/firmware cares could be just
>>> [identifier][high/low]. I'm not worried about the security
>>> implications of this at this time (though feel free to detail them if
>>> you want to).
>>> I understand that 433.92MHz and 868(.something?)MHz are favourite
>>> frequencies for this kind of thing.
>>> So what I want to know is: what's the cheapest/simplest circuit I
>>> could make to do this sort of thing, so I could pepper these sensors
>>> all over my house? What RF transmitters/receivers are the cool kids
>>> using these days?
>>> The Nanode Gateway[1] looks like a useful RF receiver I could use to
>>> hook these up to my LAN (and this would also allow my to hook up a few
>>> wired sensors too) though I'm (very) open to other suggestions. I
>>> notice that JeeLabs have a JeeNode[4] that is great for transmitting a
>>> few signals, but it's massively over-engineered for what I need. I
>>> don't need an Atmel processor, for instance - just unique IDs (could
>>> even be set manually via a small number of jumpers (e.g. 8 jumpers
>>> would allow 256 ids)) and some kind or RF transmitter[5] and some
>>> circuit/chip to hook 'em together.
On Mon, Oct 29, 2012 at 3:03 PM, Benjie Gillam <ben...@jemjie.com> wrote:
> Thanks for your input everyone!
> Michael: I think it was you I was talking to at the last SoHa meet about
> XBee's? They're great little chips but they're a bit overkill for my needs
> (and expensive!). If I want a door sensor for every door in my house
> (overkill, admittedly) then that's £200 before I even worry about the door
> sensor and the electronics between them! The off-the-shelf sensors work out
> at about £8-10 each, I was hoping to match or even beat this. There's a good
> chance I might use some XBee's for some other projects in future though.
> Mark: I've been looking at some of these modules on eBay, thanks for the UK
> shop link - £2.75 per transmitter seems reasonable. Hooking this up to a TI
> MSP430 (recommended by Bracken[1], ~ £2.68) would give me a complete
> solution (less the sensor itself and a power supply) for little more than
> £5.
> One of the many things I don't understand is whether any 433MHz transmitter
> can talk to any 433MHz receiver. From what I've seen so far there's at least
> 2 "modulations" (ASK/OOK - whatever these are) and presumably there's
> different rates and various other things. Do the receiver modules "read" the
> "airwaves" and just pass through the signal for me to read and decode, or do
> they do decoding too (e.g. detecting how long a low/high pulse is), or is
> something in between going on? From what I understand (at least some of) the
> protocols use varying lengths of high/low signal to signify zeros/ones, but
> this is all new territory for me! Is the Arduino/MSP430/similar fast enough
> to read these pulses that are in the order of a hundred nano-seconds long in
> order to decode them reliably? Can they still do other stuff?
> On 29 Oct 2012, at 13:11, Michael James Daffin wrote:
> This is basically what my third year project is at uni, I will be
> using Arduinos/Raspberry Pis hooked up to XBee[1] modules. XBees have
> the following advantages:
> * up to about 100m indoor range (300m outdoor)
> * each have their own address and auto associate with other XBees on
> the same network id.
> * contain some gpio pins which can be read and set by other XBee modules
> * can communicate to devices via a serial connection
> * operate on 3.3v so can be directly connected to Raspberry Pis or
> 3.3v Arduinos (such as the 3.3 pro mini)
> * api and transparent mode (transparent mode echos what is received on
> the serial ports over the wireless)
> * python library (for api mode)
> * arduino library (for api mode)
> The downside is they cost about £20 per XBee but could be connected to
> several near by sensors to lower the overall cost.
> My plan was to use a Raspberry Pi + XBee as a central
> controller/bridge to the physical network and then a bunch of Arduino
> + XBees to interface with the sensors and the project is mostly
> focused on the messaging framework rather then the devices them
> selves.
> I cannot say that I looked into other wireless solutions as money
> isn't really a big issue for this project (I only need a few devices
> to develop on and prove it works) and my supervisor suggested the
> XBees.
> I would be very interested in knowing how you get along with this
> project and what you decide to use for it.
> FYI, I will be posting updates about how I get along on this project
> on my blog[2] if you are interested (currently not much there yet :)
> ).
OOK and ASK are as noted by Peter. OOK is just a special case of ASK - in theory you could encode multiple bits by having multiple amplitude levels (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep things simple, 1 bit = On/Off is typically used. There are some difficulties to surmount - it is not trivial to set up comms with this little radios... generally a preamble is used to "wake" the receiver... this is how it differentiates signal from noise... then the real data gets transmitted. Its been a long while since I investigated this (I have some of these radios for a project that didn't get started beyond the initial investigation).
I'm wondering if I could use a shift register for my needs. Feed in ID from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value (e.g. each of the bits XORed with the previous) to the inputs, and then shift these down the register obeying a simple clock (555 timer possibly?) to the transmitter chip discussed previously.
What would I need to trigger the start of the transmission (i.e. to detect the switch had gone from high to low or vice versa)? Perhaps something like a bistable hooked up to the switch to store it's state and an XOR to compare the bistable value to the switch value? (e.g. it sends a spike when the logic value of the switch is not equal to the stored value of the switch? The spike could then trigger a 555 or similar to feed power to the sending circuit for a certain amount of time (and this might prevent it triggering multiple times during the same sending period?))
I wonder if there's a chip I can hook up to do the preamble for me (or even if the radio board can do it onboard...).
Will have to read up on the data sheet for the 433MHz transmitter[1] that Mark mentioned. I want to understand more about preambles, collisions and other such complexities inherent to the RF medium - will have to do more reading!
Peter/raichea: any idea if I'd be able to use these transmitters with the Nanode's built in 433.92MHz receiver, or would I need to buy a specific receiver for them? (Or even how would I go about finding out/what properties need to match up? Presumably frequency, OOK, and perhaps data rate? Can a faster receiver pick up a slower transmitter?)
> OOK and ASK are as noted by Peter. OOK is just a special case of ASK - in theory you could encode multiple bits by having multiple amplitude levels (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep things simple, 1 bit = On/Off is typically used. There are some difficulties to surmount - it is not trivial to set up comms with this little radios... generally a preamble is used to "wake" the receiver... this is how it differentiates signal from noise... then the real data gets transmitted. Its been a long while since I investigated this (I have some of these radios for a project that didn't get started beyond the initial investigation).
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
On 30 Oct 2012 12:02, "Benjie Gillam" <ben...@jemjie.com> wrote:
> I'm wondering if I could use a shift register for my needs. Feed in ID
> from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value
> (e.g. each of the bits XORed with the previous) to the inputs, and then
> shift these down the register obeying a simple clock (555 timer possibly?)
> to the transmitter chip discussed previously.
> What would I need to trigger the start of the transmission (i.e. to detect
> the switch had gone from high to low or vice versa)? Perhaps something like
> a bistable hooked up to the switch to store it's state and an XOR to
> compare the bistable value to the switch value? (e.g. it sends a spike when
> the logic value of the switch is not equal to the stored value of the
> switch? The spike could then trigger a 555 or similar to feed power to the
> sending circuit for a certain amount of time (and this might prevent it
> triggering multiple times during the same sending period?))
> I wonder if there's a chip I can hook up to do the preamble for me (or
> even if the radio board can do it onboard...).
> Will have to read up on the data sheet for the 433MHz transmitter[1] that
> Mark mentioned. I want to understand more about preambles, collisions and
> other such complexities inherent to the RF medium - will have to do more
> reading!
> Peter/raichea: any idea if I'd be able to use these transmitters with the
> Nanode's built in 433.92MHz receiver, or would I need to buy a specific
> receiver for them? (Or even how would I go about finding out/what
> properties need to match up? Presumably frequency, OOK, and perhaps data
> rate? Can a faster receiver pick up a slower transmitter?)
> OOK and ASK are as noted by Peter. OOK is just a special case of ASK - in
> theory you could encode multiple bits by having multiple amplitude levels
> (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep
> things simple, 1 bit = On/Off is typically used. There are some
> difficulties to surmount - it is not trivial to set up comms with this
> little radios... generally a preamble is used to "wake" the receiver...
> this is how it differentiates signal from noise... then the real data gets
> transmitted. Its been a long while since I investigated this (I have some
> of these radios for a project that didn't get started beyond the initial
> investigation).
How would I add intelligence on the sending side? My aim is to make the transmissions so short that the likelihood of collisions is low, but obviously a lot of other devices use this frequency too! I only want to send 1 byte, and most transmitters seem to run at around 8Kbps (1KBps) - though I'm unsure how long the preamble must be. Most of the LightwaveRF products themselves only have transmitters or receivers (rarely both) so other than adding more data integrity or repeating the message multiple times (which is how I think LightwaveRF do it) I'm not sure what I could do - suggestions?
> No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
> On 30 Oct 2012 12:02, "Benjie Gillam" <ben...@jemjie.com> wrote:
> Thanks for your input everyone!
> I'm wondering if I could use a shift register for my needs. Feed in ID from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value (e.g. each of the bits XORed with the previous) to the inputs, and then shift these down the register obeying a simple clock (555 timer possibly?) to the transmitter chip discussed previously.
> What would I need to trigger the start of the transmission (i.e. to detect the switch had gone from high to low or vice versa)? Perhaps something like a bistable hooked up to the switch to store it's state and an XOR to compare the bistable value to the switch value? (e.g. it sends a spike when the logic value of the switch is not equal to the stored value of the switch? The spike could then trigger a 555 or similar to feed power to the sending circuit for a certain amount of time (and this might prevent it triggering multiple times during the same sending period?))
> I wonder if there's a chip I can hook up to do the preamble for me (or even if the radio board can do it onboard...).
> Will have to read up on the data sheet for the 433MHz transmitter[1] that Mark mentioned. I want to understand more about preambles, collisions and other such complexities inherent to the RF medium - will have to do more reading!
> Peter/raichea: any idea if I'd be able to use these transmitters with the Nanode's built in 433.92MHz receiver, or would I need to buy a specific receiver for them? (Or even how would I go about finding out/what properties need to match up? Presumably frequency, OOK, and perhaps data rate? Can a faster receiver pick up a slower transmitter?)
>> OOK and ASK are as noted by Peter. OOK is just a special case of ASK - in theory you could encode multiple bits by having multiple amplitude levels (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep things simple, 1 bit = On/Off is typically used. There are some difficulties to surmount - it is not trivial to set up comms with this little radios... generally a preamble is used to "wake" the receiver... this is how it differentiates signal from noise... then the real data gets transmitted. Its been a long while since I investigated this (I have some of these radios for a project that didn't get started beyond the initial investigation).
For an action it is easy, the user sees the lights aren't on and presses
the button again.
For triggers, like window is open, you either need 2way signal to get an
ACK, or you need to repeat the code a few times to increase chance of
success.
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
On 30 Oct 2012 12:18, "Benjie Gillam" <ben...@jemjie.com> wrote:
> How would I add intelligence on the sending side? My aim is to make the
> transmissions so short that the likelihood of collisions is low, but
> obviously a lot of other devices use this frequency too! I only want to
> send 1 byte, and most transmitters seem to run at around 8Kbps (1KBps) -
> though I'm unsure how long the preamble must be. Most of the LightwaveRF
> products themselves only have transmitters or receivers (rarely both) so
> other than adding more data integrity or repeating the message multiple
> times (which is how I think LightwaveRF do it) I'm not sure what I could do
> - suggestions?
> Benjie.
> On 30 Oct 2012, at 12:03, Anton Piatek wrote:
> If you don't have any intelligenc, on the sending side then interference
> or collisions mean your state data could be wrong
> No trees were destroyed in the sending of this message, however, a
> significant number of electrons were terribly inconvenienced.
> On 30 Oct 2012 12:02, "Benjie Gillam" <ben...@jemjie.com> wrote:
>> Thanks for your input everyone!
>> I'm wondering if I could use a shift register for my needs. Feed in ID
>> from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value
>> (e.g. each of the bits XORed with the previous) to the inputs, and then
>> shift these down the register obeying a simple clock (555 timer possibly?)
>> to the transmitter chip discussed previously.
>> What would I need to trigger the start of the transmission (i.e. to
>> detect the switch had gone from high to low or vice versa)? Perhaps
>> something like a bistable hooked up to the switch to store it's state and
>> an XOR to compare the bistable value to the switch value? (e.g. it sends a
>> spike when the logic value of the switch is not equal to the stored value
>> of the switch? The spike could then trigger a 555 or similar to feed power
>> to the sending circuit for a certain amount of time (and this might prevent
>> it triggering multiple times during the same sending period?))
>> I wonder if there's a chip I can hook up to do the preamble for me (or
>> even if the radio board can do it onboard...).
>> Will have to read up on the data sheet for the 433MHz transmitter[1] that
>> Mark mentioned. I want to understand more about preambles, collisions and
>> other such complexities inherent to the RF medium - will have to do more
>> reading!
>> Peter/raichea: any idea if I'd be able to use these transmitters with the
>> Nanode's built in 433.92MHz receiver, or would I need to buy a specific
>> receiver for them? (Or even how would I go about finding out/what
>> properties need to match up? Presumably frequency, OOK, and perhaps data
>> rate? Can a faster receiver pick up a slower transmitter?)
>> OOK and ASK are as noted by Peter. OOK is just a special case of ASK -
>> in theory you could encode multiple bits by having multiple amplitude
>> levels (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to
>> keep things simple, 1 bit = On/Off is typically used. There are some
>> difficulties to surmount - it is not trivial to set up comms with this
>> little radios... generally a preamble is used to "wake" the receiver...
>> this is how it differentiates signal from noise... then the real data gets
>> transmitted. Its been a long while since I investigated this (I have some
>> of these radios for a project that didn't get started beyond the initial
>> investigation).
I'm not doing it for a security system, so a few lost signals won't be too much of an issue. I suspect repeating would be easy enough to accomplish with my proposed solution - just the equivalent of adding a loop. I guess I could do that with a shift register too - set it to e.g. 1000 initially and then shift it after each complete cycle and stop when the output is 1. There's probably a simpler way of doing it, too?
Having looked through the datasheets with not much luck, I've finally found this walkthrough from SparkFun which says you can just write to the data pin like a 2400baud serial port. It mentions nothing of collisions/etc and seems to hint that they work as a pair rather than being generic transmitters/receivers. It seems the more I read, the more questions I have...
> For an action it is easy, the user sees the lights aren't on and presses the button again. > For triggers, like window is open, you either need 2way signal to get an ACK, or you need to repeat the code a few times to increase chance of success.
> No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
> On 30 Oct 2012 12:18, "Benjie Gillam" <ben...@jemjie.com> wrote:
> How would I add intelligence on the sending side? My aim is to make the transmissions so short that the likelihood of collisions is low, but obviously a lot of other devices use this frequency too! I only want to send 1 byte, and most transmitters seem to run at around 8Kbps (1KBps) - though I'm unsure how long the preamble must be. Most of the LightwaveRF products themselves only have transmitters or receivers (rarely both) so other than adding more data integrity or repeating the message multiple times (which is how I think LightwaveRF do it) I'm not sure what I could do - suggestions?
> Benjie.
> On 30 Oct 2012, at 12:03, Anton Piatek wrote:
>> If you don't have any intelligenc, on the sending side then interference or collisions mean your state data could be wrong
>> Anton >> -- >> Anton Piatek >> (sent from my phone, please excuse any typos) >> http://www.strangeparty.com
>> No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
>> On 30 Oct 2012 12:02, "Benjie Gillam" <ben...@jemjie.com> wrote:
>> Thanks for your input everyone!
>> I'm wondering if I could use a shift register for my needs. Feed in ID from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value (e.g. each of the bits XORed with the previous) to the inputs, and then shift these down the register obeying a simple clock (555 timer possibly?) to the transmitter chip discussed previously.
>> What would I need to trigger the start of the transmission (i.e. to detect the switch had gone from high to low or vice versa)? Perhaps something like a bistable hooked up to the switch to store it's state and an XOR to compare the bistable value to the switch value? (e.g. it sends a spike when the logic value of the switch is not equal to the stored value of the switch? The spike could then trigger a 555 or similar to feed power to the sending circuit for a certain amount of time (and this might prevent it triggering multiple times during the same sending period?))
>> I wonder if there's a chip I can hook up to do the preamble for me (or even if the radio board can do it onboard...).
>> Will have to read up on the data sheet for the 433MHz transmitter[1] that Mark mentioned. I want to understand more about preambles, collisions and other such complexities inherent to the RF medium - will have to do more reading!
>> Peter/raichea: any idea if I'd be able to use these transmitters with the Nanode's built in 433.92MHz receiver, or would I need to buy a specific receiver for them? (Or even how would I go about finding out/what properties need to match up? Presumably frequency, OOK, and perhaps data rate? Can a faster receiver pick up a slower transmitter?)
>>> OOK and ASK are as noted by Peter. OOK is just a special case of ASK - in theory you could encode multiple bits by having multiple amplitude levels (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep things simple, 1 bit = On/Off is typically used. There are some difficulties to surmount - it is not trivial to set up comms with this little radios... generally a preamble is used to "wake" the receiver... this is how it differentiates signal from noise... then the real data gets transmitted. Its been a long while since I investigated this (I have some of these radios for a project that didn't get started beyond the initial investigation).
Well, all you're doing is serialising/deserialising data... That's a
nice simple way to handle both parts of it. By sending a byte from
the serial port, that is making use of a shift register to clock out
each bit in turn. If you wanted to wrap it in higher level protocols
- SLIP for example - that shouldn't present too many problems
(processor capabilities depending).
I think I'd be cautious about mixing manufacturers with modules like
that - it's not a defined protocol as such so you'd be adding a
potential problem into the project. These are generally for comms
from point a to point b, usually unidirectional - but if you have
suitable handshaking you could probably bypass some of the potential
collisions.
On Tue, Oct 30, 2012 at 1:39 PM, Benjie Gillam <ben...@jemjie.com> wrote:
> I'm not doing it for a security system, so a few lost signals won't be too
> much of an issue. I suspect repeating would be easy enough to accomplish
> with my proposed solution - just the equivalent of adding a loop. I guess I
> could do that with a shift register too - set it to e.g. 1000 initially and
> then shift it after each complete cycle and stop when the output is 1.
> There's probably a simpler way of doing it, too?
> Having looked through the datasheets with not much luck, I've finally found
> this walkthrough from SparkFun which says you can just write to the data pin
> like a 2400baud serial port. It mentions nothing of collisions/etc and seems
> to hint that they work as a pair rather than being generic
> transmitters/receivers. It seems the more I read, the more questions I
> have...
> For an action it is easy, the user sees the lights aren't on and presses the
> button again.
> For triggers, like window is open, you either need 2way signal to get an
> ACK, or you need to repeat the code a few times to increase chance of
> success.
> No trees were destroyed in the sending of this message, however, a
> significant number of electrons were terribly inconvenienced.
> On 30 Oct 2012 12:18, "Benjie Gillam" <ben...@jemjie.com> wrote:
>> How would I add intelligence on the sending side? My aim is to make the
>> transmissions so short that the likelihood of collisions is low, but
>> obviously a lot of other devices use this frequency too! I only want to send
>> 1 byte, and most transmitters seem to run at around 8Kbps (1KBps) - though
>> I'm unsure how long the preamble must be. Most of the LightwaveRF products
>> themselves only have transmitters or receivers (rarely both) so other than
>> adding more data integrity or repeating the message multiple times (which is
>> how I think LightwaveRF do it) I'm not sure what I could do - suggestions?
>> Benjie.
>> On 30 Oct 2012, at 12:03, Anton Piatek wrote:
>> If you don't have any intelligenc, on the sending side then interference
>> or collisions mean your state data could be wrong
>> Anton
>> --
>> Anton Piatek
>> (sent from my phone, please excuse any typos)
>> http://www.strangeparty.com
>> No trees were destroyed in the sending of this message, however, a
>> significant number of electrons were terribly inconvenienced.
>> On 30 Oct 2012 12:02, "Benjie Gillam" <ben...@jemjie.com> wrote:
>>> Thanks for your input everyone!
>>> I'm wondering if I could use a shift register for my needs. Feed in ID
>>> from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value
>>> (e.g. each of the bits XORed with the previous) to the inputs, and then
>>> shift these down the register obeying a simple clock (555 timer possibly?)
>>> to the transmitter chip discussed previously.
>>> What would I need to trigger the start of the transmission (i.e. to
>>> detect the switch had gone from high to low or vice versa)? Perhaps
>>> something like a bistable hooked up to the switch to store it's state and an
>>> XOR to compare the bistable value to the switch value? (e.g. it sends a
>>> spike when the logic value of the switch is not equal to the stored value of
>>> the switch? The spike could then trigger a 555 or similar to feed power to
>>> the sending circuit for a certain amount of time (and this might prevent it
>>> triggering multiple times during the same sending period?))
>>> I wonder if there's a chip I can hook up to do the preamble for me (or
>>> even if the radio board can do it onboard...).
>>> Will have to read up on the data sheet for the 433MHz transmitter[1] that
>>> Mark mentioned. I want to understand more about preambles, collisions and
>>> other such complexities inherent to the RF medium - will have to do more
>>> reading!
>>> Peter/raichea: any idea if I'd be able to use these transmitters with the
>>> Nanode's built in 433.92MHz receiver, or would I need to buy a specific
>>> receiver for them? (Or even how would I go about finding out/what properties
>>> need to match up? Presumably frequency, OOK, and perhaps data rate? Can a
>>> faster receiver pick up a slower transmitter?)
>>> OOK and ASK are as noted by Peter. OOK is just a special case of ASK -
>>> in theory you could encode multiple bits by having multiple amplitude levels
>>> (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep
>>> things simple, 1 bit = On/Off is typically used. There are some difficulties
>>> to surmount - it is not trivial to set up comms with this little radios...
>>> generally a preamble is used to "wake" the receiver... this is how it
>>> differentiates signal from noise... then the real data gets transmitted. Its
>>> been a long while since I investigated this (I have some of these radios for
>>> a project that didn't get started beyond the initial investigation).
Sorry I wasn't clear - I was asking if there was a better way to loop the sending process, i.e. if I output the data from an octal shift register how would I send the same data exactly 8 times without just having 8 octal shift registers? I suggested using a second shift register as my loop construct - feed 10000000 into it initially and shift it each time the entire sending process completes - repeat the sending process if the value output by the shift register is not 1. There's probably a simpler electronic looping construct I could use though - perhaps something that does counting and stops when it reaches a certain number? The software equivalent I'm after is just "for (var i = 0; i < 8; i++)" - I don't even care about the value of i inside the loop. I'm flexible with the value "8" - I've just set it to that because it's 2^3.
Anyway though I'd still be very happy to hear an answer to the above, I think I'm going to have to use a microprocessor of some kind (much as I try and avoid it) as repeats and preambles etc. are probably much better suited to software than hardware. So I'm looking for the simplest microprocessor that would get the job done. I've very recently discovered the ATtiny2313 which has 15 IO lines (I need ~9, I think) - they're UART compatible so should output to one of these transmitters easily enough, and I'm reasonably sure it has enough processor space for such a simple program. Does anyone know of a simpler microprocessor I can easily get hold of? If not, next step for me is to figure out how to program the thing! I've heard mention of AVR programmers/AVRdude and similar, until now I've let the Arduino software handle this for me - time to dive a little deeper! :D Someone said at the last Hack Day that you can use an Arduino to program AVRs so I might do that for teh lulz.
Sorry if I'm being a pain not just doing it the simple way - I don't think solving this problem with a pair of XBees/Arduinos would be particularly challenging for me. I'm looking to push my electronics understanding - not my programming skills - and learning this stuff is great fun! :D
> Well, all you're doing is serialising/deserialising data... That's a
> nice simple way to handle both parts of it. By sending a byte from
> the serial port, that is making use of a shift register to clock out
> each bit in turn. If you wanted to wrap it in higher level protocols
> - SLIP for example - that shouldn't present too many problems
> (processor capabilities depending).
> I think I'd be cautious about mixing manufacturers with modules like
> that - it's not a defined protocol as such so you'd be adding a
> potential problem into the project. These are generally for comms
> from point a to point b, usually unidirectional - but if you have
> suitable handshaking you could probably bypass some of the potential
> collisions.
> On Tue, Oct 30, 2012 at 1:39 PM, Benjie Gillam <ben...@jemjie.com> wrote:
>> I'm not doing it for a security system, so a few lost signals won't be too
>> much of an issue. I suspect repeating would be easy enough to accomplish
>> with my proposed solution - just the equivalent of adding a loop. I guess I
>> could do that with a shift register too - set it to e.g. 1000 initially and
>> then shift it after each complete cycle and stop when the output is 1.
>> There's probably a simpler way of doing it, too?
>> Having looked through the datasheets with not much luck, I've finally found
>> this walkthrough from SparkFun which says you can just write to the data pin
>> like a 2400baud serial port. It mentions nothing of collisions/etc and seems
>> to hint that they work as a pair rather than being generic
>> transmitters/receivers. It seems the more I read, the more questions I
>> have...
>> For an action it is easy, the user sees the lights aren't on and presses the
>> button again.
>> For triggers, like window is open, you either need 2way signal to get an
>> ACK, or you need to repeat the code a few times to increase chance of
>> success.
>> Anton
>> --
>> Anton Piatek
>> (sent from my phone, please excuse any typos)
>> http://www.strangeparty.com
>> No trees were destroyed in the sending of this message, however, a
>> significant number of electrons were terribly inconvenienced.
>> On 30 Oct 2012 12:18, "Benjie Gillam" <ben...@jemjie.com> wrote:
>>> How would I add intelligence on the sending side? My aim is to make the
>>> transmissions so short that the likelihood of collisions is low, but
>>> obviously a lot of other devices use this frequency too! I only want to send
>>> 1 byte, and most transmitters seem to run at around 8Kbps (1KBps) - though
>>> I'm unsure how long the preamble must be. Most of the LightwaveRF products
>>> themselves only have transmitters or receivers (rarely both) so other than
>>> adding more data integrity or repeating the message multiple times (which is
>>> how I think LightwaveRF do it) I'm not sure what I could do - suggestions?
>>> Benjie.
>>> On 30 Oct 2012, at 12:03, Anton Piatek wrote:
>>> If you don't have any intelligenc, on the sending side then interference
>>> or collisions mean your state data could be wrong
>>> Anton
>>> --
>>> Anton Piatek
>>> (sent from my phone, please excuse any typos)
>>> http://www.strangeparty.com
>>> No trees were destroyed in the sending of this message, however, a
>>> significant number of electrons were terribly inconvenienced.
>>> On 30 Oct 2012 12:02, "Benjie Gillam" <ben...@jemjie.com> wrote:
>>>> Thanks for your input everyone!
>>>> I'm wondering if I could use a shift register for my needs. Feed in ID
>>>> from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value
>>>> (e.g. each of the bits XORed with the previous) to the inputs, and then
>>>> shift these down the register obeying a simple clock (555 timer possibly?)
>>>> to the transmitter chip discussed previously.
>>>> What would I need to trigger the start of the transmission (i.e. to
>>>> detect the switch had gone from high to low or vice versa)? Perhaps
>>>> something like a bistable hooked up to the switch to store it's state and an
>>>> XOR to compare the bistable value to the switch value? (e.g. it sends a
>>>> spike when the logic value of the switch is not equal to the stored value of
>>>> the switch? The spike could then trigger a 555 or similar to feed power to
>>>> the sending circuit for a certain amount of time (and this might prevent it
>>>> triggering multiple times during the same sending period?))
>>>> I wonder if there's a chip I can hook up to do the preamble for me (or
>>>> even if the radio board can do it onboard...).
>>>> Will have to read up on the data sheet for the 433MHz transmitter[1] that
>>>> Mark mentioned. I want to understand more about preambles, collisions and
>>>> other such complexities inherent to the RF medium - will have to do more
>>>> reading!
>>>> Peter/raichea: any idea if I'd be able to use these transmitters with the
>>>> Nanode's built in 433.92MHz receiver, or would I need to buy a specific
>>>> receiver for them? (Or even how would I go about finding out/what properties
>>>> need to match up? Presumably frequency, OOK, and perhaps data rate? Can a
>>>> faster receiver pick up a slower transmitter?)
>>>> OOK and ASK are as noted by Peter. OOK is just a special case of ASK -
>>>> in theory you could encode multiple bits by having multiple amplitude levels
>>>> (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep
>>>> things simple, 1 bit = On/Off is typically used. There are some difficulties
>>>> to surmount - it is not trivial to set up comms with this little radios...
>>>> generally a preamble is used to "wake" the receiver... this is how it
>>>> differentiates signal from noise... then the real data gets transmitted. Its
>>>> been a long while since I investigated this (I have some of these radios for
>>>> a project that didn't get started beyond the initial investigation).
When you have a hammer, everything looks like a nail.
Are you saying you want to build this out of eg 74 series logic chips
then? A parallel-in, serial-out, 8-bit shift register is bound to
exist somewhere in that series; might be better to daisy chain a
couple for the start/stop/parity bits & hardwire the starting
sequence. You'd need a suitable clock generator to clock the data at
4k8baud, a counter to trigger a reset, another to end the sequence...
All doable, but the uc is a more compact, cheaper (for the sort of uc
needed for this) and more flexible solution.
On Tue, Oct 30, 2012 at 4:01 PM, Benjie Gillam <ben...@jemjie.com> wrote:
> Sorry I wasn't clear - I was asking if there was a better way to loop the sending process, i.e. if I output the data from an octal shift register how would I send the same data exactly 8 times without just having 8 octal shift registers? I suggested using a second shift register as my loop construct - feed 10000000 into it initially and shift it each time the entire sending process completes - repeat the sending process if the value output by the shift register is not 1. There's probably a simpler electronic looping construct I could use though - perhaps something that does counting and stops when it reaches a certain number? The software equivalent I'm after is just "for (var i = 0; i < 8; i++)" - I don't even care about the value of i inside the loop. I'm flexible with the value "8" - I've just set it to that because it's 2^3.
> Anyway though I'd still be very happy to hear an answer to the above, I think I'm going to have to use a microprocessor of some kind (much as I try and avoid it) as repeats and preambles etc. are probably much better suited to software than hardware. So I'm looking for the simplest microprocessor that would get the job done. I've very recently discovered the ATtiny2313 which has 15 IO lines (I need ~9, I think) - they're UART compatible so should output to one of these transmitters easily enough, and I'm reasonably sure it has enough processor space for such a simple program. Does anyone know of a simpler microprocessor I can easily get hold of? If not, next step for me is to figure out how to program the thing! I've heard mention of AVR programmers/AVRdude and similar, until now I've let the Arduino software handle this for me - time to dive a little deeper! :D Someone said at the last Hack Day that you can use an Arduino to program AVRs so I might do that for teh lulz.
> Sorry if I'm being a pain not just doing it the simple way - I don't think solving this problem with a pair of XBees/Arduinos would be particularly challenging for me. I'm looking to push my electronics understanding - not my programming skills - and learning this stuff is great fun! :D
> Benjie.
> On 30 Oct 2012, at 14:54, Peter Bond wrote:
>> Well, all you're doing is serialising/deserialising data... That's a
>> nice simple way to handle both parts of it. By sending a byte from
>> the serial port, that is making use of a shift register to clock out
>> each bit in turn. If you wanted to wrap it in higher level protocols
>> - SLIP for example - that shouldn't present too many problems
>> (processor capabilities depending).
>> I think I'd be cautious about mixing manufacturers with modules like
>> that - it's not a defined protocol as such so you'd be adding a
>> potential problem into the project. These are generally for comms
>> from point a to point b, usually unidirectional - but if you have
>> suitable handshaking you could probably bypass some of the potential
>> collisions.
>> On Tue, Oct 30, 2012 at 1:39 PM, Benjie Gillam <ben...@jemjie.com> wrote:
>>> I'm not doing it for a security system, so a few lost signals won't be too
>>> much of an issue. I suspect repeating would be easy enough to accomplish
>>> with my proposed solution - just the equivalent of adding a loop. I guess I
>>> could do that with a shift register too - set it to e.g. 1000 initially and
>>> then shift it after each complete cycle and stop when the output is 1.
>>> There's probably a simpler way of doing it, too?
>>> Having looked through the datasheets with not much luck, I've finally found
>>> this walkthrough from SparkFun which says you can just write to the data pin
>>> like a 2400baud serial port. It mentions nothing of collisions/etc and seems
>>> to hint that they work as a pair rather than being generic
>>> transmitters/receivers. It seems the more I read, the more questions I
>>> have...
>>> For an action it is easy, the user sees the lights aren't on and presses the
>>> button again.
>>> For triggers, like window is open, you either need 2way signal to get an
>>> ACK, or you need to repeat the code a few times to increase chance of
>>> success.
>>> Anton
>>> --
>>> Anton Piatek
>>> (sent from my phone, please excuse any typos)
>>> http://www.strangeparty.com
>>> No trees were destroyed in the sending of this message, however, a
>>> significant number of electrons were terribly inconvenienced.
>>> On 30 Oct 2012 12:18, "Benjie Gillam" <ben...@jemjie.com> wrote:
>>>> How would I add intelligence on the sending side? My aim is to make the
>>>> transmissions so short that the likelihood of collisions is low, but
>>>> obviously a lot of other devices use this frequency too! I only want to send
>>>> 1 byte, and most transmitters seem to run at around 8Kbps (1KBps) - though
>>>> I'm unsure how long the preamble must be. Most of the LightwaveRF products
>>>> themselves only have transmitters or receivers (rarely both) so other than
>>>> adding more data integrity or repeating the message multiple times (which is
>>>> how I think LightwaveRF do it) I'm not sure what I could do - suggestions?
>>>> Benjie.
>>>> On 30 Oct 2012, at 12:03, Anton Piatek wrote:
>>>> If you don't have any intelligenc, on the sending side then interference
>>>> or collisions mean your state data could be wrong
>>>> Anton
>>>> --
>>>> Anton Piatek
>>>> (sent from my phone, please excuse any typos)
>>>> http://www.strangeparty.com
>>>> No trees were destroyed in the sending of this message, however, a
>>>> significant number of electrons were terribly inconvenienced.
>>>> On 30 Oct 2012 12:02, "Benjie Gillam" <ben...@jemjie.com> wrote:
>>>>> Thanks for your input everyone!
>>>>> I'm wondering if I could use a shift register for my needs. Feed in ID
>>>>> from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value
>>>>> (e.g. each of the bits XORed with the previous) to the inputs, and then
>>>>> shift these down the register obeying a simple clock (555 timer possibly?)
>>>>> to the transmitter chip discussed previously.
>>>>> What would I need to trigger the start of the transmission (i.e. to
>>>>> detect the switch had gone from high to low or vice versa)? Perhaps
>>>>> something like a bistable hooked up to the switch to store it's state and an
>>>>> XOR to compare the bistable value to the switch value? (e.g. it sends a
>>>>> spike when the logic value of the switch is not equal to the stored value of
>>>>> the switch? The spike could then trigger a 555 or similar to feed power to
>>>>> the sending circuit for a certain amount of time (and this might prevent it
>>>>> triggering multiple times during the same sending period?))
>>>>> I wonder if there's a chip I can hook up to do the preamble for me (or
>>>>> even if the radio board can do it onboard...).
>>>>> Will have to read up on the data sheet for the 433MHz transmitter[1] that
>>>>> Mark mentioned. I want to understand more about preambles, collisions and
>>>>> other such complexities inherent to the RF medium - will have to do more
>>>>> reading!
>>>>> Peter/raichea: any idea if I'd be able to use these transmitters with the
>>>>> Nanode's built in 433.92MHz receiver, or would I need to buy a specific
>>>>> receiver for them? (Or even how would I go about finding out/what properties
>>>>> need to match up? Presumably frequency, OOK, and perhaps data rate? Can a
>>>>> faster receiver pick up a slower transmitter?)
>>>>> OOK and ASK are as noted by Peter. OOK is just a special case of ASK -
>>>>> in theory you could encode multiple bits by having multiple amplitude levels
>>>>> (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep
>>>>> things simple, 1 bit = On/Off is typically used. There are some difficulties
>>>>> to surmount - it is not trivial to set up comms with this little radios...
>>>>> generally a preamble is used to "wake" the receiver... this is how it
>>>>> differentiates signal from noise... then the real data gets transmitted. Its
>>>>> been a long while since I investigated this (I have some of these radios for
>>>>> a project that didn't get started beyond the initial investigation).
Holtek make encoder/decoder chips specially for this type of radio transmission... see HT12E/HT12D and related. I got a couple of these for the project I mentioned earlier. Futurlec are a cheap source I've used several times (for other components) in the past: http://www.futurlec.com/ICSFOthers.shtml
> When you have a hammer, everything looks like a nail.
> Are you saying you want to build this out of eg 74 series logic chips
> then? A parallel-in, serial-out, 8-bit shift register is bound to
> exist somewhere in that series; might be better to daisy chain a
> couple for the start/stop/parity bits & hardwire the starting
> sequence. You'd need a suitable clock generator to clock the data at
> 4k8baud, a counter to trigger a reset, another to end the sequence...
> All doable, but the uc is a more compact, cheaper (for the sort of uc
> needed for this) and more flexible solution.
> On Tue, Oct 30, 2012 at 4:01 PM, Benjie Gillam <ben...@jemjie.com> wrote:
>> Sorry I wasn't clear - I was asking if there was a better way to loop the sending process, i.e. if I output the data from an octal shift register how would I send the same data exactly 8 times without just having 8 octal shift registers? I suggested using a second shift register as my loop construct - feed 10000000 into it initially and shift it each time the entire sending process completes - repeat the sending process if the value output by the shift register is not 1. There's probably a simpler electronic looping construct I could use though - perhaps something that does counting and stops when it reaches a certain number? The software equivalent I'm after is just "for (var i = 0; i < 8; i++)" - I don't even care about the value of i inside the loop. I'm flexible with the value "8" - I've just set it to that because it's 2^3.
>> Anyway though I'd still be very happy to hear an answer to the above, I think I'm going to have to use a microprocessor of some kind (much as I try and avoid it) as repeats and preambles etc. are probably much better suited to software than hardware. So I'm looking for the simplest microprocessor that would get the job done. I've very recently discovered the ATtiny2313 which has 15 IO lines (I need ~9, I think) - they're UART compatible so should output to one of these transmitters easily enough, and I'm reasonably sure it has enough processor space for such a simple program. Does anyone know of a simpler microprocessor I can easily get hold of? If not, next step for me is to figure out how to program the thing! I've heard mention of AVR programmers/AVRdude and similar, until now I've let the Arduino software handle this for me - time to dive a little deeper! :D Someone said at the last Hack Day that you can use an Arduino to program AVRs so I might do that for teh lulz.
>> Sorry if I'm being a pain not just doing it the simple way - I don't think solving this problem with a pair of XBees/Arduinos would be particularly challenging for me. I'm looking to push my electronics understanding - not my programming skills - and learning this stuff is great fun! :D
>> Benjie.
>> On 30 Oct 2012, at 14:54, Peter Bond wrote:
>>> Well, all you're doing is serialising/deserialising data... That's a
>>> nice simple way to handle both parts of it. By sending a byte from
>>> the serial port, that is making use of a shift register to clock out
>>> each bit in turn. If you wanted to wrap it in higher level protocols
>>> - SLIP for example - that shouldn't present too many problems
>>> (processor capabilities depending).
>>> I think I'd be cautious about mixing manufacturers with modules like
>>> that - it's not a defined protocol as such so you'd be adding a
>>> potential problem into the project. These are generally for comms
>>> from point a to point b, usually unidirectional - but if you have
>>> suitable handshaking you could probably bypass some of the potential
>>> collisions.
>>> On Tue, Oct 30, 2012 at 1:39 PM, Benjie Gillam <ben...@jemjie.com> wrote:
>>>> I'm not doing it for a security system, so a few lost signals won't be too
>>>> much of an issue. I suspect repeating would be easy enough to accomplish
>>>> with my proposed solution - just the equivalent of adding a loop. I guess I
>>>> could do that with a shift register too - set it to e.g. 1000 initially and
>>>> then shift it after each complete cycle and stop when the output is 1.
>>>> There's probably a simpler way of doing it, too?
>>>> Having looked through the datasheets with not much luck, I've finally found
>>>> this walkthrough from SparkFun which says you can just write to the data pin
>>>> like a 2400baud serial port. It mentions nothing of collisions/etc and seems
>>>> to hint that they work as a pair rather than being generic
>>>> transmitters/receivers. It seems the more I read, the more questions I
>>>> have...
>>>> On 30 Oct 2012, at 12:35, Anton Piatek wrote:
>>>> For an action it is easy, the user sees the lights aren't on and presses the
>>>> button again.
>>>> For triggers, like window is open, you either need 2way signal to get an
>>>> ACK, or you need to repeat the code a few times to increase chance of
>>>> success.
>>>> Anton
>>>> --
>>>> Anton Piatek
>>>> (sent from my phone, please excuse any typos)
>>>> http://www.strangeparty.com
>>>> No trees were destroyed in the sending of this message, however, a
>>>> significant number of electrons were terribly inconvenienced.
>>>> On 30 Oct 2012 12:18, "Benjie Gillam" <ben...@jemjie.com> wrote:
>>>>> How would I add intelligence on the sending side? My aim is to make the
>>>>> transmissions so short that the likelihood of collisions is low, but
>>>>> obviously a lot of other devices use this frequency too! I only want to send
>>>>> 1 byte, and most transmitters seem to run at around 8Kbps (1KBps) - though
>>>>> I'm unsure how long the preamble must be. Most of the LightwaveRF products
>>>>> themselves only have transmitters or receivers (rarely both) so other than
>>>>> adding more data integrity or repeating the message multiple times (which is
>>>>> how I think LightwaveRF do it) I'm not sure what I could do - suggestions?
>>>>> Benjie.
>>>>> On 30 Oct 2012, at 12:03, Anton Piatek wrote:
>>>>> If you don't have any intelligenc, on the sending side then interference
>>>>> or collisions mean your state data could be wrong
>>>>> Anton
>>>>> --
>>>>> Anton Piatek
>>>>> (sent from my phone, please excuse any typos)
>>>>> http://www.strangeparty.com
>>>>> No trees were destroyed in the sending of this message, however, a
>>>>> significant number of electrons were terribly inconvenienced.
>>>>> On 30 Oct 2012 12:02, "Benjie Gillam" <ben...@jemjie.com> wrote:
>>>>>> Thanks for your input everyone!
>>>>>> I'm wondering if I could use a shift register for my needs. Feed in ID
>>>>>> from jumpers (high/low, 6 bits), switch state (high or low) and a CRC value
>>>>>> (e.g. each of the bits XORed with the previous) to the inputs, and then
>>>>>> shift these down the register obeying a simple clock (555 timer possibly?)
>>>>>> to the transmitter chip discussed previously.
>>>>>> What would I need to trigger the start of the transmission (i.e. to
>>>>>> detect the switch had gone from high to low or vice versa)? Perhaps
>>>>>> something like a bistable hooked up to the switch to store it's state and an
>>>>>> XOR to compare the bistable value to the switch value? (e.g. it sends a
>>>>>> spike when the logic value of the switch is not equal to the stored value of
>>>>>> the switch? The spike could then trigger a 555 or similar to feed power to
>>>>>> the sending circuit for a certain amount of time (and this might prevent it
>>>>>> triggering multiple times during the same sending period?))
>>>>>> I wonder if there's a chip I can hook up to do the preamble for me (or
>>>>>> even if the radio board can do it onboard...).
>>>>>> Will have to read up on the data sheet for the 433MHz transmitter[1] that
>>>>>> Mark mentioned. I want to understand more about preambles, collisions and
>>>>>> other such complexities inherent to the RF medium - will have to do more
>>>>>> reading!
>>>>>> Peter/raichea: any idea if I'd be able to use these transmitters with the
>>>>>> Nanode's built in 433.92MHz receiver, or would I need to buy a specific
>>>>>> receiver for them? (Or even how would I go about finding out/what properties
>>>>>> need to match up? Presumably frequency, OOK, and perhaps data rate? Can a
>>>>>> faster receiver pick up a slower transmitter?)
>>>>>> OOK and ASK are as noted by Peter. OOK is just a special case of ASK -
>>>>>> in theory you could encode multiple bits by having multiple amplitude levels
>>>>>> (4 levels = 2 bits, 8 levels = 3 bits etc) but, in practice, and to keep
>>>>>> things simple, 1 bit = On/Off is typically used. There are some difficulties
>>>>>> to surmount - it is not trivial to set up comms with this little radios...
>>>>>> generally a preamble is used to "wake" the receiver... this is how it
>>>>>> differentiates signal from noise... then the real data gets transmitted. Its
>>>>>> been a long while since I investigated this (I have some of these radios for
>>>>>> a project that didn't get started beyond the initial investigation).
>>>>>> IIRC, I found Microchip TB045 application note quite useful for some
Thanks for this, these look like they'd fit the problem perfectly - 8 bits for address (can be set via jumpers to ground) and 4 bits for data (4 sensors per device). You set TE (transmission enable) low to start the transmission, and whilst you hold it low the transmission repeats - so I could presumably just use a capacitor timing circuit to repeat for a certain amount of time (I can't remember how to make one of these, but it should be easy enough to Google!).
There's quite a lot of the datasheet[1] I don't yet understand, but one thing sticks out - how would I set the frequency for the output to be e.g. 2400/4800baud? I presume it's to do with OSC1/2 the oscillator pins - it looks like you put a specific resistor between them to set the frequency but I'm not sure what frequency I'm aiming for here - presumably something larger than 2.4kHz since it's a carrier wave? [2]
(I'm still planning on using a microprocessor, but I'd like to understand this low level stuff nonetheless.)
Cheers,
Benjie.
[1]: http://www.futurlec.com/Others/HT12E.shtml [2]: They mention that for IR you want a 38kHz carrier (wikipedia suggests 36kHz[3]) but then they say the IR version has got a 455kHz "resonator oscillator input" whatever that means. Page 11 looks like it should be helpful, but not knowing what frequency I want kinda negates it... Also: it's suggesting the decoder frequency should be 1/3 that of the encoder? *confused*
[3]: http://en.wikipedia.org/wiki/Remote_control#Consumer_electronics_infr...
> Holtek make encoder/decoder chips specially for this type of radio transmission... see HT12E/HT12D and related. I got a couple of these for the project I mentioned earlier. Futurlec are a cheap source I've used several times (for other components) in the past: http://www.futurlec.com/ICSFOthers.shtml
> This is basically what my third year project is at uni, I will be
> using Arduinos/Raspberry Pis hooked up to XBee[1] modules. XBees have
> the following advantages:
> * up to about 100m indoor range (300m outdoor)
> * each have their own address and auto associate with other XBees on
> the same network id.
> * contain some gpio pins which can be read and set by other XBee modules
> * can communicate to devices via a serial connection
> * operate on 3.3v so can be directly connected to Raspberry Pis or
> 3.3v Arduinos (such as the 3.3 pro mini)
> * api and transparent mode (transparent mode echos what is received on
> the serial ports over the wireless)
> * python library (for api mode)
> * arduino library (for api mode)
> The downside is they cost about £20 per XBee but could be connected to
> several near by sensors to lower the overall cost.
> My plan was to use a Raspberry Pi + XBee as a central
> controller/bridge to the physical network and then a bunch of Arduino
> + XBees to interface with the sensors and the project is mostly
> focused on the messaging framework rather then the devices them
> selves.
> I cannot say that I looked into other wireless solutions as money
> isn't really a big issue for this project (I only need a few devices
> to develop on and prove it works) and my supervisor suggested the
> XBees.
> I would be very interested in knowing how you get along with this
> project and what you decide to use for it.
> FYI, I will be posting updates about how I get along on this project
> on my blog[2] if you are interested (currently not much there yet :)
> ).
> On 29 October 2012 12:12, Mark Benson <m...@sub-design.co.uk> wrote:
> > I would look at some of the 315 or 433MHz modules, though to ensure you
> > don't see random noise trigger state changes you would probably need to
> > devise a simple protocol (which could also addresses your need to address
> > the sensors) which would necessitate the use of a micro-controller.
> >> I want to hook up a number of boolean signals (pressure mat,
> >> door/window sensor, PIR, etc) wirelessly as part of my home
> >> automation. I am aware I can buy prebuilt sensors[2][3] inexpensively,
> >> but I want to drop down a level to understand the deeper concepts.
> >> Basically what I want is:
> >> - each device has a unique (within my house) identifier
> >> - when a device transitions low to high it sends a signal HIGH
> >> - when a device transitions high to low it sends a signal LOW
> >> - (optional) when the device first comes online it sends relevant
> >> signal
> >> - most devices need their own transmitter. Some can share a
> >> transmitter between ~4 devices if necessary - these devices would
> >> still need different ids
> >> the signal as far as the soft/firmware cares could be just
> >> [identifier][high/low]. I'm not worried about the security
> >> implications of this at this time (though feel free to detail them if
> >> you want to).
> >> I understand that 433.92MHz and 868(.something?)MHz are favourite
> >> frequencies for this kind of thing.
> >> So what I want to know is: what's the cheapest/simplest circuit I
> >> could make to do this sort of thing, so I could pepper these sensors
> >> all over my house? What RF transmitters/receivers are the cool kids
> >> using these days?
> >> The Nanode Gateway[1] looks like a useful RF receiver I could use to
> >> hook these up to my LAN (and this would also allow my to hook up a few
> >> wired sensors too) though I'm (very) open to other suggestions. I
> >> notice that JeeLabs have a JeeNode[4] that is great for transmitting a
> >> few signals, but it's massively over-engineered for what I need. I
> >> don't need an Atmel processor, for instance - just unique IDs (could
> >> even be set manually via a small number of jumpers (e.g. 8 jumpers
> >> would allow 256 ids)) and some kind or RF transmitter[5] and some
> >> circuit/chip to hook 'em together.
On Wednesday, 31 October 2012 12:46:52 UTC, Benjie Gillam wrote:
> There's quite a lot of the datasheet[1] I don't yet understand, but one > thing sticks out - how would I set the frequency for the output to be e.g. > 2400/4800baud? I presume it's to do with OSC1/2 the oscillator pins - it > looks like you put a specific resistor between them to set the frequency > but I'm not sure what frequency I'm aiming for here - presumably something > larger than 2.4kHz since it's a carrier wave? [2]
You don't set the timing.. the chip does... you just set the oscillator frequency as per the p11 chart. You are not setting the carrier - that's done by the radio - you're just sending bits to the radio - p7 shows you that a '1' is high for 1 clock, low for 2, while a '0' is high for 2 clocks, low for 1. Each bit of data is therefore 3 oscillator clocks in length so a 3kHz clock will give you a 1 kbps datastream. The highs and lows in the data stream switch the radio on and off, so the receiver gets bursts of radio signal with the same characteristics - carrier on for two clocks, off for one clock or on for one clock, off for two clocks - the receiver turns that back into a datastream the HT12D can decode.
<http://www.futurlec.com/Others/HT12E.shtml> [2]: They mention that for IR you want a 38kHz carrier (wikipedia suggests 36kHz[3]) but then they say the IR version has got a 455kHz "resonator oscillator input" whatever that means. Page 11 looks like it should be helpful, but not knowing what frequency I want kinda negates it... Also: it's suggesting the decoder frequency should be 1/3 that of the encoder? *confused*
38kHz is widely quoted, but the IR carrier varies between 36-40kHz or so, depending on specific device vendors. The HT12A chip uses a 455kHz resonator (a cheaper but less stable oscillator source than a crystal) to generate internal timings within the HT12A (to generate the 38kHz IR carrier and the data clock). Basically ignore the HT12A - it's intended for IR links. The decoder frequency information is basically saying that if you use an HT12E, the decoder clock needs to be 50*3kHz (or whatever you set fosc to) = 150kHz, and for the HT12A 455kHz/3 ie approx 150kHz - take a look at p7 of the HT12D datasheet.
