PICOBEE

First new board of Spring -- PICOBEE
'328 (Arduino bootloader) + RTC (with battery backup) + XBee

Prototypes should be in around 2-3weeks.
Details at Loading...

(* jcl *)

interesting, what kind of applications are you thinking about that involves wireless combined with a RTC?

interesting, what kind of applications are you thinking about that involves wireless combined with a RTC?

What can you think of that needs wireless and couldn't have a RTC :smiley:

I use RTCs all the time - knowing the time is just handy.

What can you think of that needs wireless and couldn't have a RTC smiley-grin

I agree :wink:

  • Timestamps for datalogging
  • Wakeup timer for datalogging/transmission

Are the two that come immediately to mind.

(* jcl *)

The PICOBEE datasheet with schematic, BOM and assembly instructions is at

http://wiblocks.luciani.org/PICO/PICOBEE-index.html

I will have a couple of software examples posted in the next few weeks.

(* jcl *)

Why run the 328 at 12mhz rather then the arduino standard of 16mhz?

Lefty

This board is a 3.3V board. The maximum specified frequency in the datasheet for 3.3V is around 13MHz
so I chose 12MHz.

(* jcl *)

jluciani:
This board is a 3.3V board. The maximum specified frequency in the datasheet for 3.3V is around 13MHz
so I chose 12MHz.

(* jcl *)

OK, that makes sense. Although some vendors 'stretch' those specs and run boards at 3.3vdc and 16mhz and report no problems. I however certainly do not endorse doing that, just seen it done by Seeeduino and a few other clone vendors.

Lefty

retrolefty:
OK, that makes sense. Although some vendors 'stretch' those specs and run boards at 3.3vdc and 16mhz and report no problems. I however certainly do not endorse doing that, just seen it done by Seeeduino and a few other clone vendors.

Lefty

That's one of those features where there's really nothing to lose from a features point of view. If it works, great. If it doesn't, "meh, here's why it doesn't work, but you can burn fuses to use 8 MHz instead".

You assume that an overclocked processor will fail early (during development versus seven months after installation) and in a way that is easy to debug. I have found neither of these to be true.

A general rule of thumb is that a bug costs $1 to fix during design, $10 to fix during development, $100 to fix while debugging, and $1000 to fix after deployment. In my opinion, except for experimental purposes, overclocked processors are never worth the risk (potential failure after deployment).

Usually things go wrong when multiple factors come into the picture. For example, exposure to temperature and heat over long period of time.I would never try to deploy something by over clocking them. If you need something faster, get a bigger processor.

Added a wireless temperature logging sketch for K-type thermocouples.
The schematic and example sketch are at Loading...
I hope to have a library for the MAX31855 done in the next month or so.

Here is a picture of the prototype hardware --

(* jcl *)