DASH4 do not decode analog16 and above (with DL1 MK3)

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

DASH4 do not decode analog16 and above (with DL1 MK3)

Postby ECOELEC » Mon Nov 25, 2013 10:40 pm

Hi,

I use an ECU (homemade) which write its datas on a DL1 MK3, from analog13 to analog 32 (virtual ones, used as user variables).

When using monitor and monitor light, i can see them correctly from the DL1 but, the DASH4 pro doesn't decode any of analog16 to analog32!

I absolutely need to decode them! Could you solve this problem (with pehaps a new firmware for Dash4)?

My config: DL1MK3 (V 4.3.3), Dash4pro OLED (V 1.0.21)

Regards from Belgium

Ecoelec

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Postby ECOELEC » Tue Nov 26, 2013 12:19 am

... another problem which is probably linked with the previous one is that the message index of the analog inputs are scrambled when decoding.

For example: if i send a (verified) frame [20][00][01][21] (decimal values) on the RS232 input (either on the computer or on the DL1) which mean that i write 1 in the message index 20 (analog input1), the message is decoded as message index 27 (analog8)!

The MI20 -> MI20; MI21 -> MI25, and so one ... except the MI24 wich is ok (analog input17).

Regards

Ecolelec

Support

Support

Postby Support » Tue Nov 26, 2013 4:49 pm

Hello,

I have tested the analogue channels on the DASH4 by streaming the data in from the lite monitor advanced features and all is fine. What version of the DASH4 firmware are you running?

Regarding the random analogue channel ordering here is a link explaining the order >>> http://www.race-technology.com/wiki/ind ... elOrdering

Kind regards,
Support (K)

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Postby ECOELEC » Tue Nov 26, 2013 7:51 pm

Hello,

Thank you for your reaction.
My DASH4 is flashed with 1_0_21 firmware (the last one) and the DL1MK3 with the 4_4_3 version.

After looking at the ordering of analog channels i see my (dis)order.

The problem is that I don't write to an "hardware channel number" but to a "message index" (referenced here: http://www.race-technology.com/wiki/ind ... DataFormat).

In my example, if i send the (decimal) frame [20][00][01][21], the value "1" should normally be written on the message index 20 (the analog input 1) and not on the analog input8 (message index 27) which unfortunatly is the hardware channel number 20. If it's true, the "knowledge base" should be clarified on this point.

I never had this problem on my DL2 because i never wrote my own data on its real analog inputs (which i used all), I use the inputs from 17 to 32. I suppose that the ordering of hardware channel number is corresponding to the message index after the analog input 16.

Does it mean that to decode analog inputs values from an incoming serial data, i have to forgot which is written in the table above (message index) for analog inputs 1 to 16?

Regards.

Ecoelec

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Postby ECOELEC » Tue Nov 26, 2013 10:14 pm

I've checked my DASH4. I sent it analog inputs data directly from monitor lite.

The DASH4 can well decode and display analog1 to analog12 and 29 to 32 but not analog 13, 14, 15, 16, 17, 18, 19, 20, 27, 28.

I make the same test on DL1 with the same source and the analog 20, 21, 22, 23, 24, 25, 26, 27, 28 are not logged!

I already reflash the DASH4 with a redownloaded firmware "DASH4PRO v1_0_21" and the DL1 with the "DL1MK3_v4_4_9" without any success.

What's wrong?

Ecoelec

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Postby ECOELEC » Tue Nov 26, 2013 10:35 pm

... for the DL1, i forgot that these variables was used by DL1 CAN decoder, so, no problem for the DL1 (except that i don't understand why a step variation on any analog input (from monitor lite) always take 100ms to reach final value from the initial value (at 100Hz recording, 100Hz sampling on monitor lite, no max rate of change, no filtering).

Ecoelec

Support

Support

Postby Support » Wed Nov 27, 2013 10:20 am

Hello,

I have retested and was able to display all channels and log all channels. Below is a screen shot of the variable manager showing the samples.

PLease can you email me DASH4 and DL1 configuration and i will test using your configuration. Kieran@race-tech...

Kind regards,
Support (K)


Image

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Postby ECOELEC » Tue Dec 03, 2013 7:42 am

Hi,

Did you receive my 2 mails?
I continue to try displaying my analog inputs without any success.

Regards.

Ecoelec

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Problem solved

Postby ECOELEC » Thu Dec 19, 2013 9:50 pm

Hello,

Good news. After half a day of working on it, I think I’ve found some problems :

1) When I configured my dash4pro screen, I used the monitor variable files which are not compatible with it (it cause severe decoding errors). I think I’ll need to copy them manually (if it’s normal, an export function from Monitor and a different file extension should be great).

2) After creating a test display (all analog inputs), I connect directly the Dash to the computer and send data through monitor lite. I can command all displayed variables, fine. If I send serial data to the DL1MK3, the variables 20 to 28 doesn’t change anymore … because they are overwritten by the decoded incoming CAN data.

Now, I can decode can data and display them on the Dash4.

After recreating new .var from scratch (for the Dash4); all seem to work.

Conclusion : dont mistake between these two ".var" files! The Dash and the analysis have the same extention, are loaded without any message but they are not compatibles.

Turby
Posts: 296
Joined: Thu Nov 17, 2005 2:28 pm

Postby Turby » Fri Dec 20, 2013 1:50 pm

It would make sense if the .var (and other config / data ?) files embed a version number within them which relates to the specific file data format specification. Its then an "easy" job for the application to spot and report inconsistencies but also allows the application to "upgrade" to a newer version automagically if appropriate.

We've had just such a mechanism in place since day one (10+ years now!) with our companies data logger / analyser. It also makes updating all of the 100's of regression test data files painless...


Return to “Bug reports”

Who is online

Users browsing this forum: No registered users and 3 guests