[Ovmsdev] some partial success

Nikolay Shishkov nshishkov at yahoo.com
Thu Jan 3 02:28:14 HKT 2013


Hi Michael,
I must have missed the vehicle_overlay_data - thanks for pointing out this.
I did a very simple test - I copied all the twizy code, change the variable names in a very ugly and temporary way - so can_soc is changed to 
unsigned int can_2_soc2; 
Then I changed the CAN filter 2 to look like this:
    RXF2SIDH = 0b01100000;
    RXF2SIDL = 0b00000000;

And then in the canfilter2 case and the 0x01 subcase (corresponding to 0x301 - I hope) I try to get the can_2_soc2 value as follows:

            can_2_soc2 = ((unsigned int) can_databuffer[4] << 8) + can_databuffer[5];
Initially I got the 5th and 6th array elements, but noticed that I had it wrong... so I changed to 4th and 5th... 

And finally at the debug sms handler:
    s = stp_i  ( s, " SOC=",   can_2_soc2 );

I changed the strings abit and can see that the new code is running, but do not understand how come a completely different values are reported - the value is from can_databuffer[5] and can_databuffer[6].
So the 301 contains the following bytes (viewed with PCAN) 00 00 0e 7d 01 b2 0a 4a. 
The SOC is supposed to be in 0E7D (actually it is the DOD), but I am getting the 0AB2 in the can_2_soc2 value.

I will try to upload some code tomorrow.
 

Thanks,
Nikolay



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

Nikolay,

see around line 231 for the #pragma udata overlay
    vehicle_overlay_data in the twizy module, and you're right, it's
    purpose is to save RAM, every vehicle module shall use it.

You normally only need to tell the CAN transceiver you're done
    reading the buffer, that's done by clearing RXB0CONbits.RXFUL in the
    poll() functions. A crash (overflow) of the transceiver is handled
    by the framework.

From your description my impression is you perhaps need to declare
    the status variable you're using as "volatile"? Remember, the poll()
    functions are interrupt code, and the compiler does some
    optimization. Btw: it's easier to help if you upload your code to
    github and include a link to it. Create some "temp" branch if you
    don't like to push preliminary code into the master branch.

There are currently no car_* variables for battery pack data, that's
    why I introduced them as can_* variables for the twizy. The voltages
    are stored in the battery_* structs, the power in can_power etc.,
    maybe you can use a similar scheme.

Regards,
Michael



Am 02.01.2013 15:41, schrieb Nikolay Shishkov:

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
>
>
>
>
>
>_______________________________________________
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/ec6cbe95/attachment.htm>


More information about the OvmsDev mailing list