First, I’ll admit that it does pair nicely with the stock components (namely, legacy PWM ESCs). But…
The documentation is weak, at best, making it a bit of a game of trial and error to configure properly. This wasn’t difficult, but less experienced users might find it a difficult to impossible task to guess properly. There are several completely unlabeled/undocumented (unused?) GH headers that still have me baffled.
It would be nice to have an option to use the board as either the top or bottom plate of the frame (optionally securing all hardware inside the frame), but even if you shave the little keyed “nubs” off of the arm clamps, SMD components prevent you from orienting the board as a bottom plate, so it really must remain on top.
Further, I’m disappointed that the LEDs are hard wired on AUX 1 and 2, while the intended ESC outputs are Main 1-4 (with 5-8 supported with similar Amass connectors for X8 configs). This means that any upgrade to the ESCs becomes difficult if not impossible to fully leverage (BDSHOT).
My question is this: given that the LEDs must remain on Timer1, is it advisable to use AUX3-6 for BDSHOT, or will that work poorly due to timer grouping?
If it’s the latter, then I’m calling this board a swing and a miss for CubePilot.
Maybe not. Playing around with a Orange+ on the bench configuring Dshot for just Aux3-6 configures all AUX outputs for Dshot becaue of the shared timers. So then the LED’s wouldn’t work. Dshot300 on Main outs as you say I guess…
I’m seeing some interesting behavior here as well. Thought I was gonna put it down for the night, but now I’ll try AUX3-6 with DSHOT and BDSHOT just for giggles.
Have not been able to get ESC RPM to register at all, either with permutations of BDSHOT on the AUX ports or via serial telemetry. It’s not helping that SERIAL4 appears DOA (it was working on the ADS-B carrier but has ceased functioning on the EDU450 carrier).
UPDATE: More weird behavior. The reason I wasn’t observing ESC telemetry is that the ESCs are numbered 10-13, which became obvious in the log. I’ve never seen Motor1 show up as anything other than ESC index 0. This may be a result of leaving BRD_IO_DSHOT enabled whilst testing the AUX pins. Anyway, I think it’s pointless to continue trying to force AUX outputs to work the way I prefer, and I’ll simply use MAIN out as discussed.
Probably unrelated to this particular carrier board (but maybe a 4.5 beta1 issue), if I leave RC_PROTOCOLS set to 1, and I do not have my ELRS transmitter powered when AP boots, I get a bunch of nuisance messages about attempts to decode the GHOST protocol.
I still haven’t gotten the damn thing flying because I assembled it completely before realizing that the RVMASK parameter doesn’t seem to work for DSHOT on IOMCU (4.5 beta2), and I really don’t have the time or inclination to tear it apart right now and resolder the motor wires that are buried in the middle. For now, that’ll be a project for another day.
I feel some criticism of this carrier board is warranted. The cost of the board ($250 US, without an autopilot) is prohibitive to the casual user who just wants a near RTF experience. Thus, the target audience would appear to be those interested in frequent modification, with a lot of headers and I/O neatly arranged right on top.
However, a logical first modification would almost certainly include DSHOT ESCs, and you can read above why that’s a frustrating endeavor. Forcing the LEDs (a neat but unnecessary feature) into a situation that makes the FMU I/O pins nearly useless was a poor design choice, despite some otherwise elegant features. Also, IOMCU 1-4 are only available via fiddly Amass connectors. It would’ve been nice to double those on a DuPont header up top.
I bought this board in part because I wanted to sandwich all the hardware between the top and bottom plates and place the battery on top, even with the prop plane. But that’s not an option with this design, either. In fairness, that doesn’t appear to have been the design intent, but it would’ve taken very little effort to move 6-9 SMD components to allow for that option.
I never did get anything talking on SERIAL4. It’s either a carrier board flaw or a defect in this example, further justifying some criticism. I only ever connected previously working components, so I can be reasonably sure I didn’t short or damage anything during assembly.
I really appreciate CubePilot and their support of the community, but I think they missed the mark a coupe of times recently. Namely on this carrier board, and I have to admit a little disappointment in the Here4 as well (the Neo-F9P was an odd choice for what is otherwise premium hardware, in my humble opinion, and I won’t be buying one anytime soon).
