I tried using my own Node ID which menuconfig shows as 0x050101016001 but the command station comes up as: Allocating new alias 0B9 for node 050101013f00 Which is your new ID, so I know the build worked. cmake file: set(CONFIG_LCC_NODE_ID "0x050101016001") sdkconfig.h #define CONFIG_LCC_NODE_ID 0x050101016001 sdkconfig CONFIG_LCC_NODE_ID=0x050101016001 A rebuild didn't build anything (l.e. build test and the rebuild just to make sure I got the right stuff). Want to see anything before I clear flash and try again? Maybe it was because you changed the ID and I also changed the ID.
the new default ID is 0x05020103F000 which is from a new 16bit ID range that I had allocated for various projects that are in the works. Changing the config via sdkconfig edits or menuconfig running should force a rebuild of all files. The node ID is persisted on the spiffs partition (or SD card if used). You should be able to click on the factory reset button in the web UI to force clear persistent config so it will regenerate from the compiled configuration.
Also, I plan on revisiting the config persistence layer as it seems to be causing a bit more problems than it is solving. The new strategy will be leverage the compiled config by default and override only select areas as necessary via reconfiguration via web portal or similar.
Thank you very much. I was able to build the latest master (91077e1) and flash it with the WiFi debug on. However, I am no longer able to reproduce the web UI not being able to load while idf.py is monitoring the board. Not sure what could have caused it but well, it is not longer happening so that's great . So the web UI is always accessible to me now. Nonetheless, here is the full log in case it is in any way interesting: https://zubozrout.cz/data/idf_monitor_dccppesp32.log All I can see there is the loop of never ending messages like this (only with a different and ever increasing number in the brackets): Code: I (44286) wifi: rsn valid: gcipher=3 ucipher=3 akm=5 but that seems completely unrelated to anything other than debugging turned on. And when I turn it off again, rebuild the app and re-flash it the issue with broken WiFi still doesn't occur to me so I guess it is all good now. The connection seems stable and the log clean.
@Atani ... oh, did you change the turnouts indexing/addressing? I've had some turnouts set up from 1 to 5 and now they work from 2 to 6. Just mentioning that in case it was not on purpose. Otherwise I don't really mind
Yes there was a couple bug fixes in this area. There was an off by one error in converting the legacy DCC++ format of turnout creation to a DCC decoder address format as well as the index used by the DCC++ adapter code being discarded and a zero offset index used instead which would change if you happened to delete a turnout. If you create a turnout based on its DCC decoder address or via the legacy DCC++ interface both should result in a consistent turnout definition. In the case of creating them via the web UI they will have a DCC++ index identical to their DCC address. If creating them via DCC++ the index provided will be used instead. Sent from my ONEPLUS A5010 using Tapatalk
Thought I'd give a quick update on the CS PCB... In the picture below the board on the right is the mostly assembled PCB as it will arrive from JLCPCB. There are a 15 SMD components to add to the board and 25 through-hole components (includes all pin headers). The blue board on the left is a 32 pin IO board that is fully configurable via LCC (OpenLCB). The IO Board is powered by the LCC bus and with the 500mA bus supply up to five can be on each isolated power segment, most users have two segments via one RR-CirKits PowerPoint. Now some feature updates on the CS.... Power Station interface via the LCC ports has been updated to have a dedicated 12V 500mA power supply with support for receiving RailCom feedback from connected boosters. All track outputs are fused (OPS at 3A, PROG and LCC at 350mA). OPS and PROG track now have LEDs to provide visual indication that the signal is going to the tracks, these can be disabled by disconnecting a jumper on the bottom side. Almost all through-hole components have been replaced with SMD variants, remaining through-hole components may get replaced in the future. I'm working on the details for offering the CS PCB as a kit (assembly required) and will also be offering the Gerber files along with a BOM with references for all components.
Here is a mostly assembled CS PCB. I will be changing at least three components from their current packages to one that is easier to hand solder or see if I can track down a component number on jlcpcb so they are pre-assembled. I'll be getting one of the io boards assembled for testing this evening and get both onto my desk for testing. Sent from my ONEPLUS A5010 using Tapatalk
The IO board has come out of the oven and needs only a tiny bit of rework.. And a better picture of the CS PCB
Would your I/O board be appropriate to report turnout positions to JMRI? Could it drive servos? What uses do you envision for it?
That should be doable provided there is some sort of logic signal exposed from the turnout (switch that is closed by servo as example). The IO board leverages LCC events for the IO pins (outputs will consume an event to change the state of the output, inputs will produce events based on the state change of the pin). Possibly, but I expect some extra components will be required to translate from a TTL signal to PWM for the servo. I'm thinking that pulsed output might work but will require tweaks to get the timing just right for turnout usage. The 32 IO pins are usable for most general purpose IO needs, ie: block occupancy detection, signals, control panels, CTC panels, etc. There are a few configuration options available for each of the 32 IO pins: input: debounce (X reads before it is considered ON/OFF) active high / active low output: pulsed (0 = on/off only, 1-255 = pulse count) pulse duration (0 - 255 ~30msec intervals) paired (used for combining two output pins so they are inverse of each other) active high / active low The IDC headers are setup for RR-CirKits IO modules to either plugin directly to the PCB or via ribbon cable. I'll be adding a "setup wizard" of sorts that will reconfigure the ports for a handful of RR-CirKits IO modules since some of them have specific configuration needs (ie: BOD-4 has four occupancy detectors and four outputs, BOD-8 has eight occupancy detectors, SCSD-8 requires active-high pulsed paired outputs, SMD-8 requires active low pulsed outputs, etc).
Sounds great! I have a lot of Tortoises driven by NCE Switch8s that I would love to provide feedback to JMRI. I was hoping to avoid a rip and replace for an LCC solution as that would get a bit pricey. So i could use the Tortoise switches to drive an input, using either one or two inputs per switch (depending on how anal I want to be about the actual position). It sounds like for my servo needs I'll need to develop my single thread LCC nano shield. I have a DCC one that drives the doors and lights on my roundhouse that I would like to convert to LCC. I would like to do some other automation things like crossings. It's been on the back burner for quite a while. Maybe I can dust it off after implementing the turnout feedback as a way to wet my feet in LCC.
Sounds like a great plan, you can also use the 5v and GND connections on the IO board for the Tortoise outputs likely. Or you can use a pin interrupt to capture the pulse from the IO board (or push button!) to toggle the state of a servo (ie: 90deg, 180deg). It doesn't necessarily need to be plugged directly into the LCC bus to leverage the bus. Sounds like a great test case. For my Servo board I was planning on using a PCA9685 to control up to 16 servos. In theory if I expose the I2C bus on the IO board it should be possible to leverage an Adafruit PCA9685 board with some sort of config options.
This is what I use on my DCC Roundhouse implementation since I have 10 stalls. Then just a couple more pins for lights. It works well, just no feedback on position to JMRI (which thinks each door is a turnout) but that's not quite as useful as feedback on an actual turnout.
Yes, the Uno would know at any given time the position and status of each door (they can all be in motion at any given time). An LCC solution could create events for each door's status change.
Yes, something like that... an event to consume for each state of the door (ie: door 1 closed = <nodeid>:00, door 1 open = <nodeid>:01, and so on).
If you need more than just open and closed you can encode more. When I asked a similar question Stu Baker pointed me to the time LCC standard - http://old.openlcb.org/trunk/specs/drafts/TimeProtocolS.pdf to see how non-on/off values can be encoded. Getting something to act on them is the harder part though as most things only accept one value.
