as i was working on my DCC++Arduino (well, my altered version), i realized the software was becoming very... heavy. keep in mind, this is only an idea, that i thought i would air out. i would expect that with a little work, one could make a DCC++ generator that could run easily on a Arduino Micro or Nano, or even the trusty old UNO. strip the non-DCC++ code out, and just generate the signal. one (or more) for main tracks, and one for programming. it would be a much cleaner system, in theory. my line of thinking stems from having looked at my Raspberry Pi. i thought the DCC++Arduino generator could simply connect via serial (USB) to the Rpi, and the Rpi would transfer DCC++ commands to the appropriate Arduino, and it would handle the I/O on it's own. having a much stronger CPU, the Rpi could support a lot more automation. it could be programed to receive the DCC++ commands, so it could be connected to JMRI, or it could be programmed to use a web interface. again, just a brain-storm, derived by a particularly good cup of coffee for inspiration. feel free to comment. ~Travis
That is basically what I have done with my small sidings layout. The Nano BS that runs DCC++ is only slightly modified for a 4067 multiplexer, which allows me to have 16 magnetic sensors. I have an esp8266 connected to the Nano via the serial port. The Nano BS does just generate the DCC++ signals and monitors the sensors. The ESP runs the code that automatically runs a railcar back and forth to alternate platforms, operating points (turnouts) as necessary. The ESP also provides the WiFi comms with the (ESP8266 powered) hand held throttle which provides manual control of a shunter and points, or can also take over control of the railcar. The ESP also interrogates the commands from the throttle, and only passes those through to the BS if they are intended for the BS. I have created some extra commands, EG <J1> and <J0> which turns on/off the automatic railbus, those commands are not sent to the BS as it would not understand them and only creates unnecessary overhead. Most of the intelligence of the layout I guess is really in the ESP not the Nano. I have tried to keep the DCC++ BS as standard as possible, as in the early days I did suffer from very intermittant Arduino crashes, which I never fully found the cause of, but thankfully no longer occur, probably because of the extra coding I gradually introduced (to the BS), and have since removed.
that is sort-of what i was thinking, but even more basic. no I/O at all, and just one track output (one for Main, or one for Program). it would then be possible to use anything (in theory) for the base station, as the Arduinos handle only DCC++ generation. the Arduinos would then simply connect somehow (serial, usb). so the basestation could be a Raspberry Pi, another Arduino, ESP32, etc. in this way, nothing interferes with the signal generation. it would make it more modular, and the code would be less complex. I think i will play around with the code, and see how much it can be reduced, and still generate DCC++ reliably. i will have to make two versions of course. one for main tracks, and one for programming tracks. if it works, great. if not, nothing lost but the time coding it. ~Travis
Take a look at @Trusty 's DCC++ code, he has a great library that strips out everything that you are looking to drop and preserves the signal generation only. You can find info on it here: http://www.trainboard.com/highball/index.php?threads/new-library-dccpp.113093/ or https://github.com/Locoduino/DCCpp/
Another consideration... it sounds like you want to be able to use your Pi (or another computer) to actually send and receive commands to the DCC system. If you look at Atani's DCCppESP32, you can connect over wifi via telnet on port 2560. It should be easy to write a script in your chosen language which opens the port and can then send and receive DCC++ commands based on your own code. This would allow you to use existing BS code without modification (saving you the trouble of keeping up with updates to your own BS code) and still be able to write a control system on the Pi.
actually, my thinking was to handle the automation (reading sensors, responding with outputs, and being able to scheduled (CRON) some of the I/O using the Raspberry Pi. i was thinking of placing the Raspberry Pi between the network, and the Arduino that generates the DCC++. this would (possibly) handle the I/O with a much faster CPU than the ESP32 (possibly). granted, i was all for keeping the DCC++ on Arduino, but i am seeing it's potential limitations when handling I/O. think of my idea of using the DCC++ generator in the same way a computer uses a MODEM. the Raspberry Pi simply takes the DCC++ commands, and if they relate to I/O, handle them itself, but if the commands relate to DCC++, send them to the Arduino. with a connection as simple as a usb cable. this gives a lot of options availible for how to control, and what is being controlled. this is all just theory right now, but i think it can be done. Raspberry Pi has an I2C interface, so it could still (possibly) use my MCP23017 library, using the Raspberry Pi WiringPi: http://wiringpi.com/ (again, possibly) to mimic the full DCC++ interface via it's network interface. of course, keeping in mind that the Raspberry Pi has 3.3V I/O pins. this also opens up options for the Raspberry Pi GUI. this could run head-less (no screen, mouse, or keyboard), or somebody could program up some sort of monitoring display. and being a SBC Linux computer, nearly anything is possible. i feel like i may be on the verge of a mind-blowing idea here, but maybe it is just the coffee. ~Travis
Since the RPi has I2C you could in theory use the Arduino DCC++ generator as an I2S device, feed it directly the commands you want it to send out and not rely strictly on the text protocol.. The options are virtually unlimited.
@Atani -- along this same line, will the S88 functions also generate text-based strings in the same telnet interface to show when the sensor state changes?
Yes, the S88 sensors are treated identical to regular sensors as far as the text protocol is concerned. This way they show up correctly in JMRI without requiring JMRI changes. There is one new command added for the create/update/delete of the S88 bus or you can use the web interface to do the same.
Sweet... I've only just begun reading about S88 and trying to learn about it, but it seems like it will be an important aspect of what I would like to do in the future. Still have to wrap up building my own version of an accessory decoder first though.
interesting idea, it could speed up the interface quite a bit. i think to start, i will work with @Trusty 's library (look like a real time saver), and work in the I2C later. i don't want to jump too far ahead just yet. mainly because i haven't set my test track back up yet, and programming purely on theory, without a hardware test, can reveal new unexpected features. ~Travis
i must say, programming on my Raspberry Pi is rather inconvenient, as compared to Arduino. the C++ commands are different, and i must admit, debugging is an issue... when you don't have a display for it. the family TV is not an option, as others seem to think that me coding on my Rpi is not nearly as exciting to watch as regular TV (some people are just strange ). so i am just saying, development may have slow progress, until i get a display for my Rpi. (now i remember why i don't use my Rpi much...) ~Travis
setup a VNC server on the RPi and connect to it from your PC You can also look at using Python on the RPi as it can make development faster.
Hmm, Python. not one of my strong skills. i do happen to have a book on Python on a Raspberry Pi though. SSH, i use it all the time on my personal web server. the solution is so blazing obvious, and i still missed it. I have used VNC in the past, but i also remember it being a bit taking on my workstation (it already gets taxed heavy from me multi-tasking too much ). ~Travis
Just airing out an idea: I occurred to me, with a processor, and a full operating system (Raspberry Pi), why does the DCC++ router (what this idea is based on) have to be just one long program/script? i can create a command-set for the basic commands, such as setting the throttle, or changing a CV, could be done on the system with a smaller command-line program. then it is just a matter of writing the network server (that JMRI, or whatever, connects to) as a program that calls on the separate commands. this makes the system extremely modular, and open for others to write further modifications. the commands could be a mixture of C++, Python, whatever. and if you have a Raspberry Pi with a compatible touchscreen, you could make your own very powerful GUI to control your layout. though it would have to be stationary (in after-thought), as the Arduinos connect via USB. but i think the idea still sounds good, at least in my own mind. ~Travis
i have been taking a break on the Raspberry Pi idea due to writers block (not as used to the platform i guess). A thought occurred to me while on break. do you (anyone here) think it would be possible to fit a single DCC++ generator on a Atmel ATtiny85? i think if i do a lot of pruning, and use the DCCpp library (thanks to @Trusty ), just maybe it could fit in 8Kb of program flash. as there is no onboard UART (serial port), i would have to use I2C control commands. maybe it is possible, maybe not. but i thought it would be a neat challenge. With a simpler hardware structure, soldering up a control board would be easier than say a bare-bones UNO. just a brainstorm, but i think it can be done. ~Travis
Maybe. You would only likely be able to do prog or main track with the ATTiny85. It looks like you can do analog reads as well, at least on one or two pins. There won't be very many pins left for I2C though. I would say give it a try and see what you can do
PB0 and PB2 for I2C, PB1 for the DCC++ signal, and PB3 and PB4 for enable out and analog in. it should work with the BTS7960 based motor driver, with an inverting transistor, and most other motor drivers, with a little added circuitry. if i can trim enough "fat" from the code... i will see what i can do. it isn't as convenient as the Arduino boards and shields, but if i can do it, it may make the other accessories (GPIO) easier to program for. Like you say though, only one track per chip. ~Travis
