I think, (But matt / franz would know more than me) that the issue, is that the F9P’s dont give heading without RTK correction, so as soon as its lost, the ESP code has to revert to fix-fix, which in itself shouldnt be a problem, but for some reason it is for me. The problem is that when I loose RTK fix, my gps slows down / lags to 5hz or less, rather than 8, which is to slow and causes the steering to occilate…I am certain it can be fixed / no doubt matt already has / can sort it at some point. At the moment they have both been working super hard to try and get the main math / calculation sorted so it is reliable / correct in all areas of the world.
Hi
Does someone have a schematic of how to wire the connections of the two ArduSimple to the ESP32Duino with MTZ8302 AOG_GPS_ESP32. Instead of looking at blurry pictures.
I can’t get it to work so would be grateful if someone has it up and running to make a schematic.
thx
1 Like
My project thread as some photos from mine which may help?
I have just tested the dual antenna setup using F9P’s and can confirm that there is very accurate heading and roll without RTK fix ( found out by accident as I had trouble with the NTRIP to dual antenna connection for a while) Its only the Position which will degrade. It makes sense as the moving base pair is basically running as a local hardwired RTK pair.
1 Like
Good to hear. I would have assumed this as you say but was concerned about @darrenjlobb experience.
Who’s ESP code are you using? Matt or Franz?
Were you actually driving on autosteer?
I had no problem with heading, or position other than obviously not being RTK corrected…but it slowed to 4-5hz causing steering to be very slow to react at anything other than low speed would cause it to drift across the line alot…
Does anyone know if there is a way to get the F9P’s to keep the last RTK fix when they loose corrections? Rather than just dropping it totally, as then it causes the position to jump a meter or whatever, id rather it just stopped on its last correction so the workflow could carry on without having to adjust the A-B line…If that makes sense?
Mine (single receiver) doesn’t do that. Stays on line.
Same here. After losing corrections, even for a long time, if they recover them again from the same station, the position is the same as before it was lost.
I am just testing static at present, using Matt’s code. I think his code introduces a filter when GPS quality decreases, maybe this is the problem? Filters inside a control loop do worry me and can cause instability, much better to rely on the overall loop response to do any damping IMO, but I have seen the PPS indicator in AOG worryingly vary between 3 and 6 Hz although the figure above says 8Hz, (v4.3.10) Possible due to computer resource load as I am running multiple other programsat the same time.
The loss of RTK inevitably will cause a shift in position. It will use the last base reading for a minute or so, but eventually reverts to single mode. Maybe the problem is why the RTK is lost? I found the f9p to be rock solid on RTK using a local base station, or even 30 km away. The weak link maybe the radio channel.
Hi Darren. The two f9p work about 240 sec longer when you loos RTK.
Problem is that Agopengps stops when no ntrip is coming in.
Its very rare to loose RTK, but i rely on 4g for ntrip corrections, we have many many hills, and its simply the only way to get the signal to the rover… 95% of the time its just fine, but occasionally there are some dead spots, the F9P’s do hang on for a while without corrections, but then they revert to single, and position shifts… I cant understand the position will shift, as, well, if it didn’t, and the position is always the same, clearly RTK isn’t needed as thats the entire point to counteract drift right?! What would just be super useful, is IF you are in a field with RTK, and then you LOOSE RTK, for it to just base calculations always on last known RTK correction, rather than doing that for 240seconds or whatever it is, and then reverting to single…
Basically would be cool if there was a way to extend the 240 seconds to forever until either new RTK correction is received, or F9P is rebooted… if that makes sense?
Weirdly today, I was able to get 8hz with RTK dropped, so steering carried on working find, just had to shift the line, Had a fuel runtime errors pop up mind after long use today, will post photos in the bug thread though.
I have a permanent position on F9P even after a few days, despite the fact that I turn off the computer after finishing work the next day after restarting, the A-B lines match.
However, when the base station’s F9P power is turned off and then on again, the position shifts significantly.
There were situations that during work fell home internet which is connected to a wifi ntripmaster base station. At that time I called my wife who connected the base station to the phone’s wifi and I could continue to procure and the position has never changed in such situations.
Not sure why that would be, surely rebooted or not, if base station hasn’t moved, and everything is on / connected, your position should be identical any day of the week… Mine seems to be anyway…
I have been using it again today and found some interesting things…I find actually I don’t think the position change is the problem, yes there is a small one, but this is normal / expected once you loose your RTK fix, What I am actually noticing, is that while you are actively on autosteer, loosing NTRIP connection seems to cause AOG to hang up at certain points… I have noticed today that when it is “waiting” for a reconnect, it will randomly stop steering, and the data on screen stops updating, If you don’t pay attension, you would hardly notice, as it just returns and carries on after a few seconds normally, on level ground once you are moving along, You would probably not even tell, as tractor wouldnt go much off line, but on slopes like I have been today, you notice instantly as tractor just goes madly off track…Always when its messing around trying to re-establish ntrip. Considering maybe using another ntrip client and just turning off the one in AOG to avoid this issue…
Hello together,
Short question. The uper ardusimple is for relPos.(on the left side) The ardusimple on the bottom is for abs.Pos.(on the right side)
I have an distance between the antenna of 120cm. The Antennas are symmetrical Assembler.
My question is now which value i have to add in the Code: //cm to move virtual Antenna
Regards, Peter
Sounds like your base station is doing a survey to fix its position on startup and hence varies the position each time its started. You can fix the base station position permanently so it does not do the survey on startup if it’s an f9p once you have an accurate survey position, ideally from another base using RTK. You fix the base position permanently in one of the TMode’s under config view if its a ublox base.
I entered a fixed position in T mode but after each turn on the rover position changes. Could this be due to the lack of accuracy in the coordinates I entered? I relied on a position that the base station determined itself.
Have you checked from your base RTCM messages (1005 or 1006) that the base coordinates remain the same now?
Forever would not work , but maybe you could make it a bit longer by rewriting the code a bit to resend the last received Ntrip values for a while longer, if there was none received. It would not work very well as the corrections would not be as relevant after that length of time, but may be worth trying to see if there is any improvement over single. Maybe better do the NTRIP in the ESP32 to avoid confusing AOG. In RTKnavi using M8T’s typically the solution would go from fix to float in such circumstances ( then eventually to single), which is slighlty better than no correction but not much. Its a shame that F9P’s cannot run in WAAS mode on losing fix, but I’m not sure it would help much.
Another solution is multiple redundent NTRIPs sources, maybe two different 3G providers or one 3G and one radio modem.
Actually not sure that would work as the f9P may just ignore any out of date NTRIP values, you could modify the time stamp to fool it but the real problem is the satelites are moving and the ionosphere is changing so the values are just not relevant.