Just a quick finding:

DDX with only DCC is not managing to send the idle packet….

DDX with MM activated does  😯

I have made the test with the option of MMLP (long pause for motorola)… and still, the idle packet is sent.., but the normal packets (in the experiment for loco 23) is never sent.

I have been trying to find out why the ttyAMA0 port is not working with rocrail.
So far, I have not found the answer… but it is clear that the port generates with no problem the Motorola packets, but not the dcc ones.
I have been capturing the output with the oscilloscope and decoding them, with only dcc active… and including one loco and no loco.
The outcome should be the idle packet as sent by rocrail:
11111111111111101111111100000000001111111110
When I used an USB converter, that is precisely what is obtained…now, when I used the AMA0 port… it seems not being able to generate even the right bit code:
In the picture: 11X…

After two 1 received… there is a weird signal… neither a ‘1’ nor a ‘0’
I have also tried to measure directly from the GPIO pins… and the results are the same – discarding any problem with the board I prepare to adapt the voltage levels.

So next step… see if the problem is in the way rocrail manages the serial port… or if it is just a problem with the AMA0 port – for that I would need some help form the rocrial community.
PS:I have made test to send a file of 2MB at the baudrate used to generate dcc packets… and it arrived with no problems to my PC.

This afternoon I extended the tests. Some extra information:

The serial port in the rpi ttyAMA0 does not seem to be able to generate the dcc signals. The tests I made where with a Motorola loco.

TAMS (motorola) OK

Loksound (dcc) Not OK

DIY acc decoder Not OK

The work around so far is to make use of a USB-Serial adaptor:

TAMS (motorola) OK

Loksound (dcc) OK

DIY acc decoder OK

I will post if I found out more…at this point it is clear considering the fifures above that the ttyAMA0 is no generating the entire signal. It seems the ttyAMA0 is not capable of changing the baudrate.

Finally I have been able to prepare an adapter for the uart port at the rpi and check that rocrail works perfectly (so far). Hereafter a small video demonstrating the achievement.

Rocrail is using the ddx library to send the commands through the serial port of the rpi. The booster board (ord-3) is powering the test track. Peter Gilling, designer of the board, advised on reducing the value of the resistor R1 – I am currently using 390 ohms- , this is also convinent for usb-rs232 converters. He was also concerned about the rpi being able to generate the signal… This is something that needs further tests… so far, with just one loco and without launching rocview, it seems to work OK.
The raspberry has been adapted with a connector to generate the right voltage levels. It is based on this design I found on internet.

I am attaching hereafter the schematics and the board.

serial

serial_pcb serial

I have left some jumpers to select the signal being generated in the UART pins or other GPIO pins. In this way, if I want to play to generate the signal directly, and not though ddx, I could have a test board… this could also help to experiment and activate certain functionalities not available with usb converters -i.e. shortcut detection or programming track. In the same way, power can be selected (5v or 3v).

Note that the connections of this board would require a null-modem cable. The ORD-3 is expecting the signal in pin 3 (where the RS232 port of a PC would provide it), and the adaptor is generating the signal in pin 2. In fact, the adaptor is prepared to connect the rpi to a PC.

Obviously, it is possible to create a board with the right pin layout to directly interface the ord-3:

serial_cross_pcb

serie_cross serial_cross_pcb

Last but not least the guideline to use rocrail in a raspberry pi has been updated:

Setting up rocpi_v1.3