[Ovmsdev] some partial success

Wed Jan 2 18:43:53 HKT 2013

Nikolay,

the documentation needs some updates, the vehicle 
type parameter is new.

Easiest GPRS test is done by using the standard 
server and the iOS or Android App.

To set up your own OVMS server, you need a public 
IP, a mysqld and perl. See "server" directory in 
the git repository.

Set up some mysql schema e.g. "ovms" and access, 
prime the schema using "mysql ovms < 
ovms_server.sql" and change "ovms_server.conf" 
accordingly.

To be able to connect your module, manually add an 
entry to the ovms_cars table like this:

insert into ovms_cars set vehicleid='...', 
carpass='...', userpass='...', changed=now();

The server is started by "./ovms_server.pl" (or 
"perl ovms_server.pl" if non-UNIX). Configure your 
module using "GPRS" and "SERVER" and you should 
see log output from the server (stdout).

It's best to start without paranoid mode, so you 
can read what's happening.

Btw: I had trouble with my first SIM card as well 
in the beginning. That was network/provider 
related, after letting the module on for some 
hours, the GPRS registration suddenly succeeded 
and has been quick + stable since.

Regards,
Michael

Am 02.01.2013 10:05, schrieb Nikolay Shishkov:
> Thanks Mark,
> Looking at the code the VEHICLE TYPE is the 4th 
> parameter of the MODULE command.
> I will test this today and report back.
> I was looking at the user guide for Tesla and 
> the MODULE command has listed 3 parameters...
>
> I forgot to mention that I tested 2 different 
> sim cards in Sweden:
>  1- mini sim format (like iphone 4) with 
> adapter, operator 3 - did not work, the error 
> code is blinking too fast for me to reliably 
> count it.
>  2 - standard sim format, operator telia - 
> worked for sms
>
> Still haven't tested the gprs function. Any good 
> advice on how to test the GPRS function - can I 
> setup a simple server to just register the 
> incoming messages?
>
> Nikolay
>
> --------------------------------------------------
> *From:* Mark Webb-Johnson <mark at webb-johnson.net>
> *To:* OVMS Developers <ovmsdev at lists.teslaclub.hk>
> *Sent:* Wednesday, January 2, 2013 2:28 AM
> *Subject:* Re: [Ovmsdev] some partial success
>
> Nikolay,
>
>> Unfortunately it did not seem to work. On STAT 
>> request the response was generated from the 
>> net_sms code and not my new code for the Think EV.
>
> So long as you've registered the hook correctly, 
> it should work. Are you sure you set the module 
> correctly to TC so your vehicle module is the 
> one actually used? This is the SMS MODULE 
> command (I think it is the last parameter).
>
> You can SMS PARAMS? or MODULE? to see what 
> parameters are set.
>
>> Also - what are the capabilities used for?
>> What does "C6,C200-207" mean? I get the 200 to 
>> 207 are the extra commands but how are they 
>> plugged to the rest of the code?
>
> This is a new v2.x thing, used to tell the App 
> what the capabilities of the vehicle module are. 
> We don't use it at the moment, but plan to use 
> this in the app code in order to customise the 
> functions and appearance on a per-vehicle-module 
> basis. For example, if the vehicle module is 
> able to support a lock/unlock command, the 
> capabilities will tell the Apps that, and the 
> apps can update the UI appropriately.
>
>> f I reprogram the board, do I need to restart 
>> it somehow? Or is it enough to just reprogram 
>> it from the mplab x and the board will restart?
>
> The board will restart automatically after being 
> programmed by MPLAB-X. If you want to restart 
> it, you can also SMS RESET or just pull the power.
>
> Regards, Mark.
>
> On 2 Jan, 2013, at 9:22 AM, Nikolay Shishkov wrote:
>
>> A quick report.
>> I manged to flash the firmware and register a 
>> phone.
>> I also started on a Think EV file based on the 
>> Twizy one. I setup the CAN filters and changed 
>> the code to handle a state of charge message.
>> Unfortunately it did not seem to work. On STAT 
>> request the response was generated from the 
>> net_sms code and not my new code for the Think EV.
>>
>> On checking the code all seems fine - my stat 
>> function was plugged correctly.
>>
>> I will continue tomorrow, but wanted to ask if 
>> anyone has good ideas to try?
>>
>> Also - what are the capabilities used for?
>> What does "C6,C200-207" mean? I get the 200 to 
>> 207 are the extra commands but how are they 
>> plugged to the rest of the code?
>>
>> If I reprogram the board, do I need to restart 
>> it somehow? Or is it enough to just reprogram 
>> it from the mplab x and the board will restart?
>>
>> Any help is appreciated,
>> Nikolay
>>
>>
>> --------------------------------------------------
>> *From:* Michael Balzer <dexter at expeedo.de 
>> <mailto:dexter at expeedo.de>>
>> *To:* ovmsdev at lists.teslaclub.hk 
>> <mailto:ovmsdev at lists.teslaclub.hk>
>> *Sent:* Tuesday, January 1, 2013 9:37 PM
>> *Subject:* Re: [Ovmsdev] sprintf / crashes
>>
>> Mark,
>>
>> transparent chunk splitting seems to be 
>> non-trivial, so I split my data transfers. 
>> Everything's working fine again, so I'll merge 
>> into the master next if you don't object.
>>
>> Btw, AT+CIPSEND? gave me 1460 bytes, so that's 
>> supposed to be the size limit we should keep in 
>> mind until we find a better solution.
>>
>> @Nikolay: please note, that's the total size 
>> that can be sent within one net_msg_start() ... 
>> net_msg_send(), the buffer size 
>> (net_scratchpad) further limits a single MSG 
>> line to currently 199 bytes max.
>>
>> Regards,
>> Michael
>>
>>
>> Am 31.12.2012 16:23, schrieb Michael Balzer:
>>> Mark,
>>>
>>> I think I found my link dropping problem: 
>>> scanning a diag log I took, I found out 
>>> CIPSEND will fail with a plain "ERROR" if the 
>>> data size exceeds about 1500 bytes. I guess 
>>> that's either the SIM908 buffer size or the 
>>> max network packet size. I thought the SIM908 
>>> would handle dividing data into packets as 
>>> needed. The SIM908 manual mentions the max 
>>> packet size depends on network status and 
>>> should be queried by "AT+CIPSEND?". After the 
>>> overrun net_state_activity() will not 
>>> recognize "ERROR" to terminate the pending 
>>> msg, so will run into the timeout and start a 
>>> network re-init.
>>>
>>> My battery status data exceeds 1500 bytes on 
>>> first run and later on if enough cells need 
>>> updates. I'll think about how to split up data 
>>> packets into multiple CIPSENDs. Would be nice 
>>> if the net functions take care of this 
>>> transparently.
>>>
>>> A secondary issue turned up from the diag log: 
>>> the SIM908 crashed in the middle of a CIPSEND 
>>> command while the module continued to run 
>>> normally. The module still thought it's in 
>>> NET_STATE_READY, so did not re-initalize the 
>>> modem. The connection could then be 
>>> established on the next CIPSTART, but the 
>>> complete INIT stuff had not been done. So it 
>>> seems independant SIM908 resets need to be 
>>> handled as well, and they can occur anytime. 
>>> I'll see if I can solve that too.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 30.12.2012 15:42, schrieb Michael Balzer:
>>>> I hesitate to merge into the master because I 
>>>> currently have link / connectivity problems, 
>>>> especially during driving. I introduced a GPS 
>>>> logging to optimize my antenna positions and 
>>>> managed to get some really nice tracks three 
>>>> days ago, so I don't think this is related to 
>>>> my changes... but I'm not 100% sure. I tried 
>>>> different antenna positions and another GSM 
>>>> network, but the connection keeps dropping 
>>>> when moving the car, and GPS position updates 
>>>> need minutes. Could be weather conditions 
>>>> ...or some tricky race condition bug?
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk  <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk 
>> <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk 
>> <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk 
> <mailto: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

-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130102/cb2141ef/attachment.htm>