Sounds pretty cool. On the A/D, I would start with the external high speed one, in whatever resolution your project finds useful. If 12bit does the trick, no need to go to 16 bit. But if 16 bit is a benefit then do it. I don't know how metal detectors work, but I would think even an Uno R3 could do this. But heck, the Duo is very cool!

Well, not exactly. Those numbers seem to assume continuous operation. These are sheep, not aircraft. Put the processor, GPS, radio and all to sleep for some interval. A few questions:

- How often do you need to sample position and temp? Sheep and temp don't move fast. Every minute?  Every 5 minutes? Every 30 minutes?

- What does "5 ha" mean? How big is that in square miles?

- Are the sheep expected to be randomly distributed throughout the area? Or do you expect they will cluster all together in one area?


A few random thoughts...

First, decide what sampling interval you need and plan to shut things down in between. If you only need to sample every 15 minutes, turn the GPS and radio off, put the processor to sleep and only bring everything up to take a sample.

Zigbee or XBee or XPS is a good choice here if the sheep are spread around the sampling area. The sheep can be a mesh network and pass the info along. Even if they do cluster, Xbee pro can give you maybe 6 or more miles line of sight. If the sheep are in a big pasture, you should have line of sight.

If you are able to wait until the end of the day to get the data, SD is fine, but how many sheep are we talking about? If its a small number getting the cards is easy enough. If its 25, 50, maybe more sheep, well the radio is worth the effort. Keep in mind, you fon't need to transmit each sample. Collect the samples in EEPROM and transmit them every x samples, or every y hours, or once a day.

I'm actually working on a very similar system, although for boats. Its very doable, and fun. Maybe some folks from your University's engineering department can persuade a professor to give them some credit for helping you out with design and construction?

... C1-C3 are all 10uF capacitors, but the package size is SMC_B - I'm not familiar with this and can't seem to find any parts like that on Digikey or Mouser.

Hm, SMB and SMC are standard sizes:

http://www.digikey.com/product-detail/en/SMC5.7223K100J33TR12/399-6445-2-ND/3028943

SMC_B is something I'm not familiar with and could not find. Let me suggest you have a look at the gerber files. You can locate C1 and look at the pads, to get an idea what the package is like.

The Serial class uses the following formula to obtain the clock divider:

Code:

 _pUsart->US_BRGR = (SystemCoreClock / dwBaudRate) / 16 ;

in your case the perfect divisor would be 84000000 / 10400 / 16 = 504.8076
but the register will truncate to the integer 504.
The error is under <0.2%

IMHO you should give a try with Serial.

I agree with this assessment. Failing that, perhaps the Multi Serial shield would work...

You don't sound stupid, but I'm not clear on what you mean by having the slave read its address. You need to know the address of the slave in order to talk to it, so if the slave is reading the jumpers to set its address, you don't really have a way to tell the uC what the address is. I2C can have a multiple master bus, but you need something more intelligent that the NXP chip to make this work.

Why not just use some IO pins on the micro controller to set the address? You have plenty of pins to do that. Alternatively, you could use an I2C expander chip. The expander chip would have an address known to the uC that never changes, and it could read pins set by the user. These pins could specify the addresses of the slaves.

Oh, I forgot... The enclosure will be the hardest thing to find. There are some Arduino enclosures but not very many and rarely does an off the shelf enclosure match your goals exactly.

Also, if you're looking for one Arduino to monitor al the sensors, you'll need some circuitry to boost the signals. There are lots of ways to do this and it depends on the sensors/transducers you choose, but you need to think it through.

What you want to do is really not very difficult. If you're designing a commercial system you can use Arduino parts to prototype it, if you're building a one off then you can just buy the parts and be done. The tricky part is finding compatible shields.

If you go to somewhere like adafruit.com or sparkfun.com (or any of the many other similar online stores) you'll find hat you need. You'll need a base Arduino and some "shields" that add functionality.

Adafruit.copm has some LCD shields. They also have an ethernet shield. The Arduino itself can sample analog and digital data. For a data center (measuring temp and humidity) you probably won't need very high precision, so this is not difficult.

I would suggest the Duo, just because its not all that expensive for the tremendous capability you get. Alternatively, get a mega. Just make sure the shields you select are compatible with the arduino you get. Its easier to pair shields to an Uno R3 or even a mega, but you can paid some to the Duo.

Bottom line, everything you want to do can be done. You'll probably have to code the SNMP client code yourself, but the ethernet library has what you need for that. Just shop around for parts and have fun.

Since its a geosynchronous bird, once you found it, well you found it. You'll need some way to know where your mount is pointing, so just record the settings. As said, you'll need to fine tune. Maybe you can get signals from the receiver to even automate this part.

Of course, you do play to be able to locate more than one sat, right?
 

Sometimes the devices are tolerant, you can check the datasheets. Typically, though, you need a "level shifter" to bridge the 5V and 3.3V. This app note shows a good way to do it, and there are other ways:

http://ics.nxp.com/support/documents/interface/pdf/an97055.pdf

You can try to telnet to the port to see if you can establish a connection. If you can then the port is not blocked. If you can not, then you have an idea where to look.

There is no official Arduino WiFi library, because there is no official Arduino WiFi Shield. Obviously a WiFi library needs to support the WiFi chip /module that is used that particular WiFi Shield.

FYI http://store.arduino.cc/eu/index.php?main_page=product_info&cPath=11_5&products_id=237
http://arduino.cc/en/Reference/WiFi
Don't have so no idea how good it is.

Riva, to be fair, when that was posted, there in fact was no official Arduino wifi shield. Its a fairly new product, although it was under development for a while.

Having looked at many of these, I have to say that the Gainspan module is by far the most impressive I have run across. I have been working on a project (on and off) that incorporates it, some memory and a uC into a shield. The GS module is extremely powerful, with a web server built in, the ability to address external memory to store web content and an extremely high speed UART plus an SPI port. Because it does all this, the uC I am adding can be fairly low end and is there primarily to facilitate SPI and/or I2C communication with the host (that is, the Arduino) and to process data it receives from the host to allow dynamic web content. I might use a low end ARM just because I can, but an AVR (like the 1284P) would be completely acceptable.

One thing that has stalled the project (I always over think everything) was the arrival of the "official" Arduino wifi shield. This is one of those that uses a wifi chip (in this case from HDG) coupled to an external uC (an Atmel 32 bit UC3). The HDG104 chip is fairly dumb as compared to the GS module, but HDG has done a good job preparing firmware to run on the Atmel chip. So in this case, the UC3 handles the TCP stack and other features (I have not checked the latest list recently). The 32bit UC3 microprocessor is extremely powerful, even more powerful than the uC used on the Arduino Duo. A major benefit (at least for me) is that the Arduino wifi shield uses SPI to talk to the host Arduino.

So then, why don't I just use the Arduino wifi shield? It does look like the hardware can be used as is for my project (I still need to check a few more things to be sure). But I would need to modify the firmware, adding a basic web server, my static web content, and finally my custom firmware that produces my dynamic web content. It may actually be more difficult and time consuming to do all that than it would be to prototype my custom shield. The GS module can act as an access point, as a web server, can store the static web content on its own SRAM and do many other tricks. So thats the way I am leaning. Plus, its fun to design hardware.

As I review what I typed, I'm not sure why I am posting this, but heck, its written. Maybe someone will find it interesting.

 

 

The 6.6v you are feeding the Due goes through a voltage regulator and pared down to 3.3v before getting fed into the chip. The digital pins (I'm assuming you are doing PWM?) are at 3v3, as mentioned by Leon. It is also possible that your resistor (you are using one, right?) may be too large depending on the voltage rating on the LED. Not all leds are created equal.

Thanks for the reply. I was referring to the PWR and L LEDs, which are built on to the board.

I confess, I am not sure exactly what you're asking. If you want to learn about interface technologies like I2C/TWI, SPI and so on, have a look here:

http://www.gammon.com.au/forum/?id=10896

That's maintained by Nick Gammon (a participant here) an is a fantastic resource.

What do you mean by "compatible?" That device won't just plug on to an Arduino, but I just read through the data sheet. It requires 3.3V, which is good. You talk to it using serial/TTL which is also good for most uses. It has an SPI bus but that is used only to flash new firmware into it.

So yes, I would call it compatible in that you can power and control it from an Arduino, but its not a shield. It would not be hard to build a shield to host this module, and I would bet someone already has.

After poking around, I can not find a chip to convert I2C or SPI to TTL. Of course it could be done with a uC and a little code, so perhaps I'll take that route.