canboat / canboat

I am trying to print PGN 126464. This PGN is somewhat special as it has repeating fieldset but is missing field count reference field. It seems that analyzer is unable to print it anything about it.

PGN definition is here:

canboat/analyzer/pgn.h

Lines 1860 to 1868 in 3bac58f

    
           {"PGN List (Transmit and Receive)", 
        
            126464, 
        
            PACKET_COMPLETE, 
        
            PACKET_FAST, 
        
            {LOOKUP_FIELD("Function Code", BYTES(1), PGN_LIST_FUNCTION), PGN_FIELD("PGN", NULL), END_OF_FIELDS}, 
        
            .interval        = UINT16_MAX, 
        
            .repeatingField1 = UINT8_MAX, 
        
            .repeatingCount1 = 1, 
        
            .repeatingStart1 = 2}

Example message:

echo "2022-10-11T11:47:22Z,3,126464,127,255,7,01,04,ff,01,11,fb,01" | ./rel/linux-x86_64/analyzer -json -debug -raw -si

data bytes should map to fields as such:

0x01,             // 1 = receive list
0x04, 0xFF, 0x01, // PGN 130820    <-- first set of fields for field set 1
0x11, 0xFB, 0x01, // PGN 129809   <-- second set of fields for field set 1

This is made up NMEA message as I could not find any samples for it but I think it should be correctly created.

Testing with current version:

echo "2022-10-11T11:47:22Z,3,126464,127,255,7,01,04,ff,01,11,fb,01" | ./rel/linux-x86_64/analyzer -json -debug -raw -si
{"version":"4.8.1","units":"si","showLookupValues":false}
INFO 2022-11-09T21:23:45.907Z [analyzer] Assuming normal format with one line per frame
2022-10-11T11:47:22Z 3 127 255 126464 : 01 04 ff 01 11 fb 01

Testing with older version (commit: bb41e9c ):

echo "2022-10-11T11:47:22Z,3,126464,127,255,7,01,04,ff,01,11,fb,01" | ./rel/linux-x86_64/analyzer -json -debug -raw -si
{"version":"2.0.0","units":"si"}
INFO 2022-11-09T21:18:44.605Z [analyzer] Assuming normal format with one line per packet
INFO 2022-11-09T21:18:44.605Z [analyzer] New PGN 126464 for device 127 (heap 11151 bytes)
{"timestamp":"2022-10-11T11:47:22Z","prio":3,"src":127,"dst":255,"pgn":126464,"description":"PGN List (Transmit and Receive)"}
2022-10-11T11:47:22Z 3 127 255 126464 : 01 04 ff 01 11 fb 01

I think the output should be something like that:

{
  "timestamp": "2022-10-11T11:47:22Z",
  "prio": 3,
  "src": 127,
  "dst": 255,
  "pgn": 126464,
  "description": "PGN List (Transmit and Receive)",
  "fields": {
    "Function Code": {
      "value": "Receive PGN list",
      "bytes": "01"
    },
    "list": [
      {
        "PGN": {
          "value": 130820,
          "bytes": "04 FF 01"
        }
      },
      {
        "PGN": {
          "value": 129809,
          "bytes": "11 FB 01"
        }
      }
    ]
  }
}

2 sets of fields and each set contains single field

Hi, just is case this is useful: the sample above doesn't work because 126464 is fast, so the first 2 bytes of data must be the seqid/frame and the size. This means you need to can frames:
2022-10-11-11:47:22,3,126464,127,255,8,20,07,01,04,ff,01,11,fb
2022-10-11-11:47:22,3,126464,127,255,8,21,01,ff,ff,ff,ff,ff,ff

These are correctly interpreted by analyzer:
{"timestamp":"2022-10-11-11:47:22","prio":3,"src":127,"dst":255,"pgn":126464,"description":"PGN List (Transmit and Receive)","fields":{"Function Code":{"value":"Receive PGN list","bytes":"01"},"list":[{"PGN":{"value":130820,"bytes":"04 FF 01"}},{"PGN":{"value":129809,"bytes":"11 FB 01"}}]}}

Actisense devices like NGT-1/W2K-1 are assembling fast-packets/iso-tp frames to messages and output only fully assembled messages. This message is valid actisense-serial output so I think it should be analyzed even it is not 2 lines.

2 frames making 1 message

echo "2022-10-11-11:47:22,3,126464,127,255,8,20,07,01,04,ff,01,11,fb
2022-10-11-11:47:22,3,126464,127,255,8,21,01,ff,ff,ff,ff,ff,ff" | ./rel/linux-x86_64/analyzer -json -debug -raw -si
{"version":"4.9.1","units":"si","showLookupValues":false}
INFO 2022-11-15T06:07:26.226Z [analyzer] Assuming normal format with one line per frame
2022-10-11-11:47:22 3 127 255 126464 : 20 07 01 04 ff 01 11 fb
{"timestamp":"2022-10-11-11:47:22","prio":3,"src":127,"dst":255,"pgn":126464,"description":"PGN List (Transmit and Receive)","fields":{"Function Code":{"value":"Receive PGN list","bytes":"01"},"list":[{"PGN":{"value":130820,"bytes":"04 FF 01"}},{"PGN":{"value":129809,"bytes":"11 FB 01"}}]}}
2022-10-11-11:47:22 3 127 255 126464 : 21 01 ff ff ff ff ff ff

fully assembled message

echo "2022-10-11T11:47:22Z,3,126464,127,255,7,01,04,ff,01,11,fb,01" | ./rel/linux-x86_64/analyzer -json -debug -raw -si
{"version":"4.9.1","units":"si","showLookupValues":false}
INFO 2022-11-15T06:07:45.388Z [analyzer] Assuming normal format with one line per frame
2022-10-11T11:47:22Z 3 127 255 126464 : 01 04 ff 01 11 fb 01

I'm not sure what to view as authoritative in this situation, but in this thread:
http://www.auelectronics.com/forum/index.php?PHPSESSID=ns0k786e6jvacog3re04jh6e50&topic=421.msg1185#msg1185

Is this assertion:
2. Parameter Groups not defined as single frame shall not be transmitted without using the first two bytes of the first frame to indicate frame count, sequence counter, and message size even if the message size is 8-bytes or less.

If relaxed a recognizer pulling data from a canbus transport would have to special case this pgn. The challenge is distinguishing a valid fast continuation packet (1st byte would be sequence/frame, followed by 7 bytes of data), potentially out of order in the sequence, from a packet that puts the function code (in your case 01 so a sequence 0, frame 1) followed by 7 data bytes from the intent. My personal view is this protocol is really hard to interpret correctly already, and what seems to me to be an error shuld be treated as such.

I think this has todo more how Canboat works.

Canboat is set of different tools. Some of them read different sources (like actisense-reader, ikonvert-serial, candump2analyzer) and format this data in one common format that is piped into analyzer command. Some of these (candump2analyzer) just forward raw nmea frames as these sources do not do frame assembly by themselves. But Actisense devices (that actisense-reader is meant to pipe) have fast-packet/iso-tp assembly built in to their hardware.

analyzer tries at startup do detect which format is piped into it. This is done here

and detection logic is here

canboat/analyzer/analyzer.c

Line 366 in 172481f

static enum RawFormats detectFormat(const char *msg)

so in this example it detects as MULTIPACKETS_SEPARATE

canboat/analyzer/analyzer.c

Lines 419 to 420 in 172481f

    
           logInfo("Assuming normal format with one line per frame\n"); 
        
           multiPackets = MULTIPACKETS_SEPARATE;

but it would be better is this is used MULTIPACKETS_COALESCED

canboat/analyzer/analyzer.c

Lines 415 to 416 in 172481f

    
           logInfo("Detected normal format with all frames on one line\n"); 
        
           multiPackets = MULTIPACKETS_COALESCED;

this is potentially problematic for users using MULTIPACKETS_COALESCED devices when first line that is used for detection happens to be small PNG that falls into MULTIPACKETS_SEPARATE block

Thanks, very helpful. Our current focus is code that processes can frames directly. We use dump files of various sorts for testing, validation, and debugging. For that we translate any dump files with fast frames on a single line (coalesced) into a single line per can packet (necessary to exercise our logic fully). In the future we may need to provide direct support for gateway devices that generate these intermediate formats.

Hi guys, in my absence you have determined exactly what I think Russ is hitting; if I understand it correctly his use case is passing a single PGN to a new analyser process. And a new process is used for every PGN.

This is not how I use it; I use a pipeline as explained in the wiki. In this use case it is able to auto determine the format but it might be a few lines before it settles on the right format. In a continuously running program this is no issue.

For you use case I think the solution is to add a flag so you can control the analyser multi packets mode from the command line.

I am somewhat restricted for the next 2 weeks in my internet access as I need to ssh to a remote machine from my iPad, as I am cruising in Panama.

So either you do it yourself or wait a while. If you create a PR I will merge it.

	{"PGN List (Transmit and Receive)",
	126464,
	PACKET_COMPLETE,
	PACKET_FAST,
	{LOOKUP_FIELD("Function Code", BYTES(1), PGN_LIST_FUNCTION), PGN_FIELD("PGN", NULL), END_OF_FIELDS},
	.interval = UINT16_MAX,
	.repeatingField1 = UINT8_MAX,
	.repeatingCount1 = 1,
	.repeatingStart1 = 2}

	logInfo("Assuming normal format with one line per frame\n");
	multiPackets = MULTIPACKETS_SEPARATE;

	logInfo("Detected normal format with all frames on one line\n");
	multiPackets = MULTIPACKETS_COALESCED;

Analyzer is unable to print repeating fieldset for PGN 126464