so lets break apart;
sprintf(temp, “%.2x”,data[b]);
I get its “Serial print function”, temp is your variable array. Its the “%.2x” part that really goes over my head.
What is the purpose of “%” is “.2x” sating you want it in 0x00 format vs %.4x being 0x0000 format?
then data[b] is just the bytes number as it comes out of your for loop?
Pretty sure %.2x simply prints a number in hex, but it will always use at least two digits. Although in our case it will always be two digits because we’re only feeding it between 0 and 255. Sprintf formats the number into hex into a temporary string variable which we then print with Serial.print. It prints out the hex value of just one byte at a time.
Yes %.4x would print four digit hex numbers (or greater).
Whenever I work with C standard format strings like that I have to look them up. For example, C library function - sprintf()
The variable “data” is the array of bytes that is passed to the function, and len tells it how many bytes to pull off of data. data[b] pulls out the "b"th byte from that array. It will print as many bytes as you have, up to any length (provided you don’t go off the end of the array). Hope that helps make it understandable.
Or the TJA1050 chip as well not sure what the differences totally are.
It looks like the TJA1050 goes to ttl, and the MCP2515 boards have their own onboard crystal and talk I2C.
Speed on the can bus is important? Or with an arduino and these boards at 8000mhz it is possible to make it work, because otherwise we should migrate to ESP32 with integrated can, right?
The Filtered F02C Messages program really came into it’s own today. A friend has been struggling to get his new topcon x35 system to work with his Fendt 820 steer unit rather than the topcon wheel thing. Lots of calls to topcon but steer was really aggressive and basically all over the place. Everything calibrated as it should but there was an occasional WAS error.
I suggested trying my can units on it and what we found was the same erratic behaviour from the fendt navigation test program.
Looking at the can F02C messages we eventually found backlash in the messages coming from the WAS. Turns out the base plug for the WAS, that locates it, is loose allowing the whole thing to rotate a few degrees before it starts to register movement. Causes awful aggressive steer hunting as you would expect!!
Thats was a good diagnostic plan haha. Once you know how the system working, and can see the signals from the sensors it’s a lot easier to see who’s not doing there job and why.
There isn’t a WAS readout anywhere so, apart from back pinning a connector we couldn’t see what was happening. We actually thought there was a connection issue somewhere but the messages gave it away nicely. Good to see it works on an 820 too.
…well there’s no way it’s steering with that lash!! Track rod ends would be shot in a day! Wild oscillations. We estimated 5° of lash in the sensor mechanism.
How come a properly installed factory WAS could have any play. These are hall-effect sensors with no mechanical connection between the rotating part and the fixed part, no arms with joints. The only play I can see is between the left wheel and the right wheel but the one with the sensor should be measured accurately.
I understand the previously described case was cause by a lousy installation, lose parts that should have been securely fixed?
4 plugs into 9. The square top of 4 turns with the kingpin, the round lower part is stationary and plugs into 9. There is considerable sprung loaded drag in 4 and the locating plug at the lower end is only a small diameter so reasonably high torque is transferred through it. Hence wear.