Hi! Let me share my project can2sky.com - free cloud-based CAN bus decoder. It converts raw CAN bus data of cars and commercial vehicles into readable data. You can built a plots of recognized and unrecognized parameters for analysys.
J1939 decoder is built-in, some ISOBUS-specific parameters are in progress.
I am involved in vehicle telematics (and agriculture machinery too) and reading CAN bus parameters is my ordinary job. So I’ve created this service to simplify my work, I hope we can learn more about agriculture parameters together.
Will try to improve this service according to your suggestions.
Yes, you can built plots on same chart based on data from several logs. So for can0 and can1 you record separate logs by 2 usb-can devices. Only issue there is timesync, so may be some preparation work is there to have same time in both logs.
Baud rate no matter because at now service works only as post-analyser. Real-time is more difficult, i hope I will implement it one day.
There are not many ISOBUS PGNs in isobus open database, for example, there is a nice project
with a lot of interesting manufacturing-specified PGNs, I am adding them now.
Request PNGs is now out of my service duty, as it post-processor in fact. You have to send requests from your USB-adapter and we can analyze replies later in post-processor.
I was hoping to have it hooked to an arduino and modify the relay module INO to send can bus messages instead of turning a relay board on. Would that be doable? Then I could control my hydraulics via Can BUS messages. Is anyone else doing this on agopengps?
There are several different ways how this can be achieved:
Inject can messages normally send by your buttons/switches.
This only works when these buttons/switches don’t also send out can messages when not-operated, otherwise your injected commands will be fighting the real commands.(worst option)
Register your can interface as auxiliary input (aux buttons/joystick/panel) this has to be a supported option for your make and model tractor. (requires you to know the can commands if you don’t have that option installed)
Register your can interface as diagnostics interface and use diagnostics commands sniffed from the diagnostic firmware to control the outputs or simulate the inputs (drawback can be the tractor switches to limited operations for safety)
What I plan to do is place a bridge between the armrest controller and the rest of the Can network. Then in the bridge I can replace certain messages. This eliminates the conflicts and also reduces the amount of things I actually need to know about.
Alternatively, exploit the analog hole. Avoid Can entirely and just manipulate the analog signals that the physical controls make. For all their desire to lock people out of the computer stuff, they can’t ever block that!
A more ambitious target would be to run the whole AgOpenGPS app on that HW. Unfortunately would create two user groups, those who have isobus tractors and those who do not. I guess at the moment the majority of AOG users run it on a non-isobus vehicle.
Actually meant the tractors canbus(j1939) not isobus.
Nice but expensive kit, just use isoaglib on windows/linux/pi etc instead.
@NorthernFarmer, If you mean run AOG on a virtual terminal, forget about that. To slow updating screens and to low a resolution, not enough buttons to map etc etc. Rather go the other way around and implement a VT on your AOG machine. Which will be a complete separate topic.
@torriem not canbus but there are pretty cheap pwm to 4 20ma converters available. just no feedback to the mcu in that case
The Topcon AGI-4 receiver (including its variant brands) can be run through a virtual terminal. I have just tried to activate it for other reasons than actually running auto-steer through it. You are probably right about the drawbacks. I just thought it would be attractive from hardware point of view for those who don’t want to build their own circuit boards. Even more important to have access to all tractor and implement (?) controls directly with SW.
Tractors more or less already all have isobus screens and adding virtual terminal support for a computer running AOG sounds not needed? But I’m not able to implement any of the discussed features and will gladly accept anything that comes available.