keomabrun / k7 Goto Github PK

1. tx_count is missing in data lines (link)
2. start_date and end_date are not iso8601 strings (link)
3. datetime is not an iso8601 string (link1, link2, link3)

Related discussions / issue tickets:

• keomabrun/dense_connectivity_datasets#3 (comment)
• #7

The --check feature should check if the datetime format is the right one.

The current channels column requires extra parsing function and is not useful in practice.
The channel is either known or unknown.

For instance:

• in Mercartor, the channel in know so the value with be for instance 11
• in SMIP, the channel value in unknown so the value will be empty (no value between to commas)

This new format does not allow to group multiple channels (when multiple channels have the same RSSI value for instance) but that is rarely the case and the grouping (compression) does not bring a huge benefice.

If the channel is unknown, then the script that use the trace (e.g the 6tisch simulator) can set all the channels to the same value.

The channels that were used during the trace collection are supposed to be provided in the JSON header.

This reverts #2

As SMIP only reports aggregated traces, a conversion with basic rules need to be applied in order to convert traces into K7.
Before assuming a link is not available (i.e PDR=0), we should wait for 3 HR.

From LD:

The discovery frame is at least 256*256 slots long, that is 475.136s.
22.5 mins is 1350s.
Ceil(1350/475.136) = 3.
So my expectation is that we could hear a max of 3 discovery packets per HR under regular circumstances.
The only time this could be exceeded that I can think of is if we are unable to generate an HR (due to e.g. queue congestion), then the counters are not cleared and we try to generate the HR one interval later.

K7 should not be a matrix. That choice should be left to the script that use the trace.

• "11" -> (11,)
• "11-25" -> (11,12,13,14,15,16,17,18,19,20,21,22,23,24,25)