STAC Version 1.10 Released

[Xylopyrographer]

@mqshaw : Just released a new version of STAC. Added a Peripheral Mode allowing one STAC acting as a controller to drive the tally status of another STAC when that one is placed into Peripheral Mode.

A few internal clan-up things including a simple check to see if the existing configuration of the STAC can be used after updating to a newer version of software.

Hope you and the family are keeping well!

[mqshaw]

Hi Rob, Thanks for the update. I was also thinking about messaging you today. The family are doing well, looking forward to the spring. We have been using STAC for 9 months now and finally have it dialed in. Lots of experience with dropped connections, and fine tuning of the STAC FW to handle the connections. I can merge my changes i to branch latest and let you see the changes. Blessings, Mark

…

________________________________ From: Xylopyrographer ***@***.***> Sent: Sunday, January 16, 2022, 4:33 PM To: Xylopyrographer/STAC Cc: Mark Shaw; Mention Subject: [Xylopyrographer/STAC] STAC Version 1.10 Released (Discussion #42) @mqshaw<https://github.com/mqshaw> : Just released a new version of STAC. Added a Peripheral Mode allowing one STAC acting as a controller to drive the tally status of another STAC when that one is placed into Peripheral Mode. A few internal clan-up things including a simple check to see if the existing configuration of the STAC can be used after updating to a newer version of software. Hope you and the family are keeping well! — Reply to this email directly, view it on GitHub<#42>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANXCSGL65SSAOD56UEY36YDUWNIUHANCNFSM5MDK7WWA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[beamholder]

That’d be great to see Mark. I’ve been monitoring the arduino-esp32 GitHub repository for a while now. Seems to be a fair number of quirks wrt WiFi with the 2.X core versions as they refactor everything based on Espressif IDF. I don’t quite understand how they can be releasing new core versions when version 4.4 of the IDF upon which it’s based is still in beta. Regardless, that’s kept me leery of migrating—sticking with 1.0.6 core for a while I think. Cheers, Rob =================================== On Jan 16, 2022, at 7:02 PM, Mark Shaw ***@***.***> wrote:  Hi Rob, Thanks for the update. I was also thinking about messaging you today. The family are doing well, looking forward to the spring. We have been using STAC for 9 months now and finally have it dialed in. Lots of experience with dropped connections, and fine tuning of the STAC FW to handle the connections. I can merge my changes i to branch latest and let you see the changes. Blessings, Mark

…

________________________________ From: Xylopyrographer ***@***.***> Sent: Sunday, January 16, 2022, 4:33 PM To: Xylopyrographer/STAC Cc: Mark Shaw; Mention Subject: [Xylopyrographer/STAC] STAC Version 1.10 Released (Discussion #42) @mqshaw<https://github.com/mqshaw> : Just released a new version of STAC. Added a Peripheral Mode allowing one STAC acting as a controller to drive the tally status of another STAC when that one is placed into Peripheral Mode. A few internal clan-up things including a simple check to see if the existing configuration of the STAC can be used after updating to a newer version of software. Hope you and the family are keeping well! — Reply to this email directly, view it on GitHub<#42>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANXCSGL65SSAOD56UEY36YDUWNIUHANCNFSM5MDK7WWA>. You are receiving this because you were mentioned.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

[mqshaw]

Hi @Xylopyrographer
I have integrated my changes into a branch off 1.10
https://github.com/Xylopyrographer/STAC/tree/mqs_timeout_fixes_1.10_base
so you can see them. I have not tested the merged changes on the branch. I will be testing them in the coming weeks.

The original changes that we are running with are on this branch.
https://github.com/Xylopyrographer/STAC/tree/mqs_timeout_tracking_1.9.1_base

The key changes are between lines 317 and 339, where the code checks for the connection timing out. By making these changes we have gone from "dropping out - showing the X" frequently - almost every couple of minutes, to almost not at all. Reducing the polling frequency from 175ms to 300ms has also helped.

[Xylopyrographer]

@mqshaw Hey there Mark. How're things going?

Did a quick diff on the two versions last evening. All looks pretty good. I should hold off until you've run a few tests on the new version?

I'll probably have a question or two when I get into the nitty gritty of it.

Probably will need a paragraph describing how the filtering works for the manual.

I've been thinking about adding in to the web configuration page the ability set the polling interval. And/or adding an "Advanced" configuration tab to tweak things. However the only couple of things that come to mind in that category are the polling interval, the time to wait for WiFi connection and the number of times to retry that WiFi connection before throwing up the red "can't connect" icon. So maybe adding just the polling interval is enough? Make the bypassing the filtering an option? Add in anything else?

Still on that item, it was a bit of a judgement call on what value to use for the polling loop. In practice, are the camera operators & producer seeing any difference in the longer time?

I also should revisit the state of the official M5Stack ATOM Matrix library to see if I can do away with the custom version used for STAC. It was at 0.0.1 last year and is now at 0.0.8. Though like I said to Peter in his inquiry, anything with h=that may zero's in front seems like an alpha. M5 has also released a "Unified" M5 library inclusive to the Matrix so I guess I should poke about in that too.

I've got a few other things to manage at the church before I'll get back to this. Maybe in a couple of weeks.

Another tidbit: Purchased an El Gato Streamdeck for our production computer. Running Companion (bitfocus.io) on that. It's been a super piece of kit for productivity improvement. Using it to control OBS, ProPresenter on the FOH booth, a PTZ camera, lower thirds overlay on the stream, launching and ending the streaming & recording, etc. Too much fun. Highly recommended.

Keep well.

[mqshaw]

@Xylopyrographer
Things are going great. Very much looking forward to spring, which is just around the corner.

I will be uploading the new 1.10 based changes to one of my STAC units this Sunday so that we can start getting it tested. It would be good for me to run through that before we go ahead a submit a pull request. I agree that I need to add some documentation to describe the filtering.

In terms of the attributes that we should/could add to the EWS, Poll time and # Attempts are the two that I think are important. I do still think that having a way to accessing the EWS once the STAC is active would be really nice. Sometimes remembering how to put it into wifi-direct connect mode is cumbersome. An alternative might be to adding a "reset" to the startup sequence, which is auto skipped.

The polling interval is important, by dropping it down to 300ms we were able to reduce the "false" positives and make the system more stable. My philosophy is that we 1/3 of a second is sufficient time between polls, the camera operator does not typically make sharp movements, so an additional 150ms of wait time is no going to hurt them. I have done camera 2 or 3 times since making the change and do not notice the difference between hearing the switcher operator telling me that I am live and seeing it on the STAC.