implement morse-code status led blinker

[jeffkowalski]

I have put together a (mem- and code- cheap) morse code blinker.
I had initially thought it might be useful to convey messages to us users.
Before I check anything in, I would like input.

Broad questions:

1. Would it be better to blink one led in morse (e.g. blue flashes dit/dah) or to have the two colored leds alternate (e.g. blue dit, red dah)? The visual difference in color may be much easier to discern.

2. What messages are most appropriate? For example:
   CQ WIFI = "looking for wifi client"
   QSL WIFI = "found wifi client"
   QRV .. QRV .. QRV = "all ready from setup"
   E = "generally working, ready, waiting, ...." [most often omitted]
   QRT .. QRT .. QRT = "going to sleep"

3. what might we code for problems/errors?

Comment? Good idea, bad idea? What would you like to see?

[poynting]

I'm torn on this. I think there are two main things that have to happen for the device to be used:

First, we need a WiFi connection, but not finding a host and waiting as an AP is a valid state.
Second, we need a radio. If we don't have a radio connection we can't do anything.

Once we have the two of these, I want the device to be as innocuous as possible and wait patiently for me to do something.

If we don't have one of these, I want the state to be clear that we don't. I almost see it as modal. Until we are talking to a client and talking to a radio, the only job is to do those things. Once we are, let me know if there's an error that I can't see otherwise if action is required by me.

As far as implementation:

1. IMO definitely blink one.
2. Shorter is better. "AP AP AP ..." if in AP mode without a client request in past 15 seconds or so.
   "KX KX " if no radio connected. Alternate AP and KX if no radio or client.
3. I think E/Number or E/Letter is a good error code.

Maybe I'm looking at it wrong, but I feel the killer use case for SOTAcat is SSB ops that don't have a better way to spot when they don't have cell service, and for people that have forgotten to set an alert (or changed destination last minute). For many of these, CW might not be a first language yet.

See discord for some discussion on stand-alone ideas, in that use case CW may be more powerful as a UI. Along these lines I've done devices with small beepers/buzzers in them, and beeping CW (or just a nag "you left the power on") might be a valuable tool.

[brianmathews]

The current implementation already communicates much of this. The current startup sequence is:

1. Both LED's go on as soon as the bootloader finishes and our code is run.
2. Red LED turned off after WiFi is initialized.
3. Both LED's alternate-flash after mDNS and the Webserver has started, finishing with the Red LED off, Blue LED On.
4. Blue and Red LED turned off after radio connection established.
5. Blue LED blinks based on auto-shutdown timer
6. Red LED blinks based on network / command activity
7. Blue LED inverts when in a live FT8 session

Now there may be an issue with step-2 in that the code might turn the Red LED too soon (after the call is made, but has not succeeded yet). We can look into that as a possible bug (or not).

I do like the concept of CW codes for when we want to communicate much more information beyond the current "network is live" and "radio is live". For now we only have a few states to communicate.

[jeffkowalski]

Yes, the current implementation already has a lot of blink codes to communicate status. We'll need to document those so folks know how to interpret this private blink language.
I thought perhaps CW might be more universally understood.
I fully agree that since most of the message-bearing blinking is during startup, or pending a shutdown, the current implementation is just fine and easy to describe and comprehend.
If ever we need a more complex blinky comm scheme, I've got one in the wings ;)

[jeffkowalski]

Closing this as "won't fix".