[Ovmsdev] some partial success

Thu Jan 3 07:23:13 HKT 2013

Nikolay,

you normally only need "volatile" if there are concurrent reads & writes 
from tasks and/or interrupts to variables. All reads and writes up to 
word size (= 2 byte = int) can be considered atomic on the PIC18, and 
can_soc will only be written to by the IRQ and read from by the high 
level functions, so you normally won't need "volatile" on the can_soc 
variable alone.

New guess: you said you're using filter #2 for 0x30* msg ids, and 
changed my can_soc reader -- now, my can_soc reader happens to be 
located in poll0(), which is assigned to buffer #0 = filters #0 & #1. 
For filter #2 you'd need to use buffer #1 and accordingly poll1(). Did 
you change the code accordingly for that setup?

"Internal" means "in the OVMS module". If your car does not provide GPS, 
you can use the OVMS GPS by enabling both the compiler switch 
"OVMS_INTERNALGPS" and the net_fnbits (exactly as the twizy module 
does). You'll also need an active GPS antenna, a simple one will do 
perfectly, but take care it will run on 3 V (some older/special ones 
only run on 5 V). Also be aware that the internal GPS will raise the 
OVMS current needs to about 110 mA = about 34 Wh/day or 1 kWh/month -- 
should be no problem with frequent car use & charging though.

SMS commands and replies do not go through the OVMS server but are 
exchanged directly between mobile phone and OVMS module. The server is 
solely responsible for the IP connectivity (MSG commands). Primary tool 
for debugging is the DIAG port and mode, please read 
"docs/Firmware-Development.odt" for instructions on how to use that.

The currently available Android App does not yet support arbitrary MSG 
commands (I think the iOS one does, but can't test that). If you want to 
send your own MSG commands to your live module, you can also use the 
perl client for that: 
https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/server/client_app.pl

You need to change the passwords (line 11+12) and the car id (line 41 
"TESTCAR") in the .pl file. Then you can send a command like this, for 
example before entering the receive loop:

my $encrypted = encode_base64($txcipher->RC4("MP-0 C32,RT-GPS-Log"),'');
print STDERR "  Sending message $encrypted\n";
print $sock "$encrypted\r\n";

This for example will send command 32 (C32 = retrieve historical data) 
to the module with argument "RT-GPS-Log". The result will be printed on 
stdout by the receive loop.

Regards,
Michael

Am 02.01.2013 20:48, schrieb Nikolay Shishkov:
> Michael,
>
> I have had some conflicting experiences with CAN bus, and have learned 
> the lesson to test where the values are and take it from there. This 
> is why I actually used the car_linevoltage and car_charging current 
> variables and put the can_buffer bytes 0,1,2,3 in them to see what am 
> I getting... and the result was zeros. While the 4 and 5 are getting 
> the old value.
> It almost seems like the CAN bus registers are not written when I am 
> reading them. And the can_2_soc2 variable is just getting its value 
> from the same memory location as last time... although it should have 
> been initialized.
>
> Do the can_soc variable need to be declared as "volatile"?
>
> What is "internal" GPS? Is it internal to the car? Or internal to the 
> OVMS module? What should be the setting if there is no GPS coordinates 
> reported on the CAN bus?
>
> Can I see my debug commands (like when I send DEBUG SMS) from the 
> openvehicle.com server? Or I need the android app for that?
>
> Thanks,
> Nikolay
>
>
>
> ------------------------------------------------------------------------
> *From:* Michael Balzer <dexter at expeedo.de>
> *To:* ovmsdev at lists.teslaclub.hk
> *Sent:* Wednesday, January 2, 2013 8:34 PM
> *Subject:* Re: [Ovmsdev] some partial success
>
> Nikolay, Mark,
>
> Am 02.01.2013 19:28, schrieb Nikolay Shishkov:
>>
>>     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 don't know PCAN, but the CAN byte numbering normally begins at 0 on 
> the left, so 0e in your example is can_databuffer[2] and 7d is ...[3].
>
> If you get 0AB2, that would be [6][5] = your initial code?
>
> Btw: we could solve variable name conflicts between vehicle modules by 
> introducing some namespace prefix (replacing "can_") like Mark already 
> did for the functions. I'd shorten that for vars to e.g. "vrt_" for 
> "vehicle renault twizy", accordingly "vtc_" for the Think and so on. 
> OK, Mark?
>
> Regards,
> Michael
>
> -- 
> 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
> 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/20130103/f43dc760/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/20130103/f43dc760/attachment-0002.vcf>