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?
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.
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.
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.
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?