No problem. Glad that you have a working system, it is still odd that it is not working as expected without the flash clearing. Perhaps something is broken then, it should respond to double click events (or double tap usually) on the radio buttons. This is not ideal and I think the proper solution would be one where you click a radio button and click "change loco" which give the option of "Release loco" (shutdown decoder) or "Idle loco" (keep decoder on, sounds playing if supported). The complexity of JMRI is mindboggling. There are a lot of moving parts and I find that usually leads to problems. Working on it The web interface needs a bit of work to make it work a bit more ideally but it is mostly functional today. Very true, this leads to the solution I have been considering which is a custom ESP32 board with everything built on board (pair of BTS7960s, OLED/LCD, IPEX connected antenna, SD Card, S88-n port, LocoNet port, etc). But the problem with that so far is I would need to design the PCB, manufacture the PCB and get all of the parts on hand to assemble/test it. I am just not 100% sure that it is something people would be willing to purchase (at just above cost). Also the availability of the components and a handful of jumper connectors makes it relatively easy to setup without having to design everything from scratch. As for adding roster support without the SD storage... Technically yes it can be done if SPIFFS is leveraged instead but this has an inherent cost associated with it. Any SPIFFS/NVS access requires that we shutdown the DCC signal output for the duration of the access, if we don't do this we will have Guru Meditation errors thrown and the ESP32 will reboot. If we limit the accesses like we do today for NVS it may not be a huge problem, today the only access is during startup before the DCC signal gets turned on and if you trigger a config store/clear (via web, <E> or <e>). The duration of the DCC signal outage would be short and can very likely be planned for so you can avoid these actions during operating sessions etc. We could also send an eStop packet out on DCC prior to shutdown of the signal. I have been looking at implementing a Z21 interface for the base station. I haven't gotten very far yet but it is in progress. Thanks! Glad that it is going in the right direction. I am aiming to make a solution that fits multiple needs and options while preserving compatibility and simplicity wherever possible.
Has anyone tried a Pololu MC33926 shield on the DCC++32 yet? I just received and tested one with an Arduino UNO DCC++ and it appears to work fine. I am using this ESP-32S development board: https://www.amazon.com/gp/product/B0718T232Z I think I got the pins mapped correctly, but I want to make sure before I smoke something (on the board, that is).
It hasn't been specifically tested but it should work fine. It has similar connections and features of the Arduino shield. Double check your wires before powering up and it should all go well. If you can send me some pictures and list of your connections I can put it on the wiki and if we need a new define for the shield I can add that as well. Sent from my ONEPLUS A5010 using Tapatalk
I tried the following connections, and it did not work with neither the Master nor the Development versions: MOTORBOARD_ENABLE_PIN_MAIN - M1PWM & nD2 - GPIO25 (I tried with and without nD2 connected) DCC_SIGNAL_PIN_OPERATIONS - M1DIR - GPIO19 MOTORBOARD_ENABLE_PIN_PROG - M2PWM - GPIO23 DCC_SIGNAL_PIN_PROGRAMMING - M2DIR - GPIO18 MOTORBOARD_CURRENT_SENSE_MAIN - M1FB - GPIO36 MOTORBOARD_CURRENT_SENSE_PROG - M2FB - GPIO39 I don't have a scope, so I can't tell if I am getting signal out of the ESP32. The shield is supposed to work with 3.3V logic. I used the ARDUINO_SHIELD current parameters which should have been conservative for this board.
From this picture: https://www.pololu.com/product/2503#lightbox-picture0J4011 your connections seem right. Do the LED lights on the board turn on when you enable track power? You may need to cut traces and add jumpers as listed here as well: https://github.com/DccPlusPlus/Documentation/blob/master/Motor Shield Pin Mappings.pdf Also there is a define for POLOLU but it uses the same as the Arduino setup, you can alter MotorboardManager::registerBoard() to the following and get the 3A support for this board: Code: GenericMotorBoard * MotorBoardManager::registerBoard(adc1_channel_t sensePin, uint8_t enablePin, MOTOR_BOARD_TYPE type, String name) { GenericMotorBoard *board; switch(type) { case ARDUINO_SHIELD: board = new GenericMotorBoard(sensePin, enablePin, 980, 2000, name); break; case POLOLU: board = new GenericMotorBoard(sensePin, enablePin, 2550, 3000, name); break; case BTS7960B_5A: board = new GenericMotorBoard(sensePin, enablePin, 5000, 43000, name); break; case BTS7960B_10A: board = new GenericMotorBoard(sensePin, enablePin, 10000, 43000, name); break; } motorBoards.add(board); return board; } This will cut the power at around 85% of max power output (2.55A) which is inline with the Arduino shield settings IIRC. This will go in on the development branch soon..
I needed to provide 3.3V to the VDD pin. I had assumed that the shield provided power to its own logic circuits. I learned otherwise ONCE I READ THE MANUAL. So here is the complete wiring table: MOTORBOARD_ENABLE_PIN_MAIN - M1PWM & nD2 - GPIO25 DCC_SIGNAL_PIN_OPERATIONS - M1DIR - GPIO19 MOTORBOARD_ENABLE_PIN_PROG - M2PWM - GPIO23 DCC_SIGNAL_PIN_PROGRAMMING - M2DIR - GPIO18 MOTORBOARD_CURRENT_SENSE_MAIN - M1FB - GPIO36 MOTORBOARD_CURRENT_SENSE_PROG - M2FB - GPIO39 GND - GND VDD - 3.3V I'll try to make a pretty diagram sometime now that I got it working.
I am using JMRI Panel Pro 4.10 to test DCC++32. Although I am able to set and read sensors using the tables and layout panel, the throttle functions do not work. The throttle panel's power button does not work, let alone any of the other functions. I am monitoring the Ethernet and serial connections to the ESP32 and no commands appear to be sent from JMRI. Has anyone else had luck using JMRI? It works fine with DCC++ over a serial port.
You will need to be using the latest development version for it to work properly. At least 4.11.1 as there are fixes specific to the ESP32 base station. Also start with DecoderPro and enable the traffic monitor to confirm that it is not complaining about various packet outputs, you can ignore the unrecognized responses for the commands JMRI is sending to the base station as the base station is just echoing them back to all connected clients and JMRI doesn't ignore these today. I will be adjusting the base station code to not echo these to the client that sent them in one of my next updates.
Also @Dan Worth, the <RS> command fixes you submitted are now present on the development branch. Let me know if there are any further issues on it from your tests.
Sorry to be such a pain, but I installed version 4.11.3 on my PC and I still have the same behavior. I open a serial monitor in Code and also the DCC++ traffic monitor. I have one sensor defined (GPIO 4) which shows up in the sensor table and shows the proper status and traffic as I activate the pin. The keep alive from JMRI shows up as well. I then open a new throttle, set the DCC address to 4, power up and turn on the light. None of these commands show up in the serial monitor nor the DCC++ traffic monitor although they work via a telnet connection manually. The keep alive <s> command continues to operate on JMRI I used the same sequence with a Arduino DCC++ system on a serial interface and that works fine.
I'll give JMRI a go and see if I can figure it out. It was working previously. They have done some refactoring of the code recently so it is possible they broke it somehow. Open up the web interface in a browser, go to the base station status tab and click to connect there. That will give you the raw console output. JMRI hides anything it doesn't understand. It is also possible that JMRI is not sending valid commands to the base station now. One difference between the esp32 and Arduino versions is in the requirement for a space after the command ID, the Arduino ignores it if it is there and JMRI was sending it previously. Sent from my ONEPLUS A5010 using Tapatalk
NVM. I deleted the configuration and created a new one. Everything now works! I really didn't want to start digging into the JMRI code. That is why I started fooling with DCC++ in the first place.
Excellent! JMRI is nice but it can be a huge pain at times. Especially with DecoderPro, it switches to internal mode and doesn't go back to DCC++ as you might expect. It doesn't always do that though. Glad that you got it working now. Let me know if you encounter any oddities with it. I need to go through the JMRI code and see if there are any areas that still need fixing for DCC++ (Arduino or esp32 variants). Sent from my ONEPLUS A5010 using Tapatalk
I created a diagram and table of my connections. Here is link to the .pdf version https://drive.google.com/open?id=1uECTdp9HjW-MCCuT9pcMKqjTMbo5HmTI And to a .jpg https://drive.google.com/open?id=1gDbKVnRcHxxqOXwq75nobGItr86ez9PM You are welcome to copy and use as you see fit.
Thanks! It looks like a great diagram and is perfect for what we need to get on the Wiki. It will go up on the Wiki today after I get my morning workout complete and get some breakfast.
I’m thinking of trying a development board called a “TTGO T8 ESP32” (Sometimes T-eight). It seems to have at least an antenna connector and an SD/TF card slot. There is also a variant of this board with an OLED screen out there. Pair it with a protoshield and it would be pretty close to your ideal hardware without any need for custom PCB.
I started looking at what you call LilyGO-esp32-uno in your github docs (aka the Wemos D2 R32 or the ESPuino). It looks like the following remappings would need to occur in the DCC++32 code in order to use a Pololu shield that had been modified to use with DCC++. MOTORBOARD_ENABLE_PIN_MAIN GPIO13 (this would also be jumpered to nD2) DCC_SIGNAL_PIN_OPERATIONS GPIO14 MOTORBOARD_ENABLE_PIN_PROG GPIO23 (or GPIO5 if not cut and jumpered) DCC_SIGNAL_PIN_PROGRAMMING GPIO12 MOTORBOARD_CURRENT_SENSE_MAIN GPIO39 MOTORBOARD_CURRENT_SENSE_PROG GPIO36 Actually GPIO23 would remain the same. And GPIO12 might have to be mapped somewhere else since it is used by flash. I will probably make an adapter board for my HiLetgo (same as the esp32-dev in your docs) to simulate at ESPino test this out. I would also need to change my diagram to match the new mappings.
I've been working lately on re-coding one of the NMRA accessory decoder sketches to provide 16 direct outputs plus work with the PCA9685 PWM board to control either 16 or 32 servo motors. Should be ready soon, I just have to dig up a 5V power supply for the servos to test the current code and see if I broke anything. In the meantime I've also been researching into S88 and getting some parts ordered to play with that. Rudy's code looks like a great place to start, except I have no idea how to wire this back to the ESP32 base station. I checked the wiki but couldn't find any info about S88 there. Has anything been posted? I'm also curious about how I would check or monitor changes to the S88 sensors from within a telnet session, or if there is a different way to confirm that the sensors are being read?
Sorry, it is not on the Wiki yet. The default pins are listed in Config.h for Clock, Reset and Load. The data pin is defined when you define the S88 bus at runtime. So, to connect your ESP32 to an S88 node (based on Rudy's code): NAME: ESP32 -> Arduino S88 CLOCK: 17 -> 2 LOAD/PS: 27 -> 3 DATA: 15 -> 13 VCC: 5V -> 5V GND: GND -> GND The S88 reset pin (16) is not connected to the Arduino S88 nodes as Rudy's code doesn't use it. After the above connections have been made you will need to create the S88 bus on the base station, there are two ways to do this: 1) via the web interface on the Sensors (S88) tab. 2) via telnet to the base station network port and send: <S88 0 15 16> Note the last parameter on the command in #2 is the number of sensors on the bus, as you add more Arduino nodes you should resend this command to add the extra sensors, or use the web interface to update the existing bus. These will end up showing up in JMRI as standard sensors via <s> and will trigger <q ID> or <Q ID> as appropriate.
Thanks, that should be plenty to get me started with it. I figured once I can get the servos controlling my turnouts and add some block detection on the test loop then I'll be ready to get back to writing some code to allow a train to run itself. Should be fun, but I probably won't get too much done over the Summer months.
