Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000465OLVGeneral Featurespublic2011-12-05 17:412011-12-10 17:46
Assigned ToBenFenner 
PlatformAllOSAllOS VersionAll
Product Version0.0.2-SNAPSHOT 
Target Version0.1.0Fixed in Version 
Summary0000465: Add Ability To Display Missing Data Distinctly
DescriptionDistinctly from bad data.

Right now when I parse FreeEMS data streams, if I get a bad packet I insert a set of zeros into the log and increment the record by one such that it can be seen, however we can do better than that.

I recently introduced a bug in the firmware which illustrated that to me in detail. I can and will upload that log file to this issue such that you can see it for yourself. One of Preston's real-word logs has similar issues for a different reason, too.

In my log file, from the bench, there is a section with 9 missing packets and I had inserted two zeros data sets into the data to be displayed, not 9. There is no reason to use more memory doing this, instead there should be a mechanism for filling out dead areas with nothing, or leaving gaps in the log (less obvious). This feature should be optional such that if data for it is available, then it will be handled and if not, it won't be.

Data comes in the form of a number that increases with each packet sent. Thus if there are N missing, you can insert the equivalent of N records of null space into the display to illustrate this and keep the visual alignment of the other data correct.

In terms of display, I think leaving out the bad data as black/blank space is bad and non-obvious, especially for smaller discrepancies, however for larger ones it would work OK. Instead there are some options available. One is to draw a white line down in the first and last missing location pixel and leave it blank in between. The second is to draw white traces between the end and restart of each trace, a different colour to make it obvious that it's not real data. And there are probably other ways too.

I was planning to count these as a type of reset, however I think it should be handled differently as it's different.

My data was generated by a firmware bug, Preston's was generated by a loose serial cable. Both will be good for testing :-)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0000955)
BenFenner (developer)
2011-12-10 16:12
edited on: 2011-12-10 16:19

I like the line idea, or maybe they need start/end markers (circles)? That might be consistent.

User avatar (0000956)
Fred (administrator)
2011-12-10 16:21

Excellent point, however it won't work well for single missing records at 1:1 zoom. For that lines would work better. And what about zooming out? It won't be acceptable to join them back together and i don't think a hollow circle will be sufficient. Hmmmm.
User avatar (0000960)
BenFenner (developer)
2011-12-10 16:47
edited on: 2011-12-10 16:48

I don't see the issue. When at 1:1 or zoomed out you'll still see the circles, they just may overlap some or overlap completely. All you need to know is that there's a break in the data, right? A circle will show that. The only issue I see is that if you have tons and tons of breaks in the data, the trace could get filled with circles and look a bit silly when zoomed out?

User avatar (0000962)
Fred (administrator)
2011-12-10 16:59

The issue is that they would be too visually similar to the "I'm different" dots when zoomed in. I know you're not zoomed in, but that will cease to be obvious. It also doesn't say "this break goes through the entire data set" like the line does. We're definitely going to use lines for other events such as keyboard space bar user marks, resets, etc. Hence it probably makes sense to use the same sort of look.

The other HUGE and irreconcilable difference between end points and break points, is that breaks are fucking serious and bad and end points are normal. Hence end points should be subtle, as they currently are, and breaks should be red flags that stand out like a spare dick at wedding.
User avatar (0000964)
BenFenner (developer)
2011-12-10 17:15

I wasn't aware that the breaks would always and necessarily be in all of the data traces. I thought maybe it would be on a data type basis, but that's obviously not right.

However, I wasn't envisioning a circle for each missed packet. Simply a circle marking the last legit packet, and a circle marking the next legit packet. And NO trace between them. It would not have gotten confusing when zoomed in I assure you.

Something spanning the height of the division makes more sense though I agree.
User avatar (0000965)
Fred (administrator)
2011-12-10 17:22

It wouldn't get confusing when zoomed in, rather when zoomed out as they approach each other and eventually overlap.

I think it would always be in all data from a set. If we allow multiple sets at the same time, it might be reasonable to do something other than full lines as that would falsely say that all sets had ended, but we should deal with that if/when we come to it. It would be a big deviation from the current structure anyway, and not overly useful either, probably. In fact, if it was handled, it would likely use a new instance of most OLV stuff in parallel in the same app/window framework. Right now the code would probably vomit if you suggested such a thing close enough for it to hear, but it could be achieved. If it was done like I suggested ,tab or meta division per instance, then the vertical lines would still make sense.

How about dashed lines for ordinary markers and other informational stuff and solid lines for breaks and resets and other nasties?
User avatar (0000967)
BenFenner (developer)
2011-12-10 17:38

Dashed for normal and solid for severe makes perfect sense to me. Do we want colored lines? Just shades of grey? A single shade of grey? With colored flags at the top in a dedicated flag section* at the top of the first division.

*Already planned in my head months ago.
User avatar (0000970)
Fred (administrator)
2011-12-10 17:46

I like the flag bar idea :-)

We do want colours, and they should be configurable somehow too, with defaults provided by whatever is generating them.

FreeEMS will mark resets with red and logging drops with yellow, and errors with orange, or something like that. This sounds non-optimal, come up with something better.

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker