In my case I am using older win10 laptop running JMRI and using "Hot Spot" on the wifi adapter to allow for both my phone and a fire tablet t act as throttles, I am sure there are many out there with older windows computers collecting dust that could task to running their DCC, especially at JMRI really doesnt need much..... Also since I have not seen it while I was working on getting my system up the only way around the windows defender firewall that actually worked for WiThrottle server was to have my throttles connect directly to the laptop using the "Hot Spot" feature in Wndows 10, otherwise it looked like the firewall even though turned off wold block the inbound WiThrttle traffic.
PLEASE VOTE: What repository structure should we have? Right now we have: Organization: DCC-EX (Display Name: DCC++ EX) Current Structure: GitHub.com/DCC-EX ├── dcc-ex.github.io (GitHub Pages Webpage) │ └── BaseStation ├── DCCpp_ESP ├── DCCpp_UNO └── docs Option 1: (just add to existing repo) GitHub.com/DCC-EX ├── dcc-ex.github.io (GitHub Pages Webpage) │ └── BaseStation ├── DCC-EX ├── DCCpp_ESP ├── DCCpp_Classic └── docs Option 2: (Gives classic its own repo) GitHub.com/DCC-EX ├── dcc-ex.github.io │ ├── BaseStation-Classic │ ├── DCCpp_Uno (may name this just DCCpp) │ └── docs └── BaseStation-EX ├── DCCpp_ESP ├── DCC-EX └── docs There are so many issues/questions Because of the way URLs work and the way Github writes everything out in a hierarchy, you have to think through names. You don't want, "DCC-EX/DCC-EX/tree/master/DCC-EX", you want, "DCC-EX/BaseStation/tree/master/DCC-EX" or "DCC-EX/BaseStation/tree/master/DCCpp-EX) Note: Using "++" is out in other than name fields and descriptions because you can't use them in a URL (it will use ugly escape codes). 1. Greg uses DCC++ and DCCpp and DCCplusplus depending. What is the official name of our product? DCC-EX, DCC++ EX, DCCpp-EX?? I like simple (DCC-EX) but should we keep the pp/++ in there? How important is that? And we can still have it called one "official" name and have folder names in GitHub just approximate. 2. Option 1 above just adds "DCCpp_Classic" to the existing structure. Simple, but we could risk people using the wrong version if they try to use Classic with hardware it doesn't support. 3. Option 2 gives DCC++ Classic its own repository, so if you go to github.com/DCC-EX, you will see BaseStation-EX or BaseStation-Classic. Once in either of those, you see the appropriate file structure. (hyphens or underscores are mandatory) This could also just be "BaseStation"
Generally like #2 What's the difference between basestation ex and DCC ex? As far as name I vote DCC++ EX but honestly don't feel strongly. Also I would drop the basestation nameand just call it DCC++ Classic. Simple is better but again no strong feeling if others disagree. Also can we take the ESP out of this repository and link to it? To me it confuses folks. Should be only 2 options. If this ESP based code becomes the basis of our EX then let's rename but I think important you basically see 2 options. Classic and EX (with docs) to avoid confusion. And totally agree on naming (dropping UNO in Classic)
I agree with documenting and putting a stake in the ground for dcc++ classic. Uno or mega with arduino (or directly compatible) shield. Acknowldge all the inital work amd credit orginal development and freeze it as classic. Start new wikis, code base, ect as DCC EX, drop the ++. Support both Arduino amd ESP platforms in releases if possible, but since I am not a coder I am not sure if it is feasable to cleanly support both providing all the same features (I need to research the esp platform). Support 3 different very commonly avalible and reliable shields. 1 in the 2ish amp range, 5ish amp range and the IBT2 for tge 8 to 10A+ range which should give good coverage for z to g scales. If possible keep things modular for pieces like train detection, wifi, turnout control amd other "features" beyond basic dcc control. JMRI does a good job and we should build a relationship with that group, but yes it would be nice to have a more user friendly and basic interface. I could see us building a modual to turn this into a "Zepher" like equivelant that would be a modual for the basic system. IMHO if we want to make something that can be widely adopted amd supported standardazation and control is needed. Possibly a "board" made up of people like FlyByNight, Antani and other major contributers to set goals amd releases. We will also need a group. (I would be will to be one) of testers. As a former developer I sucked at testimg my own code because my brain would just expect things and not look for all the possible error paths, having a few "sets of eyes" to test will help greatly make reliable releases. These are just my thoughts from someone who in the past developed embedded user interface systems.
Firstly @Paul1361 welcome and looking forward to your knowledge contributing. I think there is consensus in what you say with others. My only slight modification would be that I wouldn't limit the motor boards to 3. There is no reason not to support all we can. We can make recommendations or preferred options in documentation but it's not very code or memory intensive to support additional shields so why limit. Just provide for all that are tested and work. Can be easily selected with one number in config. I would envision as more and more motor shield come out over time that list should keep growing and I see no issue with that.
@Keith Ledbetter While I do agree that therebis plenty of room in the code to support many shields amd as others have stated if people want to explore ANY particular shield, so be it. The reason I am saying we limit our direct support is for both QA and the not so technically savy. From a QA perspective we should be testing ALL functions with ALL supported hardware combinations. If no one has stepped forward I would be willing to start work on a QA test procedure manual and tools needed beyond basic dcc decodered locomotives such as mesurable current loads. From a less electronic/programer perspective we can provide solid documentation for these "supported" shields and moduals.
I lost the ability to edit my post because too much time has passed. This is how it should look: Organization: DCC-EX (Display Name: DCC++ EX) Current Structure: GitHub.com/DCC-EX ├── dcc-ex.github.io (GitHub Pages Webpage) │ └── BaseStation ....├── DCCpp_ESP ....├── DCCpp_UNO ....└── docs Option 1: (just add to existing repo) GitHub.com/DCC-EX ├── dcc-ex.github.io (GitHub Pages Webpage) │ └── BaseStation ....├── DCC-EX ....├── DCCpp_ESP ....├── DCCpp_Classic ....└── docs Option 2: (Gives classic its own repo) GitHub.com/DCC-EX ├── dcc-ex.github.io │ ├── BaseStation-Classic │ ├── DCCpp_Uno (may name this just DCCpp) │ └── docs └── BaseStation-EX ....├── DCCpp_ESP ....├── DCC-EX ....└── docs
I know this is very confusing because there are too many variables. The bottom line is that there are "products" let's call them DCC++ Classic and DCC++ EX and there there are respositories and folders in a tree that let you navigate to things. And that navigation is in web links, which can't have + signs and which concatenate in a path. So if you name each step DCC-EX, the link would be "DCC-EX/DCC-EX/DCC-EX/docs...". Look at what we have now: https://github.com/DCC-EX Click on BaseStation and you get: https://github.com/DCC-EX/BaseStation Click on DCCpp_Uno and you get: https://github.com/DCC-EX/BaseStation/tree/master/DCCpp_Uno So is DCC++ EX just that or is it DCC++ EX BaseStation? It would be confusing to go to the DCC-EX top page and then see DCC-EX again to have to click on and then in the third page is a folder called DCC-EX yet again. In GitHub we have an "Orgainization" (DCC++ EX) and then it's "repositories" (website, DCC-EX, DC-Classic, etc.), then the builds or things we include in folders which at a minimum would be the DCC-EX basestation code for PlatformIO and a version for the Arduino IDE. (Step 2 above would hold that). It could also hold classic or anything else. The more I think about it, the more I agree with Atani, that if we put classic as just another version, people might they they can use the ESP code to add WiFi to DCC++ Classic, which you cannot. So the big question are which are their own separate projects with their own separate respositories instead of folders in the same repository. And what do we call all the repos and the folders?
And THIS is another big source of confusion. I think most people may see this folder and think it is DCC++ to run on another platform. IT IS NOT. This is for an add-on accessory. Neither the UNO or MEGA (sadly) have WiFi. So the code in this folder is to upload to a separate ESP8266 board (NOT and ESP32 microcontroller) and then wire that or stick it onto an Arduino (One option is the AI-Thinker ESP8266 Shield). Not a beginners project. It is, however pretty cool in that it acts as a Wifi to Serial Bridge so that you can connect to JMRI wirelessly. The big feature for me is that it also exposes a web server. So you can get rid of your computer and JMRI if you wanted, use your phone browser to connect to the ESP and have a dual cab throttle. There is another opportunity for someone here to provide these boards already loaded with the firmware. Even then, networking adds a layer of complexity and supporting networks is a hassle. There is always some reason someone can't connect. But I do dream of a true starter kit (starter and network edition) where you open a box, plug in cables and power, all by following a 1 sheet help diagram, turn it on and it works. Just like a commercial product. Looks like we have plug and play Pi and maybe UNO/MEGA part of this, which would be great! Then adding networking would be the next step.
. It is there right now if one gets a $35 Pi for the computer. With Steve's $12 image SD card in the Pi they turn it on and it comes up with JMRI and WiFi works out of the box with phone throttles. Nothing else to do---plug-n-play. With the Pi, a monitor, a keyboard/mouse, Keith's $70 pre-loaded Arduino Uno/Shield combination, $15 power supply and a couple cables they can have all of that right now and/or a little later when you guys work on the base code a little more. It is what I have and I've been real happy with it, Sumner
Summer, whenbI was searching around and learning about DCC++ there was no mention that someone was offering prebuilt arduinos and shields, and this was only 1-2 months ago. What is out there , using google searches, and is very disjointed, it looks like a home brew project, which it is. FlyByNight is so right that all the pieces need to be brought together and standardized. Doing this I feel will bring many more modelers into this by making it so that the not as tech savy as us have a centeral , polished repository to draw from.
The model to follow would be Arduino itself (or Raspberry). Slick packaging, clever design. So far, no one has wanted to take it that far. Starting a business like that is a ton of work. I have no idea how many units a month it would be. But if small enough, then a small up charge to cover time plus shipping wouldn't be a problem. As you've mentioned, it should be in a box, tested, professionally packaged, with a color quick setup sheet and a web page/phone number to call.
Wasn't there then, just offered in the past few days. http://1fatgmc.com/RailRoad/DCC/DCC-Index.html Not a packaged deal but still would fill the needs of many. Will be working on an easy quick start guide to go along with what is there but that is already available to a great deal. Keith and I aren't in this for the money and all profits will go here to TrainBoard and JMRI at the present. We are just trying to help the DCC community grow larger. I'm sure new users will do like I did and move on to buying decoders and other commercial products related to DCC. Sumner
I still have some contacts who can do small production runs in metal and I still have my powder coating equipment..... I also have a comtact to do limited electronics production and assembly. If we get enough traction I draw something up and send out a rfq.
My quick throw together... Case, $30 Ac/Dc supply $16 Fan $8 w/grill Panel Mount USB extender $6 And another $10-12 in misc hardware.
Summer I know I am about to put a date stamp on myself, but do you remeber or have you ever seen what Heathkit used to be? Even providing a kit like that would have a major impact IMO
For anything that would potentially be released, revisioned, versioned, etc. independently, I would suggest creating a dedicated repository. That way, standard repository-level version control branching/merging with Git will be more intuitive if independent products are kept in separate repositories. (This also relates somewhat to earlier branching strategy discussions.) Public GitHub repositories are unlimited, so we don't need to worry about trying to stay within some predetermined limit.
Could be very useful indeed. I know @Atani was doing some fab work on his own already. I don't want to derail this thread with a discussion on providing "plug and play" solutions.Sumner and I are offering something that gets pretty close. If we get some real demand there we can start another thread around it as I don't think either one of us has the time or desire to do it with any kind of scale. They do have an official wireless version of the UNO FYI https://store.arduino.cc/usa/arduino-uno-wifi-rev2
My vote would be for 2. And wow, the ESP32 packs a lot of power, I see why @Atani is all over it, it has more than enough capability and expansion to be pretty damn future proof for this application. I can easily see myself building a new system around it.....
