I have changed to english, no effect. I must say I haven’t got it to work with USB either. Will look further into it when I have two F9P’s.
The pbuf_free error is still the same, when NTRIP starts thanks to the simulator or GPS coming from USB device, the error keeps ESP32 rebooting.
I believe @doppelgrau has had a same fault message i came across here: assertion "pbuf_free: p->ref > 0" failed: file · Issue #2685 · espressif/arduino-esp32 · GitHub
Here is a picture of my test setup. No advancement so far with two F9P’s. I have checked configurations, all looks good. One of the modules has a blinking ‘no RTK’ so I guess communication between them is OK.
The pin numbers of ESPduino should be the same for ESP-32 dev kit? In the code, the TX, RX 1 and 2 are declared in the beginning, so should be fine I guess.
1 Like
You can switch on debug mode UBX, so you can see the incoming stuff on serial monitor, while changing the GPIO pin in Webinterface. So you will find the right wiring/ pin assignments.
Other remark:
When having trouble with booting the ESP32, use 10uF electrolyte capacitors from Reset to GND and EN to GND. That keeps the pins low until power supply stabilizes.
3 Likes
Thanks for the tip, indeed I had to switch the assignment of RX/TX 1 pins with the RX/TX 2 ones and it is working. Position enters AOG well. Gps rate from 5 to 10 Hz at the moment but I think I’ll have to try outside for further testing. Screen latency (the number next to …Hz) 5 to 20. With the debug modes on I receive this kind of messages in screen monitor:
GNSSfix Type: 3 roll / heading quality : 0
got RelPosNED. Heading: 0.00 down vector (cm): 0.00
got UBX1 PVT lat: 50... lon: 2...
no dual Antenna values, no heading/roll, watchdog: send only Pos
Do you think a capacitor would change this pbuf message/rebooting? I think it just reboots because of the error. Before when testing without any connections with a good USB cable as power it did the same.
Two possible problems: the relposned seems to be empty, so no good gps signal, or no communication between the 2 f9ps over rx2 tx2
The boot problem could come when powering over Vin, not USB
Your tips are spot on. I have switched TX/RX across the F9P’s. So I should have switched the F9P’s in place from the start.
I put the antenna’s outside on ground planes and there you go, roll and heading appear. On particular moments the communication seems messed up as the values for ‘Roll:’ and ‘GPS:’ in the left side pane switch place! The tractor on the screen goes wild offcourse. It looks to be happening when the refresh rate goes down, probably due to bad wifi reception. I can make a video of what is happening.
I have found a 10 uF capacitor and connected it to EN-GND. I noticed there is a tiny SMD capacitor at one end of the physical ‘EN’-button, so maybe that should already be OK. Anyway the ESP32 keeps rebooting. Is there another reset button or pin to protect with a capacitor, next to EN?
I received my ESPduino-32 in the mail so will try with that module shortly. Getting there!
FWIW: one thing I did notice for sure: you need a good wifi router for this. Every small pause can be seen in the refresh rate which should be a steady 10Hz. I am just testing at home with home network or smartphone hotspot. Bad reception or every bit of activity on the smartphone is impacting the stream.
BTW sorry for having hijacked this topic. Should have started one ‘experiences with dual gps code’ two days ago.
Hi Alan, I suppose the Xbee format is 3.3v level by design. Not only the modules but also the headers on e.g. the simpleRTK2b towards it. The simpleRTK2B-lite is also 3.3v level standard.
1 Like
@MTZ8302 could I ask a few quick questions…
Have flashed your ESP32 GPS file to my esp32duino (Wemos), all working fine / can access web interface, fantastic work!!
I have a few questions,
1- Am I correct in thinking that the “left” antenna is used for actual position, and the right one just for heading, and roll calculations?
2 - In the setup, I am slightly confused by the Antenna position variables, what should be used for antenna position? Height is i assume just ground to antenna, but not sure exactly what “position” it is after here?
3 - Antenna virtual position, assume this just “moves” the position reported to AOG vs the actual position? IE can move the virtual antenna back to center ?
4 - Have you had any time to look at implementing an ethernet connection at all yet? Would really like to implement ethernet for everything on my setup if possible…
Thanks again, such great work!
Hi,
about the left and right antenna I’m not quite sure.
I think (not sure) if you use 90° heading correction, right is position, left is heading.
Antenna position: hight above ground (needed to “remove” roll), Antenna distance: distance between the 2 Antennas at the roof.
This is in relation with Signal quality check: deviation factor: The 2 Antennas give a GPS position. If these positions are precise, it should be the same distance GPS and real Antenna distance on the roof. If the GPS distance is more than the adjustabel factor (1.3) * real distance (or smaler…) the the GPS signal is bad. For testing in bad conditions, set factor to 1.9
The virtual postion is the point that is given to AOG. So if the Antennas are l+r with 1m distance, set 50 to right and AOG sees the antenna in the middle. Same foreward.
with RTK system you can set the offset here, by driving in one direction, mark the tires side on the ground, drive the other way and adjust until you hit the same point.
Ethernet connection is not done yet. All day in wineyard, so it comes maybe this spring, maybe not
1 Like
Hi,
I am reading about AGOpenGPS since the early beginning in 2017.
The dual antenna GPS is really nice.
Why do you go the route over the ESP32. Why don’t we use the Ardusimple “simpleRTK2Blite” in combination with the normal “simpleRTK2B” and get a UBX Parser inside AGOpenGPS to extract the necessary data?
Then we would simply plug in the Board via USB and we are done?!
Think this has been discussed before…But think in the end it was decided, its easier if AOG just accepts a standard NMEA / PAIGO sentence, from whatever it may be, and any processing to get to that point is done outside of it. I think its more just because there is such a huge range of different GPS options, and to keep it simple inside of AOG for most people, its easier to keep the settings clean and simple, and if you want to run dual antenna / something strange, to deal with it outside of AOG, and input in the same manor as everyone else…one less thing to go wrong / get effected by updates etc also.
I could be wrong though!
2 Likes
The first thing for me was to get NMEA wireless. A roof unit, that is independent.
There is an NTRIP client by coffeetrac for 1 Antenna with BNO and MMA, I added Bluetooth and WiFi.
Then the results with one antenna aren’t satisfying for wineyard use, when the antenna is on the cab, so double antenna. The first code is from 2018. My first goal was to keep it independent from UBlox. There is an GGA parser so you can in theory use 2 GPS sources no matter wich brand. The prob with doing all the calcs in ESP32 is the timing of the 2 receivers so I came to RelPosNED where this is the Prob of the F9P and with this we are tied to UBlox.
We discussed the possibility to do all in AOG, but in the end we decided to send a corrected message to AOG like commercial systems do. So if in 2 years another receiver is state of the art, it will affect the ESP code.
so the answer of darrenjlobb is right.
1 Like
Hello… What if the Tool on the tractor is rigid. Then its Maybe a good Solution to put one Gps in front of the tractor and the other Gps on the Tool to get a very accurant heading. And then mount the DOG2 on the Tool together with the Gps just to know the roll.
Also Maybe drift compensation can be automatically.
any thoughts?
regards
Peter
I guess it poses the question, in the future, could we be looking at an implement receiver also? Commercial system such as Deere are doing this I noticed now…
Could account for drift etc accurately then, just another F9P and UDP connection I guess! Sorry @BrianTee_Admin ! 
If you were talking about the tool, you could use a system to control the leveling equator. I mean tool level control to get a perfectly horizontal / sloped surface.
Going further, you could also place drains, etc. with the help of such a system.
Is this to be done?
I just guess, for most cases the drift compensation by AOG is OK. For high precision cases like planting trees or wine comercial systems use 2 independent devices: 1 steers tractor, other does the sliding frame.
When using dual GPS roll is compensated by the ESP and also send to AOG. So normally set Antenna hight in AOG to 0. If you need more compensation like in sidehill drift, you can set Antenna hight in AOG to 100 or use the setting in steer settings
there was a special AOG version years ago to do this, not sure if Brian did updates on this
Ok I get you point. What do you think about this suggestion with two gps for heading and Dog2 for roll?
The question is, is Dog2 more accurent or the Gps roll?
If the Dog2 is more accuerent more frequently, so why we should cange it to an Gps calculated roll?
the HR mode give hight above Main sea level at a resolution of 0.1 mm. RelPosNED gives the difference between the two antennas so the roll is very precise. The dog2 works good, but is expensive. It is not needed. Keep it simple: 1 Antenna and no correction (only RTK) or 2 Antennas l+r to calculate a corrected position.
If you have a dog2 than use it and keep one antenna
The thing is we have a small farm and no field is straightened. So its more challenge for AOG to follow a curve and not a straight line i guess. Ok, i get the point, that roll is more precise. Have someone tested the roll and heading from Gps while automatic steering? Is there a benefit compared to one antenna and Dog2