Mark, Works like a charm! It now detects charging status and SOC correctly. Please see the logs attached with all situations you suggested. Patrick Am 05.04.2013 um 17:31 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
Patrick,
This version has 0x00 (SUV) also treated as 'charging'. It also has polling for the other possibly useful parameters, so we can get them in the log files. Please load and try.
While you have the logger/tool, it would be good if you could get logs for:
Driving Car sitting on, but idle Car sitting off, but idle Car sitting off, then charge starts (perhaps 1 minute before charging, and 1 minute during charging) Car charging completes (the last minute or so of a charge, followed by the minute afterwards) Car charging interrupted (the last minute or so of a charge, followed by an interruption, followed by the minute afterwards)
Regards, Mark.
P.S. This is for Tazzari only - it has a bunch of other work-in-progress for Tesla Roadster, so please just use this firmware in Tazzari.
<OVMS.X.production.hex>
On 5 Apr, 2013, at 11:10 PM, Patrick Kapsch <patrick.kapsch@mac.com> wrote:
Maybe the sheet I've sent wasn't clearly structured. 0x00 is also a valid value (called SUV) as well as all the others you've mentioned and correctly implemented.
Patrick
Am 05.04.2013 um 17:01 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
Looking at the code, I have implemented (as a start):
SOC Battery Capacity Charge Status Drive / Park GPS location (via in-built gps)
The charge status is currently working of PID 0xF6E0. In your log, these seem to be coming in as:
0x775 11,7059 0A A1 F6 E0 00 00 00 00
ie; value is always 0x0000000.
But, code expects values:
0x04: Charge completed 0x63: Charge done/failed (depending on where we came from) 0x01,0x02, 0x03: Charging
I'll have to check my notes, but the log doesn't seem to match what we were expecting.
The log is while charging the car, right?
Good news is that polling seems to work, and the 0x267 trigger is there and working well.
Regards, Mark.
On 5 Apr, 2013, at 10:18 PM, Patrick Kapsch <patrick.kapsch@mac.com> wrote:
Bus looks okay - the charge state is asked correctly and answered as well. But in fact OVMS doesn't recognize it. Please check the Log-File below.
Patrick
Am 05. April 2013 um 15:42 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
Can you check can write 1 (one of the features).
On 5 Apr, 2013, at 9:35 PM, Patrick Kapsch <patrick.kapsch@mac.com> wrote:
Mark, I've just had a look on the bus activity and there is nothing going out on 0x078A. The OVMS isn't sending anything. I'm sure it's connected correctly as the parking indicator works. I'll send you the log file later. Any idea what could cause that? "MODULE?" gives me what it should: Module: VehicleID:GTTG12212 VehicleType:TZ Units:K Notifications:SMSIP
Anything wrong with the Vehicle type maybe?
Thanks, Patrick
Am 02.04.2013 um 15:36 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
> From the code point of view, I do something similar to the Volt/Ampera. > > I need a periodic reception of CAN ID 0x267 to tell the system the bus is 'alive'. This should be at least once a second. > > If the bus is alive, then I poll the bus for the PIDs suggested. > > A second routine handles poll replies (on CAN ID 0x775). That does the decode for SOC, etc. > > If you manage to T the bus, the things to look for are if you see a periodic 0x267 to signify the bus is alive. Then, if you see the polling activity from OVMS going out on 0x078A. And, finally do you see the poll replies coming in on 0x775? In particular, 0xF9EF (SOC). > > Regards, Mark. > > On 2 Apr, 2013, at 9:14 PM, Patrick Kapsch <patrick.kapsch@mac.com> wrote: > >> Mark, >> that could be the problem then. I'll swtich them and try again. If that gives me values from the car, I can dive into the GPRS/Server-Issue. >> >> >>>> On the Tazzari there is no value at all. What could be wrong? >>> Now, that is going to be hard. On my desktop simulator, it worked fine. >>> >>> Can you double check vehicle type is TZ? >> checked. There is no possibility of encoding problems? Z being Y on the german keyboard layout. >>> Do you have any way of getting a CAN bus dump while the OVMS module is connected? That would allow us to see if the polling is working or not. >> I would have to rewire the adapter I've done for logging before. >> >> Thanks, >> Patrick >> >> Am 02.04.2013 um 15:12 schrieb Mark Webb-Johnson <mark@webb-johnson.net>: >> >>> Patrick, >>> >>> Yes, CAN-H and CAN-L matter. They must be correct. >>> >>> For adaptor software, any terminal emulator should be ok. Set to 9600 baud. Type "ATE1" to turn on command echo and save a transcript. That should tell us what is going on. >>> >>> Regards, Mark. >>> >>> On 2 Apr, 2013, at 9:10 PM, Patrick Kapsch <patrick.kapsch@mac.com> wrote: >>> >>>> Yes I've got an adapter. Which software should I use with it? >>>> >>>> Another question: Is there a difference from CAN high / CAN low? Does it matter if they are switched? That could possibly be one problem with polling data from the car, because I'm not sure which is which on the car. >>>> >>>> Thanks for your help. >>>> Patrick >>>> >>>> >>>> Am 02.04.2013 um 14:37 schrieb Mark Webb-Johnson <mark@webb-johnson.net>: >>>> >>>>> Car connected once, delivered some messages, then disconnected (timeout). >>>>> >>>>> Do you have a USB-RS232 adapter? If so, that on the diagnostic port is the easiest way of finding out what is going on. >>>>> >>>>> Regards, Mark. >>>>> >>>>> On 2 Apr, 2013, at 7:43 PM, Patrick Kapsch <patrick.kapsch@mac.com> wrote: >>>>> >>>>>> Mark, >>>>>> I've got major issues regarding the 2.2.5. I've not even been able to get the GSM to work properly. I've got three modules and it's all very weird. I've got one Module working now with 2.2.5 by previously configuring it on 2.2.2 and then updating. It now connects to the GSM network but not to the OVMS Server. I can't get it to do so. >>>>>> Maybe you can have a look at the Serverlogs? ID has been GTTG1221 and now is GTTG12212 because I deleted the first one which was then in use. >>>>>> >>>>>> Thanks, >>>>>> Patrick >>>>>> _______________________________________________ >>>>>> 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 >> >> _______________________________________________ >> 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 <ovms_attached_charging.CSV>_______________________________________________ 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