The Gertbot I/O section has no way to read responses. How do you know you are not getting any?Maarten M wrote:I am ..The DCC decoder has not acknowledged any of my programming attempts.
How fast does the Gertbot send out the messages? The DCC service mode standard requires maximum 20ms between the reset message and the programming command.
What does the Gertbot transmit between messages? 0's, 1's or random bits?
How does the Gertbot queue up the DCC messages?
I try to change the Address (CV1) and afterwards verify the decoder still repsonds to command addressed to the original or new address. I will expand the system in the future to actively measure the acknowledge of the decoder.Gert van Loo wrote:The Gertbot I/O section has no way to read responses. How do you know you are not getting any?Maarten M wrote:I am ..The DCC decoder has not acknowledged any of my programming attempts.
The full set of standards making up DCC can be found here: http://www.nmra.org/index-nmra-standard ... -practicesThe DCC service mode standard requires maximum 20ms between the reset message and the subsequent programming command.
Hummm, I did not know about that rule. At the moment reset messages are treated like all normal messages. It always send one idle packet after a command to guarantee the 5ms between same address rule.
I have just started a DCC train project, and am happy to test.As mentioned elsewhere I am working on a new SW release but I have NO LONGER ACCESS to ANY DCC material to test changes.
Setting the flag only suppresses FURTHER idle messages.Thus you always get one.I suspect the idle message between reset and programming command is stopping it working.
Code: Select all
# # DCC configure # This routine does NOT support the 'no idle' flag # # preamble and repeat are set per board, not per channel # dc is not very well supported and the use is generaly discouraged # # 19-Oct-2014 : This function is NOT tested! # def dcc_config(board,channel,repeat,preamble,dc) : #GB_CHECK(board>=0 && board<=3, "dcc_config illegal board\n") #GB_CHECK(channel>=0 && channel<=3,"dcc_config illegal channel\n") #GB_CHECK(repeat>=4 && repeat<=255,"dcc_config illegal repeat\n") #GB_CHECK(preamble>=14 && preamble<=255,"dcc_config illegal preamble\n") #GB_CHECK(dc>=-100 && dc<=100,"dcc_config illegal dc\n") id = board<<2 | channel no_idle = 0 # set to 1 only for testing, debug & development wrtbuf = [PRE, CMD_DCC_CONFIG, id, repeat, preamble, dc, no_idle, POST ] os.write(filehandle,bytes(wrtbuf))
Code: Select all
id = board<<2 | channel no_idle = 1 # <<<<<<<<<<<<< wrtbuf = [PRE, CMD_DCC_CONFIG, id, repeat, preamble, dc, no_idle, POST ]
Having never looked at how DCC works, I always assumed that is what it did. Now you've told me how it does work, I don't think I'm going to touch itGert van Loo wrote:By-the-by : from a technical point of view the DCC standard is appalling!
You have to modulate the power signal!!
Much simpler would have been an RF modulated signal on top of DC.