Mow.XML.txt (16.1 KB)
I’m sure you don’t need this now but here it is.
Thinking about the save routine. I feels awfully clumsy to me. Could a flag be set on entering the form and when the green button lower right clicked the user asked if they want to save changes?
How is the current sensor for autosteer disengagement connected to the pcb v2? And what kind of sensor is used?
I’ve got a couple hundred acres under v5 now and it’s great! Nice work everyone with a huge thank you to Brian!
Well changes are saved as soon as you change them for the current vehicle. It is your decision if you want to save those changes to the vehicle or not.
The green checkmark isn’t actually the save, once you leave a particular submenu, anything you changed is saved for the current vehicle. But not saved for the particular vehicle.
Or maybe it should? What do others think? Should it overwrite the existing vehicle when you leave config?
I will see about this, yes!
Hi Bennet,
The current sensor is connected to A0 of the arduino.
The assumption is a 4-20ma hydraulic pressure sensor which measures to about 250BAR.
Using a 250Ohm resistor to convert that current to a 1-5v signal.
But it is converting 1-5v input to 0-250 BAR pressure value. And the switch off threshold can be set in AgOpenGPS, so anything that suits your needs can be attached to A0 as long as it makes a bit of sense 
Does that answer your question?
Finally I had some time to debug a problem I have been suffering in my gps serial interface with all v5 versions. Sometimes the sentences appear to be seriously late when arriving to AgIO. Usually happens if I start my receiver before launching AgIO.
The problem is that AgIO reads data from input buffer one sentence at a time (when new data arrives). If the serial buffer has - for any reason - more than one sentence waiting, the oldest one will be handled. It will never again catch up. The parser can already handle multiple sentences, so in sp_DataReceivedGPS() I changed
string sentence = spGPS.ReadLine();
to
string sentence = spGPS.ReadExisting();
to read the whole buffer instead of just one sentence and all my problems disappeared.
I’m really not an expert in this area so I’m asking if this is a proper thing to do at all? It’s really hard to find the root cause of the problem, but this way data stream would at least recover without resetting the connection.
You can’t imagine how many times it was switched between the two finding the best one. The disadvantage of the ReadExisting is many more async calls. With ReadLine, every time there is a line, it calls the parser - just as ReadExisting does except far less times. The parser won’t parse an incomplete sentence anyway so it wastes a bunch of time sending chunks till it does.
I’m not sure why ReadLine would cause a delay since as soon as it sees a CR, it sends it to the parser, its parsed, and returns only once instead of a bunch of times.
I just don’t know at all, but if it fixes it, that is great.
What is your antenna setup? Make, etc
I have the notorius Emlid, it must be part of the problem as nobody else has reported similar issue. Good to hear you have thought about this, and I see your point. I’ve got to think a better way but I’ll use this as a workaround anyway until that as it seems to work.
The thing is, what happens if a sentence arrives immediately after another, before the first one was ever handled? Or if there are several lines in the buffer from the beginning. Not likely but in sw unlikely and unwanted things can happen sometimes. We handle the first one, the other will wait until the next line arrives. Then we handle the second one, but the latest waits until next line. And so on, we have old data flowing in all the time.
Are you sending only GGA and VTG? There is a fix for that in Emlid.
I think its like 12 sentences otherwise
Yes, and only 5Hz so it’s definitely not the amount of data causing this.
Hello, today i started seeding corn with the new V5, and it works great.
But sometimes the Motor stops steering, and when i press the Button again, or reload my Ab Line or Curve it works again. Is there a fix or does somebody else experience this problem?
But nevertheless great work everyone 
It makes sense to me the way vehicles are saved now.
After much discussion, when you make changes and exit in the Config form, Steer form, or exit, the current settings are saved to the current vehicle.
If you enter a new vehicle name and hit save - that will be the one saved to.
If you clicks “Save As” that will be saved to and all subsequent saves made to it.
This will come out in v5.1.4
How are these two different?
So it just reads an output from a current sensor in 1-5V range. I just thought there would be a specific sensor because in the setting a limit in amps can be set, not an abstract value. Will try out my sensor that I already used.
But anyways thank you for the explanation 
Will try it out in a couple of days
how do I easily save a change in the steer form to the vehicle I actually use? I think this ‘current vehicle pattern’ makes it unnecessary complicated. Try to explain it: I use the same vehicle for days, do little changes in the settings during work the first day and forget to save it. It is all fine because next day when I open AOG it is all okay due to current vehicle. Then one day I swap to another vehicle, load it do my work. But when I come back to the first vehicle and load the file I have old settings and wonder what happend.
Could it be a solution to erase the buffer at startup (after AGIO and AOG have connected)?
Save As saves it to an existing vehicle file, Save makes a new vehicle file.