WiFi as an Access Point? In anticipation of collectively creating a WiFi-only system that did not require a central computer to navigate between Base Station and any software or hardware throttle, I have been reviewing the specs for various WiFi shields. One thing I just realized is that, at least the shields I reviewed, they cannot be used as access points (APs). Even if the hardware could support configuration as an AP, the software libraries do not. What this means is that these WiFi shields are designed to connect to an existing network, but not create its own network. If these shields can't operate as an AP, I'm not sure they can be used to create a standalone system where other throttles connect directly to the Base Station. All of the devices, including Base Station, would be looking for a WiFi SSID to connect with -- none of them would be broadcasting an SSID. It may be that a central computer or simply a wireless router would always be needed. That would not be a problem and its probably a lot more secure anyway. Base Station would utilize an Ethernet card to connect directly to one of the ports of a WiFi router (no need to use WiFi for this part), and other throttles would utilize WiFi to connect to that same router. Am I missing something? Are their WiFi boards that do allow an Arduino to act as a central WiFi Access Point? Alternatively (or in parallel), the XBee wireless protocol seems very popular and there are a lots of low-cost Xbee shields and components designed for use with the Arduino. An Xbee-enabled HHT could wirelessly interface directly with a Base Station that had an XBee shield without the need for any central hub. Also would allow for wireless connectivity between distributed Unos and Megas if more than one is used on a layout (haven't forgotten about that idea!) -Gregg
Gregg Love the configuration mode as I too have many iterations. Compiles and uploads (Mega with Arduino Wireless shield) with warning:”platform.txt from core ‘Arduino AVR Boards’ contains deprecated recipe.preproc.macros= ………………….” Jumping pin 5 to ground reports but even with commenting out and inserting an IP address in config.h … program reports “ IP ADDRESS: 0.0.0.0 (STATIC) not the IP address entered. Still can not connect to Engine driver. I’m awaiting a couple of Ethernet shields to replace the Wireless shield (which is no longer supported by Arduino) to conform with what everyone else seems to be using……. And will test further. Steve
Gregg I was under the impression that we were just looking for the Base Station to join an existing LAN to allow Engine Driver (or other) to access a computer running JMRI .... doing away with the USB cable ..... not doing away with the computer completely. Sorry for the confusion. Steve
Wow lots of stuff over the night... (1) JMRI does not need the Register, and in fact having the Register for JMRI to deal with only complicates things. We could ditch it altogether and I would not mind. It is probably early enough in the evolution of all this that we could even dispense with backward compatibility. (2) I've been working under the assumption that the "stand alone" WiFi throttle system (Engine Driver/WiThrottle) would involve a router and would not be the Arduino acting as an AP. I would certainly not be opposed to a wireless Throttle design using XBee or something like it.
TD I am in agreement, if possible, but as Gregg indicated I'm not certain that the Arduino Ethernet/Wireless shields are capable ...... have not studied XBee but if that would work it would be fantastic .... I may be wrong but I think XBee only communicates with XBee (you need a pair) but a WIfly shield might work as you imagine. Steve
This is actually determined by the program issuing the throttle command, not the Base Station. In the <t> command you specify both speed and direction at the same time. If the current throttle is forward at a speed of 15, you could issue a <t> command with that same speed but in reverse. Or you could first issue a halt. Or any other combination. If it would be helpful, I could add an additional option for the DIRECTION parameter that would simply cause the direction to flip, or be set to forward or reverse at the existing throttle speed. This would be helpful for HHTs that do not ever read the actual throttle responses but instead just issued increase and decrease commands. This new option would allow them to flip the direction without needing to know the current speed.
No, no... I did not mean to mix the wireless throttle (HHT) with the EngineDriver/WiThrottle support over WiFi. Apples and oranges in my head, though I wasn't clear about that in my post. Anyway, what I meant was two separate things... a EngineDriver/WiThrottle server that works on WiFi using an external router (so the Arduino is not an AP), and (completely separately) an XBee-based wireless HHT design that doesn't have anything to do with WiFi or EngineDriver/WiThrottle at all. Although, I suppose with a low enough cost WiFi module, one could build a HHT that uses WiFi and the WiThrottle interface, but provides a buttons-and-knobs UI, rather than using/being a smartphone. That would be yet another completely different implementation, though.
I am attempting to get a Mega+Ethernet+Pololu stack working. I remapped SERIAL_ENABLE_PIN_PROG to 11 because the Ethernet card uses pin 10. I cut the link traces for pin 10 and pin 4 on the Pololu. I wired a jumper for pin 11 to M2PWM. The Ethernet shield is W5100- based. I discovered that the shield does not pass through the IOREF, RESET, (I2C)SCL and (I2C)SDA pins, but I don't think that is the problem. I believe the Ethernet connection to DCC++ is working - JMRI will connect to it. If I issue a Power On command the Pololu does not get activated. If I reconfigure DCC++ to use Serial instead of Ethernet but leave the stack intact, the Pololu board responds normally so it only matters if the Ethernet shield is in use. I think my issue is that the Ethernet shield is still using pins 11-13 even though I thought it would use the 6-pin ICSP header instead for those connections. Ideas?
Exciting times today!!! - Gregg's innovations including increase/decrease throttle commands for rotary encoders and throttle commands sans register. - Distributed Uno/Mega boards still under Gregg's consideration (I'm okay with wired I2C vs a $22 xBee per board) with a simplified sketch. - Jason's great looking HHT that would be a perfect application for an xBee. - The concept of an AR using a distributed $8 Uno clone with clone motor shield (dual AR's?). Please accept my heartfelt gratitude for Gregg and all those who work together in developing this great project.
On a slightly different note regarding Ethernet functionality and library setup of the INTERFACE ... would it be possible to use the a MQTT library -- for example the one from Adafruit? MQTT is light weight messaging protocol that can easily sent and received by any connected device. Adafruit has recently done some significant work in this space ( as has many others) Note: you do not need to use the cloud unless you want to... you can keep the central "broker" local. Using such a library may only be possible on the MEGA given the limitations of the UNO. My thought here is simple, if you wanted to expose the functionality to a larger group, the use of a MQTT solution would provide this without a large structural change if considered now. AS for comments on the need for the register in the <t> command, I believe allowing the base controller to manage would be best. One suggestion would be an explicit command that allow the base controller to know that you are finish with this cab. (e.g. <x cab>) This would allow the base controller release the register back to the pool of unused registers. Paul.
Mike, you've identified at least one issue that I will resolve in the documentation. When using the Pololu with an Uno, we need to cut the Pololu's Prog-Enable connection to pin 10 and establish one for pin 11 instead, since the Uno uses Pin 10 for DCC signal generation. When I created the docs for using the Polulu with a Mega, I figured you might as well save the need for cutting and establishing a new Pin-10 connection, since the Mega does not use Pin 10 for DCC generation. Instead, I recommended you keep the Prog-Enable on Pin 10 and we would re-map it in the software. Last night when I was updating Base Station I was about to add in the logic so that when a Mega is detected the Prog-Enable remains at Pin 10. But then I reviewed your post and realized that my original assumption was incomplete -- even though the Mega does not need Pin 10 for DCC generation, most Ethernet Shield DO use that pin. It is therefore best to always remap the Enable-Prog connection from Pin 10 to Pin 11 whether or not you are using an Uno or a Mega. This means that the Base Station software does not need to be updated, but the documentation and picture of the Pololu when used with a Mega does (and I will do that shortly). But since you've already done this re-mapping on your own board, that can't be the problem. I can't find the schematic on the link you provided but assuming it is a clone of Arduino.cc board, it is likely wired the same. And since it uses a Wiznet 5100, the default Arduino Library should work (are you using the latest version of the master branch I uploaded last night?). Though without seeing the schematics I can't be sure, the Wiznet should be connect to the SPI connector, and not to pins 11, 12, or 13 (though it will be connected to Pin 10). It is the Uno itself that makes the connection back from the SPI pins on its board to pins 11, 12, and 13. On the Mega, the connection is from the SPI bus to pins 50, 51, 52. If the system seems to be working when configured for Serial, and the stack is still assembled, this means the master enable must be working, even though you cut the trace to pin 4 on the Pololu. I assume you kept this in tact on the Ethernet Shield. Base Station needs to drive this pin HIGH to disable the SD-Card on the Ethernet Shield to allow the Wiznet to operate. Is there a way of confirming JMRI is actually talking to the board? Perhaps try out the new config mode to check the IP parameters? -Gregg
I can see the HH Cab progressing to a wireless version, but right now I have just been concentrating on hard wire version. Simple connection. RJ45 jack. Right now I'm only using four pins. +V, Ground, RS485-A and RS485-B for the data buss.
Here is a way to make esp8266 based wifi a access point. https://www.hackster.io/rayburne/esp8266-access-point-using-arduino-ide-19f632
I believe that the WIfly shield from Sparkfun will do the same thing and is configured as a compatible plug in Arduino shield. Steve
Gregg, IIUC on the Pololu we need to cut the trace to pin 10 and map Pololu 10 to Mega 11? BTW am using the file you uploaded last night and have the first loco running with Mega/Pololu/JMRI. Thanks again. Dave
Gregg and gang, My thoughts: About registers, if the BaseStation can use any register with a 0 speed dynamically i don't see a need for any software or throttle to need to know what it is. If the throttle or software is for one train it wont need it, if its for two or more trains the software or throttle should be responsible for its own registers to keep track of witch is witch. The throttle or software has less work to do than the BaseStation does to begin with. When the BaseStation receives a command for a cab address it should reply with the cab address (making the register private instead of public). Maybe the BaseStation should wait 5 or so minutes after a 0 speed before releasing the register just in case the operator needed more coffee. Increase decrease, that would just be making extra work (math, processor cycles) a throttle or software should just send what it wants. A throttle or software will know that it sent but it should read the current reply to check for changes made by another throttle or software and change its self to what was received. Most encoder libraries keep track of the total steps. A throttle or program could be setup for different speed modes forward - zero - reverse or speed + direction. We still send both speed and direction in each<t> command packet so it should be up to the throttle or software how its sent (if it stops first or not). willy - w8one
From what I read I thought the problem for wifi voltage was either the usb port did not send enough amps or the on board 3.3v reg on the uno and mega was not big enough.
I just wanted to give a quick thanks for all the development of the DCC++ system. I set it up myself and it worked wonderfully on the DCC sound trains I inherited from my grandfather. Two month ago I don't know what DCC was and with this system I was able to show my two kids their great grandfathers trains in action. It was quite fun controlling the trains on a peace of straight track I setup in the living room from our ipad using the Arduino base station and JMRI's DCC++ plugin om my MS Surface developed by member if this forum. Thanks. For reference and hardware compatibility here is what I used. UNO clone http://www.ebay.ca/itm/111707200402?_trksid=p2057872.m2749.l2649&ssPageName=STRK:MEBIDX:IT Motor shield http://www.ebay.ca/itm/161276647674?_trksid=p2057872.m2749.l2649&ssPageName=STRK:MEBIDX:IT I have HO dcc sound trains and used a adjustable universal laptop power supply to get the required voltage. Total cost of the DCC setup a shocking 17 dollars Canadian. I already had the power supply and don't know its cost.
Gregg, I am a JMRI newbie so I could be misinterpreting behavior, but if it can't connect to the shield's IP - at least at some level - then you get an error message. I have updated to 1.2.1+ but behavior is the same. Is there a way to monitor commands coming in via Ethernet by echoing them out to the Serial Monitor? I have not modified the Ethernet shield. On the Pololu, the links for pins 4, 10 and 12 are cut. I have a 'board enable' shunt installed to account for the pin 4 link being cut. I have installed a jumper from pin 11 to the M2PWM connection. I have pin 12 jumped to 7 and pin 2 jumped to 8. The only change I needed to make in the 1.2.1+ sketch was the COMM_INTERFACE value. If I compile with COMM_INTERFACE = 0, I can issue the On and Off commands and the Pololu responds. If I compile with COMM_INTERFACE = 1, JMRI connects (or at least appears to) but there is no response to the On and Off commands. I am using JMRI 4.3.2. If I start the Mega with A5 jumpered to GND, DCC++ reports the IP address. @TwinDad - any thoughts? I am beginning to suspect that the problem is not a hardware conflict but is in a software piece. Just can't tell which end, yet. The JMRI Power Control window reports current power state as Unknown. The Traffic Monitor shows a number of Status Cmd lines. If I click the On button in the Power Control window the monitor shows Track Power ON Cmd. I don't see anything the looks like a response message.
Dave, If you are going to add an Ethernet Shield to the stack, that is true. You also will have to create a jumper from pin 11 to the M2PWM connection point on the edge of Pololu board. If you are not going to use an Ethernet Shield you can leave the pin 10 trace alone but you will have to change the value of SIGNAL_ENABLE_PIN_PROG to 10 on line 77 of DCCpp_UNO.h (assuming release 1.2.1+).
