Telemetry suggestions

Do you need continuous reporting? Can you tolerate *polled* operation? Or, a combination of both: e.g., "If you notice the wind speeds picking up and a significant and sudden barometric drop, *call* me so I can watch the tornado sweep across the plains..."

How much recurring dollars do you want to spend? Could you have the phone regularly contact an internet address to upload data?

I think a lot depends on how much you want to put "up front" and how much you want to spend "ongoing"...

Polled operation should be fine, and SMS for communications should suffice.

AT&T has some pre-paid plans that should work OK.

I guess the question now is what phone? I have not done any phone programming.

So the phone API needs to be able to scan the incoming SMS messages, talk to serial device, and send an SMS. Monitoring the device temperature would be a plus.

I have a new HTC sensation that I can program on, but I want to put the cheapest least-common-denominator in use.

I was wondering if you could actually opt for *voice* output (or, a tone-based scheme if you know the device will always be talking to another "device" -- i.e., non-human). My thinking, here, is that a voice-only plan might save you some money?

Can your "meteorological instrumentation" provide a BT link, instead? I don't know how universal serial ports are on native phone hardware (iPhone, maybe?) so, otherwise, you might have to use USBserial.

E.g., with a BT *headset* style interface, the meteorological instrumentation could provide an *audio* interface over BT to convey data to the phone (and, ultimately, *you*)

With mains power available, the power consumption of these other devices (often not designed with low power considerations) shouldn't be an issue.

Sorry, can't help you, there. I don't use a cell phone so the only ones that I have are "toys" (usually kept for their WiFi features... "wireless terminals")

Also, consider if this is a "one off" project or something that you want to make "in quantity". I.e., you can kludge together things on the cheap with bubble gum and string that you wouldn't ever consider releasing as a real product!

G

as

ta

e.

What serial device? Are you building one?

You can send SMS with the following:

//---sends an SMS message to another device--- private void sendSMS(String phoneNumber, String message) { PendingIntent pi =3D PendingIntent.getActivity(this, 0, new Intent(this, SMS.class), 0); SmsManager sms =3D SmsManager.getDefault(); sms.sendTextMessage(phoneNumber, null, message, pi, null); }

3G

as

ata

ice.

Most Android serial ports are connected to blue tooth module (for audio only). There are no external serial ports.

Most Android USB ports are device mode. Device mode USB2Serial are usually custom product, like ours.

Possible, but not what I was thinking.

I don't have anything selected yet. There seems to be a good selection of kits.

Depending on how it turns out, I might post the source and instructions. Don't think it's worth trying to sell.

Many or most of these weather kits are wireless, but my research is just starting there also. I doubt they are WiFi. Intended to be mounted on the roof, and read from a console, from what I can tell.

I just read that Android 3 supports USB host mode. Don't know if any phones have that version yet.

o 3G

ne as

data

ffice.

So, you need to build the receiver and talk to it as well. They are usually in proprietary protocols. If you only need temperature, it might be easier to just build the sensor.

Android 3 are for tablets. Have not seen any phone with 3.

If you are only looking to convey "current conditions" (i.e.,

*not* acting as a "datalogger" that needs to dump *batches* of data), this should be a relatively low bandwidth requirement. I.e., lower than *voice*.

So, sending the data to the phone over an audio link (even if it isn't a BT earpiece but, rather, taping a speaker to the phone's mic -- or hardwiring the two together) may prove the path of least pain.

Note that you can have the weather station *speak* the "current conditions" (even if it does so *continuously*) or encode the data into something akin to DTMF -- or, even, a simple TDD representation (or, even simpler!)

OK. Something I have little/no experience with. I had a small wireless temp transmitter but it didn't fare well *in* the weather.

Understood. My point was that you have a lot more leeway when hacking together "one off" designs. Things that you could never get away with (appearance, durability, etc.) if you were making something for a "paying customer"). Even releasing such a design allows others to make incremental improvements to it without investing in expensive tools or fabrication.

Oh, if you're looking at the sort of things I've seen, these are closed systems. Often using very low power/short range RF links operating as "wires". E.g., no smarts in the actual sensors.

Imagine generating a "frequency" that varies with temperature and sending that on a particular *carrier* to a "base station". I.e., "eeeeeee" is 82 degrees, "ahhhhhhhhh" is 74.3 and "ohhhhhhh" is 63.9 -- which the base evaluates and "digitizes" for display.

Look carefully at what you are buying before you embrace a solution. Look at the frequency that the device uses to give you some idea as to how "smart" the protocol might be.

You might find that a *wired* met station is more amenable to your use. E.g., anemometer just outputs pulses (which you can count), temperature measured via thermistor (which you can use in an oscillator -- and then count!), rain gauge just drives a contact closure each time a specific volume of water is collected (which you can count), etc.

(do you notice my obsession with *counting*? :> )

you said you have AC so, maybe X10/domotics to a 'receiver'/'host computer in a more hospitable location. Then either internet or phone or ???

OK, i got it. You are a "bean counter". :-}

I, however, am a picture guy. Since we are talking about Android phones (most with camera), nothing wrong with taking pictures of themometer, rain guage and wind vane. With the right image processing, you can get any data you want.

BTW, serial link (from USB2Serial) can send image data over hundreds of feet. That's why i am so obsessed with serially linked droids.

No beans; events! I like doing things "over time" (e.g., integrating converters) -- trading time for resolution, etc.

E.g., the Am9513 was one of the "drool parts" ages ago (too bad it was so expensive -- *huge* die!)

I just mentioned that most of the ones I saw for sale were wireless between the sensors and the base in response to the question about BT. I have no intention of running over the wireless provided by the as yet unselected unit.

ASCII over a serial link is what would be preferred.

OK. I had originally assumed you were *making* something (even if that meant piecing together various bits and pieces).

You may, instead, want to look into the wired option. The one that I cannabilized had lots of telephone-like cables (the flat stuff that you sometimes see used for network cabling) that plugged into the display unit. *Long* cables since the display was intended to be indoors while the instruments were typically roof mounted.

So, the signals coming down those wires had a high degree of inherent noise immunity -- often easy to interface with.

You might find something like that harder to locate. Or, more costly (?)

I wonder if you could, also, come up with an SD-card-like interface to connect your field to the phone? Or, even a

*real* hack -- using the headphone out signal to control a multiplexer... that presents some selection of signal(s) on a mic in connector? This would probably be the least painful mod to the phone (and low-enough-tech that it would be easy to breadboard "one-off")

This is for pretty much out in the middle of nowhere.

G

as

ta

How far away are the sensors from your central (for lack of a better term) location?

The sensors and the "station" are in the same place. So there is no complicated scheme between the sensors the telemetry node.

Don Y sent on October 10th, 2011: |-----------------------------------------------------------------------------| |"On 10/10/2011 10:44 AM, bbhack wrote: | |[..] | |> Polled operation should be fine, and SMS for communications should suffice.| | | |I was wondering if you could actually opt for *voice* output | |(or, a tone-based scheme if you know the device will always | |be talking to another "device" -- i.e., non-human). My | |thinking, here, is that a voice-only plan might save you | |some money? | | | |> AT&T has some pre-paid plans that should work OK. | |[..]" | |-----------------------------------------------------------------------------|

Telephone companies change pricing schemes, but supposedly (perhaps in Europe and definitely when all telephones were landline telephones) using a telephone line only for data instead of voice was charged at a higher rate.