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

[KN2TOD]

BTW, my Nextion screen is similar to yours but posting mine here as a ref for the code scraps/logs posted previously

My Nextion Screen (DMR).jpg (38.7 KiB) Viewed 1345 times

[KN2TOD]

The root cause of the problem is the fact that two screen variables (t8 and t9) are being used for two different purposes, are being propagated with two different types of data: either the name of the talk group (corresponding to the TG number in t1 and t3) or with data from Talker Alias (TA) information associated with the CS in t0 or t2. The TA's are intermittent, i.e. not all CS's have/utilize the feature, so the screen only occasionally displays the errant data. To compound matters, the TA's for TS1 are passed along to t9 while TA's for TS2 are passed to the t8 field, essentially backwards. The bottom line: the screen info becomes confusing.

Changes need to be made upstream, in the NextionDriver: Talker Alias data needs to be assigned to new variables (t88 and t98, perhaps?). This change will take some time and thought by other developers, to vet and implement.

In the meantime, changes can be made Nextion screen itself, to the script associated with the S0 event in the DMR screen that accounts for the misuse of the t8 and t9 field variables. Two new fields in the screen are created: t201 and t203, and substituted for the t8 and t9 fields - the event script then selectively updates T201 and T203 only if the t8/t9 variables contain the appropriate data:

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

// clear t8/t9 variables if Talker Alias data:
substr t8.txt,tolets2.txt,0,2
if(tolets2.txt=="N ")
{
  t8.txt=""
}
substr t9.txt,tolets0.txt,0,2
if(tolets0.txt=="N ")
{
  t9.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<69)
  {
    //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
  }
}

//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
  }
}

//selectively apply (copy) t8/t9 data to t201/t203 field variables:
if(t1.txt!="")
{
  if(t9.txt!="")
  {
    t201.txt=t9.txt
  }
}

if(t3.txt!="")
{
  if(t8.txt!="")
  {
    t203.txt=t8.txt
  }
}

//clear TGname fields if TG goes blank:
if(t1.txt=="")
{
  t201.txt=""
}

if(t3.txt=="")
{
  t203.txt=""
}

For this script to work, two new local variables, t8 and t9 need to be defined for the screen (since they are no longer declared on the screen itself).

[G7OMN]

The root cause of the problem is the fact that two screen variables (t8 and t9) are being used for two different purposes, are being propagated with two different types of data: either the name of the talk group (corresponding to the TG number in t1 and t3) or with data from Talker Alias (TA) information associated with the CS in t0 or t2. The TA's are intermittent, i.e. not all CS's have/utilize the feature, so the screen only occasionally displays the errant data. To compound matters, the TA's for TS1 are passed along to t9 while TA's for TS2 are passed to the t8 field, essentially backwards. The bottom line: the screen info becomes confusing.

Changes need to be made upstream, in the NextionDriver: Talker Alias data needs to be assigned to new variables (t88 and t98, perhaps?). This change will take some time and thought by other developers, to vet and implement.

While I get this... I still have a niggle.
As I noted earlier, i have an image of PiStar 4.1.6 and nextion driver v1.17 - this works as expected. so i am looking at this logically.
Surely replacing the default installed driver on a current clean install, with v1.17 driver would resolve the issue if this was driver related?
This fact surely suggests that the mappings have been altered in the Pi-Star code?

The first line of your reply supports this theory.

The t8/t9 fields are explicitly defined as:
screenLayout >2 :
t8 : talkgroup name TS2
t9 : talkgroup name TS1
there is no cross over in the use of t8/t9 and the data for t0 and t2 are being incorrectly written to the data fields for t8/t9.
t8/t9 are not supposed to be used for anything else.
So, is it not as simple as the t8/t9 fields are now being written to when they shouldn't be?

With v4.1.6 / v1.17 everything works as it should - even with TA being displayed.

Really I'm hoping that @MW0MWZ or @M1DNS are looking at this thread and have some comment?

[KN2TOD]

This problem has been around for a long, LONG time; can't say exactly when it went off track - only PD0BID and ON7LDS can explain all this.

The documentation I believe is in error/highly suspect, given that it appears to have been created after the fact (of the coding) and contributed to by a third party independent of the original developers. There are other fields and values that are wrong or missing altogether, so I won't put too much faith in it being gospel/correct. The docs, like numerous other things, hasn't always kept up with the code.

The fact that 1.17 appears to work but 1.25 does not only confirms the addition of the TA data to the driver stream occurred after 1.17, but one would have to dig into the GitHub change logs to determine exactly when and where that occurred, assuming one could first determine which Github fork to investigate.

So, is it not as simple as the t8/t9 fields are now being written to when they shouldn't be?

So, yes, I'm saying the t8/t9 fields are being misused, used for a dual purposes. It jumps out to ya after you prowl through 100k+ lines of debug info and start seeing the pattern.

With v4.1.6 / v1.17 everything works as it should - even with TA being displayed.

Yes, everything seems to work as it should, even if occasionally some errant TA data shows up.

v4.1.6 probably was originally using the 1.17 version, but with various updates/upgrades, moved to 1.25. Depending on where in the update/upgrade process you are with that version, one would naturally expect differing results.

It should be mentioned that Talker Alias data was a late(r) addition to DMR; not all software was changed to accommodate the feature in lock step or consistently in codeplugs/radio firmware, repeater/hotspot code, or Nextion codings. So there are some missteps here up and down the chain.

[G7OMN]

The root cause of the problem is the fact that two screen variables (t8 and t9) are being used for two different purposes, are being propagated with two different types of data: either the name of the talk group (corresponding to the TG number in t1 and t3) or with data from Talker Alias (TA) information associated with the CS in t0 or t2. The TA's are intermittent, i.e. not all CS's have/utilize the feature, so the screen only occasionally displays the errant data. To compound matters, the TA's for TS1 are passed along to t9 while TA's for TS2 are passed to the t8 field, essentially backwards. The bottom line: the screen info becomes confusing.

Changes need to be made upstream, in the NextionDriver: Talker Alias data needs to be assigned to new variables (t88 and t98, perhaps?). This change will take some time and thought by other developers, to vet and implement.

In the meantime, changes can be made Nextion screen itself, to the script associated with the S0 event in the DMR screen that accounts for the misuse of the t8 and t9 field variables. Two new fields in the screen are created: t201 and t203, and substituted for the t8 and t9 fields - the event script then selectively updates T201 and T203 only if the t8/t9 variables contain the appropriate data:

code deleted

For this script to work, two new local variables, t8 and t9 need to be defined for the screen (since they are no longer declared on the screen itself).

Which script is this?
Have you got it working?

I'm assuming it's what pistar uses to write to the screen? as i can't see any code that resembles this in the Nextion editor for my screen layouts.

I'm happy to give it a go, if you point me in the right direction. I can see that i would need to comment out t8 /t9 in the Preintialize events for the DMR screen in the Nextion editor and add t201 and t203 to the list, and then replace the object names in the attribute sections of the Nextion layout for t8/t9?

Jon

[KN2TOD]

Yes, I have this code working .. on two different hotspots: updated one (it's a pain!) and then let it run for a day or so, then updated the second one. Watching both on them now like a hawk to see if anything else may be amiss.

You're almost there: in the DMR "page", click the "s0" event in the upper left corner of the screen layout - the code in question then appears at the bottom in the "event" panel. I usually copy the script in this panel out (ctrl-A, ctrl-c) to Notepad and work with it there, then copy it back in to the Nextion Editor. It's a pain working with this editor, not intuitive at all, documentation sux (technical term) and I'm not a wiz at using it in any case: keep forgetting to click this or that, whatever. Patience, patience.

In the DMR layout, click on the t8 and t9 fields respectively, and modify their names to t201 and t203 respectively. In the "attributes" panel on the right, look at the dropdown showing all the variables. From the Toolbox, click on "X-Variable" to (re)create the t8 and t9 variables: change/correct the "objname", set "vscope" to local, set "sta" to string, and "txt_maxl" to 20.

I did NOT fiddle with the pre-initialization assignments; perhaps I should have but I don't fully understand the sequencing here: I'm assuming they are set (pre-initialized) and then the command(s) are processed that (re)set those fields/variables, and then the revised screen is "presented".

Anyway, that's the easy part. Next comes "compiling" and saving the results as a .tft file and then loading it into the Nextion display. Argh!

(I'd post some pic of all this but I seem to be having trouble with that aspect of this forum. It worked once for me but now I've forgotten what I did to get there. Go figure!)

----

BTW, what is the setting of this config in your /etc/mmdvmhost files? Is it the same in in all the various versions 4.1.6/1.17 et al, that you've been working with? Curious if this has any control over the TA lines showing up in the logs (and hence being routed to the Nextion Driver). Ah, something else I hadn't looked at, haven't tested in the context of the current thread.

Code: Select all

[DMR]
Enable=1
Beacons=0
BeaconInterval=60
BeaconDuration=3
ColorCode=1
SelfOnly=1
EmbeddedLCOnly=0
DumpTAData=0     <------------
CallHang=3
TXHang=4
ModeHang=20
Id=311684705
OVCM=0

(Thanks for all your work on this, for posting your query in the first place. It's nice to hear others are working with Pi-Star, that they are paying attention to what it does, what it can do, looking at ways to correct and improve it.)

[G7OMN]

Ok.. Now I see it.
Interestingly, there's a lot more variables commented out on my nextion DMR s0, see below
my DumpTAData=1

BTW - thank you, i think you have achieved more than me. I don't really do coding, it kinda passed me by.
If it's got wires or moves, I can fix it...
(with that said, I do do a lot of software testing in my job - hence the eye for things that are just not right)

//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>21)
{
t0.font=2
}
if(tmp1.val>21)
{
t2.font=2
}
if(tmp0.val>37)
{
t0.font=1
}
if(tmp1.val>37)
{
t2.font=1
}
if(tmp0.val>45)
{
t0.font=0
}
if(tmp1.val>45)
{
t2.font=0
}
//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(MMDVM.status.val==64)
{
if(t1bis.txt!=t1.txt)
{
t1bis.txt=t1.txt
}
}
//timeslot 2
if(MMDVM.status.val==72)
{
if(g2bis.txt!=t2.txt)
{
g2bis.txt=t2.txt
}
}
if(MMDVM.status.val==72)
{
if(t3bis.txt!=t3.txt)
{
t3bis.txt=t3.txt
}
}

[KN2TOD]

my DumpTAData=1

No worries - changing it doesn't accomplish anything anyway: the alias info keeps getting passed along. Deadend train of thought here.

BTW - thank you, i think you have achieved more than me. I don't really do coding, it kinda passed me by.
If it's got wires or moves, I can fix it...

It seems that a lot of the software I encounter these days ... has passed me by as well.

(with that said, I do do a lot of software testing in my job - hence the eye for things that are just not right)

We all need other sets of eyes looking over all this stuff! Different perspective, different objectives.

//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
:

Except for the commented lines, this looks essential like the code I started with.

The t51/t2/t3/t500 fields are, respectively the temp, cpu cycles, cpu load, disk usage, and IP addr. So you can comment out those assignments in my code.

But double check your script against my script: I didn't see anything else besides the variable assignments but I may have missed something nevertheless.

Hit the "compile" button/selection and see if anything else is amiss.

If everything looks ok, save the file/screen def and then select file->tft file output from the toolbar at the top.

[G7OMN]

I've just got around to looking at this.
I think the preininitialze event just ensure the fields are cleared when the screen is called.

So if i am interpreting correctly:
you are looking at what is written to the t8/t9 fields and if begins with N you throw it away as that is designated as a TA field and write "" as the value
If t8/t8 <> "" then the field values are then written to T201/t203
The statements that look like this: if(tmp0.val>22) are used to resize the font based on the length of the string?

Oddly my S0 data didn't have text colour definitions for slot1, only slot 2 (go figure?).
And when i first compiled it i must have swapped t201 and t203, as the TG appeared in the wrong slot.

Anyway, it compiled successfully - i then save it, and as my display is connected via USB to the Pi, it's easy to connect to the PC and upload, without having to flash to a uSD card. The editor is a bit smart doing it this way, as it looks at the delta's and only uploads those and at 921Kbps, it takes about 10 seconds.

Thanks for your input - I'm also now watching like a hawk - looks good on slot1 so far! (not had anything on slot2 yet)

The next step is to try and increase the cap on the number of users read in from the nextionUser.csv or perhaps get it to automatically download, process and read in the data from kf5iw.com

[KN2TOD]

you are looking at what is written to the t8/t9 fields and if begins with N you throw it away as that is designated as a TA field and write "" as the value If t8/t8 <> "" then the field values are then written to T201/t203

Correct.

The statements that look like this: if(tmp0.val>22) are used to resize the font based on the length of the string?

Correct again.

Oddly my S0 data didn't have text colour definitions for slot1, only slot 2 (go figure?).

You can easily fix this by duplicating the logic for TS1, with the appropriate changes in variables.

The next step is to try and increase the cap on the number of users read in from the nextionUser.csv or perhaps get it to automatically download, process and read in the data from kf5iw.com

A revised NextionDriver has been posted that increases the limit, but it has not made its way into the appropriate Pi-Star libraries:
<https://github.com/on7lds/NextionDriver ... bf273dcb08>

Progress! Good to hear you succeeded in making the changes!