I think it’s just a block of 4 bytes and each bit in that block represents a section. So for 8 sections you could just send bits in byte 5 and leave the others as 0x00
Could be wrong though!!
1 Like
Thanks for writing this bridge CQuick! I have just setup a new Bogballe M35W with the Totz box successfully. The only snag I ran into was the bridge software did not pick up the section data from AOG properly. It just showed the error “Invalid section data! Please re-load the vehicle file in AgOpenGPS”. In the end I got around this by manually editing the config.ini file and it seems to be working. Will test tomorrow.
Any ideas what might have gone wrong? This is on a mixed UDP/USB system (nano for canbus steering over USB) on a slightly older AgOpenGPS version (5.2.2 I think). I tried reloading various vehicles, restarting AgopenGPS/AgIO etc but no luck.
By the way I would be interested in variable rate control if/when you get around to implementing it.
How did you go about getting your hands on the serial protocol CQuick? I want to do a similar thing for a Hardi Sprayer but I am not having much luck getting my hands on the “Hardi VRA protocol.”
Bogballe publishing the documention for the serial protocol. See link it github repo
AgOpenGps should be included in this leaflet:
https://www.google.com/url?q=https://www.krm-ltd.co.uk/Bogballe/Bogballe%2520Leaflets/GPS_Controlled_Spreading.pdf&sa=U&ved=2ahUKEwi0lurSp_f8AhUJuIsKHem0CjoQFnoECAEQAg&usg=AOvVaw1fErbdIT58Lw5vn5sloh1t
That’ll be because the section width PGN was only added in v5.6.something
The section data forwarding should still work, but you’ll need to use the latest AOG for the autoconfig.
I’ve updated the script on Github now, which should be more verbose about whether it’s connected to AgIO, incase there are any network issues, and also displays a warning if you’re using an unsupported version
That would explain it! I will try the new version.
Couple of bugs squashed today.
There’s a new setting in the config.ini, if you want the spreader to continue spreading after losing connection to AOG then set it to 1. By default when losing network it will stop spreading, but this can be annoying going over hills and losing cell connection, which causes AgIO to briefly lock up.
So this means you can carry on your run until it re-connects
Anyone tested this in the 2023 season. How is it working?
Wondering if I sell my old L1 spreader and buy a used M35W with Zurf Control unit.
Is variable rate on roadmap? Maybe AgopenGPS needs Shapefile support first?
I’ve been using it all last spring, no changes planned for this year unless anyone reports any bugs.
Should work on a Zurf but I haven’t tested it personally. I will help you if you have any issues though!
In terms of variable rate, I’m waiting for the VR function in AOG to mature and stabilise before I put any effort in. I agree, shapefile support is important.
Hello , it seem you work on ASD Quantron , I do also , did you have some results ?
I have bench tested the older UNIQ with this script. Even though there is no actual section control on the unit, the active working width is reduced, decreasing the output. With the 2/4 times overlab, this section control probably works well enough for smaller tramline spacings.
The speed is likewise sent to the unit from aog GPS.
Funny thing is that Bøgballe put a disclaimer in their seriel protocol description that the old unit will not receive the “new” protocol that CQuick have used. But with firmware update to 1.13, this works nicely. So if you have an older spreader with UNIQ, try this script out.
Any idea if its possible to controll Bogballe calbibrator UNIQ? Maybe this fact play role too that our spreader is on its own wheels and not attached to 3-point.
It should work, give it a go and let us know if there are any issues.
Works like a charm with UNIQ for me. It might shut off a bit early on headland but can be adjusted with agOpenGPS headland timers. It does performs the open delay needed to minimize overlap though.
What spreader model, spreading width and general speed range?
I’m working on a very old Calibrator 2003 - I’ve got the speed update working by simulating the radar signal. The on/off seems to be controlled by a pulse on pulse off so will have to be coded into the machine code to work.
Bogballe m3w, 20m and 17-18kph.I need to update to latest firmware but i think i will factory reset all settings
Very cool to get the speed input by adding a pulse output from machine board. Have you tried trough the protocol using {SVxxxC} even though not documented?
Regarding on/off, you should be able to use the serial protocol, just like the python script CQuick has written. Small changes are needed, but see the protocol specific for 2003:
https://dam.bogballe.com/dmm3bwsv3/AssetStream.aspx?mediaformatid=10061&destinationid=10016&assetid=1926
I might try to help modify the script as I can get a hand on a 2003, if you want?
On a 2003 you can do on/off through the same input at the speed signal. You use a stereo jack plug. Not sure if the serial protocol works on a 2003?
You will most likely factory reset your settings, but I guess you only need to write down a few numbers for this to be back to normal?
- Calibration number (not needed since you have a W (weighing system)
- Working width (is set from the script, so not really needed)
- Quantity settings
- Speed values, if needed.
I will try to get my hands on a 2003 soon. With the serial protocol, you should also get section control (only by reducing the amount of fertiliser, not anything fancy change of fall point).
This section control is actually working in the calibrator by reducing the working width.
From what I see in the manual for 2003, it is not mentioned that the stereo jack has the on/off. That function is first mentioned in the UNIQ manual. It might still work though.