ooh. I didn’t see his hand lol 
After AOG V5 is released are we going to need to load a new file to the Arduino that the light bar is connected to?
I think so, i tried it but it doesn´t work. AgIO don’t recognize the lightbar as an Autosteer device (Arduino)
The External Light Bar shines from the value of “Distance from Guidance line” in the Auto Steer Data (Header = 0x7FFE) sent from AOG.
When I looked at “/AgOpenGPSv5_Beta/PGN 5.0.xlsx”, this value was no longer sent.
v4.3.10
v5beta
I posted your comment in the v5 thread, Brian replied with this.
Not sure if that means he will put it back in?
1 Like
Once the source for V5 is released we could add our own PGN and recompile the application if Brian doesn’t want to add it to the main branch?
It would be nice if it could work with minimal changes though as it is a good stepping stone into AgOpen if you don’t want to commit to all of the hardware at once.
2 Likes
Hello everyone i have a UDP System, whats the best way to start? Like to have such a System.
Where should i start.
Regards, Peter
Currently I would wait a bit, if/how V5 has a “Distance from Line” PGN, else you might want to move to the steering angle as source for the display.
For the LEDs I’d go with a WS2812 LED-Strip and controlling them with an ESP32 with ethernet.
Have you looked if that line was put back in V5 the the light bar to work properly? I would like to start updating the tractors nano’s and laptops, but I would need to update all 3 tractors (only one with lightbar) and either they all run V5 or they stay at V 4.3.10.
Sorry guys, Too many things to work on at once!
@Mueller @woody_matt @minolu-JP
So if there was a single byte where 127 is zero, 255 is all the way right, zero is all the way left, would that work?
In your ino you would make an (int) DistanceFromLine = 127 - serialRead();
If 1 value represented 4 cm, this would give about 5 meters in either direction (4*127).
The other option is each value would be 2 cm which would give about 2.5m each way. Seems to me this may be the best way to go.
The other thing is byte 10 is currently used in the autosteer pgn but as a tram byte, which already is in the machine pgn, so would this be a better place for the distance to be stored? Or do you prefer the machine pgn?
Would this meet your needs?
3 Likes
Personally I think a single byte would be fine, if you set the bar to too small a precision you end up meandering back and forth like a badly tuned PID loop would. I use a mix of 2cm and 4cm on my existing installations so somewhere around there is about right I think.
I would prefer the Autosteer PGN as in my installations I have connected to the main Autosteer PCB, but I don’t want to break anyone elses set ups that use the new tramlining byte so if it ended up in the machine byte I would just add processing for that PGN to my code.
Thanks for looking into it! And well done on V5 release, a big step forwards!
Thank you Brian for taking a look at this.
Autosteer png is also best for me, in the spare single byte.
I don’t remember if this is 2cm or 4 cm configurated in my system.
Well done for V5 !
Thanks for helping out Brian, Great work on V5
On my set up there is only one nano that AOG needs to communicate with so either PGN would work.
On the last version there was spot in the INO that we could adjust the distance value of each LED. I’m no programmer but maybe that’s still possible? That might be a question for @minolu-JP?
Thanks for the great work guys!
Maybe the way to look at this is how far off the line do you want to be able to detect? I would think going 2.5 m away from the line would be pretty far away, so that would mean sending 2 cm per count at which point you could then divide that by 2 again in your settings to get 4cm.
I agree, a setting too small makes you go all wavey wonky and getting a headache shortly thereafter! But while it is easy to go from 2 to 4 to 6, you can’t easily go the other way as resolution is lost
Byte 10, formerly the tram, will now have distance where it will send:
255 - autosteer is off or invalid so turn off all LEDs.
127 - zero distance
To get distance (Byte10 - 127) gives you ± distance from the line. But, check for 255 first.
Code in AOG:
int distanceX2;
if (guidanceLineDistanceOff == 32020 || guidanceLineDistanceOff == 32000)
distanceX2 = 255;
else
{
distanceX2 = (int)(guidanceLineDistanceOff * 0.05);
if (distanceX2 < -127) distanceX2 = -127;
else if (distanceX2 > 127) distanceX2 = 127;
distanceX2 += 127;
}
p_254.pgn[p_254.lineDistance] = unchecked((byte)distanceX2);
1 Like
Anything lower than 1 cm is probably a spurious level of precision, but 1 cm itself would easily allow people to set multiples of that to allow them to go bigger if they wanted.
1 m either way would be fine for me, I only have 6 LEDs for each direction. I don’t know if other people have more.
Makes sense, so sending 2cm per value is a good tradeoff. Will put this in v5.1.2 in a few hours and you can try it!
5 Likes
Version 5.1.2 is up and has the distance in that format in byte 10 (11th byte). Enjoy!! LEt me know if it works ok for you.
1 Like
That’s awesome, thanks Brian! I will try it out spraying this week and report back.
2 Likes
Lightbar does not seem to work with more than 17 leds with AutosteerPCBv2LB v5.
If I set it up with 19 leds it start to clitch, more than 19 and it basicly stop working alltogether.
older version worked fine with 71 leds.
for all of my tests i have used ledstrip with 71 leds and external power source for leds do not make any difference.
1 Like