EDDC-IDLE Release Notes

We have moved the list of messages that used to be sent by the orignal NDDC away from the MMDVMHost messages. This is the IDLE screen and Nextion Display GOLBAL messages.

t50-t59 - Presently defined Globally sent EDDC program messages.

t60-t79 - Presently defined Globally sent EDDC operational messages. Since these items don't change that often, they sent only once on each load/reload of page 0/MMDVM.

t80-t89 - Presently defined Globally sent EDDC regularly changing message values. What is special about these is that they are sent every ~10 seconds as set by the GenerateCPU on the MMDVMHost setting page. They sent on all pages at the proper interval.

t90-t99 - Presently defined Globally sent EDDC regularly changing message values. What is special about these is that they are sent everytime a user is decoded for a last heard screen. This is presently being worked on.

MMDVM.n68.val, MMDVM.n69.val, and MMDVM.n70.val takes the place of the multiple hoards of controlled messages that was done by others. This crams all those messages into bitwise messages, or, 96 possible bit messages in three sent integers (OR 12 Bytes internally to the Nextion).

These messages are sent in a text format to the Nextion, as a big number, even though it's still a lot less overhead that the Nextion will have to process. BITWISE addition and testing for a true will give each message individually. ALSO, this way YOU get to program the code how each item looks and works on your Nextion Screen Code.

REMEMBER, MMDVM.n68.val, MMDVM.n69.val, and MMDVM.n70.val are sent as Gobally setup variables. They can be accessed from any page IF your make them Gobal on the MMDVM Nextion Page. They are updated when ever the HotSpot/Repeater is first started, when returning to the IDLE screen from another MODE screen, and anytime the MMDVMHost is STOPPED and RE-STARTED (Back to saying "IDLE").

The MMDVMHost messages below are passed to the NDC VerB code. They are parsed and handled ONLY for their values. They are never displayed in their RAW form anywhere on the IDLE screen.

The Reasoning behind the "MMDVM.status.val=number" is an elusive one, not documented anywhere, yet, it is sent by the MMDVMHost extensively, and used in places within the ON7LDS NDDC (Driver). Here's what I have found out. Over the past year I stopped these messages from coming through the AG4OJ EDDC (Driver). I deleted the "S0" touch references throughout my NDCVerB code.

What happened next was my NDCVerB code took errors when changing from the MMDVM IDLE screen to a mode screen. In other words, randomly, rarely, the NDCVerB code would not switch to the proper MODE screen, it would just stay stuck on the MMDVM IDLE screen. In doing a deep dive on this problem, and thanks to the individuals at iTead Nextion, I would be advise of the Nextion Page Switch Timings.

I would be told that this could take as much as 33ms at times depending on what the Nextion Buffer has waiting to be executed. The LOW LEVEL commands taking up the most time to execute. With the ongoing development of the Nextion Firmware, this is why I was given the 33ms value. With this in mind, and as rare, random this was happening, I set the wheels in motion to minimize this problem.

A "usleep()" value was placed after certain critical low level Nextion commands in the AG4OJ EDDC. This made this problem even more extremely rare to happening, this value was set to 20ms. NOW, this didn't fix ALL of these "HICCUPS", yet, it did catch most of them. YES, I know, there is still the 13ms short fall. It is now being made up by the reintroduced "MMDVM.status.val=number" back into the AG4OJ EDDC and NDCVerB.

SINCE I now know what the reason is for the "MMDVM.status.val=number", the "MMDVM.status.val=number" is limited pass-through to "Nextion Page Switching" and only the switch from the MMDVM IDLE screen to another MODE screen. The AG4OJ EDDC also interprets these "MMDVM.status.val=number" changes for it's own internal adjustments if necessary.

This way everything stays in alignment, from the MMDVMHost, to/through the AG4OJ EDDC (Driver), and finally to the NDCVerB (Nextion Display Code). AND we are NOT sending ALL of those other "MMDVM.status.val=number" and "click S0" messages to the Nextion Display unnecessarily. These excessive message overhead BURDENs should be removed from the MMDVMHost. ONLY the Page switching ones are really important.

The "S0" code burden should also be light. IF you need more help making sure that your "S0" code handler on each page is written properly, efficiently, please send me an EMAIL by using the EMAIL link below.