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..

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 ...

You need to use the escape character '\'

So your string will be .str = "AT+CUSD=1,\"100#\",15"

Martin

Autocorrect on my phone..

I read it as not(!) equal - nice that either works...

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

One trick I use a lot - allows an imitation of the ternary operator in a lot of cases.

Boolean operations return 1 for true and 0 for false.

So use:

.v1 = (.v2 < 20) + 2. // 3 if v2 is < 20 else 2

.flag = (.v == 10) // flag true if v = 10

Martin

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?

Odd, how about waiting until the value changes from 128 - it sounds as though only the start byte is being received correctly. Can you just display (or send to uart) all the data received?

I tried this - I've used a timer interrupt to add data if running as a simulation.

I think the issue is - your code continually searches for 128 - and as soon as it is found - attempts to read 4 bytes from 'after' the 128.
These may not have been received yet...
So - one solution is wait for 128 to be found then wait until caunt_rx >= 4 and then display the values.

Martin