Any thoughts on getting rid of the A/D conversion with a separate A/D converter and power feed by using a sensor which outputs a digital signal?
Some pros:
-Directly supply voltage from +12 volt possible to sensor
-No additional HW needed
-Read directly from PWM or CAN message. PWM you could do with arduino as well, so you read when the sensor pwm is high or low and then get the duty cycle. Wouldn’t be voltage dependent.
Cons:
-Price
-Complexity?
So something like this:
or
Pros:
Cons:
CUI AMT213F-V
12 or 14-bit absolute position with multi-turn capability
• 3.3 V half-duplex RS485 - high speed 2 Mbps or adjustable data rate
• settable zero position
https://www.cuidevices.com/product/motion/rotary-encoders/absolute/modular/amt21-series
Quoted the Danfoss, around 200 eur but 15 week delivery time 
Asking for pricing on the Novotechnik one as well.
One option could be this: High-speed rotary magnetic shaft encoder RE36 - www.rls.si Needs an RS422 transceiver but should be readable with arduino with the SSI interface.
Alright, ordered this one for testing: RM44 / RM58 - up to 13 bit encoder base - www.rls.si and a magnet. Idea is to put it on the Carraro axle kingpin. Will go with a RS422 shield for arduino and use another CAN shield to dump it on the bus.
Ordered the RLS out of principle as they seem to be one of the industrial encoder companies living in the same millenium with the general public and with a webshop where you can actually order stuff…
Hello,
I like the idea of a WAS with directly a numerical output.
Seems not being a advantage of this sensor: if the output is CAN or RS, you will have to replace ADS by an adapted transiver.
Accuracy is ±0.5°, will it be enought ? I my mounting WAS angle of 0.2° make the difference between a tractor going straight or slightly turning left/right.
Math
Yeah I’m kinda contradicting the original idea but I got excited about the RS422 communication so couldn’t help my curiosity 
Well, sort of gets halfway as you get rid of the need to have a well-regulated +5 volts. Was thinking of putting one box (main control) on the roof with the IMU/tilt sensor and another canbus I/O box inside the cab (and connect the WAS to that).
As for the accuracy, that’s the error from true position, the resolution is 13 bits so 0.05 degrees, should be plenty. For the commonly used Honeywell RTY the accuracy is ±1.6% from the measuring range so shouldn’t be worse at least. Or that’s at least how I understand the accuracy in the datasheet, i.e. if you zero the sensor correctly and turn the shaft to say 45 degrees, RLS is showing 44.5 to 45.5 degrees, whereas Honeywell RTY would show from 44.28 to 45.72 degrees.
Now the Danfoss J1939 sensor is also on order, let’s see. The problem is that I’ll probably need another module is any case for the steering disengage, unless I do that with a CAN sensor as well, could as well try out with the SASA sensor I have coming up for another setup, though.
Hello
Ok. I haven’t look carreffuly at the 2 datasheet.
So you are going to test the RM44 and the Danfoss sensor ? Where did you buy the Danfoss ?
Math
That’s the plan. Need to modify the kingpin to accept both. Danfoss I bought from Holstein Hydraulik, not arrived yet.
The sensor arrived today from Slovenia. Gotta find the RS422 module and start testing.
Hello,
I am impatiently awaiting the results !
For the Danfoss sensor, did you order the one with CAN J1939 protocol or the one with CAN CANOpen protocol ?
Math
It’s J1939, CANopen is a mess imho. And you don’t wanna mix those.
Rs422 interface now underway as well.
Hello,
Yes I agree about CANOpen.
If fact my idea was:
Some peoples were interested by this motor: electric steering motor for precision agriculture China Manufacturer. This motor is power supplied by 12V and had a CAN interface but with CANOpen protocol.
So I was thinking to use CAN bus for the steering controler and put on the same CAN bus the WAS and these motor. We also could imagine to connect the IMU through this ESP32 CAN board: The CAN32—an ESP32-Based CAN Bus Board - Hackster.io (in addition this board is 12V power supplied).
So from the autosteering box, we just have to distribute the CAN bus + 12V bus to the orthers modules (motor, WAS and eventually IMU with ESP 32 CAN). And the CAN bus is a bus specially design for communication between module inside a vehicule, so seems to be a perfect solution.
But in the same time, I read some documents about CANOpen (that I doesn’t know before): and yes the protocol is too complex for what we want to do. Too high level protocol, hard to implement with Arduino I think.
So to bad that this motor use CANOpen protocol and not J1939 !
Math
Yeah CANOpen is kind of like a bad compromise for everybody
Got the RS422 converter now so can get to testing some late night in the near future. Also trying to price the Gefran GRA sensor, that’s the same one as the Danfoss one but Gefran is the OE manufacturer for the sensor
Okay, the J1939 sensor arrived now. It actually even has the Gefran part number on it, so that’s where it comes from. Direct sourcing a second one from them.
Works like charm on the bench, set the message rate to 40 ms via specific PGN and off she goes. Gives a dual reading as the sensor is dual channel as well.
Hello,
Nice ! Ordering directly from Gefran is cheaper than from Danfoss ?
Have you thinking how to manage the WAS setup with AgOpenGPS sensor 0 and convertion between sensor angle and wheel angle (assuming that depending on the sensor mounting, absolute numerical angle output (in degree) of the sensor will not necessary be egal to wheel angle) ?
Perhaps the steerSettings.wasOffset parameter send from AgOpenGPS to Arduino (increment of 1 ?) can be reused for centering the sensor, with a slight .INO modification with a convention 1 = 0,1°. Then the 0° of sensor can be adjusted by increment of 0,1°.
For convertion of sensor angle into wheel angle, the steerSettings.steerSensorCounts can be reused as a convertion coefficient: wheel angle = k * sensor absolute angle.
What do you think ?
Math
About 70% of the price directly.
Sensor sends 0-3599 value so it actually works directly with AOG, of course needs the read from bus as aseparate function in the ino
Have I not looked properly or where can I find the gefran part number?
So it’s about 160 USD?
It looks promising 
Its the DS18… one, you can also configure it on gefran website for different options