The reset needs the checksum resetting too. So will only receive one message as is...
V2. 0 this evening
Search found 888 matches
- Thu Mar 21, 2024 9:30 am
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7255
- Wed Mar 20, 2024 10:49 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7255
Re: Protocol j1587
Regarding the row of two byte PIDs, for example: engine speed - PID 190, data 087 009 - PID_data[0] /; 087;/ + (PID_data[1] /;009;/<<8) I get a 16-bit value and multiply it by 0.25 (res/bit) So - the PID - get from PID[0] - if this is >= 128 then the 16 bit value is PID_Data[0] ( NOT PID_Data[0] + ...
- Wed Mar 20, 2024 4:30 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7255
Re: Protocol j1587
Let us know how it goes... Remote debugging is notoriously tricky :cry: I think the one piece of error checking it needs is to check the length of the message - if it's greater than 21 bytes then reset and start looking for MID again. As it stands - is the end isn't found then it will trample over m...
- Wed Mar 20, 2024 2:48 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7255
Re: Protocol j1587
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...
- Tue Mar 19, 2024 11:20 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7255
Re: Protocol j1587
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 (wi...
- Tue Mar 19, 2024 2:13 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7255
Re: Protocol j1587
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..
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..
- Tue Mar 19, 2024 7:58 am
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7255
Re: Protocol j1587
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 ...
- Sat Mar 16, 2024 10:29 am
- Forum: General
- Topic: AT Command's
- Replies: 2
- Views: 140
Re: AT Command's
You need to use the escape character '\'
So your string will be .str = "AT+CUSD=1,\"100#\",15"
Martin
So your string will be .str = "AT+CUSD=1,\"100#\",15"
Martin
- Fri Mar 15, 2024 10:01 am
- Forum: Feature Requests
- Topic: Ternary operator in calculation block?
- Replies: 7
- Views: 434
Re: Ternary operator in calculation block?
Autocorrect on my phone..
I read it as not(!) equal - nice that either works...
I read it as not(!) equal - nice that either works...
- Fri Mar 15, 2024 9:21 am
- Forum: Feature Requests
- Topic: Ternary operator in calculation block?
- Replies: 7
- Views: 434
Re: Ternary operator in calculation block?
True - but I've not had any issues so far. Also use if(.x) rather than if(.x !=0 ) - would be interesting to know if it actually saves any memory / or time. Must do a test...
It could come back to bite me someday
Martin
It could come back to bite me someday
Martin