oorail Posted February 11, 2020 Author Share Posted February 11, 2020 49 minutes ago, RobjUK said: Exactly! If you control the track power, you have all the drawbacks of track-wheel connectivity. If your lighting module is not controlling the motor, then that's also messing up any armature feedback through the track DCC puts the motor controller in the ultimate location, directly against the motor. With buffering, which many newer decoders include and is a simple add-on for most others, temporary loss of track connectivity is irrelevant. I'm guessing from your tone the existence of this has sort of upset you. No worries, you don't have to use it! What you said above here is pure nonsense, the power has to flow through the track-wheel whether you are using DC or DCC. We've tested the DDC system for a very long time, there is no impact on lighting using the system because of the way PWM works. Perhaps you should go read up on it? 49 minutes ago, RobjUK said: Garbage. You are comparing two totally different things in a meaningless way. The performance of whatever CPU is in a device is irrelevant, as long as it is sufficient to do the job properly. DCC is a signalling protocol that does not require radio or cause interference to other services. Actually thats not true at all, the hardware architecture and performance of the microcontroller play an important role in what can be done. DCC is a signalling protocol thats piggybacked over your power source. Its not the most ideal of communication methods. 49 minutes ago, RobjUK said: And using WiFi is, to be blunt, idiotic. The ESP32 is 2.4GHz only. With any system using 11n in the area, there is not sufficient bandwidth for even two simultaneous transmissions without collisions. In many cities 2.4GHz systems slow to a crawl or just give up at times due to congestion & hidden station effects. You don't know too much about WiFi do you. What you've written here is complete nonsense. 2.4GHz is the frequency spectrum, 802.11n runs off both 2.4Ghz and 5GHz, and the frequency spectrum is channelized. Modern wifi systems adjust the power output of the radio and perform analysis on the channels to avoid collections. What you've basically said above is the equivalent of saying if you have two mobile phones in the same room they won't work. Complete nonsense. 49 minutes ago, RobjUK said: More garbage. The components used in DCC decoders are all off-the-shelf parts. Anyone can build them from various kits or by buying parts & using stripboard or whatever. Not really. You are missing the point. You can assemble this system by buying 2-3 items off Amazon, plug together and off you go. You can't do that with DCC. Also if these kits are so available how about some links? 49 minutes ago, RobjUK said: And source code?? There are dozens if not hundreds of examples freely available I've just found an N-gauge decoder design, even - source code included and about $5 in parts to build: http://web.nucky.jp/dcc/decoder4/onecoindecoder4.html Dozens? Hundreds? So far you've provided two? 49 minutes ago, RobjUK said: Or a source package on github: https://github.com/Railstars/Aegaeon Eh, this code hasn't been touched in about 6-7 years, and one of the outstanding issues from 2013 is that it doesn't output properly?? 49 minutes ago, RobjUK said: And of course all the MERG stuff, which is dirt cheap, extremely well designed, and with free source code. Again, this is all about providing options. You guys seem really adverse to having options, why is that? 49 minutes ago, RobjUK said: IF that were the case, I may have been slightly more impressed by the idea - but the github repository apparently contains nothing but waffle and blurb. That is the case, either you have no idea how to navigate GitHub or you are just knocking it for the sake of knocking it? The code is in the modules directory. 49 minutes ago, RobjUK said: You can run any number of locos independently from one controller on one layout. Track power control means one loco per track section & one controller for each section. You need as many controllers as locos, and without the seamless running of DCC systems. That is one way to do it. However if you are a little smarter about it, you don't need one controller per section. If you check out the PSU video, you'll see you can control two modules with one PSU, and each module controls two track sections. So you can effectively power four block sections very cheaply. Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 39 minutes ago, oorail said: There is no such thing as a WiFi domain. WiFi operates on different frequency bands, and each band is split into channels. There are a wide range of techniques you can use from adaptive radio management (adjusting the channel / power levels of the radios) to maintain appropriate levels of SNR. There are things you can do at a packet level (802.11) that will discourage other access points from selecting certain channels. A layout, especially at an exhibition is a pretty finite space, it would not be a challenge to establish a very workable WiFi network even when you are dealing with hundreds of conflicting access points. There are a number of vendors - Aruba, Ruckus, Ubiquiti, Cisco etc, that have done this at trade shows for well over a decade. Its a non-issue if you know what you are doing The issue is an exhibitions there are large numbers of disparate and separate WiFi systems, ( I used the term domain ) these consume channels , you have no way of controlling tyrs3 under 802.11 as they are not connected together and hence not subject to management its not conflicting access points , it’s the swamping of all the available WiFi channels and the in ability to control them where they are all unmanaged ( as is the case) Yiu are confusing managed wifi, say at a big conference, like web summit . The facts are that are large MR exhibitions this issue has been experienced and there is a serious question mark over the suitability of WiFi for control Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 3 hours ago, Junctionmad said: As a person that develops for esp32 there’s a lot of hyperbole around Cool, the more folks developing on esp32 the better. Do you have your code up on GitHub somewhere? What kind of things do you like to develop? 3 hours ago, Junctionmad said: the big advantage of dcc is the ability to drive trains wherever you like without section switching Yes, that is also one of the goals with this solution. I currently have a prototype board stuff into a Hornby Class 66 that allows you to control the loco that way, and it also works with the track control. Once I have modules that have tested safely for a few weeks, and I have the time to document it up, I'll push the code and the documentation / video for it. 3 hours ago, Junctionmad said: as for conversion from AC to dc to ac for dcc , so what Extra processing steps.. 3 hours ago, Junctionmad said: esp32 is a dual core processor , many sound decoders in dcc are now high performance 4 core This is a very simplistic way of looking at hardware architecture. There is a lot more to it than that, you should know that as well being a developer? Do you have a link to the spec sheets for these 4 core decoders. Soundtraxx have a couple of 32-bit decoders but there is no indication on their site as to the specifications, they also run US$188 compared to $5 for an ESP32/32S. 3 hours ago, Junctionmad said: note of you deploy lots of pwm bassed dc controllers along adjacent track sections , you better have synchronised pwm or you’ll short the H bridge . It will be amusing to see how that’s done over Wi-Fi That isn't a problem. I've already got this working in proof of concept. Even if you crank up the density of the block sections (for example if you want to build dynamic blocks). Its handled by code in the microcontroller with the control plane done via WiFi. This really isn't that hard, I have over two decades of experience writing code for high-end enterprise networking devices (eg. firmware) across layer 2-7. Its not hard to do if you apply the right techniques. For example, I saw someone post a few months back that it was impossible to do something via RFID, however I was able to do it by increasing the output of the RFID emitter and optimizing how the data was written to the RFID sticker. 3 hours ago, Junctionmad said: lastly as a builder of a layout with 70 CBUS modules all Can bus nodes I run two wires and power between each board and you clearly have zero idea about the uses for a bi directional layout control bus I'm very familiar with CAN. You still have to run the two wires, you don't need to do that with WiFi, and WiFi doesn't suffer from the node limitations of CAN. CAN can only support up to 64 nodes. 3 hours ago, Junctionmad said: lastly Merg members have already designed a superior system to yours. Open source for Merg members, why invent the wheel Do you have a link? There seem to be a lot of people very afraid of this system why is that? 3 hours ago, Junctionmad said: by all means talk up your scheme , but it’s not new , and it will not displace conventional Dc or DCC Again, this is just another option. Its something I developed for my layout because there wasn't anything on the market that let me do what I wanted to do. Looking at the tone and the number of posts you've made, you seem to be afraid of this system for some reason. Why are you worried if it replaces DC or DCC or both? 3 hours ago, Junctionmad said: Ps ESPNOW round trip time to ACK packet is truly awful , it’s a very slow protocol Yeah I did come across some folks that ran into that problem. It looks like it may have been a bug in the ESPNOW stack, I have tested several MESH configurations with it, and haven't run into the RTT problem. Its also possible that the guy who was complaining about it had a mistake in his test code. The original problem was reported some 11 months ago, no longer seems to be an issue. ESPNOW has some potential but WiFi + IP can be optimized so easily, I am not sure for model railways you would need more than that. Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 19 minutes ago, Junctionmad said: The issue is an exhibitions there are large numbers of disparate and separate WiFi systems, ( I used the term domain ) these consume channels , you have no way of controlling tyrs3 under 802.11 as they are not connected together and hence not subject to management its not conflicting access points , it’s the swamping of all the available WiFi channels and the in ability to control them where they are all unmanaged ( as is the case) Yiu are confusing managed wifi, say at a big conference, like web summit . The facts are that are large MR exhibitions this issue has been experienced and there is a serious question mark over the suitability of WiFi for control Oh I understand what you are saying. I'm not confusing anything. What I'm saying is that there are "ways" to "guide" unmanaged access points so they don't interfere with your network. There are a wide range of techniques you can use to do this. Think of it as "herding" the other unmanaged wifi access points / routers to go where you want them to go, often this is done by creating conditions that trigger features that cause the neighboring access points to react a certain way. Exhibitions are a very small subset of model railways compared to layouts at home, where you won't really have this density issue, and if you do, you've got other problems! For exhibitions though, there are other things you can do to limit the impact of neighboring wifi, even outside of software. It really is a non-issue. Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 (edited) Quote Practically, are you ever going to have more than one train per block except for maybe in a siding or depot? If you have a main or branch line, you'll never have more than one train in a block anyway? If you have more than one train running in a block, your blocks are probably too big. You sort of touched on one of the things you can do with this, which is slicker changing between blocks. With a little more effort, you will also be able to use this to build dynamic blocks, which you can change via software! This is a bizare statement for a railway modeller to make of course you have often two locos or more in a block , calling on being a classic case , or station pilot engine operation , leaving aside banking and multiple engine heading secondly if you are using the L298 driver , you need to synchronise the PWM waveforms in adjacent blocks otherwise you’ll short the H bridge of one controller repeatedly as the wheels bridge the gap. This was an issue in Mergs CANDC distributed CANbus DC controller and needed a sync line fed to the controllers. How do you address this with DDC The whole project will be a solution looking for a problem, (a)unless you fit loco based decoders , you don’t get any benefit over conventional DC , whether or not you deploy 10 bit speed steps. (B) if you fit loco decoders , you might as well fit DCC decoders and get all the benefits of a developed eco system (c) track side control overs no benefits over conventional DC which can implement the same thing with a few section switches (D) the technical complexity is such DC users will avoid it and DCC users get cab control “out of the box “ (e) right now there’s few throttle options , like a proper button based throttle (/wired or wireless ) (f) you still have to distribute 12 v track power and switch frogs etc , that’s means bus systems and drivers and frog switchers , still have interbaseboard wiring etc. (g) there are no general purpose IO for layout control , multiplexed mimic panels leds etc. (h) WiFi’s comms issues are very hard for the non technical user to debug and issues like IP resolution , routing etc are not well understood by the average railway modeller i wish you well , but it’s intended “ market “ has not been thought through , to run down DCC , whose installed base is literly huge and worldwide in an attempt to justify your project is really pathetic and ridiculous. your attempts to paint DCC communications , given the many 1000 s of layouts using it daily as somehow less then adequate are just rubbish and utter contrived ( like the 128 versus 1024 step non issue and the nonsense comments over AC->DC conversion comparisons ) justfy your project by comparison with normal dc layouts dc layouts (a) technically simple ( #1 reason people stay with it) (b) uses simple components (c) no software or computers needed (d) cheap (f) easy to debug and repair disadvantages (a) does not provide cab control (b) sound is difficult ddc track side control (a) technically complex ( b) no advantage in operations over conventional dc (c) ability to control multiple sections requires lots of track side modules = expensive (d) isolating locos in sidings requires conventional isolating switches & wiring , no savings (e) requires a knowledge of software and electronics hardware (f) needs computer h) not easily user repaired Sorry but but if you think this will convince any numbers of DC or DCC modellers to switch , you’re very misguided Edited February 11, 2020 by Junctionmad Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 6 minutes ago, oorail said: Oh I understand what you are saying. I'm not confusing anything. What I'm saying is that there are "ways" to "guide" unmanaged access points so they don't interfere with your network. There are a wide range of techniques you can use to do this. Think of it as "herding" the other unmanaged wifi access points / routers to go where you want them to go, often this is done by creating conditions that trigger features that cause the neighboring access points to react a certain way. Exhibitions are a very small subset of model railways compared to layouts at home, where you won't really have this density issue, and if you do, you've got other problems! For exhibitions though, there are other things you can do to limit the impact of neighboring wifi, even outside of software. It really is a non-issue. As a person who has written 802.11 stacks , what you says is largely nonsense for 2.4ghz solutions Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 (edited) Quote Again, this is just another option. Its something I developed for my layout because there wasn't anything on the market that let me do what I wanted to do. Looking at the tone and the number of posts you've made, you seem to be afraid of this system for some reason. Why are you worried if it replaces DC or DCC or both? What you do and how you justify it for yourself is fine , just don’t try and suggest you have a serous competitor to dcc that’s all. Im not afraid of it , why would i , as i have said , it’s not unique , and it doesn’t address current issues on DC layouts nor address the typical DC modeller, that’s all its you , with nonsense 128 versus 1024 speed steps stuff that should be afraid , afraid of speaking nonsense Edited February 11, 2020 by Junctionmad Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 (edited) Quote Do you have a link? There seem to be a lot of people very afraid of this system why is that? No links as they are not public , you have to join merg. But there are currently Arduino based distributed dc solutions , pic based and STM32 solutions in merg at present, plus hand held throttles , smartphone servers etc , all that can control DC in various centralized and distributed formats. Critiquing your design is not to be conflated with being afraid of it. If anything you seem overly eager to self justify , ( a form of confirmation bias ) Edited February 11, 2020 by Junctionmad Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 (edited) . Edited February 11, 2020 by Junctionmad Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 (edited) Quote Yes, that is also one of the goals with this solution. I currently have a prototype board stuff into a Hornby Class 66 that allows you to control the loco that way, and it also works with the track control. Once I have modules that have tested safely for a few weeks, and I have the time to document it up, I'll push the code and the documentation / video for it. There are several Bluetooth and WiFi systems with loco based electronics https://www.wifimodelrailroad.com http://www.wifitrax.com http://bluerailtrains.com http://monocacytrains.com Edited February 11, 2020 by Junctionmad Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 Quote Yes, that is also one of the goals with this solution. I currently have a prototype board stuff into a Hornby Class 66 that allows you to control the loco that way, and it also works with the track control. Once I have modules that have tested safely for a few weeks, and I have the time to document it up, I'll push the code and the documentation / video for it. There are several Bluetooth and WiFi systems with loco based electronics https://www.wifimodelrailroad.com http://www.wifitrax.com http://bluerailtrains.com http://monocacytrains.com And several more making your own will be expensive and the SMD will mean it will have to machine assembled in practices , not accessible to home builders etc. Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 6 hours ago, Junctionmad said: ultimately putting a Wi-Fi decoder in the loco is .... reinventing DCC because the technology doesn’t deliver any real advantages Not really. Having a fully programmable (actually programmable, not setting fields like DCC does with CVs) decoder on the locomotive opens up a slew of possibilities, aside from stuff DCC is capable of like independent control of lights and the motor. You can also do some pretty slick stuff with sensors and get advanced telemetry from the loco. This is just one application. 6 hours ago, Junctionmad said: 10 bit speed is useless on most model railways, the typical model motor can hardly resolve 128 steps ( a real GM engine has actually only 8 speed notched ! ) This is actually not true. The PWM on the ESP32 supports three modes 7-bit, 10-bit and 15-bit if my memory serves me correctly. We've done extensive testing with dozens of locos from different manufacturers, you can see some very basic results of this in the manufacturer profiles that we added to the track module in 1.0.0. It is early days yet, but basically you will be able to tune both the resolution and frequency, along with the speed-step range within that configuration for optimal control of the loco. This maybe using the resolution for inertia or directly through speed steps. Ultimately though we will be able to use this along with data from the real prototypes, to simulate the running characteristics of the real thing. 6 hours ago, Junctionmad said: wifi brings higher data transfer , for what exactly WiFi brings a lot more that higher data transfer. WiFi is being used to connect the module to the controller, so the API you see with the track module will ultimately be consumed by the controller, which the user will either interact with or configure for automated operation. The controller uses WiFi to exchange state and health information on the module, and gather other information. 6 hours ago, Junctionmad said: dcc is a widespread cheap system , you can get $10 decoders and MERGs DCC system is about £60 Railcom provides two way transmission so what? DCC is definitely *not* cheap. Sure you can get $10 decoders, they also seem to lose their settings and go POP quite often. I think you are missing the point about the reliability of using the data single over the power signal over metal track as being a reliable communications means. You just have to pickup something like a Bachmann Dynamis which is a reasonable OK DCC controller and the latency issues with DCC are pretty apparent? If you say otherwise, you just in denial! 6 hours ago, Junctionmad said: DC users typically stay away from “ tech “ they won’t adopt this system either Again why does this matter? This system is just another option. No harm in having alternatives are there? 6 hours ago, Junctionmad said: Wi-Fi brings issues in exhibitions , including IP handling and channel contention This is completely wrong. You would be a complete nut job to expose your model railway at an exhibition by attaching the modules to public WiFi. The system ultimately uses a controller (should be available in the March release 1.1.0) which has the option to act as a secure WiFi access point, or you can use any off-the-shelf access point. The DHCP server on the controller takes care of IP handling, manages the WiFi network and won't have any issues with channel contention. You guys seriously have WiFi knowledge that is about a decade out of date! 6 hours ago, Junctionmad said: the esp32 is a single source proprietary Wi-Fi controller what happens if it’s unavailable The ESP32 is a widely used IoT platform, it is the successor to the popular ESP8266 platform, which is also still widely available. Short of a massive coronvirus outbreak, which to be fair is quite possible, you should be able to source these for years to come without any issues. This is a bit like asking what if OLED displays become unavailable. We are adding support for other IoT hardware platforms including Particle, and of course we will be adding support for the Arduino with both WiFi and Ethernet support. Most likely going to see support for ESP32, then ESP8266, Particle, Raspberry Pi Zero and then other IoT platforms. 6 hours ago, Junctionmad said: using http is very inefficient and what security have to to prevent unauthorised access This is the dumbest thing I've read all day. You do realize that HTTP based APIs are the foundation for high performance / highly scalable distributed cloud applications and microservices right? Obviously not by your comment. Security is managed through the controller, the controller sets up the private network, so the connections between the controller, the modules and between the modules is all done under encrypted WiFi using things like WPA2. Since the data is being exchanged internally, this is very similar to the data being exchanged on the backend of enterprise cloud computing deployments, where you use HTTPS on the frontend and HTTP on the backend as the backend is usually a private network. Access control is handled by the controller. As mentioned in the original post, the 1.0.0 release is about making the technology available for people to play around with and get familiar with, provide feedback. 6 hours ago, Junctionmad said: today for layout control there are several layout busses schemes including openlcb , Merg CBUS , loconet. Adding another is hardly Innovative All of those buses you mention are CAN based. There is a massive difference between a CAN bus and an advanced REST/Web based API! Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 4 hours ago, Junctionmad said: As a person who has written 802.11 stacks , what you says is largely nonsense for 2.4ghz solutions Obviously its a bit above your head. Go check out Adaptive Radio Management, its been around for over a decade! Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 3 hours ago, Junctionmad said: There are several Bluetooth and WiFi systems with loco based electronics https://www.wifimodelrailroad.com http://www.wifitrax.com http://bluerailtrains.com http://monocacytrains.com And several more making your own will be expensive and the SMD will mean it will have to machine assembled in practices , not accessible to home builders etc. Thats odd since I've got a prototype sitting in a Class 66 that cost under $20 to put together! Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 4 hours ago, Junctionmad said: No links as they are not public , you have to join merg. But there are currently Arduino based distributed dc solutions , pic based and STM32 solutions in merg at present, plus hand held throttles , smartphone servers etc , all that can control DC in various centralized and distributed formats. Critiquing your design is not to be conflated with being afraid of it. If anything you seem overly eager to self justify , ( a form of confirmation bias ) Not available to the public, there is part of the problem right there. Arduino is ok, but IoT platforms like ESP32 are much better controllers. I see why you're aggressively "critiquing" this now, you worried it'll obsolete the efforts of merg. People will choose what they want to use. Ultimately things that are built in hardware get replaced with software defined solutions. Look at networking, it used to be dominated by FPGA/ASICs, now everything is moving towards SDN. I don't need to justify anything. I'll let GitHub do the talking release after release! Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 4 hours ago, Junctionmad said: What you do and how you justify it for yourself is fine , just don’t try and suggest you have a serous competitor to dcc that’s all. Im not afraid of it , why would i , as i have said , it’s not unique , and it doesn’t address current issues on DC layouts nor address the typical DC modeller, that’s all its you , with nonsense 128 versus 1024 speed steps stuff that should be afraid , afraid of speaking nonsense Ironically this makes absolutely no sense at all.. Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 (edited) 6 hours ago, Junctionmad said: This is a bizare statement for a railway modeller to make Not really. Perhaps you should look into what a block actually is.. "Signalling block systems enable the safe and efficient operation of railways by preventing collisions between trains. The basic principle is that a route is broken up into a series of blocks, only one train may occupy a block at a time,[1] and that the blocks are sized to allow a train to stop within them. This ensures that a train always has time to stop before reaching another train on the same line. A block system is referred to as the method of working in the UK, method of operation in the US and safeworking in Australia." Note "only one train may occupy a block at a time". Quote of course you have often two locos or more in a block , calling on being a classic case , or station pilot engine operation , leaving aside banking and multiple engine heading Banking and double/multi-heading for the purposes of blocks are just one train. Station pilot operation is similar to depot and siding operations, which are special cases. Quote secondly if you are using the L298 driver , you need to synchronise the PWM waveforms in adjacent blocks otherwise you’ll short the H bridge of one controller repeatedly as the wheels bridge the gap. This was an issue in Mergs CANDC distributed CANbus DC controller and needed a sync line fed to the controllers. Yeah this is pretty obvious? Wheels will bridge between blocks, its a pretty standard problem. You can synchronize PWM waveforms on the ESP32 using library calls. We also have a couple of neat software "techniques" that prevent problems with wheels bridging the gap. Some require the use of some sensor data, so you'll see these up in GitHub as the sensor modules are finished and made available. Quote The whole project will be a solution looking for a problem, sounds like you Quote (a)unless you fit loco based decoders , you don’t get any benefit over conventional DC , whether or not you deploy 10 bit speed steps. This is not true at all. Even with just the track module, DDC provides: Digital speed control Profiles that enable tuning to match the loco Independent acceleration and deceleration inertia Braking Consistent illumination of lights Simple automation (show me a DC solution where you can script control with a few URLs out of the box?) Quote (B) if you fit loco decoders , you might as well fit DCC decoders and get all the benefits of a developed eco system Or you could fit decoders where you can update the software on the decoder, modify the software on the decoder and add sensors? Quote (c) track side control overs no benefits over conventional DC which can implement the same thing with a few section switches (see (a)). Quote (D) the technical complexity is such DC users will avoid it and DCC users get cab control “out of the box “ Its no more technical complex than DCC? Quote (e) right now there’s few throttle options , like a proper button based throttle (/wired or wireless ) Yes, but you are comparing something thats brand new and under development, with something that is 30 years old? You are also missing the point that the API provides the ability for anyone to build their own throttle, whether that is company or end user. Quote (f) you still have to distribute 12 v track power and switch frogs etc , that’s means bus systems and drivers and frog switchers , still have interbaseboard wiring etc. You only need the 12V and 5V power, everything else is handled by controllers. The track module is just one module, there are many many more moving their way from PoC into general availability. Again you seem to have missed the original post where this is an open source project, so the development is eh.. open? Quote (g) there are no general purpose IO for layout control , multiplexed mimic panels leds etc. This is on the controller? Quote (h) WiFi’s comms issues are very hard for the non technical user to debug and issues like IP resolution , routing etc are not well understood by the average railway modeller These are handled "automagically" by the controller. I just finished loading esp32tools onto the controller image, so the controller can now "program" the esp32 modules via USB. So essentially, you plug an ESP32 into the USB port, select the type of module you want it to be (eg. track etc), and then it loads the software onto it. Quote i wish you well , but it’s intended “ market “ has not been thought through , to run down DCC , whose installed base is literly huge and worldwide in an attempt to justify your project is really pathetic and ridiculous. your attempts to paint DCC communications , given the many 1000 s of layouts using it daily as somehow less then adequate are just rubbish and utter contrived ( like the 128 versus 1024 step non issue and the nonsense comments over AC->DC conversion comparisons ) LOL. Looks like I've hit a nerve! Quote ddc track side control FYI.. this is just one module, its not the entire system Quote (a) technically complex The mistake you are making is that the initial release isn't an end-user targeted solution. The initial release is a "hey check this out, has a lot of potential". Ultimately, the solution will be very simple to install and use. The project has a couple of different goals, one of them is to enable it to be used to teach people how to build systems. Which is why the code is being released in a certain way. For example, 1.0.0 has just L298N support, it has synchronous HTTP support, these are deliberate design decisions to make the thing "safe" for people to experiment with. The 1.1.0 release has a specific roadmap, but there is also cycles set aside for bugs or features or difficulties people have. Obviously its not too complex since we've had just over 30 people sign up for different paid subscription models to get weekly private beta access. The 1.0.1 release that comes out later today in private beta fixes some bugs, adds a lighting module and RFID module. The feedback we've got from a few people is that the controller is an item they want sooner rather than later. So for the remaining pre-1.1.0 releases, we're prioritizing the controller. The controller enables us to default asynchronous HTTP support (it requires an independent library) but we can pre-package that into the controller. So just with the second public release (1.1.0), you should be able to just download and write the image to an SD card, boot up the controller, then automatically program your ESP32 modules. We will probably try to cramp ESP8266 support into 1.1.0 if I have the time. Quote ( b) no advantage in operations over conventional dc This isn't correct (see my response to the question back up the top.. Quote (c) ability to control multiple sections requires lots of track side modules = expensive This depends on the number of blocks you decide to have, which is dependent on your layout. The PSU we recommend will power two track modules, so PSU ($20) + L298N ($2.67) + ESP32 ($6). One L298N will power two block sections. So $20 (PSU) + $5.34 (L298N x 2) + $12 (ESP32 x 2). So you are looking at $37.34 to power four track sections, or if you're not doing blocks, four loops. This is about the same cost as one analogue DC controller. Even if you have a massive layout like we have here at oorail. You are still looking at a fraction of the cost of chipping every loco with DCC. Quote (d) isolating locos in sidings requires conventional isolating switches & wiring , no savings You are making an incorrect assumption here. You are looking at probably $14-$16 in off the shelf hardware modules, and $6 for an ESP32 or possibly less for an ESP8266, to support the siding software module. Quote (e) requires a knowledge of software and electronics hardware Not really. You don't need any software knowledge, this will become very clear once the controller is available. Again you are confusing open source project with finished product. You don't really need to be familiar with electronics hardware, you just need to be able to watch a video and follow instructions. I fully understand this isn't everyones cup of tea, however we've already had multiple inquiries just from the demo video from several companies in the UK that want to build and offer the systems. So obviously its got some peoples attention! Quote (f) needs computer This is temporary, once the controller is released this requirement will go away, as will the need to use the arduino IDE. Again you should re-read the original post! Quote h) not easily user repaired Wow this is pretty funny. You do realize the whole thing is modular right? You break an L298N module, you swap it out. You brick an ESP32, you swap it out. You break the software, you just reflash it. The source code is fully available. Its literately about as open and user repairable as you can get. There is also the issue tracker in github, as you can see from replies on here, we're pretty responsive! Quote Sorry but but if you think this will convince any numbers of DC or DCC modellers to switch , you’re very misguided Again.. this is your opinion and again I don't care who uses it and who doesn't use it. This is about doing something different and giving people different options. There are already several layouts using this system, if you think this system is limited to the track module, you are very misguided. The track module is a very small part of it. As I've said in previous replies, the project will resonate with different people as it hits different milestones. So sit back and enjoy or go back and play with your CAN bus. Thats the nice thing about model railways, you can check out the options and pick out what works best for you! Edited February 11, 2020 by oorail Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 8 hours ago, Robin2 said: I'm trying to be on your side. But don't expect people to start by looking at code. Railway modellers generally aren't interested in code unless they are first convinced that there is a system that might be useful to them - and maybe not even then. Thanks Yeah I understand where you are coming from. This is the reason that the code releases are going hand in hand with demo videos and howto videos on the YouTube channel. I'm not expecting your average modeler to pick this up anytime soon. Its more for people who experiment with similar things to check out and for folks to provide feedback. It will appeal to different modelers at different stages. Its all about providing options. 8 hours ago, Robin2 said: I find this confusing. A DCC decoder is mounted inside a locomotive. Wireless controllers for DCC systems are now commonplace - they send wireless commands to the DCC master control unit. As far as I can tell your module is located on the baseboard and it is a wireless control system for DC track power and if multiple trains are to operate the traditional cab-control track section wiring will be needed. (I am trying to use language that model railway folk will be familiar with). ...R So what I meant was that "electronically" the track module is doing the same type of digital control of the motor that the DCC decoder is doing inside the locomotive. So the same "digital" control is possible, such as inertia, close control etc. The track module is just doing it via the track rather than in the locomotive. The wireless handset <-> DCC master control unit is wireless on those systems, but the DCC master control unit to the decoder is not. Yes, if you want blocks, you will need to divide your track into blocks. However you just need a track module per two blocks and the modules are wireless. So a pair of wires from the track in that block, and 12VDC to the module. Probably less wire than DCC droppers, the only difference would be the need for insulated fish plates between the blocks. We will cover doing blocks in an upcoming release and videos. Link to post Share on other sites More sharing options...
RMweb Gold Joseph_Pestell Posted February 11, 2020 RMweb Gold Share Posted February 11, 2020 I think this project sounds interesting. And I am very much a modeller who does not like to get embroiled in electronics. When I can, I will take a longer look but, as I understand it, it takes us back to controlling the track rather than the locomotive. That may be useful in some circumstances but for most it must be a step backwards, given the old problem of getting good current pick-up from the track. It might be more useful to direct the technical effort at train detection systems so that we can install proper signalling on layouts. On board power (batteries) looks more promising with regard to the trains themselves. A good train detection system based on blocks and signals would be just as applicable to that as to DCC, so more future proof. 1 Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 3 minutes ago, Joseph_Pestell said: I think this project sounds interesting. And I am very much a modeller who does not like to get embroiled in electronics. Thanks. There has been a lot of interest in the project, I don't think it will be too long before a few places are offering pre-built systems for people who don't want to mess with the electronics. 3 minutes ago, Joseph_Pestell said: It might be more useful to direct the technical effort at train detection systems so that we can install proper signalling on layouts. On board power (batteries) looks more promising with regard to the trains themselves. A good train detection system based on blocks and signals would be just as applicable to that as to DCC, so more future proof. This is actually something we've already been working on. The next release will have our RFID module which enables detection and identification. If I have enough time, I'll see if I can get the IR and photo resistor modules cleaned up and API added for them. Link to post Share on other sites More sharing options...
Robin2 Posted February 11, 2020 Share Posted February 11, 2020 9 hours ago, oorail said: First off, I'm really confused why people think this is some kind of business venture, I think everyone is aware that you are not proposing a commercial product. Nevertheless, if you want to attract new people to become users of your product then it needs to be "marketed". It is my own view that you are not sufficiently aware of that and that you are not presenting your product in an effective way for take-up by railway modellers. And I think that is well illustrated by the types of comment you have been receiving. I also have the impression that you have not been absorbing the messages that those people have been presenting. Every comment has been met with a strenuous rebuttal rather than a "I hear what you say, that's very interesting. My system is / is not/ intended to do that / will be adapted to take account of that" It is utterly pointless talking about the technical superiority of one chip or another - that is for a discussion between computer nerds. The only thing that matters to a model railway nerd is "what can I do with it". At this stage most people know what they can (and can't) do with traditional DC track control and what they can do with DCC. Never mind the internal technology - what can people do with your product? ...R 1 Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 (edited) Your knowledge of signalling and absolute block is very limited. There are many cases where two trains can be in a block shunt ahead being one etc warning arrangement permissive block ( goods etc ) it’s much more complicated then u present dc control blocks are not the same as signalling blocks either. Very few model railways have proper signalling blocks. but in order to allow individual dc control they do have far more dc sections and its dc sections that I was referring to. Edited February 11, 2020 by Junctionmad Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 (edited) I’m all in favour of people creating projects. what I don’t like is then creating ridiculous comparisons and running down a clearly successful method simply to self justify their own effort. it’s simply a form of confirmation bias many of us hear have 30 years or more in DC and DCC and can see what is meaningful and what is not. Equally making stupid claims about speed steps and AC -> DC waveforms just heaps nonsense on ridiculous. ( not to mention processor speed comments ) justify it on its own merits thanks, dont be a shrill Edited February 11, 2020 by Junctionmad Link to post Share on other sites More sharing options...
Junctionmad Posted February 11, 2020 Share Posted February 11, 2020 (edited) Quote So what I meant was that "electronically" the track module is doing the same type of digital control of the motor that the DCC decoder is doing inside the locomotive. So the same "digital" control is possible, such as inertia, close control etc. The track module is just doing it via the track rather than in the locomotive. The wireless handset <-> DCC master control unit is wireless on those systems, but the DCC master control unit to the decoder is not. Yes, if you want blocks, you will need to divide your track into blocks. However you just need a track module per two blocks and the modules are wireless. So a pair of wires from the track in that block, and 12VDC to the module. Probably less wire than DCC droppers, the only difference would be the need for insulated fish plates between the blocks. good practice dcc needs no more wires /droppers then good practice DC. The DCC signal has no influence on wiring topologies. hence “ DDC” will not be be better or worse then existing systems equally conventional track side DC can and does offer momentum effects and dcc offers all the advantages of on loco control to that end “ DDC” brings very little new to the party , in track control format it merely duplicated existing DC functionality in an arguably more complex fashion and in its future in-loco mode merely brings what DCC already has. dcc biggest advantage is its standardisation, allowing mix and match. Wi-Fi and Bluetooths biggest issue is the corresponding lack of such standards a useful initiative would be a Wi-Fi to dcc decoder allowing Wi-Fi signalling to be back fitted to dcc locos however this overlooks the fact that while Wi-Fi is technically superior to dcc , it’ doesn’t really bring any added value to a model railway, while introducing incompatibilities and technical complexities for no real gain. Conventional DC remains an option because it’s cheap , easily understood by the non technical and well supported by documentation and learning aids dcc is well out in front in worldwide usage over dc , the poll on rnweb a few years again showed the same here ) it offers a standardised method of cab control , loco sound , and optionally feedback at quite low costs. Fire away , but don’t be blinded as to what you are developing , it’s merely a peculiar form of DC largely to satisfy your own technical interests. it brings very minor features to bear on ordinary model layouts. Edited February 11, 2020 by Junctionmad Link to post Share on other sites More sharing options...
oorail Posted February 11, 2020 Author Share Posted February 11, 2020 1 hour ago, Junctionmad said: shunt ahead being one etc warning arrangement permissive block ( goods etc ) it’s much more complicated then u present Yes but initially you have to keep things simple and build on it. This is how you build a platform that is modular and can be used by various different people for various different applications. 1 hour ago, Junctionmad said: dc control blocks are not the same as signalling blocks either. Very few model railways have proper signalling blocks. but in order to allow individual dc control they do have far more dc sections and its dc sections that I was referring to. Yes you are quite correct. Very few model railways have proper signalling either. Ah but proper signalling blocks is exactly what DDC provides. Perhaps I should have mentioned that our project has a consultant who has decades of experience with railway signaling at British Rail, Network Rail and several outside consulting firms! Give it time, it'll get there 1 Link to post Share on other sites More sharing options...
Recommended Posts