OK. I'll handle this over the weekend. On 5 Dec, 2012, at 3:43 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

that's an even better idea, reduces server complexity as no type switch will be needed.

Just one addition: to be able to store and retrieve multiple records within one type (e.g. multiple cells for type "cell data"), an "address" or "recno" field could be added after the type. That would be part of the primary key, so the server ensures there's at most one record no. x of type y.

I think that's necessary to keep the xfer data volumes low, otherwise all blob data of a type would need to be updated if just a part of it changes.

So that would be: MP-0 H,<type>,<recno>,<lifetime>,<data> type (integer type code) recno (integer record number) lifetime (storage lifetime requested, in seconds) data (a blob of data to be dealt with by the application however it wants)

For general purpose type codes, maybe some classification scheme would make sense? Maybe adopt some standard scheme already defined for automotive data? ...if there is one...

Regards, Michael

Am 04.12.2012 06:14, schrieb Mark Webb-Johnson:

...

Michael,

I really like this, but think it best to use a generic message type for historical data that can be supported in the server, and retrieved from the clients in a standardised way.

Perhaps just:

MP-0 H,<type>,<lifetime>,<data> type (integer type code) lifetime (storage lifetime requested, in seconds) data (a blob of data to be dealt with by the application however it wants)

We can maintain a registry of 'types' - as they are just numbers, they can be vehicle specific, or general purpose.

The server could then just store that in a special table. It can timestamp it when it receives the data, and generate an expiry date based on NOW()+<lifetime-seconds>, so that it can be auto-purged. It would be keyed by the vehicleid, type, and timestamp.

So, not using carmessages, but cardata (or something like that).

For access, we can just use the existing command/response functions (C/c).

Does that make sense? If so, I can get server support for this quite easily and quickly?

Regards, Mark.

On 2 Dec, 2012, at 4:00 AM, Michael Balzer wrote:

...

Hi Mark,

this is my first draft of a battery data protocol as implemented in the Twizy module 2.0 (see vehicle_twizy_battstatus_msgp()).

For each battery pack (min 1), a message of type "B" transports the current state and collected min/max values:

// Output pack status: // MP-0 B,<packnr>,<nr_of_cells> // ,<volt_alertstatus>,<temp_alertstatus> // ,<soc>,<soc_min>,<soc_max> // ,<volt_act>,<volt_act_cellnom> // ,<volt_min>,<volt_min_cellnom> // ,<volt_max>,<volt_max_cellnom> // ,<temp_act>,<temp_min>,<temp_max>

The units now are 1/100 % for the SOCs, 1/100 V for the voltages and 1 °C for the temperatures. Maybe floats are more readable / standard for SOC & V?

Alert status are enums of... 0 = unknown 1 = nominal 2 = suspicious 3 = alert 4 = fail

For each cell in each pack, a message of type "H" transports the cell details accordingly:

// Output cell status: // MP-0 H,<packnr>,<cellnr> // ,<volt_alertstatus>,<temp_alertstatus>, // ,<volt_act>,<volt_min>,<volt_max>,<volt_maxdev> // ,<temp_act>,<temp_min>,<temp_max>,<temp_maxdev>

Numbering of packs and cells begins at "1" to reserve "0" for an "all" selector. Alert status uses the same enum scheme as on the pack level. Voltages on the cell level are in unit mV, temperatures in °C. The maximum deviations are signed to reflect the direction of the deviation.

Of course, a cell need not be a physical cell, it's just the smallest monitorable unit in a pack. Monitoring huge packs will not be possible with the current OVMS hardware, unless we consider streaming all sensor data to the server.

I thought about how much could be stored in the server now and had a first look at the current server implementation. The primary key of table "ovms_carmessages" would need to be changed, as it currently is bound to just the message type character (and also case insensitive, reducing the number of possible message types). The key would need to be extended by the packnr on "B" messages and the pack + cellnr on "H" messages.

So, generally speaking, we could introduce 2-3 key extension columns that can be used dynamically based on the message type. That would also enable storing of other historical records. To keep the database clean, an expire mechanism could drop all rows older than e.g. 24 hours.

Please comment.

Regards, Michael

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

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

The coding looks good, and sensible. How about we just make it a text string, rather than integer. Much clearer to read, and almost no impact on size. VV.C.P VV the normal vehicle types, or '*' for generic. C your class P your property On 15 Dec, 2012, at 6:53 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark, List,

Am 04.12.2012 20:43, schrieb Michael Balzer:

...

type (integer type code) For general purpose type codes, maybe some classification scheme would make sense? Maybe adopt some standard scheme already defined for automotive data? ...if there is one...

It seems there is none suitable, so here's my attempt at defining one. Please comment.

Regards, Michael

Type classification scheme: id size: 32 bit integer

Generic / standard props:

0x 0000 C PPP

Vehicle specific props:

0x VVVV C PPP

VVVV = Vehicle ID 0001 = Tesla Roadster 0002 = Tesla Model S 0003 = GM Volt / Opel Ampera 0004 = Renault Twizy ...

C = Class:

...main classes:

0 = Power 1 = Engine 2 = Transmission 3 = Chassis 4 = Body 5 = Electrics

...auxiliary classes?

6 = Safety (Chassis, Body, Electrics) 7 = Security (Power?, Body, Electrics) 8 = Comfort (Chassis, Body, Electrics) 9 = Entertainment (Body, Electrics) a = Communication (Body, Electrics)

b = reserved c = reserved d = reserved e = reserved f = reserved

PPP = Property ...allowing for 4096 properties per class.

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Too fast... regarding the class definitions, to achieve readability here as well I would then suggest using a 3 letter abbreviation. ...main classes: Power PWR Engine ENG Transmission TRX Chassis CHS Body BDY Electrics ELC ...auxiliary classes? Safety SAF (Chassis, Body, Electrics) Security SEC (Power?, Body, Electrics) Comfort CMF (Chassis, Body, Electrics) Entertainment ENT (Body, Electrics) Communication COM (Body, Electrics) Also I would prefer "-" as a separator over ".". For my current application (battery pack + cell data), that would result in type codes... RT-PWR-BattPack RT-PWR-BattCell ...or general form *-PWR-BattPack *-PWR-BattCell Btw: general purpose codes could be written without "*-" prefix as well? That would be... PWR-BattPack PWR-BattCell Regards, Michael Am 15.12.2012 12:01, schrieb Michael Balzer:

Silly me just assumed you'd prefer integer... I'm using text codes in my own DB designs whenever possible due to readability.

In other words: of course! :-)

I'll modify my code now accordingly.

Am 15.12.2012 11:48, schrieb Mark Webb-Johnson:

...

The coding looks good, and sensible.

How about we just make it a text string, rather than integer. Much clearer to read, and almost no impact on size.

VV.C.P

VV the normal vehicle types, or '*' for generic. C your class P your property

On 15 Dec, 2012, at 6:53 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

...

Mark, List,

Am 04.12.2012 20:43, schrieb Michael Balzer:

...

o type (integer type code)

For general purpose type codes, maybe some classification scheme would make sense? Maybe adopt some standard scheme already defined for automotive data? ...if there is one...

It seems there is none suitable, so here's my attempt at defining one. Please comment.

Regards, Michael

Type classification scheme: id size: 32 bit integer

Generic / standard props:

0x 0000 C PPP

Vehicle specific props:

0x VVVV C PPP

VVVV = Vehicle ID 0001 = Tesla Roadster 0002 = Tesla Model S 0003 = GM Volt / Opel Ampera 0004 = Renault Twizy ...

C = Class:

...main classes:

0 = Power 1 = Engine 2 = Transmission 3 = Chassis 4 = Body 5 = Electrics

...auxiliary classes?

6 = Safety (Chassis, Body, Electrics) 7 = Security (Power?, Body, Electrics) 8 = Comfort (Chassis, Body, Electrics) 9 = Entertainment (Body, Electrics) a = Communication (Body, Electrics)

b = reserved c = reserved d = reserved e = reserved f = reserved

PPP = Property ...allowing for 4096 properties per class.

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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@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

This has been completed, and is now live on both tmc and development OVMS servers. Server identifies itself as 2.1.1-20121216. It was implemented in three places: A new "H" record type - not stored in the carmessages table, but inserted with a timestamp into historicalmessages. A new command 31 - retrieving a summary of what historical data the server has for the vehicle. A new command 32 - retrieving detailed historical data records of the specified type. I haven't implement data expunging yet. It is actually a one-liner, but I've left it out on purpose, since I want to see what data is added to make sure everything works correctly. Michael: Can you try to send your battery data with this new "H" type, and let me know when done so I can check server storage. It is a pretty simple change to the sample client_app.pl code to retrieve the summary and/or detailed historical records, if you want to see for yourself. Regards, Mark. On 16 Dec, 2012, at 10:28 AM, Mark Webb-Johnson wrote:

Ok.

But, lets keep the *- prefix for generic. Easier to split the fields later in the database, and only 2 bytes extra per record.

I'll try to get the server side of this done today.

Regards, Mark

On 15 Dec, 2012, at 7:19 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Too fast... regarding the class definitions, to achieve readability here as well I would then suggest using a 3 letter abbreviation.

...main classes:

Power PWR Engine ENG Transmission TRX Chassis CHS Body BDY Electrics ELC

...auxiliary classes?

Safety SAF (Chassis, Body, Electrics) Security SEC (Power?, Body, Electrics) Comfort CMF (Chassis, Body, Electrics) Entertainment ENT (Body, Electrics) Communication COM (Body, Electrics)

Also I would prefer "-" as a separator over ".".

For my current application (battery pack + cell data), that would result in type codes...

RT-PWR-BattPack RT-PWR-BattCell

...or general form

*-PWR-BattPack *-PWR-BattCell

Btw: general purpose codes could be written without "*-" prefix as well? That would be...

PWR-BattPack PWR-BattCell

Regards, Michael

Am 15.12.2012 12:01, schrieb Michael Balzer:

...

Silly me just assumed you'd prefer integer... I'm using text codes in my own DB designs whenever possible due to readability.

In other words: of course! :-)

I'll modify my code now accordingly.

Am 15.12.2012 11:48, schrieb Mark Webb-Johnson:

...

The coding looks good, and sensible.

How about we just make it a text string, rather than integer. Much clearer to read, and almost no impact on size.

VV.C.P

VV the normal vehicle types, or '*' for generic. C your class P your property

On 15 Dec, 2012, at 6:53 AM, Michael Balzer <dexter@expeedo.de> wrote:

...

Mark, List,

Am 04.12.2012 20:43, schrieb Michael Balzer:

...

type (integer type code) For general purpose type codes, maybe some classification scheme would make sense? Maybe adopt some standard scheme already defined for automotive data? ...if there is one...

It seems there is none suitable, so here's my attempt at defining one. Please comment.

Regards, Michael

Type classification scheme: id size: 32 bit integer

Generic / standard props:

0x 0000 C PPP

Vehicle specific props:

0x VVVV C PPP

VVVV = Vehicle ID 0001 = Tesla Roadster 0002 = Tesla Model S 0003 = GM Volt / Opel Ampera 0004 = Renault Twizy ...

C = Class:

...main classes:

0 = Power 1 = Engine 2 = Transmission 3 = Chassis 4 = Body 5 = Electrics

...auxiliary classes?

6 = Safety (Chassis, Body, Electrics) 7 = Security (Power?, Body, Electrics) 8 = Comfort (Chassis, Body, Electrics) 9 = Entertainment (Body, Electrics) a = Communication (Body, Electrics)

b = reserved c = reserved d = reserved e = reserved f = reserved

PPP = Property ...allowing for 4096 properties per class.

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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@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 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

In general, I try to minimise stack and ram usage on the small PICs. Early on in OVMS, we had a bunch of local variables, and some were quite large. We were getting all sorts of random weird behavior (reboots, corrupt messages, etc). Since we changed to global variables, and very limited use of stacked function calls and local variables, things have been much better. I agree that a large sprintf may be the cause of your problems. Can you try to change to itoa() and strcat(), to see if it makes an impact? Regards, Mark. On 18 Dec, 2012, at 8:05 AM, Michael Balzer wrote:

Mark,

the client_app.pl hint was good, I had not recognized that as a server query utility yet.

I removed the comma (misread the draft) and can now see my H entries. However, that lead me back to my assumed connectivity issue:

MP-0 c31,0,2,6,RTPWR-BattCell,1,1,76,2012-12-17 23:18:43,2012-12-17 23:18:43 MP-0 c31,0,3,6,RT-PWR-BattCell,14,16,1215,2012-12-17 23:13:11,2012-12-17 23:18:43 MP-0 c31,0,4,6,RT-PWR-BattC�ll,1,1,65,2012-12-17 23:18:43,2012-12-17 23:18:43 MP-0 c31,0,5,6,RT-PWR-BattPack,1,2,202,2012-12-17 23:13:11,2012-12-17 23:18:43 MP-0 c31,0,6,6,RT-PWR-Usag,1,1,45,2012-12-17 23:13:11,2012-12-17 23:13:11

This C31 result shows all kinds of garbled chars in my module's messages, and even a truncation on "RT-PWR-UsageStats" (also missing parts on the data blob on that one).

Now that's a bit odd and most probably cannot be connected to a GPRS link failure -- as that would not garble single bytes in a TCP connection.

I could fix some similar output problems in DIAG mode more than once by reducing complex sprintf() calls, so I searched for C18 sprintf() stack usage and found nothing concrete, but many warnings about very high stack usage of the whole printf family, plus advice not to use them at all on small embedded systems. One source mentioned sprintf() will need 70+ bytes stack for a simple integer template.

I also have read a bit into the C18 software stack management and found my previous assumption to be correct: it's currently fixed to bank 12 (0xC00), so provides 256 bytes for any kind of parameter + local vars combination. I think sprintf() on a 256 byte stack could well be a source of problems... and stack overruns can produce weird effects, as those above. I think about rewriting all my sprintf calls to itoa/ltoa/ultoa, but find it strange they did no harm up to now, even with complex templates as in net_msgp_environment(). Or maybe they did, unrecognized?

Do you have some other info on C18 sprintf()? I'd rather avoid recoding every output without sprintf(), but that's my best bet currently...

Regards, Michael

Am 17.12.2012 07:37, schrieb Mark Webb-Johnson:

...

This has been completed, and is now live on both tmc and development OVMS servers.

Server identifies itself as 2.1.1-20121216.

It was implemented in three places:

A new "H" record type - not stored in the carmessages table, but inserted with a timestamp into historicalmessages. A new command 31 - retrieving a summary of what historical data the server has for the vehicle. A new command 32 - retrieving detailed historical data records of the specified type.

I haven't implement data expunging yet. It is actually a one-liner, but I've left it out on purpose, since I want to see what data is added to make sure everything works correctly.

Michael: Can you try to send your battery data with this new "H" type, and let me know when done so I can check server storage.

It is a pretty simple change to the sample client_app.pl code to retrieve the summary and/or detailed historical records, if you want to see for yourself.

Regards, Mark.

On 16 Dec, 2012, at 10:28 AM, Mark Webb-Johnson wrote:

...

Ok.

But, lets keep the *- prefix for generic. Easier to split the fields later in the database, and only 2 bytes extra per record.

I'll try to get the server side of this done today.

Regards, Mark

On 15 Dec, 2012, at 7:19 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Too fast... regarding the class definitions, to achieve readability here as well I would then suggest using a 3 letter abbreviation.

...main classes:

Power PWR Engine ENG Transmission TRX Chassis CHS Body BDY Electrics ELC

...auxiliary classes?

Safety SAF (Chassis, Body, Electrics) Security SEC (Power?, Body, Electrics) Comfort CMF (Chassis, Body, Electrics) Entertainment ENT (Body, Electrics) Communication COM (Body, Electrics)

Also I would prefer "-" as a separator over ".".

For my current application (battery pack + cell data), that would result in type codes...

RT-PWR-BattPack RT-PWR-BattCell

...or general form

*-PWR-BattPack *-PWR-BattCell

Btw: general purpose codes could be written without "*-" prefix as well? That would be...

PWR-BattPack PWR-BattCell

Regards, Michael

Am 15.12.2012 12:01, schrieb Michael Balzer:

...

Silly me just assumed you'd prefer integer... I'm using text codes in my own DB designs whenever possible due to readability.

In other words: of course! :-)

I'll modify my code now accordingly.

Am 15.12.2012 11:48, schrieb Mark Webb-Johnson:

...

The coding looks good, and sensible.

How about we just make it a text string, rather than integer. Much clearer to read, and almost no impact on size.

VV.C.P

VV the normal vehicle types, or '*' for generic. C your class P your property

On 15 Dec, 2012, at 6:53 AM, Michael Balzer <dexter@expeedo.de> wrote:

> Mark, List, > > Am 04.12.2012 20:43, schrieb Michael Balzer: >> type (integer type code) >> For general purpose type codes, maybe some classification scheme would make sense? Maybe adopt some standard scheme already defined for automotive data? ...if there is one... > > It seems there is none suitable, so here's my attempt at defining one. Please comment. > > Regards, > Michael > > > Type classification scheme: > id size: 32 bit integer > > Generic / standard props: > > 0x 0000 C PPP > > Vehicle specific props: > > 0x VVVV C PPP > > VVVV = Vehicle ID > 0001 = Tesla Roadster > 0002 = Tesla Model S > 0003 = GM Volt / Opel Ampera > 0004 = Renault Twizy > ... > > C = Class: > > ...main classes: > > 0 = Power > 1 = Engine > 2 = Transmission > 3 = Chassis > 4 = Body > 5 = Electrics > > ...auxiliary classes? > > 6 = Safety (Chassis, Body, Electrics) > 7 = Security (Power?, Body, Electrics) > 8 = Comfort (Chassis, Body, Electrics) > 9 = Entertainment (Body, Electrics) > a = Communication (Body, Electrics) > > > b = reserved > c = reserved > d = reserved > e = reserved > f = reserved > > > PPP = Property > ...allowing for 4096 properties per class. > > > > > -- > Michael Balzer * Paradestr. 8 * D-42107 Wuppertal > Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 > <dexter.vcf> > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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@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 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Michael, I think our revisions overlapped. I'd just merged in all your previous changes, plus documentation and server code updates. I did make some minor layout fixes (where the indentation was wrong - I think you are using 4 spaces, or perhaps tabs, where the rest of the project uses 2). I also added your pseudo-command #6 to the protocol document. Can you merge in my changes, then re-push yours? I'd like to get this v2 branch complete today and merge back into master tonight (my time). Going forward, do you still want to maintain and work off your clone, or would it be easier if I just gave you write access to the main project? Your contributions are so helpful and good, that there is little I am having to do other than just accept them :-) For the watchdog reboot and occasional ram trashing, I too suspect the NET, NET_MSG or SMS code. It is the only place where things are externally controlled to result in variable length strings. I did review it a while ago, but didn't see anything obvious. The other possibility is sprintf() elsewhere in the code (such as STAT). Running v2.1.1 in my car, I have seen the firmware version go bizarre about a month ago: 2012-11-21 07:32:06.388834 -0500 info main: #74 C EV915 rx msg F 2.1.1/V2,SFZRE8B15B3000569,1,1,TR2N,3(2G) 2012-11-21 07:34:58.845568 -0500 info main: #61 C EV915 rx msg F 49.51.51/V2,SFZRE8B15B3000569,1,1,TR2N,3(2G) That is a sprintf(). Regards, Mark. On 20 Dec, 2012, at 9:13 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

I've rewritten all my sprintf() calls now. I introduced a new general string utils family to ease avoiding sprintf(), see my utils module addition.

I've had no garbled strings since and can now fetch all my history rows from the server, so it had some positive effect.

But the watchdog timeout reboots still occur, they still occasionally trash variables and I once still got the STKUNF flag from the reboot. That feels like some uninitialised pointer or writing beyond array / string bounds. I'm about to review the basic net code, if you've got an idea where to look first, tell me.

An example of the RAM trashing can still be seen on the server: MP-0 W17.4,8,17.4,8,17.4,8,17.4,8,-1 When that occured, a lot of other data was displayed wrong as well. The TPMS vars never get written to by the twizy module. The values 17.4 & 8 mean both car_tpms arrays had been filled completely with 0x30 or '8'. Does that ring a bell?

Regards, Michael

Am 18.12.2012 02:39, schrieb Mark Webb-Johnson:

...

In general, I try to minimise stack and ram usage on the small PICs.

Early on in OVMS, we had a bunch of local variables, and some were quite large. We were getting all sorts of random weird behavior (reboots, corrupt messages, etc). Since we changed to global variables, and very limited use of stacked function calls and local variables, things have been much better.

I agree that a large sprintf may be the cause of your problems. Can you try to change to itoa() and strcat(), to see if it makes an impact?

Regards, Mark.

On 18 Dec, 2012, at 8:05 AM, Michael Balzer wrote:

...

Mark,

the client_app.pl hint was good, I had not recognized that as a server query utility yet.

I removed the comma (misread the draft) and can now see my H entries. However, that lead me back to my assumed connectivity issue:

MP-0 c31,0,2,6,RTPWR-BattCell,1,1,76,2012-12-17 23:18:43,2012-12-17 23:18:43 MP-0 c31,0,3,6,RT-PWR-BattCell,14,16,1215,2012-12-17 23:13:11,2012-12-17 23:18:43 MP-0 c31,0,4,6,RT-PWR-BattC�ll,1,1,65,2012-12-17 23:18:43,2012-12-17 23:18:43 MP-0 c31,0,5,6,RT-PWR-BattPack,1,2,202,2012-12-17 23:13:11,2012-12-17 23:18:43 MP-0 c31,0,6,6,RT-PWR-Usag,1,1,45,2012-12-17 23:13:11,2012-12-17 23:13:11

This C31 result shows all kinds of garbled chars in my module's messages, and even a truncation on "RT-PWR-UsageStats" (also missing parts on the data blob on that one).

Now that's a bit odd and most probably cannot be connected to a GPRS link failure -- as that would not garble single bytes in a TCP connection.

I could fix some similar output problems in DIAG mode more than once by reducing complex sprintf() calls, so I searched for C18 sprintf() stack usage and found nothing concrete, but many warnings about very high stack usage of the whole printf family, plus advice not to use them at all on small embedded systems. One source mentioned sprintf() will need 70+ bytes stack for a simple integer template.

I also have read a bit into the C18 software stack management and found my previous assumption to be correct: it's currently fixed to bank 12 (0xC00), so provides 256 bytes for any kind of parameter + local vars combination. I think sprintf() on a 256 byte stack could well be a source of problems... and stack overruns can produce weird effects, as those above. I think about rewriting all my sprintf calls to itoa/ltoa/ultoa, but find it strange they did no harm up to now, even with complex templates as in net_msgp_environment(). Or maybe they did, unrecognized?

Do you have some other info on C18 sprintf()? I'd rather avoid recoding every output without sprintf(), but that's my best bet currently...

Regards, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

If you go to project settings, C18 / MPLINK, you can set a map file for the linker. Looking at what has been generated for a V2 experimental build, I get: ... __AARGB4 0x000025 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm __AARGB3 0x000026 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm __AARGB2 0x000027 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm __AARGB1 0x000028 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm __AARGB0 0x000029 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm __AEXP 0x00002a data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm __BARGB3 0x00002b data extern C:\MCC18\v3_39\src\traditional\math\barg.asm __BARGB2 0x00002c data extern C:\MCC18\v3_39\src\traditional\math\barg.asm __BARGB1 0x00002d data extern C:\MCC18\v3_39\src\traditional\math\barg.asm __BARGB0 0x00002e data extern C:\MCC18\v3_39\src\traditional\math\barg.asm __BEXP 0x00002f data extern C:\MCC18\v3_39\src\traditional\math\barg.asm __TEMPB3 0x000030 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm __TEMPB2 0x000031 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm __TEMPB1 0x000032 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm __TEMPB0 0x000033 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm __TEMP 0x000033 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm DelayCounter1 0x000034 data extern C:\MCC18\v3_39\src\traditional\delays\delayd1.asm ovms_firmware 0x000060 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_linevoltage 0x000063 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_chargecurrent 0x000065 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_chargelimit 0x000066 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_chargeduration 0x000067 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_chargestate 0x000069 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_chargesubstate 0x00006a data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_chargemode 0x00006b data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_charge_b4 0x00006c data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_chargekwh 0x00006d data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_doors1 0x00006e data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_doors2 0x00006f data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_doors3 0x000070 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_doors4 0x000071 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_lockstate 0x000072 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_speed 0x000073 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_SOC 0x000074 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_idealrange 0x000075 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_estrange 0x000077 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_time 0x000079 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_parktime 0x00007d data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_ambient_temp 0x000081 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_vin 0x000082 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_tpem 0x000094 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_tmotor 0x000095 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_tbattery 0x000096 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_tpms_t 0x000097 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_tpms_p 0x00009b data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c car_trip 0x00009f data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c ... The firmware version number is right at the start, so that would explain why I'm seeing it overwritten. It is the most vulnerable. As you can see, tpms is a little further down. The net buffers are much later. Data usage summary is: Section Info Section Type Address Location Size(Bytes) --------- --------- --------- --------- --------- .idata_ovms.o idata 0x000060 data 0x000069 .idata_vehicle.o idata 0x0004d8 data 0x000028 .idata_net.o idata 0x0005c8 data 0x00002c .idata_vehicle_twizy.o idata 0x0007e8 data 0x000014 SEED_DATA idata 0x0007fc data 0x000002 .idata_led.o idata 0x0008c7 data 0x000005 .idata_stokpr.o idata 0x0008cc data 0x000002 .idata_diag.o idata 0x000900 data 0x0000b9 .idata_net_sms.o idata 0x000a5e data 0x00005d .idata_net_msg.o idata 0x000abb data 0x000045 .idata_crypt_md5.o idata 0x000b00 data 0x000040 MATH_DATA udata 0x000020 data 0x000014 DELAYDAT1 udata 0x000034 data 0x000001 .udata_ovms.o udata 0x0000c9 data 0x00002d .udata_c018i.o udata 0x0000f6 data 0x00000a TX_CRYPTO udata 0x000100 data 0x000100 RX_CRYPTO udata 0x000200 data 0x000100 PM_CRYPTO udata 0x000300 data 0x000100 .udata_crypt_hmac.o udata 0x000400 data 0x0000d8 NETMSG_SP udata 0x000500 data 0x0000c8 .udata_crypt_base64.o udata 0x0005f4 data 0x000008 .udata_net.o udata 0x0005fc data 0x000003 .udata_led.o udata 0x0005ff data 0x000001 NETBUF_SP udata 0x000600 data 0x0000c8 .udata_net_msg.o udata 0x0006c8 data 0x000026 .udata_vehicle.o udata 0x0006ee data 0x000012 NETBUF udata 0x000700 data 0x0000c8 .udata_params.o udata 0x0007c8 data 0x000020 .udata_vehicle_twizy.o udata 0x0007fe data 0x000002 .udata_UARTIntC.o udata 0x000800 data 0x0000c7 .udata_crypt_md5.o udata 0x0009b9 data 0x000040 .udata_net_sms.o udata 0x0009f9 data 0x000007 vehicle_overlay_data udata 0x000a00 data 0x00005e .stack udata 0x000c00 data 0x000100 SFR_BANKED0 udata 0x000d60 data 0x00000c SFR_BANKED1 udata 0x000d70 data 0x00000c SFR_BANKED2 udata 0x000d80 data 0x00000c SFR_BANKED3 udata 0x000d90 data 0x000004 SFR_BANKED4 udata 0x000dd4 data 0x000002 SFR_BANKED5 udata 0x000dd8 data 0x000001 SFR_BANKED6 udata 0x000de0 data 0x000008 SFR_BANKED7 udata 0x000df0 data 0x000004 SFR_BANKED8 udata 0x000df8 data 0x000001 SFR_BANKED9 udata 0x000dfa data 0x000001 SFR_BANKED10 udata 0x000dfc data 0x000001 SFR_BANKED11 udata 0x000e20 data 0x000060 SFR_BANKED12 udata 0x000f00 data 0x000060 SFR_UNBANKED0 udata 0x000f60 data 0x000018 SFR_UNBANKED1 udata 0x000f80 data 0x000080 Interestingly, you can see you 0x100 byte stack. Still looking, but I reckon the problem is more likely to be sprintf() or library based than our net / net_msg / sms handlers. Regards, Mark. On 20 Dec, 2012, at 9:42 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Micheal,

My 49,51,51 is 0x31, 0x33, 0x33 - or "1", "3", "3" - similar to your 0x30 "0".

The base64 stuff in net_msg and net comms is mostly lower and uppercase letters. We see ascii encoded numbers in VINs and GPS mostly (but I am using the car's GPS and you are using the ovms module's GPS). Anywhere else we'd expect to see long strings of ascii encoded numbers?

Or, perhaps, sprintf() somewhere is going crazy and printing numbers?

Regards, Mark.

On 20 Dec, 2012, at 9:29 AM, Mark Webb-Johnson wrote:

...

Michael,

I think our revisions overlapped. I'd just merged in all your previous changes, plus documentation and server code updates.

I did make some minor layout fixes (where the indentation was wrong - I think you are using 4 spaces, or perhaps tabs, where the rest of the project uses 2). I also added your pseudo-command #6 to the protocol document.

Can you merge in my changes, then re-push yours? I'd like to get this v2 branch complete today and merge back into master tonight (my time).

Going forward, do you still want to maintain and work off your clone, or would it be easier if I just gave you write access to the main project? Your contributions are so helpful and good, that there is little I am having to do other than just accept them :-)

For the watchdog reboot and occasional ram trashing, I too suspect the NET, NET_MSG or SMS code. It is the only place where things are externally controlled to result in variable length strings. I did review it a while ago, but didn't see anything obvious. The other possibility is sprintf() elsewhere in the code (such as STAT).

Running v2.1.1 in my car, I have seen the firmware version go bizarre about a month ago:

2012-11-21 07:32:06.388834 -0500 info main: #74 C EV915 rx msg F 2.1.1/V2,SFZRE8B15B3000569,1,1,TR2N,3(2G) 2012-11-21 07:34:58.845568 -0500 info main: #61 C EV915 rx msg F 49.51.51/V2,SFZRE8B15B3000569,1,1,TR2N,3(2G)

That is a sprintf().

Regards, Mark.

On 20 Dec, 2012, at 9:13 AM, Michael Balzer <dexter@expeedo.de> wrote:

...

Mark,

I've rewritten all my sprintf() calls now. I introduced a new general string utils family to ease avoiding sprintf(), see my utils module addition.

I've had no garbled strings since and can now fetch all my history rows from the server, so it had some positive effect.

But the watchdog timeout reboots still occur, they still occasionally trash variables and I once still got the STKUNF flag from the reboot. That feels like some uninitialised pointer or writing beyond array / string bounds. I'm about to review the basic net code, if you've got an idea where to look first, tell me.

An example of the RAM trashing can still be seen on the server: MP-0 W17.4,8,17.4,8,17.4,8,17.4,8,-1 When that occured, a lot of other data was displayed wrong as well. The TPMS vars never get written to by the twizy module. The values 17.4 & 8 mean both car_tpms arrays had been filled completely with 0x30 or '8'. Does that ring a bell?

Regards, Michael

Am 18.12.2012 02:39, schrieb Mark Webb-Johnson:

...

In general, I try to minimise stack and ram usage on the small PICs.

Early on in OVMS, we had a bunch of local variables, and some were quite large. We were getting all sorts of random weird behavior (reboots, corrupt messages, etc). Since we changed to global variables, and very limited use of stacked function calls and local variables, things have been much better.

I agree that a large sprintf may be the cause of your problems. Can you try to change to itoa() and strcat(), to see if it makes an impact?

Regards, Mark.

On 18 Dec, 2012, at 8:05 AM, Michael Balzer wrote:

...

Mark,

the client_app.pl hint was good, I had not recognized that as a server query utility yet.

I removed the comma (misread the draft) and can now see my H entries. However, that lead me back to my assumed connectivity issue:

MP-0 c31,0,2,6,RTPWR-BattCell,1,1,76,2012-12-17 23:18:43,2012-12-17 23:18:43 MP-0 c31,0,3,6,RT-PWR-BattCell,14,16,1215,2012-12-17 23:13:11,2012-12-17 23:18:43 MP-0 c31,0,4,6,RT-PWR-BattC�ll,1,1,65,2012-12-17 23:18:43,2012-12-17 23:18:43 MP-0 c31,0,5,6,RT-PWR-BattPack,1,2,202,2012-12-17 23:13:11,2012-12-17 23:18:43 MP-0 c31,0,6,6,RT-PWR-Usag,1,1,45,2012-12-17 23:13:11,2012-12-17 23:13:11

This C31 result shows all kinds of garbled chars in my module's messages, and even a truncation on "RT-PWR-UsageStats" (also missing parts on the data blob on that one).

Now that's a bit odd and most probably cannot be connected to a GPRS link failure -- as that would not garble single bytes in a TCP connection.

I could fix some similar output problems in DIAG mode more than once by reducing complex sprintf() calls, so I searched for C18 sprintf() stack usage and found nothing concrete, but many warnings about very high stack usage of the whole printf family, plus advice not to use them at all on small embedded systems. One source mentioned sprintf() will need 70+ bytes stack for a simple integer template.

I also have read a bit into the C18 software stack management and found my previous assumption to be correct: it's currently fixed to bank 12 (0xC00), so provides 256 bytes for any kind of parameter + local vars combination. I think sprintf() on a 256 byte stack could well be a source of problems... and stack overruns can produce weird effects, as those above. I think about rewriting all my sprintf calls to itoa/ltoa/ultoa, but find it strange they did no harm up to now, even with complex templates as in net_msgp_environment(). Or maybe they did, unrecognized?

Do you have some other info on C18 sprintf()? I'd rather avoid recoding every output without sprintf(), but that's my best bet currently...

Regards, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Michael, To save time, I just fixed the conflicts. If you 'pull' again from master v2, you should get up-to-date. I'm going to do the switch back from v2 to master tonight (in a few hours time). I'll let you know when done. Regards, Mark. On 20 Dec, 2012, at 9:29 AM, Mark Webb-Johnson wrote:

I think our revisions overlapped. I'd just merged in all your previous changes, plus documentation and server code updates.

I did make some minor layout fixes (where the indentation was wrong - I think you are using 4 spaces, or perhaps tabs, where the rest of the project uses 2). I also added your pseudo-command #6 to the protocol document.

Can you merge in my changes, then re-push yours? I'd like to get this v2 branch complete today and merge back into master tonight (my time).

Mark, Am 20.12.2012 02:29, schrieb Mark Webb-Johnson:

I did make some minor layout fixes (where the indentation was wrong - I think you are using 4 spaces, or perhaps tabs, where the rest of the project uses 2).

My personal C/C++ style is no common standard, so I'll try to remember reformatting everything at least before committing. I've seen the MPLAB editor supports a range of standard formatting styles, among which the GNU style seems to be what you're using -- right? I'll use that one now. Any changes to the style config needed? Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

Mark, could you please audit & test this? https://github.com/markwj/Open-Vehicle-Monitoring-System/commit/ad17c2662942... I've reworked most of the complex sprintf() calls in the net and net_msg modules now. I also added a simple crash debug & checkpoint utility to be able to measure the effect and possibly narrow down remaining occurrences. It seems I've gained a lot of stability, had only two watchdog timeouts during the last week, no stack problems at all. 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? Thanks, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

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?

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

Michael, Not too surprising, and I think your approach is good. The main limiting factor we have is RAM, and doing any sort of big buffering at the framework level will be hard. I think it is better to limit at the module level (as you have done). It looks good for a master merge. Regards, Mark On 2 Jan, 2013, at 4:37 AM, Michael Balzer wrote:

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@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 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Michael, Looks good. Not sure if we need date/time (the record is stamped when we recieve it, but no harm if easy). You can bump version to 2.2.2. I'll have a look at the GPS logger. It sounds useful. Regards, Mark On 3 Jan, 2013, at 3:18 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

master merge done. Hm... maybe I should have increased the firmware version on this... as we've got new functionality, to 2.2.1?

Following your suggestion I changed the DebugCrash msg to a more generic and extendable format including the version information. Example entry:

MP-0 c32,0,6,6,*-OVM-DebugCrash,2013-01-02 18:33:48,0,2.1.1/RT2.5/V2,0,0000,20

Btw: I think the GPS logger could also become a standard function. Besides producing nice tracks it's useful to test different antennas and antenna positioning. Maybe the send rate needs more configurability, it currently logs once per minute or every 5 seconds if streaming is enabled.

Regards, Michael

Am 02.01.2013 02:19, schrieb Mark Webb-Johnson:

...

Michael,

Not too surprising, and I think your approach is good. The main limiting factor we have is RAM, and doing any sort of big buffering at the framework level will be hard. I think it is better to limit at the module level (as you have done).

It looks good for a master merge.

Regards, Mark

On 2 Jan, 2013, at 4:37 AM, Michael Balzer wrote:

...

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@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 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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@expeedo.de> To: ovmsdev@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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@webb-johnson.net> To: OVMS Developers <ovmsdev@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@expeedo.de> To: ovmsdev@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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@expeedo.de> To: ovmsdev@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@webb-johnson.net> To: OVMS Developers <ovmsdev@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@expeedo.de> To: ovmsdev@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

...

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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@expeedo.de> To: ovmsdev@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@expeedo.de> To: ovmsdev@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@webb-johnson.net> To: OVMS Developers <ovmsdev@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@expeedo.de> To: ovmsdev@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

...

...

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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@expeedo.de> To: ovmsdev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Nikolay, I suggest you look at the Volt/Ampera module first. That is the simplest and just handles three CAN messages - SOC, vin#1 and vin#2. Your Think probably has an equivalent three. You should be able to just change the CAN IDs, and information extraction. You can see the global variables are used, then use a global STAT SMS to test (DIAG mode is the easiest and fastest way to test this stuff). Regards, Mark On 3 Jan, 2013, at 7:23 AM, Michael Balzer <dexter@expeedo.de> wrote:

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/...

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@expeedo.de> To: ovmsdev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Nikolay, In general, all the car module needs to do is put the correct data into the car_* global variables (defined in ovms.h). From there, SMS commands are implemented in net_sms.* and smartphone app comms are implemented in net_msg.* - the vehicle module itself doesn't need to do anything. For example, if you store the state-of-charge percentage in car_SOC, then an SMS STAT command will return it, and the battery gauge on a connected smartphone App will show it. You only need to override / add SMS or MSG commands if you want to do something vehicle-specific. The default net_sms and net_msg modules will do the standard stuff all for you. Assuming that you are doing the above (e.g. writing state of charge to car_SOC), to get this on the smartphone all you need to do is configure the car module for GPRS and SERVER, then get the app running on your smartphone. You can follow the instructions in the Tesla Roadster User Guide to do this. Regarding notifications, those are initiated by the vehicle module, using net_req_notification() and one of the NET_NOTIFY_* notification types (defined in net.h). The framework will issue the notification - you just need to set the bit to request it. Regards, Mark. On 6 Jan, 2013, at 10:04 PM, Nikolay Shishkov wrote:

Thanks to Michael, Mark and google the code now works. I am fetching SOC, pack current, pack voltage, and pack average temperature. So what next? The current code is based on the Twizy, I have changed the implementation of the Debug command and am getting correct values... but I would like to have the STATE command work too, and I will implement a custom one too (based on the Twizy code) so it will report what I want it to report. There is for example no range. How to go about with integrating server and android/iphone app? In the simplest form I would like to have at least SOC, Temperature, Pack voltage, Pack current, a some kind of text or bit map for state (like charged, charging enabled, plugged, waiting temp) there are some more states, some additional parameters like PWM signal for charge power, and eventual errors and warnings - there is a warning "please charge to full soon" for example. These can also be bits or text. From the Twizy code I can see how to handle this for the sms commands, and I see some ways of generating semicolon separated message to the server... but would that mean that the message will be later understood/presented by the apps?

I would also like to have the SOC notifications - low SOC, charge finished, charge stopped - I can also fix this the Twizy way.

Very exciting! Thanks, Nikolay

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Nikolay, OK, a bit more detail :-) Am 07.01.2013 08:05, schrieb Nikolay Shishkov:

In the simplest form I would like to have at least SOC, Temperature, Pack voltage, Pack current, a some kind of text or bit map for state (like charged, charging enabled, plugged, waiting temp) there are some more states, some additional parameters like PWM signal for charge power, and eventual errors and warnings - there is a warning "please charge to full soon" for example. These can also be bits or text.

Use the standard "STAT" message (overloaded) for charge state notifies. Send other text messages by SMS or by "MP-0 PA...". See Twizy notification system on how to do this.

What "car_" variables I should use for the pack voltage and pack current? None, those currently are no common properties.

What "car_" variables I should use for statuses that are not available as a car_variables? None, use vehicle specific variables until at least Mark agrees on adding them to the common set.

Also the nominal pack temperatures (for the zebra battery) are around 270C (two hundred and seventy Celsius) - any idea if this would be a problem with the current setup? That's a definite yes, as the temperature vars are currently bytes. That also may need to be changed in the common variables. Until then, you could do a workaround by re-basing your App readings at e.g. 200 °C, so 270 can be displayed as 70.

Eventhough the Tesla and Think are both EVs, they have some significant differences in technology and thus significant differences at what drivers would be interested in seeing.

So should I define my own handling and "think_" parameters, or should I add more "car_" ones? Add them as "think" vars first, upload your code, then post a suggestion what to include into the common set, so we can discuss it.

The common set of properties can be extended and refined, but there basically needs to be vehicle specific support in the Apps anyway, and that in turn could eliminate the need for most extensions to the common set. IMO the common set should cover just the basic functions that can be supported by most vehicles. It currently already contains more properties than really are common (from the Twizy point of view), so the App already will need at least some vehicle feature support matrix. Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

Ok, I get the current situation and will go ahead with stat command override. I will also look at "command calls" and "historical data". I remember reading some discussion on the list regarding this with the Twizy.  Having a working app for the Think is going to be a big +, and I can probably help with that too. In general this may be a good time (having twizy, ampera and think) to reevaluate the architecture and implement changes so new features/parameters/cars could seamlessly be integrated in the ovms/server/app ecosystem. I would imagine that the sooner the better. On the app side the interface may be abstracted in a such a way that each info screen of the app can be composed of background (the car or system illustration) and a list of parameters with their locations on the screen. Each parameter may have associated rendering UI component. There could be dial rendering component, thermometer rendering component, simple number and unit in a box component, etc.  This all can be done in xml or json, and then the app can be generic - pulling up new backgrounds, and parameter lists on startup. This would allow to extend the apps with new vehicles or new parameters without changing anything in the code or redeploying on the google play /apple appstore. Also would allow for "pushing" new visuals, and revisions in parameter descriptions. Maybe something similar can workout on the server side - if it is not working like that already. On a second thought - would it possible (or make sense) to have a direct connection between the app and the car? So the server would in a sense run on the mobile platform, and there could be an UI on top. Far more complex though and some limitations like uptime, historical data, etc. Regards, Nikolay ________________________________ From: Mark Webb-Johnson <mark@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Sent: Monday, January 7, 2013 8:56 AM Subject: Re: [Ovmsdev] test works, what next Nikolay, Michael B, There are some global parameters that can be easily extended, in a backwards compatible manner. For example, battery temp should be easy to change from byte to int16. I think there will be zero impact on the Apps, as the change can be made in a backwards-compatible manner. It is also easy to test. There are some global parameters that are harder to change, because it will break the apps, and the apps will thus have to be changed to cope with both old and new formats co-existing. The example there is change of odometers from miles to vehicle-units. There are some parameters that are vehicle specific, and some that are candidates for 'globalisation' :-) For those, I think it best to just publish to the list what individual cars are offering that are not handled by the existing globals, and we'll extend as necessary. An example of this would be 2 more doors (for 4 door cars). Until that is done, the parameters should be implemented as vehicle-specific and obtained via command calls or historical data. Interesting discussion, and glad we're having it. Regards, Mark. On 7 Jan, 2013, at 3:41 PM, Michael Balzer wrote:

Nikolay,

OK, a bit more detail :-)

Am 07.01.2013 08:05, schrieb Nikolay Shishkov:

...

In the simplest form I would like to have at least SOC, Temperature, Pack voltage, Pack current, a some kind of text or bit map for state (like charged, charging enabled, plugged, waiting temp) there are some more states, some additional parameters like PWM signal for charge power, and eventual errors and warnings - there is a warning "please charge to full soon" for example. These can also be bits or text.

Use the standard "STAT" message (overloaded) for charge state notifies.

Send other text messages by SMS or by "MP-0 PA...". See Twizy notification system on how to do this.

...

What "car_" variables I should use for the pack voltage and pack current? None, those currently are no common properties.

...

What "car_" variables I should use for statuses that are not available as a car_variables? None, use vehicle specific variables until at least Mark agrees on adding them to the common set.

...

Also the nominal pack temperatures (for the zebra battery) are around 270C (two hundred and seventy Celsius) - any idea if this would be a problem with the current setup? That's a definite yes, as the temperature vars are currently bytes. That also may need to be changed in the common variables. Until then, you could do a workaround by re-basing your App readings at e.g. 200 °C, so 270 can be displayed as 70.

...

Eventhough the Tesla and Think are both EVs, they have some significant differences in technology and thus significant differences at what drivers would be interested in seeing.

So should I define my own handling and "think_" parameters, or should I add more "car_" ones? Add them as "think" vars first, upload your code, then post a suggestion what to include into the common set, so we can discuss it.

The common set of properties can be extended and refined, but there basically needs to be vehicle specific support in the Apps anyway, and that in turn could eliminate the need for most extensions to the common set. IMO the common set should cover just the basic functions that can be supported by most vehicles. It currently already contains more properties than really are common (from the Twizy point of view), so the App already will need at least some vehicle feature support matrix.

Regards, Michael

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

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Nikolay, congratulations :-) Mark already said it: look for "car_" variables, these will transport common properties. "can_" variables are currently vehicle locals, see my previous suggestion on renaming these to reflect their vehicle specific nature. Only common properties and commands will currently be supported by the Apps -- adding vehicle specific code and UIs to the Apps is the next main todo. Note there are some variables already in the Twizy code, that could/should become common. Generally, the more vehicles turn up to need some value, the more likely it will become common. Without App support, you still can do vehicle specific data collection and analysis by sending "H" MSGs to the server. "H" msg types are basically free-form, they can transport all vehicle specific data to the server and to any client. There are multiple examples in the Twizy code for that, and I've added user guides and a perl utility "cmd.pl" to query them from the server last night, take a look. The output is simple CSV format, so you can load that into any spreadsheet or database. For text messages, note there is already an App msg defined ("P" = push message), the only current caveat is, the Apps (at least the Android one) will only process these if backgrounded. That certainly can be fixed soon, so push messages will become a fully functional SMS alternative. Regards, Michael Am 06.01.2013 15:04, schrieb Nikolay Shishkov:

Thanks to Michael, Mark and google the code now works. I am fetching SOC, pack current, pack voltage, and pack average temperature. So what next? The current code is based on the Twizy, I have changed the implementation of the Debug command and am getting correct values... but I would like to have the STATE command work too, and I will implement a custom one too (based on the Twizy code) so it will report what I want it to report. There is for example no range. How to go about with integrating server and android/iphone app? In the simplest form I would like to have at least SOC, Temperature, Pack voltage, Pack current, a some kind of text or bit map for state (like charged, charging enabled, plugged, waiting temp) there are some more states, some additional parameters like PWM signal for charge power, and eventual errors and warnings - there is a warning "please charge to full soon" for example. These can also be bits or text. From the Twizy code I can see how to handle this for the sms commands, and I see some ways of generating semicolon separated message to the server... but would that mean that the message will be later understood/presented by the apps?

I would also like to have the SOC notifications - low SOC, charge finished, charge stopped - I can also fix this the Twizy way.

Very exciting! Thanks, Nikolay

_______________________________________________ OvmsDev mailing list OvmsDev@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

Michael, I had a visual review of this, and it _seems_ ok. I haven't put it in my car yet, because I'm leaving on a short overseas trip and need to make sure I have the ability to keep an eye on my car while I'm gone. I'll load the new firmware into my car when I get back at the weekend. I really like your debug_crash*, CHECKPOINT and reporting to server as a historical record system. It would be good to take this out of OVMS_DIAGMODULE and make this a standard feature to allow us to see what is going on. On the report to server, though, I think it would be useful to add the firmware version so we can correlate crashes across different firmwares. For the iOS App, a while ago I added testflightapp to it - which centrally reports every single app crash - that was invaluable in getting the app more stable and dealing with both common and edge cases. Regards, Mark. On 30 Dec, 2012, at 10:42 PM, Michael Balzer wrote:

Mark,

could you please audit & test this?

https://github.com/markwj/Open-Vehicle-Monitoring-System/commit/ad17c2662942...

I've reworked most of the complex sprintf() calls in the net and net_msg modules now. I also added a simple crash debug & checkpoint utility to be able to measure the effect and possibly narrow down remaining occurrences. It seems I've gained a lot of stability, had only two watchdog timeouts during the last week, no stack problems at all.

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?

Thanks, Michael

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

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev