[Ovmsdev] module GPRS connection frequency

Tue Nov 11 12:10:23 HKT 2014

Thanks for your reply, Mark.

As for the SMS messages... couldn't the app simply tie-into the phone's 
own SMS features?  So the SMS is sent from the phone and not from the 
server.  Granted... not all compatible devices are phones, but at least, 
then, the cost and ability to use the feature is put into the hands of 
the user and does not burden the server operators.

For the SIM cards, I'm using the AT&T "GoPhone" plans which, basically 
are $100 per-year if the usage is low-enough.  That's $8/mo.  However, 
the usage isn't low-enough because of the frequent GPRS 
disconnects/reconnects.  I appear to be running at about double the 
expected cost.

For users in the US, I would be happy to know of a better (lower-cost 
and reliable) alternative.

Thanks,

Lee.

On 11/10/2014 05:50 PM, Mark Webb-Johnson wrote:
> Lee,
>
> We can (technically) actually do this from the server. The issue is the lack of business model to support it.
>
> With users buying their own SIM cards and paying for their own SMS and data plans, things are simple. If we start having to pay for a large number of SMS messages server->car, that isn't going to work out.
>
> Some interesting numbers on the SMS provisioning system that we run. We do this free-of-charge, but ask for sponsorship. Currently, it runs approximately break-even (I had to sponsor quite a few top-ups at the start, but haven't had to pay anything extra in the past year, as sponsorships cover it - just). For every 1 sponsor, there are approximately 5 users not paying at all. At break-even, that means 1 in 6 are paying 6 times more than they personally use, and 5 in 6 are paying zero. I guess that is human nature, and so long as I don't end up personally paying I guess I don't mind too much, but that model definitely wouldn't work if using SMS from the server for wake-up. The other issue is that both ends pay, and that can end up pricey.
>
> Technically, I hate wake-up. It is messy and slow. It is also the thing most users of the vehicle's own telemetry system complain about (and perhaps complain about most). The modems can go into a low-power state and in that state GPRS won't work but they can still receive USSD and SMS messages. The wake up involves establishing a GPRS session, then bringing up a TCP/IP connection over that, and can take a while.
>
> A very good alternative is pure USSD. That is free, very reliable, but (a) kludgy and liable to pissing off the cellular providers as it is not intended to be used for what we need it for, and (b) kind of pricey at the moment (perhaps US$8 a month, which is more than most OVMS users are paying). But, it is low-powered, fast, flat-rate, globally roaming, and doesn't require GPRS at all.
>
> Regards, Mark.
>
> On 8 Nov, 2014, at 5:33 am, Lee Howard <lee.howard at mainpine.com> wrote:
>
>> For what it's worth...
>>
>> Even if app-to-module features existed for my vehicles (VA and XX), I believe that my SIM card costs would be significantly less if app-to-module commands (lock, preheat, etc.) were sent only by SMS text and not via internet - AND - the module-to-server communications were limited to regular/periodic times only when the status has changed.  The app-to-module features would be used relatively infrequently.
>>
>> I recognize that diverges considerably from the operational design of OVMS, and I don't necessarily expect anything to be done about it.  I'm just saying it, though, to have it out there.
>>
>> Thanks,
>>
>> Lee.
>>
>>
>> On 10/29/2014 10:06 AM, Lee Howard wrote:
>>> I understand.  Thank-you for the clue-stick.
>>>
>>> In my situation - VA and XX - there is no functionality (yet) for the App to send anything useful to the car.  I can't lock/unlock the doors, start pre-conditioning, or tell auto-pilot to drive the car to my location.  So, for all intents and purposes OVMS serves as a one-way street of information flowing from the module to the app and not the other way 'round.
>>>
>>> Especially in the case of XX (GPS only) there is no need to update the server when the car can be determined to have been stationary.
>>>
>>> I suppose, though, that your response is what I needed to know: this is not configurable.
>>>
>>> Thanks,
>>>
>>> Lee.
>>>
>>>
>>> On 10/27/2014 06:59 PM, Mark Webb-Johnson wrote:
>>>> Lee,
>>>>
>>>> The GPRS connection is different from the server connection.
>>>>
>>>> Think of GPRS like a VPN. The OVMS firmware tries to keep GPRS open at all times. If a GPRS connection fails to be established, it backs-off for 15 seconds and tries again, then 30 seconds, then 45 seconds, etc, etc, up to 150 seconds. Normally, cellular providers charge for data transferred within the GPRS session, and often they round it up to the nearest 1KB, 100KB or 1MB. If you establish a GPRS session, then it is lost, you get charged the minimum.
>>>>
>>>> What pisses me off is that in 99.999% of the cases, the cause of the loss of GPRS session is the cellular provider's crappy cellular network. OVMS only purposely disconnects a GPRS session when (a) the GPRS parameters are changed, or (b) the box is turned off. All the other disconnections are because of the cellular provider's network.
>>>>
>>>> Once a GPRS connection is established, OVMS will try to establish a TCP/IP connection over GPRS, to the server. Once that is established, OVMS will attempt to keep the server updated with the vehicle status (once every ten minutes while idle, once every minute while an App is connected). Checksums are used to only send changed data (which further reduces data charges).
>>>>
>>>> This constant connection is necessary so that the OVMS module is always-on ready for an App to connect to it. Again, due to the cellular provider's arrangements of using private IP address spaces and NAT, the OVMS module cannot normally be contacted by the server. Instead, the module has to establish and maintain a TCP/IP connection to the server, and the server talk back to the module over that connection.
>>>>
>>>> Regards, Mark.
>>>>
>>>> On 28 Oct, 2014, at 5:17 am, Lee Howard <lee.howard at mainpine.com> wrote:
>>>>
>>>>> For those of you using unlimited data plans this may not matter, but for those of us using per-use/per-minute/per-MB plans the frequency at which the OVMS module connects via GPRS to the OVMS server is quite relevant for the long-term cost of using OVMS.
>>>>>
>>>>> For example, I'm using AT&T "GoPhone" per-minute plans which basically result in a $0.01 charge every time the OVMS module connects via GPRS to the OVMS server.  The OVMS module does this a bit more-frequently than I had anticipated... about 3X more frequently.  Consequently, I was a bit surprised to find what I had hoped to be a $100-per-year account get used faster than that... requiring me to add $100 to the account every four months or so.  So the per-minute/per-use/per-MB plan I'm on ends up not really being less-expensive than their $25 per-month plan.
>>>>>
>>>>> I see that the OVMS module is connecting with the OVMS server roughly every 7 minutes... even if the car is stationary and there have been no changes to SOC or other vehicle information.  I see this behaviour both with module type "VA" and "XX".
>>>>>
>>>>> I would prefer to see the OVMS module connect with the server with *greater* regularity (like, every 2 minutes) when GPS position is changing (more than the expected 60-meter or so "jitter" that I usually see) or when SOC is changing or some other information changes.  However, if the vehicle is stationary and there are no SOC changes or other information changes, then I would prefer to see the OVMS module connect to the OVMS server very infrequently... like only every 30-90 minutes.
>>>>>
>>>>> Is this, by chance, something configurable?  Or is this something that I'm going to need to build-into the firmware, myself?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Lee.
>>>>>
>>>>> -- 
>>>>> *Lee Howard*
>>>>> *Mainpine, Inc. Chief Technology Officer*
>>>>> Tel: +1 866 363 6680 | Fax: +1 360 462 8160
>>>>> lee.howard at mainpine.com | www.mainpine.com
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>
>>
>> -- 
>> *Lee Howard*
>> *Mainpine, Inc. Chief Technology Officer*
>> Tel: +1 866 363 6680 | Fax: +1 360 462 8160
>> lee.howard at mainpine.com | www.mainpine.com
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>

-- 
*Lee Howard*
*Mainpine, Inc. Chief Technology Officer*
Tel: +1 866 363 6680 | Fax: +1 360 462 8160
lee.howard at mainpine.com | www.mainpine.com