DCC broken in latest master 53c9bd8 and at least after 3c42798

[TrainzLuvr]

I spent the whole evening troubleshooting my hardware thinking something I broke in the mean time. Turns out the software is broken.

I went back to 3c42798 (last commit of Aug 30) and DCC is actually working, compiled with ESP-IDF v4.0.1.

The culprit is probably those serial LEDs which need to go and be replaced with simple single colour ones. As-is they take valuable resources on the ESP32, and for what, fancy lights?!

There's really no reason for fancy lights, if the basic functionality suffers. Personally I feel DCC and Railcom+ are more important than colourful lights, so I propose the following:

1. Use pin 22 for WiFi LED only,
2. Power LED should come off of the DC input,
3. OPS and PROG LEDs should come directly off of the OPS and PROG outputs.

Thanks.

[atanisoft]

The LEDs are an optional module and are not required for your usage. You can always disable it.

However, there does appear to be a regression as part of the IDF v4.1 support. It isn't directly tied to the update of NeoPixelBus.

[TrainzLuvr]

I do want LED indication but it does not have to be a multi-colour spectacle, single colour is fine by me.

[atanisoft]

There's really no reason for fancy lights, if the basic functionality suffers. Personally I feel DCC and Railcom+ are more important than colourful lights, so I propose the following:

We are in 100% agreement here. The Status LED module is an optional component that should not have any influence on other core functionality of the CS.

• Use pin 22 for WiFi LED only,

Unfortunately even the current usage of a single LED is not ideal since there are two operational modes of WiFi that can be simultaneously active. There ideally should be two LEDs for WiFi for this reason and I've considered adjusting the LED assignment to be WiFi-STA, WiFi-AP, OPS, PROG, EXT.

• Power LED should come off of the DC input,

There is no POWER LED in use today so this is a non-issue. In fact virtually all ESP32 module boards have an LED on them for this specific purpose.

• OPS and PROG LEDs should come directly off of the OPS and PROG outputs.

In the current v1.3 PCB that is available as an option.

[TrainzLuvr]

All of this should be made a nobrainer for users, unambiguous UX, so they don't need to know for example that ESP32 has power LED, or that WiFi initialized STA but not AP.

Is there really a need to indicate WiFi STA vs AP mode? I think not, if WiFi is on, the unit will either connect to AP (STA mode) or become one. I really do not believe users will want to see that kind of granular indication of function, because in all honesty, it doesn't matter. WiFi LED should, IMHO, indicate a successful init of WiFi, whatever that was set at.

Come to think of it, you included support for a full blown display, and that could display all the pertinent information for those who want to look at it all the time.

Power LED is to indicate there's power to the whole system. Maybe not pick the DC plug as a source, since ESP32 already provides an indication (although users need to know that's what it is). But then some other power rail of the system, which also indicates "all green we got power everywhere".

OPS, PROG, and perhaps CAN too, should be there as defaults LEDs, not as option. ESP32 is a black box otherwise - there's no way of knowing things are working unless a DVM and a scope are used, or it's plugged into a USB serial monitor.

[atanisoft]

Is there really a need to indicate WiFi STA vs AP mode?

Possibly not, the current code differentiates between the two as two different colors but in the case that both interfaces are enabled it will end up showing only one color (almost always station).

Come to think of it, you included support for a full blown display, and that could display all the pertinent information for those who want to look at it all the time.

That is an optional module as well and brings in other complexities that not everyone wants/needs.

But then some other power rail of the system, which also indicates "all green we got power everywhere".

Right now on the PCB there are indicators for the following:

1. 5v power (via esp32 power LED)
2. OPS track output (LED on A and B outputs, also exposed as TP6)
3. OPS status (GREEN: NORMAL, YELLOW 75% utilization, RED: SHORT, OFF:OFF, also exposed as TP7)
4. PROG track output (LED on A and B outputs, also exposed as TP5)
5. PROG status (GREEN: NORMAL, YELLOW 75% utilization, RED: SHORT, OFF:OFF, also exposed as TP4)
6. WiFi active (GREEN: Station connected, GREEN BLINKING: Station connecting, BLUE: SoftAP active, RED: Station disconnected, OFF: all off)
7. EXT-1, EXT-2. Currently unused (OTA does blink all five in a pattern as it receives the updates).

Possibly missing indicators:

1. LCC-CAN activity
2. LCC-OPS output LEDs
3. 12v power (used only for LCC-OPS so maybe optional)
4. RailCom "on" (exposed as TP1)
5. RailCom "short" (exposed as TP3)
6. RailCom "data" (exposed as TP2)
7. OPS "brake" (exposed as TP8)

If I can find a safe way to provide indicators for LCC-CAN activity I can add that, LCC-OPS LEDs is doable but space is tight near the RJ45 sockets.

ESP32 is a black box otherwise - there's no way of knowing things are working unless a DVM and a scope are used, or it's plugged into a USB serial monitor.

The ESP32 will always be a bit of a black box even with LEDs as they are only usable up to a certain point. There are currently eight test points on the PCB for diagnostic testing via logic analyzer or scope. Even the serial monitor is a bit of limited diagnostic tool since most people will not have a way to utilize the USB output while also simultaneously powering the PCB on the layout.

[atanisoft]

DCC signal issues appear to be resolved.