Using many moudels with FEZ Spider Mainboard


I have a FEZ spider Mainboard and I would like to plugin many sensors/modules to my mainbaord in order to build a prototype for my project, and I have designed (customized) enclosure to avoid reading conflicts between these sensors.

My sensors/modules are: 3 light sensors, 2 motion sensors, multicolor LED, music module (for notification), Power supplier (4 XAA Batteries), Display screen T35, button and external sensor for audio frequency detection.

I am a newbie in using .NET Gadgeteer and it is my first time in building such an embedded system. My questions are:

1- Is it viable to use such many sensors with .NET Gadgeteer?

2- If I want to add an external sensor (Audio frequency sensor), what should I look for exactly before buying one? my electrical engineering background is almost (NULL), so please refer to products you recommend.

3- From your experience, will I face problems during the implementation and deployment phase with these many sensors?

If you want to know why I need so many sensors from the same type like: light and motion sensors, well I am looking to survey a floor at my building for light usage. And as I said before I have my box to make everything tidy and in its correct position (I hope so :slight_smile: )

I apologize if my questions seem so basic to you, but I don’t know where to ask! So I back to you guys.

Thank you in advance,

It all depends on the through put you are trying to get.

I have a spider running a web server, ftp server, X10 controller, IR receiver that decodes 8 different remotes, sends macro commands to IR devices and IP commands to AV equipment. It also has a SQLite database to hold a movie database. It controls SSR to control power to equipment. Bottom line its a media center controller. Works very well.

@ Cowby - Sounds like a cool project. I’m especially impressed to hear that you could decode and encode IR signals straight from the Spider. (I was under the impression that the managed code would not be able to handle such fast I/O, but then… I never used the IR module)

@ waadimsi - Do you have a specific audio frequency sensor in mind? If it is something that handles the processing externally and only pass the results serially to the mainboard, then it will probably work well. From what I can tell it would be the only part of your concept that might involve a bit of careful planning to get it working. Keep in mind that managed code is not real-time and not perfect for very fast pulse sensing and such. If that is something you need, it might be better to add an external microprocessor circuit to assist with that bit of functionality.

@ Cowboy Thanks a lot. Thats a relief, now I can order more! Since I need to build more. Can I ask you two questions from your experience please

[ul]It seems your Media Gadget consumes a lot of power and it seems you have managed that issue perfectly! In my case, I need a portable device so I figured out (4 X AA batteries) is the solution as power supplier, if I need this device (my prototype) to be running for 48 -72 hours do you think it will work without interruption, such as (having many sensors/modules will drain the batteries power! What is your suggestion in that matter? [/ul]
[ul]The second question is about the communication part in your project, in later stage of my project, I need to send data (the sensors reading) for a web service as a POST request every 10 seconds, so I am planning to use WiFi R21 Module with REST (in Visual Studio , lightweight web service) do you think this will work? What are the major problems that I may face in such a stage, I mean in the communication process in general?[/ul]

@ KiwiSaner Many thanks and I appreciate your insight. Well, I am thinking to get this sensor from Grove. The complete package to make it running on FEZ spider Mainboard and .NET Gadgeteer compatible are:

[ul]Grove Sound Sensor
Grove Expansion - .NET Gadgeteer Compatible
The Cable[/ul]

And regarding the serial reading I am thinking to sample the data every 2 seconds, do you think this is okay? Another question please, it is about using many modules, if there is a module X needs socket type Y on the mainboard and Y is already taken by another module! Can I use Extender module on GPIO socket to connect module X with the mainboard?
Thank you so much,

@ waadimsi - In my case I dont worry about power that much because its always plugged in to AC. I use the J11D for Ethernet connection and I dont have any experience running on batteries so I cant help you there. The service POST should work just fine. My process drives a Denon AV receiver via IP and it works great. I have all of the output driven by a FIFO queue in a thread and I actually throttle the output so I dont over run the receiving devices ( X10, IR devices) for IP devices it bypasses the throttling. The IR interface is interrupt driven and the spider handles it well. The interrupt receiver only stores the event and time in an array and when the IR stream is over then decodes the data. I can get 50 uSec resolutions using this method and most IR streams are in the 500 uSec and slower. Hope this helps.

I would be concerned that using WiFi and running efficiently on batteries for long periods of time are mutually exclusive. If you’re contemplating this, you will probably need to look at better and larger power sources than AA’s. Unfortunately there’s no real way to measure how long a device will work on batteries until you actually run it and measure current draw. You will probably need to power down the radio when not in use to extend battery life.

Simple answer is NO an extender doesn’t allow you to use a port designated as one function as another. An extender or breakout is more intended to allow you to use extra pins on a socket you’re using for one purpose, or when you want to connect a non Gadgeteer device. In the scenario you’re talking about though, if you’re explicitly talking about X and Y sockets as defined by Gadgeteer, you can see from that there is a difference in X and Y but the first data pins should be able to do the same function… this means you need to tell us explicitly what devices you want to be able to use together, as it will come down to what connections it has (number of IOs it needs) and the driver.

@ Brett Thanks a lot Brett. Well I created a simple sketch with Gadgeteer visual designer (please see image below) without connecting all modules, would you please help me to achieve my goal in building such multiple sensors device.I mean what would you do if you have these sensors/modules how would you connect them to the mainboard?

Regarding my devise and to be more explicit, I want a device that can sense the ambient environment and give me a full reading where I can use these data and I apply my algorithm later for analysis. In this stage of my project, I am looking to build a monitoring device, basically it uses: two PIR senors and three digital light sensors and sound sensor from other vendor (Grove) beside other essential modules such as WiFi and power pack.

Regarding your advise in not using AA’s batteries, what do you think the best option as a power supplier, considering that I want my device to be portable and not strictly wired. And do you think if I used SD Card memory as a storage replacement, instead of sending the data wirelessly via WiFi, will reduce the power consumption?

Thank you again on your reply that was helpful and save me from trouble.

In general, I would say running a wifi module would definitely consume more power than the SD card.

I added all those components on the design surface myself - although I used the TE35 not the T35, since that’s all you’re likely to buy (not that it changes things at all, except the code behind the scenes).

Given there’s specific ports for the RGB/T on the display, wire that up first. Then same for SD card.

From what you have left, the GHI LightSensor can only be connected to the single A socket, so that’s a problem since you have 3 on the designer. Worse, the A socket is also one of the S sockets - since both the music and WiFi modules use S ports, you will only be able to wire up one (without potentially doing something different)

The button will use an X or Y socket, the motion sensors will use an X or Y socket, the multicolour LED will use an X or Y socket, so they can use those successfully.

(warning: there’s some reports of Spider and the motion sensor firing every 6 seconds or something - I don’t have these devices to have experienced it but thought it was worth noting)

So now the challenge. Either ditching modules, or figuring out how to piggy back things together so they don’t use all the sockets they would normally. If you do this, you would also need to create your own driver (modifying the existing driver). But what you would need to do here is to look at the modules in detail, specifically what pins they use and see how to “join” two or more.

Posting this at this point, and I’ll take a look at the music+wifi first and then 3x light sensor.

Edit1: Music module uses whole socket. Not going to be easy to piggy back it with anything, going to have to steal pins from somewhere else.

Edit2: Wifi needs 3 pins above MOSI/MISO/SCK that can be shared. Music needs 4 pins + MOSI/MISO/SCK. That’s 10 pins total, so we need an S plus 3 pins from an X/Y.

Edit 3: the lightsense module is simple, only uses one AnalogIn pin per module. We can piggy back three onto a single A socket.

Edit4: the PIR module can be piggy backed since they each only use one pin.

Edit5: the SPI hub won’t help us with music+wifi combinations. We might need a “custom” way to deal with these.

To add one option to @ Brett’s excellent analysis, you could use a DL40 with the DL40IO firmware to extend the number of IOs available for both digital input as well as Analog inputs.

So you could shift the light sensors and the Grove sound sensor to the DL40, quite easily since these are all simple analog input devices so you will not need any elaborate code for them.

The motion sensors can also be moved to the DL40 since they only require simple digital interrupt pin.

Of course the downside is that the DL40 does not have any Gadgeteer sockets so you will need to wire some extender modules to the DL40 so that you can connect the modules. But the DL40 it self will only require one socket from the mainboard.

DL40-IO Firmware:

You can read more about the DL40-IO firmware on the original code share.

Agree, a DL40 can be a good tool in a scenario like this - although I was thinking that the driver modification would be simpler if you just deal with pin remapping. You’re still going to need the Extenders and/or a way to connect things with remapping pin connections.

Lets take the LightSense module as an example of the driver mods you’d need, and the hardware mod you’d need.

Each LightSense module uses Pin3, an AnalogIn pin. You should check the socket map so you know why this works and check the “A” socket; you’ll see it has 3 AnalogIn pins on pin 3, 4, and 5.

So a simple approach to connect 3 of these modules at once is to use a breadboard and 4 extenders. From the mainboard, the cable is connected to one extender (the “input” extender), that is then plugged into the breadboard. The other 3 extenders are plugged into the breadboard as well, in different non-overlapping areas. Pins 1, 2, and 10 from the input extender need to connect to the same pins on the other three extenders - run jumper wires. Then, pin 3 from the other 3 extenders needs to be connected back to the input extender - pin 3 on one extender goes to pin3 on the input extender, pin3 on the next goes to pin4 on the input, and pin3 on the last goes to pin5 on the input.

Then software. is the driver. You can see it’s very simple - the constructor uses the socket it’s passed, and sets up “input” as pin3. I’d opt to extend the driver by changing the constructor to set up 3 inputs, and then add a pair of new methods to read the voltage or percentage of a chosen input (1, 20 or 3). Leaving the standard methods alone means you have backward compatibility if you just have one of the modules connected not this triple one…

For the WiFi/Music combo, you’ll need to make bigger changes and use two sockets to get enough pins. You’ll need to connect MOSI, MISO, and CLK on both modules to the MOSI/MISO/CLK pins on the S socket.

Hope that gives you enough information to decide to progress or not. Certainly seems achievable, just not as plug and play as it could be with les modules :slight_smile: but where’s the fun in that ! :slight_smile: :slight_smile:

Thanks a lot @ Brett @ taylorza that’s really helpful. Indeed WiFi module is much important to me than Music module! So I’ll keep in my mind your recommendations.