Send PGN 32736 Back to Aog for Machine controller
Send PGN 32761 Back to Aog for Section Switches
I dont think i understand. i also hooked light to pin 5 on nano (section 1) and no response
Yes it should
1 Like
I wonder what im doing wrong. Its an aftermarket nano. Would an genuine nano make a difference. Using it with one of these
powered with 9 volts on VIN and gnd.
???
I just powered my nano from usb power for now. an aftermarket nano should work. Looks like the right ethernet module. I justed hooked up 4 relay module and it worked. Sorry don’t have office time now as busy seeding so cant look right now exactly which version my udp machine control is from. Somewhere Brian mentioned which one to try and thats the one i used. And yes i’m using lastest 4.3 version
1 Like
Sorry, i ran out of time with the udp machine module. That will be next!
There was a bug saving Overshoot reduction. I know some were saying getting back to the line caused the vehicle to oscillate, so double check if your settings isn’t set to 0.1 Generally a good setting is 1.0
The fix is in the updated release - no version change at all https://github.com/farmerbriantee/AgOpenGPS/releases/tag/4.3.10
1 Like
Hi Brian,
why do you always update the releases with the same Version number? This can get really confusing. Why not counting up the last digit for small improvements?
Which Version do you have?
4.3.10
Ah ok. But which one? The one with feature X or without
3 Likes
I’m guessing it is to do with the fact that Arduino version has to match AOG. But I agree, it kind of defeats the object of incremental version fixes.
1 Like
I thought the different 4.3.10 releases did not have different features. On bug fixing you would unlikely want to have one bug fixed but another one not and then unlikely seeking a version in-between two.
I’m not against having versions increased, I’d just prefer to leave it up to the ones that take care of the hard work and let them try to safe their effort during the busy days. Getting two bugs fixed is better than having one bug fixed plus a perfect version tracking history and documentation.
But for this we could only check in Arduino code the first 2 numbers. And if there is a change in Arduino communication we need to increase the second number.
With the saved settings from AOG there is also a solution. I added the following code to the Program.cs
if (Mutex.WaitOne(TimeSpan.Zero, true))
{
// Copy user settings from previous application version if necessary
//https://stackoverflow.com/questions/23924183/keep-users-settings-after-altering-assembly-file-version/47921377
if (Settings.Default.UpdateSettings)
{
Settings.Default.Upgrade();
Settings.Default.UpdateSettings = false;
Settings.Default.Save();
}
if (Vehicle.Default.UpdateSettings)
{
Vehicle.Default.Upgrade();
Vehicle.Default.UpdateSettings = false;
Vehicle.Default.Save();
}
So it tries to recover Settings from the previous Settings file.
As far as I can see, it works as aspected.
The only important thing is, it is dependent of the file name and path of the AgOpenGPS.exe.
Yes i know, not ideal, but neither is changing version numbers all the time either. the only important part is the 4.3 out of the 4.3.10 for vehicle/tool/environment settings, but the .10 is used in the arduino code as well for versioning.
I made the arduino code dependent on AOG version with much opposition, but to do it for every little fix, that is not the easiest either to access the steer box, possibly open it, and update the Arduino.
The other option is to just wait with the fixes till there are enough of them - or be like Adobe and update constantly. One of the downsides is we don’t want to test it for 3 months and release a stable version either.
4.3.10 is pretty stable, there is that overshoot reduction thing, setting skip to more then 6 crashes on uturn form, but other then that, not a lot. Not sure best path forward