Which controller to use?

I'm in agreement, although they seem reluctant to go that way.

I can understand their thinking. "All" that is needed is a passive memory device - a sneakernet - to get information from the office to the control unit and back again. (Wifi would be great except for the range required. Wimax would probably be great except for the cost and that the technology doesn't seem stable). But USB is *not* designed for the outdoors.

A semiconductor device *intended* to drive the coil of an electromagnetic relay. This can be something as simple as a Darlington...

Understood. You know your application better than any of

*us*! :>

Of course you can provide whatever API you think you need. And, that will depend on the actual device(s) that you use for your indicator/display, etc. E.g., if you don't want to have to bother with a timer job that does: lamp on - delay - lamp off - delay - repeat then you can always purchase an LED that blinks by itself.

Unfortunately, that happens far too often. I prefer looking at the entire application and then making the hardware-software tradeoffs myself. I.e., some things it is silly to "spend (hardware) money on" (e.g., a low speed UART could be done with bit-banging) whereas other things are *essential* (when you run out of RAM, there's not much else you can do! :> )

Are you sure that they are thinking *exactly* along these lines? I.e., that the USB device is *just* a "transport device" and *not* a "storage device"?

In other words, your box operates *without* the "thumb drive" installed and accumulates data *internally*. The thumb drive is introduced *just* to copy the data out of your device and transport it to some other device that "prints it" (likewise, it transports "settings" from some external device *to* your box).

[N.B., you might want to *retain* the "old data" within your device to cover the case where the copy-to-thumb-drive fails -- or the thumb drive gets lost, etc. You can always externally track which data you have printed vs. "new data" -- i.e., let your external application disregard the "old data" that it sees *again* in the thumb drive]

In this (transport) case, you can possibly come up with a weatherproof connector (behind a rubber gasketed door, etc.) that is "always" protected from the environment *except* for the minute or two that the thumb drive is present.

OTOH, if the thumb drive *is* your "data storage" device, then it must be connected at all times -- different problem to solve. :<

Returning, again, to the "transport" approach...

You can argue that, instead of carrying a thumb drive to the box, you can carry some "wireless enabled" device instead. E.g., I have a WiFi PDA and a WiFi phone that I use to talk to wireless devices so that I can make them "headless", otherwise.

In your case, (depending on budget, sophistication, market, etc.) you might suggest bluetooth but supporting a profile that a "typical" cell phone would be able to pair with -- perhaps even an iPhone? Depending on your market, the "wow factor" might be worth something...

Or, a zigbee (or bluetooth) dongle that plugs into a laptop's USB port, allows the laptop to talk to the "box" (user interface for all those "settings", etc.) to fetch history data and deliver configuration data.

In *any* case, you also have to look at the consequences of folks tampering with the box via the "interface" (be it USB or wireless). What happens if someone introduces bogus configuration data (safety, liability, security, etc.). And, what happens if someone harvests data from your device -- is there anything exposed there that *shouldn't* be?

For $150 in small quantities you can get a PC-104 processor board with an ARM, running Linux. That'll have a USB stack, and Bluetooth as well, if you want.

It has the potential to save you loads of development time, and you can play video games on it as well, as long as you don't mind building them from source.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Yo D,

I am but a simple software endjuneer. I set the bit to one, it goes on. Unless it's the other way round.

Hah! I've abstracted it a bit, but otherwise I am pretty much in the dark myself.

That's an interesting thought. But really I think "we" want an off the shelf controller module of some sort.

I, too, insist on the "big picture". The tradeoffs are often in the numbers - basically, "how many of these things do you want?"

Right now, we're talking prototype; in any case I get the impression that it's low-volume, high-markup, which means off-the-shelf everything.

Power *might* be an issue there. I know ARMs run at low power, but how much does the whole module take "on standby"?

Pretty sure.

Even *with* a rubber gasket it's bound to end up full of goo.

Oooh. Bluetooth smartphone. I like it.

Development cost, OTOH...

To give credit to the original spec writer(s), they'd already flagged this as an issue.

Yes. My point is in how you go looking for this "board". I.e., you can get a board with a bunch of CMOS/TTL outputs routed to a connector; or, some number of those connected to "transistors" capable of switching bigger loads (like relays); or, opto-isolators that give you one of the above two scenarios but with the advantage of isolating the "load" (relay, etc.) from your logic; or a board with actual *relays* on it.

The more you put *on* the board, the fewer choices you have (in terms of COTS solutions). OTOH, the less you put on-board, the more interconnects, modules, etc. you will need.

In any case, to the software, it's "just a bit" (well, actually, some designs might require you to periodically stroke that "bit" as a safety factor -- so the motor or whatever shuts off if the processor looks like it may have become "distracted")

You can still hook a "flashing LED" to a digital output (since the LED would presumably be mounted off-board so it could poke through a window in the enclosure)

Present informed opinions to customer/client. Let them decide on what the actual product needs to be (since they, ultimately, know the market "best" -- or, *should*!)

Such a board is unlikely to have relays in the mix you need - so a simple daughter/slave board is usually done.

Be very cautious deploying mechanical relays, if at all possible, use Power fets, or even solid state relays. - lower power, and the arcing contacts in relays, can have unexpected consequences.

-jg

You might strongly hint at the possibility of users failing to understand this (and any consequences it might have for you or it)

Yup. Any holes in a case are problem areas -- buttons, connectors, indicators, etc.

The biggest issue is the BT stack. You can either purchase one, develop one or use an "open source" solution.

You can also go other wireless routes -- e.g., 900MHz "modem". There are also some devices suitable for low frequency short hops -- like the distance between a laptop user and your device.

You have to look at the application and its market and decide which "fits right".

Good luck!

--don

For a low volume/high cost device, I'd suggest the use of BT modules like the ones form Ezurio. They support the Serial Port Profile and are as easy to use as a modem through AT commands. BT stack is in the module, no development cost and, even more important: no approval cost/issues since these modules are sold and appoved as an End Product. You only need to stick the supplied labels that come with each module on next to your own type sticker on your device are you meet all the RF requirements in almost every country.

Meindert

Just a quick data point: I've used the Tern products, and found that:

1) The quality was average, at least for the board-level devices (we didn't use the boxed products) 2) Price was quite competitive 3) Support was awful - bad enough to turn me off from ever using them again.

Just my experience - maybe I hit them on a bad day (couple of months, actually). Also, this was several years ago - they may have gotten better...

Also, have you considered ZigBee as a wireless protocol? On the down side, you'll need a hardware interface of some sort on your PC (as opposed to BlueTooth, which is so often built in now). However, development is really easy, the cost is low, and the range is a bit better than BlueTooth.

-- Mark Moulding

eob$ snipped-for-privacy@news.eternal-september.org...

..

't

in.

,

ally

There is (was?) a pantech phone with zigbee and there are some handheld remotes (maybe AMX?)

Perhaps an infra-red interface could work?

FJG skrev:

If you go with a 32 bit AVR like the AT32UC3A0xxx, you will have a USB OTG. There is WiFi support from H & D Wireless -

There are several 8 bit AVRs with USB - AT90USB1287.

Best Regards Ulf Samuelsson

check this rfid 'toy' interface;