forum.pistar.uk

Posted: **Thu Apr 11, 2024 3:23 pm**

I have a 4.3" Nextion screen, with the ON7LDS driver loaded as per https://github.com/on7lds/NextionDriverInstaller.
Hardware is Pi3B+ and MMDVD HS Dual HAT
The nextion is connected on /dev/ttyUSB0
/dev/ttyNextionDriver is selected
Nextion Layout is ON7LDS L3 HS
Nextion has model 10 v1.05 Build 230820-01 loaded (PD0DIB)
Nextion driver is 1.25

I've recently noticed a change in behaviour on the mapped fields that are displayed in 4.2.1 which is an upgrade from earlier versions, where the current active callsign is being populated in a field that should be the TG description on the other timeslot.
The same symptom exists in 4.3.0 (I tried a clean install of that today, without running the driver install as above - as i know the driver is now supposed to be installed by default.)
I've reverted back to in image of 4.1.6, that i had kept and confirm that it still worked as expected.
Referring to the attached images:
In 4.1.6 with the nextion driver installed via the script:
The idle screen populates the CPU load, CPU cycles and Disk free fields. [416_ON7LDS_idle.jpg]
The TG description field is displayed in the bottom right of the display for each slot. [416_ON7LDS_inuse2.jpg]

4.2.1 & 4.3.0
The current callsign in 1 time slot is now being displayed where TG description should be in time slot 2 and vice versa. - [421_430_inuse2.jpg]

4.3.0
the CPU load, CPU cycles and Disk free fields are not displayed in the idle screen - i suspect this is something the NextionDriverInstaller script populates, as it also inserts extra fields in the MMDVM Host section of config as that section is not present in the 4.3.0 install.

So i'm not sure where this has gone awry - but it looks like it might be a field mapping somewhere, that has been introduced as part of the upgrades against the t8/t9 mappings defined in https://github.com/PD0DIB/Nextion_HAM-r ... %20use.txt

Is there something i should be checking, that i have missed?
Should the default driver populate the CPU load, CPU cycles and Disk free fields? (PD0DIB fields t21, t22, t23)

Posted: **Mon May 27, 2024 3:12 pm**

Bump....
Out of interest, i had kept an image of 4.1.6 and when i run that, all fields are in the correct places - so that would seem to confirm something has changed in the code?

Posted: **Mon May 27, 2024 11:17 pm**

Have you considered copying the NextionDriver module in 4.1.6 (/usr/local/bin/NextionDriver) to the 4.2.1/4.3.0 images and seeing if that changes anything? (remember to make backups of the effected module).

There are at least three variants of the driver I'm seeing on my images: sized 53292, 55276, and 62892. Which one is correct, or current, is hard to determine as they all return 1.25 as their version number. The 55276 and 62892 sized variants exhibit the same behavior you're seeing on your systems; don't know if the 53292 variant will change that.

Not sure if this is a driver problem or a Nextion screen definition problem: either the wrong values are being populated in the variables passed to the screen OR the screen has field variables crossed somewhere.

Just some thoughts.

Posted: **Wed May 29, 2024 1:20 pm**

Thanks for looking at it.
(Maybe i have an uncommon Nextion config - i assume you are running the same? and this is why others haven't seen it?)

I've done a couple of things since yesterday.

I re uploaded the Nextion config to the screen to make sure it hadn't got itself corrupted - the same results.

So looked back at the SD card images.
I have an image of 4.1.6 with dashboard version 20221114 - that worked fine. Nextion Driver 53292bytes, dated 19/12/2022. this reports as driver 1.17
I also have an image of 4.1.6 with Dashboard version 20230924. The nextion driver is 62800 Bytes. Dated 23/03/2022 and reports 1.25
(why i have different dates, i am unsure - i don't remember rebuilding it, especially as the later dashboard seems to have an earlier version?)
However when I update this last version (20230924) and it picks up dashboard version 20240307 it breaks. This version installs Nextiondriver 55276 bytes dated today (this is just the date of the file creation on the local drive) and reports as driver 1.25

Overwriting the driver with v1.17 or the earlier version of 1.25 does not resolve it - so it looks like the wrong index fields have been mapped in Pi-Star, and it predates version 4.3.0 and 4.1.8 - the same issue has just been rolled through.

If I run a subsequent PiStar update - it doesn't update the NextionDriver to 1.25 and stays at 1.17

On Pistar 4.3.0, replacing the driver with 1.17 doesn't fix the issue and the same symptom is exhibited

At least i can see it's not something i have done.

Posted: **Wed May 29, 2024 2:39 pm**

I wrote this in my original post:
So i'm not sure where this has gone awry - but it looks like it might be a field mapping somewhere, that has been introduced as part of the upgrades against the t8/t9 mappings defined in https://github.com/PD0DIB/Nextion_HAM-r ... %20use.txt

For a bit of clarity - where Pistar is should be writing the screenlayout >2 t8 : talkgroup name TS2 field, it is actually writing the values for DMR t0 : src1 id / call / TA
Where it should be writing the t9 : talkgroup name TS1 value, it writes the t2 : src2 id / call / TA value
So it writes the currently transmitting user on one time slot into the TG name of the other slot.
This incorrect value on the "other slot" gets over written with the correct TG description if a user transmits on the "other slot"
e.g user Rx on S1.
The t0 value (src1 id / call / TA) is written to the top banner in slot 1 and to the TG description field of Slot 2
As soon as another user is received on Slot 2 (while Slot 1 is still in Tx), the TG description field is overwritten correctly in Slot 2

The same happens in reverse on Slot 2.
I hope that makes sense?

Posted: **Wed May 29, 2024 10:33 pm**

G7OMN wrote: ↑Wed May 29, 2024 2:39 pm For a bit of clarity - where Pistar is should be writing the screenlayout >2 t8 : talkgroup name TS2 field, it is actually writing the values for DMR t0 : src1 id / call / TA

Where it should be writing the t9 : talkgroup name TS1 value, it writes the t2 : src2 id / call / TA value

So it writes the currently transmitting user on one time slot into the TG name of the other slot. This incorrect value on the "other slot" gets over written with the correct TG description if a user transmits on the "other slot" e.g user Rx on S1.

The same happens in reverse on Slot 2.

Yes, it makes sense. To further the analysis: the phenomenon seems to only occur when TA's are involved. If a particular QSO does not include an embedded TA, then the screen(s) look normal. Otherwise, it appears as previously documented. Most of the time, anyway.
(I'm also seeing "user not found in stripped.csv" for some QSO's, also, again involving embedded TA's.)

----

Where are are these strings that are being sent to the Nextion being created: in the NextionDriver code or in the MMDVMhost code?

Posted: **Thu May 30, 2024 10:22 am**

Mark,
You might be right about the TA inclusion, as sometimes the text that is written the TG name field has additional content to the callsign banner - though this could be because myTG name field scrolls - may callsign banner doesn't.

I've now done a clean install of 4.3.0 using it's native Nextion drivers and i see that the .csv files have changed name and would appear to be able to download new versions - that may account for missing calls, as previously i was manually updating from https://kf5iw.com/contactdb.php, which is more comprehensive than than the radioid.net list that the pistar lists look to be based on.

The strings have to be created in the code, presumably as variables, and then sent to the driver. it looks like the t0 and t2 value are also being written to t8 and t9 at the start of transmission, and they get over written if the t8/t9 values are updated in the correct timeslot during the transmission.
If it was the driver, then restoring an earlier driver (which is possible without complaint - as the Nextion shows the driver version in use at start) would resolve the issue. It doesn't. I'm pretty sure it's been introduced as part of an update and i just didn't notice it for months.

My Nextion layout attached

: Nextion.jpg (29.5 KiB) Viewed 6574 times

Posted: **Fri May 31, 2024 8:14 am**

KN2TOD wrote: ↑Wed May 29, 2024 10:33 pm
(I'm also seeing "user not found in stripped.csv" for some QSO's, also, again involving embedded TA's.)

Looking at in \var\log\user.log It would appear that there is a cap on the number of users that can be read in - it's 250K.
Currently the nextionUser.csv file is >260K, so it gets capped at 249999 entries. That could explain some of the not founds if they are in the last 10K of users, which appear to be mostly South America.

Posted: **Mon Jun 03, 2024 11:49 pm**

G7OMN wrote: ↑Fri May 31, 2024 8:14 am
KN2TOD wrote: ↑Wed May 29, 2024 10:33 pm (I'm also seeing "user not found in stripped.csv" for some QSO's, also, again involving embedded TA's.)
Looking at in \var\log\user.log It would appear that there is a cap on the number of users that can be read in - it's 250K.
Currently the nextionUser.csv file is >260K, so it gets capped at 249999 entries. That could explain some of the not founds if they are in the last 10K of users, which appear to be mostly South America.

You are correct! I cross-wired some of my analyses resulting in an incorrect observation! Sorry 'bout that. Good catch!

Posted: **Tue Jun 04, 2024 12:32 am**

G7OMN wrote: ↑Wed May 29, 2024 2:39 pm For a bit of clarity - where Pistar is should be writing the screenlayout >2 t8 : talkgroup name TS2 field, it is actually writing the values for DMR t0 : src1 id / call / TA

Where it should be writing the t9 : talkgroup name TS1 value, it writes the t2 : src2 id / call / TA value
So it writes the currently transmitting user on one time slot into the TG name of the other slot.

This incorrect value on the "other slot" gets over written with the correct TG description if a user transmits on the "other slot" e.g user Rx on S1. The t0 value (src1 id / call / TA) is written to the top banner in slot 1 and to the TG description field of Slot 2
As soon as another user is received on Slot 2 (while Slot 1 is still in Tx), the TG description field is overwritten correctly in Slot 2

The same happens in reverse on Slot 2.

You are essentially correct here.

Some samples from tracing/analysis of the logs coming out of the Nextion Driver (loglevel=4 in the config):

Code: Select all

64350   │ Jun  2 15:36:26 pi-star-test NextionDriver: Received 36 bytes from host
64351   │ Jun  2 15:36:26 pi-star-test NextionDriver: RX:   dim=50
64352   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: dim=50
64353   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [dim=50] on page 2
64354   │ Jun  2 15:36:26 pi-star-test NextionDriver: RX:   t0.txt="1 N VO1JGN John"
64355   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t0.txt="1 N VO1JGN John"
64356   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t0.txt="1 N VO1JGN John"] on page 2
64357   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 0 is [txt="1 N VO1JGN John"]
64358   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 64
64359   │ Jun  2 15:36:26 pi-star-test NextionDriver: LH Inhibit#012 
64360   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- User index search for call VO1JGN (0 [] - 249999 [ZZ1Z] )
64361   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- User index search for call VO1JGN (124999 [KG4AUB] - 249999 [ZZ1Z] )
  :                                                            :                        :
64377   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- User index search for call VO1JGN (222993 [VO1JEF] - 222995 [VO1JQB] )
64378   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t18.txt="VO1JGN"
64379   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t18.txt="VO1JGN"] on page 2
64380   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 18 is [txt="VO1JGN"]
64381   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 64
64382   │ Jun  2 15:36:26 pi-star-test NextionDriver: LH Inhibit#012 
64383   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t19.txt="John G Noseworthy"
64384   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t19.txt="John G Noseworthy"] on page 2
64385   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 19 is [txt="John G Noseworthy"]
64386   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 64
64387   │ Jun  2 15:36:26 pi-star-test NextionDriver: LH Inhibit#012 
64388   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t20.txt="St Johns"
64389   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t20.txt="St Johns"] on page 2
64390   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 20 is [txt="St Johns"]
64391   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 64
64392   │ Jun  2 15:36:26 pi-star-test NextionDriver: LH Inhibit#012 
64393   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t21.txt="Newfoundland"
64394   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t21.txt="Newfoundland"] on page 2
64395   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 21 is [txt="Newfoundland"]
64396   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 64
64397   │ Jun  2 15:36:26 pi-star-test NextionDriver: LH Inhibit#012 
64398   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t22.txt="Canada"
64399   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t22.txt="Canada"] on page 2
64400   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 22 is [txt="Canada"]
64401   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 64
64402   │ Jun  2 15:36:26 pi-star-test NextionDriver: LH Inhibit#012 
64403   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: MMDVM.status.val=68
64404   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [MMDVM.status.val=68] on page 2
64405   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: click S0,1
64406   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [click S0,1] on page 2
64407   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t22.txt="Canada"
64408   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t22.txt="Canada"] on page 2
64409   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 22 is [txt="Canada"]
64410   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 68
64411   │ Jun  2 15:36:26 pi-star-test NextionDriver: LH Inhibit#012 
64412   │ Jun  2 15:36:26 pi-star-test NextionDriver: Received 86 bytes from host
64413   │ Jun  2 15:36:26 pi-star-test NextionDriver: RX:   MMDVM.status.val=62
64414   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: MMDVM.status.val=62
64415   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [MMDVM.status.val=62] on page 2
64416   │ Jun  2 15:36:26 pi-star-test NextionDriver: RX:   click S0,1
64417   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: click S0,1
64418   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [click S0,1] on page 2
64419   │ Jun  2 15:36:26 pi-star-test NextionDriver: RX:   t1.txt="TG91"
64420   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t1.txt="TG91"
64421   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t1.txt="TG91"] on page 2
64422   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 1 is [txt="TG91"]
64423   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 62
64424   │ Jun  2 15:36:26 pi-star-test NextionDriver: NO LH Inhibit#012 
64425   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 1522)
64426   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 761)
64427   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 380)
64428   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 190)
64429   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 95)
64430   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 47)
64431   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 23)
64432   │ Jun  2 15:36:26 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 11)
64433   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t9.txt="World-wide"
64434   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t9.txt="World-wide"] on page 2
64435   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 9 is [txt="World-wide"]
64436   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 0                            <-----
64437   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: t9.txt="World-wide"
64438   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [t9.txt="World-wide"] on page 2
64439   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: page 2 field 9 is [txt="World-wide"]
64440   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: statusval 0                            <-----
64441   │ Jun  2 15:36:26 pi-star-test NextionDriver: RX:   MMDVM.status.val=65
64442   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: MMDVM.status.val=65
64443   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [MMDVM.status.val=65] on page 2
64444   │ Jun  2 15:36:26 pi-star-test NextionDriver: RX:   click S0,1
64445   │ Jun  2 15:36:26 pi-star-test NextionDriver:  NET: click S0,1
64446   │ Jun  2 15:36:26 pi-star-test NextionDriver:   LH: check [click S0,1] on page 2
64447   │ Jun  2 15:36:27 pi-star-test NextionDriver: Received 35 bytes from host
64448   │ Jun  2 15:36:27 pi-star-test NextionDriver: RX:   MMDVM.status.val=64
64449   │ Jun  2 15:36:27 pi-star-test NextionDriver:  NET: MMDVM.status.val=64
64450   │ Jun  2 15:36:27 pi-star-test NextionDriver:   LH: check [MMDVM.status.val=64] on page 2
64451   │ Jun  2 15:36:27 pi-star-test NextionDriver: RX:   click S0,1
64452   │ Jun  2 15:36:27 pi-star-test NextionDriver:  NET: click S0,1
64453   │ Jun  2 15:36:27 pi-star-test NextionDriver:   LH: check [click S0,1] on page 2
64454   │ Jun  2 15:36:35 pi-star-test NextionDriver: Received 23 bytes from host
64455   │ Jun  2 15:36:35 pi-star-test NextionDriver: RX:   t0.txt="1 Listening"
64456   │ Jun  2 15:36:35 pi-star-test NextionDriver:  NET: t0.txt="1 Listening"
64457   │ Jun  2 15:36:35 pi-star-test NextionDriver:   LH: check [t0.txt="1 Listening"] on page 2
64458   │ Jun  2 15:36:35 pi-star-test NextionDriver:   LH: page 2 field 0 is [txt="1 Listening"]
64459   │ Jun  2 15:36:35 pi-star-test NextionDriver:   LH: statusval 64

Code: Select all

1420   │ Jun  2 14:17:29 pi-star-test NextionDriver:  NET: click S0,1
1421   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: check [click S0,1] on page 2
1422   │ Jun  2 14:17:29 pi-star-test NextionDriver: RX:   t1.txt="TG91"
1423   │ Jun  2 14:17:29 pi-star-test NextionDriver:  NET: t1.txt="TG91"
1424   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: check [t1.txt="TG91"] on page 2
1425   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: page 2 field 1 is [txt="TG91"]
1426   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: statusval 62                           <------
1427   │ Jun  2 14:17:29 pi-star-test NextionDriver: NO LH Inhibit#012 
1428   │ Jun  2 14:17:29 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 1522)
1429   │ Jun  2 14:17:29 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 761)
1430   │ Jun  2 14:17:29 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 380)
1431   │ Jun  2 14:17:29 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 190)
1432   │ Jun  2 14:17:29 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 95)
1433   │ Jun  2 14:17:29 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 47)
1434   │ Jun  2 14:17:29 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 23)
1435   │ Jun  2 14:17:29 pi-star-test NextionDriver: --- Group search for ID 91 (0 - 11)
1436   │ Jun  2 14:17:29 pi-star-test NextionDriver:  NET: t9.txt="World-wide"
1437   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: check [t9.txt="World-wide"] on page 2
1438   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: page 2 field 9 is [txt="World-wide"]
1439   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: statusval 0                            <-----  62?
1440   │ Jun  2 14:17:29 pi-star-test NextionDriver:  NET: t9.txt="World-wide"
1441   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: check [t9.txt="World-wide"] on page 2
1442   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: page 2 field 9 is [txt="World-wide"]
1443   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: statusval 0                            <-----  62?
1444   │ Jun  2 14:17:29 pi-star-test NextionDriver: RX:   MMDVM.status.val=65
1445   │ Jun  2 14:17:29 pi-star-test NextionDriver:  NET: MMDVM.status.val=65
1446   │ Jun  2 14:17:29 pi-star-test NextionDriver:   LH: check [MMDVM.status.val=65] on page 2
1447   │ Jun  2 14:17:30 pi-star-test NextionDriver: RX:   click S0,1
1448   │ Jun  2 14:17:30 pi-star-test NextionDriver:  NET: click S0,1
1449   │ Jun  2 14:17:30 pi-star-test NextionDriver:   LH: check [click S0,1] on page 2
1450   │ Jun  2 14:17:30 pi-star-test NextionDriver: Received 90 bytes from host
1451   │ Jun  2 14:17:30 pi-star-test NextionDriver: RX:   t8.txt="N TA3AUP"
1452   │ Jun  2 14:17:30 pi-star-test NextionDriver:  NET: t8.txt="N TA3AUP"
1453   │ Jun  2 14:17:30 pi-star-test NextionDriver:   LH: check [t8.txt="N TA3AUP"] on page 2
1454   │ Jun  2 14:17:30 pi-star-test NextionDriver:   LH: page 2 field 8 is [txt="N TA3AUP"]
1455   │ Jun  2 14:17:30 pi-star-test NextionDriver:   LH: statusval 65                           <------ 70! 
1456   │ Jun  2 14:17:30 pi-star-test NextionDriver: RX:   MMDVM.status.val=63
1457   │ Jun  2 14:17:30 pi-star-test NextionDriver:  NET: MMDVM.status.val=63
1458   │ Jun  2 14:17:30 pi-star-test NextionDriver:   LH: check [MMDVM.status.val=63] on page 2
1459   │ Jun  2 14:17:30 pi-star-test NextionDriver: RX:   click S0,1
1460   │ Jun  2 14:17:30 pi-star-test NextionDriver:  NET: click S0,1
1461   │ Jun  2 14:17:30 pi-star-test NextionDriver:   LH: check [click S0,1] on page 2
1462   │ Jun  2 14:17:30 pi-star-test NextionDriver: RX:   MMDVM.status.val=64
1463   │ Jun  2 14:17:30 pi-star-test NextionDriver:  NET: MMDVM.status.val=64
1464   │ Jun  2 14:17:30 pi-star-test NextionDriver:   LH: check [MMDVM.status.val=64] on page 2
1465   │ Jun  2 14:17:30 pi-star-test NextionDriver: RX:   click S0,1
1466   │ Jun  2 14:17:30 pi-star-test NextionDriver:  NET: click S0,1
1467   │ Jun  2 14:17:30 pi-star-test NextionDriver:   LH: check [click S0,1] on page 2
1468   │ Jun  2 14:17:37 pi-star-test NextionDriver: Received 70 bytes from host

Ok, so I'm asking you to trust my analysis here: the logs are difficult to shift through and you have to have a good sense of how the data streams are being constructed and sent to the Nextion display and interactions of the variables and status codes therein.

The basic concept is that a buffer is constructed with a command and some status information and variables to be set, and then sent out to the display. For our particular case (the subject of this thread), it is obvious that the "status" information associated with some variables are either incorrect (set to zero) or held over from a previous command (with an improper status code being sent).

I believe the problem is in the Nextion Driver code - as noted elsewhere, specifically the "basicFunctions.c" section of code, wherein, three send commands should be invoked instead of just one as is the case currently:

Code: Select all

   //send TG name if found (Slot 1)
    if ((page==2)&&(strstr(TXbuffer,"t1.txt")!=NULL)&&(TXbuffer[8]!='"')) {
        char *TGname;
        int nr,TGindex;
        sendCommand(TXbuffer);
        if ((TXbuffer[8]>='0')&&(TXbuffer[8]<='9'))
            nr=atoi(&TXbuffer[8]);
        else
            nr=atoi(&TXbuffer[10]);
        TGindex=search_group(nr,groups,0,nmbr_groups-1);
        writelog(LOG_INFO,"Search group %d (index %d)",nr,TGindex);
        if (TGindex>=0) {
            TGname=groups[TGindex].name;
            writelog(LOG_INFO,"Found %s",TGname);
            sprintf(TXbuffer,"t9.txt=\"%s\"",TGname);
        } else if (TGindex<0) {
            //is it maybe a user private call ?
            TGindex=search_user_index_for_ID(nr,users,0,nmbr_users-1);
            writelog(LOG_INFO,"- Found [%s] for ID %d",users[TGindex].data1,nr);
            if (TGindex>=0) sprintf(TXbuffer,"t9.txt=\"Private %s\"",users[TGindex].data1);
        } else {
            sprintf(TXbuffer,"t9.txt=\"TG%d name not found\"",nr);
        }
        sendCommand(TXbuffer);
        sprintf(text, "MMDVM.status.val=62");          <----
        sendCommand(text);                             <----
        sendCommand("click S0,1");                     <----
    }
    //send TG name if found (Slot 2)
    if ((page==2)&&(strstr(TXbuffer,"t3.txt")!=NULL)&&(TXbuffer[8]!='"')) {
        char *TGname;
        int nr,TGindex;
        sendCommand(TXbuffer);
        if ((TXbuffer[8]>='0')&&(TXbuffer[8]<='9'))
            nr=atoi(&TXbuffer[8]);
        else
            nr=atoi(&TXbuffer[10]);
        TGindex=search_group(nr,groups,0,nmbr_groups-1);
        writelog(LOG_INFO,"Search group %d (index %d)",nr,TGindex);
        if (TGindex>=0) {
            TGname=groups[TGindex].name;
            writelog(LOG_INFO,"Found %s",TGname);
            sprintf(TXbuffer,"t8.txt=\"%s\"",TGname);
        } else if (TGindex<0) {
            //is it maybe a user private call ?
            TGindex=search_user_index_for_ID(nr,users,0,nmbr_users-1);
            writelog(LOG_INFO,"- Found [%s] for ID %d",users[TGindex].data1,nr);
            if (TGindex>=0) sprintf(TXbuffer,"t8.txt=\"Private %s\"",users[TGindex].data1);
        } else {
            sprintf(TXbuffer,"t8.txt=\"TG%d name not found\"",nr);
        }
        sendCommand(TXbuffer);
        sprintf(text, "MMDVM.status.val=70");          <----
        sendCommand(text);                             <----
        sendCommand("click S0,1");                     <----
    }

I'm not an expert on this but that's my analysis and I'm sticking with it (until further notice).

Check it out and let me know: comments? questions?

-----

Changing (compiling) the Nextion Driver is an involved process, for me anyway: haven't quite got the hang of all the in's and out's of the process, so if you've got a better handle on this aspect of things, I'd appreciate the help, your thoughts.

In the meantime, I thought of a way to get around the problem, to "correct" the data after it gets to the Nextion display, on the fly:

In the HMI code, specifically in the DMR screen, code could be added to save/restore the t8/t9 values across screen refreshes, accounting for the proper assignments of the fields and the faulty status codes being passed:

Code: Select all

//Variables
t30.txt=MMDVM.va1.txt
t32.txt=MMDVM.va0.txt
t50.txt=MMDVM.va2.txt
t51.txt=MMDVM.va4.txt
t52.txt=MMDVM.va3.txt
t53.txt=MMDVM.va5.txt
t500.txt=MMDVM.va7.txt

//************************************************************
// Copyright 2018-2021 by PD0DIB | Rob van Rheenen
// SET SCREENLAYOUT TO TYPE 3 - Pi-Star to ON7LDS L3
// the DMRID/TA field will be processed - Code partly by ON7LDS
// depending on type (ID, TA, call end) color and font size are set

//choose font size
t0.font=3
t2.font=3

strlen t0.txt,tmp0.val
strlen t2.txt,tmp1.val

if(tmp0.val>22)
{
  t0.font=2
}
if(tmp1.val>22)
{
  t2.font=2
}
if(tmp0.val>31)
{
  t0.font=1
}
if(tmp1.val>31)
{
  t2.font=1
}
if(tmp0.val>35)
{
  t0.font=0
}
if(tmp1.val>35)
{
  t2.font=0
}

//text color (for slot 1)
if(MMDVM.status.val>60)
{
  if(MMDVM.status.val<65)
  {
    //status 61=listening, 62=ID, 63=TA, 64=call end
    if(MMDVM.status.val==61)
    {
      t0.pco=0
    }
    //ID
    if(MMDVM.status.val==62)
    {
      t0.pco=31
    }
    //TA
    if(MMDVM.status.val==63)
    {
      t0.pco=1024
    }
    //Call end
    if(MMDVM.status.val==64)
    {
      t0.pco=33808
    }
  }
}

//text color (for slot 2)
if(MMDVM.status.val>68)
{
  if(MMDVM.status.val<73)
  {
    //status 69=listening, 70=ID, 71=TA, 72=call end
    if(MMDVM.status.val==69)
    {
      t2.pco=0
    }
    //ID
    if(MMDVM.status.val==70)
    {
      t2.pco=31
    }
    //TA
    if(MMDVM.status.val==71)
    {
      t2.pco=1024
    }
    //Call end
    if(MMDVM.status.val==72)
    {
      t2.pco=33808
    }
  }
}

//last heard & talkgroup LH
//timeslot 1
if(MMDVM.status.val==64)
{
  if(g0bis.txt!=t0.txt)
  {
    g0bis.txt=t0.txt
  }
  if(t1bis.txt!=t1.txt)
  {
    t1bis.txt=t1.txt
  }
}
//restore previous ts2 tgname
if(MMDVM.status.val==64)
{
  t8.txt=MMDVM.va9.txt
}

//timeslot 2
if(MMDVM.status.val==72)
{
  if(g2bis.txt!=t2.txt)
  {
    g2bis.txt=t2.txt
  }
  if(t3bis.txt!=t3.txt)
  {
    t3bis.txt=t3.txt
  }
}
if(MMDVM.status.val==72)
{
//restore previous ts1 tgame
  t9.txt=MMDVM.va10.txt
}

//save ts1(t9) and ts2(t8) for next time
MMDVM.va9.txt=t9.txt
MMDVM.v10.txt=t8.txt

Note: for this to work, va9.txt and va10.txt need to be declared as global variables under "page 0" (the initial screen).

More on this approach later.

(BTW: Does anyone know how to get the nextion.py routine to work? It can't seem to determine a workable baudrate)

forum.pistar.uk

v4.16 / 4.2.1 / v4.3.0 Nextion field mapping?

v4.16 / 4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.16 / 4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.2.1 / v4.3.0 Nextion field mapping?

Re: v4.2.1 / v4.3.0 Nextion field mapping?