DCC++ Update Project 2020

FlightRisk Feb 16, 2020

  1. haba

    haba TrainBoard Member

    78
    32
    10
    Disclaimer: I am not a lawyer, so use what I say with enough grains of salt. ;-)

    > loconet is not open source

    LocoNet - the protocol - is not software so the question is not if it is open _source_ but under what license you may use it. But yes, if you want to sell products which incorporate LocoNet support then you need a LocoNet license. If you need a licenese to _implement_ LocoNet support in an open source software is another discussion, your legislation may differ from mine. But that point is moot as the JMRI project as I understand has a license, so you may add whatever you want to JMRI to support whatever LocoNet features. Then I think you may build hardware (and matching firmware) that takes bits from your wire into your computer and vice versa. Depending on leagalize you may not _sell_ hardware that is LocoNet specific. That hardware works independent from if the bits and bytes represent LocoNet or not. Then your computer interprets these bits to be LocoNet, for example with JMRI.

    > rocrail

    Don't get me started on rocrail. The main author of rocrail did remove the GPL on rocrail some years ago. To republish his own code with a different license or even without a license and close down the source (even if it's bad taste) is one thing. To do so with code that others have contributed under the GPL is another. I will not use or work with rocrail. Btw, threads about license questions are deleted on the rocrail forum (which is run by the rocrail author).

    Regards,
    Harald.
     
    David Cutting likes this.
  2. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    I just started a hardware thread under the DCC++ thread. I included my schematics so far - can anyone take a look and critique them? We will move further discussion on hardware over there, and I am about to go create a software thread.
     
  3. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    And those skills are exactly what we need. There is a lot of information out there (some that might need correction) that needs to be collated and sifted for the documentation we need and to have a flow that creates a circle of the hardware, the setup, the operation, the technical, the add-ons, and back again. I'm looking forward to your help in the documentation thread.
     
    David Cutting likes this.
  4. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    @FlightRisk, I just submitted a pull request to the documentation github. Is that the best way of adding stuff or do you want to give me access to the repo?

    David
     
  5. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Both :) Even with full access, it is good to have a review process where at least one of us looks over things. Thanks adding to the documentation. There is so much out there to pull from and we are going to have to do some editing and think of the flow for the different types of users. We have "quick start guides" we started on as well.
     
  6. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    What do all of you think about the accessory decoder addressing scheme DCC++ uses? Should we change it? I know it is one of the things Geoff Bunza didn't like about DCC++. EX:40 needs to be entered in the 2 part form as "10 and 3" decimal. That's not a problem for software like JMRI since it sends whatever DCC++ needs, but the rest of us would need a calculator. The NMRA spec is ambiguous, so either way is probably correct, but what should we do? Is there any reason I'm missing about why NOT to change it? More examples:

    address 45 becomes 12 0
    address 46 becomes 12 1
    address 47 becomes 12 2

    If we agree, we can keep JMRI from breaking until we can issue a PR to them by having an ifdef for "USE_2PART_ADDRESSING" or somesuch.
     
  7. haba

    haba TrainBoard Member

    78
    32
    10
    Do you mean how the a and the T command take adress and subadress? Yes, that's unfortunate but I would _not_ change the behaviour of a and T (which is quite overloaded).

    Btw, because of the historic confusion how to read the standard, depending on command station manufacturer different accessories are adressed on the wire when you in the user interface throw switch X (typically with a offset of 4).

    Question: What is the value of storing turnouts in the Arduino with the T command in the first place? Who is using that? I would just use the a command from whatever higher level software I was using.

    Question: Do you actually use some interface beyond debugging where you need to enter address/subadress?

    Question: If you want a command that lets you conviniently use decimal addresses, why not add one?

    Regards,
    Harald.
     
  8. RandyR

    RandyR TrainBoard Member

    25
    6
    2

    A little side track here, FlightRisk. We can PM if you don't want to mess this thread. About this accessory addressing. I've been searching for a reason why my Bachmann DCC Turntable(address 3) for not do anything using the JMRI layout, but works fine when used as a throttle. I saw on another website that the address should be the accessory address. Where can I find information on these addressing? I tried changing it to 255 per his post but still does not work. So wondering if this addressing you mentioned here was the key to me getting the turntable to work. Thanks
     
  9. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    What is the decoder under the roundhouse? 44915? 44926? Something else? There are two types of decoders:

    mobile (aka locomotive, aka multi-function)
    stationary (aka accessory)

    You would think that since a turntable which doesn't roll down the track and is "stationary" and an "accessory" would fall under that address space, but it does not. It is the same decoder that is in a locomotive. It uses the speed and direction commands that you would send to a locomotive to move it. So think of it like an engine motor that drives a train. The addresses are in different "address partitions", so when there is overlap, the decoder ignores an address that is not in its partition. Look here:

    https://dccwiki.com/Address_Range

    (assuming 2 bit addresses and baseline, ie: not extended, packets)
    locomotive addresses 1-127
    accessory addresses 128-191

    You would need to think in binary ;) Here is a are packets where A = Address bit, C = Command and D = Data, S = speed :

    Code:
    locomotive decoder
    
     preamble       address     data     error chk
    111111111111 0 0AAAAAAA 0 01DCSSSS 0 EEEEEEEE 1
    
    accessory decoder:
    
    111111111111 0 10AAAAAA 0 1AAACDDD 0 EEEEEEEE 1
    
    
    They are in different formats. Notice the 10 at the beginning of the address byte for the accessory decoder. That tells the decoders that this packet is for an accessory decoder. The data packet is different too. One decoder would not be able to make sense from the other. It might make it do something, but it wouldn't be what you wanted ;) It gets more complicated than this with long addresses, but this may give you the idea. So if you are using JMRI to try to talk to an accessory decoder, your locomotive decoder sees an accessory decoder packet and ignores it. The same holds true for extended addressing where you can go up to addresses over 10,000.

    Does that answer your question?

    P.S. If you want, look at the source code in the PacketRegister.cpp at the setThrottle and setAccessory functions that create the addressing and data for those packets.

    P.P.S JMRI handles the issue in the original post. It does the math so that you just put in normal addresses and it sends what DCC++ expects. So that is unrelated to your issue.
     
    Last edited: Apr 10, 2020
    RandyR and OzLodger like this.
  10. RandyR

    RandyR TrainBoard Member

    25
    6
    2
    Thanks for getting back to me on this.
    I am using the 44915 decoder on it.
    I am able to control it like a loco using the throttle panel when it was on address 3 and address 255 after changing the address. Just not when i try to move it as a turntable on JMRI layout.

    Will look at the wiki you sent to read more about it. Hopefully I will get it to work and actually post a "how to" video as there is pretty much nothing out there so far which runs through the process.
     
  11. haba

    haba TrainBoard Member

    78
    32
    10
    There are turntabes out there which use an accessory decoder adress for each track and then can run automatically to that track (from Heljan?) In contrast to that, the Bachmann turntable uses a loco decoder and is controlled with speed and direction like a locomotive. The JMRI turntable symbol only works with the accessory type of turntables where you have an accessory adress for each ray track. So if you want to run your Bachmann turntable from JMRI the only graphical symbol that is available now is a throttle. Btw, I have converted an old Arnold Rapido tunrtable with a loco decoder inside which I run from a loco throttle.

    Regards,
    Harald.
     
  12. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Sorry I wasn't more clear. I gave a long explanation and should have just said "You can't get there from here!" ;)
     
  13. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Did you mean "overloaded" as in the code is already something that can slow the system down or "overrated" as in not really of much use?

    Yours is exactly the kind of input I am trying to get us to talk about. I wish more people would join in for a "survey" of what we should and shouldn't have in DCC++ EX. We can't be all things to all people. And there will be people who still make a fork and change something that is not in our scope. Our market is for beginners, tinkers (build it myself / software / electronics hobbiests) and for people who want to save money. There may be features we can offer that some of the commercial systems don't have. Beyond open source like ours, the commercial systems like Digitrax offer a lot for people. For me, I don't understand why you would need 127 loco addresses ;)

    I don't know and I don't know :) I think this may be from the "turnkey" system Gregg initially began with his "Controller" software written for the Processing IDE. I don't think anyone uses that either. Maybe also for people who want to do automation which is pretty interesting feature, but also one that will probably not have wide support. You wouldn't need any external software to control turnouts but I think most people use JMRI as their front end anyway. So you are right that we need to focus on what functions people will really use.

    See previous answer.

    That is a good option. Unless anyone jumps in to say we need to change anything, it seems we just leave it as is (or even remove things)
     
    Sumner likes this.
  14. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    I understand having frustration if one is putting a lot of effort like you guys are into a project and not getting feedback. The problem here might be that what you guys are doing is just above what maybe 95% of us are capable of understanding. My programming days ended in the 90's and I'm way behind the curve with what you guys are doing as I was self-taught then and haven't progressed. If I was 20 years younger I'd be jumping into this and catching up but realistically now I have to devote my time to what gives me the most back in the shortest possible time. I have a feeling others on here are in the same situation.

    I think you guys need to move forward without us and make the best decisions you can. Hopefully we will still be around to reap the benefits of your efforts. We for sure appreciate what you are doing and what Gregg did by himself to lay the groundwork for where things are now.

    I know you guys are trying to add a number of advanced features but also believe that many in the hobby are still stumped with just getting the basic Classic DCC++ up and running and then running trains, wireless throttles and programming with JMRI. I've only had one request for a SD card for the Pi with Steve's image on it. Now with Dex's installer and the pre-loaded SD card you can't get much easier than that but still no ground swell of interest in either as far as I can tell. Keith have you had any requests for your pre-loaded Arduino? I'm sure it will take time as there are thousands of people in the hobby that don't frequent this board and don't go to the DCC section of it much. So they don't even know the current options for moving from DC to DCC exist at this time.

    One update....I have Dex's initial install of Classic on an Arduino and have used it to program a couple loco's and run them on a short piece of test track and I've had no problems. Are you finished with the work on the Classic and is it different than what I downloaded? If so I'll put the new version on and try it out. Maybe a separate thread that is called "Classic DCC++ update newest and latest information" might be a good. Separate it from here.

    Sumner

    P.S. Even though some of us are now limiting input to this thread doesn't mean we aren't following along and trying to understand what we can.
     
    Mani likes this.
  15. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    279
    195
    12
    In my opinion and it's only that.

    We need to really focus on getting the controlling and programming of trains through DCC the best we can and fully nmra compliant so the packet talk is fully relevant and I think extremely important to get best we can.

    Then I think we need to test it for programming like crazy. I'm sure we could get at least a dozen on this board to help testing. We should test as many different decoders as possible etc and try to get the programming track code as robust as other programmers our there. To me that's when we call a big win and the next major release as it's probably the biggest complaint with original DCC++.

    Then I think we should add as many motor drivers as possible and test again. At a minimum an original and a high power one but no reason we shouldn't have at 5 or 6 supported fairly quickly. We should designate a default but make something easily selectable.

    Then and only then in my opinion should we move on to accessory issues. DCC accessory addressing should be first. I think followed by LCC if possible but agree the more we could support the better as far as Loconet, S88, CMRI, etc. Again to me if we could do LCC and DCC then we hit out goal of NMRA open source.

    @Sumner to answer your question I have had only one inquiry and they didn't go through with purchase after indicating interest and I agree that with @Dax work that's about as easy as it gets so uptake won't happen by osmosis. There will need to be effort of "marketing" it to get folks interested.

    DCC++ when introduced was a slow burn and took a lot of time to get a reasonable following. This relaunch will be the same. We need a good EX release that we can really tout the upgraded parts then we can cast a broader net and get more to test and try.

    We are on the right path here. Key will be to keep scope right and not bite off more than can be done in a reasonable timeframe. The key will be releases that build on each other on a regular basis rather than a huge release after everything is perfect.

    Documentation will absolutely be a key part and one I quite frankly have dropped the ball on a bit as my job has become crazy with Covid but I am still fully committed to the lead and organizing that but again all volunteer here so things will ebb and flow as folks have time.

    I think if there is a specific ask of what we are looking for opinions on etc we can create polls, mention in other threads etc and that will help. Just know we'll never please everyone and at some point have to make the calls.
     
    Last edited: Apr 11, 2020
    Mani and David Cutting like this.
  16. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    Excellent vision @Keith Ledbetter - I think you've got it just about right. A couple of comments from my end...
    1. Hardware - DCC++ needs its own boards. We can make many flavors of boards, but for DCC++ to mature further, IMHO we need to have a plug and play solution. Or several. I can imagine the ESP32 getting baked into a base station, as well as the raspberry pi. We also need a booster station so we can cater to larger layouts.
    2. Hardware - I agree about the need to nail the DCC part of things before we get any further, but we need to be thinking forwards. May I suggest that we consider a standard expansion header that would allow LCC, LocoNet, S88, CMRI, etc to be added to any hardware coming out of the project?
    3. Software - RailCom support in DCC++ would be beautiful. It's an NMRA standard, so there's no reason we should not be developing for it.
    Others - please chime in with things that we should be focusing in on. Again, Keith you've got it just about right.
     
  17. haba

    haba TrainBoard Member

    78
    32
    10
    Custom HW is nice as you can design it to do what you want, but....

    The problem with custom HW ist that you never get the numbers up to get the price down. That's the reason why we should base our stuff on off the shelf HW (Arduino, Motorshields, Raspi etc) with _maybe_ (rather not) _small_ additons which the user can make himself. HW that is available all over the world. Otherwise the cost is creeping up to what you would pay for example for a Digikeijs DR5000 and then what's the point?

    In additon to that, selling your own electronic HW which is a consumer product (not a kit) has many regulations in the EU (CE-marking, electronic waste regulations etc) and therefore is almost unfeasable if you are not a company of some size.

    Regards,
    Harald.
     
    Sumner likes this.
  18. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    279
    195
    12
    Imo you were on right track with your DCC++ hat project earlier.

    It needs to be very simple in my opinion. A hat and/or a shield for Arduino. And we should provide plans for people to diy of needed. Whole point of this is open source and realizing not many of us envision this as an hardware provider competing with the commercial systems available but certainly if you want to do fabrication etc go for it. I was in for your hat before it died.

    Again for the EX maybe going with different hardware base may indeed be the way to go and leave classic sort of alone. Given the cheapness of a mega plus a shield though I think that is the best way to go as base for the purpose of cheap easy and open source unless of course it really limits ability to support things like LCc then you have to move to better base hardware.

    My point let's crawl before we walk before we run. Great projects due from scope creep or to big a scope.
     
    Last edited: Apr 12, 2020
  19. ChuckB

    ChuckB TrainBoard Member

    15
    1
    3
    Hardware - I agree about the need to nail the DCC part of things before we get any further, but we need to be thinking forwards. May I suggest that we consider a standard expansion header that would allow LCC, LocoNet, S88, CMRI, etc to be added to any hardware coming out of the project?

    Hey guys,
    Just found out about this discussion and I see there are 24 pages of comments to read through. I have been using DCC++ on a Mega with ethernet and motor shield, plus my own design of an S88 shield with 3 S88 ports. It's working OK so far and I have friend who just got one of my boards and is getting set up to use it.
    Are you interested in my input? I'm not sure where to start.
    Chuck
    Retired Automation Engineer
     
  20. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    @ChuckB , we would love to have your input. Would you consider yourself more helpful on the software side, the hardware side, or the documentation side?
     

Share This Page