Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

direct address transport protocol initiated through Node.send_parameter_group() results in a broadcast transfer #21

Open
DaveP987 opened this issue Nov 10, 2022 · 4 comments
Open

direct address transport protocol initiated through Node.send_parameter_group() results in a broadcast transfer #21

DaveP987 opened this issue Nov 10, 2022 · 4 comments

Comments

@DaveP987
Copy link

When sending a directed long message through Node.send_parameter_group, the resulting transfer is always broadcast. j1939.Bus.send is always seeing a destination address of 0xFF.

I added some logging in Node.send_parameter_group immediately prior to the send:

            logger.debug('send_parameter_group: to address: %s', pdu.arbitration_id.pgn.pdu_specific)
            logger.info("DKP: send_parameter_group: is_destination_specific={}, destAddr={}".format(pdu.arbitration_id.pgn.is_destination_specific, pdu.arbitration_id.destination_address))

When sending a long message that requires the use of the transport protocol, I see the following results:

DEBUG:j1939:send_parameter_group: to address: 176                  <---- correct address
DEBUG:j1939:PGN is_pdu1 00ef: True
DEBUG:j1939:            (self.pdu_format & 0xFF) < 240 00ef: True
DEBUG:j1939:            self.reserved_flag 00ef: 0
DEBUG:j1939:            self.data_page_flag 00ef: 0
DEBUG:j1939:value-result = 00efb0
DEBUG:j1939:PGN is_destination_specific efb0: True
DEBUG:j1939:PGN is_pdu1 00ef: True
DEBUG:j1939:            (self.pdu_format & 0xFF) < 240 00ef: True
DEBUG:j1939:            self.reserved_flag 00ef: 0
DEBUG:j1939:            self.data_page_flag 00ef: 0
DEBUG:j1939:value-result = 00efb0
DEBUG:j1939:PGN is_destination_specific efb0: True
INFO:j1939:DKP: j1939.send: is_destination_specific=True, destAddr=255   <---- global address

I believe the root issue is in ArbitrationID, where destination_address_value is maintained separately from pgn.pdu_specific, allowing them to hold different values that I believe should never be different. Node.send_parameter_group sets pdu.arbitration_id.pgn.pdu_specific to the destination_address, but not pdu.arbitration_id.destination_address.

My gut feel is that ArbitrationID.destination_address_value should just be a property that defers to pgn.pdu_specific. I see the following in ArbitrationID.__init__, which kinda indicates the separation may be intentional, and the commented assert makes me think the intention was that they should always be the same (yet it's been commented out...). I'm not sure if there's more to this than I'm seeing.

                        if  self.destination_address_value != self._pgn.pdu_specific:
                                logger.debug("self._pgn=%s, self.destination_address_value = %x, pgn.pdu_specific = %x" %
                                        (self._pgn, self.destination_address_value, self._pgn.pdu_specific))
#                        assert( self.destination_address_value == pgn.pdu_specific)

My workaround is to assign the destination address to both within Node.send_parameter_group, which gets me by for now, but isn't a fix, IMO:

        pdu.arbitration_id.pgn.pdu_specific = pdu.arbitration_id.destination_address = destination_address

I'm happy to take a stab at a fix, but would need some guidance/clarification on the reason for separate address storage.
@milhead2
Copy link
Owner

milhead2 commented Nov 11, 2022 via email

@DaveP987
Copy link
Author

Hi Miller,

Before I pursue any adjustments, I thought I'd setup some tests to make sure the basics were working. Right off the bat, I'm not seeing address claiming work as I expected (i actually thought I might have tripped into some insight about the global destination address for long transfers, but it turns out not...).

What I'm seeing is that "address claimed" messages appear to be ignored because the transmitted PGN (0xeeff) doesn't match the defined PGN_AC_ADDRESS_CLAIMED (0xee00), causing the check for pgn in [PGN_AC_ADDRESS_CLAIMED, ...] in Bus.notification to never be true, preventing the message from getting dispatched back to Node.

I've instantiated two nodes in a test environment, each attached to its own j1939.Bus, which are each using a test implementation of can.Bus. I see PGN_AC_ADDRESS_CLAIMED get sent by each and received by the other.

I would love to believe I'm just setting this up incorrectly, but this particular scenario seems baked in -- 0xeeff is explicitly constructed and sent and then explicitly compared to 0xee00.

This would also block the build-up of the known address list, which I would think would be super apparent. Are your tests/simulations relying on any address negotiation, and are you seeing them resolve correctly?

Step #2 was to change pgn in [PGN_AC_ADDRESS_CLAIMED, ...] to (pgn.value & 0xff00) in [PGN_AC_ADDRESS_CLAIMED, ...], which got me to another issue...

I'm at the head-scratching "how could this ever work" stage.

@DaveP987
Copy link
Author

Hi Miller,

With a few changes, I was able to get address claiming and negotiation working in a test environment, but they're definitely in the "how did this ever work?" category. I'll write up a separate issue to capture it all.

As for this issue, I'll do some experimenting and see if I can arrive at a fix.

@milhead2
Copy link
Owner

milhead2 commented Nov 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@milhead2 @DaveP987