Built a v2 pcb for this spring. Used it some for seeding, seemed like it mostly worked, except for a couple quirks here and there. Tractor sat all summer, now trying to use aog again for fall field work. I go to the field, get started and everything is working perfectly. I keep going for about half an hour, and suddenly it disengages auto steer. I press the button to re-engage and sometimes it stays engaged for a bit longer, but mostly it immediately disengages again. I’m completely puzzled by this behaviour. I have a udp setup, although I currently use usb for my ardusimple. I tried changing ino on arduino and used just usb, didn’t fix the problem, disconnect engage switch as well, also no joy. Was running v5.6.2, downloaded 5.5 didn’t make any difference. So I guess I’m throwing this out there if anyone has ideas or insight, let me know…
Also there doesn’t seem to be any pattern that I could discern, except that it maybe…….seemed to work for about quarter to half hour before it started acting up
Tried on dell latitude 5175 and Getac f110 g2, did the same thing on both of them
Have a momentary footswitch, don’t have disengage if rtk lost enabled. Using hydraulic valve, so have transducer on orbital for disengage. I have watched the disengage indicator in aog though, and haven’t seen a spike when it voluntarily disengages.
Spent most of the day on the combine so didn’t have time to tinker with it today, but next chance i’m gonna try that. Just thinking, i could maybe disconnect and disable the pressure sensor as another test, just to start eliminating possibilities.
Just an update, I disconnected my footswitch from the pcb completely, changed the settings in AOG to none and tried that. The problem did not go away. Next, I reconnected the switch and on a whim, I drastically increased the percentage for the disengage. Fingers crossed, it hasn’t been disengaging randomly since……
Yeah I agree that can be confusing…was, WAS, WAAS…
I had the pressure sensor setting turned on, and set at 30%, which seemed about right, as it would disengage as soon as I grabbed the wheel, and turned very slightly. I put it up to 50% and it still worked reasonably well, although it was a bit sticky, I’d have to make sure to turn the wheel hard enough to disengage. Now I have turned it down to 40% and it seems to work quite well.
On the dreams list it would be nice for some type small text annunciation for when steering kicks out. I know its only rtk loss, sensor, or steering button. But sometimes its hard to tell what did it.
Or debug mode which I see is in development on the teensy with messages through the serial port.
My old trimble 500 has messages like “steering disengaged by foot switch” or “steering disengaged by over speed” or “steering manual disengage” or “steering disengaged too far offline.”
Always thought that was a neat troubleshooting feature.
for the current sensor the ratio is a 0.7/0.3 ratio. This would give less affect to spikes. You could even try other ratios to see what worked best to get your overall value lower.
Hey that’s an idea…would give me a reason to tinker and hopefully learn something in the process. I guess there must be random spikes. When I would watch the display in agopen, steering wheel not moving, it would sit at a steady 20%, so I never really considered that there might be spikes because nothing registered on the display. Like @PotatoFarmer mentioned, it would be nice if it would display what caused the auto steer to disengage……
So an update, everything worked nicely for quite a few hours, and it started doing the same thing again. I tried tweaking the ratio in the ino as previously suggested, but it didn’t seem to make any meaningful difference. Spent some time tinkering with it over the next couple of days and it seemed like the sensor just wasn’t working at all…. The percentage bar in aog would stay at the same place whether I turned the wheel or not. So I went ahead and ordered a new sensor from Digi-Key to see if that would fix my problem. In the meantime I happened to study the wiring diagram and it looks like the signal wire is supposed to be connected to ground with a resistor?? I tried that with my new sensor but that didn’t seem to work, so I disconnected the signal from ground and it seemed to work like I thought it should. So my question is, does the signal actually need to be connected to ground or not? Could this be part of my problems with it disengaging randomly?
I switched to UDP and Panda. Panda works with navspark px-1122. When I turn on the steering wheel, after a while the steering wheel turns off randomly, the icon is still green. The government pwm instructions are added to the board. It’s like turning off the 6/2 valve. I turn off the automatic steering and it works again. It does it a couple of times in the first half hour, then it works fine all day. I’m going with a hydraulic hydraulic valve. Aog 5.6.2 is the current version. He also did it with USB for version 5.4.5. How can I filter out errors?
What type of relay do you use to switch on power to the 6/2 valve?
When the icon is still green, then autosteer is still on, so the pressure sensor has not been giving a change in signal.
Problem must be in power supply to 6/2 valve!
Or bad solder in signal line to relay, which is likely because problem stops when pcb, and solder joints heat up after 1/2 an hour.
I connected the signal line directly between the nano and the Bts442. I replaced the Bts442. I turned on the steering without a switch. The problem persists. When it randomly shuts off, the steering wheel is moving, meaning the 6/2 valve is not getting power. The icon remains green, but when I turn the steering wheel, it detects the pressure sensor data. and disengages the steering. The pressure sensor is fine.
At least you now know it must be the circuit including the 6/2 spool that has problem.
How many Ampere does the spool use?
How hot does the BTS 442 become during use?
Try to make a manual switch that supply 5V to the BTS 442 (direct from steady 5V to input on BTS 442, aka leg 2 ) and see if 6/2 stop working then.(still have dropouts)
Edit: reminds me to say. Check all solderings on line from nano to BTS 442 including nano leg and seating of nano to the pcb. Also check OHM of the resistor in that line.
If 6/2 stay on, then fault could be too low voltage coming from Nano to drive BTS 442
Check spec for other possible issues:
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://docs.rs-online.com/20a2/0900766b81620e29.pdf
