ESP32 Command Station

Atani Dec 10, 2017

  1. Shdwdrgn

    Shdwdrgn TrainBoard Member

    251
    182
    13
    Ah I think it's going now... figured out the problem on my end, when I pulled the new code it was done as root so I didn't have permissions to save the file changes. Got past the Nextion issues, but now getting an error on InfoScreen.cpp:83 - invalid conversion from const uint8_t* to const char* (this is the dev branch).
     
  2. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    I'm not sure what could be wrong other than wrong OLED library. Since you are not using PlatformIO it is critical that you pick the right libraries and versions, make sure you are using this one: https://github.com/ThingPulse/esp8266-oled-ssd1306/releases/tag/4.0.0
     
  3. Shdwdrgn

    Shdwdrgn TrainBoard Member

    251
    182
    13
    Ugh it looks like they changed the library? The last time I compiled the code was in January, but it was working fine then. Wonder how that's going to affect my other projects that are using the esp32-oled board? This should be fun...
     
  4. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    there shouldn't be many changes required, i have been using this latest version since the beginning and haven't seen any issues on here or the esp8266.
     
  5. Shdwdrgn

    Shdwdrgn TrainBoard Member

    251
    182
    13
    Woo! Back up and running with the latest dev code. The new web interface looks great!
     
  6. Duesselklaus

    Duesselklaus New Member

    9
    0
    1
    All questions resolved now and the ESP32 is running fine. Presented it last weekend at the RocRail users meeting resulting in a discussion on how to benefit from the WiFi interface. My personal idea: I would like to build the DCC++ station into the loco and supply the DCC signal directly into the loco-decoder (don't want to scap the expensive, high performance ESU sound decoders though). Preferraby using ESP8266 instead of ESP32, because its smaller. Don't need the second PROG track output in this setup. May this be my wish for Christmas? :)

    ... I didn't recognize the direction.

    With a new module no BrownOut detection is triggered any more. The "old" board seems to have a poor voltage regulator on.

    The new one came with a HELTEC OLED display, but unfortunately I'm now running into the same trap as already posted: "invalid conversion from 'const char*' to 'const uint8_t* {aka const unsigned char*}' [-fpermissive]. ... oledDisplay.setFont(Monospaced_plain_10);". I already checked. The only library installed for SH1306 is the version "esp8266-oled-ssd1306/releases/tag/4.0.0". Actually I have no idea how to resolve this problem. Obviously Shdwdrgn resolved the issue. Can you please describe how?

    Thanks!!!!
     
  7. Shdwdrgn

    Shdwdrgn TrainBoard Member

    251
    182
    13
    There is an option for a half-size ESP32. This board also uses an external antenna which may be helpful to locate it away from large weights, but otherwise appears to have all the functionality of the full-size ESP32.

    @Atani: Not sure if this is a bug or a change in functionality, but I was playing with the dev code branch through telnet commands last night and noticed when I issue w or b writes it no longer echoes back a confirmation that the code was received. I do still get results back from commands for track power and throttle though (these were all done on the main track).
     
  8. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    It looks like the code on master is broken by this release version of the OLED library, a simple fix though.. https://github.com/atanisoft/DCCppESP32/commit/2c34345350ed043dda31a3ba2f49fce971b00967 I'll get this backported to master soon.

    I'm not sure that "w" or "b" has ever responded, even on the Arduino side. These are for the MAIN track write CV byte and bit operations. I know the PROG track equivalent (W and B) do respond though.
     
  9. Shdwdrgn

    Shdwdrgn TrainBoard Member

    251
    182
    13
    Yeah they did on version 1.0.0, which I was using earlier this week when I programmed a new loco decoder (basically the same command echoed back). With the new wifi interface I decided to give my locos full 4-digit addresses, and thought something was wrong because I wasn't receiving the feedback, however after I finished setting the CVs the locos do respond to the new addresses. Ah well, I'll compare the code later when I get a chance. For all I can remember, I may have added the reply code myself when I was troubleshooting why those commands didn't work on main.
     
  10. John Holdsworth

    John Holdsworth TrainBoard Member

    21
    4
    6
    Not exactly on topic.. but have a look at the Internet Of Lego site : http://www.internetoflego.com/lego-train-automation-wifi-controlled-nodemcu-esp8266/

    Perhaps a different approach should/could be taken.. this one uses Node Red to link web based controller to web based Loco..and has the potential for MQTT broker access too. Perhaps a better route to "directly" controlled trains..bringing in the power of home automation tools.

    regards JH
     
    Atani likes this.
  11. Duesselklaus

    Duesselklaus New Member

    9
    0
    1
    THANKS !!! That did it! My DCC++-ESP32-OLED is running now. I am looking forward a loooong weekend!

    I did a similar approach last year for the RocRail Users Meeting: An ESP8266 with RocNetNode and MQTT client. RocRail directly supports writing the commands to the MQTT broker. All has Pros and Cons...

    The main question for discussion is: What does the DCC++ controller do if it temporarily loses power or WiFi connection? Does it store the loco speed settings and recover? And what happens if WiFi connection is permanently broken? Shall it send a stop command after some seconds? Is there the need to extend DCC++ protocoll by a handshake/watchdog? Or maybe route the commands via an MQTT broker for recover purposes?
     
  12. John Holdsworth

    John Holdsworth TrainBoard Member

    21
    4
    6
    The issue of MQTT broker is an intetesting one..if your going to have a centralised software ekement why not something like a dcc++ controllers. While MQTT has lots of standards orientated benefits is it entirely appropriate... with its ability to have peer level entities its intetesting but does that have any relevance in model railways?

    I suppose the issues of what happens when coms are lost have been addressed by iot/home automation to an extent..but again are they entirely adequate in an environment when brief power loses are common( eg dirty track)..perhaps superCs would help address this issue.

    At the moment I'm grapoling with platformio..currently heading for it winning by two submissions rather than a knock out

    Thanks for your efgorts and responses
    JH

    Sent from my CLT-L29 using Tapatalk
     
  13. John Holdsworth

    John Holdsworth TrainBoard Member

    21
    4
    6
    Im no expert in dcc stuff..but it strikes me after very little experience that the overall system.doesn't automatically inventory the layout/points/signals locos etc..surely for example building a track diagram could be made a lot easier if it did?..hence this would call for greater intelligence in the electronics associated with all these bits?

    Don't really know but i used to work for a company that sold a network management system with a realtime updated centralised database at its core..made adding intelligence on top of the network much easier and resulted in a flexible and comprehensive solution..that was before ip itis over took the world..eg route (connection) planning automation

    Dont know probably avstep too far..and ive no idea how things like rocrail work

    Regards JH

    Sent from my CLT-L29 using Tapatalk
     
  14. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    If it looses power it restarts as a fresh boot up, nothing can be done about this currently. WiFi outages should be automatically recovered.

    No, they are not stored outside of memory.

    the base station won't start up currently, it will end up in an endless reboot loop until it can establish network connectivity. There was a request to have it fallback to starting up a soft AP but I haven't had a chance to set that up yet.

    as long as power to track is ON it will continue sending packets.

    I don't think this is necessary but perhaps in your usage it would make sense to have some sort of additional checking that would shutdown the base station if certain conditions are not met.

    That is an option but would complicate the base station considerably. If you want to implement such a mechanism I'd be happy to review it for possible inclusion.

    you can try this: http://udelmas.e-monsite.com/pages/centrale-dcc-wifi-d17.html I haven't looked at it in depth but I have seen a WeMos D1 board that did emit DCC packets and connect to a motor shield.
     
  15. Shdwdrgn

    Shdwdrgn TrainBoard Member

    251
    182
    13
    After playing with the new web page code this week I have some issues I wanted to point out. First off, the web page allows throttle settings up to 128, however if you set it to 127 or 128 the loco stops. This seems to follow the DCC++ command page, which states that throttle settings should be in the range of 0-126.

    The throttle itself could stand to be a bit bigger. When trying to run it from a cell phone it's impossible to slowly run up the speed. Also if you hold your finger on the throttle control, chrome is now popping up a right-click menu and you have to stop and clear that. This didn't happen on the old code.

    I realize the web code is still in progress so I would guess creating a list of locos and not having to re-type them every time is one of those things still to come. And while it is nice that power is automatically turned on to the track when you connect to the web interface, it would also be helpful to still have an option to turn the power off again. Otherwise the dev code branch seems to be working great!
     
  16. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    For the loco list you will need to define a roster. Power can be managed on the base station status tab, perhaps having a pop-up for it on the throttle makes sense though, I'll see if I can create one.

    I'll need to check the speed settings, I remember something about those but it used to work. Must be something simple that is off.

    Sent from my ONEPLUS A5010 using Tapatalk
     
  17. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    A quick review of NMRA S-9.2 confirms you are right! I forgot to set a cap of 126 (127 steps as zero is a step). I'll be adjusting this shortly to cap at 126. The reason 127 or 128 stop the loco is that the DCC packet ends up as speed step zero or emergency stop due to 7bit data type rollover.

    it should auto resize for the screen, it is designed with mobile in mind. I'll do some more testing and see if i can increase the size a bit on the throttle. I couldn't find a vertical slider otherwise I would have used that with functions / buttons to the right of it. I may need to create my own vertical slider...

    I haven't seen this but I'll see if I can figure something out with long hold events but it is likely a bug in jQueryMobile. I'm not 100% set on jQM, it just seemed like a good fit as it is relatively light weight and has only a few dependencies. By using jQM I was able to cut the size of the HTML code considerably while still retaining the same functionality.

    I'll need to add some documentation to the Wiki soon for this as it should be relatively simple to setup the roster. The easiest way to setup the roster is Base Station -> Programmer -> Identify Address. This is still a WIP and may not successfully identify the address of the loco on the programming track, Pololu motor shields currently are problematic. If this doesn't identify the decoder successfully you can create roster entries via Base Station -> Roster and these will show up when you click the Acquire Locomotive button on the Throttle.
     
  18. Shdwdrgn

    Shdwdrgn TrainBoard Member

    251
    182
    13
    Part of the problem is likely that I simply don't know where to find everything, and having everything as parts of two separate tabs kinda makes it a bit more confusing. Since the space is already being used, maybe it would make more sense to create more tabs at the top for direct access to specific features? For example, if you were actually using this as a throttle during operations you would need instant access to the turnouts rather than switching tabs and then scrolling down. I was also thinking about the function group at the bottom of the throttle... again instead of scrolling down, what about having a few of the important ones at the bottom, then using CSS to bring up a small window when you tap a button? Ideally you would want to eliminate all scrolling on every page since scrolling is a real pain on mobile, but that'll take quite a bit of rearranging to accomplish.

    Once we get through the holiday season I'll have more time and will try to throw together a mock-up of what I'm thinking. Oh and I did a quick check on vertical sliders, it seems the standard method is to use a transform:rotate in CSS, then you can use the built-in methods. Which gives me another idea for the future... define each section as a block ID and it would allow for easy theming and moving things around to suit individual users?
     
  19. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Yeah, it is a bit of a change. The second tab is not intended for use during operating sessions entirely as the major functions should be on the first page.

    I'd rather not expose more features on the top as tab but I'm open to adding a button for turnout/accessories control on the throttle page as that does make sense.

    It is in a collapsible section for this reason now. I originally had it setup as a few sections and didn't like how it looked on mobile so I switched to keeping F0-F8 exposed always and dropping the less used functions into the collapsed section. All collapsible sections are tap to open/close (even the headings on the base station tab are this way!)

    Yes, scrolling etc is a pain on all devices really. I'd like to have it as simple as possible for usability and it is not quite there yet but it is getting closer.

    a working example: http://jsfiddle.net/iancboswell/eM7Rh/ I just haven't dug into it yet but moving from horizontal to vertical will give a bit more room for various options to the side of it. The main problem I have with this is the size of the JS code is considerable. I may be able to stash it away on github and reference it from the html code so we can offload it from the ESP.

    I'd love to explore this but jQM doesn't appear to support jQUI draggable objects by default, but can possibly be made to work with jQUI components brought in: https://stackoverflow.com/questions/10693143/how-make-draggable-li-element-with-jquerymobile

    I'd certainly be interested in having something from that working here but I'm unsure how it would work with jQM entirely.
     
  20. Shdwdrgn

    Shdwdrgn TrainBoard Member

    251
    182
    13
    Wow the JQ code block really is huge. I like my CSS solution a lot better! :) I guess the real question should be are you coding for ALL browsers, or just focusing on ones that support HTML5?

    Speaking of JQ, why IS there jquery in this code? I could understand previously for generating the speedometer, but the new web page all seems to be pretty straightforward stuff that could be handled by HTML5 and some bare javascript.

    Regarding the dragable objects, that wasn't quite what I meant. Especially for mobile viewing, I wouldn't expect a dragable interface. I was just suggesting that different themes could be made via CSS and a framework html file.
     

Share This Page