V5 Motor wiring

I would like to prototype some things using the V5 motors, but don’t have enough V5 control systems. Is there a way to run a V5 motor using a 0-12 volt power supply, an IQ controller, a controller with 12 volt PWM or something else?

No, there is no simple way to do this.

I would think you could do it with any embedded EVM/etc… with I2C and a power supply?

Has Vex released the I2C command Set?

I have no experience or information about I2c commands, but just googled it and Raspberry pi can do I2C.
That would be a great workaround until Vex fills the pipe line.

V5 does not use I2C, it’s RS485.

485 = much better…, sorry had my mind stuck on cortex and IQ

Either way, it’s doable, actually not that hard for someone skilled in the trade. The command set is quite simple, though proprietary, which primarily means it could change any time (the brain can update the motor firmware, completely changing the protocol if it needs to).
Great exercise nonetheless, if you want to learn, ping me and I can provide some guidance.
Of course nothing of that would be competition legal, but the goal is to learn, grow, isn’t it?

Thanks for your comments, they sound right. I’m not trying to steal Vex’s secrets, i just wanted to prototype some claw, arm and ball toss ideas but lack V5 controllers. Eventually they will be readily available. Designing something beyond following a diagram to use a Pi is beyond my resources.
If there is something that could trouble shoot motor failures, maybe someone will follow that.

Just out of curiosity-
What is the application layer on top of RS485? Is it completely proprietary or using SSI with nanoUDP? How is the address for each sensor derived - some kind of DHCP? I presume that only brain us acting as a master and that it is not duplex?

When the V5 was in Beta, someone from IFI had stated they were Android compatible and that a command set or instructions would be released. I have a lot of interest in getting that to work, so if someone solves the problem or if someone from IFI cares to clarify, I would definitely love to hear from them. Like a previous poster stated, I too don’t have the expertise to thunk this one out myself.

RS485 is the physical layer, by definition a half-duplex link.
The “link layer” would be that it uses USART-like signaling (start bit, 8bits, no parity, 1 stop) at 1.5625Mbaud
(pretty bad baud rate, 25MHz/16, hard to get common serial ports - off a 12 or 24MHz xtal, synchronize to this).
There is no addressing whatsoever - each port is really a dedicated point-to-point link, the CPU really has 25-some serial ports attached to it (implemented in the programmable logic around the ARM cores in the central ZYNQ7 chip), so what could you call the network layer is that each attached device keeps sending a frequent periodic status packet, to which the brain answers with a form of ACK or, if there is one ready, a command packet.
Yes, you read that right, the communication is initiated by the devices and it’s the brain that answers.

The motor talks in 16B fixed size messages. 16B status, 16B ack or command with the only framing being the delays for bus turn-around and between the messages.

So, what happens when you, for example, set a motor rpm on port 13?
First, the VexOS runtime assembles the command packet (16B), stores it in a buffer accessible to the programmable hardware dedicated to the port 13 and raises a flag. That’s about all from the SW point of view. Next, on the motor’s own schedule, the motor starts streaming its 16B status packet on its own dedicated wire and through ZYNQ-implemented USART HW, which DMAs it into another shared memory buffer dedicated to port 13. Once the status packet is received, the HW notices the flag and starts streaming the premade command packet (otherwise it would stream an ack packet).
Since all that happens using DMA and dedicated, per-port HW, all the devices can talk at the same time, while the brain can work on its own schedule (but still rather fast) to process the incoming data.
Last time I checked, the motors were sending the updates every 5ms…


Motors!? Android and RS485!?

If something is Android Compatible, it’s the radio in the BlueTooth mode. The brain act as BTLE central and if your phone mimicks a BTLE peripheral with some specific traits, the brain would connect to you and use particular BTLE characteristics to exchange the data.
I haven’t researched the protocol in depth, but on surface, it looked like the evolution of the Vex IQ Smart Radio protocol, which is somehow documented in the product SDK
And for the Vex IQ Blue Radio protocol, there were several sample applications published.