In reverse order.. Steve - I'm not so sure. The DCC++ base station currently sends commands to individual locomotive decoders using the DCC protocol over the rails. As has been alluded to above, I see the WiFi Decoder as using WiFi as the comms path instead of the rails. Keeping the DCC++ base station as the server means that the WiFi decoders are a bolt on option, with many 'throttle' choices, including WiThrottle commands, JMRI commands, DCC Controller commands. I'll make another attempt at your ESP server. The mesh is a great idea for offline comms (eg at an exhibition) but I just can't find anything about how to get other devices hooked up to it. I had a read of painlessmesh last night, it might hold more promise as the SSID/Password are more configurable. @Atani (sorry, haven't spotted if that is your name or a username) - Sounds great. I'm really tempted to defer to the combined greater knowledge on WiFi, and go back to enhancing the decoder code with OtA, Eeprom (CV's), Momentum and Braking. As a discussion point, I might refer back to http://model-railroad-hobbyist.com/node/11824 My rough diagram is;
From your MRH link what I am working towards is effectively figure #3. What you are after is figure #4 or figure #5, both of those would be feasible from your throttle with a bit of work. You would need to implement one of these options: know the IP for every device you need to send the message to. use multicast UDP packets to broadcast the message out to all devices on the same subnet. setup a mesh network and broadcast to all members. For the first one your throttle would take a while to send the packets to all devices since it would likely do them sequentially. You could improve this by keeping a mapping of loco address to IP and then send the packet only to that IP. You could setup an mDNS responder on the ESPs to give your throttle an easy way to figure out what devices are out there and what they are possibly. This would be one way for the throttle to find devices out there. You could combine this with #3 on my list above to have devices figure out things automatically. Mike
Simon, So the aim now then, is to use NMRA DCC as the protocol for your decoders? In other words you have changed the spec of the first code examples you presented here? For something like that to work with a DCC++ base station, all using WiFi, will need two servers. One to deal with the incoming text based commands, be they from directly connected throttles, or a computer based control system like JMRI. Then on the DCC packet output - which will require some modification of Base Station code - the distribution server for all the decoder clients. At the decoder end you will then have the issue of generating the precisely timed signal from those data packets, if it is to work with commercially available decoders and provide that in a high voltage format. Sure, there are designs out there using Arduino's as a decoder base, but the amount of task specific silicon units is starting to stack up. Can ESP handle both those tasks? And then what of the high output voltages? A pseudo DCC text base system, should be relatively easy to achieve. Something like the above is in another league.
Hi Steve, Sorry to mislead. I have no intention at all of creating the DCC packets. The only reason to do that would be to drive a standard DCC Decoder, and I have no reason to do that. However I thought it would be cute to be able to 'program' the wifi Decoder CV's using Decoder pro. Shouldn't be that hard to do as they are just text commands.
So back to my point earlier... Throttle is a loose term I used for the the many available options for sending the text commands. Which again, means there is no need to even consider adding more layers of complexity by including a Base Station 'server'. A single pass through text command server is all you need, and just continue to develop the decoders to interpret that text as required. If 'real' DCC is needed for say, the audio part of the project, then a Base Station can be added later as a separate branch (client) of the text server. So now we're right back at plan A, a software solution based on a java chat server (my favourite choice), or hardware based on some WiFi mesh protocol.
I just had a closer look at your java chat server post. I guess grabbing eclipse would be a good idea since I hope to look under the bonnet of Twin Dad's VSD. Then it will be deciding what to run the chat server on, not an ESP8266 in the long term. I've posted on the ESP8266 forum about connecting to a mesh.
Not ESP for sure, the Java server would run on the host PC along with your JMRI. You could do it as an 'invisible' API or look at a simple GUI which is easier to do that you might first think. And, as you note a little Java knowledge will help with JMRI. On the CV thing, as you're in complete control of how your decoders actually function. Then I can't see you needing a back door into the settings - which is all CV programming is - you do all that at compile time. It's no big deal if you need to tweak things later, you just reprogram ESP in the more conventional ways, even OTA if you want. This again keeps it simple
I think I'll set it up on my laptop, and then in due course migrate it to the RPi3. Agreed re programming CV's. I was thinking down the line for others who may want to use them. I definitely need to do OTA, and I'm feeling fairly confident about that now.
Well, we can cover OTA another time, it's is real easy once you know the protocol. In fact most things ESP are just reworks of all the brilliant library examples that the Arduino/ESP guys have given us to work with. If you take a modular approach to the project, baby steps if you like, then it will all come together in a logical sequence. Trying to incorporate all the 'frills' at the same time is not a good approach, and it will usually take longer to achieve the goal. So start having some fun with that Java.
Hi Simon It just occurred to me that the Processing IDE might have some simple server in Java. Sure enough in the examples, there is a Chat Sever. It should take you all of 2 minutes to get this running. Get the IP address of the machine you are going to run it on. Then from any other device on the same network, even a cellphone. With a TCP terminal app, point to that IP with the port number you have specified (you can change from default 10002). Start sending something! With a simple base such as this, it won't take you long to figure writing to multi clients.
So with no modification to the example sketch, I was able to connect JMRI at localhost/8080. It's now just a case of hacking some reply routines in from other examples I posted earlier. Note: my efforts stop here, I've no intention of writing the whole thing
Does anyone know how to run this server in JMRI. The one time I managed to run it without the whole thing hanging, I could telnet in over WiFi. Whats it's main purpose? Can you output a throttle through this? Edit: OK answered my own question. It's quite close to what's required here, maybe with some modification to source, it could be made to work. Now where do you start looking for it in those dozens of files? BTW description of what it does here.... http://jmri.sourceforge.net/help/en/html/hardware/dccpp/index.shtml Once I got a newer version, I was able to telnet in from my phone, as commands are sent from JMRI, I could see the replies coming back from Base Station. Hmmm
Hi Steve, Sorry I've been off air, doing lots of other stuff. I'm experimenting today, hopefully will have some progress. I've been able to create a client in the DCCppOverTcp Server and see some comms. But the DCC++ base station code I copied is not a client (I think it's a server), so I need to work on this. Also there is some handshake stuff going on that I need to look at. I suspect JMRI->Chat Server->DCC++ base station will be the way to gain access - and a real base station may be needed as there is some handshake stuff done by JMRI which I can either replicate in the Chat Server, or just leave the Base Station doing everything it is supposed to do. Again, I think my decoders will need to be changed to become clients, not servers. Anyway, lots of great contributions from all of you, minimal progress from me (sitting here looking slightly dazed).
Yeah, um... I wrote that. The server is meant to allow a remote JMRI instance to access a USB-only Base Station via a JMRI server. So it dumbly transfers DCC++ packets from the Base Station to the remote JMRI. Put another way, it's using a PC as a giant USB<->network adapter for the Base Station. Code for the server is in jmri.jmrx.dccpp.dccovertcp ... but it might be easier if you can explain to me what you need and I can make the required changes.
Hi Mark Any chance you could make it transmit the DCC++packets from the host instance of JMRI? Then I would have a lovely little DCC++ server running on my RPi3 straight out of the box...
You mean broadcast them? Or send them to a specific network address? Not quite sure I follow what you're asking...
Hmm. Broadcasting is what I am after. As an aside, I've just been playing with this setup; Host RPi3 running JMRI DCC++ Serial USB to an Arduino Uno (no shield attached), DCCppOverTCP Server (100.168.54.101:1235) Traffic monitor open Client Laptop running JMRI, connected to above host Putty connected to 100.168.54.101:1235 I'm seeing the throttle commands in traffic monitor on the RPi3, but no function commands I'm seeing the responses back from the RPi3 in Putty, but only for power/throttle. If I knew how to have a mesh working, I note that it seems to specify a bunch of devices with the same IP address. Which would probably be option 2, and I think that is already in available in the DCC++ code (Ethernet) So the big thing to get the mesh/server idea working would be a wireless base station, as JMRI is really unhappy without the initial handshake, and subsequent throttle acks. I looked at a wifi shield but that was expensive, so what I need to do is modify the base station code for an ESP8266 or Arduino UNO WiFi. I note that Mike (Atani) said he is working on the former.
OK, for the broadcasting, assuming you can do that by just making a "connection" to the Broadcast address... On the HOST JMRI instance, In Preferences->Connections make a DCC++ connection to Ethernet (not DCCppOverTCP) to the broadcast address. Or maybe for testing, directly to your decoder or mesh network or whatever. Then launch the DCCppOverTCP server on the HOST. On the REMOTE, create a Connection (Preferences->Connections) using DCCppOverTCP that points to the HOST. If JMRI is choking on not getting response strings from the Base Station, and you want it to ignore the (lack of) response strings, I can probably do that. I'll look at it tonight. Very odd that it seems to only be passing throttle commands. It should be passing EVERYTHING. If there are problems between the Host and Remote JMRI instances, you might want to try using the SimpleServer and JMRIClient interface: http://jmri.sourceforge.net/help/en/html/hardware/jmriclient/index.shtml This works at a higher layer than DCCppOverTCP ... it has the two JMRI instances talking to each other in "JMRI" and is hardware independent. So you'd have a JMRIClient connection from REMOTE to HOST, and then DCCpp/Ethernet or DCCpp/Serial from HOST to Base Station. I don't know if that would be better or worse.
