Topics

DCC++ (dccpp) loco decoder function support

Harald Barth
 

Hi!

DCC++ supports today only the speed of the loco in it's refresh loop
for mobile decoders (inside the Arduino). Mobile decoder fuctions that
are sent to DCC++ with the <f ADDR BYTE> DCC++-command are only sent
to the track once and not refreshed by the Arduino. It looks to me
like JMRI because of this implements some repetition of sending the
<f ADDR BYTE> to DCC++.

1. Where is this repetition implemented? I must admit that I probably
need some "intro to send queues" here.

2. Can one configure the rate of repetiton? Looks to me that this happens
several times a second which is a bit much.

3. The repetitition continues even after the function is turned of and even
after there is no throttle any longer attached to the ADDR. That seems
broken.

I am currently trying to get the DCC++ code so it's more like a
command station (for example together with JMRI) instead of a
standalone-controller of a small layout.
See https://github.com/habazut/dcc-ardu

Regards,
Harald.

Harald Barth
 

To follow up on myself...

DCC++ supports today only the speed of the loco in it's refresh loop
for mobile decoders (inside the Arduino). Mobile decoder fuctions that
are sent to DCC++ with the <f ADDR BYTE> DCC++-command are only sent
to the track once and not refreshed by the Arduino. It looks to me
like JMRI because of this implements some repetition of sending the
<f ADDR BYTE> to DCC++.

1. Where is this repetition implemented? I must admit that I probably
need some "intro to send queues" here.
I wonder if this repetition actually exists or if I stumbled over a
bug because when I test it now (current git master) I only see that
function commmands are sent _once_. I am puzzled.

But still when I a reading the code in DCCppThrottle.java I wonder why
there is this construct with a send queue (inherited from XPressNet?)
which then has states THROTTLESPEEDSENT and THROTTLEFUNCSENT when they
never seem to be used. Looks to me that an implementation like the one
for the SPROG would more fit DCC++.

2. Can one configure the rate of repetiton? Looks to me that this happens
several times a second which is a bit much.
As DCC++ (today at least) can not remember the state of F0 .. F28
some repetition (say evey 10 seconds) would be nice to have. Any
examples to look at?

Regards,
Harald.

Bob Jacobsen
 

DCC++ is an odd system from the point of JMRI support because there’s no clear definition of DCC++, no clear community supporting DCC++ itself. (If such a community exists, nobody here has found it; pointers would be appreciated!) Maybe somebody can create a groups.io discussion home for DCC++ and start to build a DCC++ community?

Absent such a community, it’s hard to know what's the “right” way to operate a DCC connection. And that (a) leads to long, frustrating conversations which (b) reduces the enthusiasm for working on these issues.

Earlier work on functions:

https://github.com/JMRI/JMRI/issues/6529
https://groups.io/g/jmriusers/topic/29656331#156639

https://github.com/JMRI/JMRI/issues/3817
https://github.com/JMRI/JMRI/pull/5769

https://github.com/JMRI/JMRI/issues/3826
https://github.com/JMRI/JMRI/pull/6399
https://github.com/JMRI/JMRI/pull/6229
https://github.com/JMRI/JMRI/pull/6193

Bob


On Mar 15, 2020, at 2:00 AM, Harald Barth <haba+jmri@...> wrote:


To follow up on myself...

DCC++ supports today only the speed of the loco in it's refresh loop
for mobile decoders (inside the Arduino). Mobile decoder fuctions that
are sent to DCC++ with the <f ADDR BYTE> DCC++-command are only sent
to the track once and not refreshed by the Arduino. It looks to me
like JMRI because of this implements some repetition of sending the
<f ADDR BYTE> to DCC++.

1. Where is this repetition implemented? I must admit that I probably
need some "intro to send queues" here.
I wonder if this repetition actually exists or if I stumbled over a
bug because when I test it now (current git master) I only see that
function commmands are sent _once_. I am puzzled.

But still when I a reading the code in DCCppThrottle.java I wonder why
there is this construct with a send queue (inherited from XPressNet?)
which then has states THROTTLESPEEDSENT and THROTTLEFUNCSENT when they
never seem to be used. Looks to me that an implementation like the one
for the SPROG would more fit DCC++.

2. Can one configure the rate of repetiton? Looks to me that this happens
several times a second which is a bit much.
As DCC++ (today at least) can not remember the state of F0 .. F28
some repetition (say evey 10 seconds) would be nice to have. Any
examples to look at?

Regards,
Harald.

--
Bob Jacobsen
@BobJacobsen

Harald Barth
 

DCC++ is an odd system from the point of JMRI support because
there’s no clear definition of DCC++, no clear community supporting
DCC++ itself. (If such a community exists, nobody here has found it;
pointers would be appreciated!) Maybe somebody can create a
groups.io discussion home for DCC++ and start to build a DCC++
community?
I am trying to revive DCC++ but the original author has kindof
vanished (no reaction on email nor where he presented the
original code - I think that was TrainBoard). So no, there
seems not to be such a thing.

Absent such a community, it’s hard to know what's the “right” way to
operate a DCC connection. And that (a) leads to long, frustrating
conversations which (b) reduces the enthusiasm for working on these
issues.
Currently I am often conversating with myself ;-) But I think to have
a commuity there needs to be a first stepping stone to make the code
useful to more as a small nice, which it was originally. With the
original concept you could automate a very small layout but I think it
would be much more useful as a very very cost effective command
station.

In spite of no community, I had already some success today when JMRI
and my DCC++ code did read through all CV of some decoders (Kühn,
Zimo, D&H) without timeouts. With a Digitrax DCS50 behind a LocoBuffer
that was not possible, the DCS50 did throw in the towel and needed a
reset now and then (poweroff/on). In spite of being much slower than
my DCC++ in the first place. Well I probably should make a bug report
to JMRI about the timeouts I encoutered today, but there is this
"only 24/7 per week" problem.


Earlier work on functions:

https://github.com/JMRI/JMRI/issues/6529
https://groups.io/g/jmriusers/topic/29656331#156639
Thanks!

I have the same opinion as pabender commented on Feb 21, 2019.
Especially #2. And 250ms is far too often. If the decoder forgets its
functions because of a 250ms pause the decoder should be better.
And you might have many passenger cars with light decoders. But
I have to read more code until I can make a suggestion.

The repeating behaviour is not there if you run against the DCC++
simulator which makes the simulator a bit useless to debug this
particular problem.

I am thinking as well what would be needed to make the function
commands repeat in the Arduino but mine (Uno) has only 2k of RAM and I
struggled already to make room for 100 loco slots (the original code
has tvelve). I must admit I had to thow out some other stuff like
sensors and save state. Problem with refreshing functions is that you
don't know how many functions are used per loco and thus how much
space should be reservated. Unless you make it dynamic which makes
the complexity go though the roof (and maybe the time for the
interrupt routine generating the DCC-signal as well).

Harald.

Bob Jacobsen
 

The various connection simulators are meant to simulate the JMRI behavior _above_ the connection, not the behaviors inside the connection nor beyond it on the layout. That’s enough for JMRI users to set up their sensors, turnouts and signals, etc. Simulating more than that rapidly becomes very, very difficult, and nobody has attempted it yet.

So they’re not particularly useful for debugging the connections themselves.

Bob

On Mar 15, 2020, at 1:46 PM, haba+jmri@... wrote:

The repeating behaviour is not there if you run against the DCC++
simulator which makes the simulator a bit useless to debug this
particular problem.
--
Bob Jacobsen
@BobJacobsen

Harald Barth
 

(...) might have many passenger cars with light decoders. But
I have to read more code until I can make a suggestion.
I think we can agree that the function refresh should not continue for
ever no matter what (how it is now).

So we need a condition when the repeat should stop. We can not take
the "not selected by throttle" condition because that would make
the passenger car example above impossible.

What about this: The function group in question should be refreshed
as long as the following is true:

At least one function of the group is on
OR
Throttle is > 0
OR
Timer purge-time has not yet passed since last update (default 3 minutes)

Refresh interval should be configurable

So we need a refresh thread whose data structure will
be filled/upated from DCCppThrottle every time a
function state changes and purged by itself,
preferably when the thread wakes up to send
out the message.

What about that? It that a good logic?

Unfortunately my knowledge of the JMRI codebase and
all the methods that come with Java is not that
good so but something with a circular list and
TimerUtil and ScheduleAtFixedRate sounds like it
could do what we want.

Harald.

FlightRisk
 

Hello All. As you have found Harald, we have revived the DCC++ project as of February and have created several resources. I'll post here so people can find us. Here are the Trainboard Threads:

DCC++ Update Project 2020
DCC++ Update Project 2020 Documentation

And our GitHub:

https://github.com/DCC-EX

and the GitHub hosted website we need to flesh out:

https://dcc-ex.github.io/

We have updated Gregg's original DCC++ and will maintain it for bug fixes. It is now called "DCC++ Classic". The new "DCC++ EX" version (for EXpanded Edition) is where new development work is ongoing. This edition is in the "BaseStation" repo. That will be renamed soon.

A groups.io page was mentioned. Should I create one? Or are we good with Trainboard for now?

Bob Jacobsen
 

Excellent news!

Can I link to those from the JMRI DCC++ page? That’ll help people find them.

https://www.jmri.org/help/en/html/hardware/dccpp/index.shtml

As to Trainboard vs other places, i.e. groups.io: Personally, I prefer handling these conversations via email, as a lot of the time I have for that is while disconnected. Is there a way to get email from Trainboard?

Bob

On Mar 23, 2020, at 9:28 AM, FlightRisk <@FlightRisk> wrote:

Hello All. As you have found Harald, we have revived the DCC++ project as of February and have created several resources. I'll post here so people can find us. Here are the Trainboard Threads:

DCC++ Update Project 2020
DCC++ Update Project 2020 Documentation

And our GitHub:

https://github.com/DCC-EX

and the GitHub hosted website we need to flesh out:

https://dcc-ex.github.io/

We have updated Gregg's original DCC++ and will maintain it for bug fixes. It is now called "DCC++ Classic". The new "DCC++ EX" version (for EXpanded Edition) is where new development work is ongoing. This edition is in the "BaseStation" repo. That will be renamed soon.

A groups.io page was mentioned. Should I create one? Or are we good with Trainboard for now?

--
Bob Jacobsen
@BobJacobsen

FlightRisk
 

Yes Bob, Thank you. I'm excited by all the interest and all the talented coders that have volunteered to help. Trainboard does have email notification. It emails you the thread and has a button in the email you can click to go to the web page and read it there if you want.

Harald Barth
 

https://github.com/DCC-EX
My repo is at https://github.com/habazut/dcc-ardu/ and we'll see how
useful the DCC-EX folks will find my code. Today I implemented that
the ack time is actually measured so that the code can detect what is
a real ack pulse from the decoder. (Not every flank is an ack.) As
there was no timer over the code got a bit yucky.

We have updated Gregg's original DCC++ and will maintain it for bug fixes.
Time will tell if that is needed or if it is enough to #ifdef various
parts of the code depending what feature set is wanted. An Arduino
UNO is a litte small to keep all the features at the same time.

Harald.