TCP/IP Sockets using the text based protocol, same protocol used for serial connections. The Mobile throttles using WiThrottle protocol would be communicating to JMRI which will internally translate it to the appropriate commands etc for the text based DCC++ protocol. Part of my goal of having the custom PCB (and kits for it) will be to simplify this process for the DIY crowd, same as your goals along that line. In my case though I'm adding LCC as an added bonus to allow the extension of the CS for boosters or a more powerful way to control the layout from JMRI. JMRI would be driving the layout (signals, detection, etc) and also able to control locos all via one logic bus (LCC) and the fact that DCC is being used to send commands to devices is not important to JMRI, it is only relevant to the CS and devices on the DCC side. Yup, makes sense. This is where the ESP32 is superior to the AVR architecture is that it has more memory available and if you don't use outputs/sensors/etc the CS doesn't really spend time on them. In my view the CS shouldn't spend any time on these extras either. It should be offloaded to a purpose built device that deals exclusively with that complexity. In my case I'm moving all of that over to the LCC side which the CS won't be paying any attention to really, there are a couple LCC events that it does care about but most it ignores. The OLED shows current CS status which JMRI doesn't know or display. It is not necessary but is nice to have. There are multiple options, they can communicate via: WiFi (socket text based protocol or http), LCC (CAN or WiFi), S88, LocoNet. In simple terms the CS is just managing the signal generation for the tracks, much like the AVR code does. It exposes many of the same communication options for JMRI but has a few extras which the AVR doesn't offer today (web, sockets, LCC, S88, LocoNet, etc). Sure, feel free to drop a message on here and we can schedule a call or email etc...
GREAT! Let me look into your code some so I don't make a foolf myself by asking obvious questions about what is obvious. I'm retired, so once we get goiung, your schedule will drive all this......it'll take me a few days at least to get ready. Thanks.
If you use the development branch it should have a much better performance than the last release. There is one "breaking" change from 1.2.0 to the version on the development branch in the Config_WiFi.h file so be sure to verify the settings after pulling down the latest version. I've got this on the list of notes for the next release (coming soon!).
I thought I had posted this earlier. I am still working on getting this working reliably. However while I can successfully now read the decoder and program it on the Main. When I try using this with the OPS the system crashes with the following dump and the motor just runs away at full speed. This is with the separate ESP32 dev board and the motorshield. I not have much success with the ESP32 UNO either other than it keeps rebooting, but I have not been able to get useful error from the serial console yet. Any ideas on below? [OPS] RMT Timing: ZERO: 98uS, ONE: 58uS [Loco 6] speed: 10, direction: REV [Loco 6] speed: 26, direction: REV Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception) Debug exception reason: Stack canary watchpoint triggered (thread.00) Core 1 register dump: PC : 0x40081ce0 PS : 0x00060336 A0 : 0x3ffdf040 A1 : 0x3ffdef80 A2 : 0x00000000 A3 : 0x3ffdf234 A4 : 0x00000000 A5 : 0x3f400bc4 A6 : 0x3ffdf420 A7 : 0x00000008 A8 : 0x3ffdf350 A9 : 0x3ffdf030 A10 : 0x3ffdf050 A11 : 0x3ff9c510 A12 : 0x000000ff A13 : 0x0000ff00 A14 : 0x00ff0000 A15 : 0xff000000 SAR : 0x00000019 EXCCAUSE: 0x00000001 EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xffffffff ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000 Backtrace: 0x40081ce0:0x3ffdef80 0x3ffdf03d:0x3ffdf350 0x40114b1e:0x3ffdf3e0 0x400dc8e6:0x3ffdf420 0x400d4e39:0x3ffdf580 0x400d5047:0x3ffdf5a0 0x400d8974:0x3ffdf5c0 0x400d9072:0x3ffdf5e0 0x400d919d:0x3ffdf640 0x400d923e:0x3ffdf670 0x400dc271:0x3ffdf6a0 0x400e756e:0x3ffdf6d0 0x4008ff11:0x3ffdf6f0 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 modeIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:928 ho 0 tail 12 room 4 load:0x40078000,len:9504 load:0x40080400,len:5900 entry 0x40080698 DCC++ESP32 v1.2.5 starting up
Change this line to read: Code: os_thread_create(nullptr, nullptr, 0, 3072, jmriClientHandler, (void *)fd); If you still see failures change it from 3072 to 4096. This is the thread for the JMRI client connection, it is interesting that it is crashing with the default size of 2048. It could mean there is a memory leak somewhere in the code, I'll do some digging but this should help mitigate the issue for now. I'm also going to update the thread name so it is easier to ID it.
Ok I used the value 3072 and the throttle for the first time is working both in the web interface and JRMI. No crashes now. If I set it to 0 instead it crashes and gives them core dump as before. I have run a motor back and forwards for 20mins with any problems. However (as there is always something) it now longer detects the decoder. Either on the main or prog. [PROG] Creating RMT feeder task [PROG] Enabling DCC Signal [PROG] RMT Timing: ZERO: 98uS, ONE: 58uS [PROG 1/3] Attempting to read CV 3 [PROG 1/3] Attempting to verify read of CV 3 as 0
YAH!! I put it in as 4096 on development branch but will lower it after testing a bit (a few changes coming in v1.2.5 still)
Still get some issues with the decoder detection in the development branch. But will wait to until you push out the next version. I notice you committing more changes once it is stable then I will start testing again. Thanks for you help so far. I am going to have a look at the LCC next.
If you can send me details on what you are finding as failing on this piece I can look at improving it. But I don't know that it can be improved too greatly outside of possibly additional retries with the current implementation. One thing that is in the works is RailCom support, this has a few advantages such as automatic detection of locomotives placed on the track without reading CVs! This only works for some decoders today but support is growing. This feature will be optionally enabled as it will cause a few feature combinations to not be supported (RailCom will use one of the two "free" UART interfaces also used by LocoNet, Nextion or HC-12). In addition to RailCom support, there will soon be integrated support for the new TCS WiFi Throttle coming out this fall (already pre-ordered mine yesterday). I don't have any details to share on this work just yet.
Hi Mike, I haven't seen any S88 option in JMRI without using an interface translator to another bus. How do you (plan) manage your S88 data transmit to JMRI ? When I used S88 with your code with a size above 255 but far below 512 bits, a crash occured. Check it before the next release I am waiting for. Thanks for all what you do for us.
They are exposed to JMRI as a standard sensor with a starting index of 512. Any specific number where it crashed? Also do you have a backtrace? I'll be able to do basic testing but I don't have any S88 devices which I can use currently for testing (I've been meaning to setup a set of AVR devices for testing but have been busy with non-train activities and stabilizing other features as S88 hasn't had any changes in a while and was working previously).
But your Sensors ID base starts with 1024 ? It works fine up to 255 bits, above 255 ESP32 is frozen after it told me: Sensor 1028 & 1030 :: inactive. But they were not, they were still active. Any number wider than 8 bits is not welcome. That's why nobody told you this issue because it works fine below 256 sensors and 3 paths. Here is the log: [DCCppESP32.cpp:398] setup(): DCC++ESP32 READY! [Sensors.h:52] set(): Sensor: 1028 :: ACTIVE [Sensors.h:52] set(): Sensor: 1030 :: ACTIVE abort() was called at PC 0x4014d89b on core 1 Backtrace: 0x4008d1cc:0x3ffd8370 0x4008d3fd:0x3ffd8390 0x4014d89b:0x3ffd83b0 0x4014d8e2:0x3ffd83d0 0x4014d1df:0x3ffd83f0 0x4014d2ce:0x3ffd8410 0x400da5e9:0x3ffd8430 0x400da679:0x3ffd8450 0x400da6e3:0x3ffd8480 0x400da85a:0x3ffd84a0 0x400ddc42:0x3ffd84e0 0x4016d9a9:0x3ffd8530 0x400e68b3:0x3ffd8550 0x400e4f65:0x3ffd8590 0x400e4fe1:0x3ffd85e0 0x4014e625:0x3ffd8600 0x4014e66d:0x3ffd8640 0x4014e9ca:0x3ffd8660 0x4008f45d:0x3ffd8690 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) .............. and so on Put it on TODO list, there is no hurry here. I wait for the new release to see if it happens again. When using 255 bits long, display is out of screen. Please put a CRLF there because Action buttons are difficult to reachhhhhhhhhhhhhhhhhhhhhhhhhhh ! Do you think JMRI is able to read your all S88 sensors 10 times per second ? using WiFi.
Ahh, that would depend on the bus ID. It can be a bit confusing for sure, the first sensor for bus 0 would be 512, bus 1 1024, etc... How did you create the bus? Was it through the web interface or through text protocol? I'll do some tests but it should accept any number of sensors from 1 to 512 (or 511 if you count zero as the first sensor). Also the number of buses is not capped at three, it is dependent on the number of free pins which can be higher. But in practical use I'd expect considerably less than 256 sensors on a bus and to have multiple buses. It's on the list I've also got on the list to fix the rendering in the web UI as it is not usable today once you go beyond 30-40 sensors. The v1.1.1 version had it listed as ON (GREEN), OFF (RED) and would break on 16 sensor intervals. I'll be re-adding this back in as the majority of the code is there now to support this with only the custom render callback for the table population code. There should be no issues with this. The sensor data is only sent on demand or if there is a state change on a sensor. I don't believe JMRI is requesting the full sensor list except on startup. JMRI does send <s> every 30 seconds (I believe) but that doesn't include outputs or sensors.
Ahh, that would depend on the bus ID. It can be a bit confusing for sure, the first sensor for bus 0 would be 512, bus 1 1024, etc... The Web interface start with 1 not 0, and 1024. With the Web interface, it works fine. I agree 100 should be enough but the norm is 512. My patched version can have a bug. I wait for a new release because I stopped modifying. Some module are designed for 8 sensors, I'ld choose to break at 8. It is quick and easy to send 64 bytes in a row showing 512 sensor states. Only 12 bytes with 96 sensors. Monitoring a lot of trains needs to be quick. 10 scans per second is a good number. It is my rate wih Arduino.
Yup, that is a bug. I've added the sensor ID base to the UI for creating a bus as well now. The DCC++ protocol is not so "cheap" when it converts the sensor reporting, each sensor results in either: <Q ID> or <q ID> being sent. This is partially why they do not report except for changes. The speed for reporting is dependent on the number of sensors on the longest bus. The scans are currently set to have a delay of 50ms between iterations, it may be slightly longer than this between runs if there is another task that is running at the time. I'm not sure what all you might have patched, the code today supports up to 512 sensors on a bus and no modifications should be required. The development branch now has this update to split on groups of eight.
I included my own S88 routine in DCCpp for Arduino and don't use any sensors option. Yes, but you must have 2 tasks, one reads the S88 bus to feed a buffer, another replies to data requests. It is much faster.
There is in fact a task dedicated to just S88 polling, it passes off any updates for sensors and if they change state they then broadcast the change to all listeners (connections). It is pretty quick generally. Ahh, what did you use instead? Is it just pulling data to the CS side and doing processing there?
That's what I saw on the console repport. Yes I dump a block of 64 bytes on USB to the PC in less than 20ms with a rate of 10Hz. Link occupancy < 20%, it is fine. As I only use 8 bytes for my layout I drop downto 3%. ESP32 with 2 S88 buses of 32 sensors will save cable length because S88 is a daisy chain bus.
I just got my first ESP32 development board, and I'm trying to come to grip with pinout definitions vs edge connector definitions. Even with an Arduino, I'd have to correct errors much too often. I've got the blink code running(from the examples in the ESP32 part, so it fades instead of blinks), so the next step is to get your code to compile from the Arduino IDE.......I looked at platform I/O, and I really don't quite feel the need for all that debugging stuff, or to spend the horrendous amount of time it would take ME to learn the environment, so I need to stay with what I feel comfortable with. Once that's done, I'll do a deep dive into your code and hopefully see where I need to change things to accomplish what I want to do. Rememeber, my goal is to have the remote boards that drive the IBT-2 modules do the overcurrent/short/reversing functions, so as far as that's concerned, all they'll need is the DCC signal and an enable signal to each, and no current feedback to the CS. I don't know much about how much resources you use as far as available pins, but adding what I need seems trivial. I'd like to leave all your code there, just add some modules with compile time switches to add what's required. Even if your design is short on available pins, adding some simple multiplexing or shift registers could easily be added as an option, as long as the pins required could be connected to any required external simple HW to implement the extra power districts. So, I'm still here, and ready to start.......one basic question, please. I saw mention of FreeRTOS being used with the ESP32.......is that a requirement? I used FreeRTOS on an uncompleted project with an Arduino, and except for the gross timings(minimum of 15ms tick to switch tasks), it was easy to use in my simplistic way. I was able to achieve much faster context switching(less than 100usec) between tasks. I used FreeRTOS simple because initially I decided that trying to combine what was originally running on 3 separate Arduino modules would be easier than tying to combine the multiple state machines that were used in the operation. It turns out that after I finished the FreeRTOS work, the result allowed me to do the combination into one Arduino program(I refuse to call my work sketches!). When I scanned your code I didn't see any FreeRTOS references, but I wasn't specifically looking for any.
I guess I'll HAVE to learn platform..... Just what parts do I need to install? I don't know what parts I need to install, and I get more crap installed than needed.
