NinOz

How about UV fluorescing "invisible" ink as used to inconspiculously mark personal property. Write on loco and illuminate with UV pen light.

1. The aim of OP was to describe a concept of using a Raspberry Pi to interface to a servo controller board to allow control of up to 16 servos acting as point motors. Just one of the many options to switch points. 2. I don't remember which specific points have been used with servos but given the number in use I assume the quoted point has likely been used. I doubt the type of point will make much difference. 3. Most people just rip the centreing spring out and rely on the servo gear train holding the point blades in place, takes a bit of force to move even an inactive servo output. Works OK. One can leave the spring in and just use a servo which has sufficient force to overcome resistance (my preferred option in N). 4. Routes would be taken care of in the micro processor via programming. Can be quite sophisticated. 5. Stalled servos are not a problem. Movement limits can be set and stored for each servo, actuating rod is usually spring steel so has a bit of give, servos are generally put to sleep at the end of movement. 6. Routes can be set up as you describe, the prods (or buttons) just tell micro which route is required, micro then tells servo controller which servos to move, the direction to move each servo and the sequence and timing of servo moves. 7. Interfacing is dependent on the installation and use. The simplest is just a small circuit to drive the servo (a dpdt relay, a 555 timer, two trim pots, few resistors and capacitors). Cheaper is to use a cheap small micro to drive a servo directly. Both of these could act and be setup rather like the solenoid setup as described. Can get fancy and go for a micro driving a couple of servos or, as in this thread, driving a servo controller board. My DIY has a micro(s) in the control panel which detects which route, lights or points are to be set, broadcasts such requests on Loconet, micros scattered about the layout monitor Loconet and react to their specific switch requests and switch their points or any other action required.

The code to control the board from any arduino is fairly simple, IDE and library is available as well as examples (sort of C++). Mine is a little more complicated as it is DCC controlled and chats on Loconet. At runtime stores individual servo addresses, closed and thrown settings, last known location, etc. Programming the arduino is simple, single cable from usb port to arduino (can buy arduino with suitable cable). The only difficulty is remembering to ensure the correct USB port is selected in the IDE config.

How about some pogo pins instead of the PB strips. Example: https://www.aliexpress.com/item/10pcs-Spring-loaded-pogo-pin-connector-3-Pin-Pitch-2-54mm-Surface-Mount-PCB-SMT-brass/32722259285.html CFJ

Can buy an arduino pro-mini and the 16 servo controller board for about 3 quid delivered. One arduino can control "N" servo controllers via I2C. Works ok. If you are into DCC then the arduino can be used as a decoder. Examples: https://www.aliexpre...iceBeautifyAB=0 https://www.aliexpre...iceBeautifyAB=0 CFJ

This used to be called "pulse injection" to differentiate from PWM.

"the southern black C class sells out before the other versions" Do manufacturers make equal numbers of each variant (beyond minimum livery run requirements) or adjust numbers of each to their best guess as to possible sales? CFJ

https://static.rcgroups.net/forums/attachments/6/9/4/0/6/a10475151-176-324932.jpg

I would try connecting the track and frog wires to inputs of an AC optocoupler (or two normal ones). If the same potential on the inputs then no output from the optocoupler if different potential then there will be an output. The output from the optocoupler could drive a relay, power transistor or provide a digital signal. Would require at least a volt or two DC to get it operating but if you have locos moving about will be no problem. From memory the H11AA1 (or equivalent) would be suitable. Regards, CFJ

Some feedback. Problem was two faulty servos. Replaced with new ones and all ok. Must have grabbed the two from my used RC bits and pieces box.

They have one? Will have to check mine and set. Thanks. CFJ

Anyone know how to stop servos from jumping about when they are awakened from sleep mode? CFJ

Geoff, When you release the motor it is no longer "locked" in place. If it is moved accidentally and your code relies on the last known position then won't work too well. For my controller, it releases after several minutes of inactivity but seeks a home position on reactivation. CFJ

Only problem - despite Hattons providing a list, I still cant work out which CV to dim the lights! Help please anyone? The common opinions seem to suggest that these are rebadged DCC Concepts decoders. Looking up the Zen decoder manuals on DCC Concepts site may help but the ones I saw are very limited. They do claim a CV advanced manual but I couldn't find it on their site. If you have access to JMRI, DecoderPro has a section on Zen decoders which provides some guidance on which CVs do what and easy experimenting. It would appear that CV64 with a value range of 1 to 30 controls the constant dimming light level. CV49 bits 0-3 control Front light effects with one option being "Constant Dimming", bits 4 & 5 controlling when the effect is active. CV50 bits 0-3 control Rear light effects with one option being "Constant Dimming" bits 4 & 5 controlling when the effect is active. CV49 and CV50 are both annotated with a provision that the exact CV values are not documented and thus need to be ratified. Best guess would be Bits 0-3 set to 1111 and bits 4-5 set to 11 (Decimal 63) would provide constant dimming in both travel directions. CFJ

Well I wouldn't say no problem for me. Lead free has a different "feel" to it in the way it melts and flows which made my attempts to try it a bit unsatisfactory; particularly with fine decoder wires. But as you say "experience". I am sure with a bit of perseverance I could get the feel and wonder why I was having so much concern. I think many people just quit in frustration in the early stages of adapting (like me). Especially if one already has several spools of the lead/tin alloy to hand. CFJ

Setup: Digitrax DCS100, JMRI. Behaviour: Can read CVs ok in service mode. Can write CVs ok in operations mode. Can write CVs ok in service mode but reports no response from loco. (no other decoder has the same behaviour) Works fine running loco. Anyone experienced similar behaviour? CFJ

Good call. At least there wouldn't be any concerns of any sand paper grit or glass fibres getting into the mechanism, which would be nagging in the back of my mind. CFJ Now we just need someone to preach about the "collection of dirt in scratches" myth or hardboard (masonite) is not abrasive. Just a thought: I had a problem with a couple of old Poole steamers where the draw bar was lifting the rear loco drivers a tad. Possible on the Castle? There was also the problem with their tenders fitted with pickups where the wheels wouldn't rotate easily because of the ill fitting tender pickups and the loco just dragged the tender around.

Thanks for that. I have one incline on my layout so hmmm. Do you know how many of those coaches it will pull up that gradient? I assume it can haul itself up ok. Regards, CFJ

I have started work on constructing arduino based modules for control of my DCC layout mainly with loconet input. I started out to make another LOCOIO board but thought making a board for everything was a bit of an over-kill so decided to split the board into small dedicated units with circuit and much of the code in common. In this case I am using ultra cheap pro minis, a Loconet and DCC interface, a simple plug-on programming board (button and 10 position BCD encoder so I don't have to build them on each module). Modules are built on PCB prototyping boards. Sketches based on published DCC libraries. The aim is to simply grab a module and up-load the appropriate sketch to give required functionality. So far I have a reasonable module circuit layout and have working sketches for; - a button board to throw switches, each button (8 available) is assigned a single switch address. Buttons can be toggle or momentary. Addresses can be programmed. - an input sketch to report to loconet up to 8 inputs. Almost finished a sketch to take loconet switch requests and control slow motion switch motors (Tortoise); input from the track type module is being created. Still need also to adopt a standard design for powering the tortoises. Each module can control 8 switches as well as 8 routes of up to 8 switch addresses in each route, programmed via switch requests. Next in to-do queue is a LED sketch to take loconet traffic and control LEDs on a panel and then a small servo control sketch. Nothing really innovative, just using bits of other peoples' concepts and work, cobbled together. All good fun though. CFJ

Most likely. Both will be trying to use interrupts to monitor inputs so quite possible that your serial info is being lost. I doubt that the DCC library was written with consideration of any other concurrent coms usage. Serial inputs seem to be quite problematic for arduinos, lots of correspondence on the net but little resolutions. One solution to a similar problem I remember is a chap used two arduinos connected by I2C, one to handle the serial input, buffer and pass to the other. If you only wanted to send a TON and TOFF to the DCC decoder then could use a second arduino (cheap pro mini type) for serial input and use 3 input/output pins on each arduino. Should only take a few lines of code on each sketch.

What does the original BlueTooth (BT) code look like? Does your BT need specific baud such as 115200 and not 9600? Couple of unrelated questions: 1. Does this code return "8": (sizeof(gAddresses)/sizeof(gAddresses[0])), seems like it should equate to ( 8 * IntBytes / IntBytes ) 2. What does this code do (beside resetting addr to 0 after 8 cycles): if( ++addr >= (int)(sizeof(gAddresses)/sizeof(gAddresses[0])) ) { addr = 0; } Can't find any other reference to addr.

Is this movement still a concern?

For general info, some learning references: Online: http://www.learncpp.com/ http://www.uow.edu.au/~nabg/ABC/ABC.html Free e-books for arduino stuff: https://it-ebooks.info/tag/arduino/ Some examples from the site: 1. Beginning C for Arduino, 2nd Edition http://it-ebooks.info/book/5816/ 2. Arduino Cookbook http://it-ebooks.info/book/538/ 3. Getting Started with Arduino, 2nd Edition http://it-ebooks.info/book/1338/ Apologies if posted before or old news. Regards, CFJ

Sorry to muck you about a bit but I checked the MynaBay libs and they have been fixed since my original download a while back. "prog_char" references have been changed to "char PROGMEM" So just download and install the current DCC_Decoder library and all should be good with newer IDEs (my 1.6.5 compiles ok). From here: https://github.com/MynaBay/DCC_Decoder

Stew, I can send you a copy of patched DCC_Decoder files to remove the compile error if you are interested.