Page 7 of 9
Re: Protocol j1587
Posted: Thu Mar 14, 2024 3:43 pm
by mnfisher
Is that 'in tractor' or only on the bench?
If it's in situ - how long are the leads to the Nextion display? Interfence might be affecting that?
Re: Protocol j1587
Posted: Tue Mar 19, 2024 6:00 am
by bios33
Hi all!
The wires are very short, I installed the Controller in the display itself.
In this version, the lines began to be output correctly, but as soon as I enable the checksum calculation, it starts to work very slowly and skips data.
Re: Protocol j1587
Posted: Tue Mar 19, 2024 7:58 am
by mnfisher
I think the checksum calculation is incorrect. If this fails then the display won't update.
Need to sum all the bytes of the message (including the checksum byte) - it would be easier to use a loop here! - then take the 2s complement MOD 256
Final value compare to checksum byte...
Don't have access at the moment - if it's not working for you - could you post a complete message (as 1,2,3,4...21) and I'll try writing a checksum macro and test that - later today.
Martin
Re: Protocol j1587
Posted: Tue Mar 19, 2024 10:00 am
by bios33
bios33 wrote: ↑Mon Jan 22, 2024 11:55 pm
Hi!
Here is a fragment of data taken from uart via USB/RS485, you can see there that the packet starts at 0x80 if in hex and in the next screen from special software, j1587 Navigator, from Volvo, and there you can also see that the beginning of the packet starts at 128 in hex 80 But when all the blocks and other packages appear on the network, for example MID 144, MID 130 and so on, now I only have MID128 on my desk.
I can't connect external COM to FC, I think it would be easier that way
Here is the monitoring of communication between control units in my tractor
Re: Protocol j1587
Posted: Tue Mar 19, 2024 2:13 pm
by mnfisher
The length of the data blocks seems to vary - for example there are several starting 128, 84 with differing lengths..
Iain, kindly gave a link earlier - it looks like it is not as simple as waiting for 128 then reading a fixed number of bytes..
Re: Protocol j1587
Posted: Tue Mar 19, 2024 4:29 pm
by bios33
Yes, the length of the frame is always different and the beginning always begins with the name of the control unit (128 is the MID engine) and at the end of the frame there is a checksum byte. But there are other MIDs, for example the 144-central module
Re: Protocol j1587
Posted: Tue Mar 19, 2024 4:32 pm
by bios33
bios33 wrote: ↑Tue Mar 19, 2024 4:29 pm
Yes, the length of the frame is always different and the beginning always begins with the name of the control unit (128 is the MID engine) and at the end of the frame there is a checksum byte. But there are other MIDs, for example the 144-central module
Re: Protocol j1587
Posted: Tue Mar 19, 2024 4:35 pm
by bios33
bios33 wrote: ↑Tue Mar 19, 2024 4:32 pm
bios33 wrote: ↑Tue Mar 19, 2024 4:29 pm
Yes, the length of the frame is always different and the beginning always begins with the name of the control unit (128 is the MID engine) and at the end of the frame there is a checksum byte. But there are other MIDs, for example the 144-central module
Re: Protocol j1587
Posted: Tue Mar 19, 2024 11:20 pm
by mnfisher
We need to look at a 'slightly smarter' read - need a way to check the length of each data block and also when the end of the current data is received. This is the checksum byte - but how to know that this is the end of the data and not another PID?
So it looks like PIDs are in a range of values (with some having one byte of data following and some a byte indicator of the number of bytes) - but I;m not sure about how the end of data is specified (up to 21 bytes) - or we could just use the next '128' and take the previous byte as end of block ?
Will read the manual
I have an idea how to do the 'read' - using a simple 'state' for the ISR - so looking for 128 (MID), looking for PID, looking for data, looking for checksum - more to follow....
Martin
Re: Protocol j1587
Posted: Wed Mar 20, 2024 2:48 pm
by mnfisher
This was my first attempt..
It works in simulation for the 'dummy' data (one row of above table) - it assumes that the checksum condition is met to end the input...
Output is a table of PIDs (PID[]) and a table of the data values for each PID (PID_Data[]) It assumes that PIDs of 0..127 have one byte of data and those above have two - these might be stored incorrectly - I read MSB (most significant byte) first and then LSB (and this might be the reverse of the real situation.
No attempt to handle errors at this stage, or 'extended' PIDs or PIDS with byte counts...
Demonstrates the idea (the problem is that there doesn't seem to be a count of data blocks or an end marker...) and seems to work. Please test with some extra data sets (sim_data)
Martin