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

There's no doubt that I have crossed some form of line. None what so ever... I give you, "Yet another persons home grown DCC generator" (thingie): What is it? It's effectively an alternative to the DCC++ Arduino and Motor shield solution for driving your DCC trains. It is all fresh code which has it's own selection of pro's and con's, but I am chuffed with the LCD giving a second by second summary of what is going on (as far as the Arduino can tell). The "Lnnnn" gives the value returned by the Motor Shield for the power/load passing through the H-Brigde, "Pn" says which track is on (0-none,1=Main, 2=Programming). "Fnn" tells you how many output bit buffers are free. "Tnnnn" indicates how many DCC packets are being transmitting per second. "Uxxxx" is the uptime of the Arduino since last restart. The right hand side gives a brief summary of what the currently active bit buffers are doing. In this case an engine with the DCC ID 473 is going forwards at speed 48. Obviously the Volt & Amp meter are self explanatory. All good fun, so far. Plenty of testing to do .. good excuse to play trains me thinks [Edit] A little film of it working here: https://photos.app.goo.gl/9Cz8GeaqVTo8fu1E7 Jeff

David, You're absolutely right. All the pictures of work shops I can see (on google) have lathes and other machines with the belts heading straight up but the limited number of pillar drills all had an intermediate shaft on the ground behind the pillar. So far it would seem that pillar drills are the only machine I've noticed like this, but I would guess that any machine driven "from the top", like the drill, would have used a similar mechanism. Live and learn, hopefully. Jeff.

A thought just crossed my mind. I would have assumed that the pillar drill in the photo has been adapted to be operated by the floor mounted electric motor (right where all the swarf would be heading). Would it not have originally been driven from an overhead power shaft (can't think of the proper name at the moment). Should I have kept the thought to myself? One way or another, that cannot take anything away from the results though; Just awesome. Jeff/

After a wee comment from one of the local club members, I've been "refining" the servo motor code for the Arduino, thus: Bouncing servo motor Refining isn't perhaps accurate, more of a complete over haul.

So, given that I've been playing with servos it seems that producing something simple to drive them would be a good idea. If you are of a mind, and fancy a modest challenge, then over HERE (in Github) is the source for the Arduino firmware. This, after relatively limited testing, should work on a Nano, Uno or Mega2560 and control as many servos and the board has PWM outputs (with some reasonable exceptions). Here (and arguably meaninglessly) is a picture of an Uno operating a single servo: What this *has* shown (and provided justification for writing the software), is that I need to adjust the chassis design: The Servo "pokes through" the mount a little too far (1 - 2mm) and so things catch on each other. Back to the CAD again, and another 3D print. I should add that while driving a single servo directly off an Arduino isn't a problem, driving more might be. If you were to employ this then you would need to provide 5 volts for the Arduino (using the barrel jack or Vin and GND pins), and this power supply should be directly supplying the Servos with only the control wire linking the servo to the Arduino. Jeff/

Just a quick one. "Can I arrange to put the switches on the actuator" was, I think, the last question. Yes: and So there are "T Slots" in the chassis into which rather small M1.6 bolts fit and M2.0 might fit (I haven't any to try). I would hardly say that it is simple, but it is achievable. Attached are the STL files for the chassis, the rod and two wheels (one with 10mm throw and the other with 4mm throw). Please feel free to play though I would warn that I am new to this CAD for 3D printing activity, so there are no doubt some features which are "sub-optimal" I've had an inspiration regarding making a generic configurable stand-a-lone Arduino driver sketch which could make going forward with this type of solution less involved and result in a more "traditional" operation mode. Hmmmm... Jeff PointActuatorRod.stl PointActuatorSwitchFrame.stl ServoCamWheel4mm.stl ServoCamWheel10mm.stl

Hi Stu, I have looked at the MERG servo mounts, and thought they were a bit fiddly, especially the "pin" moving between the goal posts. The wheel I've modelled screws in-place of the arm normally found on a servo so it feels more rigid and secure. It's also put the loads closer to the motor so the twisting forces are reduced. To be honest I couldn't quite see how I was going to fit the pin to the arm reliably. On the subject of the built-in point springs, I would remove them. They're essential for the electro-magnet point motors, otherwise the blades would not remain in one position or the other. For a more driven solution like servo motors or stall motor based systems (e.g. tortoise point motors) then the spring is working against you IMHO. I'd also electrically tie the point blades to their accompanying rail and let the mirco-switch power up the frog. Of course this last statement is probably only really pertinent to electro frog points. Jeff

Should I have said "Hi" in here? I'll keep in brief: Hi. I'm Jeff and I have a problem ... hang on, that's the other group Seriously now. The wife and I have been living in the Uckfield area for a few years now, and a couple of years ago thought "shall we try to build a model railway?" and that's when the trouble started. Since then I've been trying to combine every possible interest I have with that objective so, naturally, progress has been unpredictable. Her interest? Anything other than that which I am interested in. My interest? Southern post grouping, though I keep looking back to pre-grouping SECR and LBSCR and going "hmmmm". Already know a few of the local guys on here as a result of joining the local club. Jeff

Estimated cost per switch is a little tricky. The servos are really cheap at about £1.15 each off ebay, and a really cheap arduino to run it is about £3.50 but can control a number of servos. 3D printing is cheap but the printer isn't, unless you've a friend with one. How you make it all hang together and operate is really the question, to which there are many approaches, mine being just one (and technically far from the simplest). Could the switches be incorporated into the servo unit? Yes. The mount for the servo has been deliberately centrally located meaning the switches could be positioned either side as part of the same component. Then, yes, it could be used to drive a simple rod and pin to the point.

Well, I guess I ought to have known that I would end up doing this, so, yes, wheel re-invention was the order of the day. Putting that to one side I think I have come up with something a little different, perhaps more flexible while being simpler to print and deploy (though that last point really will have to wait until I have actually installed one and got it working). I have chosen to divide the whole "model railway point motor" thing into two distinct parts: The component which interfaces to the point itself, and the component which provides the driving force to actually move the point. So, following the picture painting a thousand words ethos: The point interface: and the Point Actuator: I'll quickly point out that I realise that the the interface unit only catches the "bottom" switches, I have to extend the 3D model and raise the post up another 4mm. How would they work (I can't say "how do they work", yet )? Hopefully it's obvious they screw up under the base board, where a suitable metal pin inserted into the post of the interface unit would engage with the point itself. The interface unit can be aligned and positioned such that it is centred lined up with the tie bar of the point. This interface unit (in deed both units) have a maximum 10mm swing which should be way more than required for normal usage. The actuator unit clips onto either side of the interface unit and (with the servo motor in it's "zero" position, as per above photo) moved until the point is accordingly set. The 3D printed "springs" allow for both some freedom of alignment and also a little extension or compression hopefully making the whole arrangement easier to install and set up. So how do you adjust the "throw"? Two ways: Firstly you could simply drive the servo through a limited arc rather than a full 180 degrees and 10mm of movement. Or, secondly, change the offset of the hub in the actuator wheel for one where the centre of rotation is closer to the centre of the wheel. At the moment I am thinking that a combination of the two is the best approach. What I like about this design are the following: The servo is not actually attached to the component interfacing with the point, in the event that something needs doing to he servo there would be no need to fiddle with the point and risk upsetting something that can be tricky get right (not to mention a whole bunch of wires) There is no direct mechanical linkage between the servo and the point roding. To remove the servo simply unscrew it and drop it off its actuator rod. SImples. Of course this is all, currently, hypothetical. I think I shall have to make up a small "plank" test bed to see just how this is actually going to work. The best laid plans and all that stuff. The switches on the actuator will perform the normally anticipated "frog polarity" thing. "But wait", you say, "that only needs the one switch". Yes is the reply, however, the software I have been writing can accept confirmation signals (in the electrical sense) that the point movement has completed, and this is the purpose of the other two switches: they will pull down Arduino pins to earth allowing the software to know when a point is set (and which way) and also when it is "in motion" between states. Anyway, some more images: For info: CAD done using FreeCAD 0.18.4 exporting to STL and into Ultimaker Cura 4.4.1 under Linux Mint 20 Cinnamon. Been trying to get these all "lined up" for a while now. Some of my issues were software related, but there's been a fair amount of mental re-alignment required as well Jeff.