[Ovmsdev] Multi frame query

[Michael Balzer]

I don't see any issues in the standard poller. The "incoming" methods 
get called per frame.

You can verify it's working correctly by doing an obdii request.

Regards,
Michael


Am 02.04.21 um 12:55 schrieb didier at ernotte.com:
> Hi,
>
> Don't you think this fix has a bigger impact on vehicle.cpp, and all 
> implementations ?
> I have started creating the Jaguar Ipace vehicle, and I see a very 
> similar code (and fix) in IncomingPollReply, for the size (16 bits) of 
> the "length"
>
> protected:
> virtualvoidPollerStateTicker();
> virtualvoidIncomingPollReply(canbus*bus, uint16_ttype, uint16_tpid, 
> uint8_t*data, uint8_tlength, uint16_tmlremain);
> virtualvoidIncomingPollError(canbus*bus, uint16_ttype, uint16_tpid, 
> uint16_tcode);
>
> and
>
> voidOvmsVehicleJaguarIpace::IncomingPollFrame(CAN_frame_t*frame)
> {
> uint8_tframeType= frame->data.u8[0] >> 4;
> uint16_tframeLength= frame->data.u8[0] & 0x0f;
> uint8_t* data= &frame->data.u8[1];
> uint16_tdataLength= frameLength;
>
> Didier
>
>
>
>
> Le mardi 30 mars 2021 13 h 58 min 20 s UTC−4, Greg D. 
> <gregd2350 at gmail.com> a écrit :
>
>
> Just to close out this loose end...
>
> OBD2ECU doesn't do any multi-frame PIDs other than responding to 
> requests for the VIN (fixed format) and ECU Name (20 characters, user 
> configurable).  The flow control frame for both of these are kludged 
> with a simple (fixed) 10ms delay, i.e. it doesn't actually wait for 
> the flow control frame to be received before proceeding, and ignores 
> them when received.  Proper processing was seen as unnecessary 
> complexity when I wrote the first prototype, and was never "corrected".
>
> Greg
>
>
> Michael Balzer wrote:
> Didier,
>
> the PID scanner normally works perfectly with multi frame responses, 
> but I haven't had a response that long yet.
>
> For 1503 bytes, 215 consecutive frames need to be transmitted. The PID 
> scanner requests these to be sent with 25 ms separation time, so they 
> should need 5.375 seconds.
>
> Maybe some frame gets lost, or maybe the device doesn't allow a 
> separation time that high for a transmission that huge.
>
> Your log quote wasn't from the re-pid component but from obd2ecu, 
> which has nothing to do with the RE tools. You should raise the log 
> level for re-pid to see more info. Another tracing option is to use 
> the CAN log monitor.
>
> Btw, you should never need 30 seconds timeout for a PID poll, as the 
> scanner checks against the last frame reception.
>
> Regards,
> Michael
>
>
> Am 28.03.21 um 17:52 schrieb didier at ernotte.com 
> <mailto:didier at ernotte.com>:
>> I am investigating some PID with very long data. I am using the PID 
>> scanner for this.
>> When I turn on the log level debug , I can see this as the first repy
>>
>>
>> D (1456677) obd2ecu: Rcv 7ec: 8 (15 df 62 48 83 0 0 0)
>>
>> From the Canbus doc, I understand that the first "1x (15)" tells me 
>> that this is the first frame of a multi frame, and the length is 
>> "5df" . The Pid scanner seems to return only "df", not "5df" data, 
>> and I can see in the log that I have around 1500 byte returned, not 
>> 220. Any explanation ? anyone see this problem as well ? The scan 
>> command is (I had to hack the code to allow timeout > 10sec)
>> re obdii scan start 1 7e4 4883 4883 -r500-7ff -t22 -x30
>
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com  <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev  <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev 
> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210402/58e564d5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210402/58e564d5/attachment-0001.sig>