I’m surprised it worked too. some kind of interrupt-driven pulsing code is probably your best bet. Skip the built-in PWM mechanism entirely. It’s just not designed for that kind of thing.
I don’t know what the radar signal looks like either! It does seem to be somewhat standardized between manufacturers. My StarFire receivers simulate the radar signal, I know that.
Shame I don’t know anyone willing to put an oscilloscope on one to see what it looks like!
I can give it a try, but can’t guarantee I’ll get to it before the weekend.
I have an old Hemisphere Cresent A100 GPS receiver. The manual describes the radar simulated pulse output as:
The radar-simulated pulse output provides accurate ground speed.
The Crescent A100 uses pin 12 for the speed out pin. Pin 12 will
output a square wave with a 50% duty cycle. The frequency of the
square wave varies directly with speed. 94 Hz represents a speed
of 1 meter per second, or a 28.65 pulse per foot traveled.
Could try to capture an oscilloscope view but I’m not expecting any surprise.
I remembered I had a pigtail made up that I was using for canbus capturing. I added the radar pin to it and stuck my portable hantek oscilloscope on it. I don’t really know how to use the scope, but from what I could tell, low was 0.5v and high was 5v. The pulses were equal width on and off, and the frequency was close to what NorthernFarmer quoted from the manual. At 26 mph, it was about 1.5 kHz. 2 mph was about 90 Hz.
I think 0v for the low would be fine.
My plan2, isn’t looking to good then…using millis for pulse generation, it wouldn’t go fast enough?
Could you use an extra Arduino to process the GPS data and use the tone function to generate your square wave?
It interferes with PWM so couldn’t be used on the main control Arduino, and the minimum frequency is 32 Hz so wont work for very slow speeds.
Tone sounds great for high speeds, think an ‘if’ statement to switch between ‘millis’ blink setup for slow speed and ‘tone’ for faster than 1km/h.
Newtone sound even better with <32 Hz!
@BrianTee_Admin is there a reason for only 0.25 km/h resolution on speed sent to section/machine module ?
Its not ideal for sending to other boxes for rate control.
I think it is more accurate than that. For instance if the speed is 12.6 kmh. This muliplied by 4 and change to a byte. This results in 50 being sent to the arduino. The arduino divides it by 4 and stores it in a float. This ends up being 12.5.
Wouldn’t that be 0.25 resolution? 1 / 4 = 0.25
The speed is stored as a double in AgOpenGPS. If the speed was 12.6 it would be multiplied by 4 before being sent to the arduino. 12.6 X 4 = 50.4 This is converted to a byte and sent. 50 would be sent to the arduino. The arduino divides the byte by 4 and stores it as a float. 50/4=12.5
For some numbers there would be more loss of precision. For a speed of 8.2 in AgOpenGPS, arduino would show 8.
The speed could be multiplied by 6 and probably still fit in a byte (255/6=42 kmh). This would increase precision somewhat.
Thanks @SK21 don’t know how I’d got 0.25 resolution into my head last night.
…note to self…don’t do mental arithmetic late at night, while standing in a cold dark field waiting for a ewe to lamb!!!
I have never had that experience lol 
I guess it might affect a person’s thinking a little.
I will make sure it goes as 5 or 6x in this version to be released soon!
speed.xlsx (13.3 KB)
Built a spreadsheet with rounding to get my head around what I’m viewing on my Arduino code and spreader box. Jumps some numbers in 0.3 steps!
Am I missing something?
0.25 resolution is correct
Ok, I see what you mean. Between arduino speeds the difference can be 0.3. If you measure between AOG speed and arduino speed the difference is closer. Also AOG doesn’t round off the speed X 4 it just cuts off the decimal part, which makes the difference worst.
Interestingly using a multiplier of 6 is not always better than a multiplier of 4.
The only other way to improve it is to use 2 bytes.
2 bytes would be the best way to go, but is that extra byte available @BrianTee_Admin.
Access to $GPVTG would also work, but the thought of making it work over USB and Wi-Fi UDP is making my head hurt!