sensor add-ons
167 views
Skip to first unread message
joe saavedra
Apr 12, 2012, 1:09:58 PM4/12/12
to airqua...@googlegroups.com
hi all -
wanted to give some info on how the sensor add-ons will work. the sensor shield (which will contain all circuitry for all models of the sensor box -- wired, wireless, shield alone) will have several JST connectors all connected to the same I2C bus.
each sensor will have it's own custom breakout board with it's unique circuit and a small microcontroller to do the sensor reading and then send out I2C.
user will just need to connect whichever sensor add-on they've purchased to the shield in the sensor box, and the egg will know exactly what's connected and push data accordingly.
hope that makes sense, let us know if you have any questions! In case you didn't see before, we have a github repo with code and schematics -- alll of it is still in development, and there are many updates that need to be added, but you can at least follow along! https://github.com/jmsaavedra/Air-Quality-Egg
thanks all, for your participation and support!!
joe
Luis Fraguada
Apr 12, 2012, 3:54:48 PM4/12/12
to airqua...@googlegroups.com
Can the sensor box accept ALL addons at once? What are the limits?
Joseph Saavedra
Apr 12, 2012, 3:56:56 PM4/12/12
to airqua...@googlegroups.com
Indeed, we are designing it to accept any, all, or no addons.
Luis Fraguada
Apr 12, 2012, 3:58:51 PM4/12/12
to airqua...@googlegroups.com
Then I am assuming each of these 'breakout' boards will have their I2C address encoded?
Joseph Saavedra
Apr 12, 2012, 4:01:17 PM4/12/12
to airqua...@googlegroups.com
precisely. Nanode app will check all addresses to see who is attached and upload data accordingly! A very small ATTiny will be on each add-on breakout.
Victor Aprea
Apr 12, 2012, 4:15:42 PM4/12/12
to airqua...@googlegroups.com
Luis,
My current thinking on this is that we will conventionally bind sensor types to I2C addresses. In doing so, the Nanode will be able to poll the known addresses to determine presence and types available in a given configuration.
The limits are TBD at this time but I think the sensor shield being connectorized to accept up to eight add on sensor modules would be a good goal. I2C allows for up to 128 addresses so that is the fundamental limit of the current design concept.
Thoughts?
Cheers,
Vic
Luis Fraguada
Apr 12, 2012, 5:34:27 PM4/12/12
to airqua...@googlegroups.com
Its all sounding really interesting!
I guess some questions which arise would be timing wise and the local logic on each of those breakout boards. Makes me start to think of seeedstudio's grove kits or other attempts at providing 'convenient' plug and play functionality. What I think is different in this case is the objective with such a kit as the AQE. I could also see the potential for proto-blanks for people who want to test other sensors. How will these be encoded? Will there be access to define your own I2C addresses? What happens in the event of conflicts?
Other things that come to my mind which relate to timing is the packet size this thing would send with all sensors going. I suppose bandwidth would need to be tweaked for larger packets in order to ensure their proper delivery to the base egg?
A lot of it seems to point at clever logic to be able to throttle wireless bandwidth depending on transmission success, packet size, etc...
I guess some questions which arise would be timing wise and the local logic on each of those breakout boards. Makes me start to think of seeedstudio's grove kits or other attempts at providing 'convenient' plug and play functionality. What I think is different in this case is the objective with such a kit as the AQE. I could also see the potential for proto-blanks for people who want to test other sensors. How will these be encoded? Will there be access to define your own I2C addresses? What happens in the event of conflicts?
Other things that come to my mind which relate to timing is the packet size this thing would send with all sensors going. I suppose bandwidth would need to be tweaked for larger packets in order to ensure their proper delivery to the base egg?
A lot of it seems to point at clever logic to be able to throttle wireless bandwidth depending on transmission success, packet size, etc...
Victor Aprea
Apr 12, 2012, 6:10:56 PM4/12/12
to airqua...@googlegroups.com
Luis,
Yea Grove Kits are kind of similar, but we are addressing a more constrained problem space so that helps a lot. If we control the definition of the address space then we don't need to worry about address conflicts, and like I said I think we'll have no shortage of addresses with 128 to choose from. People who want to prototype new / undefined sensors are welcome to do so, but the AQE will only be looking for a constrained set of addresses. Maybe what we do is allocate a set of addresses as "experimental" addresses that the AQE reports on without specificity of the sensor type. We'll publish the specification and example source code of how a device can a sensor module interface controller should work. I'm thinking something simple like it only supports read requests and always returns a 16-bit value representing its sensor reading. There's obviously some work to do to define and implement this new interface, but the I think the concept is sound and not overly complicated.
An artifact of "taking over" the I2C bus as the "AQE sensor bus" (I just made that up) is obviously that you can't go and arbitrarily add I2C devices to the bus, but we are well into the realm of hacking there and you need to know what you're doing at that point anyway. We can certainly try to be smart about addresses that we take over to avoid conflict with commonly used I2C devices, but we will almost certainly be (knowingly) in conflict with existing I2C devices (that are not used in the AQE system of course!). I think I'm OK with that :-).
You kind of jumped topical boundaries into wireless next. The JeeLabs RFM12 library supports packet sizes of up to 54 bytes (66 including packet overhead) I think, which is where my notion of supporting up to eight add on sensors came from (i.e. 12 sensors total per wireless unit). Over the air, the packet structure I'm thinking will be something like (again TBD): Node Identifier (6-bytes) followed by 12 sensor structures (Sensor Address 1-byte, Sensor Value 2-bytes) = 6 + 12 * 3 = 42 bytes. The RFM12 is a transceiver so acknowledgments are possible, and some rudimentary carrier sense capability is also possible (from what I read). In the worst case, a packet takes about 12ms to be transmitted (again from what I've read). Considering that, I think we could probably just always transmit the same size packet to keep the transmitting and receiving code simple as possible. The whole wireless topic is much more complicated and needs to be fleshed out more, but I think thtat forms a reasonable going in concept that we can build on.
Cheers,
Vic--
Yea Grove Kits are kind of similar, but we are addressing a more constrained problem space so that helps a lot. If we control the definition of the address space then we don't need to worry about address conflicts, and like I said I think we'll have no shortage of addresses with 128 to choose from. People who want to prototype new / undefined sensors are welcome to do so, but the AQE will only be looking for a constrained set of addresses. Maybe what we do is allocate a set of addresses as "experimental" addresses that the AQE reports on without specificity of the sensor type. We'll publish the specification and example source code of how a device can a sensor module interface controller should work. I'm thinking something simple like it only supports read requests and always returns a 16-bit value representing its sensor reading. There's obviously some work to do to define and implement this new interface, but the I think the concept is sound and not overly complicated.
An artifact of "taking over" the I2C bus as the "AQE sensor bus" (I just made that up) is obviously that you can't go and arbitrarily add I2C devices to the bus, but we are well into the realm of hacking there and you need to know what you're doing at that point anyway. We can certainly try to be smart about addresses that we take over to avoid conflict with commonly used I2C devices, but we will almost certainly be (knowingly) in conflict with existing I2C devices (that are not used in the AQE system of course!). I think I'm OK with that :-).
You kind of jumped topical boundaries into wireless next. The JeeLabs RFM12 library supports packet sizes of up to 54 bytes (66 including packet overhead) I think, which is where my notion of supporting up to eight add on sensors came from (i.e. 12 sensors total per wireless unit). Over the air, the packet structure I'm thinking will be something like (again TBD): Node Identifier (6-bytes) followed by 12 sensor structures (Sensor Address 1-byte, Sensor Value 2-bytes) = 6 + 12 * 3 = 42 bytes. The RFM12 is a transceiver so acknowledgments are possible, and some rudimentary carrier sense capability is also possible (from what I read). In the worst case, a packet takes about 12ms to be transmitted (again from what I've read). Considering that, I think we could probably just always transmit the same size packet to keep the transmitting and receiving code simple as possible. The whole wireless topic is much more complicated and needs to be fleshed out more, but I think thtat forms a reasonable going in concept that we can build on.
Cheers,
Vic
Victor Aprea // Wicked Device
M: 607.745.1515
Luis Fraguada
Apr 12, 2012, 6:28:59 PM4/12/12
to airqua...@googlegroups.com
Great stuff Vic!
Hard to not start talking about all the implications of the design choices (how many sensors in relation to wireless packet size, in relation to .....) without crossing into other topical realms.
Glad to hear the RFM12 is still being considered!
About the I2C conflicts, could there be an I2C 'Egg Bus' interface for existing I2C devices? Maybe if a 'proto sensor breakout' is developed, it could accept I2C devices with logic to mask them from conflicting by being addressable (through the local breakout board logic) by one of the addresses in the 'experimental' range you speak of. I'm obviously not well versed in the I2C arena, but just thinking off the top of my head. Do these kind of things exist?
Hard to not start talking about all the implications of the design choices (how many sensors in relation to wireless packet size, in relation to .....) without crossing into other topical realms.
Glad to hear the RFM12 is still being considered!
About the I2C conflicts, could there be an I2C 'Egg Bus' interface for existing I2C devices? Maybe if a 'proto sensor breakout' is developed, it could accept I2C devices with logic to mask them from conflicting by being addressable (through the local breakout board logic) by one of the addresses in the 'experimental' range you speak of. I'm obviously not well versed in the I2C arena, but just thinking off the top of my head. Do these kind of things exist?
Victor Aprea
Apr 12, 2012, 9:29:36 PM4/12/12
to airqua...@googlegroups.com
Luis,
I think you're on the right track. What is "commonly" done when you want to support multiple I2C devices that with potentially conflicting addresses is to put an I2C Multiplexer game. In doing so you can effectively have multiple I2C buses, where each "branch" has only devices on it that have unique addresses. An example of such a device is the TI PCA9544A (4:1) or NXP PCA9540B (2:1). So in short, if you wanted to incorporate existing I2C devices that conflicted with 'Egg Bus' addresses, you could create a more complex I2C topology using a multiplexer. The multiplexer would be the only I2C device that was "directly" connected to to Nanode's I2C hardware, one of the downstream buses would be the Egg Bus, and the other would would be for "other I2C devices."
I think that's probably overkill for the AQE, and conventional address reservation should suffice though. Integrating an I2C multiplexer would add some hardware cost and software complexity. I'm not sure there is a good value proposition for adding it. To me, it seems like the AQE should do what it's supposed to do reliably, it should support future growth, and it have support some (finite) degree of "hackabilty", but still try to adhere to the KISS principle. I think reserving some I2C addresses for hacking would satisfactorily allow for the last thing. Hope that all made sense!
Regards,
Vic
I think you're on the right track. What is "commonly" done when you want to support multiple I2C devices that with potentially conflicting addresses is to put an I2C Multiplexer game. In doing so you can effectively have multiple I2C buses, where each "branch" has only devices on it that have unique addresses. An example of such a device is the TI PCA9544A (4:1) or NXP PCA9540B (2:1). So in short, if you wanted to incorporate existing I2C devices that conflicted with 'Egg Bus' addresses, you could create a more complex I2C topology using a multiplexer. The multiplexer would be the only I2C device that was "directly" connected to to Nanode's I2C hardware, one of the downstream buses would be the Egg Bus, and the other would would be for "other I2C devices."
I think that's probably overkill for the AQE, and conventional address reservation should suffice though. Integrating an I2C multiplexer would add some hardware cost and software complexity. I'm not sure there is a good value proposition for adding it. To me, it seems like the AQE should do what it's supposed to do reliably, it should support future growth, and it have support some (finite) degree of "hackabilty", but still try to adhere to the KISS principle. I think reserving some I2C addresses for hacking would satisfactorily allow for the last thing. Hope that all made sense!
Regards,
Vic
Chris Jefferies
Apr 13, 2012, 5:05:28 PM4/13/12
to airqua...@googlegroups.com
This sounds cool. So the "egg" is the gateway device? The "sensor box" is remote and has a radio (or is wired)? and perhaps has a hard wired sensor or two that communicates via i2c to the radio in the sensor box? Now the new idea is that there will be some JST connectors on the sensor box to extend to other custom sensors that communicate via i2c?
The question I have is, will i2c be a protocol over the wireless connection? IOW, is it a transparent i2c protocol from the extended sensor to the egg? Or is i2c from sensor to sensor box, then wireless packets to egg?
I'm sorry, I don't understand i2c and wireless.
Thanks for all your work,
Chris.
Victor Aprea
Apr 13, 2012, 5:35:59 PM4/13/12
to airqua...@googlegroups.com
Chris,
I think a good abstraction for the system concept is that all the deployed sensors will effectively have globally unique identifiers. You are spot on about the Egg being a gateway device, the means by which the sensor information gets to the web ala Pachube. There will be a shield that will go into either the Egg or a Sensor Box that provides the interface to the sensors. All Sensor Boxes also has a wireless transceiver and can talk to Wireless-capable Eggs to get the data to the web. In summary:
I think a good abstraction for the system concept is that all the deployed sensors will effectively have globally unique identifiers. You are spot on about the Egg being a gateway device, the means by which the sensor information gets to the web ala Pachube. There will be a shield that will go into either the Egg or a Sensor Box that provides the interface to the sensors. All Sensor Boxes also has a wireless transceiver and can talk to Wireless-capable Eggs to get the data to the web. In summary:
- Hard-wired / Self-Contained Egg comes with Sensor Shield and 4 sensors
- Wireless Base Egg (no Sensor Shield or Sensors) comes with Wireless Sensor Box which has the Sensor Shield and 4 sensors.
In either case, the Egg has an Ethernet Jack and acts as the gateway to the internet. The Sensor Box acts as a wireless relay for the sensor data to get back to the Wireless Base Egg (and from there to the internet).
I2C is inherently a wired electrical interface. The Nanode (either in the Egg or Sensor Box) will be able to poll the addresses on this bus to determine which sensors are present and get the data from them, and send it off to a Wireless-capable Egg. The message structure returned by sensors on the I2C bus will probably be *very* similar to the over the air message structure, but not identical. Contrary to what I wrote previously, I think it might actually be easiest to simply transmit one wireless packet per sensor instead of trying to stuff all the available sensors into a single packet.
Anyway, I'm pretty excited about the concept. I was thinking more about the whole I2C multiplexer thing and may have convinced myself that it would be worth the complexity to add one. My reasoning is that you might want to have multiple instances of a given sensor type present in the context of a single Egg or Sensor Box. You would need to plug them into separate branches for that to work in framework we've been talking about. What do people think - is there a good reason to support multiplicities of a sensor type in the context of a single Egg or Sensor Box?
Kind Regards,
Vic
Reply all
Reply to author
Forward
0 new messages