Here2 CAN vs i2c

(Trip Lee) #1

maybe this question is a bit too low level for this forum, but im very curious!
can someone point me toward the post or the wiki document or something that lists why CAN is now the preferred method for communication with the here2 gps? or explain it?

this is listed as a reference, but the link is broken:
https://docs.cubepilot.org/user-guides/here-2/here-2-instruction

there are references to it in multiple posts and ive been searching this forum and the ardupilot forum extensively for either the post saying it is the preference, or something explaining why.

1 Like
(Ian ) #2

The main reason is the ability to free up a serial port for more uses , if you build is using multiple devised like dual GPS, telemetry radio, smart port input and a companion Computer then serial ports become limited.

Moving the GPS to CAN means your able to free up two Serial ports for other use.

This is the biggest benefit for general users.

The technical benefits are there too because the Here 2 has built in Baro and SOC as well as the GPS and compass, these are not accessible via serial or I2C but these can be accessed over CAN but that’s more for advanced users and system builders.

1 Like
(David B Bitton) #3

Understand that the constituent components in a Here device communicate with the Cube using more than one connection and protocol. The GPS data is traditionally transmitted via a UART connection and the compass is what communicates via I2C. I2C is very susceptible to outside interference. CAN is used in automobiles, so you can imagine it’s tolerance for outside interference. Once you go CAN – I assume --, all data is transferred via a CAN bus connection to the Cube. The data protocol on top of the physical CAN layer is UAVCAN.

1 Like
(Danielle Rowse) #4

@sidbh - the link above is broken?

(Trip Lee) #5

ok that makes sense. i guess i’m not running enough extra peripherals to see this as an issue yet, but can appreciate having the headroom for when i will need it. i have seen issues with the compass, especially when running a longer cable to the gps puck due to craft size

will this allow for truly redundant gps, compass, and baro inputs? and would it allow for mixing of multiple baro and gps inputs from multiple Here2s?

Thanks for the info guys

(TunaLobster) #6

Updated link is here. That should be the same information IIRC. https://docs.cubepilot.org/user-guides/here-2/here-2-can-mode-instruction