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.
Regards,
Andrew
Don’t like the cloud idea to start with, but guess that’s the only way around sharing the j1939 database.
Will it handle candumps from 2 canbusses? (can0 vehicle j1939 , can1 implement iso11783)
Will it handle different baud rate’s between the 2? (500kbps, 250Kbps)
Maybe implement like a websocket for real time decoding ?
Isobus discriptions, are in downloadable on ISOBUS Data Dictionary, guess where it says: see j1939 you could use your decoder for them.
How about j1939/iso11783 pgn/spn’s that are only on request or even also require the can adapter/interface to register on the can network first?
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.
Guess indeed baudrate doesn’t matter once in socketcan,
candump -c can0 can1 (puts both interfaces in one log, with timestamp)
Pysobus, isoblue, TractorHacking, Polycan etc all cansniffers, also no active requests there unfortunately.
For a complete list see the isobus site from above, which does maintain the standard. They have the most complete list, besides some proprietary ones.
If your j1939 Description are only taken from pysobus instead of the standard or a decent j1939 dbc file, most of them will be missing.
You can do real time with for example a wireshark dissector
Timed Request PNGs are possible using can-utils>j1939 or isoaglib which can also do the requests
Or a 2-Channel Isolated CAN FD Expansion HAT which has its own power supply, dual canbus and also works on 3.3V, if you like to implement something like a raspberry or a ESP
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!
Fendt seems to use 4-20ma for some of it’s control gear. Reliable but awkward to piece into. The older pre can joysticks are like this unfortunately AFAICS.
Maybe the " ISOmaX Development-Kit" would help to go this way!?! But it’s about 900€ for students/teacher etc. or 1800€ for private use and companies plus tax…
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.
