NinOz

Not used in the non-DCC test sketch in post 17 as it is the DCC RX pin. It is defined in post 48 during setup() via the decoder setup call; DCC.SetupDecoder( 0x00, 0x00, kDCC_INTERRUPT ); kDCC_INTERRUPT is defined as pin 2 in the DCC library.

People mostly focus on the mobile nasties. What about the plants! We have lots of indiginous poisonous ones plus a whole swag of imported. A Gympie Gympie can kill on contact. Also add ticks (cattle, scrub and bush varieties) and chiggers to the list of unpleasant encounters (sometimes deadly). CFJ

Just got a note from Adafruit. Reproduced the reported odd behaviour, instituted my fix to solve and submitted an update to Github. Don't know when it will be available though. Regards, CFJ

These functions must be in the AccelStepper library (which I am not using) as I can't find them in the motorshield library. I have submitted an "issue" note so it is in Ardafruit's hands. My code seems to work ok with the routine deleted so it is forward to writing the last couple of functions and then trying to stop the lurch on stepper reattachment. Something to keep the old brain cells active. Regards, CFJ

I didn't have any problems either just shuffling back and forth between fixed points (errors would mostly cancel) until I wrote some code to "teach" the unit where a track was by stepping from the home (zero) position to the track location and using microstepping to smooth out movement. Then all went pear shaped. I spent a couple of hours tracing the library code to find where the problem was. Blow away a chunk of code and all works ok. The "problem" is in a bit of code that does microstepping so not executed if you use step, doublestep or interleaved. Also with a 50:1 gearbox you wouldn't notice an error of two steps. This bit: if (style == MICROSTEP) { while ((ret != 0) && (ret != MICROSTEPS)) { ret = onestep(dir, style); delay(uspers/1000); // in ms steppingcounter += (uspers % 1000); if (steppingcounter >= 1000) { delay(1); steppingcounter -= 1000; } } } More specifically the effect of this statement: while ((ret != 0) && (ret != MICROSTEPS)) I have written a bug report and will submit to github this week. Now I just need to figure out how to stop the table from occasionally lurching when woken from the released state. Well at least I now have a better idea on how the library code works. Not sure what you mean by "go to" or "target", the library code only has a step function. CFJ

Currently working on my turntable code. I have a problem in the Ardafruit motor library code for V2 motor shield. Problem is related to using microstepping and errors in positioning depending on how many full steps are requested. The worst case is trying for a full rotation, for my 200 step motor calling 1 * 200 steps results in one very accurate rotation but if I do it as 200 * 1step I get 2 complete rotations. 4 * 90degree (50 steps) rotations returns 208 steps, an 8 step overshoot. If the number of steps requested is a multiple of 4 (200,100,80,....4) then all is ok. Any other numbers of steps and you get a bonus of 1 to 2 steps for each call. Anyone else getting the same effect? Delete the problem bit of library code and it seems to work perfectly. A call of 200 * 1step now gives a single accurate rotation. Can't see any use for the problem bit of code; seems to be trying to capture an impossible error (badly). Regards, CFJ

If you don't want to do peer to peer over the loconet then you can use the railsync lines as the DCC input to the opto-coupler in post 8, no changes needed. If you want to do some reporting or status over the loconet then you would need to feed the data lines into the opto-coupler and will also need to add a bit of circuitry to send loconet messages, fairly simple just a resistor, fast transistor and a pin on the arduino. See the bits connected to pin 2 of schematic in http://www.locobuffer.com/LocoIO/LocoIO.pdfas example of Tx from the cpu.

I have nearly finished my first Arduino project , not counting the many, many tutorials with blinking LEDs. It is a train speed measuring unit. Yes, I know there are several of these available but it is just a simple project to see how I go. Just need to make a couple of mounts for the detectors. Uses IR reflection as detectors/sensors, a pro mini as the CPU, 2 line LCD for output and a 5V regulator. Development was done with a Uno. Truely thankful for the cheap electronic modules available from China as it certainly speeds up construction and of course keeps the cost down. I spent more on the hardware side (plastic case, power connectors, sensor connectors) than the electronics stuff. The raw cost would be about 10 quid for the major items. Making it pretty would be at least the same again. Used EEPROM CVs to store the scale (max 1:500), distance between detectors (max 2000mm) and output units (kph or mph). These can be changed at any idle time using a few push buttons. Max values can be easily changed in code. The unit can work from either direction through the IR gates. Was enjoyable, mostly, as I came to terms with the requirements for LCD, strings and C++ math. The math and units seem rather clumsy. Now am onto making my PECO turntable operational. Most of the code written, just into debugging. Using some of the coding I made for the speed unit, especially for editing CVs, adding editing and deleting tracks. For this project I am going to use a 4 line LCD on I2C, what a struggle to get the right setup for the interface, and an Adafruit motor shield for the stepper motor. Algorithm for selecting which direction to turn and then how far to move was a right pain, kept making small mistakes (really a bummer getting senile). After the code, comes the mechanics. Regards, CFJ