I'm sure I have seen posts where a 2nd UART was used on a Mega, think it was with a WiFi throttle or maybe a second Arduino for sensors (?). What I would like to do is setup the Base to use the USB as normal and an HC-12 radio, merging the two serial inputs from UART 0 (USB) and UART 1, 2 or 3 (HC-12 Tx). Have seen this done with non DCC++ projects, two Midi connections. Haven't started looking at the source so any example code would help. Bill
Went through the source files and think I have it worked out. Haven't tested anything yet so could very well go down in flames The basic idea is to add a second Serial input to the SerialCommand:: process() method. The biggest sticking point was I expected to see Serial.available and Serial.read calls but the code uses INTERFACE.available, .read, .print ect. Think this is an alias for Serial (0) if I understand this bit right: #define INTERFACE Serial //?"INTERFACE" is alias of Serial (0) >my comment< Assuming this is correct, I added an alias for Serial1, INTERFACE1. Then added another COMM_INTERFACE type that exposes the two UARTS. In SerialCommand:: process() added an extended handler for COMM_TYPE == 4. The standard COMM_TYPE == 0 handler builds the incoming bytes into a command message in commandString. When the command is complete, it calls parse(commandString) to dispatch to the DCC processor. The new handler uses two temp strings to capture the USB and RF incomming bytes till they are complete. The completed command message, in one of the strings, is then copied to commandString and parse() is call as standard. Hopefully, commands from the RF will seamlessly be processed and responses from the Base will be sent to the USB, as before; keeping JMRI, or whatever Controller, in sync. I outlined all the changes I will be making in the included file. Bill
you can always look at my clone of the base station where I have split it up so that multiple interfaces can be used I don't have an HC-12 but since it is just a streaming device it shouldn't be that different than the ESP WiFi modules... You can find my clone here: https://github.com/atanisoft/BaseStation I currently use the default Serial as the USB connection to my PC and Serial1 connected to an ESP8266 device.
Oh thanks Atani, I knew I had recently seen someone (you) had done this. Will dig through your changes Yea that's exactly what I want to do, maybe even setup another UART for a wired throttle too, just like the options and the mega has the hardware. Bill
In my repo you can add a line like this one: https://github.com/atanisoft/BaseStation/blob/master/DCCpp_Uno/DCCpp_Uno.ino#L251 for each hardware serial interface you want to support/use as a standard serial interface. I didn't add a base serial class for SoftwareSerial based interfaces but one could easily be created based on CommInterfaceSerial.cpp/h and CommInterfaceESP.cpp/h.
Did you ever test out your changes? I am interested, because while you can run multiple throttles over several HC-12 links on the same channel, when I added turnout control the interference between cabs would about 1/2 the time block the turnout command message. As I only send the turnout command once, this makes for frustrating operation. I only have 2 cabs working, but I assume that as more throttles are added, the problem will only get worse. The throttle command is sent repeatedly, so it gets through, but if you had 3-4 cabs, it might not work so well.
Hi SP_fan_1951, haven't gotten that far yet. Still waiting for the HCs to arrive and finishing up the first throttle build. Not sure I understand 100%, are you sending the turnout messages from JMRI or turn out/stationary decoder support in the wireless throttle? Being simplex devices and after reading Dave's notes on the HC, I was thinking the HCs had some sort of carrier detect function, I.E. the module would hold off keying if it detected activity on the channel; it's Rx buffer is receiving bits from the other HC on the channel so the Tx is inhibited. But I may be incorrect. I wish there was more info on the HCs and their control software. In Dave's code I think there is a section to repeat the message but it's commented out (I assumed it was unnecessary). Perhaps adding a re-trans function for stationary decoder messages would help. Another option is an active check of channel activity. Something along the lines of checking for received bytes and waiting for a ">" from the 'on-air' HC. So with two throttles, both would check before transmitting and if the channel is active the pending throttle will wait till the active message is complete. It wouldn't be 100% but would improve things maybe. The changes I outlined to the DCC++ base will hopefully handle the two UART sources gracefully, building separate incoming bytes in temp arrays till the 'end of message' marker and only processing one completed command massage at a time. But there has to be some external control for multi wireless throttles because the base expects a single message, byte by byte, from "<" to ">". So the throttles must send complete messages before the other can start a new message. Bill
I am sending turnout commands <T xxx 1> or <T xxx 0> from my wireless throttles, and using an accessory decoder to drive servos via PCA9865 I2C PWM chips. The accessory decoder grabs the signal from the track. At some point I may try to figure out how to make the wireless communication bidirectional, so if the acknowledge isn't sent from the Base Station, the turnout command will be resent. I've got my throttle code working pretty well now, and with only one throttle fired up the turnouts work flawlessly, but when I turn on my second throttle I get the intermittent action. At any rate, its great fun playing with it. I want to try attacking consisting next.
I've been experimenting with esp8266 modules for a while now, and have built a couple of controllers loosely based on Dave's S/W to control my small N-gauge Inglenook Sidings layout. Its still early days, but I'm having some success. The DCC++ BS has an ESP 8266-01 connected to the serial port, and is set up as an access point (so the wi-fi system does not need a router) and uses a websockets library. I do not use any other serial connections to the BS. The first controller has an Arduino Nano and an ESP8266-01 in it and a 16x2 LCD as a display. The second controller I built is smaller and does not have an Arduino; All the code runs on the ESP8266-07. The controller also has a small .96" OLED display. Because the websockets protocol is duplex, I have been able to get the second controller to monitor the BS confirmation packets and get the display to echo the settings of the points (turnouts). It seems to work okay - even if I have both controllers turned on; I can change the points on the controller one and the display changes on the controller two. Jim
Steve, I created a new thread here: http://www.trainboard.com/highball/index.php?threads/dcc-wifi-controller-on-an-esp8266-07.111489/ Jim
Hi. I've been experimenting with arduino Mega and Atani's DCC++ multi-serial. Dcc++ base works nice. But when I connect wired DCC++ Throttle from D.Bodnar to RX1, throttle doesn't work. In RX0 works fine, but JMRI couldn't connect to base station. Thank you for your help.
Bill I am looking to set up a Mega Base Station to use both WiFi and HC12 .... I have it working with Mega and ESP32 on WiFi. Where/how in Atanis code did you enable the additional Serial comm to enable, say, Rx2? Steve
You can add additional Serial interfaces here: https://github.com/atanisoft/BaseStation/blob/master/DCCpp_Uno/src/DCCpp.cpp#L251 Something like: Code: CommManager::registerInterface(new HardwareSerialInterface(Serial2)); Keep in mind for the DCC++ESP base station (above code link) Serial and Serial1 are in use (Serial1 is used for WiFi/ESP). Anything that comes in from any of the registered comm interfaces should be broadcast to all other interfaces as well.
MIke I've been wrestling with this for awhile ..... can you amplify a bit on where in DCCppESP32 to find "CommManager:: ......" I've searched the code and am at a loss. Once one has established the new Serial where would one enter the code to access HC12? Does it need a new library? Steve
DCCppESP32 doesn't have CommManager code in it. The code was simplified to just having WiFiInterface as the primary external interface. To support the HC12 as an input source is doable though. Probably the easiest way to do this would be add to WiFiInterface::begin() the code to initialize a Serial connection to the HC12 and then add to WiFiInterface::update() to receive data from the HC12 and add code to WiFiInterface::send() to push data out on the HC12. Keep in mind the "Serial" interface is used for logging purposes and should not be used for the HC12. A SoftwareSerial or the second HardwareSerial interface can be used though.
