Recently I started looking deeper into how the Agra-GPS CRG works. From what I can tell, it essentially acts like a StarFire receiver from the display’s perspective — it connects to the same port, speaks the right CAN messages, and provides full position + attitude data so that AutoTrac and other Deere functions still work.
What I’m wondering is:
Has anyone in the open-source or DIY community attempted a StarFire-compatible receiver (a device that plugs into the same connector and is recognized by JD displays)?
If not, why isn’t this possible yet, given that Agra-GPS has clearly achieved it commercially?
Is the blocker technical (proprietary CAN/ISOBUS messages, timing, IMU fusion, etc.), legal, or simply a lack of documentation and community focus?
Would an open-source or experimental “bridge” project — even if just for research — be of interest to others here?
This would be very interesting, I am have started looking at Agra-gps as well, it would be nice to use my rtk correction.
But I was wondering the same, use an F9p and get deere to read the signal. Hopefully there is something out there.
Well it should be doable as agragps has already done it. But honestly I dont know where to start to reverse-engineer it to make deere read F9P. According to some sources, agragps use f9p as well.
This is what I’ve had saved from a while ago, the one who knows is Torriem, he also has an AgraGps antenna, he can guide you better. @torriem StarFire.txt (7.1 KB)
Haven’t been around the forum in a long time, so I didn’t see this thread until just now.
Yes the CRG pretends to be a starfire on the CAN bus. And it works great for me.
A few years ago I started working on a project to emulate a starfire with an F9P. I also experimented with a dual GPS setup using a SkyTraq receiver. I almost got it working. My code is on github at GitHub - torriem/gps_j1939: Create J1939 GPS messages. I tried to make the code modular so it could switch easily between F9P with IMU and the dual SkyTraq code paths. The functions that generate CAN messages are called send_nogps_messages() and send_gps_messages(). In there you can see all the messages that are generated. Some are industry-standard, but others that it wants are proprietary but undocumented. We do know what most of them do, but some of the details are unknown. I ended up just copying some messages verbatim from what I saw on the bus from a real receiver. For example the message that encodes some GPS satellite information.
Last time I worked on the code, F9P with IMU kind of worked, but I had a really hard time getting the heading calibrated properly. But it autotrac did steer with it. For some reason the dual GPS stopped working on me. Autotrac refused to steer. Some simple bug in there.
Correcting GPS with the IMU is a pretty hard problem. I borrowed most of the code for that from AgOpenGPS. I understand a lot of guys are using a much better IMU now, so maybe that could be made to work here as well. The CRG does a fantastic job of integrating the IMU. They use a very expensive one. Johan is very smart and knows his algorithms. Also the CRG implements a ISOBUS virtual terminal interface for configuration which is really awesome. I had thought about making some kind of web interface for my version. But now I actually just run all CRGs so this project was shelved. But if you want to run with it, feel free!
This is all so helpful! I am not that familiar with all the coding and communication so I use AI a lot to help me understand better. I was thinking about using AI to reverse engineer some of the proprietary messages and it looks like it’s doing a good job when I tried it on some short log I have downloaded from this post.
I will try can sniffing on my sf3000 and sf6000 with sf1 and sf2 activations and if manage to get any log successfully I will try to use ai to “crack” the proprietary messages.
By any chance, do you have any saved logs? It would be interesting to see agragps crg logs as well.
Unfortunately I don’t, sorry. Don’t have any cables set up to do sniffing currently, either.
Keep in mind that these CAN messages are j1939-formatted, so if you really want to understand what’s going on, and who is sending messages to whom, you’ll need to decode the 29-bit CAN id into j1939 fields: PGN, src address, target address, and priority.
While it would be interesting to know how the proprietary messages are encoded, it does not seem to be necessary. Like I said the hard problem is doing the GPS and IMU integration. Would be interesting to see if AI could solve that one, including calibrating the heading.
One thing I did early on was to make a CAN bridge that went between the starfire and the roof connector. Then it would pass all traffic through in both direction. But I could intercept certain messages and change the data and see what happened. that’s how I discovered the bytes that change the reported signal type (WAAS, SF1, RTK, etc), and also the accuracy bargraph. Also learned that the GPS position itself is not a proprietary message, but industry standard.
Yes I did borrow the basic algorithm from AOG. Getting the heading offset figured out is hard, though. And of course reverse detection is also very hard. At the time, BNO085 was what everyone was using, but now there’s something better, but I can’t remember what it is.