search

uniba-swt / libbidib

A library for communication with a BiDiB (www.bidib.org) system using a serial connection.
GNU General Public License v3.0
10 stars 4 forks source link

Phantom Trains Detected #18

Open eyip002 opened 2 years ago

eyip002 commented 2 years ago

Trains not physically on the tracks are sometimes reported by the hardware as being detected, e.g., by MSG_BM_SPEED and MSG_BM_ADDRESS.

akuhtz commented 2 years ago

This is an issue of decoders in most cases. Are you running the latest firmware in the GBM16T ?

BLuedtke commented 2 years ago

We are running >= 2.1.1 on our GBM16T boards.

One model railway system has mixed firmware (6 boards, mix between 2.1.1 and 2.07.02). The other has 2 GBM16T boards, with firmware 2.1.1 on both of them. The phantom trains occur on both systems.

So, almost, but not quite the newest firmware (going by the release log here).

akuhtz commented 2 years ago

In most cases it's caused by DCC decoders answer in wrong timeslot according to threads in opendcc forum. What decoders do you use?

However there was a fix in 2.07.02 related to wrong address detection. See https://www.opendcc.de/elektronik/gbmboost/gbmboost_faq.html --> GBM16T.

BLuedtke commented 2 years ago

Interesting; also just saw the fix in that changelog. Maybe it occurs only when on tracks "managed" by GBM16T boards with the older firmware. That's something we have to test.

We use Doehler und Haass DH18A and DH12A decoders. I don't have an openDCC forum account yet, but will create one and check there as well. Thanks for your help!

akuhtz commented 2 years ago

D&H decoders should work fine normally.

eyip002 commented 1 year ago

Finally updated the firmwares on our model railways to

eyip002 commented 1 year ago

Ghost trains haven't been encountered when we set the train decoder address to 63 (0x3F) or 127 (0x7F), which do not include 0's in their binary representation. When driving cargo_db (0x01), we got ghost trains with addresses 0x02, 0x04, 0x05, and 0x06, but never for 0x03.

The following addresses appear to work reliably without ghost trains appearing:

eyip002 commented 12 months ago

Updated locomotive addresses to the following:

eyip002 commented 11 months ago

Phantom trains are still observed with the new locomotive addresses. The problem really does seem to originate from the GBM16T boards due to some sort of caching effect: https://github.com/uniba-swt/libbidib/wiki/Phantom-Locomotives-Reported-by-BiDiB

akuhtz commented 11 months ago

@eyip002 Can you add the addresses of the loco that are running on the layout and the address of loco that is not on the layout in your test to make reproduction easier? Thank you.

eyip002 commented 11 months ago

@akuhtz The problem doesn't seem to be tied to any particular loco address. For my testing I was using 0x7F for the loco on the layout, and 0x42 or 0x6F on separate occasions for the phantom loco.

opendcc commented 11 months ago

Hello, phantom addresses are typically caused by decoders answering in the wrong cutout. This is somehow tricky to trace down, since the reported ghost address has nothing to do with failing decoder. It simply depends on the (dynamically changing) sequence of DCC commands on the track. I've added some 'hunting tools' inside the GBM16T firmware, but these tools require an addtional serial cable connected to the GBM16T. And there is also some filtering available to sort out single ghost events.

eyip002 commented 11 months ago

Thanks for message @opendcc! Do you know if this "phantom address" issue is documented somewhere so that I can read more about it? It's been a while since I read up on the DCC bus, so I can't quite remember how the decoders are allocated (round-robin?) a slot in the bus schedule (especially when trains are added onto the tracks).

I just remembered that a single BiDiB speed request is turned into a DCC command that is broadcasted continuously to the track outputs. This at least explains why the phantom loco address remains in the GBM16Ts.

eyip002 commented 11 months ago

@opendcc We also have an FTDI-RS232-TTL serial cable that connects to the debug headers of the GBM16T. We had to use it to update the firmware on the GBM16Ts. Is this the cable that you're talking about?

opendcc commented 11 months ago

Do you know if this "phantom address" issue is documented somewhere so that I can read more about it? I've commented on this issue several times on forum.opendcc.de

This at least explains why the phantom loco address remains in the GBM16Ts. This 'phantom' are not cached or whatever in the GBM16T, these addresses remain active on the tracks until this loco is removed the host firmware. When there is no such removal, the address is alive forever (and phantom can occur with this address).

What is done with 'hunting phantom'?

opendcc commented 11 months ago

addtional info: ghost hunting is currently on by default

eyip002 commented 11 months ago

@opendcc What is your user name on forum.opendcc.de so that I can quickly find your comments?

Thanks for the information on accessing the debugging features in the firmware.

opendcc commented 11 months ago

opendcc as here.

eyip002 commented 9 months ago

We've found that, by disabling the speed feedback (Kanal 2 (CH2) für Daten ein) of our D&H DH18A 1st Gen decoders, we no longer get phantom trains being reported.

We also received new DH18A 2nd Gen decoders with firmware 3.13. With this new decoder, I haven't observed any ghost trains even when speed feedback is enabled.

BLuedtke commented 1 month ago

As a small update - the DH18A 2nd Gen decoders still work nicely and we don't get ghost trains with them.
I installed a DH10C-4 Gen2 in a new train yesterday and that also seems to work well with channel 2, but I have not run it a lot yet.