dcc-ex/commandstation-ex

EX-CommandStation firmware from DCC-EX. Includes support for WiFi and a standalone WiThrottle server. A complete re-write of the original DCC++.

commandstation-ex's Issues

Turnout technologies

TPL needs to be able to refer to turnouts by simple id. There is no place for the bizarre mixture of commands that JMRI uses to transparently handle turnouts without the knowledge of the command station. Nor is there any sense in defining these dynamically.

TPL code currently provides support for the following turnout hardware configurations:

1. DCC Accessory (equivalent to old )
2. Servo connected to servo control board over I2C
3. 2-Pin switch on native CPU pin
4. 2-pin switch on I2C pin expander board

Others may be added as required.

The issue is "how to construct turnout control code such that the old commands work if TPL is not in use and TPL code is not built into the executable when its not used. "

Create better EEPROM storage format

From #66

WiThrottle Tether

From #66 - More of a WiThrottle issue, but add USB "tether" feature to WiThrottle so we can use a USB cable connection without WiFi

RailCom support

From #66 -

• Do we want to create a RailCom cutout, and if so, what timer scheme will we use?
• Do we want to decode the RailCom data and do anything with it? What will we do with it?

<T 1 1> returns <H 1 128>

Should return <H 1 1>
Similarly has same problem

Rework accessory command for 1 part linear addressing option

From #66

Output Technologies

TPL refers to outputs by simple id. the technology is separated from the automation.

Current technologies are

1. Direct CPU pin
2. I2C extender pin

Do we need any more technologies here?

Extended current command

From #66 - Extended command to provide current in reading, mA and show trip value and max value

JMRI exception in SerialDCCppPacketizer

Sent by ([email protected]). Created by fire.

---

Mike created a ticket

Name: MikeBowers

Email: [email protected]

Timezone: -8

Software: CommandStationEx

Version: 3.0.0

Title: JMRI UncaughtException on any function cmd

Description: First I am 99% sure this is a JMRI problem not a dcc++(beta2) problem but I mention it here as the exception is in JMRI jmri.jmrix.dccpp.serial.SerialDCCppPacketizer.sendDCCppMessage(SerialDCCppPacketizer As far as I can tell all the right things happen at the DCC-EX end, the function cmd is sent and the bell rings or the whistle blows or the light turns on. I was running JMRI test version 4.21.2. I will report this at jmri groups.io but not open a JMRI issue as I don't know how

Remaining email Quota: 98

Diags through WiFi/Ethernet

From #66

Layout bus support

From #66 -

Let's discuss what kind layout bus we're interested in developing. We have the possibility of influencing where the industry goes in the future with this, but we also want to remain as backwards-compatible as reasonably possible.

Layout bus technology requires, in most cases, new hardware.

Loop speed detector

From #66

Turnout improvements

• Turnout processing/Better class (may need a filter to handle WiThrottle integration)
• Turnout names? ex: "coal yard"
• Extended turnout command to handle servo/stepper angle?

V Command (verify/validate CV)

From #66

Put RailCom cutout on its own timer

Currently, RailCom requires us to fire an interrupt every 29us. Without RailCom, interrupts can be fired at 58us intervals.

Advantages:

• Can do more in userland time without being interrupted (not sure that that's such a huge improvement).

Disadvantages:

• Need separate timer for each track supporting RailCom (on a FireBox with two main tracks, for example, that would use all three available TCCs).
• UNO cannot generate a railcom cutout because it doesn't have enough timers.

Allow AP mode to be disabled in config file

A user request is for us to disable SoftAP mode so that there is no AP if they want to use their regular network connection.

Layout technology - JMRI vs TPL

TPL requires access to the layout control hardware (turnouts sensors, outputs, signals) and is not compatible with the JMRI way of defining this externally and downloading it at run time... Quite apart from the fact that this severely limits the layout complexity and quickly overflows the EEPROM.

Current TPL code expects a
LAYOUT
ENDLAYOUT
block containing definitions of hardware devices. This information is stored in progmem and only the current status is mapped into bits in a fixed byte array which can be readily stored in eeprom.

It seems to me that it would be entirely reasonable to allow this layout definition in a non-TPL build - as an alternative to the JMRI methods which are fundamentally incompatible with TPL.

Develop WiThrottle Integration plan

1. Use of Withrottle to move stuff about while automation is paused, get stuff into starting positions, run track cleaner train, etc etc
2. TPL to hand over a loco for shunting, and ED to hand it back by sending it on a TPL route.

There are also implications for things like turnouts because TPL cannot operate on turnouts dynamically created by JMRI or ED. In effect, the layout wiring needs to be known in advance for an automation to work. Thus the layout definition (Turnouts, sensors, outputs) is effectively coded in a file that is included at compile time. [Remember the purpose of TPL is to automate within the CS without JMRI.]

May be able to:

• intercept the Turnout aspects of Withrottle to call into the TPL layout handling.
• Intercept loco acquisition so that it cant steal a loco TPL is animating.
• Use Routes to allow ED to send a loco onto a TPL route.
• Pre populate a throttle when handling a loco over from TPL..... BUT not sure how to handle multiple ED clients here.

Automate locomotive management

See CVReader for example. Locomotive management should be automatic and not controlled by JMRI. Allocation/deallocation of locomotives is done by CommandStation instead.

Security: Allow user-specified or randomly generated password

Currently the password for AP mode is generated from the SSID name, which is a security risk. There needs to be a way for the user to define an AP mode password.

Discussion so far included using a random number generator to generate a random number that is then stored in EEPROM and used for all subsequent bootups. The problem with this is that the random number generator is a pseudo-random number denerator, and would have to be initialized (seeded) with something like an analogRead() function or a number generated from the outgoing 1's and 0's of the DCC waveform interrupt.

Currently, the method for changing the AP password is to #define DONT_TOUCH_WIFI_CONFIG and then config the WiFi with the <+> command. Maybe that's good enough.

Consisting

From #66

Help turn I2C Display code into a class

To experiment and see how much memory one library for the display uses, I just put code into the config.h and the .ino file. Need help designing a class to pull that out into its own file. Also need to know how to .print() a PROGMEM version. I commented it out and am using a define.

Async prog track commands over WiFi/Ethernet

From #66

Command to automatically handle long and short locoid writes

From #66

Web Throttle/SD Card on board

From #66 - Might host turnout/input/output data, and/or host an instance of exWebThrottle.

Use ring buffer to broadcast messages from WiThrottle such as power status, speed, direction, turnout state

From #66

Create command list

List all of the keywords/commands that can be used in the API

WiFi credentials override and not saved in sketch for security

From #66

Clean up files

Currently there are too many files in the root of the repo. @Asbelos what is your opinion on moving them to subfolders? In the Arduino IDE recursive compilation is only done on the src folder. Can put the non-config and non-ino files in there? If you want to take it a step further we could divide into even finer folders within src.

Clarify WiFi config documentation

The current WiFi documentation does not tell the user how to get the password for the AP, nor how to customize the password. Overall, the documentation is very wordy and needs to be cleaned up. It should probably be split into two files: a basic setup and an advanced setup file.

Turn the command station into a smart booster

From TrainBoard.

Free memory sensing

Print RAM available in the main loop when (what conditions?) are met. Copy code in from CVReader as a base.

v3.0.0 - Release Candidate Feature List

Existing Features

• Support Mega, Uno and Nano (some features may not be available on the Uno and Nano)
• Configuration for Arduino Motor Board and Pololu board
• Full Throttle Control <t x x x>
• Turnout Control <T ADDRESS SUBADDRESS THROW>
• Define Turnout <T ADDRESS SUBADDRESS>
• List Defined Turnouts <T>
• Sensor Control
• List Defined Sensors <S>
• Output Control
• List Defined Outputs <Z>
• List Status of all Sensors <Q>
• Accessory Control
• Extended Accessory control with same issue of how to handle listing them
• All CAB functions F0-F28
• Ethernet Shield support
• Throttle reminders
• Store Definitions to EEPROM <E>
• Erase All Definitions from EEPROM <e>
• Display Status <s>

New features

• New waveform generator
• Improved CV read byte
• Improved CV read bit
• Improved CV write byte
• Improved CV write bit
• WiFi Client access to WiThrottle
• Wifi AP access to WiThrottle
• Extend Turnout Control <T ADDRESS THROW> (no subaddress)
• Extend Define Turnout <T ADDRESS> (no subaddress)
• ??? How would we display list defined turnouts if we have two ways to input them?
• Individual track power control
• Ability to join the main and prog tracks to act as one (2 districts?)
• Single or Dual-Pin Inverted PWM output
• New, simpler CAB Fn command
• WiThrottle support
• Function reminders
• Filter / user functions
• Extended <c> command
• Extended Accessory Control (1 part addressing in addition to 2 part)
• Diagnostic <D XXX> commands
• Test Multiple Locos
• Test Multiple Throttles
• V Command (verify CV aka validate)

Remove SAMC21/SAMD21/ATMEGA4809 support

Because FireBox is no longer with us, and I'm the only one that has any SAMC21 based hardware, it is best to remove the SAMC21 from the codebase to keep things simple.

Along the same lines, nobody is using SAMD21 (except maybe @mstevetodd - please confirm) so it will be easier to just remove that from the codebase.

Same for the ATMEGA4809 (@PilotinControl25 can you please give a status update here?)

The extra processors can be put into a new branch and held for later use

Base configuration decisions

We need to have a "base configuration" that offers the most wanted features in one setup for a simple install and simple configuration. We can then have one simpler option and as many advanced or specialized options as necessary. What goes in what files for the base configuration and what goes in other files and how does this work with a config.h file?

Optional features and settings:

• I2C Display
• Wifi generic settings
  - tx / rx pins
  - use software serial vs. hardware serial
  - port number
  - MAC address
• WiFi using Ethernet Shield
• WiFi AP mode
  - Server Name
• WiFi Client mode
  Static IP or DHCP
  - SSID
  - Password
  - Baud rate
• Motor Shield Selection
• Comm Interface type (usb serial, ethernet, wifi)
• Use trigger pin (debugging)
• Use EEPROM
• Enable SHOWCONFIG (turning off saves string space)
• Show config detail on/off (jumpered pin to ground displays config/debug info on boot)
• Preamble bit settings (main and prog separate)
• ACK sample threshold

I propose a base setup is :

• default - Mega (but ifdefs sense Uno and Nano)
• default - Serial USB (HC12 can be substituted)
• default - Arduino Motor Shield (numerical choice changes selection)
• must be enabled - Ethernet Shield
• Can we default this and check for "if exists"? User can comment out to save space - WiFi AP mode (default but can set client mode)
• must be enabled - I2C 2 or 4 Line Display (code for both in there)

OLED displays, TPL, RF24, filter examples, etc. can all be in another example .INO file

Turn programming track into booster

From #66 - Turn PROG track into a "booster" so when not in use, it can be a separate power district

MC33926 + Makerfabs Wifi does not stack

Sent by Brad Van der Elst ([email protected]). Created by fire.

---

Hi.

Here is a couple pictures of the MC33926 board with the wifi board sitting on top. The terminals are at the other end of the board from a typical Arduino motor shield. So that puts the terminals where the center pins are located on the Makerfab wifi shield. You requested a picture so please see below.

Maybe the best illustration is here is an Arduino motor shield besides a Pololu motor shield. Both boards are orientation as they would go onto a mega. I like the Pololu shield as the it has a higher Amp rating.

Also I tried the automated installer on my Windows 10 system. The Command prompt window opens for a few seconds and crashes. This is with me running the exe as a administrator. I reran the exe within the Command prompt window and was able to capture the error message. It appears to be trying to find files on the F drive. I do not have a F drive on my PC. See below error message. I have highlighted the lines that I am referring to.

C:\Users\Brad Van der Elst\Documents\DCC ++ EX\BaseStationInstaller-win-x64>basestationinstaller

Unhandled exception. Grpc.Core.RpcException: Status(StatusCode="Unknown", Detail="invalid instance")

at Grpc.Net.Client.Internal.HttpClientCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)

at Grpc.Core.Interceptors.InterceptingCallInvoker.b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx)

at Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext2 context, BlockingUnaryCallContinuation2 continuation)

at Grpc.Core.Interceptors.InterceptingCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)

at Cc.Arduino.Cli.Commands.ArduinoCore.ArduinoCoreClient.BoardList(BoardListReq request, CallOptions options) in F:\TrainStuff\DCC-Ex-Installer\BaseStationInstaller\obj\Release\netcoreapp3.1\win-x64\CommandsGrpc.cs:line 593

at Cc.Arduino.Cli.Commands.ArduinoCore.ArduinoCoreClient.BoardList(BoardListReq request, Metadata headers, Nullable`1 deadline, CancellationToken cancellationToken) in F:\TrainStuff\DCC-Ex-Installer\BaseStationInstaller\obj\Release\netcoreapp3.1\win-x64\CommandsGrpc.cs:line 583

at BaseStationInstaller.Utils.ArudinoCliHelper.DetectBoard() in F:\TrainStuff\DCC-Ex-Installer\BaseStationInstaller\Utils\ArudinoCliHelper.cs:line 225

at System.Threading.Tasks.Task.<>c.b__139_1(Object state)

at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute()

at System.Threading.ThreadPoolWorkQueue.Dispatch()

at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

I was able to load the Sketch via Arduino IDE and get the Wifi running and linked to my router. Of course without the motor shield in place. I suspect there may be some edits to setup the Mega and the Pololu motor shield. Where are those located? Is there a read me somewhere for that?

Brad Van der Elst

18350 Potter Bluff Circle

Anchorage, Ak

99516

907-227-8680

Figure out how to set motor board in config file

The code that uses a define to create an alias for ARDUINO_MOTOR_BOARD works just fine and compiles on everything except the Github check. Let's find a better way to do this then.

New WiThrottle Integrations

From #66

Command Station 3.1 Release Candidate Features

New Features for 3.1

• TPL Automation
• New WiThrottle Integrations
• New JMRI integrations
• Rework accessory command for 1 part linear addressing option
• Create better EEPROM storage format
• Add SDCard support option
• Extended command to provide current in reading, mA and show trip value and max value
• Consisting
• V Command (verify CV aka validate)
• WiFi credentials override and not saved in sketch for security
• Allow DCC accessory messages over PROG track
• Web Throttle onboard the CS
• Diags through WiFi/Ethernet
• Async prog track commands over WiFi/Ethernet
• DIAGs through WiFi/Ethernet
• Turnout processing/Better class (may need a filter to handle WiThrottle integration)
• Turnout names? ex: "coal yard"
• Extended turnout command to handle servo/stepper angle?
• Loop speed detector
• Off board accessory drivers API
• Command to automatically handle long and short writes
• Customizable LCD display
• Use ring buffer to broadcast messages from WiThrottle such as power status, speed, direction, turnout state
• Implement frame rate monitor
• Finalize use of Command
• Add a command to JMRI and the CS to report a list of device capabilities (devCaps structure)
• Add loconet support? (use their throttle)
• Add USB "tether" feature to WiThrottle so we can use a USB cable connection without WiFi
• Turn PROG track into a "booster" so when not in use, it can be a separate power district

Bus support

• evaluate LCC, RF24, MQTT, etc.

Installer

• Add full cross-platform support
• GUI Enhancements
• Built-In serial monitor
• WiFi support

WebThrottle-EX

• Save Turnouts (needs new data structure)
• GUI enhancements

Hardware

• Railcom support
• FireBox/FireBit
• Mobile throttle

Extend <T> command to operate turnouts on GPIO

It would be useful if it was possibly to set up a turnout that was controlled by the IO pins of the Arduino via something like a relay.

Implement frame rate monitor

From #66

Off board accessory drivers API

From #66

New JMRI integrations

From #66

Allow DCC accessory messages over PROG track

From #66

Large DCC Pakets.

Hello all,

I was directed to this GIT from a comment made on the old Site DCC++. There is a dialog that explains a bit more.

There are DCC packets of up to ten bytes of data. For example the CV XPOM command. The original code does not handle
such large packets. I have adapted the "loadDccPacket" routine to generate the bit stream. If there is interest to include it, just let me know.

DCC++ is just great for starting digital model railroading!!!!

Sensor technologies

TPL handles sensors by id.

Technologies supported

1. Direct CPU pin
2. I2C expander pin

Note that the code also supports inverse sensors (e.g an IR sensor using beam-break detection where the sensor is HIGH when triggered, vs an IR obstacle-detect sensor where the output is LOW when triggered)

Customizable LCD display

From #66

Finalize use of Command

From #66

Connecting to WiFi AP Error

Sent by ([email protected]). Created by fire.

---

Martin created a ticket

Name: MartinBäfverfeldt

Email: [email protected]

Timezone: 1

Software: CommandStationEx

Version: 3.0.0

Title: WIFI not working

Description: I intend to beta test version 3.0.0 beta 2. I have downloded the software sucessfully but can´t get the wifi-board to operate. The setup is a mega with Deek motor and ESP01s wifi. It is installed according to DCC++EX guides. I can se that the system comes up with wifi OK in AP mode (serial monitor). I have been able to connect with my phone to the IP adress 192.168.4.1 with password PASS_87e6a5 (info from serial monitor). When I start EngineDriver i try to connect with 192.168.4.1 port 2560 but it times out with errormessage "ECONNREFUSED".

Remaining email Quota: 100