ESP32 Command Station

Atani Dec 10, 2017

  1. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    We all get busy, it is normal :)

    Ok, this is a problem. You need to tell it how many sensors are on the S88 bus otherwise it will not know how many to expect in the data packets and sensors will be missed. This also is likely why the web is failing after creation. I'll adjust the defaults to set it to a minimum of 8 sensors on the S88 bus, you should be able to edit the sensor bus via the web to reset the sensor count. Also be careful on using GPIO 12 as most modules have a pull-down resistor on that pin and it could lead to false readings. There are a few pins which will be rejected by the CS, you can see a collection of them here. Some pins are rejected as bootstrap pins and others since they are used for various modules (when enabled).

    I haven't used that decoder but it should work fine as long as the signal is reaching the tracks, more on this a bit further down.

    JMRI support is very limited and will no longer be recommended starting with v1.5.0 and will be removed sometime after v1.5.0. There are a number of reasons for this but the biggest is that there is a much more capable protocol available in the CS and JMRI already supports it (LCC). The only piece that is needed to enable this is turn on the LCC hub option via the web interface and configure the connection type in JMRI. I'll have more documentation on this once v1.5.0 is ready to go.

    As for the web interface, it should automatically refresh after ~30sec. I'll check into this further as it looks like there may be a bug here still since the recent refactoring of the h-bridge monitoring code.

    This is the safest way to test with the development branch currently. I'm actively working on stability fixes and a few performance fixes currently while still tracking a few bugs introduced recently. In my testing I have seen the DCC signal at least reaching the tracks correctly, at least with the L298 h-bridge shields. I have a few other h-bridges to test with, including the PCB with the LMD18200 on board. There was a rather ugly bug in the DCC code introduced on April 2nd and fixed on April 8th where only one DCC packet would be transmitted to the tracks and the encoder would shutdown.

    Very likely yes it is related *IF* they are connected to the rails to receive the DCC signal which is one of many ways to connect accessories to the DCC bus.

    Not sure what to suggest on that unfortunately, it sounds like there is something not quite right with the decoders (component broken perhaps?).

    The development branch is mostly stable but there are definitely bugs to be fixed still. I'm working on test cases for each area to ensure it is as close to 100% tested as possible. If I could have automated unit tests I would set that up and trigger it via GitHub Actions but I don't know of any ESP32 SoC simulator which can be used for this purpose.

    Was your clone during the April 2-8th timeframe? If so, please refresh as it may fix a few of the issues.
     
  2. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Thank you for all the answers.

    I've tried that and it didn't help:
    Code:
    [S88 Bus-0] Created using data pin 13 with 8 sensors starting at id 512
    [S88] Sensor(512) created with index 0
    [S88] Sensor(513) created with index 1
    [S88] Sensor(514) created with index 2
    [S88] Sensor(515) created with index 3
    [S88] Sensor(516) created with index 4
    [S88] Sensor(517) created with index 5
    [S88] Sensor(518) created with index 6
    [S88] Sensor(519) created with index 7
    so I am still getting these alerts: `Failed to load url: parsererror`, but apparently when trying further I found out when I set the S88 sensor again (no matter the settings, so even 0 sensors or wrong data-pin will do) the power to my tracks is turned on (unfortunately had to do it after each ESP32 restart). It could be that when there is something wrong in the S88 table it breaks some stuff but because I am not seeing anything in the web interface I am not sure what that could be. Also, when I erased the whole ESP32 memory and flashed over again I still had to first add in some S88 sensor on each ESP32 start for the tracks as well as accessories to get some power (having it all on one bus).

    Then another re-flash with no memory erase and it started working from scratch again. That's weird, no idea what I was doing wrong but still suspect it has something to do with the S88 settings.

    Unfortunately turnouts still don't work for some reason but my engine does :). At least Function keys work - speed does not seem to do anything (I don't even see anything for that in the web dev console). It works through JMRI though and I can see respective logs on the serial output of the ESP32 when running through JMRI:
    Code:
    [DCC++ loco 1] Set speed to 55
    I hope not. These are still quite new. I am actually building my very first and so far very small layout and these decoders have barely been used. Also, they seem to work just fine with v1.2.3.

    It should be the very latest one: 19adca6
     
  3. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Likely it is the data coming back from the CS is not properly formatted, I'll go through it and confirm that.

    Huh, that doesn't sound entirely right! The S88 side may be lost on restart (will check!) but there should be no connection between the tracks and S88 unless the pins are being reused incorrectly which should be caught by the build script validations.

    Entirely possible. The S88 code is going to be cleaned up a bit more so it doesn't create it's own background task to poll the sensors and instead hook into the main task to be polled a few times per second.

    Progress! I'll put it down on the TODO list to check what is up with turnouts as they were working previously...

    Both functions and speed are set from the web via the websocket, look for the /ws connection and you should see the packets in the data stream there.

    That is good at least but if it doesn't make it to the track then something is not quite right. I'll need to confirm what is going on here.

    If they work with v1.2.3 that means they should work with v1.5.0 once I sort out the turnout interactions (Again).
     
  4. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Oh no, my engine did run when I controlled it via JMRI. Sorry for the confusion. Also, I have just retried and the Web interface throttle does work. Sorry about that. Could have been some JS/browser's glitch as that was definitely client side (not making any "WS" calls).

    Anyway, thank you very much for all the replies :).
     
    Atani likes this.
  5. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    It is still weird though as I was back in the no power in tracks state for a while. This time not even changing S88 settings seems to have worked. Really weird the behaviors changes like this. Another thing I've just noticed is that the state of the OPS track doesn't reflect in the Web Interface and there is no way to turn the programming track on in there as the button to make that on/off is missing in the PROG line.
     
  6. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Ok Great! Glad that that is working at least! I'll still dig into the web throttle as there may be still some bugs in there preventing it from working all the time.

    Is that in JMRI or the web?

    That is intentional, the CS manages the PROG track being active/inactive internally when it is needed. The ability to control the PROG track when it is not in active use is not compliant with the NMRA DCC specification, there have been a few other adjustments in this area to be closer to compliance with NMRA specs.
     
    zubozrout likes this.
  7. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    It was on the web. But now it just miraculously works again. I wonder if it could be somehow related to my power source perhaps as that would make more sense but I've never seen it behave like that before and still the ESP32 itself works (being powered via the same source). And I did try two different power sources but both could be flawed.

    Ah, awesome :). Thank you for the explanation.

    Also sorry about my on-top edits to my previous post. I've updated it a bit since I first posted that as I didn't want to flood it in here even more than I already do.
     
  8. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    I did find a possible bug in the h-bridge code related to tracking it's status that might lead to it advertising incorrectly that it is OFF etc. I'll be pushing that update once I complete testing.

    I don't think I even noticed that you edited it other than getting a couple extra emails on it. It's all good though.

    Found the reason for this error and will have a fix for it soon. The json payload being sent from the CS was slightly malformed (extra comma after last entry in the list), I had fixed this for turnouts but missed it on outputs, remote sensors and s88 sensors.
     
    zubozrout likes this.
  9. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Hi,
    I've just tried using the feature of my MP1 turnout decoders that sets a new address for it when certain pins are connected with a jumper just to try this and have been able to make a group of 3 out of 5 connected decoders + the 5th decoded "operate" with a very weird behaviour.

    It has started with a single decoder running the motor for me when I connected the two pins. But unfortunately it only turned one way, not back. When I tried to use a jumper on a second decoder, then that made the connected turnout move in one direction, while the first decoder switched back. In the end this group switches one way when trying to address decoder with a certain address ID and the other way when trying to use another ID. Later on, when trying out on a group of 5 switches I ended up with 3 switches in total that move at the same time but always in only one direction on ID 2 and another direction on ID 3. The switch with address ID 1 gave up for me on this after switching one way, so it won't move back. And the switch with ID 5 (I guess, maybe it is 4) goes one way on ID 4 and back on ID 5.

    Anyway, this really is weird. I've tried using all 3 possible ways to do this - mainly the web interface, but also JRMI and JRMI + LCC. And logs doesn't say anything interesting other than the turnouts were switched.

    I wonder if addressing has changed somehow. All my decoders were set up to work with IDs 1 to 5 in the older DCCppESP32 revision I had installed previously. These didn't work now unlit I tried the above experiment ^ but that suggests that ID 1 to 5 is not the same as previously, or something related I don't understand must have changed. It also seems that switching one way may be different to switching back, maybe changing the id by one or something like that. Or could the signal be noisy making it difficult for the decoders to understand it?
     
  10. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Also, sorry for me mixing IDs and addresses. In all instances I meant addresses (1 to 5). IDs are afaik only a local representation of each turnout and unrelated to the actual functionality. Anyway, in my case they match the addresses so my turnout with id. 1 has an address: 1 etc ...
     
  11. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    There have been a number of changes throughout the lifespan of ESP32 CS, the biggest being an emphasis on the DCC address of the turnout instead of the auto-assigned ID. The ID is not very meaningful outside of just an index into the array of known turnouts and a bit of a legacy item from the DCC++ support. If you create the turnouts via the web interface you should be able to create them simply with DCC addresses 1-5 and it should just work.

    Can you check the serial console to ensure the turnouts are in fact being listed as thrown? (note turn on verbose logging via menuconfig under turnouts)

    EDIT: I've added an option to dump the DCC packet data sent to the decoder, you will need to use menuconfig to turn on the verbose logging option for it to print anything.
     
    Last edited: May 4, 2020
    zubozrout likes this.
  12. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Hi,
    thank you for the update and the advanced logging option.

    I am attaching the log but it doesn't say much. I have deleted all turnouts at the beginning and started from scratch (all via web UI).
    Then I have added new turnouts and tried to switch them as I was adding these. Still on changing state of the turnout on address 2 my three turnouts switch one way and on address 3 they switch back. (same for the fourth turnout for addresses 4 and 5)

    More precisely this goes one way:

    Code:
    [Turnout 3] Set to Thrown
    [Turnout 3] Packet: [dcc] Accy 3 activate
    and this the other:

    Code:
    [Turnout 2] Set to Thrown
    [Turnout 2] Packet: [dcc] Accy 2 activate
    Accy 3 deactivate as well as Accy 2 deactivate does nothing with it.

    I am not sure how I could have ended up with this setup. But having two pins connected on my turnout decoders as the time I am trying to throw a switch on a certain address means the decoder should switch no matter what and save that particular address for future use. So I suppose that bit has worked well.

    There is however one thing that I have noticed earlier and that could perhaps be causing that (and my decoders may not understand that). It seems that I am unable to save turnouts as "DCC address only" as they always end up being "Board Address and Index". On the screenshot attached you can see a default config for me setting just Addresses to 1, 2, 3, 4 and 5. The indexes are filled in automatically and are looping through the cycle of 0 to 4. That could be just a web UI issue though, so it still could be saved correctly inside, I am not sure. Editing the turnout and re-saving as "DCC address only" won't fix that as it still registers as "Board Address and Index".

    [​IMG]

    I've played with these indexes, was setting them all to 0 for instance, but the behaviour was the same. Maybe that relates somehow.
     

    Attached Files:

  13. Pieter

    Pieter TrainBoard Member

    152
    46
    10
    I think you need to think of each MP1 module as a solenoid switch. The wiring diagram indicate it need to be wire like a solenoid switch. You probably going to need a DCC switch machine controller although a few won't work with the MP1.
     
  14. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Well, I am using a decoder designed specifically for this switch: http://www.fucik.name/masinky/MP1/ (the English is terrible, seems like someone just used Google Translate for that). Anyway, as mentioned earlier I've been able to use this combination of a MP1 motor and decoder using an older version of DCCppESP32 as well as DCC++ before that.
     
    Last edited: May 5, 2020
  15. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Yeah, that is a bug that will need to be fixed. From the console dump it did save as a DCC address:
    Code:
    [Turnout 1] Using DCC address 1 as type LEFT and initial state of Closed
    [Turnout 1] Set to Thrown
    [Turnout 1] Packet: [dcc] Accy 1 activate
    [Turnout 1] Set to Closed
    [Turnout 1] Set to Thrown
    [Turnout 1] Packet: [dcc] Accy 1 activate
    
    However, there seems to be another bug in this output in that it only created two DCC packets even though three events occurred. I'm wondering if it could have been a timing issue.. I'll see if I can reproduce this behavior.

    Now, for the rendering of the web UI... That looks like simply a bug in the conversion from internal data structure to json which is used by the web page *AND* for persistence. I'd guess if you restart the CS it will print out "Using address 1:0 as type LEFT and initial state of Closed" for ID 1.

    I'll go through and clean this up as it would be good to just use one format (DCC address) as the code no longer uses the legacy format anywhere except in the UI. Added to the TODO list...

    Can you connect the ack pulse side and read back the CVs? Specifically CV 1, 9 and 34? From the webpage it looks like these might give us clues as to what the MP1 decoder is thinking it is supposed to be listening for etc.
     
  16. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Thank you very much. As for this bit:
    how do I do that? I thought that I could read the CVs by connecting the decoders to a programming track individually?
    Will try to do that when I can, sounds like a good way to get some additional info. Thank you :)
     
  17. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    maybe? I'm not certain though, the webpage shows two PC817 ICs and something about a jumper for prog ack. I guess give it a try and see what it shows...

    Also I've pushed an update a bit ago to hopefully fix the display of the data now for turnouts in the web page, it will now always use the address and the "ID" column is now gone (it wasn't used anywhere outside of DCC++ support which can also use the address as the ID)
     
  18. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Ok, I think I may need some help with that. Could you please give me more info on what to do?

    I've tired this with another decoder which now goes one way on address 1 and back on address 2 (surprisingly no matter the Closed and Thrown state which for some reason matters to my other 3 switches reacting to addresses 2 and 3). Anyway, when trying to then read the CVs on the programming track the decoder just lights up its LED when the programing track power is on, but the reading fails in all cases:

    Code:
    [PROG 1/3] Attempting to read CV 1
    [PROG 1/3] CV 1, could not be verified
    [PROG 2/3] Attempting to read CV 1
    [PROG 2/3] CV 1, could not be verified
    [PROG 3/3] Attempting to read CV 1
    [PROG 3/3] CV 1, could not be verified
    [PROG] CV 1 value is -1
    Same goes for the other two addresses and probably any others too.

    I am not sure what's causing that and why would it be impossible to read the CVs. On the other hand I've actually never been able to use the reading feature. Just to confirm that I've connected one of my engines and am getting the same reading issues as with the above ^. Does that require anything more than having a decoder connected directly to my programing "track"?

    Thank you again for all your help :)
     
  19. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    I don't have one of those decoders so I can't really help with it unfortunately. But since you couldn't read the CVs it looks like it may not be sending the ack back to the CS.

    Ok, this gives a good clue as to what is happening and why.. The decoder may be using multiple DCC addresses, one for closed and the other for thrown. The current version of the CS is configured to use a single DCC address for the turnout and uses the activate flag to throw/close it. It should be possible to add support for sending different addresses for each event though.

    Which hbridge are you using? If you are using the L298 (arduino motor shield) do you have jumpers from A0/A1 to A2/A3 (or A4/A5)?
     
  20. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Try changing this line to:
    Code:
    packet->add_dcc_basic_accessory(_address + _thrown, true);
    
    If that fixes it then I will push that update. I'm reviewing the DCC packet created by the current code to what is in v1.2.3/v1.3.0 and spotted this as a possible difference.
     

Share This Page