Missing Fields for pgns in pgns.dbc
therishidesai opened this issue · comments
There seems to be missing fields in the dbc file even though they exist in the json file. For example PGN127506 "DC Detailed Status", here in the json file all of the fields are defined but in the dbc file here they don't exist.
I also re-ran the dbc-exporter locally and see the same exact behavior.
@mairas please help!
@therishidesai sorry I know nothing about DBC files...
Oh I think this is actually working as expected. Looks like PGN127506 is a Fast PGN therefore it can't be replaced with a dbc.
Sorry, didn't notice the notification earlier! But you got it right; higher-level protocols can't be expressed with DBC files.
@mairas fast-packets could have their own dbc file. This way you could possibly build application that combines both dbc files and uses them for decoding. For example Actisense devices do fast-packet and ISO-TP frame assembly on hardware level so on your application you get already combined messages, which can be expressed in DBC.
and DBC also supports custom attributes which can define if packet is simple or fast-packet.
https://www.csselectronics.com/pages/can-dbc-file-database-intro
assuming you device can do frame assembly by itself or you write your own frame assembly (before decoder kicks in) there is no reason why this should not work with fast-packets
DBC files don't really work that way. The files describe the raw CAN packet fields with bit precision. Any DBC based decoder would have a strong expectation of frame length etc, and in any case, decoded fast frame or ISO-TP messages would have a completely different header structure etc.
if we exclude:
- variable length field types (could be in simple packets also)
- manufacturer based proprietary PNG detection/selection
there is no difference for n2k messages between simple and fast-packets. If both can be expressed as json/xml so can they written as DBC. Although probably none of the existing software that can import DBC would not be able to use them properly - because they work on frame level.
There is no reason why you could not write DBC "signals" for more than 8 bytes (simple packet) because CAN-FD is 64 bytes - and it is done for CAN-FD. (example for working with CAN-FD DBC for one specific application https://rtahotline.etas.com/confluence/display/RH/Importing+CAN-FD+Signals+with+a+dbc+file)
Only thing here is that instead of frames we should think of n2k messages and decoding is done for full messages. individual frames should be buffered until they form full message and then decoded.
decoding n2k message to fields/signals and assembling frames (1...n) to messages are two different things.
Looking at the raw level packets, the fast packet and ISO-TP protocols are fundamentally different from the single packet format. This matters because ALL DBC based decoders work on the raw packet level. If you would be working on the transport protocol level with already assembled long messages, you could in any case use standard canboat tools for decoding the data. Using DBCs on any other level than raw messages makes absolutely no sense.
DBC based decoder work on series of bytes. there is no difference in simple vs fast-packet when fast-packet frames are assembled to message.
Lets take PGN 130824
In raw frames one example message would be (displayed in canboat format atm):
samples/susteranna2020.raw:2020-08-22T13:52:36.950Z,3,130824,27,255,8,a0,2e,7d,99,37,21,fa,3f
samples/susteranna2020.raw:2020-08-22T13:52:36.950Z,3,130824,27,255,8,a1,38,21,34,04,7e,20,a9
samples/susteranna2020.raw:2020-08-22T13:52:36.950Z,3,130824,27,255,8,a2,01,7c,20,00,00,32,21
samples/susteranna2020.raw:2020-08-22T13:52:36.950Z,3,130824,27,255,8,a3,c0,e5,33,21,c5,22,3a
samples/susteranna2020.raw:2020-08-22T13:52:36.950Z,3,130824,27,255,8,a4,21,00,00,1d,21,00,00
samples/susteranna2020.raw:2020-08-22T13:52:36.950Z,3,130824,27,255,8,a5,50,21,61,96,51,21,ce
samples/susteranna2020.raw:2020-08-22T13:52:36.950Z,3,130824,27,255,8,a6,08,52,21,32,f7,ff,ff
This is 7 individual frames.
If you assemble these frame into n2k message before decoding (throw away 2 first bytes from first byte, and 1 first byte for next frames) You would get this (46 byte long message):
7d993721fa3f382134047e20a9017c2000003221c0e53321c5223a2100001d210000502161965121ce08522132f7
which is not different from simple packet - it is just series of bytes.
you could in any case use standard canboat tools for decoding the data. Using DBCs on any other level than raw messages makes absolutely no sense
This is your assumption that everyone wants to work with Canboat tools or with json/xml files. You could be working mostly with J1939 and have developer extensive tech stack where PGNs are stored in DBC files, maybe you stack is developed with Python. Now you want to move to marine world. It could be perfectly reasonable to tweak your stack to work with dbc+fast-packets.
There is no reason to assume that there does not exist someone that wants to use for example https://github.com/cantools/cantools (or whatever tool/library) to parse in database for N2K messages and use their own custom assembler to assemble fast-packet frames to full message before they pass these "series of bytes" to decoder.
"psedocode example"
import cantools
db = cantools.database.load_file('my_n2k_pgns.dbc')
assembler = initializeMessageAssembler(db) // takes in db to extrct fast-packet PGNs
while true
message = can_bus.recv() // lets assume this is SocketCAN device that only work with CANbus frames
// assembler checks if PGN is fast-packet from db attributes
// if not then returns `message` without modification
// if is fast-packet check if we already have received same PNG from same src + sequence counter
// if we already have received frames with this sequence, check if it is the last one
// if not then buffer that frame
// if is last one - assemble all previous frames to single message with previous frame data parts combined
n2kmessage, ok = assembler.Assemble(message)
if not ok
continue
decoded = db.decode_message(n2kmessage.arbitration_id, n2kmessage.data)
print(decoded)
there are companies even offering DBC file with fast-packet PGNS
https://www.tecnologix.it/en/css-electronics-nmea-2000-dbc-file-decode-your-marine-data.html
| Standard(s) | The DBC is based on open source NMEA 2000® databases and overlaps with the NMEA 2000® Appendix B |
|---|---|
| #PGNs | 100+ |
| #Signals | 700+ |
| Fast packets | The DBC file includes a mix of single frame and fast packet NMEA 2000® PGNs |
p.s. I am not saying that canboat DBC must support fast-packets - I am saying that it is possible to support it.