rm5248 / trainutils

Train utilities(DCC/NCE/LocoNet/LCC)

Cab bus / Loconet / LCC utilities

Directories here:

CabBusCommunications - Talks to the CAB bus. Handles the protocol conversions. All in C code. LocoNetCommunications - Talks to LocoNet. Handles all the protocol conversions that need to happen. CabBusToLoconet.X - MPLABX project for PIC32. Uses both CabBusCommunications and LocoNetCommunications to talk to both sides. CabBusToLoconetComputer - A Linux/Unix program which uses both CabBusCommunications and LocoNetCommunications to do the conversions. Protocol - folder which contains protocol information for both LocoNet and the CabBus LCC - Contains LCC related code LoconetTCPUtil - Utilities related to using Loconet over TCP GUI - Train GUI that lets you do things

Notes:

• If you are using CabBusToLoconetComputer, make sure to set your latency timer to 1 for the USB to serial connection! It won't work well otherwise: echo 1 > /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/ttyUSB0/latency_timer

You can also make a udev rule like this:

ACTION=="add", SUBSYSTEM=="usb-serial", DRIVER=="ftdi_sio", ATTRS{serial}=="FTU7E2W0", ATTR{latency_timer}="1"

Change the serial that you are looking for to be the serial number of your FTDI cable.

Building

Not all dependencies are available thru apt for debian/ubuntu based systems. Support for APT is TBD.

Configuration files for vcpkg are available, you can try those.

cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=/home/robert/vcpkg/scripts/buildsystems/vcpkg.cmake -DBUILD_GUI=ON

License:

GPL v2 ONLY

trainutils's Issues

AMR collision handling

CAN frame transfer: section 6.2

Currently, LibLCC fails the test of an AMR frame when running with the OlcbChecker.

Improved API for sending packets

Need to add a function that lets the LCC code know how much space there is in the send queue. For example, if there is not enough space in the send queue for us to do a full datagram transfer(8 packets), then we should send back an error.

Send back error if already doing datagram transaction

If we are already in the middle of a datagram transaction, send back an error to a node that requests us to do a new transaction. This helps to ensure that the response to the previous transaction has been sent before we try to process a new one.

Integrate OlcbChecker into test process

Since an LCC checker already exists, we should integrate that into the build process to make sure that LibLCC behaves appropriately.

Source: https://github.com/bobjacobsen/OlcbChecker

Throttling / queueing of frames on LCC CAN

The API of the write callback on LCC is defined as "fire and forget":
https://github.com/rm5248/TrainUtils/blob/master/LCC/examples/simple-node/simple-node.ino#L28C1-L28C1

This API assumes that any time that the stack decides to call this function, the bus is free. This is not a valid assumption. The LCC stack must be prepared for the bus being busy and stop generating frames until the previously generated frames were transmitted to the bus.

It is important that when the writes to the bus are throttled, the stack must still read and process the incoming traffic. Therefore it is not an OK solution to pause the stack until the output frame was transmitted. It is also true that the new incoming traffic might generate output data, which might seem like a contradiction.
There are four priority bands in OpenLCB, and it is designed such that a request of priority X will generate a response of priority X-1, therefore even in the presence of a fully loaded bus, the responses that are generated will go out.

The way LibLCC is written today, it will lose messages when the output buffer in the CAN controller is occupied. This will cause problems that are hard to recognize and reproduce. The assumption of LCC is that all messages are delivered.

alias generation should be randomly distributed

The alias generation for nodes should be randomly generated over the 12-bit alias space. It probably isn't at the moment.

more than 8 events

if datagram too big (more than 8 events), datagram is cut in parts, but each part starts from 0
in LCC_memory.c, at line 240:

memcpy(response + start, data, data_len);
====>
memcpy(response + start, data + starting_address, data_len);

thank you for the wonderfull job.