My code only sends it out on the rails. The wifi side only gets the basic dcc++ text protocol commands. Sent from my ONEPLUS A5010 using Tapatalk
@Atani -- So would it take much to include ALL of the DCC codes over wifi? Or was there a reason for only including a partial set? My plan was to have each decoder use one or the other -- either track signals or wifi signals -- but never both. I don't know if there would actually be a problem with a single decoder receiving the same signals through both methods, I just assumed it would cause less trouble if I only looked at one source at a time. From my own experiments trying to get clean power to the ESP on my loco, I know trying to receive anything through moving wheel is less than reliable, which is why I thought it would be great to receive the loco's DCC commands over wifi (plus it provides a conduit for future expansion where I want the loco to also send information back out again). On the other hand most accessories such as turnouts can be hard-wired to the track power and cleanly receive the commands. Does my reasoning seem logical, or am I missing something important?
Dcc signal and the encoded data packets can only be sent out on the track. The dcc++ text based protocol does not have enough information in it for the locomotives to know that the command is to be sent to it and not another locomotive. At least not for all locomotive commands. It would be best to read the DCC packets from the track as all other decoders do. If you are worried about powering the esp chip you can use an onboard battery. But you would still need the track connection via the optocoupler so you can capture the dcc packets. Sent from my ONEPLUS A5010 using Tapatalk
Oh no, power for the ESP isn't a problem, and I actually use a pack of capacitors to provide a small buffer. I *can* read the signal from the track once I get in the optoisolators, I'm just impatient to get this rolling again. So can you explain this to me? I thought DCC++ implemented the full DCC protocol, and from what I've seen it's just a string of text commands. What is the difference between sending those same commands over the tracks or over wifi?
Dcc++ uses a text based protocol for throttles or jmri to communicate with it. Dcc++ generates a dcc signal to the rails based on these commands. Sent from my ONEPLUS A5010 using Tapatalk
The DCC protocol on the rails isn't text; it is made up of bytes of data embedded within a 12 bit preamble and post amble checksum byte followed by a single stop bit. This would be impossible to create using ascii text strings. Also the DCC signal on the track cannot stop, so 'idle' packets are repeated if no commands are needed. https://dccwiki.com/Digital_packet Jim
@Simon -- I got started trying to work with your code today. Turned out the JMRI throttle on my phone didn't work the way I thought it would (I guess you connect to the loco's IP address, not the base station's) so I dropped that and was using telnet to connect directly to the loco. It seemed like I was making progress directly entering commands and was trying to get the motor to work, then I started having problems. First it started having trouble connecting to dhcp on the wifi (the queries reached the dhcp server but the IP was never accepted), then when I flashed it again, and every time since then, I am getting fatal exception errors immediately after flashing, and random garbage on the serial port if I pull the power and restart. I'm using an ESP8266-12F, and am just trying to figure out how to get it working again. A full erase and check from the command line looks perfect, the flash space came back full of FF's, so I'm thinking there's a problem flashing the bootloader. Still working on that... In the meantime on line 573 of your code, since I'm using DHCP I commented out the IPaddress settings and hit an error. Try adding the following to your code here: // WIFI Begin #if defined(IPAddress) WiFi.config(ip, gateway, subnet); #endif
@Jimbo20 -- I've been thinking about what you said above, but one thing still confuses me... I keep hearing that the some pieces of the DCC++ protocol doesn't translate to text strings, yet there's a wiki page that details the exact text string for every DCC++ command that can be received. Am I missing something, or is it just that there's no support yet to rebroadcast the same commands over wifi? Yeah obviously I'm still trying to wrap my head around all of this. @Simon Mitchell -- I was thinking again about your code this morning and wondered if you had considered UDP broadcast packets? If you're not familiar, UDP broadcast means a command would be sent out across the local network that could be received by any listening machine. It is not targeted at a specific IP address, and seems like it would be more similar to how DCC commands are sent across the rails, where each receiver determines if the information was addressed to it or not. Of course it still requires something to transmit those signals, but it does allow you to not need a static IP address for each loco. Just a thought...
The DCC++ protocol is not the same as DCC. The DCC++ wiki page you reference is just for interacting with the DCC++ base station. It does not translate to anything that any DCC decoder will understand, at least not a literal translation.
@Atani -- sure I wouldn't expect a commercial decoder to understand the text strings, but I'm referring to using ESPs on locos and for accessories, received over wifi. Obviously you wouldn't want to change how things are sent over the rails or you risk breaking compatibility with the original DCC protocol, however looking at Simon's code he is using the same text strings as defined on the DCC++ wiki, which makes sense as a way to communicate over wifi channels.
This is where Simon's system is different; His system receives the DCC++ protocol ASCII text commands from the throttle (or JMRI) via WiFi in the loco, and translates those text commands directly to motor or light operations. DCC protocols (or indeed a DCC++ controller or DCC decoders) are not used at all. Jim
@Jimbo20 -- although I'm not quite sure yet how the DCC protocol works through the tracks, it doesn't surprise me that a different method would be used for wifi where straight-text is more easily handled. When I read the wiki page listing the commands (and I'd swear I saw similar information somewhere else related to DCC), I had just assumed that was the actual information being transmitted through the rails. No worries, now that I understand this is NOT the case it's staring to make more sense to me why there are differences between the track and wifi signals. I can make the wifi part work though, once I get a chance. Still fighting with my esp8266 on the loco. I loaded the same code on it and my breadboarded esp, and the one on the breadboard works perfectly but the loco chip refuses to run any code now. Such a shame, I've been experimenting with this setup for well over a year and it'll take a lot of work to solder together a new module. Good excuse to switch to an esp32 now though!
I’m pretty sure you are right, I didn’t do all possible text strings, I avoided the chang8ng of CV’s for example This would be a good idea, I just didn’t know how to do it. The issue is that JMRI requires a connection to be made, and that included a requirement for an IP address. So I was working on either a local host chat server, and a WiFi connected base station to send back the required ack. I was only using static IP’s for ease of telnet in each time. The decoder should respond based on a hard coded ‘loco number’, eg ‘5565’ in one of the examples, rather than resp9nding on the basis of the IP address.
I know this was an old one but I'm getting an interesting result that I hope someone can help me troubleshoot. First I'll start by saying I have the original DCC++ working for a few years now with no issues. I downloaded the library and then hooked up with the original motor shield. Copied the simple sketch just for text commands shown below: #include "DCCpp.h" #ifndef USE_TEXTCOMMAND #error To be able to compile this sample, the line #define USE_TEXTCOMMAND must be uncommented in DCCpp.h #endif void setup ( ) { Serial . begin ( 115200 ) ; DCCpp :: begin ( ) ; DCCpp :: beginMain ( MOTOR_SHIELD_DIRECTION_MOTOR_CHANNEL_PIN_A , DCC_SIGNAL_PIN_MAIN , MOTOR_SHIELD_SIGNAL_ENABLE_PIN_MAIN , MOTOR_SHIELD_CURRENT_MONITOR_PIN_MAIN ) ; DCCpp :: beginProg ( MOTOR_SHIELD_DIRECTION_MOTOR_CHANNEL_PIN_B , DCC_SIGNAL_PIN_PROG , MOTOR_SHIELD_SIGNAL_ENABLE_PIN_PROG , MOTOR_SHIELD_CURRENT_MONITOR_PIN_PROG ) ; } void loop ( ) { DCCpp :: loop ( ) ; } and uncommented #define USE_TEXTCOMMAND on DCCpp.h All uploads and acts fine. JMRI opens it fine and says both programming and main active. I can open dcc++ traffic monitor and see it transmitting on serial when I do track power, throttle control everything is fine. When I do a function though the following is what I see in an endless loop. TX: f 3 174] Function Cmd: Address: 3 Byte 1: 174 Byte 2: null (No Reply Expected) [TX: f 3 144] Function Cmd: Address: 3 Byte 1: 144 Byte 2: null (No Reply Expected) [RX: F0 3 174 -1] Unregonized reply: F0 3 174 -1 vals: F 0 3 1 7 4 - 1 [RX: F0 3 144 -1] Unregonized reply: F0 3 144 -1 vals: F 0 3 1 4 4 - 1 [TX: f 3 174] Function Cmd: Address: 3 Byte 1: 174 Byte 2: null (No Reply Expected) [TX: f 3 144] Function Cmd: Address: 3 Byte 1: 144 Byte 2: null (No Reply Expected) [RX: F0 3 174 -1] Unregonized reply: F0 3 174 -1 vals: F 0 3 1 7 4 - 1 [RX: F0 3 144 -1] Unregonized reply: F0 3 144 -1 vals: F 0 3 1 4 4 - 1 even if I turn track power off the transmit and receive loops continue. Any ideas on what this could be?
In the original DCC++ code, there is no serial answer to a setFunction() call. But in DCCpp, I add an answer just to be conform to almost all other functions. To verify this is the problem, remove or comment the lines 201 to 211 from PacketRegister.cpp in my library. If this is the problem, i will produce a new version with a way to avoir unnecessary text answer.
Just to close this out. I reloaded my Arduino with the library and it fixed everything so not sure exactly what it was but all seems working now.
