jeff_p

Flushed with a feeling of competence and an irrepressible desire to risk failure in the face of a public audience, I chose try my hand at another kit. The Ratio foot bridge, RO548. I knew the Jujitsu kit bashing skill were unnecessary, but it looked like it would be a little fiddly. What the heck, we were going away for a week so I packed the kit, some tools and an extra dollop of wishful thinking. Shame I forgot the instructions 🙄 Anyway, who needs instructions? What I can say is that it took way longer without them, but the kit is well formed and goes together fairly logically. Here's the result: Obviously needs painting, like a number of other kids. I'll get round to a serious painting session soon. Here's a wider shot including the cattle dock: Shame I left the super glue in shot. Jeff

I knew that I'd have to pick the right breed with care, now I know which. Thank you. My current thought was to go down a single breeding Bull route which would make the dock look less tiny and give a good reason for a cattle wagon to move in and out. Similarly a suitable horse does the same for the horse box. Jeff

.. in Lyghtondown. The good yard didn't have any form of cattle or livestock facility. Given that the size of the yard in real terms is, well, really, really tiny, this was never going to be a trivial decision or subsequent action. I had a choice of either putting a more normal dock in on the same siding as the coal staithes (?) where it could be basically rectangular, or "jamming" it between the good shed siding and the main good siding but necessitating some significant black belt kit bashing (for me at least). I chose the aesthetic option and started cutting up the Ratio cattle dock into new shapes with the aim of making a triangular structure. Not quite finished here, but to me it looks to be fitting in well without looking out of place. I shall rationalise the relatively small size of the dock by simply saying that the local farming community didn't need anything larger. Who's to say otherwise :) Jeff

Thank you .. I took to using a paint brush (a "flat" one about 5 or 6mm wide) to push stuff about initially, then (having sharpened the end of the brush into a reasonably sharp point) nudged individual bits of ballast where I wanted them. Only when absolutely happy did I glue it in place with Woodland Scenics "Scenic Cement" applied with one of those small glue bottles with the thin metal tube (the ones that look suspiciously like the end of a propelling pencil). Jeff.

It would seem that I "fell off" .. well .. lots of stuff, not least keeping this blog up to date, so perhaps it's time for a brief update. Lyghtondown continues forward but it's hard for me to tell where we had got to in the blog, all the old photos have been 'archived' (euphemism for deleted). I know I was playing out with electronics (I still am) and that some success had been witnessed regarding actually getting things moving. Anyway, we've been a little more focused and things have moved on and improved so here are a few images for the layout as it currently is: The ballasting was the work of only three or four days while the management went on a "building" building marathon filling up the empty spaces with .. stuff. There's still much to actually decide on and build however, we're currently negotiating the "greenification" of the landscape and have quite a number of trees to create and plant along with all the other paraphernalia that you can find in the oddest places. Regards, Jeff.

What do I think? Awesome.

I think it all starts with choosing a suitable technology (DCC system) which supports the functions you require. The approach to the wiring of the track, accessories etc will naturally fall out of their documentation and preferred practice guidelines. Having said that the principle of a power district is that each district is electrically isolated from it neighbours and (effectively) has just two wires feeding each district. This is something I've been playing with myself using a system initially based on the DCC++ Arduino hardware and firmware, but has since gone fully bespoke using both hardware and software I've been developing. All good fun

Seven districts ... that's going to be fun

Lovely job on the crane .. I'll have to re-visit mine now

My wife has just pointed out that I should have mentioned that she soldered all the parts to the boards. So the neat soldering you can see is her work. It's probably too late to avoid consequences now

Just a brief one as I'm a bit chuffed with some initial success with my DCC "box". I've been working on extending its abilities past the normal range of a DCC generator/controller as I outlined in the last entry, and now, finally, the various elements have come together. I'll aim to write up something more informative soon (I haven't started testing it yet), but my foray into PCB design and manufacture has worked out better than I anticipated, and resulted in the following "solution" for the controlling electronics: The Arduino UNO has been replaced with a socketed Nano, and the single motor shield simplified into a pluggable module focused on just DCC generation. Still two outputs per board, so the whole unit can run six DCC outputs. Six was chosen as this is the effective limit of the Nano in terms of pins available. I've crammed this, a power supply and one or two other bits and bobs back into the original case, and so I now have this: As I said I haven't really started testing anything yet, but the Nano is happy and now displaying 6 districts (A through F). All the panel components have had to condense sideways as the PSU is filling the extreme right of the box. The main upgrade here are the three sockets, each presenting two DCC Districts with Ground and +15V One advance on the district front (apart from each district being independently powered) is that in the event that there is a power related "Opps" the firmware will try reversing the polarity of a district briefly before actually turning it off. The aim here is that things like reversing loops/triangles or turntables which normally need some explicit mechanism for handling the potential for shorting can simply be made their own district. Well, that's the design goal. There is a whole pile of careful testing before I subject an engine to trial runs, not mentioning actually rigging up a test environment where the practical testing can take place. But this is something of a landmark that I wanted to share. Tomorrow will see our oscilloscope (just a hobbyist one, nothing fancy) get some use as we work our way through the various use and error cases to see what happens. I've no doubt that there are issues, how could there not be, the firmware is over 6,500 lines of C/C++

Yes, I know. I'm waiting for the Arduino version of the rp2040.

... and had already confirmed a modest case of "stepping over a line", there's been some additional work going on. I give you a DCC Generator that supports multiple Power DCC Districts. OK. Stunned silence from most of the audience, and I would imagine for 95% of those people using DCC out there this means little to nothing and even if it did has little to no practical use. Question: What is a DCC Power District? Answer: As I understand it it's a mechanism for subdividing up a layout is separate areas such that if there is a "power event" within an area (e.g. short circuit or overload), then only that area is impacted as the controller only shuts down the power supply to that area. The rest of the layout continues unaffected. So .. what have I done? Behind the scenes at a software level quite a lot. Visually the display on the front of the box has been updated, thus: The central area now reflects the fact that I've taken to lettering each of the possible outputs from the Motor Shield alphabetically, and display each with a small "power bar" (in this case a really short one of just a '=' symbol). This displays all the driver devices inside the box (only two in the case of a standard Motor Shield) regardless of their association with the operations track or the programming track. In the event that there is an event then the controller removes the power from that driver and fills that bar display with '*'s (which are meant to flash, but haven't yet). After a short period of time (5 seconds at the moment, probably too short) it tries to restart the output. I realise that with only two possible outputs this seems like a waste of effort, after all you need one output for the main track and one for the programming track. However, the programming track is now optional in the firmware, so it is possible to have two power districts driving the main track. But .. I have some bits and pieces on the way, and it should be possible to make a shield with four drivers which would still work on an Arduino Uno, and if you're up for it, six or eight using an Arduino Mega. Anyway, that's a week or two away. Here we are running a couple of trains (Nos 10 and 51, as above ), tail chasing style, round the layout using the controller with the new firmware: https://photos.app.goo.gl/h5etMcWpHnQQ9fT59 Jeff.

Awesome.

It's an open source (and hardware) alternative to buying a DCC Controller system from the likes of Hornby or Gaugemaster (other manufacturers are available). To be fair this box is only half of the solution. If you use this (here: https://github.com/GreyLimit/DCCGenerator ) in limited DCC++ emulation (or indeed just build yourself a DCC++ solution, see here: https://github.com/DccPlusPlus ) and use the JMRI software on a PC then you don't need to buy a commercial solution to operate DCC models and accessories on you layout. I've also been writing an alternative to JMRI (which I call "The Fat Controller" as it's a substantial chunk of code as well as the other reason) as well as building my own handsets for the actual operation of trains, so I have a completely "open" and relatively cheap DCC solution to operate my model trains (well, train set ). I started this because my wife and I had a full set of Gaugemaster kit but found it just plain fiddly to operate and spent more time trying to work out how to play trains rather than actually playing with the trains. My thought was "there has to be something easier and simpler that doesn't place so many hurdles between us and doing what we want". Replacing all the Gaugemaster equipment with an alternative system wasn't an option (money still doesn't grow on trees our way ) but by chance a member at our local club (Bluelightning in these parts) said "haven't you heard about DCC++ running on an Arduino?". From there it's all grown out of all proportion. I have Arduinos (cheap Chinese knock offs mostly) everywhere as I play around with what is possible with them (having had a long IT and programming career behind me) and have been slowly pushing the boundaries of what I can achieve with them. I have to say that this DCC Generator box has given me the most pleasure so far. Writing the code to generate the actual "on track" DCC signal accurately in both form and timing has been a challenge, especially on a piece of hardware running at just 16 MHz and with just 2048 BYTES of variable space. Putting that into perspective: A modern PC is probably getting on for 200 times faster and has 2 million times more writeable memory in it than the basic Arduino Uno (yes; 2,000,000 times, that's not a mistake). There are still ideas brewing away on the back burner, but I really need to try and spend a little time consolidating some ideas and bringing them together. Did that help? Jeff