oorail

Here is the quick and easy fix for the capacitor, downside is the capacitor is still visible on the ends, but you can't really see it when you have the coaches coupled together. Since I have to pull two full sets apart, I think I'm going to use the time between now and December when the sets are supposed to come in to detail the interiors better and 3D print some guides to route the wiring under the floor of the coach.

@backofanenvelopeBlender is fairly easy to use once you get going. I just posted up a thread with my Blender tutorial that shows the entire workflow that I use with filament printers such as the Ender 3. You can find it here :

This tutorial shows the workflow I use to go from initial concept through the CAD process, slicing, printing and testing on the layout. All of the software used in the video is available for free. It is the workflow that I use for FDM (filament) printers like the Ender 3.

For those interested in the model, I uploaded another video this morning that has: Opening the tender and a look inside Rattling noise was the glazing that fell inside the tender Follow up on the loose screw that fell out the speaker hole An issue with the contact plate and how I fixed it New footage without music (some people asked to hear the motor) Raw test footage showing the issue with the contact plate (before it was fixed) The GT3 front bogie developed a squeak, loosening the front bogie screw a half turn fixed it I wanted to point out that I'm just a customer, thought the GT3 was worth risking the money, and I'm very happy that I took that risk. Yes I got burnt by DJ Models over the APT, out about 260 quid. I can tell you now that having put the GT3 through its paces, these guys are more like Accurascale and Rapido than DJ Models, from the quality of the model to the professionalism of the company towards their customers. Looking forward to the Fell, Iron Ore Wagons and the upcoming Leader! So far its been a fantastic model, one of the best models I've picked up in the past decade, so well done to @krmodels Here is the new video:

We've been experimenting with this for just over two years, so I thought you might be interested in what we've learnt, you can see the end result at: https://trackside3d.co.uk/ We have just over 20 FDM printers and a couple of MSLA printers. The most important thing is a 100% reproducible print, with the assumption the customer's printer is leveled and calibrated correctly. The baseline we went with was a working XYZ calibration cube and the calibration cat. If your printer will print those, all of our models should print on your printer. The second most important thing is to design the model for the 3D printer technology (Eg. FDM or MSLA). When you do this, you end up with some really good results, like this 40' container: https://trackside3d.co.uk/products/t3d-030-000-40-container The third thing we've found that was really important was the licensing and pricing. We're on the third iteration of our license, which is based on software licensing. When someone buys one of the 3D models, they aren't buying the model but buying a license to use the model. Doing it this way, we provide free updates to the model and the person can re-download the model if they need to. We allow them to make unlimited prints for their own personal use. This was based off the approach Scalescenes takes, and its proven very effective. We found that people printing models would often get confused or have problems because they were tweaking too many settings at once. So what we did was setup baseline profiles (small, medium and large objects), and slight modifications for materials. You can see this in the specifications and print settings tabs on the website. We're currently working on a secure solution to allow users to view 3D objects (like Thingiverse) and working on videos / layout photos of the current products. Right now I've got probably 100 additional designs that I need to clean up, export, package and create product entries for, in addition to updating whats on the site. Its a lot of effort, but should be good when its done. We've spent quite a bit of time perfecting 3D printable (with FDM) locos and rolling stock, and those are next. However, at this point, its going to be a matter of promoting 3D printing more via YouTube, and working on several new products each week. The reason we have 20+ FDM printers is basically for testing and design, we don't mass-produce end products, only ship the designs. We have a few printers dedicated to special materials, such as transparent PETG and PolySmooth, textured PLA, Wood-Hybrid PLA, Iron composite PLA, couple of different brands of PETG, HTPLA (high temp PLA), various different PLA brands and some special materials like TPU etc. The brands / models of printers we have are: JG Aurora z603s JG Aurora A5 / A5S JG Auora A1 / A1X Creality Ender 3 Creality Ender 3 Pro Creality Ender 5 Creality CR-10 S5 ANET A8 M3Ds AnyCubic Photons The bulk of our print-farm is Ender 5, Ender 3, CR-10s and JG Aurora A5. We do all the 3D modeling work in Blender, use Cura to slice and custom software to manage the print queues. At full capacity, we can churn out around 20-40 projects a week, depending on whats going on. We try to keep the printers going 24x7, as it leads to less problems! That sort of leads into my last point. We've found that people tend to want a steady stream of designs. We tested this out over the past 2+ years by offering a monthly subscription service that costs about $20/month, but you get a steady stream of designs, while we've limited the release of designs on the main ecommerce store. The subscription service is by far, the most popular thing that we offer. An interesting thing too about the models, we design everything for OO scale, mainly because thats what I model, and the whole project is more about getting people interested in 3D printing, however we do get a lot of people modeling O gauge and sometimes HO and N, who purchase models and then use the slicer to scale up/down. Hope that helps...

a) MFRC522 - you get 5 for under $13. b) You can buy RFID stickers that will fit on the underside of a loco, right down to sub-4mm diameter. Work out to be less than 20p each. This is rubbish, RFID signals cannot work through copper tape (the kind you use for RFID-proofing things), sometimes called faraday tape (google search TitanRF), its simple to constrain the reader to the track with it! Reliable read rates are easy enough to achieve, you need to make sure the RC522 maintains maximum gain, here is some sample code, just throw it in loop() and execute it every 30-40 seconds or so, you can increase or decrease the gap depending on how your RFID system performs. It'll vary based on your environment and equipment being used. Serial.print("Health Check... "); Serial.print(mfrc522.PCD_GetAntennaGain()); Serial.println(""); if ((mfrc522.PCD_GetAntennaGain()) < mfrc522.RxGain_max) { mfrc522.PCD_SetAntennaGain(mfrc522.RxGain_max); Serial.print("Reset gain... "); Serial.print(mfrc522.PCD_GetAntennaGain()); Serial.println(""); } To reliable read at high speed rates, you need to optimize the way you write and store data on the RFID stickers. The test loco that I use for the RFID system is a Hornby GWR HST (the expensive one not the railroad model), it has a rectangular RFID tag on the base of the dummy power car, each of the coaches (its configured in GWR's 'castle' formation) and the powered power car has a special RFID tag for application on metal (costs about 50p). At full speed, I can read all the RFID tags. The trick is to store the data you need in the first usable sector and one of the last sectors, I typically use the first sector and sector 14. You most likely don't need all 1K for pulling identification information, you probably only new a block or two. If you duplicate the same data on the first and a latter sector, then program the microcontroller to pull just those sectors, you can then verify the data is correct by comparing the two. If you don't want to write your own code, my code will be in the 1.1.0 release of the oorail-system, which will be released on Tuesday March 3rd 2020. You can find it at https://github.com/oorail/oorail-system just check back on the 3rd. It will be in the modules/ directory. Oddly enough that digital dc system you were ripping on for not offering any other functionality actually does this! :-D And now there is an open source project that provides this for him. What was that about looking for a problem to solve?

and there goes your credibility... Did you really just say that Wi-Fi has a lack of standards? Have you ever heard of the IEEE? Maybe 802.11? Here this may help you out: https://en.wikipedia.org/wiki/IEEE_802.11 WiFi not only has dozens of standards, its also regulated. btw. You can also use Wi-Fi and Bluetooth at the same time.

You are definitely entitled to your opinion. I'm going to let the next couple of code releases speak for themselves.

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. 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

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. 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.

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. 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.

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". 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. 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. sounds like you 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?) Or you could fit decoders where you can update the software on the decoder, modify the software on the decoder and add sensors? (see (a)). Its no more technical complex than DCC? 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. 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? This is on the controller? 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. LOL. Looks like I've hit a nerve! FYI.. this is just one module, its not the entire system 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. This isn't correct (see my response to the question back up the top.. 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. 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. 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! 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! 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! 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!

Ironically this makes absolutely no sense at all..

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!

Thats odd since I've got a prototype sitting in a Class 66 that cost under $20 to put together!