My Modified DCC++ Base Station - Notes

Travis Farmer Jul 26, 2019

  1. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    thought i would start a thread to log notes regarding my modified version of the DCC++ Base Station.

    I was away from the project for a while, but my interest has been re-powered, so to speak. i got an issue notice on my GitHub for my version of the code, that the MCP23017 modification did not work, so i dug out, and dusted off my original prototype, just a bit ago, and noticed it was still setup for Ethernet, where i thought i had made a WiFi adaptation. where i work on stuff, no longer has a direct Ethernet connection, so i attached my Adafruit ATWINC1500 breakout WiFi module, and coded it into my copy of DCC++. this is not mandatory, as i left the original functions for Ethernet still in service, and i think the serial connection still works as well.
    now, this modification seems to be a little unstable during compile, as about 10% of the time i get a error. not yet sure what causes it, but fair warning.
    Long story short, i connected to JMRI, tested a few things, and it seems to work, though i have not yet documented how to use it, as my main attempt here was simply to provide the WiFi connection so i can debug things.

    my next course of action, is to debug the MCP23017 issue, by connecting a test interface with at least two chips, and pour into various configurations to see what works, and what does not.

    i still don't have space, or money, to setup my dream layout, but in the meantime, i can adapt and debug my variation of the code. oh, and watch my loco go round and round on a circle of cheap test track. :)

    so anyway, i look forward to continuing my work here. :coffee:

    ~Travis
     
    IronMan1963 likes this.
  2. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    i noticed notes in another thread about using a CT, instead of the IBT-2 current sensing. the IBT-2 sensing worked for sensing the CVs coming in, but i was never happy with the actual value from the IBT-2 sensing. so while i debug the MCP23017 handling, i am also exploring the use of CTs.

    ~Travis
     
  3. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    in regard to the MCP23017 issue, i finally got a test prototype setup again. the first MCP worked flawlessly. however, when i configured the code for two MCP chips, chip(0, wired A0-G, A1-G, A2-G) worked flawlessly, but chip(1, wired A0-5, A1-G, A2-G) would not respond to output. i thought sure i tested this with hardware, but perhaps with only one chip, and felt satisfied.
    i just verified from the datasheet that my wiring is correct, including the addressing. so now i turn to my code, and see were i went wrong. :coffee:

    ~Travis
     
  4. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    ok, i haven't tested it yet, other than with a calculator, but the problem was in my MCP23017 library. the exact specifics are described in this: https://github.com/travisfarmer/tjf_mcp23017/commit/0e87bc7594fefbe0124190220f578eae0659842d

    turned out to be a reversal of mathematical order. i have not yet tested it, but i suspect it may fix the issue. i will test on hardware tomorrow after work.
    anyway, if anybody is using my MCP23017 library, either make the changes listed above, or re-download the complete library to replace the old.

    ~Travis
     
  5. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    nevermind... still doesn't work. (n)

    well, it works for the first MCP still, but no change on the second. getting very frustrating. especially where my Hantek 4032L logic analyser is not driver compatible with windows 10, despite the "disable driver signing" trick, so i am forced to use my 2CH digital oscilloscope to watch the pin changes.

    what i need is somebody else with some MCP23017 chips to help debug my library. i think the DCC++ code is fine, just my library. any takers? maybe even some extra eyes on my library code? i have uploaded the latest code that compiles to my GitHub.

    it may even work now. i haven't gone back down to my workshop to test it...

    ~Travis
     
  6. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    could it be so simple?
    this function in my MCP23017 library:
    Code:
    /**
     * Register address, port dependent, for a given PIN
     */
    uint8_t tjf_mcp23017::regForPin(uint16_t pin, uint8_t portAaddr, uint8_t portBaddr){
        return(pin<8) ?portAaddr:portBaddr;
    }
    will always return portBaddr, for any pin number greater than, or equal to 8. so pin 16 (first pin of second MCP) will return the wrong port.

    Code:
    /**
     * Register address, port dependent, for a given PIN
     */
    uint8_t tjf_mcp23017::regForPin(uint16_t pin, uint8_t portAaddr, uint8_t portBaddr){
        return((pin%16)<8) ?portAaddr:portBaddr;
    }
    this change should (will test after work) reduce the pin number by modulo 16, and should convert 16 to 0, and return the correct port, in theory.

    i will post the results of the test after work.

    the effect of the bug, when setting mcp.pinMode(), will set the INPUT/OUTPUT mode for the wrong port. i am eager to test this, in the hope it is the solution.

    ~Travis
     
  7. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    i was reading back through some posts, and i have to admit, my modified version is actually the work of Atani, with the exception of the MCP23017 code. IIRC, it is based off work i did a while back, but the work for this batch was done by Atani. just wanted to place credit where credit is due. hard to keep track with open-source software. a lot of hands in the cookie jar, so to speak. ;)

    ~Travis
     
  8. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    ok, my MCP23017 library (used by my modified DCC++ base station) has a bug. this much is clear. for those fluent in c/c++, the issue is listed on my GitHub: https://github.com/travisfarmer/tjf_mcp23017/issues/1
    it works fine for the first added MCP chip, but something falls through the cracks with the second MCP chip. i assume with all further MCP chips added after that.
    I just sent my latest code to GitHub, so whomever helps has what i have to work with.

    i have been testing with the multi-mcp_toggle.ino in the examples directory.

    ~Travis
     
  9. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    solved my MCP23017 library issue, i think. bit ashamed to say it, but i think the issue was mostly hardware. you know the Reset pin on the MCP chips? yeah... forgot and left them floating...
    i may eventually add to the library a function to handle MCP resets, given a pin, and have it reset as soon as the mcp.begin() function is called. a simple quick blip from high, to low, and back high (through a resistor) should do it. or even more logical, install a pull-up resistor to the mcp reset pins (all tied together), and use a simple NPN transistor to sink the pins for a reset, then return to normal.

    EDIT: this is rather inspiring... i may yet work on finding space for my layout. :)

    ~Travis
     
    Last edited: Aug 1, 2019
  10. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    in continuing the construction of a better prototype of my DCC++ base station, i was going to use a MEGA2560 CORE module from eBay, with the prototype board. but then i remembered i have a RWP Mini 2560 from http://www.crossroadsfencing.com/BobuinoRev17/ , so why not build from that? it really is a great version of the MEGA2560, as it is very minimal, yet breaks out all the MCU pins.
    I plan on making my system as modular as possible, to make room for upgrades, yet i want a good solid design. rather contradictory, perhaps, but we will see. my original thoughts were to use an I/O bus system, where i could plug upgrades right in. but soon realized that was simply over-complicating things (if you know me, you know i tend to do that, a lot).
    my plan is to break out I/O lines for two DCC++ connections (main and programming), and use an intermediate conversion board between the MCU, and the motor drivers. more power districts can be added later, if i find i need them.
    my communication method will be my Adafruit ATWINC1500 WiFi module. general I/O will be through a combination of some MCP23017 I/O expander chips, and remote located MQTT-based I/O system.

    the layout itself will, if i design it right, be some sort of modular system, as i doubt i will reside at this location for the remainder of my life. though currently, it consists of a circle of track, this circle will later be my programming track. block detection will be through the use of HALL-effect sensors placed between track ties, and strong magnets glued under the train. years ago, i was all set to use RFID chips, but due to cost and complexity, that idea fizzled out.

    I will be using a dedicated CentOS Linux laptop running JMRI for control, and automation.

    ~Travis
     
  11. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    Quick question, why do DCC++ outputs, configured through JMRI, default to turnouts? what if i want them as signal lights?

    ~Travis
     
  12. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    nevermind, i figured it out. (y)

    ~Travis
     
  13. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    not sure what happened, but my DCC++ seems very sketchy on reading CVs. i setup my test track circle to make sure my version of DCC++ still worked, but as i said, something happened. i can control my loco on address 127. it has the ability to program on the programming track, but reading CVs works sometimes, and not other times. i suspect a dirty track, so i am running the loco around to see if it "wears in", before i change much code. i did lower ACK_SAMPLE_THRESHOLD (PacketRegister.h) from 3 to 2, and was able to successfully write a CV, and was able to read it back, but when i tried a second CV, i was only able to write it, with no read-back.

    so, if cleaning the track doesn't help, i am thinking i need to use a supplemental current sensor, or a different motor driver module for just the programing track. the main track seems to function as i remember. i tested a track power short, and it cut-out and self restored. i did this 4 or 5 times i think, and it stayed offline, as expected. so that isn't an issue.

    to check for a dirty track, i ran the loco as slow as it would go, and i only found 2 hesitation points, that cleared up with some fine steel wool (track power off, of course).

    so, i am on the lookout for a single channel motor driver module, with current sense, but with a lower scale of current sensitivity. a motor driver shield is not an option for my setup.

    i will scan eBay, but if somebody knows of a module that will fit the bill, i will consider it.

    also, i finally tried the WiThrottle (JMRI) with my tablet (Engine Driver). very nice! i do believe i have found my walk-around control.

    ~Travis
     
  14. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    well, i think dirty track is corrupting my power, again. that and the contact at the track joints is rather poor. i think i may have to get into some heavy duty cleaning of my test track (a circle of Life-Like Power Loc).

    as least the cat found the loco going around to be amusing. sat in the circle and watched it go.

    anyway, not ready to fully commit to saying it isn't the fault of the track crud. just needs more cleaning. i think it is steel track, so not much corrosion resistance.

    ~Travis
     
  15. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    Based on a tip from a friend, i found a blank 5U rackmount enclosure ( https://www.circuitspecialists.com/rackmount-enclosure-37-5u.html ), that i will be building my DCC++ hardware into. it should have room for the power supplies (18Vdc, and 5Vdc), as well as the main prototype. i will also be adding an internal shelf for future add-ons, that i am sure i will come up with. like a board with several MCP23017 i/o expander chips.
    at first i wanted to use all MQTT for remote inputs and outputs, but i have settled on MQTT outputs, and MCP23017 sensors. i figure the sensors may be better with faster hardware, and the outputs (turnouts, lights, layout scenery, etc) can stand to be whatever the speed of MQTT recognition is.
    still haven't nailed down the cause of my CV read errors. i will be testing that by first using clips to connect the loco DCC decoder directly to the prog side of the DCC++ base station. if that works, i will work my way out from there, until i narrow down where the faults are coming from. i already suspect my track, but there is only so much cleaning i can do, before the track is "cleaned" down do CODE 00 track ;)
    I really have to get some real track to work with.

    my reason for going with a rackmount enclosure, is that it adds to the mounting options. my hope is that when i setup my layout, finally, i can mount the enclosure right into the fascia of the bench work. all my connections, aside from the power cord, will be made right on the face of the enclosure, as i plan on running the layout wiring behind a fascia cover panel. mainly to save me from crawling under the layout much. the 5U enclosure is a little over 8 inches high, so i should have plenty of room to work with.

    ~Travis
     
  16. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    still alive, just haven't had anything to update on.
    just wanted to say, i am finally starting to acquire various parts to start building a layout. :)
    building my DCC++ prototype into the enclosure i bought is going well. i mounted everything using self-adhesive velcro, in case i want to change it later. just a note for others, some double sided mounting foam tape, may have restive adhesive. causes very peculiar errors that are hard to trace.

    when i start building, i will start a different thread in the correct board, here on the forum, and link to it here. i may even start it sooner to outline my plans, so others can chime in if i am doing something incorrectly.

    ~Travis
     
  17. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    came to the realization, it doesn't seem anybody cares what i am up to, so the updates will be on my own website.

    Merry Christmas everyone, and may everyone's holiday season stay on the rails. :)

    ~Travis
     
  18. drbnc

    drbnc TrainBoard Member

    57
    64
    10
    Hmmm... I've been following along, FYI.
     
  19. Travis Farmer

    Travis Farmer TrainBoard Member

    352
    320
    14
    Hmm, ok. thank you! it just felt like i was talking to myself in this thread. ;) no likes, no comments, no recommendations. i suppose i could have looked at the number of views... (just realized actually) could have been just the stress of "the day before".

    anyway, back to business.

    not much to report though, been financially busy with "the season".
    though, i did gift myself one of these: HO RTR SD40-2, UP/Desert Victory #3593 (ATH71530): Athearn Trains
    bit of an impulse, but i couldn't resist. i even have a "TCS WOWSound WOW121 Diesel 1527 21 Pin DCC Sound Decoder Version 4" on it's way. :)
    should be a teaser for things to come...

    i will start the layout thread when things get going.

    ~Travis
     
    Last edited: Dec 24, 2019
  20. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    Travis please keep posting here but also on your web site which I can't seem to find via the links in your signature. Probably right in front of me :unsure::(.

    I also like posting here and also on my web site. Often can't remember how I did something so going to my own site helps,

    Sumner
     

Share This Page