It will calibrate with excessively high offsets if the internal mag chip is oriented wrong. There is no real redundancy from the internal mag chip anyway. They are unusable in most cases due to local magnetic interference. We do not fly a single helicopter with the internal chips enabled - you will invariably get compass errors
CUAV only has two official stores - their own and their store on AliExpress.
We have used the V3x on our helicopters until this year when we switched to the Drotek Pixhawk 3 Pro, which is made in France. I am also using a custom-built linux-based autopilot running on a 64-bit A72 quad-core processor for one project. I require an I/O so have never even looked at the Nano.
My development focus will be on linux-based systems for the future, as ChibiOS is not suitable for our use and the market has been flooded with low-end STM32-based microcontrollers with no I/O. These are ok for hobby, but not suitable for commercial use. Since the divergence from the PX4 hardware specs I do not agree with ArduPilot’s focus of being able to run on any low-end unit that hits the market - it is bound to cause issues with quality and reliability. The specs on these low-end hobby-grade controls change with the wind. They are here today, gone tomorrow as everybody jumps on the next fad from STM32F4 to F7 to H7, yadda yadda.
I have found that running the code on a linux-based system where you have a real shell to interact with and diagnose problems in the subsystems is a much better long-term solution than microcontrollers. Linux can be ported to run on like STM32F7 with full-blown linux kernel with RT patches. But the F7 is woefully underpowered to do some of the things we are going to do on 64-bit multi-core A-series processors running at clock speeds in the GHz range and with memory in the GB range.
So I would say to expect “issues” with the fad-driven hardware development going on with STM32-based microcontrollers.