[Ovmsdev] some partial success

Thu Jan 3 02:24:28 HKT 2013

Nikolay,

btw, there's a more detailed HOWTO on the server in "docs":

https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/HOWTO.server.txt

Regards,
Michael


Am 02.01.2013 11:43, schrieb Michael Balzer:
> 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
>
>
> _______________________________________________
> 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/bd1812ef/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130102/bd1812ef/attachment-0002.vcf>