"Auto-Configured DCC Interfaces" : DCC++ Caution

Dear MRHers,

(EDIT: Page 16 has relevant comments which indicate the RPi latest-image may correctly-detect the CH340-equipped Arduino UNOs. However, as to whether this added-detection-code solves the hardware-based "failure to operate stable at DCC++-required BAUD rate" root cause of the below-noted CH340-chip VS DCC++ misbehaviour, is yet to be determined...)

Just a side-note on the comments on Page 12, RE "auto-detection and configuration of DCC Interfaces".

If you are using a DCC++ interface with your Raspberry Pi 3b,
based on an Arduino UNO board,
and the Steve-Todd image seems to stubbornly insist that the "DCC Interface" is a Digitrax PR3,
(IE it does _not_ seem to accurately identify and configure as a "DCC++" interface)

then it is _likely_ that the Arduino UNO you have used is a cheaper clone unit,
with some chips which are known to commonly misbehave when used as a DCC++ system.
(IE the UNO is likely equipped with a CH340x Serial<> USB bridge chip,
as pointed-at in the below image)

This is _not_ a JMRI software bug,
nor is it a fault with the Steve-Todd RPi / Linux image or configuration.

The solution is to obtain an Arduino UNO with a known-working chipset
(IE "Atmel 16u2" Serial<> USB bridge chip,
as pointed-at in the image below)

which declares itself correctly over USB
(IE so that the Steve-Todd image can accurately identify it as a "DCC++" rig)

and can be relied-upon to "work as intended" in a DCC++ system
(No control-dropouts, loss of control, loss of Track-Power feedback).

Happy Modelling,
Aim to Improve,
Prof Klyzlr

Page 24 "powering down" callout

Dear Joe,

In the small call-out box at the bottom left of Page 24 RE "Powering down your Raspberry Pi",
it makes a reference to 

Problem is, what is "#7"?

- Image/diagram #7 in the article (Page 6) is a USB Keyboard and mouse,
doesn't seem relevant?

- The text on "Page 7" does not make any reference to "powering down the RPi" or similar

- There is no "Step 7" within the article headings, literally "Step 6" starts on Page 18, and ends on page 25 with the end of the article.

- IF however, the sidebar is referenceing sub-step 7 in the text box directly above the sidebar,
(IE "Step 6, sub-step 7", on page 24)

then maybe adding the word "above" after "#7", would help get the reader to where the relevant "side note" is relevant???
(I know the main article text says "see sidebar below", 
but we need to also be able to route someone who read the sidebar _first_ back _up_ to where the relevant jumping-off-point was/is...)

FWIW, I use an app called "SSH Button" on my Droid phone/"JMRI Throttle" to remotely and safely shut-down the Host RPi...
(when it's time to stop running trains:
- bring all trains to a stop in EngineDriver
- use EngineDriver to set the Track Power to "OFF"
- close the EngineDriver app
- launch the "SSH Button" app
- press the onscreen buttong to send the required "Shutdown" command to the RPi
- wait until the RPi LED indicators are OFF
...and you're safe to turn-off the Mains power)

Happy Modelling,
Aim to Improve,
Prof Klyzlr

@Prof K re: A variety of points

Hi Prof!

First, let me make an attempt to slow you down somewhat, and consider these points before you go back and carefully reread the article.

Have fun! 

An excellent article

An excellent article  Geoff. I have my Raspberry Pi running JMRI and an Arduino Uno based DCC++ system.

I will use your tweaked version to auto start JMRI.

Thank you for that.

Duly noted

Dear Dr Geoff,

Many thanks for the clarifications. Must admit once I saw reference to Steve Todd's image, I kinda missed that the article content was using a _different_ image source. Having discussed with Steve at-length the issues of the CH340 bridge in a DCC++ implementation, I was surprised at the "can detect CH340 OK" comment,
and scurried back to my archive of RPi images to check Steve's Release Notes for the update. 

Having had absolutely reproducible fault-symtoms with the CH340-equipped UNOs when used as DCC++ host boards, I will be very interested to see if the updated RPi image can compensate for what appears to be a hardware-based problem.

I take the point about the download link "setup delay", but when the other URLs in the article work,
and only this one does not, then it kinda begs the question...  

Furthur, clicking on "the link" text didn't
"try to take me to a webpage, and Error 404 because the page was not there",
like one might expect from
"a clickable URL link in a PDF which is active, but points to a URL which does not-yet exist".

Rather, it literally did not register as a "clickable link" at all (no "click" cursor change),
even though the Color and Underscore of the text suggested that it was a clickable hotlink?

(IE it felt like a static text-formatted placeholder,
which will not "spontaneously come-alive" when the Download page URL winks into existence,
but will require the Reader to re-download an updated PDF with the text made as an actually-active clickable-hotlink?) 

EDIT - 12:19 4th Mar 2019 : Just downloaded my copy of MRH-RE landscape version,
the hotlink-in-question in MRH-RE is _actually_ a clickable hotlink,
(hover over the link text, and the cursor changes),
which re-inforces the observation that the original free MRH landscape PDF release "link" was not actually a hotlink, but a text-formatted placeholder... 

The "SSH Button" app is available for Android from the Google Play Store 
https://play.google.com/store/apps/details?id=com.pd7l.sshbutton

It comes pre-config'd with some useful buttons like "Shutdown" and "Restart",
just need to edit with the correct Linux Username, Password, and IP address.
(all of which the Modeller likely has recorded, having gone thru the process of setting up a RPI/JMRI rig).

Not an iWhatever user myself, but equivalents on the iTunes appstore look to be available?
https://itunes.apple.com/us/app/ssh-remote/id931573495?mt=8
/> https://itunes.apple.com/us/app/simple-ssh-remote/id931302552?mt=8

For truly "headless" operation where the RPi/DCC++ rig is just "the black box that makes the trains work",
being able to shut the system down from the same handset/device which acts as "the throttle",
feels like it centralises the User experience...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

@Will

Hi Will,

Have fun! 

@Prof re: CH340G problems

Hi Prof,

I agree the CH340G substitution should largely be avoided. I have seen several different CH340G chip makings as well, and am wondering if there are different sources/versions of the chip?  I also have had more early life failures with this chip than most any other. I have also ordered a batch from Chinese sources picturing the proper "square" FTDI chip but received the CH340G substitution with no warning --- GRRRRRRR!

Have fun! 

VNC

Prof Klyzlr,

I have a VNC client on my cell phone and have used it (I'm running Steve's version as well) to shutdown the RPi-JMRI OS before I turn off the power. It has the added usefulness of being able to peek at WiThrottle and being able to see what _it_ thinks the state of the world at this point is.

how long ago was article written?

it seems that the delays in publishing an electronics article can make it out-of-date by the time it is printed.

@Greg re: Timely data

Hi Greg,

The RPi image was updated last October. It was current at submission at the end of the year. However, from a modeler’s perspective, just starting out, that is mostly irrelevant. What is relevant to the article is that all the software is there, compatible, and unit and system tested. That is... it all works. And as advertised it is “load and go” capable, as is.

While some modelers will no doubt attempt to make the RPi their new “development” machine, I advise that modelers consider it their “model railroad” machine and hold onto their laptop, unless they want to make Linux and the RPi their new (sub)hobby!  And all are welcome to do so.

Those experienced hackers, already ripe in Raspberries, can enjoy the fact that mere mortal modelers will be catching up to you... at least in a small, but perhaps significant way!

All enjoy, and have fun!  

Best regards,

Geoff Bunza

Bonus files are up

Bonus files are up now! Also, the latest edition of the magazine uploaded now has the bonus download link active in the Raspberry Pi article, and the #7 reference has been made more obvious.

Thanks

Other stuff on the RPi

I have an RPi 3B that runs my railroad:  JMRI through USB to NCE for running;  JMRI through USB to RS422 interface to CMRI SMINI's for signal system, etc.   It does it all.  (The drivers for the NCE and RS422 interface card chip sets were all there as well.)  It took longer to read the how-to's than to do it.

In addition,  When you load the Rasbian (Linux) operating system, it also loads the Open Office suite.  When my home office computer died, I did all my work on the RPi.    (Thumbs Up!)

RPi motor/servo controller hats

I was wondering if anyone has had the opportunity yet to try controlling a turntable stepper motor or turnout servos with any of the motor control "hats" available for the RPi. Since the hats are designed to be stackable on to the Pi board, the servo controller hats can be stacked 64 times and control over 900 servos. It's a little tantalizing to think that one could stack a stepper motor controller hat with several servo controller hats and have turntable and turnout control from one central, somewhat inexpensive solution. 

The hardware isn't so much my concern as the software aspect is. Not sure if it's possible to have all that motor control and still be able to run JMRI at the same time in order to have the cell phone throttles. I'm also not 100% clear if the input signal has to be all software/digital, or if there is enough capacity to have local pushbutton control for all the servos.

Thanks in advance to anyone who might have some insight to share.

Mike in CO

real-time capability

ironically, the simpler Arduino is more capable of reacting to real-time events such as detecting the precise location of an optical sensor or stopping a motor when detected.   of course, real-time is a relative measure:  usec vs sec.   

the more sophisticated typical OS running will have latency issues.   Of course there are alternative OSs that can minimize latency to the degree needed.

i'm curious, what I/O mechanism is used to control 900 servos separately?

Adafruit stackable servo controller

Adafruit makes this 16 Channel Servo Controller "bonnet."  Several can be stacked to control over 900 servos. $10 per 16 channel board.  Works with all current models of the RPi.   Here is a link to the learning guide.

Here's Lady Ada describing it when it was a new product -

 

Programming On RPi

After 40 years in I.T. (retired for 10), programming in COBOL, BAL, Cybos (a derivative of Forth), Basic, and a little FORTRAN, I'm trying to learn some other language(s) for use on my RPi and for possible use on Arduino based systems. I do have some questions however!

Should I be concentrating on Python, C, C++, Java, or ...? As I see it, there is a potential for an interpretive language like Python being too slow for large programs. Compiled programs may have more complexity than I am willing to put up with in my old age. What other reasons do others have that support their language(s) of choice and what reasons for avoiding other languages?

Inquiring mind looking for answers.

@Old Curmudgeon - RPi languages

Finally, someone else on this forum who knows COBOL & FORTRAN!

I've been working with Pis since they came out in 2012 and have tried many of the languages available on it, which means many of the languages that will run on just about any Linux/UNIX machine. I've been most productive with interpreted languages such as BASH and PERL. I find them easier and quicker to code than Python and Java, but others will certainly have had different results. I normally turn to C as a last resort because as a compiled language, it's a bit more of pain when it comes to development because of the compiler involvement. That said, the gcc compiler suite is easy to work with, just an extra step.

If you loved working with BAL (ick) then you might want to give the gas (gnu assembler) a try, but I find that trying to collect all of the libraries needed for even a simple project to be a pain in the gas/a**.

There are nice COBOL and FORTRAN compilers for Linux and they will run on a Pi, but I think that using those languages is kind of overkill.

Have fun coding!

@edwardstd - Thanks

Your thoughts on C/C++ seem to be in concurrence with mine and the little bit of work I've attempted with gcc was favorable. BAL was not a favorite of mine,  though it could be pretty amazing, but development time, even with a substantial macro library, was just to darn much like work. COBOL and FORTRAN are not conducive to rapid development and definite overkill.

Haven't looked into PERL or BASH, but will do that now. And use Python in the meantime until or unless I find something that fits me better.

Thanks for your insight and we'll see if others will add their two cents worth!

It’s not that they don’t know COBOL and FORTRAN..

..but that they’re too embarrassed to admit it. Something about revealing that they are dinosaurs. Over my career, I’ve used both FORTRAN and COBOL, as well as a stint of assembler programming on Honeywell mainframes. The latter years were mainly doing Java and web development, but I’ve also done some Visual Basic “for fun” (??!). Now retired, I do a little Arduino programming I whatever flavour of C that is. But that is very limited. Nothing like what Geoff Bunza (genius) does.

Another use for a Raspberry Pi

I posted some of this information quite a while ago, but this seems like an appropriate time to mention it again. I am using two Raspberry Pi boards to control track block power assignments for my N scale railroad. I built it using traditional DC track block control because only one of my ancient N scale locomotives is DCC ready and I'm not inclined, at least at this time, to do all of work necessary to convert the others. I have had some suggestions from other MRH forum members about decoders that will work without having to butcher the guts of the locomotives too much, but that will have to wait

Here's a simple diagram of how I use a web page hosted by the Apache web server running on the Pi to control blocks of relays, which in turn connect track blocks to either Cab 1 or Cab 2.

The user interface to accomplish this is a very simple web page. Here's a screen shot.

By clicking on the desired radio button and then on one of the two Update buttons, track blocks can be connected to either of the two cabs or shut off. This enables me to control the track blocks from a smart phone, table, or any other networked device. This means that I don't have to walk over to a control panel to change block assignments. More info can be found by clicking here.

If anyone is interested in exploring this, PM me here at MRH or contact me via eMail. I'll be happy to send you all of the programming.

programming language

i've used C almost my entire career, except for a decade doing DSP work.   C++ has been unavoidable, but every since joining Bell Labs in '85 and hearing about C++, i've never seen a nice piece of code using it and have heard many complaints.   Ken Thompson and Rob Pike went to Google after leaving Bell Labs and created Go, a more pure object oriented language.

A few years ago i looked at our RR club's graphical CTC application on my laptop.   Not having a C development system with graphic libraries, I used Java for the graphics and GNU gcc to compile the CTC code.

my day-to-day language is AWK, the granddaddy of scripting languages.  It's clean, but is best suited for text processing.  I use it with Xgraph to plot data.   It has no network support.    AWK has associative arrays which affect how you code.

But a few years ago i used Python to control some test equipment over the network.   I developed a non-trivial application relatively quickly.   While I used it for it's network support, i found that it had more of the associative array like capabilities and i've seen others use it to do signal processing and generate plots like MathLab.

while it's a scripting language, today's processors are more that fast enough.   I'd suggest Python over C/C++ given it's range of capabilities to support network applications, graphics and more

Strawberry Pi

Neat idea but doesn't almost everyone have an old computer that could do it all?

As an average hobbyist who is

As an average hobbyist who is new to the world of Arduino's and Raspberry Pi but has a lot of practical experience in the hardware end of computers and electronics and wanting to learn to write simple programs and sketches... wouldn't I just want to learn "BASIC"? I'm too old to go back to school!