[Ovmsdev] some partial success

Nikolay Shishkov nshishkov at yahoo.com
Wed Jan 2 22:41:02 HKT 2013


Thanks for all the advice!

After I issued the MODULE command, I was able to get results from my code.
So to the next problem.
I changed one of the CAN filters to match a 0x30? message, and then in a switch run a piece of code for message 0x301. This code should extract data from the 8 bytes of the CAN message. 
The thing is - the result from the extraction was ok the first couple of times, and since then no matter how I update the expression to fetch the value I get exactly the same value as before... 
So I wonder - have I crashed the CAN bus transceiver? Do I need to supply a confirmation, that I handle the message or is this handled by the framework?
Or is this something to do with saving variables in a place where suddenly I can not write anymore?

Also - the volt/ampera and the tesla files have 
#pragma udata overlay vehicle_overlay_data
As I understand to reduce RAM usage, while the twizy file does not... I added it to my Think file, but am not sure - could that have messed up the stuff?

What is the correct car_* variable to put the pack voltage and pack current in?

Thanks again,
Nikolay


________________________________
 From: Michael Balzer <dexter at expeedo.de>
To: ovmsdev at lists.teslaclub.hk 
Sent: Wednesday, January 2, 2013 11:43 AM
Subject: Re: [Ovmsdev] some partial success
 

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>
>>To: 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 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
>>
>>
>>
_______________________________________________
>>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
>
>
>
>
>
>_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130102/d726a280/attachment.htm>


More information about the OvmsDev mailing list