Telemetry suggestions

I want to put a remote weather station in Central Texas. There is no 3G 
there. It would be good to reduce components - using an Android phone as 
the only programmable part of the system, with a USB interface 
presumably. There is AC.

Nothing is selected now. I'm not really well versed in the cellular data 
standards, but I know a little. Thoughts?

On 10/10/2011 7:46 AM, bbhack wrote:
>
> I want to put a remote weather station in Central Texas. There is no 3G
> there. It would be good to reduce components - using an Android phone as
> the only programmable part of the system, with a USB interface
> presumably. There is AC.
>
> Nothing is selected now. I'm not really well versed in the cellular data
> standards, but I know a little. Thoughts?

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"...

On 10/10/2011 12:16 PM, Don Y wrote:
> On 10/10/2011 7:46 AM, bbhack wrote:
>>
>> I want to put a remote weather station in Central Texas. There is no 3G
>> there. It would be good to reduce components - using an Android phone as
>> the only programmable part of the system, with a USB interface
>> presumably. There is AC.
>>
>> Nothing is selected now. I'm not really well versed in the cellular data
>> standards, but I know a little. Thoughts?
>
> 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.

On 10/10/2011 10:44 AM, bbhack wrote:
> On 10/10/2011 12:16 PM, Don Y wrote:
>> On 10/10/2011 7:46 AM, bbhack wrote:
>>>
>>> I want to put a remote weather station in Central Texas. There is no 3G
>>> there. It would be good to reduce components - using an Android phone as
>>> the only programmable part of the system, with a USB interface
>>> presumably. There is AC.
>>>
>>> Nothing is selected now. I'm not really well versed in the cellular data
>>> standards, but I know a little. Thoughts?
>>
>> 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.

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.
>
> 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.

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 USB<->serial.

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.

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

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!

On Oct 10, 10:44=A0am, bbhack <bbh...@gmail.com> wrote:
> On 10/10/2011 12:16 PM, Don Y wrote:
>
>
>
>
>
> > On 10/10/2011 7:46 AM, bbhack wrote:
>
> >> I want to put a remote weather station in Central Texas. There is no 3=
G
> >> there. It would be good to reduce components - using an Android phone =
as
> >> the only programmable part of the system, with a USB interface
> >> presumably. There is AC.
>
> >> Nothing is selected now. I'm not really well versed in the cellular da=
ta
> >> standards, but I know a little. Thoughts?
>
> > 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 suffic=
e.
>
> 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,

What serial device?  Are you building one?

> and send an SMS. Monitoring the device
> temperature would be a plus.
>

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);
    }

On Oct 10, 11:00=A0am, Don Y <nowh...@here.com> wrote:
> On 10/10/2011 10:44 AM, bbhack wrote:
>
>
>
>
>
> > On 10/10/2011 12:16 PM, Don Y wrote:
> >> On 10/10/2011 7:46 AM, bbhack wrote:
>
> >>> I want to put a remote weather station in Central Texas. There is no =
3G
> >>> there. It would be good to reduce components - using an Android phone=
 as
> >>> the only programmable part of the system, with a USB interface
> >>> presumably. There is AC.
>
> >>> Nothing is selected now. I'm not really well versed in the cellular d=
ata
> >>> standards, but I know a little. Thoughts?
>
> >> 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 suff=
ice.
>
> 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). =A0My
> thinking, here, is that a voice-only plan might save you
> some money?
>
> > 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.
>
> Can your "meteorological instrumentation" provide a BT link,
> instead? =A0I don't know how universal serial ports are on
> native phone hardware (iPhone, maybe?) so, otherwise, you
> might have to use USB<->serial.

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.

On 10/10/2011 1:00 PM, Don Y wrote:
> On 10/10/2011 10:44 AM, bbhack wrote:
>> On 10/10/2011 12:16 PM, Don Y wrote:
>>> On 10/10/2011 7:46 AM, bbhack wrote:
>>>>
>>>> I want to put a remote weather station in Central Texas. There is no 3G
>>>> there. It would be good to reduce components - using an Android
>>>> phone as
>>>> the only programmable part of the system, with a USB interface
>>>> presumably. There is AC.
>>>>
>>>> Nothing is selected now. I'm not really well versed in the cellular
>>>> data
>>>> standards, but I know a little. Thoughts?
>>>
>>> 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.
>
> 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?
>

Possible, but not what I was thinking.

>> 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.
>
> 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 USB<->serial.
>
> 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*)

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

>
> With mains power available, the power consumption of these
> other devices (often not designed with low power considerations)
> shouldn't be an issue.
>
>> I have a new HTC sensation that I can program on, but I want to put the
>> cheapest least-common-denominator in use.
>
> 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!

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

On 10/10/2011 1:07 PM, linnix wrote:
> On Oct 10, 11:00 am, Don Y<nowh...@here.com>  wrote:
>> On 10/10/2011 10:44 AM, bbhack wrote:
>>
>>
>>
>>
>>
>>> On 10/10/2011 12:16 PM, Don Y wrote:
>>>> On 10/10/2011 7:46 AM, bbhack wrote:
>>
>>>>> I want to put a remote weather station in Central Texas. There is no 3G
>>>>> there. It would be good to reduce components - using an Android phone as
>>>>> the only programmable part of the system, with a USB interface
>>>>> presumably. There is AC.
>>
>>>>> Nothing is selected now. I'm not really well versed in the cellular data
>>>>> standards, but I know a little. Thoughts?
>>
>>>> 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.
>>
>> 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.
>>
>>> 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.
>>
>> 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 USB<->serial.
>

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.


> 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.

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

On Oct 10, 11:51=A0am, bbhack <bbh...@gmail.com> wrote:
> On 10/10/2011 1:07 PM, linnix wrote:
>
>
>
>
>
> > On Oct 10, 11:00 am, Don Y<nowh...@here.com> =A0wrote:
> >> On 10/10/2011 10:44 AM, bbhack wrote:
>
> >>> On 10/10/2011 12:16 PM, Don Y wrote:
> >>>> On 10/10/2011 7:46 AM, bbhack wrote:
>
> >>>>> I want to put a remote weather station in Central Texas. There is n=
o 3G
> >>>>> there. It would be good to reduce components - using an Android pho=
ne as
> >>>>> the only programmable part of the system, with a USB interface
> >>>>> presumably. There is AC.
>
> >>>>> Nothing is selected now. I'm not really well versed in the cellular=
 data
> >>>>> standards, but I know a little. Thoughts?
>
> >>>> 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 su=
ffice.
>
> >> 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). =A0My
> >> thinking, here, is that a voice-only plan might save you
> >> some money?
>
> >>> 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.
>
> >> Can your "meteorological instrumentation" provide a BT link,
> >> instead? =A0I don't know how universal serial ports are on
> >> native phone hardware (iPhone, maybe?) so, otherwise, you
> >> might have to use USB<->serial.
>
> 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.

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.

>
> > Most Android serial ports are connected to blue tooth module (for
> > audio only). =A0There are no external serial ports.
>
> > Most Android USB ports are device mode. =A0Device mode USB2Serial are
> > usually custom product, like ours.
>
> I just read that Android 3 supports USB host mode. Don't know if any
> phones have that version yet.

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

On 10/10/2011 11:48 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?
>
> Possible, but not what I was thinking.

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!)

>> 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*)
>
> I don't have anything selected yet. There seems to be a good selection
> of kits.

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

>> 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!
>
> Depending on how it turns out, I might post the source and instructions.
> Don't think it's worth trying to sell.

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.