Hi there,

I think there may be a bug in the Raw Capture window.

When you drag the column headers to rearrange, the sort function does not work correctly. i.e. when you click the headers to sort the data, the data gets rearranged but not in the correct order.

I think the column id's are not being changed when the order is changed. So if you swap PGN with PID, then sort by PID the list will be sorted by PGN number (which is what that column used to be).

Great product by the way. The colour coded database is brilliant. On the wish list I would love to see the spinners for the transmitter blocks, and the dual scale graphs. Also, an option to view the packet data in binary as an 8x8 grid/matrix. This would make it easy to identify individual bit changes within the packet e.g. when trying to interpret proprietry PGN's.

Keep it up.

Shane Vallely

Thanks for the feedback.

That bug with packet sorting has already been fixed - we are long overdue for the next release... should be very soon.

I like your suggestions.

The variable transmitters with spinners has long been on our list to add and will probably be the next "major" change we see. I think it will be a completely new transmitter block that is used to transmit PGNs and their respective variables using sliders or something similar. I'm not sure where "graph improvements" are in our priority list, but I know its been suggested before. The graph does support 2 visible Y scales ("primary" and "secondary"), but no more. Each variable is scaled individually, but only 2 can be displayed. Are you suggesting that we support multiple scales that get stacked side-by-side on the left-axis? The 8x8 grid is something that I really like, but I pictured it in the database editor. Where would you suggest the 8x8 be displayed... in a separate raw capture column, or just in the detailed view? It may be hard to present it as a column though w/o making each row significantly taller.

Ah thats good to know and I will be looking out for the updated release.

Additional scales would be good in the graph window. This would make it easier to view 3 or more variables with differing data ranges (e.g. engine speed, fuel rate, gear selected) on the same graph.

The 8x8 view I imagined as a watch window, either a selectable view in the packet watch window or a separate watch window. It would be useful (in my application) for live data. We would like to use it to confirm the existence of specific data on the J1939 bus of test vehicles. e.g. we could use the 8x8 view to watch pgn65265 and check bit changes when the clutch, foot brake and park brake are activated. I know it is easy to create telltales for these parameters, but it would be very usefull for interpreting proprietary pgns when we don't know the allocations.

Regards,

Shane

I really like the 8x8 matrix idea for the packet watch, but I can't promise how soon it will be added.

I like it also because it will really help our aftermarket/reverse-engineering customers... its kind of a sad state that so much of CAN in the auto world is locked-down and proprietary.

Have you seen the highlighting mode of the "Compact Display" mode in Raw Capture? That may help you to monitor changing bits too - but you will need to be very experienced with hex (and set hex mode) to really get a feel for the changing bits of each byte. Basically in compact mode, as each data byte of a given packet ID (or PGN) changes, it highlights the byte, and then it slowly fades out if the byte doesn't get updated over a certain time period. Its useful to see what packet and byte changes when you press the brakes, as an example.

We have just taken delivery of the full version with E-Com device and it has proven very useful already. Great product. I have been able to interpret the proprietry PGNs using the compact display mode and the data recorder to analyse the individual bit changes offline by converting the hex to binary, but obviously the bit display would make this process much simpler.

The only issue I have had with the compact display is reading the data as it changes due to the highlight clashing with the text colour. Usually not a problem unless the data changes quite quickly. I havent delved into the settings yet either so there may be a way to customise the colours.

Regards

Shane.

I'm glad to hear that worked out. I'm always hesitant when I recommend or hear that people are trying to reverse engineer proprietary packets because their success depends on a lot of factors - including their competency with CAN and hex! =) Of course, it also depends on the types of variables that are within the packets.

I believe the algorithm darkens the data highlight color if the packet background color is past a certain brightness of color, or lightens the highlight color if the packet background color is past a certain darkness level. Its difficult for this to work on all possibilities of color, but its better than having a "highlight color" setting for every packet. This sort of contrasts our natural selection of contrasting background vs text color for packets, but it still usually works out.

If there is a packet color that is hard to read I suggest that you change the packet color to something that doesn't clash as much. You can do this in realtime - just right click on the Raw Capture packet, click "Goto Definition", and then in the packet definition change its color.

There is also a setting to control how long it takes the highlighted data color to fade out, and it may help readability if you speed this up a bit. Right click the "Raw Capture" and select Properties to find this setting.