Closed hammyMarc closed 3 years ago
hammyMarc
commented
3 years ago As I have thought about this more, I may propose another alternative LED management schema:
Solid LED's for all of the protocols that have successfully been initiated and connected to their various master servers etc. Dashes (slow blink for protocol failures (e.g. failure to connect to a server, failure to authenticate to a service, etc.). And dots (quick blink) when for the "protocol in use".
g4klx
commented
3 years ago Your understanding of the LEDs is incorrect. The flashing LED is important as it indicates that all is fine in the firmware. It is driven off two important pieces of software and if either one of these fails, it will stop flashing. It has never indicated "scanning" whatever that means. It is designed to be used with an external hardware watchdog timer, where a delay in either switching on or off can be used to give the system a hardware kick. This is useful for remote locations. The modem knows nothing about masters (which only exist in DMR anyway) and so cannot be used for that purpose. There is a log file that can be parsed if you need to know, after all that is what Pi-Star does, or use a display like a Nextion. The LEDs aren't changing any time soon. Being open source you're well within your rights to change your version of course. On Thursday, 18 February 2021, 23:25:38 GMT, Marc Verdi notifications@github.com wrote:
First, you guys are freaking amazing. I looked through the code... and although I do not write C++, I was amazed with the meticulous nature and structure.
I would like to recommend that, instead of the "fancy flashing" LED's (illuminated when the MMDVM hat is "scanning"), that we implement a schema of "quarter second blips, and one second pauses, when the hat is 'scanning' or in standby" with "solid Illumination on the gpio pin, for the protocol currently in use / in Tx".
I make this suggestion for the following reason: while running the current code, (with both DMR and D-star protocols enabled) the rapid flashing leads me to believe that there is a trouble condition, rather than a "scanning" condition.
Thank you for considering this for the next release. I would make the changes and create a pull request, if I were better at C++ :(
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
hammyMarc
commented
3 years ago Jonathan:
Thank you for your kind response. Some interesting food for thought.
Be well,
Marc
First, you guys are freaking amazing. I looked through the code... and although I do not write C++, I was amazed with the meticulous nature and structure.
I would like to recommend that, instead of the "fancy flashing" LED's (illuminated when the MMDVM hat is "scanning"), that we implement a schema of "quarter second blips, and one second pauses, when the hat is 'scanning' or in standby" with "solid Illumination on the gpio pin, for the protocol currently in use / in Tx".
I make this suggestion for the following reason: while running the current code, (with both DMR and D-star protocols enabled) the rapid flashing leads me to believe that there is a trouble condition, rather than a "scanning" condition.
Thank you for considering this for the next release. I would make the changes and create a pull request, if I were better at C++ :(
I might also make the same observation for the SVC LED; this flashing makes me believe that there is a trouble condition. I would recommend only flashing the SVC LED to indicate some problem establishing connectivity, on a per-protocol basis.