One of our mentors suggested this sweet production-robotics grade sensor for high precision single- or multi-turn arm sensing.
Starting from the premise that I know it’s unnecessary and I “should” throw an AS5600-based hall sensor with pwm output at absolute encoder problems in FRC, is there a reasonable way to communicate with this device and get its data back to the RIO?
An unreasonable way could be to hook it up to an RS485-serial USB adapter to a coprocessor (like RPi) and then have that coprocessor talk to the RIO, but that sounds awful and high latency.
The roboRIO has an RS232 port, so you should be able to connect to that using an RS485->RS232 transceiver chip (or if you can’t find an all-in-one, RS485->UART->RS232).
This seems less unreasonable. The converter datasheet claims some kind of built-in buffering, which also sounds like unknown latency, but at least its only a single source of unknown latency.
All RS232 ports expect (or at least tolerate) -25 V to +25 V; that’s part of the RS232 standard (technically TIA/EIA-232). Specifically, on the receiving end, a 0 is +5 to +15 V and a 1 is -5 to -15. But that’s exactly why transceivers exist. For example, the MAX232 has a charge pump to generate the appropriate positive and negative voltages from a single +5 V rail.
You don’t need 15v as other have said. A good example is an RS232/RS485 RFID reader module. Even though they both use 12v dc power (really they can handle 9v-24v) but I have the serial lines being run through an RS232 - UART adapter like these
Or I can’t find the exact rs485 I used before but one like these
Both would allow you to use the default Uart serial lines on the roborio. Those our team has used for communication from a roborio to an Arduino mega for lights and other IO controls. Never used the onboard ports for the other serial types.
The RS485 won’t work with a Rio even with a signal translator. The output baud rate is 2.5 MHz, the maximum the Rio is spec’ed to support is 230 kbps. Maybe the SSI mode (1 MHz) could be used with a signal translator (to differential) and DMA on the Rio DIO? Might get messy to keep up with, so I’d probably go with PIO on a Pi Pico, paired with a signal translator.
You’re right. I’m very confused at how RS-485 half-duplex is supposed to work with this device. The app note talks about enable and request signals, but there’s only a data+/data- pair. So you send a low “request” signal for 4 us typical, and then it replies with data, with undefined bit periods? This documentation is really bad.
Rs485 is also sometimes referenced as modbus. While the convertor boards in question might not be a max485 this article about rs485 async half-duplex talks about how the master/slave communication works in an example between two arduinos.
I have used that link as reference before for PLC to Arduino stuff. Rs485/modbus is really common and there are lots of generic Arduino libraries for it that might just work with the board even if it doesn’t have the same pinouts as the max485.
According to the PDH documentation “RS485 Ports are not currently used in FRC and are included for potential future use.” Maybe they can do something similar to this in the future.
This datasheet (which might be applicable to this part) has marginally more details; I infer that the “enable” and “request” stuff is internal to the encoder. Page 5 shows roughly what the serial communication looks like. Of course, that datasheet also says the rate is exactly 2.5M, like you originally said, so who knows.
Strictly speaking, RS485 is a physical layer spec; modbus is a protocol that runs on top of RS485 (among other things). Notably, RS485 does not specify how bus arbitration works; the user needs to provide their own mechanism for which device can be transmitting at any given time.
The MAX485 is just one transceiver chip; pretty much any compliant transceiver will behave the same. They’llLimelight, an integrated vision coprocessor have a differential pair, receiver output, transmitter input, and enable/disable pins (or sometimes, a combined TXEN/!RXEN pin).