Hello,
I have a naive question related to understanding the ordering of GPS/GNSS. I have two Here 3’s plugged into the two CAN ports of a cube orange +. In the parameter settings there is reference to ‘first GPS’ and ‘second GPS’ and I believe these reference to GPS_TYPE and GPS_TYPE2 respectively. Because we have two identical Here3’s, the GPS_TYPE is identical for both. I need to physically confirm which HERE3 is ‘first GPS’ and which is ‘second GPS’.
The reason for asking is the need to enter GPS_POS antenna offsets for each Here3 and of course it’s important to physically know which Here3 is ‘first’ and ‘second’ as GPS_POS references the ‘first’ and ‘second’
I realize one solution would be to remove both Here3’s and sequentially connect them and note of which HERE3 is assigned to GPS_TYPE and GPS_TYPE2 (for example) but confirming this somehow via software / parameters would be a nice confirmation. Apologize for asking this basic question, probably asked previously but could not easily find on the wiki. Thank you. Steve
CAN GPS modules are assigned on a first come, first served basis, which can be inconsistent. Here are the steps to ensure they remain fixed:
GPS1_CAN_OVRIDE (Base NODEID) and GPS2_CAN_OVRIDE (Rover NODEID) determine which physical DroneCAN GPS is used for GPS1 and GPS2. These are automatically populated at boot from the detected addresses, which are also shown in GPS1_CAN_NODEID and GPS2_CAN_NODEID, but can be overriden, if needed. You will need to determine which physical CAN GPS is assigned as GPS1 and GPS2 in order to setup the position offsets (see Sensor Position Offset are here)
The above paragraph comes from the GPS for Yaw documentation but applies equally to your intended use.
If you are intending to use a moving baseline (GPS for yaw) configuration, Here3/3+ do not support that feature.
Thank you for the reply’s
Yuri is getting at my potential concern. Just to rehash the objective, I’m applying antenna offsets to two (2) CAN GPS (Here3) and these offsets will be different for each Here3 / GPS antenna. This is not for moving base, it’s just that these two HERE3’s are separated between 30-40 cm from the controller and 60-70 cm from each other and it might be wise to apply antenna offsets in this situation.
I know very little about CAN protocol, but I’m somewhat concerned these antenna offsets could be ‘flipped’ and applied to the wrong GPS and want to eliminate any concern this could happen. I don’t know if this could happen if for some reason the GPS node number assigned to a particular CAN port / HERE3 is variable – which might be an issue if nodes are applied on a first come basis? If I’m not physically changing out GPS receivers on CAN ports, maybe then the nodes stay relatively fixed?
Currently I have a GPS_CAN_NODEID1 value of 124 assigned to the first discoverable GPS and a GPS_CAN_NODEID2 value of 125 assigned to the second discoverable GPS. If I’m interpreting things properly, I could assign GPS1_CAN_OVRIDE to be 124 and GPS2_CAN_OVRIDE to 125 and this would provide fixed node assignments. The assumption I’m making (which might be wrong) is that these fixed nodes values are then assigned / fixed to a particular CAN port on the controller and thus a specific HERE3 with a unique set of antenna offsets?
Also, I should have noticed this earlier, but in MP there is a UAVCAN GPS Order dialog. I’m uncertain what this is - but seems like it might pertain to this question.
thanks again for your help and explanations.
Currently I have a GPS_CAN_NODEID1 value of 124 assigned to the first discoverable GPS and a GPS_CAN_NODEID2 value of 125 assigned to the second discoverable GPS. If I’m interpreting things properly, I could assign GPS1_CAN_OVRIDE to be 124 and GPS2_CAN_OVRIDE to 125 and this would provide fixed node assignments.
Thanks Yuri,
This is probably a dumb question – but is there a way of linking this GPS node value back to a particular CAN port via software?
If not, I’ll need to disconnect one of the CAN GPS / HERE3, then fix the node value for the attached HERE3 and then connect the second CAN GPS / HERE3 and then fix that node value for that receiver. This way I’ll physically know which GPS is 1 and 2 – right now I’m not 100% certain which Here3 is assigned to a particular GPS node. thanks
I would always recommend manually setting a CAN Node ID for each module if you are doing a GPS for YAW Setup or calculating offsets that need to be precise.
And then use GPS1_CAN_Override + GPS2_CAN Override as Yuri said.
We have seen setups where multiple modules get assigned the ID 125 and also changed IDs depending on boot-up times as well as earlier CAN configurations and other factors.
I switched to using the CAN BUS splitter that comes with the cube and plugging both Here3 into that and plugging the splitter into CAN1 on the cube. I fixed the GPS nodes to make me feel more comfortable the offsets are applied consistently to the proper GPS. thanks
Technically you could determine which is which via Mission Planner and some parameter manipulation, but you risk fouling a perfectly good configuration by changing things around that way. It’s much cleaner and easier to simply physically unplug one to sort the order.
You pretty sure it works? Recommendation is separate ports.
Connect two Here 3 / Here 3+ CAN cable to the CAN1 and CAN 2 port of the flight controller. Another example.
There may be some error in writing, anyway, * This allows for connection of items to either I2C port, potentially allowing two GPS / Mag units to be plugged in without the Mags conflicting.
It’s all CAN communication. They can all be connected on the same CAN port. You are conflating CAN bus comms with I2C. The second CAN cable on the Here3 isn’t even used for anything and has been “reserved” for future use for years so far as I know. But even so, it can be connected to the same splitter without issue.
It seems to be working, but your right the documentation says CAN1 and CAN2 on the cube. As Yuri mentioned, CAN is a bus, so in theory it should work. It may be that the CAN1 and CAN2 cube ports are the same bus in the cube (maybe someone reading this would know).
I did as Yuri described to test the node assignments, I first fixed the GPS nodes using GPS1(2)_CAN_OVRIDE and then unplugged each Here3 individually and then looked at the GPS_CAN_NODEID1(2), if the value went to 0, then that GPS / node was disconnected.
Also because the Here3 has a magnetometer / compass the MP compass priority shows the node (address) and unplugging a particular compass indicates that node address as missing (its another check).
thanks
In case of CAN, message is broadcast by the transmitter and whichever node having address of transmitter in its receiver filter can receive the message from the bus and generate acknowledge.
in I2C, message can be received only by intended device. since in I2C, first link is established between two devices, then transfer will begin.
The issue at hand is solved. I don’t really know what you’re getting at by continuing the discussion.
With Here3, all I2C comms are handled within the peripheral node inside the Here3. All comms with the autopilot are over CAN. There should be no opportunity for I2C conflict.
