I have just migrated the text into a separate LaTeX doc as proposed in the guidelines thread:
UCANPHY_Specification.pdf (2.6 MB)
The doc is maintained on GitHub at https://github.com/UAVCAN/ucanphy; let me know if you lack access.
This draft has been waiting long enough, so I would like to set a deadline for change proposals to Oct 1st. If there are no pending changes or unreviewed proposals by that date, the standard will go live in its current form. If there are change requests, we will define a new deadline appropriately.
1 Like
We sudgest to use the 502585-0670 (plug for it 502578-0600) as connector while we want to power up the board from a battery. We already use this connector in our cases.
Here is the pin description on the picture: 
That’s an interesting connector indeed – up to 100 V, 2 A per contact. Whether it’s worth expanding the spec for the sake of the extra power is unclear. Can you provide the use cases you envision for this connector? Are there any specific power supply requirements? Do you want to set up a voting session?
Paging @dmitry.ramensky @alexklimaj
Question: is there any standard connector for CAN data use on drones that is more robust than the JST-GH 4 pin connector? D-Sub is far too big and even M8 seems a bit large/heavy, and both are expensive compared to JST-GH. I’m asking out of curiosity because earlier this year we encountered a crash due to failure of one of the JST-GH connectors (it was damaged during cable management and nobody noticed, and we aren’t running redundant interfaces).
All onboard system of VTOL assebled using this connectors. UAVCAN to PWM node (with DC-DC converter from battery voltage to 5V output on servo) for example
We have the large plane. Nodes which control ailerons servos are too far, and take about 1.5 amps in peak load. If I provide a higher voltage to end point than I can use smaller wires. Also i can prevent the shut down of all subsystems in case of short circuit in particular node.
Yes, if you mind.
The rules for voting are outlined in the SIG guidelines (they are quite minimalistic). For this specific session, let us schedule the deadline on Sep 27, which is one week from now. Every Consortium member is allowed to cast one vote (please select a delegate and avoid casting more than one vote; if you voted by mistake, please, reassign your vote to “abstain”). At least half of the consortium members shall cast their vote to render the results valid (which would be 7 out of 13). Shall the vote fail, the proposal will not be accepted by default.
This simple majority vote is to determine if there is interest in the new connector option exactly as outlined by @Sainquake above. Shall it be agreed that there is interest, the technical details will be settled separately afterward.
Restarting the vote due to a procedural error.
Extend the UCANPHY specification with a new high-voltage PCB-level connector Molex CLIK-Mate 502585-0670 6-pin
- yes
- no
- abstain
0 voters
Alright, I’ll abstain (although I don’t appear to be able to retract my vote).
Yeah, this is an annoying limitation of the voting feature here: once you voted, you can’t remove your vote. I added “abstain” to work around this.
The proposal has been rejected by default. Summary:
- Voted Yes: Innopolis University, AmadorUAVs, LX Robotics
- Voted No: Zubax Robotics, Volz Servo, ArduPilot
- Abstained: Dronecode, ARK Electronics
- No-show: Revolve NTNU, MKS Servo, Hitec Commercial Solutions, MiSmart, Flytrex
The document is out: